Re: [PATCH] arm64: dts: renesas: r8a7796: Add CMT device nodes

[Daniel Lezcano <daniel.lezcano@linaro.org>]

On 19/11/2018 16:50, Biju Das wrote:
> Hi Daniel,
> 
> Thanks for the feedback.
> 
>>>> Subject: Re: [PATCH] arm64: dts: renesas: r8a7796: Add CMT device
>>>> nodes
>>>>
>>>> On 26/10/2018 10:25, Biju Das wrote:
>>>>> This patch adds CMT{0|1|2|3} device nodes for r8a7796 SoC.
>>>>>
>>>>> Signed-off-by: Biju Das <biju.das@bp.renesas.com>
>>>>> ---
>>>>> This patch is tested against renesas-dev
>>>>>
>>>>> I have executed on inconsistency-check, nanosleep and
>>>>> clocksource_switch selftests on this arm64 SoC. The
>>>>> inconsistency-check and nanosleep tests are working fine.The
>>>>> clocksource_switch asynchronous test is failing due to
>>>>> inconsistency-check
>>>> failure on "arch_sys_counter".
>>>>>
>>>>> But if i skip the clocksource_switching of "arch_sys_counter", the
>>>>> asynchronous test is passing for CMT0/1/2/3 timer.
>>>>>
>>>>> Has any one noticed this issue?
>>>>
>>>> So now that you mention that, I've been through the
>>>> clocksource_switch on another ARM64 platform (hikey960) and disabled
>>>> the
>>>> ARM64_ERRATUM_858921 config option. I can see the same issue.
>>>>
>>>> Is this option set on your config ?
>>>
>>> No.  As per  " config ARM64_ERRATUM_858921", it is "Workaround for
>> Cortex-A73 erratum 858921"
>>>
>>> Our SoC is 2xCA-57 + 4 x CA-53.  Does  it impact CA-57 + CA_53?
>>
>> Dunno :/
>>
>>> Any way I will enable this config option and will provide you the results.
>>
>> Ok, thanks!
> 
> The following config is enabled by default on upstream kernel(4.20-rc3)
> CONFIG_ARM_ARCH_TIMER_EVTSTREAM=y
> CONFIG_ARM_ARCH_TIMER_OOL_WORKAROUND=y
> CONFIG_FSL_ERRATUM_A008585=y
> CONFIG_HISILICON_ERRATUM_161010101=y
> CONFIG_ARM64_ERRATUM_858921=y
> 
> For a quick testing,  I have activated the erratum using the property "fsl,erratum-a008585" on device tree.
> With this I confirm the issue is fixed.
> 
> I have  some questions on this.
> 1) Based  on the test result ,do you think renesas soc also  impacted by the ARM64_ERRATUM_858921?
> 2) Is there any way to find, is this Erratum actually causing the asynchronous test to fail?

I guess, you can hack the __fsl_a008585_read_reg macro and check if the
invalid condition is reached.

This thread https://lkml.org/lkml/2018/5/10/773 will give you all the
answers you are looking for (well very likely).

Let me know if it helped.


> timer {
>                 compatible = "arm,armv8-timer";
>                 interrupts-extended = <&gic GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_LOW)>,
>                                       <&gic GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_LOW)>,
>                                       <&gic GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_LOW)>,
>                                       <&gic GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_LOW)>;
> +                fsl,erratum-a008585;
> }




-- 
 <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog