mvebu: armada 3720 cpufreq reverts

Sun Aug 8 12:06:07 PDT 2021

On 8/8/21 8:15 PM, Josef Schlehofer wrote:
> 
> On 27. 07. 21 11:24, Hauke Mehrtens wrote:
>> 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
> Hello Hauke,
> 
> I sent 2nd version almost 2 weeks ago [1] [2].
> 
> [1] master:
> https://patchwork.ozlabs.org/project/openwrt/list/?series=255415 +
> https://patchwork.ozlabs.org/project/openwrt/list/?series=254135
> 
> [2] openwrt-21.02:
> https://patchwork.ozlabs.org/project/openwrt/list/?series=255418
> 
> Is there something wrong with it?
> 
> Looking forward to hearing from you,
> Josef Schlehofer
> 
Hi Josef,

I overlooked these patches before and applied them now to master and 21.02.

Today I applied multiples patches and pull request and already had them 
in my list, I just took the one for the 21.02 branch initially into master.

If some new developments happen upstream and they apply a better fix 
upstream, please send a backport to OpenWrt.

Hauke