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.be...@nic.cz> >>>>>> wrote: >>>>>>> >>>>>>> On Wed, 30 Jun 2021 17:51:24 +0200 >>>>>>> Robert Marko <robert.ma...@sartura.hr> wrote: >>>>>>> >>>>>>>> On Wed, Jun 30, 2021 at 3:19 PM Marek Behún <marek.be...@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-ka...@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 _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
