public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Sean Young <sean@mess.org>
To: Joakim Zhang <qiangqing.zhang@nxp.com>
Cc: "mchehab@kernel.org" <mchehab@kernel.org>,
	"linux-media@vger.kernel.org" <linux-media@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	dl-linux-imx <linux-imx@nxp.com>
Subject: Re: [PATCH] media: rc: gpio-ir-recv: add QoS support for cpuidle system
Date: Thu, 17 Sep 2020 21:43:36 +0100	[thread overview]
Message-ID: <20200917204336.GA21441@gofer.mess.org> (raw)
In-Reply-To: <DB8PR04MB6795CB9F519D2BD277654B29E63E0@DB8PR04MB6795.eurprd04.prod.outlook.com>

Hi Joakim,

On Thu, Sep 17, 2020 at 09:12:32AM +0000, Joakim Zhang wrote:
> 
> > -----Original Message-----
> > From: Sean Young <sean@mess.org>
> > Sent: 2020年9月15日 17:34
> > To: Joakim Zhang <qiangqing.zhang@nxp.com>
> > Cc: mchehab@kernel.org; linux-media@vger.kernel.org;
> > linux-kernel@vger.kernel.org; dl-linux-imx <linux-imx@nxp.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.

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

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.

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);

  reply	other threads:[~2020-09-17 20:43 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-15 15:02 [PATCH] media: rc: gpio-ir-recv: add QoS support for cpuidle system Joakim Zhang
2020-09-15  9:33 ` Sean Young
2020-09-15 10:55   ` Joakim Zhang
2020-09-15 20:19     ` Sean Young
2020-09-16 10:22       ` Joakim Zhang
2020-09-16 18:19         ` Sean Young
2020-09-17  9:12   ` Joakim Zhang
2020-09-17 20:43     ` Sean Young [this message]
2020-09-18  1:42       ` Joakim Zhang
2020-09-18  8:23         ` Sean Young
2020-09-18  8:56           ` Joakim Zhang
     [not found] ` <CAHp75Vftg3GmBsCCrZeXo4eofOYTJ2ii+s64hY5FqZadvX6Bww@mail.gmail.com>
     [not found]   ` <DB8PR04MB6795840F4C0D938A14D1E3BEE6200@DB8PR04MB6795.eurprd04.prod.outlook.com>
2020-09-15 10:42     ` Andy Shevchenko
  -- strict thread matches above, loose matches on Subject: below --
2020-09-15 14:57 Joakim Zhang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200917204336.GA21441@gofer.mess.org \
    --to=sean@mess.org \
    --cc=linux-imx@nxp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=mchehab@kernel.org \
    --cc=qiangqing.zhang@nxp.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox