[PATCH 21.02] ipq806x: backport cpufreq changes to 5.4

[Shane Synan]

On 7/1/21 4:55 PM, Shane Synan wrote:
> On 6/28/21 2:10 AM, Shane Synan wrote:
> [...]
> 
> Given these commits work just fine on the "master" branch, and on
> "21.02" it worked to change the CPU governor *without* the DTSI
> backports and cache (i.e. only the first commit), I strongly suspect I
> goofed up and missed backporting something important.

After further attempts, I still encounter the issue on OpenWRT "master"
with Linux kernel 5.4 as well, I just didn't try enough iterations of
SFTP upload testing.  Disabling 1.4 GHz L2 cache by removing that
"opp_table_l2" entry from the .dtsi
(git revert'ng "ipq806x: fix missing 1.4ghz cache freq for ipq8065 SoC")
*so far* seems more stable.

This applies to OpenWRT 21.02 as well if I try backporting the changes:
https://github.com/openwrt/openwrt/compare/openwrt-21.02...digitalcircuit:openwrt-21.02-cpufreq-dtsivolt-cache
...versus...
https://github.com/openwrt/openwrt/compare/openwrt-21.02...digitalcircuit:openwrt-21.02-cpufreq-dtsivolt-cache-no-1.4ghz
(stress-ng currently fails to build from source on the "master" branch,
hence trying to narrow it down on 21.02 as well)

Unfortunately, I still haven't managed to recreate this issue in a
simple manner.  I'm continuing to experiment with stress-ng parameters
in various loops, scripting GNOME's GIO backend via Python for repeated
SFTP uploads, etc, but haven't succeeded yet.  I'll continue to explore
my options.

Would you have any suggestions for how to diagnose this issue at a lower
level?

I've not gotten any cpufreq-related error messages from the serial
console.  I've noticed that the cpufreq driver mentions transitions
to/from 384 MHz as well, despite having the /etc/init.d/cpufreq changes
applied raising scaling_min_freq to 600 MHz - perhaps I'm somehow
bypassing the check that tries to avoid the hardware constraint?
   From  :    To
         :    384000    600000    800000   1000000   1400000   1725000 
   384000:         0        14         3         6        11         9 
   600000:        15         0     49834     23113         7    106477 
   800000:         7     64708         0     14301        34     28653 
  1000000:        10     32739     13774         0        37     24203 
  1400000:         6         8        21        62         0        17 
  1725000:         5     81977     44070     33281        25         0
(Source: /sys/devices/system/cpu/cpufreq/policy[0..1]/stats/trans_table)

Alternatively, is it possible to adjust the maximum L2 cache frequency
at runtime, similar to setting the CPU governor min/max?

To be clear, I appreciate your efforts to keep ipq806x alive, especially
after Qualcomm had abandoned the platform (I hadn't realize this until
someone on #openwrt-devel pointed this out).  I don't intend to seem
ungrateful.  If you'd prefer to consider this bizarrely hard-to-simplify
test case unsolvable, that's okay!  I can continue to run custom builds
with 1.4 GHz L2 cache frequency disabled, and the majority of others
without my bizarrely-nondeterministic issues can enjoy the higher speed.

Regardless, thank you for your time spent looking into this!  I hope
my attempts to diagnose this has not caused you any trouble.