[Kernel][Sense 4] crpalmer | August 25, 2013

Search This thread

jeremy46er

Senior Member
Apr 25, 2011
215
31
Re: [Kernel] [Mar 16] crpalmer's [Linaro 4.7 -O3] [Linux 3.4.36][hotplug, thermald, e

I'm just happy that we have these guys working on our phone. I came from the Droid X2 which had nowhere near this type of development.

If things aren't working get a log and post it in the devs forum. From what I've seen they all make their best effort to address issues when logs are provided. If something still isn't working on your phone just try something else, there are plenty of choices and it would be nice to keep it this way. No need to bash anyone's work especially if you don't have the skills to help make it better yourself. If you do have those skills than please share to make this device the best it can be.

Sorry Palmer, I don't like to complain but I couldn't resist. I will not comment on this topic again.

Sent from my HTC6435LVW using XDA Premium HD app
 
  • Like
Reactions: andrewlyle

CharliesTheMan

Senior Member
Re: [Kernel] [Mar 16] crpalmer's [Linaro 4.7 -O3] [Linux 3.4.36][hotplug, thermald, e

Anybody have an OTG cable to ship to crpalmer? I just sent mine to another developer, I was hoping somebody else might have one already that they can send, instead of me ordering one and waiting on it to arrive then shipping it to crpalmer.

Sent from my HTC6435LVW using Xparent Red Tapatalk 2
 

crpalmer

Inactive Recognized Developer
Mar 25, 2011
2,999
8,280
Re: [Kernel] [Mar 16] crpalmer's [Linaro 4.7 -O3] [Linux 3.4.36][hotplug, thermald, e

I have an otg cable (although I only use it in cmr). Does it not work with my kernel?
 

CharliesTheMan

Senior Member
Re: [Kernel] [Mar 16] crpalmer's [Linaro 4.7 -O3] [Linux 3.4.36][hotplug, thermald, e

I have an otg cable (although I only use it in cmr). Does it not work with my kernel?

Crap lol I saw you mention needing to order a cable for OTG+charging (well I thought I did).

It it the y cable that you're needing maybe? Or did I just totally screw that up?

Sent from my HTC6435LVW using Xparent Red Tapatalk 2
 

crpalmer

Inactive Recognized Developer
Mar 25, 2011
2,999
8,280
Re: [Kernel] [Mar 16] crpalmer's [Linaro 4.7 -O3] [Linux 3.4.36][hotplug, thermald, e

Yeah, I said that I would need an otg y cable if there was any hope of getting otg with charging working. I ordered a super cheap cable that will eventually arrive from China. But, it might be awhile before I play with that (and likely will never get it working anyway...).
 
  • Like
Reactions: Zarboz

CharliesTheMan

Senior Member
Re: [Kernel] [Mar 16] crpalmer's [Linaro 4.7 -O3] [Linux 3.4.36][hotplug, thermald, e

Yeah, I said that I would need an otg y cable if there was any hope of getting otg with charging working. I ordered a super cheap cable that will eventually arrive from China. But, it might be awhile before I play with that (and likely will never get it working anyway...).

Ok im with you now, sorry about my confusion. I'm going to be ordering some soon since they take forever. I'll probably order several extra ones so if you're working with anybody on this that may need one let me know. It's the least I can do with all the work you guys put into this stuff.

Sent from my HTC6435LVW using Xparent Red Tapatalk 2
 

bsSkunkApe

Senior Member
Jan 15, 2009
194
27
Re: [Kernel] [Mar 16] crpalmer's [Linaro 4.7 -O3] [Linux 3.4.36][hotplug, thermald, e

I've been having some issue with the oc frequencies I've set not "sticking" on the last 2 or 3 releases. I'll set them and a few hours later the frequency will be back to 1.5 GHz. I run intellidemand @ 1.6 GHz. Any ideas? Anyone else? CPU tuning app doesn't seem to matter. Usually use kernel tuner though.

