Message-ID: <2674541.jV2qHCZlHf@vostro.rjw.lan>
Date:	Fri, 18 Jul 2014 03:30:31 +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 05:43:42 PM Dmitry Torokhov wrote:
> On Friday, July 18, 2014 02:43:02 AM Rafael J. Wysocki wrote:
> > 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)
> 
> This is default approach that works for many, but not necessarily all  use 
> cases. I believe docked with lid closed scenario was mentioned already.
> 
> > 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.
> 
> OK, so how do we let the drivers know that they should start being aggressive 
> with PM and that they should disable remote wakeup? I'd rather not add 
> subsystem-specific interface for this, that is why we are reaching out in the 
> first place.

For disabling remote wakeup we have a PM QoS flag that I'm not entirely happy
with, so I guess we can replace it with something saner (I talked about that
with Alan during the last year's LinuxCon, but then didn't have the time to
get to that).

For the whole thing I guess we can add a sysfs attribute under devices/.../power
that will need to be exposed by drivers supporting that feature.  I'm not sure
how to call it, though.

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