[4.4-rc][PATCH] ARM: dts: am4372: fix clock source for arm twd and global timers

[Tero Kristo]

On 11/30/2015 03:49 PM, Grygorii Strashko wrote:
> On 11/30/2015 03:32 PM, Tero Kristo wrote:
>> On 11/30/2015 01:53 PM, Grygorii Strashko wrote:
>>> On 11/30/2015 10:25 AM, Tero Kristo wrote:
>>>> On 11/27/2015 09:44 PM, Grygorii Strashko wrote:
>>>>> ARM TWD and Global timer are clocked by PERIPHCLK which is MPU_CLK/2.
>>>>> But now they are clocked by dpll_mpu_m2_ck == MPU_CLK and, as result.
>>>>> Timekeeping core misbehaves. For example, execution of command
>>>>> "sleep 5" will take 10 sec instead of 5.
>>>>>
>>>>> Hence, fix it by adding mpu_periphclk ("fixed-factor-clock") and use
>>>>> it for clocking ARM TWD and Global timer (same way as on OMAP4).
>>>>>
>>>>> Cc: Tony Lindgren <tony at atomide.com>
>>>>> Cc: Felipe Balbi <balbi at ti.com>
>>>>> Cc: Tero Kristo <t-kristo at ti.com>
>>>>> Fixes:commit 8cbd4c2f6a99 ("arm: boot: dts: am4372: add ARM timers and
>>>>> SCU nodes")
>>>>> Signed-off-by: Grygorii Strashko <grygorii.strashko at ti.com>
>>>>> ---
>>>>>    arch/arm/boot/dts/am4372.dtsi        | 4 ++--
>>>>>    arch/arm/boot/dts/am43xx-clocks.dtsi | 8 ++++++++
>>>>>    2 files changed, 10 insertions(+), 2 deletions(-)
>>>>>
>>>>> diff --git a/arch/arm/boot/dts/am4372.dtsi
>>>>> b/arch/arm/boot/dts/am4372.dtsi
>>>>> index d83ff9c..de8791a 100644
>>>>> --- a/arch/arm/boot/dts/am4372.dtsi
>>>>> +++ b/arch/arm/boot/dts/am4372.dtsi
>>>>> @@ -74,7 +74,7 @@
>>>>>            reg = <0x48240200 0x100>;
>>>>>            interrupts = <GIC_PPI 11 IRQ_TYPE_LEVEL_HIGH>;
>>>>>            interrupt-parent = <&gic>;
>>>>> -        clocks = <&dpll_mpu_m2_ck>;
>>>>> +        clocks = <&mpu_periphclk>;
>>>>>        };
>>>>>
>>>>>        local_timer: timer at 48240600 {
>>>>> @@ -82,7 +82,7 @@
>>>>>            reg = <0x48240600 0x100>;
>>>>>            interrupts = <GIC_PPI 13 IRQ_TYPE_LEVEL_HIGH>;
>>>>>            interrupt-parent = <&gic>;
>>>>> -        clocks = <&dpll_mpu_m2_ck>;
>>>>> +        clocks = <&mpu_periphclk>;
>>>>>        };
>>>>>
>>>>>        l2-cache-controller at 48242000 {
>>>>> diff --git a/arch/arm/boot/dts/am43xx-clocks.dtsi
>>>>> b/arch/arm/boot/dts/am43xx-clocks.dtsi
>>>>> index cc88728..2ff58b1 100644
>>>>> --- a/arch/arm/boot/dts/am43xx-clocks.dtsi
>>>>> +++ b/arch/arm/boot/dts/am43xx-clocks.dtsi
>>>>> @@ -259,6 +259,14 @@
>>>>>            ti,invert-autoidle-bit;
>>>>>        };
>>>>>
>>>>> +    mpu_periphclk: mpu_periphclk {
>>>>> +        #clock-cells = <0>;
>>>>> +        compatible = "fixed-factor-clock";
>>>>> +        clocks = <&dpll_mpu_ck>;
>>>>
>>>> I don't think this is correct, ARM core is fed dpll_mpu_m2_ck, where the
>>>> divisor value can potentially differ from 1. If you feed this clock
>>>> directly from dpll_mpu_ck, you bypass this divisor.
>>>
>>> Sry. My mistake. I'll update it to use dpll_mpu_m2_ck.
>>>
>>>>
>>>> Did you check what is the impact of cpufreq on the ARM TWD/timers?
>>>
>>> TWD is cpufreq friendly, ARM GT is not.
>>
>> I think the TWD kick period changes with cpufreq also right?
>
> linux/arch/arm/kernel/smp_twd.c has code to handle cpufreq.
>
>>
>> How are the clocks handled with cpufreq? The user just needs to
>> understand that the timers will be screwed if he uses ARM GT? Should we
>> add some sort of dependency to disable the ARM GT if cpufreq is enabled?
>
> Yep. May be, but very good question is how to do that in case of
> OMAP multiplatform build which enables most of all config options at once.
>
> There two threads related to this:
> [1] http://www.spinics.net/lists/arm-kernel/msg459649.html
> [2] http://www.spinics.net/lists/arm-kernel/msg461141.html
>
> Personally, I've do not see better way than [2] right now.

Yeah, [2] seems the way to go.

>
>
>>>>> +        clock-mult = <1>;
>>>>> +        clock-div = <2>;
>>>>> +    };
>>>>> +
>>>>>        dpll_ddr_ck: dpll_ddr_ck {
>>>>>            #clock-cells = <0>;
>>>>>            compatible = "ti,am3-dpll-clock";
>>>>>
>
> By the way, does this patch is still correct taking into account dependency
> from cpufreq?
> Does it make sense update it to use dpll_mpu_ck and resend?
>

Well, this patch is still valid, as the selection of the clocksource 
should be done elsewhere, and this patch should not care about that.

-Tero