mvebu: armada 3720 cpufreq reverts

[Hauke Mehrtens]

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?

Hauke