mvebu: armada 3720 cpufreq reverts

[Hauke Mehrtens]

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