Messages in this thread | | | Date | Wed, 22 Mar 2000 17:41:37 +0100 | From | Benjamin Herrenschmidt <> | Subject | power management (WAS Re: [linux-usb] OHCI crash) |
| |
On Wed, Mar 22, 2000, Dunlap, Randy <randy.dunlap@intel.com> wrote:
>Alan's OHCI disable_irq/enable_irq patch was rejected >by Linus. My understanding is that power management code >will be modified to do a "disable all interrupts at the >interrupt controller" on suspend and then "enable all >interrupts on the int. controller (that were previously enabled)" >on resume.
Well, that may not be enough. We have done that on PowerMac, but it may cause other problems. What if your driver needs some interrupts before beeing able to completely shut itself down ? The "suspend" message of the driver will be called with or without interrupts ? If it's called with interrupts still enabled, what's up if an interrupts falls after it's called and before the sleep code mask them all ?
Currently, on pmac, we have the chance of having one device = one irq line, so we don't have to handle shared interrupts and we can enfore "each driver masks it's own interrupt on suspend".
A better mecanism is a 2 stage messaging protocol: A first "early" suspend request is sent to every driver so that they can do whatever is needed to cleanup pending requests and stop accepting new ones. When all drivers have answered, the second stage routine can be called with all interrupts disabled. Then, the opposite is done on wakeup.
In fact, the best is a 3 stage request actually. Some drivers need to vmalloc huge amounts of memory before suspend (the frame buffer devices may have to backup the VRAM content). That means possible swapping out of dirty pages and so disk activity. So either those drivers are all suspended _before_ the swapping device, or you have a 3 stage meacanism:
1 - Sleep request, where all necessary memory allocation takes place, usually a good place to refuse sleep (if possible) when you know something is wrong
2 - Sleep command, where interrupts are still on. The driver is responsible for doing all necessary cleanup to cancel pending requests (and block the request queue if that makes sense for this specific driver).
3 - Sleep now, where interrupts are disabled.
Some drivers don't need to implement all 3 stages, most of them need only stage 3.
The wakeup process can be a 2 step process. (without interrupts first to put the chip in a clean state, then with interrupts to resume request processing).
On the PowerBook sleep mecanism, we have a special message "sleep reject" that is sent after stage 1 if the sleep request was canceled. (if it's canceled from state 2 or 3, then the real wakeup commands are sent to resume the driver).
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |