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 _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel