[Motorola Droid RAZR] dtrail1:
What kernel is it?

Regarding to "useless freq":

see 200mhz, if this is the kernel from the AOKP Thread (Surdu_Petru), it seems to be the first early release which has no fixed PM_QOS Request to keep frequency lower than current freq - in this case 200mhz. I am referring to this similar peace of code inside PM QoS source (Power Management Quality of Service) from kernel. this shows how the CPU Policy for min_freq works, and this process can be executed by the PM_QOS too:

if ((cur_freq < table_min_freq) && (optimum_freq > cur_freq)) {
table_min_freq = cur_freq
};

this means:

"If the current frequency is lower than the minimum suggested frequency from the whole table (no matter what freqs are defined by the dev) AND if also the lowest optimal available frequency (which is 400 mhz in this case) is bigger than the current frequency (which is 200mhz), then set the value of the lowest optimum frequency table entry (400mhz) to be the current frequency, so the lowest frequency will be 400mhz immediately."

So the frequency of 200mhz will be ignored, until the user sets it back manually and then the the same process begins from start again after a while...

Why 800mhz could be "useless":

It depends on seeveral things, in example the used CPUFreq governor and its settings how to handle upscaling and downscaling. Usually most governors are scaling up to highest available frequency as soon as the device registers some user input, so it will jump over all other frequencies. But, depends on how the settings is, but usually the other freqeuncies in table will be used more while scaling down. It stays for a specified time (e.g. 100 ms) on each step as long as the user doesn't do anything anymore.

There are several ways to "solve" or change this behavior:

- Reconfigure Governor to lower/faster scaling

- Disable PM_QOS Request for CPU DMA Latency

- Change the rules for CPU Policy min_freq, like:

if ((cur_freq < table_min_freq) && (optimum_freq > cur_freq)) {
cur_freq = table_min_freq
};

SO it detects that the optimum frequency is bigger than the current frequency, but it sets the minimum available frequency to that amount of the current frequency (200mhz). - In my theory :D

One more possibilty: Just add more OPPs (Frequency steps) for smoother scaling, so it "climbs" slower per Frequency and can target the optimum frequency more efficient.

However, maybe you can help me with something within the next days. thx.

I've just packed the new build including two kernel version, selectable from Aroma Installer:

1. JBX-Kernel - Default Kernel for battery saving

2. JBX-Kernel OC Edition: Higher Frequencies but also eats more power

Both kernel provide the same features, such as Custom Voltage Interface Support, usbale with any VSEL App (Speed Daemon included already).

I will install on my device now, and if it goes without issues -> Release! :)

EDIT: In Kernel documentation is described that you can change the behavior of policy, but my theory didn't work that way I want. Kernel works, but scaling set doesn't work now.

Doesn't matter. I found finally the needed stuff to finish the kernel. Besides of that both Kernels are stable. You can select your preferred one in Aroma Installer..