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

Quoting Lucas Stach (2018-12-18 06:02:28)

Am Dienstag, den 18.12.2018, 13:53 +0000 schrieb Anson Huang:
[...]

quoted

quoted

quoted

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

Does any clk consuming driver of the downstream clks that are branched
off of the bus clk managed by firmware care about the frequency? Or do
they just want the clk to be on. If they don't care then it's possible
to break the parent dependency and just not care to tell them what the
bus frequency is anymore.

I don't know how you would implement #4 above, besides by having the bus
freq scaling driver use clk_set_rate() to tell the bus clk that it wants
a new rate and then having that clk implementation do #2. That way the
rate propagation works without having to notify clk code somehow.


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel