> Date: Thu, 4 Aug 2005 01:06:49 -0700 > From: Tony Lindgren <tony@xxxxxxxxxxx> > > * david-b@xxxxxxxxxxx <david-b@xxxxxxxxxxx> [050801 19:44]: > > > 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/
