mvebu: armada 3720 cpufreq reverts

[Josef Schlehofer]

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