lkml.org 
[lkml]   [2000]   [Mar]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
Subjectpower 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/

\
 
 \ /
  Last update: 2005-03-22 13:57    [W:0.051 / U:1.792 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site