[SENSE KERNEL] no longer maintained

I forked LeeDroid v2.2f, so we have all usual patches (GPU, SDFix etc), kernel is then patched it up to 2.6.32.27.

BFS363,
VR IO Scheduler enabled. Why? These benchmarks - http://xdaforums.com/showpost.php?p=10669818&postcount=591
SLQB slab allocator enabled
Sibere charging fix applied (thanks to sibere)
HAVS@875mV and 925mV (Thanks to Richard Trip)
vorkKernel compiler optimisations. (Thanks to benee)
Camera Overclock (Thanks to Cyanogen!)
Various Cyanogenmod patches (Thanks to Cyanongen for the fantastic job they do!)

**DISCLAIMER**** I don't take any responsibility for any damage this kernel may cause to your device.

Only use this if you have a Sense ROM (no defrost/cyanogenmod/AOSPDesire/opendesire/). It works great with the new HD roms.

Download at http://mirror.couttstech.com/android/index.php?dir=bravo/kernel/Sense/BFS/

DO NOT GO POKING ABOUT IN SUB FOLDERS OR DOWNLOADING ANYTHING WITH TEST IN THE NAME

"couttstech-2.6.32.28_OC1190_HAVS@875mV_BFS_VR.zip"
"couttstech-2.6.32.28_OC1190_HAVS@925mV_BFS_VR.zip"
"couttstech-2.6.32.28_OC1190_BFS_VR.zip"

CFS versions download at http://mirror.couttstech.com/android/index.php?dir=bravo/kernel/Sense/CFS/-:

"couttstech-2.6.32.28_OC1190_HAVS@875mV_CFS_VR.zip"
"couttstech-2.6.32.28_OC1190_HAVS@925mV_CFS_VR.zip"
"couttstech-2.6.32.28_OC1190_CFS_VR.zip"

Please visit the sponsors and help pay for bandwidth!

Source -
git://git.couttstech.com/couttstech-bravo.git

***CHANGES

