On 28/03/17 18:03, Tony Lindgren wrote:
* Tero Kristo <t-kristo@xxxxxx> [170327 22:46]:
On 28/03/17 03:18, Tony Lindgren wrote:
* Tero Kristo <t-kristo@xxxxxx> [170317 02:12]:
Convert the drivers to use the new clkctrl clocks.
Signed-off-by: Tero Kristo <t-kristo@xxxxxx>
---
arch/arm/boot/dts/omap4.dtsi | 164 ++++++++++++++++++++++++++++++++++++++-----
1 file changed, 146 insertions(+), 18 deletions(-)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 3ecf616..c39304a 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -94,16 +94,22 @@
compatible = "ti,omap4-mpu";
ti,hwmods = "mpu";
sram = <&ocmcram>;
+ clocks = <&mpuss_clkctrl OMAP4_MPU_CLKCTRL 0>;
+ clock-names = "clkctrl";
};
Oh one more thing. I don't think we should add the clocks
here as they are now wrongly allocated to the device within
the interconnect target module. These clocks really belong
to each interconnect target module that we don't have in the
dts yet.
So we're better off adding the clockctrl clocks and then
changing the dts to use the interconnect target modules
with the clockctrl clocks.
The problem is, you can't just add the clkctrl clock nodes themselves alone,
as this introduces the problem that any clocks with no users will get
disabled => causes a boot time hang when all the device clocks get shut
down.
Hmm yeah. I wonder how to work around that.. What if we first updated
the clocks in the hwmod code? Or updated the aliases?
Kind of a chicken-egg problem. You could maybe probe the "ti,clkctrl"
driver manually to avoid the issue.
The core clocks get disabled when CCF notices they are not used. You
can't really avoid that with updating aliases / updating the clocks in
hwmod code. And, hwmod basically tries to still use the same registers
through the legacy route, which leads to conflict.
If you want to delay the usage of the clocks until you have interconnect
target modules in place, you need to introduce the clock nodes also at that
point, similar to what needs to be done now to squash patch #8 or #9.
I'd like to do this one device at a time without any large
flips as we have quite a few devices with special handling for
reset and idling in the hwmod code.
One thing that can be done also is to introduce the clkctrl clocks one
at a time in the data file also, but this is going to be cumbersome, as
you need to keep these three in sync:
- drivers/clk/ti/clk-44xx.c
- arch/arm/mach-omap2/omap_hwmod_44xx_data.c
- arch/arm/boot/dts/omap4.dtsi
... and that per SoC of course.
With the interconnect driver introduction, you should be able to flip
one device at a time from hwmod to interconnect. In this case, all the
clocks are already there, and you just need to modify DT + hwmod data to
do the flip.
-Tero
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
