On Wed, Apr 27, 2011 at 11:34 AM, Mark Brown <broonie@xxxxxxxxxxxxx> wrote: > On Wed, Apr 27, 2011 at 10:49:47AM -0700, Colin Cross wrote: > >> Moreover, from a silicon perspective, there is always a simple link >> from a single frequency to a minimum voltage for a given circuit. >> There is no need to group them into OPPs, which seem to have a group >> of clocks and their frequencies that map to a single voltage. That is >> an artifact of the way TI specifies voltages. > > This isn't just a TI thing, other CPU (and general big digital) vendors > spec things similarly. It's just that TI have more code in mainline > than most. My understanding is that when people do this the set of > operating points aren't purely about DVFS, they're also about specifying > the relationships between the various system clock rates and potentially > other things which are supported, especially in the blocks that mediate > between multiple domains. The voltages are just one of the parameters > here, and with multiple supplies the voltages aren't always orthogonal > to each other. Then TI (and other vendors) are providing one table that specifies two things - the relationship between frequency and voltage for each clock, and the relationship between multiple clocks for optimal performance. Mixing those in the kernel breaks platforms (like Tegra) that do not have any relationship between multiple clocks. Can you point me to a platform that implements keeping multiple clocks changing between OPPs together? As far as I can tell, OMAP4 always does dev -> clk, clk -> freq, dev + freq -> voltage, and never looks at multiple clocks. >> I proposed in a different thread on LKML that DVFS be handled within >> the generic clock implementation. Platforms would register a >> regulator and a table of voltages for each struct clock that required >> DVFS, and the voltages would be changed on normal clk_* requests. >> This maintains compatibility with existing clk_* calls. > > This comes back to the thing we were discussing in the thread there > about there being n:m constraints between settings. I've not looked at > this in any detail but it may be that for the systems which spec things > as operating points we want to root the core clocking in an operating > point block which deals with stuff like this. > On some platforms there may be a need for some global clock governor, which can keep multiple clocks in sync, but I haven't seen one for which that is truly required. _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
