mvebu: armada 3720 cpufreq reverts

[Hauke Mehrtens]

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