[Tweak] AXI Frequency Tweaks for performance and battery savings - Nexus One Android Development

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/q...it;h=6caa6d84d8c687b5f66f5b5ea281183eae8947a8
Code:
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/q...it;h=009d997b1439edf1991e181206c74ee3e943787e
Code:
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/q...it;h=fdb01a9945f2ac3a4cc76c507ed0abf5dd5cfb57
Code:
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/q...it;h=dee586811e34cb24dedc1d0587f3e31f1ba656a6
Code:
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:
Code:
/* 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?

---

coolbho3000 said:
We could try to further reduce the frequency of the AXI bus while the screen is off. AOSP currently does 61MHz, right?
Click to expand...
Click to collapse
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....

---

jazzor said:
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....
Click to expand...
Click to collapse
I've made too many changes to acpuclock to apply this directly. I'll take a look at it later though.

---

jazzor said:
For those interested, if you have a look at pm.c, a lot of the logic seems to be already there:
Code:
/* 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);
}
Click to expand...
Click to collapse
True, but the comment doesn't agree with the code itself:
Code:
/* 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).

---

hugonz said:
True, but the comment doesn't agree with the code itself:
Code:
/* 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).
Click to expand...
Click to collapse
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.

---

oooh great thread. I will definitely be looking into this stuff when I get back in town! thanks for the links!

---

https://www.codeaurora.org/gitweb/q...it;h=8a68421a300878d729991c1db609a541910d2c70
Here is another patch (more up to date -> perhaps easier to merge).

---

I just implemented the AXI frequency tweak for N1 - I noticed it is also present in HTC Desire kernel
I am testing it now - so far it seems stable.
Attached acpuclock_scorpion.c implementing the AXI tweaks. Basically, AXI frequency now scales with CPU frequency.

---

Ivan Dimkovic said:
I just implemented the AXI frequency tweak for N1 - I noticed it is also present in HTC Desire kernel
I am testing it now - so far it seems stable.
Attached acpuclock_scorpion.c implementing the AXI tweaks. Basically, AXI frequency now scales with CPU frequency.
Click to expand...
Click to collapse
Do you run this along with a custom kernel and just flash in recovery like an update.zip?

---

I usually use Cyanogen's kernel as base for my experiments - so this should definitely compile with Cyanogen's 2.6.34 kernels. This acpuclk-scorpion.c has lowered voltages and also support for frequencies up to 1190 MHz
Although you will also need to change few call prototypes in acpuclock.h - it is quite trivial just replace old acpuclk_set_rate() and acpuclk_power_collapse() prototypes with these:
enum setrate_reason {
SETRATE_CPUFREQ = 0,
SETRATE_SWFI,
SETRATE_PC,
SETRATE_PC_IDLE,
};
int acpuclk_set_rate(unsigned long rate, enum setrate_reason reason);
unsigned long acpuclk_power_collapse(int from_idle);
Click to expand...
Click to collapse
That should do it.

---

Markdental said:
Do you run this along with a custom kernel and just flash in recovery like an update.zip?
Click to expand...
Click to collapse
No, this will have to compiled into the kernel, which I'm doing right now. Thank you so much for doing this Ivan!

---

Nice to see someone finally got this to work! I've been too lax as of late.

---

Getting AXI scaling to work was pretty easy - makes me wonder why is it not in the AOSP kernel for N1.
It is definitely in the HTC Desire kernel, and I am sure HTC knows what is good for the hardware they built

---

Ivan Dimkovic said:
Getting AXI scaling to work was pretty easy - makes me wonder why is it not in the AOSP kernel for N1.
It is definitely in the HTC Desire kernel, and I am sure HTC knows what is good for the hardware they built
Click to expand...
Click to collapse
what change to pm.c if any?

---

pm.c already has everything in place needed for AXI clock switching.