Am Dienstag, den 18.12.2018, 13:53 +0000 schrieb Anson Huang: [...] > > > > > Regarding about the over head, yes, the change in common composite > > > clock register has too many over head for other clocks, what if I > > > ONLY have dram core clock to pass the CLK_GET_RATE_NOCACHE flag to > > > register the composite clock? > > > > IMHO marking clocks under TF-A control explicitly as nocache would be > > much more acceptable than doing it for every composite clock. This > > seems okay for a short term solution. > > > > Still I think that whatever is causing the bus frequency scale to > > change should have a way to explicitly invalidate the clock cache for > > the affected clocks eventually. > > It is because the DDR PLL/clocks can only be changed with strict DDR > freq change flow, and it is done in TF-A, Linux kernel can NOT touch > it in runtime, so we have to mark the child clock of DDR PLL to be > uncached, in V2 patch, I will just add the flag for the DDR PLL child > clocks to be a shorten solution, should be only very few ones, hope > it is acceptable, thanks.
I fully understand why you are doing the frequency change in TF-A and I agree with the reasoning to do so. I also think that using uncached for the few clocks under TF-A control is fine for now. But if/when the bus frequency scaling is actually implemented for upstream I think the flow should look something like that: 1. Bus freq scaling driver determines that a change is necessary 2. Scaling driver calls into TF-A to do the change 3. TF-A reconfigures clock rates 4. Scaling driver calls into clock driver to signal that a clock change might have happened 5. Clock driver invalidates and recalculates cached values for the affected clocks Regards, Lucas
