mvebu: armada 3720 cpufreq reverts

[Robert Marko]

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



-- 
Robert Marko
Staff Embedded Linux Engineer
Sartura Ltd.
Lendavska ulica 16a
10000 Zagreb, Croatia
Email: robert.marko at sartura.hr
Web: www.sartura.hr