[HTC Sensation] Cayniarb:
First, let me put out a HUGE thanks to BrokenWall for all his testing and morfic for helping me pour over code for hours and catching things I missed.

The changes I have made to this point are, honestly, fairly minor and I was kinda surprised it worked at all. It is a couple tweaks from the Code Aurora Forum (Qualcomm) and some changes of my own (largely with CAF influence - I'm not trying to claim inception here). My source is here for anyone to grab. The repo will build for both the e3d and sensation -- but as I only have a e3d, that's why things are limited on my end to 2.3.3 (the kernel changes in the e3d were more substantial with the version bump than for the sensation, so the 2.3.3 source isn't booting 2.3.4 ROMs at all). I can look more into that issue at some point, but it is really not the priority here... The commits should apply to one with the pyramid 2.3.4 updates without any issues.

So far, the issue of SetCPU *not* imposing the user-selected freq_min and freq_max on cpu1 appears to be solved. Hence, you can scale the min/max to 1512 (or anything else) and at whatever point cpu1 comes online, it will run at that freq. Furthermore, if you manually set the freq_min and freq_max for cpu1 (using echo), those values will persist after cpu1 returns from idle.

The remaining issue at this point is that SetCPU is still *not* imposing the user-selected freq_governor on cpu1. Worse still, manually setting the governor (using echo) does not stick after cpu1 returns from idle -- it will default back to ondemand.

Additionally, I am not sure that I accept the premise that only the ondemand governor is properly set up for this chipset. The way that it is *supposed* to work (and I am by no means confirming that it *is* doing this) is that each cpu is assigned it's own policy information -- freq_min, freq_max, governor, etc. As such, the governors themselves should not need any modifications, and users *should* be able to set different governors for each core. I am still looking more into this, and my understanding may well not be accurate.

There is also the issue of the fact that cpu1 idles at all. This is not a function that I intend to remove. It may be worth it to decrease whatever load threshold triggers cpu1 to come online, but keeping it on all the time would be a really unnecessary power drain. Even other dual core ARM chips without asynchronicity (read: all non-Snapdragon dual-core ARM chips) idle cpu1 under light load. The difference there is that, for those, when cpu1 comes back online it is locked to whatever cpu0 is doing. Again, I would not recommend trying to mimic that functionality here -- asynchronicity is a huge advantage of the snapdragon processor. Furthermore, the operating system that is available is *not* optimized for dual core processors at all -- so, when cpu1 does come online, its only ever useful when cpu0 is taxed to the max in the first place (cpu1 essentially acts to extend the power of cpu0 rather than distributing the task equally across multiple cores). The will change with ICS (or at least that is the assumption). Applications themselves also need to be optimized for multi-core setups -- so, the bottom line is that it will still be a while before the real power of multi-core processing is realized on Android.

If you want to help out with this (with testing or code) please hit me up in my IRC channel. You can prolly also get test builds from me there...