Re: [linux-pm] suspend blockers & Android integration

[David Brownell <david-b@pacbell.net>]

--- On Fri, 6/11/10, James Bottomley <James.Bottomley@suse.de> wrote:

> > Do we at least have a clean way that a driver can
> > reject a system suspend?  I've lost track of
> many
> > issues, but maybe this could be phrased as a QOS
> > constraint:  the current config of driver X
> needs
> > clock Y active to enter the  target system
> suspend
> > state, driver's suspend() method reports as
> much.  Then the entry to
> > that system state gets blocked
> > if the clock isn't enabled.
> 
> So in QoS modifications to android patches, the answer is "yes" ...
> except that the current android patch set didn't actually
> have this type
> of wakelock in it.

Except, we're not talking "wakelock" ... :)

So ... no, these cases still have no solution.
(I think  that's at least five years now.)


> The one thing that does look difficult is that these power
> constraints
> are device (and sometimes SoC) specific.

Exactly why they make good examples  for
turning up framework limitations... like
having overlooked constraints coming from
various SoC peripherals.

> Expressing them in a generic way
> for the cpu govenors to make sense of might be hard.

Requiring "CPU governors" to be involved in such
stuff feels a bit off-course to me.  At least, if
the involvement is very deep. The constraints are
from the integrated peripherals, not (usually)
from the CPU

There are plent of places to hang SoC or
device specific data, once there's awareness
that without such data, (which PCs hide behind
ACPI bytecode) the PM framework is missing out
on support for some desirable low power modes.


> 
> > (That QOS constraint should be removed when that
> > driver no longer needs to issue wakeups; that's
> > not quite the same as "removed by driver.resume().
> 
> The USB one needs user input, doesn't it,

I don't quite see that.  The drivers get called
in enough places, and they'll know if the system
is going to be in a suspend state where they need
to be partially 
aactive (with various QOS constraints, or they
can't work.

> since user hotplug might (or
> might not) be one of the wakeup sources.

If it wakes via hotplug, then the driver must
already Do The Right Thing; what input would
be needed  (Beyond changing the cable config)?

> 
> James
> 
> 
> --