Re: [linux-pm] driver power operations (was Re: suspend2 merge)

["Rafael J. Wysocki" <rjw@sisk.pl>]

On Friday, 27 April 2007 17:56, David Brownell wrote:
> On Friday 27 April 2007, Johannes Berg wrote:
> > 
> >  * FREEZE       Quiesce operations so that a consistent image can be saved;
> >  *              but do NOT otherwise enter a low power device state, and do
> >  *              NOT emit system wakeup events.
> >  *
> >  * PRETHAW      Quiesce as if for FREEZE; additionally, prepare for restoring
> >  *              the system from a snapshot taken after an earlier FREEZE.
> >  *              Some drivers will need to reset their hardware state instead
> >  *              of preserving it, to ensure that it's never mistaken for the
> >  *              state which that earlier snapshot had set up.
> > 
> > Why is prethaw even necessary?
> 
> Read the patch comments for the patch adding that transition.  Briefly,
> adding that transition to swsusp resume was a significant bugfix for
> all drivers that rely on controller state to determine how to resume.
> 
> (That's mostly drivers that are intelligent about wakeup events... so
> unless you're working with such drivers, the issue may be unclear.)
> 
> 
> > As far as I can tell it's only necessary 
> > because resume() can't tell you whether you just want to thaw or need to
> > reset since it doesn't tell you at what point it's invoked.
> 
> More like:  because swsusp overloaded the suspend()/resume() code paths
> to do double duty.
> 
> Instead of just putting devices into low power states (just *which* state
> is another discussion), they evolved into support for swsusp transitions...
> causing trouble (and sometimes breakage) for non-swsusp models.
> 
> 
> > Having ->freeze(), ->thaw() and ->restart() (can somebody come up with a
> > better name?) that are called at the appropriate places (with
> > freeze/thaw around preparing the image and freeze/restart around
> > restoring would go a long way of clearing up the confusion in all the
> > drivers. Of course, it'd have to be documented that freeze/thaw isn't
> > the only valid combination but that freeze/restart is used too, but
> > that's not hard to do nor hard to understand.
> 
> I suspect that after snapshot resume restart() should always be used.
> That shouldn't be hard to understand at all.  It'd be sub-optimal in
> the same cases today's system resume is sub-optimal:  devices that
> were in low power states before system suspend wouldn't be that way
> after system resume.
> 
> 
> > And, incidentally, it could possibly make both suspend and hibernate
> > work much faster too. The comments there talk about "minimally power
> > management aware" drivers which always do the wrong thing for suspend,
> > in that they always reset everything...
> 
> That comment was purely about existing practice ... and was mostly
> about resume() processing, not suspend() paths.
> 
> It's an unfortunate reality that most device drivers are stupid in
> terms of power management, so we need to be clear about just how
> stupid they're allowed to be without being terminally broken.
> 
> Additionally, it would be a Good Thing if changes to clean up the
> swsusp-related code paths didn't make "real suspend" more painful.
> 
> 
> > Of course, some drivers will 
> > actually need to do that, but if freeze/suspend and thaw/restart/resume
> > have the same prototypes (probably just int <function>(void)) then
> > drivers can trivially assign the same there.
> > And hibernate would benefit since a lot of drivers could do a lot less
> > work for freeze/thaw.
> 
> That actually gets into discussions from a while back about wanting
> to be able to quiesce() devices, as separate from actually putting
> them into low power states.

Yes, exactly.

Moreover, I think we should separate the current suspend code from the
hibernation (aka STD) code paths we're discussing.  I mean, we need
hibernation-specific equivalents of drivers/base/power/suspend.c etc.

Greetings,
Rafael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/