FlashBurn

Here it comes
 
It works like this, you have a base frequency of e.g. 1000MHz and you have 4 load levels. For every load level you can define a divider and a core voltage.
 
Base frequency divider real frequency core voltage 1000 MHz 1 1000 MHz 1.10 V 1000 MHz 2 500 MHz 1.05 V 1000 MHz 4 250 MHz 1.00 V 1000 MHz 5 200 MHz 0.95 V  
Without the patches for the cpu freq driver the kernel thinks it uses a base frequency of 1000 MHz, but in reality is looks like this:
 
Base frequency divider real frequency core voltage 800 MHz 1 800 MHz 1.10 V 800 MHz 2 400 MHz 1.05 V 800 MHz 4 200 MHz 1.00 V 800 MHz 5 160 MHz 0.95 V  
As the cpu is running with a lower frequency in reality it also is not a problem that the core voltage is not high enough for the lower load levels.
 
The problem is not the core voltage of the highest load level, but the lower load levels (which one precisely I don´t know).
 
I hope I could explain it to you, if something is still not clear, just ask.

The elegant way is supplying a lib.config in userpatches and insert the line:
KERNELBRANCH='tag:v4.19.20'  

I just made the pull request with the 2 needed patches to make cpu frequency scaling working. These patches also fixed the problem with the 600 MHz firmware and the cpu scaling.
 
Best would be if some people could test this on older revision boards. I also could not test this for the 1000 MHz firmware.

This is getting annoying. The deeper I look the more errors I find
 
My fix seems to work. I tried my fix with the current uboot firmware´s supplied by armbian and these are my findings:
 
- 1200 MHz: working fine, sbc-bench: http://ix.io/1BQ9
- 1000 MHz: I´m still trying to find out why this wont work for me
- 800 MHz: working fine, sbc-bench: http://ix.io/1BQr
- 600 MHz: could work fine, if the cpufreq init code would not mess up; at the moment it is just running at 300 MHz, sbc-bench: http://ix.io/1BQF
 
The problem with the 600 MHz is, that the parent clocks are running at 1200 MHz and a divider by 2 is used, but this is a problem for the cpufreq init code, because the cpu core frequency is 600 MHz and the cpu frequency which gets reported to the kernel is 600 MHz divided by the divider found in the dvfs which is 2.
So to fix this problem, the parent frequency has to be taken to report the right frequency to the kernel. As I don´t intend to run at 600 MHz I will ignore this problem, but regard it as reported with this post. If someone wants to fix it and needs more information just ask.
 
When I found out what the problem with 1000 MHz is and I fixed it, I will post the needed patches for fixing the cpu frequency for 800, 1000 and 1200 MHz.

So the good thing is I found the problem, the bad thing is I don´t know how to fix it
 
The problem is, like I assumed, that the wrong clock source is selected or better to say, no clock source is selected and because of that it is the wrong one.
 
In drivers/cpufreq/armada-37xx-cpufreq.c the dvfs is initialized. The right clock source should be selected with the 2 lines at the end of the function armada37xx_cpufreq_dvfs_setup(). But this does not call the needed function clk_pm_cpu_set_parent() in driver/clk/armada-37xx-periph.c.
 
I fixed it for me with hard coding the right value in the registers.
 
So all that is needed for fixing the problem is that the function clk_pm_cpu_get_parent() needs to be called, to get the right clock source and then clk_pm_cpu_set() needs to be called with that source. I don´t know enough about the clk code to know what needs to be done the right way.
 
The question is now, whom to tell this, so that this could be fixed?
 
This is a sbc-bench.sh run with my hard coded fix and 1200MHz: http://ix.io/1BCD