David Brownell wrote: >>Thing is, it's the system power states that are placing clock >>constraints on devices. On OMAP, going into "deep sleep" means >>you've got to stop using the 48 MHz clock. For "big sleep", >>you can keep using that clock. Most other CPUs have similar >>constraints: multiple system states, defined primarily by >>clock usage. > > > > So to focus on one point: "pm_message_t" doesn't work well > at all, since it doesn't have a way to identify the target > system power state, and drivers thus have no way to see if > they should drop their requests for those clocks or whether > the hardware should keep working away. If I've followed the discussion correctly, it sounds like a lot of the system intelligence is targeted at the bus driver level, and the current generic platform bus driver for embedded onchip devices will probably become something very tied to the particular platform. If so, then at least the bus driver would need to be told of the system state, which can code the logic for figuring out which devices must be stopped prior to entering a state, and device drivers can simply follow orders to suspend. But I suppose there's some cases in which a device driver may have options more complicated than run/suspend in the face of changes in clock gating, so having the info available to all drivers could be useful even in that situation. -- Todd
