mvebu: armada 3720 cpufreq reverts

[Josef Schlehofer]

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

>
> Hauke