On Tue, Aug 25, 2009 at 19:43:47, Kevin Hilman wrote: > Nori, Sekhar <nsek...@ti.com> writes: > > > Adds basic CPUFreq support for DA850/OMAP-L138. > > > > Currently, frequency scaling only on PLL0 is supported. No scaling of PLL1 > > or voltage levels as yet. > > > > Peripherals like MMC/SD which have a clock input synchronous with > > ARM clock will not work well since the clock will change behind their backs. > > Support for notification to such devices to adjust themselves to the > > new frequency will be added in later patches. Current defconfigs keep > > CPUFreq disabled so it will not affect normal operation. > > > > The OPP defintions assume clock input of 24MHz to the SoC. This is inline > > with hardcoding of input frequency in the <soc>.c files. At some point > > this will need to move into board dependent code as new boards appear with > > a different input clock. > > > > Tested with ondemand governer and a shell script to vary processor load. > > > > Signed-off-by: Sekhar Nori <nsek...@ti.com> > > Hmm, I'm not crazy about the duplicate clock tree for the PLL0 clocks. > This will not scale well when scaling other clocks. > > I'd rather see a dedicated function in clock.c that does the recalc > for a particular PLL and all its children.
But, currently there is no easy way to traverse the clock tree top down. Since only the parent is being maintained in each clock, its easy to travel up the tree but not down. So, maintaining a separate per-PLL tree seems to be the only way around. However, I could do possibly do better by maintaining a list of pointers than copying the clock structure over. > struct pll_data has a > 'num' field which could be used instead of the string match you're > doing now to generated the PLL0 list. Right, I will use that instead. Thanks, Sekhar _______________________________________________ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
