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: <0b84bd4640c4c7ff52d1452d73e1ba46f6cedd7d.camel@collabora.com>
Date: Thu, 20 Jun 2024 11:24:03 -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>
Subject: Re: [RESEND PATCH v6 2/4] media: chips-media: wave5: Support
 runtime suspend/resume

Le jeudi 20 juin 2024 à 20:22 +0530, Devarsh Thakkar a écrit :
> Hi Jackson, Nicolas,
> 
> On 20/06/24 19:33, Nicolas Dufresne wrote:
> > Hi Jackson, Devarsh,
> > 
> > Le mercredi 19 juin 2024 à 23:56 +0000, jackson.lee a écrit :
> > > Hi Devarsh
> > > 
> > > If there is no feeding bitstreams during encoding and decoding frames, then driver's status is switched to suspended automatically by autosuspend.
> > > And if we don’t use autosuspend, it is very difficult for us to catch if there is feeding or not while working a pipeline.
> > > So it is very efficient for managing power status.
> > > 
> > > If the delay is very great value, we can adjust it.
> > 
> > One way to resolve this, would be if someone share measurement of the suspend /
> > resume cycle duration. With firmware (third party OS) like this, the cost and
> > duration is few order of magnitude higher then with more basic ASIC like Hantro
> > and other single function HW.
> > 
> > Yet, 5s might be to much (but clearly safe), but getting two low may means that
> > we suspect "between two frames", and if that happens, we may endup with various
> > range of side effect, like reduce throughput due to suspend collisions, or even
> > worse power footprint. Some lab testing to adjust the value will be needed, we
> > have very little of that happening at the moment as I understood.
> > 
> 
> Okay I see the intention here is that if there is a process holding the vpu
> device handle and the input feed is stalled for some seconds due to network
> delay or CPU throughput then after a specified timeout say 5 seconds we want
> to suspend even if the process is still active and holding the vpu device
> handle ? I agree then if we want to support this feature a safer/slightly
> larger value is required to avoid frequent suspend/resume due to network
> jitter or any other bottleneck and maybe 5s is a good value to start with.
> 
> But if last instance is closed/stops streaming and there is no process holding
> the device handle anymore then I think we should suspend immediately without
> any delay.

Our emails crossed each other, but see my explanation about gapless playback
transiton, were userspace may destroy and create a new video session. I believe
5s is way too long to be honest.

Nicolas

> 
> Regards
> Devarsh