24 - Nov - 2010 - Changed from SLAB to SLUB
24 - Nov - 2010 - Latest HTC kernel updates patched (Thanks to ziggys kernel for this patch)
25 - Nov - 2010 - Added 128MHz as requested
27 - Nov - 2010 - Audiomod added to BFS kernels
05 - Dec - 2010 - Removed OC1113 kernels
05 - Dec - 2010 - Added camera overclock patch ( http://review.cyanogenmod.com/#change,35 )
05 - Dec - 2010 - Various cyanogen patches applied see git log for details
05 - Dec - 2010 - Change from SLUB to SLQB slab allocator
06 - Dec - 2010 - Change to ondemand by default (initial testing showing better battery life with HAVS, thanks melethron)
07 - Dec - 2010 - HAVS SetCPU clock speed out by one step issue fixed.
09 - Dec - 2010 - Changed Audio min gain for handset and headset
10 - Dec - 2010 - Added AUFS module
14 - Dec - 2010 - Patched to 2.6.32.27
16 - Dec - 2010 - BFS patched to version 360
17 - Dec - 2010 - Charging on lock screen fix included (many thanks to snq-)
23 - Dec - 2010 - Headset max gain lowered, also video compiled into kernel instead of being modules
01 - Jan - 2011 - BFS updated to v363
06 - Jan - 2011 - Full ck2 patch set applied (for BFS kernels)
09 - Jan - 2011 - Car dock working
09 - Jan - 2011 - Revert to stock battery driver
09 - Jan - 2011 - Sibere battery fix applied
09 - Jan - 2011 - Patched to 2.6.32.28
09 - Jan - 2011 - Reiserfs enabled
09 - Jan - 2011 - CFS builds added
10 - Jan - 2011 - CGROUPS sorted on CFS builds
11 - Jan - 2011 - Voltages raised for higher freq on SVS versions, should be stable for all now
14 - Jan - 2011 - Revert ck2 patch set for BFS kernels
17 - Jan - 2011 - Switch to VR IO Scheduler as default

Full changelog -:

http://git.couttstech.com/?p=couttstech-bravo.git;a=summary

IRC - irc.freenode.net - #coutts99

Terepin said:

But with HAVS ondemand should be better, no?

Click to expand...

Click to collapse

An explanation how this all works. Ondemand has a sampling rate of 20ms default. This means that the govenor checks every 20ms if it needs to change clocks. This means that there can be a delay of up to 20ms (worst case) to let the clock jump up. (if you play/played online game you may have a "feeling" for what this value feels like as ping. But note that ondemand hasn't a constant latency of 20ms but is somewhere between 0 and 20ms ... so not everytime "feelable")

Interactive/smartass works different. They take over the "idle" process. Through this the change of clocks is almost "instant".

This is at least the theory but in my opinion smartass in indeed faster. Also the threshold (95% at ondemand) isn't needed then. This means it wont jump from 245->998->245 but also goes to medium values. The difference between smartass is not feelable in most cases (but it is if you watch closely it is slower). If you bench then is also noticeable because the latency of ondemand will sum up and you may stay like 100-200ms (pure guessing maybe much more) or something on a low clock when a high clock is needed. Thus the lower score.

Now to HAVS. HAVS changes values dynamically depending on system load. This means if the cpu jumps up while there is only a short spike the voltage wont be set as high. This is good on ondemand because it has those spikes because of those jumps from the needed high threshold (and you if you reduce the treshhold it will go up too slow if its needed 245>556>998 with a delay between 20ms and 40ms so changing that is not a good idea).

As smartass is changing clocks much more often it has a side effect with smartass. HAVS needs to calculate the values more often than with ondemand. In general HAVS isnt more stable on ondemand than on smartass, but there is a physical issue. If a voltage is change to a higher value by a conductor it needs to build up a higher "electrical charge". This means that voltage switching is physically delayed (its really short time but its testable). If your cpu is stable on 875mv on 245mhz and stable on 1275mv at 998mhz it can be still unstable if it jumps from 245 to 998 (because of the physical delay the 998 may not have the full 1275mv). I had instabilities because of this with an older version of coutts kernel. On "performance" (means CONSTANT high value) 998@1275 and on powersave (CONSTANT low clock) with 245@925 it was stable. When i switched to smartass/ondemand it has gotten unstable .... so this is not just some physical theory it's also practice (btw: a theory that doesnt apply to practice is wrong ). Now as i said this issue is there on both governors but it applies more often on smartass because of the faster switching of clocks. This is why ondemand is more stable in combination with HAVS.

Now as i said the dynamically switching of voltages from HAVS is good to keep a lower overall voltage on spikes it is a bit different with smartass. Since smartass uses the idle process the governor ITSELF is more adjusted to actual system load. This makes HAVS redundant in my opinion. If you watch the "info" tap in set cpu you'll see that smartass will stay a.) more time on lower or medium clocks and b.) doesnt "spike" that much. So the voltages set by SVS (svs sets the voltage statically to a value ... the mV for every clock is fixed) will be lower than on ondemand and this makes HAVS obsolete imo.

To summerize:

ondemand is a "static" adjustment of clock (every 20ms)
smartass is dynamic depending on system load (through idle process)

SVS sets voltages statically depending on clock
HAVS sets voltages dynamically depending on system load.

This means then that smartass + svs is completly dynamical on its own. Because if the clock is dynamically changed the "static" voltages are dynamic because of the dynamic clock.

This makes HAVS then reduntant. Since SVS doesnt need time to calculate the mV values it means
a). less to do for the cpu (but thats not much anyway ... but still there is)
b). Without calculation the switching is faster and thus a bit more stable (havs adds calculation time to the physical delay).

So much for the theory. But what about reallife? Test it on your own

I never found any power advantages from HAVS in conjunction with smartass (on daily use). This makes HAVS practically "dead code". Since i constantly calculates values that aren't needed and it is slightly more unstable. I'll stick to SVS + smartass.

EDIT: @coutts: It's funny. I got a freeze in recovery with your svs cfs 1275 kernel. After flash it was idle and my cpu couldn't handle the voltage. I pack your 1300 version to the recovery. That is rock solid for me.

Ill add btrfs and jfs

Sent from my HTC Desire using XDA App

coutts - is there any chance you can shorten the filename somewhat?

...only the filename is so long now that I'm having problems telling versions apart when I download them ...the filenames get truncated sometimes such as in ROM Manager and clockwork...

I suggest perhaps removing the LeeDroid bit cos it's not really relevant anymore...I promise I'll put more attention into my file management if you can do this

Ok

Building CFS versions with -:

CONFIG_GROUP_SCHED=y
CONFIG_FAIR_GROUP_SCHED=y
CONFIG_RT_GROUP_SCHED=y
CONFIG_CGROUP_SCHED=y
CONFIG_CGROUPS=y
# CONFIG_CGROUP_DEBUG is not set
# CONFIG_CGROUP_NS is not set
# CONFIG_CGROUP_FREEZER is not set
# CONFIG_CGROUP_DEVICE is not set
# CONFIG_CGROUP_CPUACCT is not set
# CONFIG_SCHED_AUTOGROUP is not set
CONFIG_CGROUP_BFQIO=y
# CONFIG_NET_CLS_CGROUP is not set