I kinda think it might be related to the governor resetting things because occasionally it will reset lower, like 1.1 GHz.

Sent from my HTC6435LVW using Tapatalk 2
 
Last edited:

phuckwithfire

Senior Member
Dec 31, 2010
181
40
SL,UT
Re: [Kernel] [Mar 16] crpalmer's [Linaro 4.7 -O3] [Linux 3.4.36][hotplug, thermald, e

If this had S2W, I'd be all over this kernel. From my experience, it's the most stable, and provides the best battery life.
 
  • Like
Reactions: seeingwhite

123421342

Senior Member
Nov 21, 2012
1,445
319
If this had S2W, I'd be all over this kernel. From my experience, it's the most stable, and provides the best battery life.

If you are on viper rom there is an option to wake by swiping from back to recent apps buttons. Kind of the same thing?

EDIT: nevermind it only unlocks it. If cpalmer is a mix of everything, can you include S2W from dsb's kernel?
 

phuckwithfire

Senior Member
Dec 31, 2010
181
40
SL,UT
Re: [Kernel] [Mar 16] crpalmer's [Linaro 4.7 -O3] [Linux 3.4.36][hotplug, thermald, e

If you are on viper rom there is an option to wake by swiping from back to recent apps buttons. Kind of the same thing?

EDIT: nevermind it only unlocks it. If cpalmer is a mix of everything, can you include S2W from dsb's kernel?

Yeah, and I'm on Newt's Sense 5 ROM. :p
 

crpalmer

Inactive Recognized Developer
Mar 25, 2011
2,999
8,280
Re: [Kernel] [Mar 16] crpalmer's [Linaro 4.7 -O3] [Linux 3.4.36][hotplug, thermald, e

I've been having some issue with the oc frequencies I've set not "sticking" on the last 2 or 3 releases. I'll set them and a few hours later the frequency will be back to 1.5 GHz. I run intellidemand @ 1.6 GHz. Any ideas? Anyone else? CPU tuning app doesn't seem to matter. Usually use kernel tuner though.

I kinda think it might be related to the governor resetting things because occasionally it will reset lower, like 1.1 GHz.

I felt like I was seeing something like that right around the time I switched back to ondemand. I saw it mostly when running benchmarks though. I can look and see what's going on but it was would help if you could give me a sequence of steps that reproduce the problem.
 

bsSkunkApe

Senior Member
Jan 15, 2009
194
27
Re: [Kernel] [Mar 16] crpalmer's [Linaro 4.7 -O3] [Linux 3.4.36][hotplug, thermald, e

I felt like I was seeing something like that right around the time I switched back to ondemand. I saw it mostly when running benchmarks though. I can look and see what's going on but it was would help if you could give me a sequence of steps that reproduce the problem.

Usually scales the clock back while playing a game. Could be heat related if it happens while benchmarking too. Although, it happened last night while I was sleeping. Woke up this morning and the clocks were back down to 1.5 GHz.

This may be related if your kernel shares any code with Zarboz's - It actually just happened to me on Beastmode 4.1 while gaming AND using intellidemand governor. It scaled me back to 1.1 GHz.
Seems to ONLY happen to me while using intellidemand on either kernel.

Sent from my HTC6435LVW using Tapatalk 2
 
Last edited:

Zarboz

Known Scammer
Mar 5, 2009
145
9,339
Denver
Re: [Kernel] [Mar 16] crpalmer's [Linaro 4.7 -O3] [Linux 3.4.36][hotplug, thermald, e

Usually scales the clock back while playing a game. Could be heat related if it happens while benchmarking too. Although, it happened last night while I was sleeping. Woke up this morning and the clocks were back down to 1.5 GHz.

This may be related if your kernel shares any code with Zarboz's - It actually just happened to me on Beastmode 4.1 while gaming AND using intellidemand governor. It scaled me back to 1.1 GHz.
Seems to ONLY happen to me while using intellidemand on either kernel.

