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