[Tweak] AXI Frequency Tweaks for performance and battery savings

---

So I've been traipsing through some of the other Qualcomm repositories searching for tidbits that might be of use for N1 kernels. As far as I can tell, none of these changes have been merged in to the aosp or cyanogen kernels, although unfortunately the underlying kernels have diverged and these won't apply cleanly but it should be possible to manually merge with some effort.

First up, this patch reduces AXI (internal bus) speed when the apps CPU is running at lower clock speeds and increases it when at higher clock speeds. Memory would otherwise be the bottleneck for many applications.

https://www.codeaurora.org/gitweb/qu...81183eae8947a8

msm: acpuclock-8x50: Couple CPU freq and AXI freq.

The memory throughput is directly proportional to the AXI frequency. The
AXI freq is coupled with the CPU freq to prevent the memory from being
the bottleneck when the CPU is running at one of its higher frequencies.
This will cause an increase in power consumption when the CPU is running
at higher frequencies, but will give a better performance/power ratio.

This patch adds core support for AXI clock changes.

https://www.codeaurora.org/gitweb/qu...c74ee3e943787e

msm: clock: Add SoC/board independent APIs to set/get max AXI frequency.

Some drivers need to set the AXI frequency to the maximum frequency
supported by the board. Add a MSM_AXI_MAX_FREQ_KHZ magic value that
allows them to achieve that in a SoC/board independent manner.

The following two patches drop the AXI speed when the processor is idle but the screen is on, down to the minimum that will allow the framebuffer to keep driving the screen. Claims to save ~20 mA which would be somewhere around 10-20% at least. Unfortunately these will probably be harder to merge in, as the Chromium kernel uses quite a different mdp/framebuffer architecture. Still, worth trying!

https://www.codeaurora.org/gitweb/qu...d0abf5dd5cfb57

msm_fb: Reduce AXI bus frequency to 62 Mhz from 128 Mhz

Reduced AXI bus frequency to 62 Mhx to save power during idle
screen mode/limited sleep mode.

https://www.codeaurora.org/gitweb/qu...f3e31f1ba656a6

msm_fb: Reduce AXI bus frequency to 58 Mhz from 64 Mhz.

Reduce AXI bus frequency further to 58 Mhz for lcdc panels to save
~20mA power during idle screen mode/limited sleep mode.

I can't wait to see what Kmobz, Intersect, and pershoot do with this!

interesting stuff...hopefully one of the many great kernel devs can use this info and find a way to get it to be useful on the N1 and save more battery life

For those interested, if you have a look at pm.c, a lot of the logic seems to be already there:

/* axi 128 screen on, 61mhz screen off */
static void axi_early_suspend(struct early_suspend *handler) {
	axi_rate = 0;
	clk_set_rate(axi_clk, axi_rate);
}

The only thing that is missing is the setting of the axi rates along with the cpu frequency. However, I would think that it is going to take a special amount of trial and error to get the rates correct for the nexus one, since they are, after all, different pieces of hardware.

We could try to further reduce the frequency of the AXI bus while the screen is off. AOSP currently does 61MHz, right?

Originally Posted by coolbho3000

We could try to further reduce the frequency of the AXI bus while the screen is off. AOSP currently does 61MHz, right?

It should be possible to go with Code Aurora's 58 I think?

Yes we could reduce it further. I dont know what impact it will have on stability yet.

I have provided a very quick (and very dirty) patch for scaling the axi rates according to cpu frequency. THIS IS NOT INTENDED TO BE USED UNLESS YOU KNOW WHAT YOU ARE DOING.