Sent from my HTC6435LVW using Tapatalk 2
It's cuz we use fauxs intellidemand backport and it has a crew limiter built in
 
  • Like
Reactions: bsSkunkApe

bsSkunkApe

Senior Member
Jan 15, 2009
194
27
It's cuz we use fauxs intellidemand backport and it has a crew limiter built in

So is this basically how it works except with 4 cores? (copied from fauxs sensation kernel thread)

"Intellidemand Governor tweak:
Introducing Smart Core Management
Automatic offlining of 2nd CPU core while Screen is ON.
Scenarios:
1- While Screen is ON > 3 min, and average load of the CPU is < 35%, then CPU1 will be taken offline.
2- While Screen is On, if average CPU load > 35%, CPU1 will be Online and both CPUs max frequencies will be limited to 1.13 GHz Max
3- While Screen is On, After both CPUs' Max is limited to 1.13 GHz, when the average CPU load has dropped down to less than < 25%, then both CPUs Maxfreq will be restored to 1.51 GHz Max (then go back to scenario 1).
-- for 3D Games or GPU intensive apps, both CPUs's max frequencies will be restored to 1.51 GHz and both CPUs will be online."

And is there a way to tweak this to take into account the overclock settings from Kernel Tuner? Or will it eventually re-overclock the processor to say 1.6 GHz after a certain load/time?

P.S. faux123's CPU tuning app (search fauxclock in app store) looks really nice. I wonder if we could get "official" support for the DNA?
 
Last edited:

Zarboz

Known Scammer
Mar 5, 2009
145
9,339
Denver
So is this basically how it works except with 4 cores? (copied from fauxs sensation kernel thread)

"Intellidemand Governor tweak:
Introducing Smart Core Management
Automatic offlining of 2nd CPU core while Screen is ON.
Scenarios:
1- While Screen is ON > 3 min, and average load of the CPU is < 35%, then CPU1 will be taken offline.
2- While Screen is On, if average CPU load > 35%, CPU1 will be Online and both CPUs max frequencies will be limited to 1.13 GHz Max
3- While Screen is On, After both CPUs' Max is limited to 1.13 GHz, when the average CPU load has dropped down to less than < 25%, then both CPUs Maxfreq will be restored to 1.51 GHz Max (then go back to scenario 1).
-- for 3D Games or GPU intensive apps, both CPUs's max frequencies will be restored to 1.51 GHz and both CPUs will be online."

And is there a way to tweak this to take into account the overclock settings from Kernel Tuner? Or will it eventually re-overclock the processor to say 1.6 GHz after a certain load/time?

P.S. faux123's CPU tuning app (search fauxclock in app store) looks really nice. I wonder if we could get "official" support for the DNA?

i havent had time to play with it but i would assume thats how since crpalmer picked hte code from faux as did i
 
  • Like
Reactions: bsSkunkApe

crpalmer

Inactive Recognized Developer
Mar 25, 2011
2,999
8,280
So is this basically how it works except with 4 cores? (copied from fauxs sensation kernel thread)

"Intellidemand Governor tweak:
Introducing Smart Core Management
Automatic offlining of 2nd CPU core while Screen is ON.
Scenarios:
1- While Screen is ON > 3 min, and average load of the CPU is < 35%, then CPU1 will be taken offline.
2- While Screen is On, if average CPU load > 35%, CPU1 will be Online and both CPUs max frequencies will be limited to 1.13 GHz Max
3- While Screen is On, After both CPUs' Max is limited to 1.13 GHz, when the average CPU load has dropped down to less than < 25%, then both CPUs Maxfreq will be restored to 1.51 GHz Max (then go back to scenario 1).
-- for 3D Games or GPU intensive apps, both CPUs's max frequencies will be restored to 1.51 GHz and both CPUs will be online."

And is there a way to tweak this to take into account the overclock settings from Kernel Tuner? Or will it eventually re-overclock the processor to say 1.6 GHz after a certain load/time?

