Hi Joakim, On Fri, Sep 18, 2020 at 01:42:15AM +0000, Joakim Zhang wrote: > > -----Original Message----- > > From: Sean Young <s...@mess.org> > > Sent: 2020年9月18日 4:44 > > To: Joakim Zhang <qiangqing.zh...@nxp.com> > > Cc: mche...@kernel.org; linux-me...@vger.kernel.org; > > linux-kernel@vger.kernel.org; dl-linux-imx <linux-...@nxp.com> > > Subject: Re: [PATCH] media: rc: gpio-ir-recv: add QoS support for cpuidle > > system
-snip- > > > Autosuspend delay should be fixed value, should be set to gpio device > > > timeout > > value, which is 125ms. > > > > So the idea was that cpuidle is only enabled while IR frames are being > > received, > > that's why I suggested it. > > May be a typo, "cpuidle is only DISABLED while IR frames are being receive,", > this is not I want to implement, experiments have also shown poor results. Sorry, yes I got this wrong. You are right. > > If you set the autosuspend delay to 125ms, then the cpuidle will not be > > enabled > > between IR frames. Maybe this is what you want, but it does mean cpuidle is > > totally suspended while anyone is pressing buttons on a remote. > > Yes, this is what I want, cpuidle is totally disabled while pressing buttons, > disable cpuidle at the first frame then keep disabled until there is no > activity for a while. > So that we only can not decode the first frame, such as, if transmitting 4 > frames once, we can correctly decode 3 times. > > I also try your suggestion, set autosuspend delay time to protocol's timeout > value, but the result is terrible. If transmitting 4 frames once, we can't > correctly decode 3 times, > even can't decode it sometime. The sequence is, cpu in idle state when the > first frame coming, then disable cpu idle until protocols' timeout, cpu in > idle state again, the first frame can't be decoded. > The second frame coming, it will repeat the behavior of the first frame, may > cause the second frame can't be decode...... > > Can you take account of I have done in the first version, autosuspend delay > time is set to 125ms? Yes, in retrospect you are right. Trying to shorten the cpuidle suspended period will not work. I am sorry about this. How about setting the autosuspend period in devicetree, and 0 will turn this feature off completely? Thanks, Sean
