On Friday 11 March 2005 5:08 pm, Adam Belay wrote: > > Under the topic of dynamic power management, there are a few logical > divisions of interest: > > 1.) Low-level - providing the bus support and facilities for higher > level power management (ex. the current work I'm doing with the PCI bus > driver). Also support for power domains might fall under this category. > > 2.) Driver state and driver relationships - logical vs. physical, driver > API, threading power management to transition multiple devices at once, > etc Clock management. ARM (and other) SOC based boards commonly have schemes to gate clocks off when the peripheral in question is unused, thereby saving power. <asm-arm/hardware/clock.h> has an API used to explicitly represent the clock tree. So a common mode of operation with such systems will be to keep the peripheral unclocked (saving power) until it's needed. I don't actually see any reason to routinely plan policy options there, that'd just be pointless extra work. clk_use() when the device is active, clk_unuse() otherwise. And in some cases "suspended" will mean "unused" for at least some clocks. That's sort of a "low level" category ... except that it pops up to higher level concerns. For example, clocks may be shared (which can make the "low level" vs "driver state and relationships" distinctions look nonexistent), and they may interact with system power transitions. Plus there are interactions with external devices. For example, some SOCs can enter various deep sleep states when USB is either suspended (by the host) or disconnected ... but not all. (And some could do it given external transceiver support...) So there may be a choice between entering a deeper sleep, or discarding active device state... > 3.) Power Management Policy - determining which behavior to take for > various classes of devices, how to determine idleness etc., and how to > control/monitor those devices. The primary mechanism I've heard discussed is having devices monitor when they haven't been used recently, and using that to enter some suspend level. The "not even active" clock gating approach isn't quite the same. > 4.) Userspace - how to notify of power changes, how to allow the user to > control power management. > > Anything else? Oh, and wakeup event sources. ACPI has a very indirect approach, which seems to underlay some assumptions on this list. There's a similar thing going on with PCI. So for example when folk start to assume that a "wakeup" event is for some reason distinct from the device's normal IRQ, I must cringe ... anyone assuming that device or system suspend involves turning off IRQs is erecting roadblocks against most embedded hardware. - Dave
