mvebu: armada 3720 cpufreq reverts
robert.marko at sartura.hr
Wed Jun 30 08:51:24 PDT 2021
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
> 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.
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
> 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
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
Staff Embedded Linux Engineer
Lendavska ulica 16a
10000 Zagreb, Croatia
Email: robert.marko at sartura.hr
More information about the openwrt-devel