On Sunday 17 October 2004 16:19, Benjamin Herrenschmidt wrote: > So what do we do here. Do we still have a single PM_FREEZE (or whatever > we call it) message and a single resume() and stuff the details somewhere > else or do we pass a richer message ? I think I'd go for the richer message ... pass a struct pointer indicating the upcoming system state, with platform hooks, and let drivers use that to ask questions about the upcoming state: "Is CLK48 active during this state?" "Is PCI Vaux available to this device?" ... Somewhat related: it's possible that some of the ARM clock gating APIs should become more mainstream. Those are set up so that for example when nobody needs CLK48 any longer, it can be automatically turned off. (Benjamin, this is a different model than you've described so far: drivers determining clock usage, not system sleep transitions. It gives much finer control over power consumption, since power can be reduced without going to sleep.) Those APIs need a bit of work though; for example, if the 48 MHz DPLL can be disabled, that might mean that the system is now eligible for "deep sleep" ... but there's no callback to report that. The information flow should go both ways. If user mode forces such a sleep state, that clock must be disabled -- as a side effect of all the drivers dropping their claims. But when the system is sufficiently idle, since the drivers went idle, it should probably just enter that sleep state by itself. And in the same way, if a cpufreq change slows down a clock, a driver may need to adapt ... or even veto some changes, since the cpu clock changes can affect device clocking. - Dave
