> >>>> Could you perhaps provide list of operating points for 770? It > >>>> would help understanding a bit, I'd say. > >>> > >>> If there was a followup here, I missed it ... > >>> > >>> ISTR that it doesn't use (formal) operating points, and that ... > >> > >> http://dynamicpower.sourceforge.net/dpm-omap.html > > > > That's the old DPM stuff not any of the newer proposals right? > > Example operating points were requested. Using the operating points > from DPM is fine for examples. I read the query to be specifically about operating points used in that product ... as giving better insight into the real PM requirements for Linux-based products. Examples of how one solution _could_ be used address another purpose than highlighting requirements. > > ... that's in addition to the reduced power idle, which didn't > > seem to fit into the DPM framework in any obvious way. > > Actually, automatically reducing power at idle is what DPM is all > about. In DPM an operating point is mapped to the idle state so when > the idle task is entered an operating point change is triggered. The > system can choose the best point for the idle task based on latency > requirements, length of idle when using dynamic ticks, etc. Hmm, that's something that somehow never came out in previous discussions. At least, not to me. It's possible that the point did come out, but got buried in all the noise. So it would appear that an operating point (in DPM, anyway) is a combination of clock, voltage, and probably other settings, coupled with an implementation of the idle task and a policy implemented by idle task ... yes? Given that the clock API manages clock settings, and cpufreq (for better or worse) handles CPU-specific clock and voltage, you can still color me confused about how an "operating point" would be a programming construct rather than a side effect of those other APIs on an implementation. (If anyone wants to enlighten me, that should go into a new thread!) - Dave
