lkml.org 
[lkml]   [2000]   [Mar]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: [linux-usb] power management (WAS Re: [linux-usb] OHCI crash)
Date
> -----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/

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