It is just a preliminary patch which compiles into a zImage. I do not know if it works (i'll leave that to the experts). Please, always (!!), check the patches and code before running the kernel image.

I tried to follow the convention already existing in acpuclock-scorpion as much as possible. One caveat: I do not know what the return value for a successful clk_set_rate is, and I am only assuming based on the code aura sources (pm.c does not use the return value).

Edit: forgot to add that I think it is a little too much for pm.c AND acpuclock-scorpion to be setting the axi value (if it works at all), and might cause stability issues. Maybe someone might try removing the pm.c code and use acpu-clock only, I dont know....

Originally Posted by jazzor

Yes we could reduce it further. I dont know what impact it will have on stability yet.

I have provided a very quick (and very dirty) patch for scaling the axi rates according to cpu frequency. THIS IS NOT INTENDED TO BE USED UNLESS YOU KNOW WHAT YOU ARE DOING.

It is just a preliminary patch which compiles into a zImage. I do not know if it works (i'll leave that to the experts). Please, always (!!), check the patches and code before running the kernel image.

I tried to follow the convention already existing in acpuclock-scorpion as much as possible. One caveat: I do not know what the return value for a successful clk_set_rate is, and I am only assuming based on the code aura sources (pm.c does not use the return value).

Edit: forgot to add that I think it is a little too much for pm.c AND acpuclock-scorpion to be setting the axi value (if it works at all), and might cause stability issues. Maybe someone might try removing the pm.c code and use acpu-clock only, I dont know....

I've made too many changes to acpuclock to apply this directly. I'll take a look at it later though.

Originally Posted by jazzor

For those interested, if you have a look at pm.c, a lot of the logic seems to be already there:

/* axi 128 screen on, 61mhz screen off */
static void axi_early_suspend(struct early_suspend *handler) {
	axi_rate = 0;
	clk_set_rate(axi_clk, axi_rate);
}

True, but the comment doesn't agree with the code itself:

/* axi 128 screen on, 61mhz screen off */
<snip>
static void axi_late_resume(struct early_suspend *handler) {
	axi_rate = 128000000;
	sleep_axi_rate = 120000000; // <- 120 MHz...
	clk_set_rate(axi_clk, axi_rate);
}

I wonder if we could drop the sleep_axi_rate = 120000000 to something much lower?

Also, the OP patches were for dropping the AXI rate when the screen is on but the processor is idling. (And it's not clear what screen resolution the code in the OP patches was for, but if it's for ChromeOS I presume it's higher than our 800x480, so bus bandwidth for the framebuffer shouldn't be a problem). So no, unless I'm missing something most of the logic in these patches isn't there already as you claim. (If I am missing something, please show me where... I believe it would have to be in the MDP driver somewhere).

Originally Posted by hugonz

True, but the comment doesn't agree with the code itself:

/* axi 128 screen on, 61mhz screen off */
<snip>
static void axi_late_resume(struct early_suspend *handler) {
	axi_rate = 128000000;
	sleep_axi_rate = 120000000; // <- 120 MHz...
	clk_set_rate(axi_clk, axi_rate);
}

I wonder if we could drop the sleep_axi_rate = 120000000 to something much lower?

Also, the OP patches were for dropping the AXI rate when the screen is on but the processor is idling. (And it's not clear what screen resolution the code in the OP patches was for, but if it's for ChromeOS I presume it's higher than our 800x480, so bus bandwidth for the framebuffer shouldn't be a problem). So no, unless I'm missing something most of the logic in these patches isn't there already as you claim. (If I am missing something, please show me where... I believe it would have to be in the MDP driver somewhere).

I might be wrong, but this is how I understand it. axi_early_suspend is called when the nexus is going under suspend mode, which is like suspend to ram. This happens when there are no active tasks running and the screen is off. As the code says, the rate is set to 0 implying it is going to set it as low as the limits allow (assuming that is 61mhz). axi_late_resume is for the case when the nexus is NOT in suspend. There are still 2 states in this mode, one where the machine is being actively used (browsing web) and one where the machine is idle (such as when we are listening to music or any background task that may or may not be using the screen), but the machine cannot suspend to ram due tasks still actively running.

In any case, experimenting with lower values of axi rates should be done to see if it indeed saves battery.