Date:	Fri, 18 Jul 2014 02:43:02 +0200
From:	"Rafael J. Wysocki" <rjw@...ysocki.net>
To:	Dmitry Torokhov <dtor@...gle.com>
Cc:	Alan Stern <stern@...land.harvard.edu>,
	Bastien Nocera <hadess@...ess.net>,
	Patrik Fimml <patrikf@...omium.org>, linux-pm@...r.kernel.org,
	Benson Leung <bleung@...gle.com>, linux-input@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: Power-managing devices that are not of interest at some point in time

On Thursday, July 17, 2014 09:59:19 AM Dmitry Torokhov wrote:
> On Thursday, July 17, 2014 10:39:16 AM Alan Stern wrote:
> > On Wed, 16 Jul 2014, Dmitry Torokhov wrote:
> > > We are not planning on implementing the policy in kernel, that's
> > > indeed task for userspace; but unless we bring in the heavy hammer of
> > > forcibly unbinding drivers, we do not currently have universal
> > > mechanism of quiescing devices.
> > 
> > We sort of do: the ->freeze() callback.  But it wasn't intended for
> > this kind of use; drivers may very well expect that userspace will
> > already be frozen when the callback runs.  Besides, ->freeze() is
> > supposed to quiesce devices without powering them down, whereas you
> > want to do both.
> 
> Right.
> 
> > 
> > What you're asking for is different from anything the PM subsystem has
> > done before.
> 
> Right.
> 
> > Given this fact, I don't see any alternatives to adding a
> > new API or repurposing an existing API.  Either one would be somewhat
> > painful.
> > 
> > For example, we could arrange to invoke ->suspend().  However, since
> > the circumstances would be unusual (userspace is still running,
> > ->prepare() was not called beforehand, ->suspend_irq() won't be called
> > afterward), subsystems and drivers may very well react inappropriately.
> 
> I do not think anybody expects that drivers would not have to be modified to 
> support this functionality; I expect drivers would have to declare themselves 
> "queiscable" and therefore would assert that they will act according to 
> whatever rules we set up. I only want to make sure that this new state is 
> added to existing list of PM states rather than creating completely new 
> facility, so that driver authors have a chance to understand PM state 
> transitions that involve their driver.

If you're referring to runtime PM, it doesn't use "states".  It uses status
values (you can think of them as metastates) which are "active", "suspended"
or in-transit from one to the other.  There's no room for more of these in
the design, I'm afraid.

Moreover, .runtime_suspend() can only be called when the device is quiescent
already.  [That also applies to .suspend_late() and .suspend_irq() for
system suspend and the freezing of tasks is requisite for the .prepare() and
.suspend() callbacks (and the corresponding hibernation-related ones).]

>From past discussions on similar topics it followed that there really was
no generic way for individual drivers to quiesce devices on demand as long as
user space was running.  Everything we could come up with was racy, this way or
another.  That is the reason for using the freezer during system suspend.  In
other words, if you want drivers to quiesce devices by force, you need to quiesce
user space by force to start with - for example by freezing it.

For runtime PM, on the other hand, the underlying observation is that drivers
should be able to detect when devices are already quiescent and initialize power
transitions at those points.  It's role is to help with that, but not with quiescing
things.

That said, in the "laptop lid closed" scenario (assuming that the system is not
supposed to suspend in response to that, which in my opinion is the best approach)
the problem really seems to be that drivers are not aggressive enough with starting
PM transitions (using runtime PM) when they see no activity.  Thus it seems that
when the lid is closed, it'll be good to switch the drivers into a "more aggressive
runtime PM mode" in which they will use any opportunity to start a power transition
without worrying about extra latencies resulting from that.  In that mode they
should also disable remote wakeup.  I think this should be sufficient to address
the use case at hand.

Rafael

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists