Re: Nested suspends; messages vs. states

[Pavel Machek <pavel-+ZI9xUNit7I@public.gmane.org>]

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

Hi!

> > 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?

Yes.

There are many drivers that do not fit your idea of "driver". Like
mtrrs. Some drivers only ever do work on resume, etc. Forcing driver
to think how to split it into class->stop, bus->save_state and
bus->enter state is bad idea. [Notice that almost no drivers need
->save_state operation...]
								Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

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