linux-kernel - Re: [RESEND PATCH v6 2/4] media: chips-media: wave5: Support runtime suspend/resume

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Thu, 20 Jun 2024 19:50:14 +0530
From: Devarsh Thakkar <devarsht@...com>
To: Nicolas Dufresne <nicolas.dufresne@...labora.com>,
        "jackson.lee"
	<jackson.lee@...psnmedia.com>,
        "mchehab@...nel.org" <mchehab@...nel.org>,
        "sebastian.fricke@...labora.com" <sebastian.fricke@...labora.com>
CC: "linux-media@...r.kernel.org" <linux-media@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "hverkuil@...all.nl" <hverkuil@...all.nl>,
        Nas Chung
	<nas.chung@...psnmedia.com>,
        "lafley.kim" <lafley.kim@...psnmedia.com>,
        "b-brnich@...com" <b-brnich@...com>, "Luthra, Jai" <j-luthra@...com>,
        Vibhore
	<vibhore@...com>, Dhruva Gole <d-gole@...com>,
        Aradhya <a-bhatia1@...com>, "Raghavendra, Vignesh" <vigneshr@...com>
Subject: Re: [RESEND PATCH v6 2/4] media: chips-media: wave5: Support runtime
 suspend/resume

Hi Nicolas,

On 20/06/24 19:35, Nicolas Dufresne wrote:
> Hi Devarsh,
> 
> Le jeudi 20 juin 2024 à 15:05 +0530, Devarsh Thakkar a écrit :
>> In my view the delayed suspend functionality is generally helpful for devices
>> where resume latencies are higher for e.g. this light sensor driver [2] uses
>> it because it takes 250ms to stabilize after resumption and I don't see this
>> being used in codec drivers generally since there is no such large resume
>> latency. Please let me know if I am missing something or there is a strong
>> reason to have delayed suspend for wave5.
> 
> It sounds like you did proper scientific testing of the suspend results calls,
> mind sharing the actual data ?

Nopes, I did not do that but yes I agree it is good to profile and evaluate
the trade-off but I am not expecting 250ms kind of latency. I would suggest
Jackson to do the profiling for the resume latencies.

But perhaps a separate issue, I did notice that intention of the patchset was
to suspend without waiting for the timeout if there is no application having a
handle to the wave5 device but even if I close the last instance I still see
the IP stays on for 5seconds as seen in this logs [1] and this perhaps could
be because extra pm counter references being hold.

[2024-06-20 12:32:50] Freeing pipeline ...

and after 5 seconds..

[2024-06-20 12:32:55] |   204     | AM62AX_DEV_CODEC0 | DEVICE_STATE_ON |
[2024-06-20 12:32:56] |   204     | AM62AX_DEV_CODEC0 | DEVICE_STATE_OFF

[1]: https://gist.github.com/devarsht/009075d8706001f447733ed859152d90

Regards
Devarsh