P.S. faux123's CPU tuning app (search fauxclock in app store) looks really nice. I wonder if we could get "official" support for the DNA?

Intellidemand shouldn't take CPUs on/off-line anymore. I believe that was from before faux123''s creation of intelli_plug to handle hot plugging (which I don't use, I wrote my own hot plug driver instead).

It looks like intellidemand has its own notion of max frequencies and doesn't play very nicely with overclocking (and I think that you're right that it gets confused with thermal throttling). I added improving that to my to-do list and in the meantime it might be good to avoid it if you want to overclock.
 

crpalmer

Inactive Recognized Developer
Mar 25, 2011
2,999
8,280
I'm trying to figure out why mpdecision and multicore power saving settings won't stick after reboot, where should I start looking to find what's resetting them upon reboot?

I'm not sure what you're doing... What are you setting and how are you setting it?

And, there is no mpdecision for this kernel. I disable HTC's mpdecision and instead use the hot-plug driver that I wrote instead.
 

Top Liked Posts

  • There are no posts matching your filters.
  • 59
    The goal of this kernel is above all stability with the secondary goals of increased performance and increased battery life. I use this phone for several hours a day for work and therefore it must be reliable. I am not focusing on providing a million options for governors, etc. In addition to those main goals of the kernel, I have an additional secondary goal of removing as much HTC code as possible from the kernel.

    This is based on the 2.04 kernel source release from HTC with a huge number of modifications. Thanks to faux123, showp, harsh, mdeejay, zarboz and dsb9938 whose kernels I have pulled some commits from.

    The unique features of this kernel are:

    New init.d scripts to allow some tweaking without needing any 3rd party apps
    * See the next post for details.

    Replaced HTC's mpdecision with a new custom hot-plug driver that I created:

    * This hot-plug driver is more aggressive about bring cores on and off-line to match the load on the system.
    * Bringing cores online earlier makes your phone more responsive / smooth.
    * Taking cores offline earlier improves battery life.
    * It ramps up very quickly on resume to avoid lag.

    Replace HTC's thermald with a new custom thermal driver that I created:

    * Unlike all other thermal drivers, it uses "trip-points" to let the phone tell the kernel when it is overheating. The other thermal drivers poll every X ms and read the temperature instead.
    * By using trip-points, there is 0 battery consumption unless the phone is overheating.
    * By using trip-points, there is an instant reaction to temperature changes.
    * It's probably nearly impossible to cause thermal shutdown without being in a desert!

    Replaced HTC's bluetooth drivers with Code Aurora Forums (CAF) version.

    Replaced HTC's lightsensor table with one that is more sensible and that matches what other devices use. If you have custom auto-brightness settings, you'll probably need to tweak them after installing this kernel.

    There are many additional changes to boost performance and battery life:

    * Linaro -O3 compiled (Linaro 4.8).
    * Overclocking from mdeejay's kernel.
    * Underclocking to 192MHz.
    * I disable tons of HTC debugging crap left enabled and needlessly consuming battery.
    * Improvements to the core locking code of the kernel.
    * Patches that transform traditional locks into RCU backed data structures.
    * CAF version of the ondemand and conservative governors.
    * hsic wakelock changes from dsb9938's kernel.
    * CAF changes to power management to sleep faster and waste less CPU during suspend.
    * Improved code for moving data to/from user-space and manipulating strings within the kernel.

    Other features:

    * Include all mainline Linux changes to keep up-to-date on bug fixes.
    * Voltage control (faux123) to allow user-space under-volting.
    * BFQ I/O scheduler.
    * CAF lowmemorykiller.
    * Force fast charge.

    Links

    A link to each version is included in the changelog entry. Scroll down to the changelog to download the latest version.

    Source (GitHub):
    * Kernel source
    * Merging of upstream into the stock kernel
    * Build tools

    Installation Instructions:

    If you are S-OFF you can flash the update.zip in recovery.

    If you are S-ON, then after you flash the update.zip in recovery then, while still in recovery, you must run

    Code:
    adb pull /tmp/boot.img
    <reboot into bootloader>
    fastboot flash boot boot.img

    Changelog:

    Version 2.0.41: August 25, 2013: Linux 3.4.58, HTC colour "enhancement"
    * Merged Linux versions 3.4.53 - 3.4.58
    * Added the ability to enable / disable the HTC colour enhancement (this lets you see if you like it or not)

    Version 2.0.38: July 7, 2013: Linux 3.4.52
    * Linux version 3.4.51 / 52 merged in
    * Reverted a small change to the PWM values used for the display (it wasn't giving any value so why change ti)

    Version 2.0.34: June 24, 2013: colour enhancement, fixes, debug messages
    * Toned done yet more HTC debugging messages
    * Enable UTF-8 codepage support for Windows file-systems
    * Fix error in HTC's light-sensor calibration table (overflows the 16-bit number they are using)
    * Avoid buffer overflow in acdb driver
    * Remove HTC's colour enhancement gamma correction (beaups)

    Version 2.0.32: June 15, 2013: linux 3.4.49, scheduler & mutex improvements
    * Linux 3.4.49
    * Three scheduler performance improvements
    * Move to more standard and slightly faster mutex implementation

    Version 2.0.30: June 8, 2013: linux 3.4.48, small fixes
    * Linux 3.4.48
    * Fix CVE-2013-2595
    * Decrease latency in cpufreq frequency changes

    Version 2.0.27: May 26, 2013: init.d governor, 3.4.47
    * Ability to specify the cpufreq governor at boot time (see second post).
    * Linux 3.4.47
    * Remove an annoying HTC debugging message

    Version 2.0.26: May 23, 2013: init.d tweaks, 3.4.46, no default undervolting
    * Added PVS information to /proc/cpuinfo in case you wanted to knoiw what it is for your phone.
    * Linux upstream version 3.4.46
    * Improve how I set the CPU frequences to safe levels for boot without having to reset them every time a core is hot-plugged in.
    * New init.d scripts for some common tweaks (see post #2).

    Version 2.0.23: May 13, 2013: Lightsensor fix, 3.4.45, faster freq. changes:
    * Fix an error transcribing the lightsensor ranges into the source.
    * Update to Linux 3.4.45
    * cpufreq: use a high priority to target new frequencies to allow faster changes under load

    Version 2.0.20: May 12, 2013: Lightsensor, 3.4.44, undervolt for "fast":
    * Use a new lightsensor table to get a more granular light reading If you have custom auto-brightness settings, you'll probably need to tweak them after installing this kernel.
    * Update to Linux 3.4.44
    * Undervolted for devices binned "fast" by -100mV.
    * CAF fix for cpufreq driver.

    Version 2.0.17: May 7, 2013: Linaro 4.8.0 build, minor CAF fixes:
    * Moved to updated Linaro 4.8.0 based toolchain (theoretically faster, less battery likely it's unnoticeable)
    * CAF: change boot-up order for cpufreq
    * CAF BT: recover from a hardware error by resetting the device

    Version 2.0.15: May 2, 2013: boot hang fix, 3.4.43, CPU frequencies, brightness, misc fixes:
    * Linux 3.4.43
    * Small fixes from CAF (bluetooth, usb)
    * Restore the CPU frequences/voltages from 1.x.y kernels (previously I was using HTC's new tables)
    * simple_plug: keep cores online during boot
    * use the correct brightness ranges for our display (HTC cut off the lowest brightnesses).
    * fix a race condition on boot with the binder kernel services

    Version 2.0.9: April 23, 2013: 3.4.41 and small fixes:
    * Linux 3.4.41
    * Small fixes from CAF
    * Clean up some more HTC crap in the kernel

    Version 2.0.6: April 17, 2013: boot changes, linux 3.4.40:
    * Linux 3.4.40 (upstream).
    * Limit CPU speeds during boot to stock speeds.
    * Enable the thermal driver 5 seconds into the boot (previously was 30 seconds).
    * Small changes to the ramdisk from the 2.04 update (I forgot these before).

    Version 2.0.3: April 15, 2013: on_demand, battery, HTC spew:
    * HTC insists on adding more and more debugging messages to the kernel log. Clean these up.
    * OnDemand: revert a CAF change I made and disable io_is_busy.
    * Remove HTC's over-volting for CPUs binned anything other than nominal.
    * defconfig changes to ease building the kernel for CM10.1 (no you can't use this one for CM10.1!).

    Version 2.0.0: April 11, 2013: 2.04 (OTA) source drop:
    * Updated to Linux 3.4.39
    * Updated to HTC's release of 2.04 source
    * cgroup permissions fix
    * Otherwise the same as 1.2.6
    * Note: After running this for a day, I feel like the battery is draining faster and the phone is hotter than it should be. I'm looking into that.

    Changelog from 1.2.x


    Version 1.2.6: April 4, 2013: ramdisk fix, lowmemorykiller, hsic wakelocks:

    * Fix a problem where the ramdisk was no longer disabling mpdecision and thermald. This issue causes a very minor additional battery drain that has now be fixed (Thanks t1gartist!).
    * CAF updates to lowmemorykiller.
    * Reapply elkay's HSIC fixes by pulling the real commits from CAF (instead of his hand copied commits) which fixes two problems in his commits.

    1.2.2: April 1, 2013: linux 3.4.38, lag fixes, bluetooth drivers, cleanup:

    * Undo some dubious commits (or extra code included in unrelated commits, what I meant by "early mistakes"). I reexamined every commit in the kernel to decide whether to keep it or remove it.
    * Bluetooth drivers are the current CAF msm-3.4 drivers.
    * Additional CPU speed and governor information added in /proc/cpuinfo.
    * Cleaner patching to upstream linux (see my github repo for the clean upstream patching).
    * Linaro -O3 compilation was redone from scratch because there were some problems found by kern3l in the original patches I pulled, I wanted to ensure that there were no other problems so I redid the work myself.


    Changelog from the 1.0.x series:


    1.0.27: Mar 25, 2013: thermald, simple_plug

    * Make the previous changes to simple_plug less aggressive about turning cores back off when applications force them online. We now detect that this has occurred and give the application 2 minutes to be in charge before we force the state back to what we want.
    * Change thermald default throttling to be slightly less strict.

    1.0.25: Mar 21, 2013: Linux 3.4.37, simple_plug, performance

    * Linux 3.4.37
    * simple_plug: add a verify mode (every 5 seconds => almost 0 cost) that fixes the state when apps bring cores on/off-line (e.g. kernel tuner).
    * rwsem performance improvements
    * CAF improvements (correctness, performance) of the power management layer

    1.0.21: Mar 16, 2013: Linux 3.4.36

    * Linux 3.4.36
    * Small bug fixes from CAF

    1.0.18: Mar 7, 2013: Linux 3.4.35

    * Linux 3.4.35

    1.0.17: Mar 4, 2013: Linux 3.4.34, Linaro 4.7-2013.02, thermald fix

    * Linux 3.4.34.
    * Linaro 4.7: stopped using 4.8 beta builds due to stability fears and lack of apparent benefit from it. The latest 4.7 drop back-ports some optimizations anyway.
    * lowmemorykiller: switch to the CAF version of the low memory killer.
    * Fixed several bugs in HTC's thermal driver that could cause the termal driver to miss thermal events.

    1.0.15: Feb 26, 2013: Battery optimization, performance, thermal & hotplug improvements

    * governor: make ondemand the default governor
    * GPU: Very minor GPU overclock to 487MHz (from mdeejay).
    * msm_thermal: react better when temperature decreases.
    * simple_plug: be slightly less aggressive about bringing cores online.
    * New suspend mode PM_SUSPEND_FREEZE
    * Oprimization for RWSEM lock handoffs.
    * RCU locking in cpufreq!
    * Disable more HTC debugging code.

    1.0.11: Feb 22, 2013: Battery optimizations, Linaro 4.8 build, update.zip format

    * Disable HTC's PNP power manager and adaptive policy services (used for thermald / mpdecision which are already disabled).
    * Turn off all the kernel code that was polling to compute the state needed for thermald / mpdecision.
    * Turn off a bunch of HTC statistic collection and debugging that isn't needed and wastes battery.
    * Linux 3.4.33: fixes a kernel memory corruption/hang in all 3.0 and 3.4 kernels
    * Sparkco's 4.8 Linaro build is now being used to compile the kernel
    * Moved to update.zip format with less commonly used modules moved to loadable modules.

    1.0.8: Feb 19, 2013: Switch to different OC values

    * Now using mdeejay's over/unclocking (hopefully solving the L2 cache corruption panic).
    * thermal driver is less aggressive about throttling the phone with an additional early step down to stock speed
    (50C => 1.5GHz, 75C => 1.3GHz, 83C => 918MHz, 90C => 384MHz).
    * Linux 3.4.32 (although no changes that would affect our phone).

    1.0.7: Feb 15, 2013: thermal driver no longer polls for state

    * Linux 3.4.31.
    * Now using the 2013-01 build of the Linaro toolchain.
    * Major rewrite of the thermal driver to remove polling (now uses essentially no power).
    * Tweaks to the hot-plug driver to reduce CPU consumed to reduce power consumed.

    1.0.5: miscellaneous optimizations

    * Optimization: use optimized memcpy for user-space copies
    * Update to linux 3.4.30
    * Tons more cleansing of excessive debugging output
    * Use RCU_FAST_NO_HZ as caf claims to have found that this improves battery life
    * More linaro -O3 fixes from kern3l via dsb

    1.0.2

    * cm3629 driver, removed power button pocket check (sounds like a good idea, doesn't work and is a likely candidate for an infrequent sensor drain coming from the proximity sensor not turning off).
    * cm3629 remove some unused functionality.
    * Two small fixes from kern3l via dsb9938's kernel.
    * clean some log messages.

    1.0.0

    * Merge linux 3.4.29
    * simple_plug: a new CPU hot-plug driver (default)
    * msm_thermal: a new thermal throttling driver (default)
    * faux123's intelli_plug (disabled by default)
    * faux123's intellidemand governor (default)
    * disable mpdecision and thermald in initrd
    * dsb9938's overclocking tables, GPU fix and more -O3 changes
    * optimizations/fixes from faux123's mako kernel
    * Based on elkay's LK kernel which is based on dsb9938's kernel.
    * Includes all elkay's HSIC fixes, but nothing beyond that.
    * Linaro -O3 compilation (zarboz) and other compiler flags (dsb9938).
    * Disabled remote assistance because that just creeps me out.
    * NTFS and CIFS.
    * Various optimizations and improvements (faux123's mako kernel, similar to dsb9938's pulls from there).
    * Force fast-charge (dsb9938).
    * Voltage control (faux123).
    * Latest OnDemand and Interactive governors from faux123's mako kernel.
    * Large set of scheduler fixes / improvements (faux123).
    * Underclocking (but not overclocking right now) to 192 MHz.
    * BFQ I/O scheduler (default).
    * Cleaned up debugging to make the kmsg more useful.


    FAQ

    sweep2wake: I have no plans to add that to this kernel at this time.
    22
    FAQs

    init.d tweaks

    I really like Zarboz's goal of trying to get rid of the need for 3rd party apps to make the common changes that we want to make to some of the configurable parameters of the kernel. I created some scripts that run on boot (init.d) because I install my kernel so many times that I would go insane if I had to use an installer. By using these scripts and configuration files on the sdcard, I can just configure it once and keep installing away to my heart's content.

    After installing this kernel, there will be:

    /system/etc/init.d/99crpalmer

    run at boot, even if you switch to another kernel. It is safe to leave this file there and to let it run as it only makes changes if the kernel contains "crpalmer" in the version.

    The tweaks are:

    CPU Frequencies
    * Frequencies loaded from /sdcard/crpalmer-cpufreq-min and /sdcard/crpalmer-cpufreq-max
    * Governor loaded from /sdcard/crpalmer-cpufreq-governor
    * If you specify either or both of these frequencies, it will lock down all of the CPU frequency controls. I had to do this because HTC overrides them in a script that is run very late in the boot process (thanks HTC!).
    * E.g. adb shell su -c "echo 192000 > /sdcard/crpalmer-cpufreq-min"
    * E.g. adb shell su -c "echo 1728000 > /sdcard/crpalmer-cpufreq-max"
    * E.g. adb shell su -c "echo interactive > /sdcard/crpalmer-cpufreq-governor"

    Undervolting
    * + or - value loaded from /sdcard/crplamer-uv
    * The undervolting in 2.0.23 for FAST binned CPUs would be specified as:
    * E.g. adb shell su -c "echo -100 > /sdcard/crpalmer-uv"

    Lightsensor
    * My light sensor changes didn't sound like they worked well for everyone. If you don't like them you can disable them by:
    * E.g. adb shell touch /sdcard/crpalmer-stock-lightsensor

    HTC Colour "Enhancement"
    * If this file is present then the stock colour "enhancement" will be used, otherwise it will be disabled.
    * Introduced in kernel 2.0.41.
    ** E.g. adb shell touch /sdcard/crpalmer-color-enhancement

    My WIFI Won't Turn On

    If your WIFI won't turn on then the most likely cause is that either you didn't flash the boot.img (e.g. not S-OFF) or your modules don't match the kernel. To figure out what's wrong, first boot the ROM after having installed my kernel. Second, verify that you are running my kernel by running

    adb shell cat /proc/version

    and seeing that it says crpalmer in (it should match the version that you think you installed, but at least saying crpalmer is a good start). Then do:

    adb shell dmesg -c
    (turn on wifi)
    adb shell dmesg

    and look for an error that says crpalmer in it (something like a module version mismatch error). If you see that, it should tell you the version number of the modules that are installed and the version of the kernel.
    14
    New kernel released. The most important change is that I believe I've fixed the problem that some people are experiencing where boots sometimes hang. See my previous post for more details about what I think was causing it. The update is:

    Version 2.0.15: May 2, 2013: boot hang fix, 3.4.43, CPU frequencies, brightness, misc fixes:
    * Linux 3.4.43
    * Small fixes from CAF (bluetooth, usb)
    * Restore the CPU frequences/voltages from 1.x.y kernels (previously I was using HTC's new tables)
    * simple_plug: keep cores online during boot
    * use the correct brightness ranges for our display (HTC cut off the lowest brightnesses).
    * fix a race condition on boot with the binder kernel services
    14
    New version:

    Version 2.0.17: May 7, 2013: Linaro 4.8.0 build, minor CAF fixes:
    * Moved to updated Linaro 4.8.0 based toolchain (theoretically faster, less battery likely it's unnoticeable)
    * CAF: change boot-up order for cpufreq
    * CAF BT: recover from a hardware error by resetting the device
    13
    New version updated in the OP / test kernel post.

    1.0.15: Feb 26, 2013: Battery optimization, performance, thermal & hotplug improvements

    * governor: make ondemand the default governor
    * GPU: Very minor GPU overclock to 487MHz (from mdeejay).
    * msm_thermal: react better when temperature decreases.
    * simple_plug: be slightly less aggressive about bringing cores online.
    * New suspend mode PM_SUSPEND_FREEZE
    * Oprimization for RWSEM lock handoffs.
    * RCU locking in cpufreq!
    * Disable more HTC debugging code.

    And the BT test version also has

    * Replaced all HTC BT drivers with CAF drivers (these have a few fixes on top of the standard Linux drivers).
    * Enabled additional HID devices (USB & BT)