On Wed, 23 Mar 2005, Benjamin Herrenschmidt wrote:
>
> > Just to clarify, are you suggesting that the functional (not necesarily
> > literal) steps to fully suspend a device during a system state transition
> > are first to 'suspend' it, preventing it from being used and accessed or
> > being suspended/resumed from userpsace; then to have it directly enter a
> > low power state (e.g. via an enter_state() method)?
>
> At the system level, low power state must be entered atomically with the
> actual suspending of the driver. That is, when suspend() has returned,
> th device must be sleeping. That is necessary for the good old reason
> that once the parent is asleep, no way you can talk to your device.
I wasn't disputing that. What I was trying to say was the core could
effectively do:
for each device {
device->suspend(); /* Stop Device */
device->enter_state(); /* Power Down */
}
The reason I'm going down this road is because I think it could possibly
be split into such a way like this:
device->class->stop(dev, system_state);
device->bus->save_state(dev, system_state);
device->bus->enter_state(dev, system_state);
The first would perform functional-level suspension - stopping current
transactions and preventing future ones.
The second would call down to the device driver and save the device
context for the system state being entered.
The third would call down to the device driver and actually enter the low
power state.
Functionally, this is what happens. Do you see a reason to/not to break it
up programmatically?
...
Too many subjects in 1 email. Snipping and replying separately. :)
Pat
