Messages in this thread | | | From | "Henroid, Andrew D" <> | Subject | RE: [linux-usb] power management (WAS Re: [linux-usb] OHCI crash) | Date | Thu, 23 Mar 2000 18:18:27 -0800 |
| |
> -----Original Message----- > From: Benjamin Herrenschmidt [mailto:bh40@calva.net] > Sent: Thursday, March 23, 2000 2:01 AM > To: Henroid, Andrew D > Cc: linux-usb@suse.com; linux-kernel@vger.rutgers.edu > Subject: Re: [linux-usb] power management (WAS Re: [linux-usb] OHCI > crash)
> The framebuffer may need a vmalloc. For now, that's the only > case we have on powerbooks.
Do you need to have the system save the framebuffer or can X do that? It would be unfortunate (time consuming) to have to dig into swap to save device context. That's something we would like to avoid for ACPI, especially for shallower sleep states that are intended to have little resume latency.
> However, our > PowerBook sleep code may not be very robust if there is lot > of activity > on the IDE or SCSI while going to sleep. (What would happen > if the sleep > occur in the middle of an ATAPI command, after the command is > sent and before the reply is reveived).
Yes, with the multi-stage approach it is going to be painful to get suspend right with any amount of system activity. The only safe thing to do is to block software request queues, drain hardware queues, and then do the sleep. This becomes considerably more complicated when we want to do suspend to disk.
> Ideally, this should be > handled by a dependency tree (for example, the IDE depends on the > hot-swap media-bay and so the bay must be put to sleep after the > IDE).
Right, I was hoping to be able to build a dependency tree from the information provided to pm_register. There would have to be some intimate knowledge of PCI class information but it seems doable.
> Well, you close your portable lid, and then, because an IDE > request is > still pending somewhere, your machine will wake back up with the > lid > closed. This can be bad, especially with some machines that have > heat > problems when running with the lid closed.
Actually, the laptop wouldn't wake back up. It would just stay awake until the IDE request clears (presumably quickly) and the system would then go to sleep. I'm counting on most drivers being a bit heavy handed and only handling vital requests after the suspend request is issued. Storage is really the only area that comes to mind where we need to be very careful about dropping requests.
> > 1. Send all drivers a suspend request > > 2. Save contents of memory to disk (yes, special handling > > for storage devices) > > Well, you need the disk drivers to be still alive at this > point. That can > be a problem if the underlying device was already suspended.
When we take into account suspend to disk, it's even more complicated. We really need to
1. Save the state of all devices to memory 2. Dump the contents of memory out to disk 3. Shutdown the storage driver(s) 4. Put the system to sleep
This is unfortunate as storage drivers will presumably need to change device state during step #3. I think the best we can do is save a snapshot of the system state at some time before sleeping.
> Also, some machines > don't need the save-to-disk (this feature is useful when you > actually > shut the machine down instead of putting it to sleep).
Right, suspend to RAM is a little easier that suspend to disk. For ACPI, we would like to get both working.
> IMHO, asynchronous handling of sleep would be way too complex > and cause more problems than it solves.
Hmmm.. I'm not sure that is true. My concern is with making it easy to add power management support to drivers. I'd rather see complication go into the power management subsystem where it only has to be done once rather than several hundred times (once in each driver).
Here is how I see it working. Drivers call pm_access before handling a new request. Once pm_access returns, a driver can be confident its device and bus are alive and ready to go. I don't think this is any more complicated than the request queue blocking you are going to have to do to get your approach working solidly.
Right? Or am I leaving out too many of the complicating details?
Thanks, Andy
- 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/
| |