Re: [PATCH] clk: imx: add CLK_GET_RATE_NOCACHE flag for i.MX8M composite clock

[Lucas Stach <l.stach@pengutronix.de>]

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