[Nexus 6  Original Android Development] purian23:
FAQs:

Based on 5.1 Stock Kernel - It should work on all AOSP & CM ROMS

Disabled forced encryption - Meaning if your encrypted you'll stay that way, if you aren't, you'll stay that way

CPU Interactive Governor - Conservative/OnDemand/Userspace/Powersave/Performance Available

CFQ I/O - Deadline/Noop/Bfq/Row/FIOPS Available

Overclocking now available up to 3GHz - Must use Aroma OC Zip above.

F2FS Support - Find out how to enable this here!

KCal Colors by Savoca

Full Wake Gestures by flar2

Double Tap to Wake / Sweep to Sleep / Sweep to Wake

New stock setting - 5.1 throttles at 40% and again at 20% battery life - See the dev's details below on how to change this

[MENTION=2632235]bbedward[/MENTION] Regarding 40-20% Battery Throttle

Typically in the old days (which is the last time I was around) this type of thing would be in a cpufreq kernel driver using methods from the battery driver, and possibly allowing configurability through a basic sysfs interface. However, this is not the old days.

I inquired to my good friend imoseyon (I say good friend, he'd probably say "friend? you mean that crazy guy who i talked to once and now he keeps asking if I want to hang out?")

It appears that this battery change goes through the msm_thermal driver through a userspace process. The sad news is that there isn't a way to differentiate between thermal-related calls and these battery-related calls at the kernel level.

BUT,

this specific behavior can be disabled in the userspace (just not in the kernel space) - You will need root access (or you could make this change through twrp)

I will point you to this file (Which you should make a backup of before making any changes to it):

/system/etc/thermal-engine-shamu.conf

You can either edit it in something like root explorer, or pull it down through adb like this:

# adb pull /system/etc/thermal-engine-shamu.conf

Open it in your editor of choice (on windows I suggest you use something that supports unix line endings, like notepad++)

Point yourself to BAT-SOC-CPUFREQ near the top of the file

[BAT-SOC-CPUFREQ]
algo_type monitor
sensor soc
sampling 5000
thresholds 60 80
thresholds_clr 59 79
actions cpu cpu
action_info 2265600 1728000

Interpreting this is pretty straight forward:

- sampling 5000 : I guess how often (probably in ms) that it compares battery % to thresholds and thresholds_clr

- thresholds 60 80: defines two thresholds in which to take actions

- thresholds_clr 59 79: defines two thresholds in which to clear actions

- actions cpu cpu: the action to take (like a method) when thresholds are met

- action_info 2265600 1728000: action parameters that are apparently used to change scaling_max_freq

Read from thresholds down like a column

The bit that tells it to reduce frequency to 2.26Ghz at 40% and back to 2.6 at 41% is this:

thresholds 60
thresholds_clr 59
actions cpu
action_info 2265600

Where thresholds 60 refers to 40% battery by apparently % discharged (100-60 = 40%). Similarly thresholds_clr 59 (100 - 59 = 41%)

Anyway lets you say you want to throttle to 2.26GHz at 20% and at 21%+ you want to be back to normal scaling_max_freq (2.6Ghz stock) You should change it to look like this:

[BAT-SOC-CPUFREQ]
algo_type monitor
sensor soc
sampling 5000
thresholds 80
thresholds_clr 79
actions cpu
action_info 2265600

Save the file thermal-engine-shamu.conf and push back to device (or in root explorer you are already there)

# adb remount rw /system
# adb push thermal-engine-shamu.conf /system/etc/
# adb remount ro /system

Changes will probably take effect after you restart the thermal-engine service (if not, then do a reboot).

# adb shell stop thermal-engine
# adb shell start thermal-engine

Also notice the exact same applies for GPU frequency throttling and HOTPLUGGING due to battery

On stock 5.1 - Here is everything that happens and can be understood from the default thermal-engine-shamu.conf (related to battery):

CPU is throttled to scaling_max_freq 2.26GHz @ 40% battery

CPU is throttled to scaling_max_freq 1.7GHz @ 20% battery

GPU is throttled to 500MHz @ 45% battery

GPU is throttled to 389MHz @ 10% battery

GPU is throttled to 300MHz @ 5% battery

CPU3 (core #4) is removed (hot-unplugged) @ 15% Battery

CPU2 (Core #3) is removed (hot-unplugged) @ 8% Battery

Hotplug and GPU throttle behavior can be changed in the same thermal-engine-shamu.conf on the subsequent lines. (Exact same logic as described above, but actions/methods are different OFC)

[BAT-SOC-HOTPLUG]
algo_type monitor
sensor soc
sampling 5000
thresholds 85 92
thresholds_clr 84 91
actions hotplug_3 hotplug_2
action_info 1 1

[BAT-SOC-GPU]
algo_type monitor
sensor soc
sampling 5000
thresholds 55 90 95
thresholds_clr 54 89 94
actions gpu gpu gpu
action_info 500000000 389000000 300000000

So this is actually quite an easy thing to adjust. I know that franco/imoseyon have taken further actions to (and are currently working on):

Prevent this sort of userspace changes from going through msm_thermal driver, by rewriting the driver to only deal with thermal stuff (basically - and probably as it should do to begin with). Apparently this is a little problematic because QC/Moto/Goog have used this driver and its ioctl to funnel other important stuff through (that isn't thermal-related but is still important)

To lock specific msm_thermal userspace processes from making changes to cpufreq

But there are other factors in play there that complicate things.

Disabling the specific behavior of throttling CPU+GPU and disabling hotplugging at certain battery percentages is extremely easy through that configuration file.

Edit: More Knowledge Added - 4/7/15

Each row represents an array essentially, but if you specify something like 3 values for thresholds you need to specify 3 threshold_clr and 3 actions and 3 action parameters.

It's hard for me to say how the thermal engine behaves if you specify something wrong. Ideally you would assume that the parser is smart enough to handle things done incorrectly - and that the service itself is smart enough to have fallback for critical things if they are missing (I don't trust QC enough to assume that's the case), but it's impossible to say without guessing unless we saw the thermal-engine source (this is the service that's in the userspace - not in the kernel). Remember this is a qualcomm piece of software, and because /system is always mounted read-only in android (unless you access it with root access or through a custom recovery) they possibly didn't spend a lot of time working out error handling with respect to user error - because it's not something a user would ordinarily change.

Other Stuff:

Moto is cheap: (and so is everyone else). When it comes to a power supply there's more to it than just a battery - there's regulators, surge-protecting capacitors, protecting diodes, current sensors, etc. Each component in the device doesn't care about these things - they just draw a certain current. The cheapness comes in to play in that Motorola or any manufacturer is not going to bother building a power supply that's more than needed. In the case of the nexus 6 it appears that what they have is "just enough"

Battery efficiency degrades as it discharges. This certainly varies from battery to battery, but the faster the battery is discharging - the less ability it has to provide the required charge to power the device

Recall that there was a huge slurry of random reboot issues reported after the Nexus 6 launch. Something that occured apparently entirely at random, that didn't result from any sort of kernel panic - apparently simply the battery couldn't supply current demanded, so some current-limiting protection or a diode went into reverse bias and just cut the power (I can't say exactly because I didn't design the device).

The issue of unexplained random-rebooting seems to be almost entirely resolved in 5.1. The likely reason: the addition to the thermal-config-shamu file that restricts the maximum frequency, at 40% battery, to ~2.2GHz.

In short, it doesn't matter where you change this behavior. Changing the configuration file that directly communicates to the kernel ioctl is just as good as any kernel solution. The problem with a kernel solution is it goes through the same userspace process as thermal-related throttling. There are ways to block it in the kernel, but it is not configurable and not adjustable. It's more of an on/off type of thing.

Every device is different (different manufacturing tolerances). The majority of users probably had no issues with reboots or supply issues when they didn't have any throttling (until ~20%) on 5.0. But for the ones that did the only thing they could be told was to RMA their device.

I personally think google did the throttle at 40% to make up for a crummy power supply, rather than to gain an extra few minutes of battery life.

Also, there is no active hotplugging on 5.1 (Except for at something like 15% battery and while the device is sleeping - but not ACTIVE hotplugging). This could also be part of the reason why they added the 40% throttle, because when the cores are online all the time there's going to be more active draw from the power supply.

Interested in building ZenKernel?

Using GIT Differently

You don't need permission to fork, build, modify zen. Nor do you need permission to bundle it in your rom.

BUT, there has been some confusion in the way I handle my git tree I thought I would help explain here.

I handle all of my kernel-related GIT affairs very differently from anybody else you've seen, probably:

Everything is based off of stock msm/android-msm-shamu-3.10-lollipop-mr1 (Or newer revs as they come available)

When there is a major revision update to the base (android-msm-shamu-3.10-lollipop-mr2 or something), I will avoid rebasing the branch and create a new branch each (so there will be a BFS and a BFS_mr2 or something)

Every change from the stock kernel lives on it's own,independent branch. There's BFS, kcal, fsync, f2fs/ext4_upstream, kexec-hardboot, usb_fastcharge, etc, etc.)

I merge all these independent branches into the master branch, which is how I come up with the "Zen-Kernel" that includes all of them (git merge BFS; git merge kcal; git merge wake_gestures_ex, etc, etc.)

This means forking zen is not traditional, but it's a good thing!

What do I do if I want to pull something from Zen kernel into my tree?:

Add the ZenKernel_Shamu remote to your local tree (git remote add zen https://github.com/bbedward/ZenKernel_Shamu.git)

Fetch the newest zen changes (git fetch zen)

Pull the change you want, for example to pull BFS into your local tree: git pull zen BFS

Whenever you want to pull an update, git fetch zen; git pull zen BFS

These branches are all based on the STOCK msm/android-msm-shamu tree. So if you pull in BFS or kcal you will not get anything new except BFS or kcal. No other unwanted things will be pulled. Some branches depend on each other (ext4_upstream depends on mm_upstream for example), so if you pull in ext4_upstream you will also get the contents of mm_upstream, and so forth.

What do I do if I want to fork the entire zen kernel exactly as it is?

Well you can do it the old way as you always have. But I change some other stuff for internal purposes you may want to change (in the zen branch), such as the ZEN_INFO_SYSFS_INTERFACE is probably irrelevant to you and ZEN_INFO_VERSION_CODE only represents an integer value with the extra version "-zen" statically defined in the Makefile. You may want to change these things or revert them and just append something in the CONFIG_LOCALVERSION such as "-MyKernel_5.1" or something.