linux-kernel - RE: [PATCH] media: rc: gpio-ir-recv: add QoS support for cpuidle system

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: <DB8PR04MB6795D5228426C7D93AF08081E63F0@DB8PR04MB6795.eurprd04.prod.outlook.com>
Date:   Fri, 18 Sep 2020 01:42:15 +0000
From:   Joakim Zhang <qiangqing.zhang@....com>
To:     Sean Young <sean@...s.org>
CC:     "mchehab@...nel.org" <mchehab@...nel.org>,
        "linux-media@...r.kernel.org" <linux-media@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        dl-linux-imx <linux-imx@....com>
Subject: RE: [PATCH] media: rc: gpio-ir-recv: add QoS support for cpuidle
 system


Hi Sean,

> -----Original Message-----
> From: Sean Young <sean@...s.org>
> Sent: 2020年9月18日 4:44
> To: Joakim Zhang <qiangqing.zhang@....com>
> Cc: mchehab@...nel.org; linux-media@...r.kernel.org;
> linux-kernel@...r.kernel.org; dl-linux-imx <linux-imx@....com>
> Subject: Re: [PATCH] media: rc: gpio-ir-recv: add QoS support for cpuidle
> system
> 
> Hi Joakim,
> 
> On Thu, Sep 17, 2020 at 09:12:32AM +0000, Joakim Zhang wrote:
> >
> > > -----Original Message-----
> > > From: Sean Young <sean@...s.org>
> > > Sent: 2020年9月15日 17:34
> > > To: Joakim Zhang <qiangqing.zhang@....com>
> > > Cc: mchehab@...nel.org; linux-media@...r.kernel.org;
> > > linux-kernel@...r.kernel.org; dl-linux-imx <linux-imx@....com>
> > > Subject: Re: [PATCH] media: rc: gpio-ir-recv: add QoS support for
> > > cpuidle system
> > >
> > >
> >
> > [...]
> > > > @@ -92,6 +113,12 @@ static int gpio_ir_recv_probe(struct
> > > > platform_device *pdev)
> > > >
> > > >  	platform_set_drvdata(pdev, gpio_dev);
> > > >
> > > > +
> > > > +	pm_runtime_set_autosuspend_delay(dev, (rcdev->timeout / 1000 /
> > > > +1000));
> > >
> > > rcdev->timeout is in microseconds (since very recently), so this is wrong.
> > > Also, the timeout can be changed using the LIRC_SET_REC_TIMEOUT
> > > ioctl (using ir-ctl -t in userspace). The autosuspend delay should
> > > be updated when this happens. This can be done by implementing the
> s_timeout rcdev function.
> >
> > Hi Sean,
> >
> > I come across a problem when implementing this feature.
> >
> > At probe stage, devm_rc_register_device -> change_protocol, then timeout
> set to 125ms.
> >
> > When echo sony or nec to protocols, will call change_protocol changing the
> timeout value, that timeout would change to handler->min_timeout + 10ms.
> For sony is 16000000ns, for 15625000ns.
> 
> The sony protocol decoder wants a 6ms space after the last bit. So, the timeout
> for the IR receiver can be set to 6ms (plus 10ms margin). This has the
> advantage that decoding is happens very quickly. Before this change, there as a
> 125ms delay before the first and last IR frame was decoded. This causes
> decoding to feel laggy and keys also a bit sticky.

Yes, I can understand this, each IR protocols have their own timeout, this is reasonable.


> > This is not the way I want to take before, this would frequently disable/enable
> cpuidle. So is it necessary to provide s_timeout, this callback should be used to
> change protocols' timeout?
> > If implement s_timeout, users need change the timeout value from
> userspace, this is a mandatory operation and unfriendly. And it will affect
> protocol's timeout.
> >
> > 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.

> 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?

> Thanks
> Sean
> 
> >
> > Best Regards,
> > Joakim Zhang
> > > > +	pm_runtime_use_autosuspend(dev);
> > > > +	pm_runtime_set_suspended(dev);
> > > > +	pm_runtime_enable(dev);
> > > > +
> > > >  	return devm_request_irq(dev, gpio_dev->irq, gpio_ir_recv_irq,
> > > >  				IRQF_TRIGGER_FALLING | IRQF_TRIGGER_RISING,
> > > >  				"gpio-ir-recv-irq", gpio_dev);