* Tero Kristo <t-kristo@xxxxxx> [170330 00:36]: > 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. Yeah OK. Using status = "disabled" won't help much there either as the amount of patching is still pretty much the same. > > > 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. Yes seems like that's what we should do then. Regards, Tony -- 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
