Date: Thu, 4 Aug 2005 01:06:49 -0700
From: Tony Lindgren <tony@atomide.com>

* david-b@pacbell.net [off-list ref] [050801 19:44]:

quoted

quoted

to power down, couldn't the PM framework take care of
recursively sending 'power down' message to all children, wait for
confirmation, and then power itself down?

Could, arguably should -- but doesn't, just now.  I don't
think I'd try to manage all system devices' power through
sysfs from usermode yet ... :)

There are some cases where the whole bus can be powered down, but
a device on the bus needs to be left on to provide wake-up events.

And many similar examples of cases where the "bus" isn't the
traditional "motherboard expansion" model with power, data,
address, and control lines in parallel.  They may not even
be grouped together on an expansion connector.

The wake-up event might take another path, such as GPIO, and the
bus can be powered down with some devices on.

An example that comes to mind is the smc91x Ethernet driver on
OMAP OSK board.

The smc91x is a "platform_bus" device, which has interesting
power management characteristics.  Like it usually can't all
be turned off, and certainly not all at once ... :)


Some folk might find the hardware spec [1] for this board
to be interesting: mostly text explaining the schematics,
subsystem by subsystem, and much easier to digest than raw
schematics.  The power management subsection also includes
a power budget.  I think it's fair to call that board design
"power-aware", though not very power-optimized if it does
have a battery-powered mode.

That's a fair example of hardware that Linux runtime PM
should be able to handle without breaking a sweat; there's
nothing very unusual about it.  

- Dave

[1] http://omap.spectrumdigital.com/osk5912/