On Monday 06 July 2009, Sekhar Nori wrote: > The patch implements cpufreq driver, support to change PLL > output rate and recalculation of the rates of PLL derived clocks
It seems to me this is missing some sanity checks. First, that the DRAM isn't being clocked through this PLL... since changing the PLL would imply recalculating all of its timings, and might require running the re-clock from SRAM. Second, similar issues crop up with every clock derived from that same PLL. If you change the clock going into the MMC controller, that can require recalculating the dividers used to clock the MMC/SD card it's talking to. Now, those are issues the clock framework handles poorly. So I don't think there are likely to be easy fixes for those PLL recalc problems ... unless I missed something. It might be simpler to just restrict a first pass of this to changing dividers for the ARM's clock. Also, this patch is doing two separate things. One is adding clk_set_rate() support for PLLs. The other is matching $SUBJECT. Better to split those two. (And notice how your patch [2/2] hit that second issue already, with the UART2 clock getting goofed ...) - Dave _______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
