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
