[PATCH 21.02] ipq806x: backport cpufreq changes to 5.4

[Shane Synan]

On 7/26/21 11:19 PM, Shane Synan wrote:
> Thank you!  In the upcoming weeks, I'll look into tinkering with the
> voltage settings for the CPU in the OPP table.
>
> […]
I've tried multiple other things (mentioned below) which haven't
worked, so it's on to modifying the CPU voltage!  I admit I held off
out of concern for damaging the router, but I'm at the point of
being willing to replace it, so if I mess up, it's fine.

Just to confirm, increasing CPU voltage in the OPP table involves
modifying the "opp-microvolt" line within "[...]/qcom-ipq8065.dtsi"...

opp-1400000000 {
	[...]
	opp-microvolt = <1150000>;
	[...]
}

...correct?

And if so, do you remember how much you increased the voltage?

I'll research this regardless, so if it'd be a hassle to find it, etc,
no obligation.  As before, thank you for your time!

Regards,
Shane Synan


P.S. The rest of this is merely publicly keeping track of what I've
tried that has not worked:

* Replacing the router power supply (tried "HitLights 12VDC 60W", e.g.
5 amp vs. router's OEM 3.5 amp)

Nothing-shown-in-serial-console reboot still happens.  It is possible
I picked a bad power supply, I don't (yet) have a convenient way to
measure it while connected to the router, but it at least seemed
reasonable.  I can revisit this one if desired.

* Using a powered USB 3.0 hub connected to the USB 3.0 port on the
NBG6817 to remove all power draw (peak measured current: 0.001 amps)

Issue still happens.

* Using an SSD (Samsung 850 Pro 256 GB) via the USB 3.0 hub instead
of the spinning 1 TB HDD

Issue still happens.

(Note: the SSD connected directly to the NBG6817's USB 3.0 port
without the powered USB 3.0 hub in between resulted in the Linux
kernel losing connection and resetting the USB port, possibly due to
sharper current spikes than the spinning disk.  I'm treating that as
an unrelated issue.)

* Using the same SSD via the USB 3.0 hub connected to the NBG6817's
USB 2.0 port

Issue still happens - it's likely not the router's USB 3.0 port.

Older tests:
* Measuring and recreating the 1 TB USB 3.0 HDD's peak power draw
(670-ish mA) and/or the maximum USB 3's spec power draw (900 mA) and
manually toggling a testing load rapidly on/off while router's under
CPU load

No quick crashes.  I'd need to automate the USB test load to perform
a long term (multiple hours) test though.

Future tests:
Asides from the OPP table adjustment, I may try other testing
combinations too, e.g. an IRC suggestion of turning off WiFi radios.
Other ideas include putting the USB HDD on USB 2.0 port without/with
the powered USB 3.0 hub, fitting a measurement device between the
router's power supply and the router itself, etc.


As a refresher for others and myself, my backport efforts are
currently in these two links:

Backport CPU governor with 1.4 GHz L2 cache enabled (broken for me):
https://github.com/openwrt/openwrt/compare/openwrt-21.02...digitalcircuit:openwrt-21.02-cpufreq-dtsivolt-cache

...versus...

Backport CPU governor with 1.4 GHz L2 cache DISABLED (works for me):
https://github.com/openwrt/openwrt/compare/openwrt-21.02...digitalcircuit:openwrt-21.02-cpufreq-dtsivolt-cache-no-1.4ghz

(As Ansuel noted months earlier, this should be a performance
regression from 19.07.  While I've not noticed any appreciable
degradation, I've also not run iperf3/etc to confirm throughput, and
my ISP's claimed 200 mbit/s download speed is hardly top tier.)