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]

Message-ID: <147fddd4-0f73-0546-b73e-d8e2326bfb2a@ti.com>
Date: Fri, 21 Jun 2024 18:01:59 +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 23:02, Nicolas Dufresne wrote:
> Le jeudi 20 juin 2024 à 19:50 +0530, Devarsh Thakkar a écrit :
[..]
 > Imagine that userspace is going gapless playback, if you have a lets say
30ms on
> forced suspend cycle due to close/open of the decoder instance, it won't
> actually endup gapless. The delay will ensure that we only suspend when needed.
> 

Shouldn't the applications doing gapless playback avoid frequent open/close of
the decoder instance too as it will add up re-instantiation (initializing hw,
allocating buffers) and cleanup (de-initialization and freeing up of buffers)
delay for each open/close respectively ? Even in case of scenario where
resolution of next stream is different than previous, I guess the application
can still hold up the file handle and do the necessary setup (stream
off/stream on/REQBUFS etc) required for re-initialization ?

Regards
Devarsh