Re: [PATCH] Remove process freezer from suspend to RAM pathway
- From: Benjamin Herrenschmidt <benh@xxxxxxxxxxxxxxxxxxx>
- Date: Fri, 06 Jul 2007 13:59:07 +1000
How about a freezer whose job it is to "wait for pending hard
interrupts to complete when we have already guaranteed that we won't
get any more"? That part should be really *REALLY* easy. You don't
need to care about either userspace processes or kernel threads at
all. Specifically, Step 1 consists of:
Well, waiting for pending DMA and making sure to not trigger more
activity is what driver suspend() is supposed to do. With the ability
for simple drivers that can cope with it to just basically use a
late_suspend(), called after IRQs are off, that basically does what you
describe: wait for pending HW tasks to complete (polling) and turn the
damn thing off.
Note that the later is really a shortcut for somewhat dump and directly
accessible devices (PCI comes to mind). Things like USB has to use the
"normal" mechanism of blocking IOs etc... at suspend(), at least, USB
devices have to since the USB HC will not issue any new URBs. (And will
return them with a nice error code which is a perfect way to deal with
it in driver, been there, it works fine, once we fixed the races in the
USB host code itself, which I think we pretty much did by now).
Scheduling and userspace are all still fully enabled in this
scenario. Once all your devices are turned off, the only remaining
running threads will be those which haven't done IO since the
beginning of the suspend. We can then disable preemption, turn off
the timer interrupts, and tell the other CPUs to park all their
remaining threads in schedule() and sleep. Then we put the IRQ
controller to sleep and go to sleep ourselves. If our driver model
locking is sufficient to handle putting a parent device to sleep
while threads are sleeping on a child device then there are exactly 0
problems.
What you propose is basically a slightly over-simplistic version of what
I think (and Paulus think) should be done. We do need to do it via
driver callbacks down the tree since only drivers can know how to deal
with their DMA etc... and ordering need to be respected, but that's
basically it.
And guess what ? It's what we do on powerbooks, and it works fine,
without a freezer :-)
Ben.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
- Follow-Ups:
- Re: [PATCH] Remove process freezer from suspend to RAM pathway
- From: Alan Stern
- Re: [PATCH] Remove process freezer from suspend to RAM pathway
- From: Rafael J. Wysocki
- Re: [PATCH] Remove process freezer from suspend to RAM pathway
- References:
- [PATCH] Remove process freezer from suspend to RAM pathway
- From: Matthew Garrett
- Re: [PATCH] Remove process freezer from suspend to RAM pathway
- From: Nigel Cunningham
- Re: [PATCH] Remove process freezer from suspend to RAM pathway
- From: Benjamin Herrenschmidt
- Re: [PATCH] Remove process freezer from suspend to RAM pathway
- From: Nigel Cunningham
- Re: [PATCH] Remove process freezer from suspend to RAM pathway
- From: Kyle Moffett
- [PATCH] Remove process freezer from suspend to RAM pathway
- Prev by Date: Re: [linux-pm] Re: [PATCH] Remove process freezer from suspend to RAM pathway
- Next by Date: Re: [PATCH] Remove process freezer from suspend to RAM pathway
- Previous by thread: Re: [PATCH] Remove process freezer from suspend to RAM pathway
- Next by thread: Re: [PATCH] Remove process freezer from suspend to RAM pathway
- Index(es):
Relevant Pages
|
