Re: [PATCH 2/2] Fix console handling during suspend/resume

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

On Wednesday 21 June 2006 10:04 am, Linus Torvalds wrote:
> On Wed, 21 Jun 2006, Alan Stern wrote:
> > 
> > At what stage do you restore power to the device?
> 
> I am ambivalent about this.

Good, because it's not necessarily the right question.  On most
SOC systems, the right question relates to clock gating.  As in,
"when do you re-enable the device's clocks?"  And disabling the
clocks doesn't necessarily imply losing any device state.  It will
mean the hardware state machines stop transitioning, but there are
devices (like MMC/SD controllers) where that doesn't matter since
the controller is a pure cpu slave.

Plus there are nuances like "which clocks do you enable when" ...
you may want to keep a controller-specific PLL off most of the
time, but leave the the registers (and basic hardware state machine)
clocked all the time except during sleep states.  (And maybe not
turn it off even then, if that device should be a wakeup event
source.  Of course, leaving it clocked during sleep states costs
maybe a couple milliAmps per device...)


> > How does the handling differ when you are doing runtime (AKA dynamic AKA 
> > selective) suspend/resume?
> 
> I think that you should be perfectly able to do a single-device "shut that 
> device off" with a simple:
> 
> 	save_state(dev);
> 	suspend(dev);
> 	..
> 	restore_state(dev);

Separating the save/restore state for STR seems dubious to me.  I've not
seen hardware where it's necessary ... in large part because the point of
runtime PM is less about "shut it off" and more just "conserve power".  And
the hardware folk tend to do the right thing there, so that low power modes
don't imply losing any state.  (PCI drivers may need to care about D3 vs D2
of course, since D3 allows state trashing that D2 doesn't.  But that's a
separate discussion.)

 
> without having any other suspend going on and without iterating over any 
> other devices.
> 
> Of course, whoever does this needs to verify that the device itself is 
> quiescent (or able to wake up itself and force its own "restore_state()").
> 
> I don't see any real issues there, do you?

Child devices need to be suspended first, which is an issue the current
PM core completely ignores.  Until it does, any driver supporting runtime
suspend needs to at least verify that a device's children were suspended
before it tries to suspend that device.

- Dave