[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1cefd686-2eb2-e0b2-0b24-2c4efb0c41a1@ti.com>
Date: Thu, 20 Jun 2024 20:22:35 +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>
Subject: Re: [RESEND PATCH v6 2/4] media: chips-media: wave5: Support runtime
suspend/resume
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.
Regards
Devarsh
Powered by blists - more mailing lists