On 28.06.2019 00:15, Stephen Boyd wrote:

Quoting Leonard Crestez (2019-05-30 00:13:51)

quoted

Add a wrapper clock encapsulating dram frequency switch support for
imx8m chips. This allows higher-level DVFS code to manipulate dram
frequency using standard clock framework APIs.

Linux-side implementation is similar in principle to imx_clk_cpu or a
composite clock. Only some preparation is done inside the kernel, the
actual freq switch is performed from TF-A code which runs from an SRAM
area. Cores other than the one performing the switch are also made to
spin inside TF-A by sending each an IRQ.

This is an early proof-of-concept which only support low/high mode on
imx8mm but NXP has secure-world dram freq switching implementations for
multiple other chips and this approach can be extended.

Many platforms handle this kind of stuff externally but cpufreq is quite
insistent that actual rates are set by clk code and that new platforms
use cpufreq-dt.

Let me know if there are objections to handling dram freq via clk.

Can it be an interconnect driver instead? I don't see how this is a clk
driver. It looks more like a driver that itself manages a collection of
clks, and you've put the coordination of those clks behind the clk_ops
interface. We don't want to have clk_ops calling clk consumer APIs in
general, so the whole approach doesn't seem correct.

The imx8m dram clk structure is only slightly more complicated than that 
for the cpu. It's not clear why mux manipulation should be pushed away 
from clk and onto consumers. Isn't it desirable for clk_set_rate to 
"just work"?

Implementation uses consumer APIs because the constructor takes struct 
clk*. It could be modifed to take struct clk_hw*, but probably only with 
larger changes to clk-imx8m.

The interrupt handling should be moved to secure world.

Hopefully this can
work out as some other sort of driver that is used directly from devfreq
or interconnect core instead and then have a different consumer driver
of devfreq or interconnect core that knows how to drive the clk tree.

Hiding dram rate setting behind a clk rate makes it much easier to 
implement devfreq or interconnect, as in this series:

https://patchwork.kernel.org/project/linux-arm-kernel/list/?series=139367

I sent than RFC after you replied to this email, mostly because it's 
been pending for a while.

--
Regards,
Leonard

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