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 for Android: free password hash cracker in your pocket

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

Message-ID: <b2f5c00d5567a37129f691a89063c6196fbb142a.camel@collabora.com>
Date: Mon, 15 Jul 2024 13:01:49 -0400
From: Nicolas Dufresne <nicolas.dufresne@...labora.com>
To: Devarsh Thakkar <devarsht@...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,

Le vendredi 21 juin 2024 à 18:01 +0530, Devarsh Thakkar a écrit :
> 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 ?

I don't have a very strong opinion here, I usually try to avoid optimizing for
what userspace should do. Best would be to build your opinion on your own
testing of existing userspace (perhaps not just GStreamer).

I think if you have good reason to force suspend when the last instance is
destroyed, please do so (e.g. stability issue, race conditions etc). So far, I
don't personally know what is the issue with leaving a small delay in order to
avoid a suspend / resume cycle if one quickly close the last instance and open
the next one immediately. A comment would be nice, so no one fall in such a trap
later.

Nicolas