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

[Adam Belay <ambx1@neo.rr.com>]

On Fri, Jun 23, 2006 at 04:44:40PM -0700, Linus Torvalds wrote:
> 
> 
> On Fri, 23 Jun 2006, Adam Belay wrote:
> > 
> > In my opinion, the point here is that the suspend functions are trying to
> > prevent access to hardware.
> 
> Yes. 
> 
> My point is that it's not needed for STR, has nothing to do with "driver" 
> (every driver needs to do it, and it doesn't actually touch hardware), and 
> it's wrong.
> 
> And IT'S ONLY DONE BECAUSE THE INTERFACE SUCKS!

Yeah, I think it could certainly be improved.  However, I think it's very
important that we be careful to prevent a driver from attempting to access
powered off hardware, even in the STR case.  Now that doesn't warrant a
fullblown teardown of the driver stack.  In most cases this sort of thing
can be handled by notifying the right higher-level subystems.  So the actual
driver suspend() mechanisms can remain very simple. (see below)

> 
> It's really only needed with the current setup, because the whole 
> suspend() phase is so messy, and we try to solve everything in one single 
> pass, and one single function call.

As an immediate incremental improvement, we could add a prepare_suspend()
callback that would be called before userspace is stopped and a
finish_resume() callback that would be called after userspace has been
started again.

> 
> What I'd like to get to (and no, I realize that just ->save_state() will 
> _not_ get me there - it's just a first step) is a point where 99% of all 
> devices can literally do just something like
> 
> 	pci_save_state(dev);
> 	pci_set_wake_event(..);
> 	pci_set_power_state(dev, PCI_D3hot);

Yes, most drivers, especially of the PCI variety, can do something pretty
simple when suspending, but only if we have the right infrastructure in place.

> 
> in their suspend routine. 
> i
> Now, in order to get there, we'll need a few more pieces. In particular, 
> it would require that this final suspend be called when interrupts have 
> been turned off.

One thing that might help us get there is if we passed a suspend notification
to the class devices (i.e. the higher level subsystems).  In this example,
I'm referring to the objects represented in /sys/class/net.  If that were the
case, most network drivers would only have to do something similar to what you
suggested above, plus possibly some hardware specific power-off registers.
Right now a lot of drivers have to do some "calling upward" to higher layers.
IMO this adds a lot of unneeded complexity and is less than ideal.

> (And I think Ben is right, we might want to have a "final_resume()" which 
> is called when user mode has resumed).

I agree.

> Five simple routines are _superior_ to one complicated routine. That is 
> true even if the five simple routines end up having more lines of code.
> 
> 			Linus

I'm curious about your thoughts on runtime suspending of devices are, such as
the resource rebalancing or cpufreq cases I suggested earlier.  Do you have
any opinions on how this might be handled?  So far, I've been favoring usage
of the same sort of freeze() mechanism used for preparing for memory snapshots
etc.

Thanks,
Adam