Re: [RFC] powermac: proper sleep management

2 messages, 2 authors, 2007-11-12 · open the first message on its own page

Re: [RFC] powermac: proper sleep management

From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: 2007-11-12 20:24:01

On Mon, 2007-11-12 at 17:32 +0100, Johannes Berg wrote:
quoted
Looks good to me, +/- a couple of things:

 - We _REALLY_ want the freezer to be optional and not enabled by
default on PowerPC. Maybe make it a compile option ?
Well, Alan is going to tell you that USB will break. If we need
confirmation for that I can do the test he suggested to you or Paul a
while ago.
Then USB is broken today on powermacs and need to be fixed. We had a
clear agreement at KS this year that the freezer was at best a band-aid
and that drivers -had- to be fixed to cope regardless.
Obviously. I don't have any of that. I'd appreciate if somebody could
test on a 3400 powerbook to see if that pci config space save/restore
stuff is really necessary or even interferes with the regular stuff.
Might not be that necessary anymore nowadays, the generic code ought to
do it, but I'll give a go, I have one of those (paulus old one) though
last I tried, the HD was dead.

Ben.

Re: Re: [RFC] powermac: proper sleep management

From: Alan Stern <stern@rowland.harvard.edu>
Date: 2007-11-12 20:40:58

On Tue, 13 Nov 2007, Benjamin Herrenschmidt wrote:
On Mon, 2007-11-12 at 17:32 +0100, Johannes Berg wrote:
quoted
quoted
Looks good to me, +/- a couple of things:

 - We _REALLY_ want the freezer to be optional and not enabled by
default on PowerPC. Maybe make it a compile option ?
Well, Alan is going to tell you that USB will break. If we need
confirmation for that I can do the test he suggested to you or Paul a
while ago.
Then USB is broken today on powermacs and need to be fixed. We had a
clear agreement at KS this year that the freezer was at best a band-aid
and that drivers -had- to be fixed to cope regardless.
More accurately, freezing user tasks is at best a band-aid.  However 
some kernel threads do need to be frozen, and keeping the freezer 
around for their use makes sense.  It has less overhead -- I think 
-- than adding new code to do the freezing in each of these threads.

(It's true that USB drivers in general aren't written to operate in a
freezerless system-suspend environment.  That's a harder problem and
it will have to be fixed driver-by-driver, over time.  The same may be
true for lots of non-USB char device drivers as well.  Pick your 
favorite char device driver: How will it behave if a user task submits 
an I/O request after the device has been suspended?)

Alan Stern
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help