[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20180525140213.GI30172@localhost>
Date: Fri, 25 May 2018 16:02:13 +0200
From: Johan Hovold <johan@...nel.org>
To: Tony Lindgren <tony@...mide.com>
Cc: Johan Hovold <johan@...nel.org>,
Sebastian Reichel <sre@...nel.org>,
"H. Nikolaus Schaller" <hns@...delico.com>,
Andreas Kemnade <andreas@...nade.info>,
Mark Rutland <mark.rutland@....com>,
Arnd Bergmann <arnd@...db.de>, Pavel Machek <pavel@....cz>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@...r.kernel.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Rob Herring <robh+dt@...nel.org>, linux-serial@...r.kernel.org,
linux-omap@...r.kernel.org, linux-pm@...r.kernel.org,
Andy Shevchenko <andy.shevchenko@...il.com>
Subject: Re: OMAP serial runtime PM and autosuspend (was: Re: [PATCH 4/7]
dt-bindings: gnss: add u-blox binding))
On Thu, May 24, 2018 at 06:32:37AM -0700, Tony Lindgren wrote:
> * Johan Hovold <johan@...nel.org> [180524 09:20]:
> > On Mon, May 21, 2018 at 08:48:32AM -0700, Tony Lindgren wrote:
> > > Well if you have some better mechanism in mind let's try it out. Short of
> > > sprinkling pm_runtime_force_suspend/resume calls all over, I'm out of ideas
> > > right now.
> >
> > Yeah, that would be too much of a hack and likely wouldn't work either
> > (and we really should do away with those _force calls altogether).
> >
> > I've been thinking a bit too much about this already, but it may be
> > possible to use the pm QoS framework for this. A resume latency can be
> > set through sysfs where "n/a" is defined to mean "no latency accepted"
> > (i.e. controller remains always-on while port is open) and "0" means
> > "any latency accepted" (i.e. omap aggressive serial RPM is allowed).
>
> Oh yeah, PM QoS might work here!
Actually, after reading a recent QoS related bug report, I realised that
a resume latency request of "n/a" is actually a third way of disabling
runtime PM, which similarly to the negative autosuspend would prevent
also a closed port from suspending.
Using a small positive resume latency for this feels like too much of a
hack, but defining a new QoS flag might still work.
Johan
Powered by blists - more mailing lists