LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Tony Lindgren <firstname.lastname@example.org>
To: Johan Hovold <email@example.com>
Cc: Greg Kroah-Hartman <firstname.lastname@example.org>,
Rob Herring <email@example.com>, Sebastian Reichel <firstname.lastname@example.org>,
"H. Nikolaus Schaller" <email@example.com>,
Andreas Kemnade <firstname.lastname@example.org>,
Mark Rutland <email@example.com>,
Arnd Bergmann <firstname.lastname@example.org>, Pavel Machek <email@example.com>,
Subject: Re: [PATCH 1/2] serdev: add controller runtime PM support
Date: Fri, 11 May 2018 09:00:35 -0700 [thread overview]
Message-ID: <20180511160035.GJ98604@atomide.com> (raw)
* Johan Hovold <firstname.lastname@example.org> [180511 13:14]:
> On Fri, May 11, 2018 at 05:56:27AM -0700, Tony Lindgren wrote:
> > * Johan Hovold <email@example.com> [180511 08:09]:
> > > On Thu, May 10, 2018 at 09:48:31AM -0700, Tony Lindgren wrote:
> > > > If this solution works for GPS then this should also work for modems
> > > > that might produce data. And as long as the serdev consumer driver
> > > > can wake up the UART with pm_runtime_get(&serdev->ctrl->dev) then
> > > > the out of band GPIO wake interrupts will work to. And for TX,
> > > > the serdev consumer driver can toggle the wake GPIO, and then call
> > > > pm_runtime_get(&serdev->ctrl->dev).
> > >
> > > I don't think any serdev driver action is needed for TX however. The
> > > serial driver itself would know that there's data in the write buffer
> > > and should manage PM itself until the buffer has been drained (which may
> > > never happen due to flow control).
> > Sure if the serial driver can manage TX wake directly. However, the
> > case I'm thinking needs few hundred milliseconds after toggling the
> > GPIO before we can even attempt to do TX. I guess what I'm saying
> > let's not try to stuff any "application specific" GPIO handling to
> > generic UART code :)
> Ok, I think understand what you have in mind now, but that sounds like
> something which should be handled by the serdev driver which is
> responsible for the power state of the serial-attached device (e.g.
> through a pm_runtime_get_sync(&serdev->dev)).
Yes that makes sense.
> And you're absolutely right that that RPM reference cannot be dropped
> before any written data has reached the device. But note that the serial
> controller responsible for that transfer could potentially runtime
> suspend before the write buffer has been drained (e.g. during long
> periods without I/O due to flow control).
> So I still think that TX is not directly related to this patch and RPM
> support for serdev controllers.
Yes you are right after the device on the serial line has been properly
woken up then TX should just work and at that point the UART driver
runtime PM can take care of things.
next prev parent reply other threads:[~2018-05-11 16:00 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-09 9:44 Johan Hovold
2018-05-09 9:44 ` [PATCH EXAMPLE 2/2] dbg: gnss: sirf: allow aggressive controller runtime PM Johan Hovold
2018-05-10 16:48 ` [PATCH 1/2] serdev: add controller runtime PM support Tony Lindgren
2018-05-11 8:07 ` Johan Hovold
2018-05-11 12:56 ` Tony Lindgren
2018-05-11 13:12 ` Johan Hovold
2018-05-11 16:00 ` Tony Lindgren [this message]
2018-05-11 12:35 ` Sebastian Reichel
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--subject='Re: [PATCH 1/2] serdev: add controller runtime PM support' \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).