On Wed, 2005-03-23 at 10:20 -0800, Patrick Mochel wrote:
> 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 */
> }
Where is room in the above for suspend() to be the one deciding what
state to enter ? suspend() has no way to do it with your example. I'd
rather have suspend optionally call device_enter_state() itself (and not
device->enter_state if we decide to have a function pointer per state in
the state array, those won't be pointers in struct device, which is
probably better since enter_state() would end up just switch/casing on
them anyway).
> 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.
It's up to the driver's suspend() to do those. I would keep that policy
in there, really. I agree that a class->stop() may be useful for putting
the "common" code, but I'd rather have it seen as a "helper" that the
driver can call.
> 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.
save_state would be nop most of the time. enter_state may have to save
things too... I think the distinction between those is very academic and
makes little sense in practice.
> Functionally, this is what happens. Do you see a reason to/not to break it
> up programmatically?
Because I think it's a lot more flexible not to do it :) That is,
breaking it up _imposes_ a structure on driver that I'd rather avoid in
this case. Just let them have suspend(), that can eventually use the
state mecanism and maybe a class "stop" helper, but some drivers will
want to do tricks etc... or do things before stopping the class, you
can't even imagine now :) So I'd rather not have the core do that.
Ben.
