On Fri, 2010-06-11 at 16:48 -0400, Alan Stern wrote: > On Fri, 11 Jun 2010, Mark Brown wrote: > > > On Fri, Jun 11, 2010 at 10:46:27AM -0400, Alan Stern wrote: > > > On Fri, 11 Jun 2010, James Bottomley wrote: > > > > > > The one thing that does look difficult is that these power constraints > > > > are device (and sometimes SoC) specific. Expressing them in a generic > > > > way for the cpu govenors to make sense of might be hard. > > > > > Doesn't the clock framework already handle this sort of thing? > > > > The clock framework is implemented independantly for each CPU. > > That's not an impediment, since drivers' requirements regarding which > clocks remain running in which power states are necessarily > platform-dependent also. > > > On Fri, 11 Jun 2010, James Bottomley wrote: > > > Well, there are two elements to "this sort of thing": > > > > 1. Allow a driver to request that a given clock not be turned off. > > 2. Make the cpuidle governors aware of a pending "don't turn off X > > clock source" so they can keep the system in a state where the > > clock doesn't get powered down. > > > > As far as I can tell from the code, neither currently exists at the > > moment. > > Well then, can (or should) the clock framework interact with the > pm-qos subsystem so that drivers don't have to worry about it? So the implementation of this seems to be a bit complex: We could have clockevents_register() do a per clock pm_qos variable but then the cpuidle governors need to know which to listen for so they don't transition to a state too low for them to be active if pm_qos says keep them running. Even if that gets sorted out, how would USB know which platform specific clock source is driving the wakeup events on its bus? How complex can SoC clocksources be? If it's just a simple binary do/don't potentially stop all clocks, I think it's easy. If SoC's have a hierarchical shutdown sequence, and they really need this to save power, then expressing that generically becomes rather problematic. James -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
