On Thu, May 24, 2018 at 03:49:22PM +0300, Dmitry Osipenko wrote: > On 24.05.2018 13:04, Peter De Schrijver wrote: > > On Wed, May 23, 2018 at 07:00:20PM +0300, Dmitry Osipenko wrote: > >> PLL_C is running at 600MHz which is significantly higher than the 216MHz > >> of the PLL_P and it is known that PLL_C is always-ON because AHB BUS is > >> running on that PLL. Let's use PLL_C as intermediate clock source, making > >> CPU snappier a tad during of the frequency transition. > >> > > > > pll_c isn't necessarily 600Mhz when used as a source for the second display > > head. > > Hmm, indeed. > > Even if PLL_C rate will be adjusted, it will be higher than the PLL_P.. won't > it? That's likely to be good enough. > Yes. I think it can be always higher than pll_p, but that assumes the display driver will always program the highest possible rate for pll_c for a given mode and then program the display divider to divide it down to the required rate. > Do you know if any of the available CCLK parents has a glitch-less rate > switching? I.e. CPU won't hang on the rate switch. > Tegra20 doesn't have dynamic ramp PLLs no. So you always have to switch to a backup clock source before changing the rate of pll_x. > There is other possible 600MHz source, the PLL_M. Can we use it? This one also > may become dynamic if we'll consider implementing the memory scaling, but the > memory frequency probably will fit the transition role pretty well. I think this should work, but as you mention it may very well be lower than pll_p if Tegra20 EMC scaling is re-introduced. I think that's why historically this was never done. Peter. -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
