[PATCHv2 9/9] ARM: dts: omap4: convert to use the new clkctrl clocks for the drivers

[t-kristo@ti.com (Tero Kristo)]

On 28/03/17 18:03, Tony Lindgren wrote:
> * Tero Kristo <t-kristo@ti.com> [170327 22:46]:
>> On 28/03/17 03:18, Tony Lindgren wrote:
>>> * Tero Kristo <t-kristo@ti.com> [170317 02:12]:
>>>> Convert the drivers to use the new clkctrl clocks.
>>>>
>>>> Signed-off-by: Tero Kristo <t-kristo@ti.com>
>>>> ---
>>>>  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