mvebu: armada 3720 cpufreq reverts

[Josef Schlehofer]

On 27. 07. 21 11:24, Hauke Mehrtens wrote:
> On 7/27/21 9:50 AM, Josef Schlehofer wrote:
>>
>> On 24. 07. 21 20:03, Hauke Mehrtens wrote:
>>> On 7/24/21 7:50 PM, Josef Schlehofer wrote:
>>>>
>>>> On 24. 07. 21 19:37, Hauke Mehrtens wrote:
>>>>> On 7/1/21 11:08 AM, Robert Marko wrote:
>>>>>> On Thu, Jul 1, 2021 at 12:42 AM Marek Behun <marek.behun at nic.cz>
>>>>>> wrote:
>>>>>>>
>>>>>>> On Wed, 30 Jun 2021 17:51:24 +0200
>>>>>>> Robert Marko <robert.marko at sartura.hr> wrote:
>>>>>>>
>>>>>>>> On Wed, Jun 30, 2021 at 3:19 PM Marek Behún <marek.behun at nic.cz>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Hello Robert,
>>>>>>>>>
>>>>>>>>> I am writing regarding commit
>>>>>>>>>      mvebu: 5.10 fix DVFS caused random boot crashes
>>>>>>>>>   
>>>>>>>>> https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=080a0b74e39d159eecf69c468debec42f28bf4d8
>>>>>>>>> in OpenWRT.
>>>>>>>>>
>>>>>>>>> This commit reverts the one patch of a3720 cpufreq driver, but
>>>>>>>>> not
>>>>>>>>> the subsequent ones.
>>>>>>>>>
>>>>>>>>> Your commit message says that some 1.2 GHz SOCs are unstable
>>>>>>>>> with the
>>>>>>>>> fix. Did you also test this with the subsequent patches, which
>>>>>>>>> are
>>>>>>>>> now
>>>>>>>>> in stable kernels? I guess the answer is yes, because all these
>>>>>>>>> patches
>>>>>>>>> were backported to 5.10.37.
>>>>>>>>
>>>>>>>> Hi Marek,
>>>>>>>>
>>>>>>>> Yes, the rest of the patches were there as well.
>>>>>>>>>
>>>>>>>>> I am of the opinion that a better approach would be to
>>>>>>>>> - either disable cpufreq for 1.2 GHz variants
>>>>>>>>> - fix a3720 cpufreq driver to only scale up to 1 GHz on 1.2 GHz
>>>>>>>>> variant
>>>>>>>>
>>>>>>>> I would prefer limiting it to 1GHz as that would not cause
>>>>>>>> performance issues,
>>>>>>>> but 1GHz models could have the same issue as well.
>>>>>>>> This is because the voltages that are set as a minimum are from
>>>>>>>> the
>>>>>>>> testing that
>>>>>>>> Pali and the Turris guys did, but it really depends on the SoC
>>>>>>>> batch
>>>>>>>> you receive.
>>>>>>>>>
>>>>>>>>> Since the approach you've taken now (reverting the patch)
>>>>>>>>> basically
>>>>>>>>> changes the CPU parnet clock to DDR clock, which is just wrong.
>>>>>>>>> Worse is that you are doing this for everybody, not just for the
>>>>>>>>> 1.2
>>>>>>>>> GHz variants.
>>>>>>>>>
>>>>>>>>> What do you think?
>>>>>>>>
>>>>>>>> I understand that it was not the best solution, but something had
>>>>>>>> to be done as
>>>>>>>> I was not able to even finish booting on multiple boards before
>>>>>>>> crashing.
>>>>>>>> It just reverted the things back to the previous state.
>>>>>>>>
>>>>>>>> I really could not figure a proper solution even after being in
>>>>>>>> touch
>>>>>>>> with Pali, and contacting
>>>>>>>> GlobalScale.
>>>>>>>>
>>>>>>>> This is an issue caused by Marvell simply ignoring the issue and
>>>>>>>> refusing to publish
>>>>>>>> a fix or release the OTP and AVS docs as they all have a validated
>>>>>>>> voltage in the OTP
>>>>>>>> somewhere.
>>>>>>>
>>>>>>> Robert, we've found this table in linux-marvell repository:
>>>>>>>   
>>>>>>> https://github.com/MarvellEmbeddedProcessors/linux-marvell/blob/dc33b62c90696afb6adc7dbcc4ebbd48bedec269/drivers/regulator/armada-37xx-regulator.c#L99-L105
>>>>>>>
>>>>>>> Do you still have the 1.2 GHz boards which were crashing? Would
>>>>>>> you be
>>>>>>> willing to test whether those boards are stable if we provided
>>>>>>> patch
>>>>>>> for you?
>>>>>>
>>>>>> Yes, I tested on 4 boards If I remember correctly and they all
>>>>>> crashed
>>>>>> with the voltages that are set,
>>>>>> only by manually raising to at least 1.1902V one got stable while
>>>>>> other required 1.2+V
>>>>>>
>>>>>> I would be glad to test a possible solution.
>>>>>>
>>>>>> Regards,
>>>>>> Robert
>>>>>>>
>>>>>>> Marek
>>>>>
>>>>>
>>>>> Hi,
>>>>>
>>>>> any progress on this?
>>>>> Are there any patches to avoid the 1.2GHz?
>>>>
>>>> Hello,
>>>>
>>>> The patch [1] was sent to the linux-arm-kernel mailing list, but there
>>>> was no response from Marvell even though it was requested multiple
>>>> times. Hopefully, it will be merged soon.
>>>>
>>>> [1]
>>>> https://lore.kernel.org/linux-arm-kernel/20210630135942.29730-1-kabel@kernel.org/T/
>>>>
>>>>
>>>>
>>>> Josef
>>>
>>> Hi,
>>>
>>> Should we then better revert the patch from Robert and take this
>>> additional patch from Marek even when Marvell does not react?
>>>
>>> Does anyone have a better idea?
>>>
>>> Hauke
>>
>> Hello,
>>
>> Yes, we should do it before there is going to be OpenWrt 21.02 release.
>> Should I send v2?
>>
>> Josef
>>
>
> Hi Josef,
>
> Yes, please send a v2.
>
> Hauke
Hello Hauke,

I sent 2nd version almost 2 weeks ago [1] [2].

[1] master:
https://patchwork.ozlabs.org/project/openwrt/list/?series=255415 +
https://patchwork.ozlabs.org/project/openwrt/list/?series=254135

[2] openwrt-21.02:
https://patchwork.ozlabs.org/project/openwrt/list/?series=255418

Is there something wrong with it?

Looking forward to hearing from you,
Josef Schlehofer