Re: Nested suspends; messages vs. states

[David Brownell <david-b-yBeKhBN/0LDR7s880joybQ@public.gmane.org>]

[-- Attachment #1: Type: text/plain, Size: 4179 bytes --]

On Monday 21 March 2005 8:21 pm, Benjamin Herrenschmidt wrote:
> 
> Yup, the model we are desinging now should allow for arbitrary
> transitions I suppose as long  as the target state is legal vs. the
> dependencies.

Leading to the question:  how are the dependencies identified and
enforced?

My current thought is that it's wrong to expect the PM core code to
do all this.  Discussion on this list strongly suggests to me that
we'll never achieve a Grand Unified Theory of PM into which every
device, bus, platform, and board will fit ... unless we give up
on the notion that _everything_ be centrally controlled.  The key
will be having good ways to delegate all the important issues.

So for example it would make sense to have device suspend() logic
verify any dependencies for the target state, and then just fail
cleanly if they're not satisfied.

That'll mostly be an issue for bridge drivers ... like PCI
bridges, host adapters for things like USB, hubs, and so on.
But it also shows a way to handle custom hardware, which may
not be as regular as the PC and server centric developers want
the world to be...


> > The simplest way of handling this is to allow explicitly for such
> > possibilities.  When a device is asked to go from a very-low-power state
> > to a slightly-low-power state, it should be legal for the driver to leave
> > it in the very-low-power state.
> 
> Well... I'm not sure about that one. If the power states represent some
> performance states, the system may want to raise the performance a bit
> at the expensve of power and would stay low perf unless a full
> transition to state "full on" is done ?
> 
> I suspect it's a per driver responsibility here. I suppose common sense
> will dicate what can be allowed and what not.

I'm happy with per-driver responsibilities.  Less so with the notion
of conflating power states and performance modes; they seem a bit more
orthogonal to me.

On the other hand, I've also described the role of a driver suspend()
call as just picking one of potentially many device power states that
are compatible with the target (system) state, and I think there's
common ground there.  If the "very low" device power state is compatible,
nobody should care ... because the request to the driver should have been
"become compatible with this system power state", and only in unusual
cases (sysfs requests) "go into this device power state".

So, two types of request to drivers then.  The main one would be to
become compatible with a given system power state; flexible.  The
inflexible one would be to go into a specific device power state.



> One thing that is important if we deal with partial suspend and tree
> dependencies is the ordering...
> 
> When a device is asked to enter a given state, the dependencies of the
> childs has to be checked in a different order if we are going to lower
> power than if we are going to higher power.
> 
> If going to lower power (that is toward suspend), we must check the
> dependencies of childs and eventually low-power them before the parent
> is actually state changed.
> 
> If going to higher power, it is the opposite.

The handful of drivers that deal with dependencies can be responsible
for that ordering.  They should be able to delegate much of the work
to PM core code (else why have a PM core?).


> So I think we need to have the states in some sort of order at least so
> the core has a notion of what is "lower" and what is "higher" power to
> deal with that. Though I suppose we could also have optional hooks in
> driver (pre-parent-change and post-parent-change) for driver who want to
> be sneaky, but that gets nasty and complicated.

I suspect that having all device states in some sort of order like that
is a problem isomorphic with the Grand Unified Theory of PM, which I
said we shouldn't try to derive.

If the drivers that deal with dependencies -- "bridge" drivers, for
now -- can tell the PM core what to do with a given device (before
me, after me, skip it) the PM core could just ask those bridge drivers
to build a list, then walk the list issuing the right calls.  Instead
of having a single global list, build it on demand.

- Dave

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]