I've implemented a generic cpufreq range regulation based on a previous work proposed by newmail here.
With "generic" I mean that it can work with any cpufreq governor, the whole logic is implemented in the core cpufreq subsystem using early_suspend hooks.
How does it work?
Without this patch set applied, using for example the ondemand governor, the cpu frequency ranges always between 200MHz to 1200MHz (without overclocking/underclocking the device) that are the min and the max frequency supported by the processor.
With this patch set applied the frequency is regulated in the range [min ... max/2] when the screen is off and [max/2 ... max] when the screen is on. If the cpu doesn't support exactly max/2 an appropriate frequency is chosen, as close as possible to the theoretical value (for the GT-I9100 it's 500MHz).
Advantages
This forces background apps to always run at lower frequencies, reducing the power consumption when the phone is not used interactively, and, at the same time, boost the cpu at max speed when used interactively. IOW, it's faster and it drains more battery life when the phone is used interactively, and the battery last longer when the phone runs background tasks.
An additional side-effect using 'ondemand' is that the heuristic always works with shorter ranges, so the cpu ramps up / down faster to the target frequency. The feeling is that everything seems smoother and more responsive. I only tested ondemand for now, but the same logic should apply to the other available governors as well.
Source code
I like to post source code, more than binaries, so in attach you can find only the patches that implement this feature. The patches can be applied on top of the original Samsung kernel - Update2. These patches are also included in my kernel tree on github.
Patch set description
The 1st patch 0001-cpufreq-frequency-regulation-based-on-screen-on-off-.patch, implements the dynamic cpufreq range regulation logic. This patch is totally generic, so theoretically you can use it with any Android device.
The 2nd patch 0002-cpufreq-do-not-forget-min-max-clock-frequency-on-cpu.patch is required by multicore systems with cpu hotplugging enabled. It allows to resume the right frequency range on a cpu when it goes offline and then back online.
The 3rd patch 0003-mach-s5pv310-cpufreq-800MHz-sleep-death-fix.patch is specific for the GT-I9100 hardware. It's the 800MHz sleep death fix: the hardware requires to suspend the cpu always at 800MHz, so with the dynamic cpufreq range regulation this is always needed, independently of the particular governor you're using.
The 4th patch 0004-pm-hotplug-do-not-consider-frequency-in-the-cpu-hotp.patch is specific for the GT-I9100 hardware. It makes the cpu hotplug heuristic independent of the cpu frequency; this is required to properly offline the secondary cpu when screen is on _and_ the dynamic cpufreq range regulation patch is applied.
The 5th patch 0005-pm-hotplug-disable-secondary-cpu-auto-hotplug-when-s.patch is specific for the GT-I9100 hardware. It always sets the secondary cpu offline when the screen is off.
The 6th patch 0006-mach-s5pv310-cpufreq-smooth-scaling.patch is specific for the GT-I9100 hardware. It is needed to fix a wrong behavior with governors that run at a fixed frequency (like 'performance', 'powersave' or 'userspace'). Basically, the low-level driver doesn't allow to switch from a very low frequency to a very high frequency, so in some cases the actual cpu frequency can be different than the frequency requested by the higher layers. This fix introduces a smooth scaling mechanism in the low-level driver that allows to switch to the target frequency incrementally in multiple steps.
Everything is transparent to the higher layers, so in this way we are sure that the actual cpu frequency is always the same value requested by the cpufreq governor. See also the commit in my kernel on github.
NOTE: the last patch (0006-mach-s5pv310-cpufreq-smooth-scaling.patch) is a fix for the low-level cpufreq driver of the GT-I9100 that should be _always_ applied IMHO, even without the dynamic cpufreq range regulation patch.
ChangeLog
v2 -> v3
fix a wrong behavior (cpu stuck at 800MHz) with fixed-frequency governors (i.e, performance, powersave, or userspace).
v1 -> v2
fix: allow to offline the secondary cpu when screen is on
always disable the secondary cpu when screen is off
Looks promising, hope it works well, will sure try it out, but some kernels has almost the same built in...
Great work!
Uploaded a new version of the dynamic frequency range regulation patch.
There're two additional patches in the patch set:
The first patch (0004) is a fix that allows to properly offline the secondary cpu when screen is on.
The other patch (0005) applies the same concept of the dynamic frequency range regulation to the secondary cpu hotplugging: when the screen is off also the secondary cpu (cpu1) is kept offline, when the screen is on the secondary cpu is turned on/off depending on the load on the primary cpu (cpu0).
thanks a lot for your hard work.apply patch without problem, good for battery life.
a developper like me is very happy to have a master developper like you.
thank you very much it looks cool.
a noob question, how will I apply this zip just CWM or what?
arighi: one thing i don't like the freq min is set to 500 mhz . it is too high.
edit:excuse when screen off the freq reach 200 mhz .it's ok perfect and cpu1 is well disable when screen off
edit2: yay1974 ,apply all patch in the order they are all necessary. but this patch is only for developper who compil his kernel.
pixiebob said:
arighi: one thing i don't like the freq min is set to 500 mhz . it is too high.
edit:excuse when screen off the freq reach 200 mhz .it's ok perfect and cpu1 is well disable when screen off
edit2: yay1974 ,apply all patch in the order they are all necessary. but this patch is only for developper who compil his kernel.
Click to expand...
Click to collapse
hmm i see i wish you had a cwm flashable file for this to apply
yay1974: if you wish you can try my own kernel i have apply patch from this thread and some other good stuff(like sched autogroup, etc...).i obtain more 4000 quadrant:
flash with odin or heimdall:
http://www.megaupload.com/?d=TCQFKISK
commit:
https://github.com/pixiebob/pixie-kernel/commits/master
pixiebob said:
yay1974: if you wish you can try my own kernel i have apply patch from this thread and some other good stuff(like sched autogroup, etc...).i obtain more 4000 quadrant:
Click to expand...
Click to collapse
pixiebob, I see you've applied also the CONFIG_FILE_SYNC_DISABLE patch. Be careful to enable this, it may cause loss of data if applications crash in unsafe ways. Probably if you run quadrant in a kernel with CONFIG_FILE_SYNC_DISABLE=y you'll get about 4500-4600. But actually you're just cheating.
what kernels have this built in (if any)
cheers
@arighi great job on the patches... looking forward to more cool stuff from you.
Great patch, thank you.
pongster said:
@arighi great job on the patches... looking forward to more cool stuff from you.
Click to expand...
Click to collapse
Hey pongster, you are always hanging around here!! When can we see your rom running all tweaks and fixes... looking forward to it...
Sent from my GT-I9100
arighi said:
pixiebob, I see you've applied also the CONFIG_FILE_SYNC_DISABLE patch. Be careful to enable this, it may cause loss of data if applications crash in unsafe ways. Probably if you run quadrant in a kernel with CONFIG_FILE_SYNC_DISABLE=y you'll get about 4500-4600. But actually you're just cheating.
Click to expand...
Click to collapse
thanks i will be careful but until by now i didn't have crash
great patch! I was also working on something similar but your patch is so complete that I gave up working and used yours
just a perfect patch!
pongster said:
@arighi great job on the patches... looking forward to more cool stuff from you.
Click to expand...
Click to collapse
Hey Sar ! You here ?!? .. didnt know ... cook some MIUI stuff dude ... I'll help out
v-b-n said:
Hey Sar ! You here ?!? .. didnt know ... cook some MIUI stuff dude ... I'll help out
Click to expand...
Click to collapse
cooking something up... not a MIUI based one though...
PM me
arighi said:
I've implemented a generic cpufreq range regulation based on a previous work proposed by newmail here.
With "generic" I mean that it can work with any cpufreq governor, the whole logic is implemented in the core cpufreq subsystem using early_suspend hooks.
How does it work?
Without this patch set applied, using for example the ondemand governor, the cpu frequency ranges always between 200MHz to 1200MHz (without overclocking/underclocking the device) that are the min and the max frequency supported by the processor.
With this patch set applied the frequency is regulated in the range [min ... max/2] when the screen is off and [max/2 ... max] when the screen is on. If the cpu doesn't support exactly max/2 an appropriate frequency is chosen, as close as possible to the theoretical value (for the GT-I9100 it's 500MHz).
Advantages
This forces background apps to always run at lower frequencies, reducing the power consumption when the phone is not used interactively, and, at the same time, boost the cpu at max speed when used interactively. IOW, it's faster and it drains more battery life when the phone is used interactively, and the battery last longer when the phone runs background tasks.
An additional side-effect using 'ondemand' is that the heuristic always works with shorter ranges, so the cpu ramps up / down faster to the target frequency. The feeling is that everything seems smoother and more responsive. I only tested ondemand for now, but the same logic should apply to the other available governors as well.
Source code
I like to post source code, more than binaries, so in attach you can find only the patches that implement this feature. The patches can be applied on top of the original Samsung kernel - Update2. These patches are also included in my kernel tree on github.
Patch set description
The 1st patch 0001-cpufreq-frequency-regulation-based-on-screen-on-off-.patch, implements the dynamic cpufreq range regulation logic. This patch is totally generic, so theoretically you can use it with any Android device.
The 2nd patch 0002-cpufreq-do-not-forget-min-max-clock-frequency-on-cpu.patch is required by multicore systems with cpu hotplugging enabled. It allows to resume the right frequency range on a cpu when it goes offline and then back online.
The 3rd patch 0003-mach-s5pv310-cpufreq-800MHz-sleep-death-fix.patch is specific for the GT-I9100 hardware. It's the 800MHz sleep death fix: the hardware requires to suspend the cpu always at 800MHz, so with the dynamic cpufreq range regulation this is always needed, independently of the particular governor you're using.
The 4th patch 0004-pm-hotplug-do-not-consider-frequency-in-the-cpu-hotp.patch is specific for the GT-I9100 hardware. It makes the cpu hotplug heuristic independent of the cpu frequency; this is required to properly offline the secondary cpu when screen is on _and_ the dynamic cpufreq range regulation patch is applied.
The 5th patch 0005-pm-hotplug-disable-secondary-cpu-auto-hotplug-when-s.patch is specific for the GT-I9100 hardware. It always sets the secondary cpu offline when the screen is off.
ChangeLog
v1 -> v2
fix: allow to offline the secondary cpu when screen is on
always disable the secondary cpu when screen is off
Click to expand...
Click to collapse
Hi,
Can you make it also for ninphetamine source code?
netchip said:
Hi,
Can you make it also for ninphetamine source code?
Click to expand...
Click to collapse
All the patches apply fine, except patch 0003, because the ninphetamine kernel already has a 800MHz sleep death fix.
The following patch set should apply cleanly (UNTESTED!!!).
Related
I take no credit of these codes. All i did is create a patch against with the leo kernel tree.
cpufreq: interactive: New 'interactive' governor
New interactive governor.
This governor is designed for latency sensitive workloads, UI interaction for
example.
Advantages:
+ significantly more responsive to ramp cpu up when required (UI interaction)
+ more consistent ramping, existing governors do their cpu load sampling in a
workqueue context, the 'interactive' governor does this in a timer context, which
gives more consistent cpu load sampling.
+ higher priority for cpu frequency increase, rt_workqueue is used for scaling
up, giving the remaining tasks the cpu performance benefit, unlike existing
governors which schedule rampup work to occur after your performance starved
tasks have completed.
Existing governors sample cpu load at a particular rate, typically
every X ms. Which can lead to under powering UI threads when the user has
interacted with an idle system until the next sample period happns.
The 'interactive' governor has a different approach. Instead of sampling the cpu
at a specified rate, the governor will scale the cpu frequency up when coming
out of idle. When the cpu comes out of idle, a timer is configured to fire
within 1-2 ticks. If the cpu is 100% busy from exiting idle to when the timer
fires then we assume the cpu is underpowered and ramp to MAX speed.
If the cpu was not 100% busy, then the governor evaluates the cpu load over the
last 'min_sample_rate' (default 50000 uS) to determine the cpu speed to ramp down
to.
There is only one tuneable for this governor:
/sys/devices/system/cpu/cpufreq/interactive/min_sample_rate:
The minimum ammount of time to spend at the current frequency before
ramping down. This is to ensure that the governor has seen enough
historic cpu load data to determine the appropriate workload.
Default is 5000 uS.
Click to expand...
Click to collapse
2.6.32-sched-bfs-318.patch.zip: is the patch is downloaded from official BFS site.
oc_uv_ab.patch.zip : this patch includes under volt, overclocking (upto 1.3GHz, any frequency above 1.15G is unstable on some of HD2s) and audio boost.
how does it work?
Sounds great. Maybe someone can integrate this into a kernel?
thanks for this!!
How to apply patch
I could really use the audio boost. Is there anyway you could explain how to apply the patches. Or is it possible you could apply them and post the patched kernel files? Thanks.
Would this actually have an improving effect on the touchscreen being unresponsive from time to time?
Hello,
Would it be possible to add the newer versions for oc_uv_ab.patch and interactive governor or I just don't know how to use GIT to well?
I don't have too much experience with C++, PHP dev here , and I'd like to compile my own kernel from the official GIT + change the MAC of the build to my own HD MAC + maybe some other small changes (adjust max freq and such).
Thank you very much for your hard work.
Kind regards.
dlsniper said:
change the MAC of the build to my own HD MAC + maybe some other small changes (adjust max freq and such).
Thank you very much for your hard work.
Kind regards.
Click to expand...
Click to collapse
This would be great.If someone can guide us how to make our wifi mac address
dolby71 said:
how does it work?
Click to expand...
Click to collapse
Just sit down and relaxed lol,michelle (michyprima kernel) or the topic starter build them i guess in few days
Whoops,nevermind,old topic i see
NOTICE: This is COMPATIBLE with ALL Google Rooted Stock and Custom ROMs based on JellyBean 4.2!
Just a statement regarding kernel source: The Kernel Source is of course covered under GPL version 2. Free software does NOT mean no work or time was spent working on it. I have donated a large sum of my free time to hack this kernel. If you use my modified kernel source in parts or in its entirety, I kindly ask you mention its origins and to send me a github pull request or PM whenever you find bugs or think you can help improve my kernel hack further. This way the entire community will truly benefit from the spirit of open source. Thank you ![/b][/center]
Hi XDA members and fellow Nexus users:
This is my twenty-third kernel hack. I want to thank T0dbld, Turl and rest of my teammates, and several others I cannot recall for inspiring me to venture into this unfamiliar territory for me.
What is a Kernel? The Kernel is the Foundation in which everything else builds upon in any software system.
[Car Analogy]: Kernel is like the Engine, Electrical system and the Transmission to a car. The Library, Framework and the Apps [AKA ROM] are the body frame and the rest of the Car.
THIS KERNEL is BASED ON Google Source Code. So it is COMPATIBLE WITH ALL AOSP JB 4.2 Builds.
DO NOT use any task killers, they DO NOT improve performance nor battery life. They INTERFERE with your phone's stability (more crashes) and App compatibility (Forced Close).
Kernel Features:
So what type of kernel is this? Well, this kernel is based on Linux 3.4.y (says so from the version string)
Features in Magenta are identical as the latest Linux 3.4+
Memory Management subsystem:
Init:
Core Kernel:
*** RCU:
*** Scheduler:
Power Management:
File System:
Block I/O:
Kernel Features:
Device Drivers:
Library Support:
Installation Instructions:
Change Log => Change Log
Beta 4.4 Kernel => Beta kernel
Mainline 4.4 Kernel => mako kernel <== (Stock CPU frequencies, Stock GPU frequencies 400MHz)
Ultimate 4.4 Kernel => mako kernel <== (CPU frequencies up to 1.8 GHz, GPU frequencies up to 450 MHz)
Deprecated JELLYBEAN kernels:
Stock Plus Change Log => Change Log
JWR Stock Plus Kernel => http://faux.romhost.me/mako/sp/mako-SP-JB43-JWR_r2.zip
JSS Stock Plus Kernel => http://faux.romhost.me/mako/sp/mako-SP-JB43-JSS_r2.zip
Mirrors http://androidhosting.org/Devs/Faux/
Here's a step by step instruction to install this kernel:
1. download the above file (via phone directly or to a PC)
2. copy the downloaded zip file to /sdcard/download/
3. Open ROM Manager and select "Reboot into Recovery" and select "OK"
4. Once in recovery, select "wipe cache partition", select "Yes", then select "advanced", then select "Wipe Dalvik Cache", then select "Yes" again. Once finished, click the back button to go back to the main recovery menu. On that menu, select "Install Zip From SDCad", then select "Choose zip from SDCard", then go to /sdcard/download and select the downloaded zip file and let it run its script.
5. Once the script is done, select "reboot system now"
Note: After FLASHING, the first reboot may take longer than usual, please be patient... After the first reboot, it may lag during initial load (let everything finish loading). Once everything is loaded and phone is ready for use, reboot the phone a 2nd time and the lag will be gone and everything should be silky smooth...
[ Advanced Users: ]
[ Optional: ]
If you encountered any funny / weird / strange issues coming from other than 100% pure stock ROMs or my kernels, the following "Reset Kernel" will restore the kernel to its Original Stock Settings.
After applying the reset kernel, then load my latest kernel again.
*** JellyBean -- RESET KERNEL (FOR STOCK BASED ROM ONLY. FORC CM SIMPLY REFLASH THE LATEST NIGHTLY, then FLASH my KERNEL AFTERWARDS) ***
JellyBean 4.2.x Reset kernel for STOCK ROMs ONLY (Cyanogenmod, simply reflash nightly again to reset)
*** 4.2.2 ***
http://faux.romhost.me/mako/mako_422_reset_kernel.zip
*** 4.2.1 ***
http://faux.romhost.me/mako/mako_421_reset_kernel.zip
Tmobile LTE Hybrid Modem hack:
http://forum.xda-developers.com/showpost.php?p=43926154&postcount=12988
[ For Kernel Devlopers ONLY: ]
NEWS BULLETIN:
Version 029 is OUT!
(lurking, no more open betas )!
Please don't hesitate to talk among yourselves and help each other out... The XDA community is what inspired me to hack kernels for everyone since everyone here is nice and helpful to each other... Keep helping each other.... Famous proverb: It's better to give than to receive...
BUGS:
Not All CHIPS ARE CREATED EQUAL
TO DO:
version 0.x.x -- more to come...
History:
See Post below...
Standard Disclaimer: Not responsible for bricking your phone, voiding your warranty, or any other pain or suffering you may feel as result of using this kernel!!!
My github Complying with GPL and XDA rulez
Follow me on
:
If you find this Kernel useful, feel free to hit the [Thanks] button below
FauxClock App recommended Settings"
CPU Control
Max clock - GHz 1.512 GHz for performance, 1.242 GHz for battery
Min clock - MHz 384 MHz for both
CPU Governor - Intellidemand for performance AND battery
mpdecision - Off
Snake Charmer - OFF for performance, On for Battery
Eco Mode - Off for performance, On for battery
Set On Boot - On
SOC Control
Set On Boot - On
C0 - On
C1 - On
C3 - On (Note: N4 AP modem is very sensitive to some of the deeper sleep states, if you experienced Green/Yellow AP Modem Watchdog Bark screens, I recommend disabling C2/C3 states).
Voltage Control
Set On Boot -
Global CPU Voltage - mV
intellidemand gov control
Up Threshold - 95 for both
Up Threshold Any CPU Load - 85 for both
Up Threshold Multi Core - 75 for both
Boost Frequency - 1026000 for both
Two Phase Freq - 1134000 for both
Optimal Freq - 1242000 for both
Synchro Freq - 756000 for both
Set On Boot - On
GPU Control
GPU Governor - Simple for both
GPU Clock - 400 MHz for performance and 320 MHz for battery
GPU Vsync Toggle - On for both
Set On Boot - On for both
I/O Scheduler Control
I/O Scheduler (eMMC) - FIOPS for both
Readhead Size (eMMC) - 2048 for both
Set On Boot - On for both
Misc Control
Dynamic File Sync - On for both
TCP Congestion Control - Westwood for both
Vibration Control
Set On Boot - On for both
Vibration Control - 70 for both
Screen Color
Set On Boot - On for both
Factory Presets - LG Presets
Color Adjustments - R, G, B 255, 250, 245
Gamma Amp Adjust 0 - R, G, B 13, 20, 22
Gamma Amp Adjust 1 - R, G, B 0, 2, 3
Z-Control
Set On Boot - On for both
ZRAM Disk size - 150~200 Megabytes (or 50 MB when disabled)
ZRAM Enable/Disable - Enable if you mult-task often
Clear VFS Cache After Boot - On
Auto FS Writeback Delay Mode - On
Swappiness - 100% if ZRAM enabled, 0% if disabled
VFS Cache Pressure - 100% if ZRAM enabled, 150% if disabled
Dirty Ratio - 20% for both
Dirty Background Ratio - 5% for both
Above is what I use personally. MAY NOT be optimal for all :fingers-crossed:
Updated on September 6, 2013
DUE TO MY EXTREMELY BUSY SCHEDULE BOTH @ WORK AND @ HOME, I WILL ONLY MAKE MAJOR ANNOUNCEMENTS ONCE PER WEEK
Open Beta may not be stable and may cause issues with your phone!
By loading open beta you have agreed to:
1. To report all random reboots with associated /proc/last_kmsg
2. To provide feedback on errors or bugs with detail phone information such as ROM, kernel version, and apps
3. Participate in Forum discussions for the beta software with others without FLAMING each other or post useless information such as:
a) Phone doesn't boot (without providing any additional information, ROM versions etc)
B) phone is too hot (without providing any additional information, ie OC freq, UV etc)
The Open Beta system is designed to have the community help each other and the developers. This way, all potential bugs are flushed out so the final released version will be stable and error free. The more actively you participate in Beta Testing the better the final product will be (you are really helping yourself to create a better community software).
If you do NOT agree with the statements above, DO NOT load my Open Beta software.
Kernel 00x Open Beta 0x is now CLOSED!
FAQ:
1. Why don't my settings "stick" when using FauxClock App?
#1 issue with settings NOT sticking is superuser Switch to SuperSU should solve 95% of issues
https://play.google.com/store/apps/...51bGwsMSwxLDEsImV1LmNoYWluZmlyZS5zdXBlcnN1Il0.
UPDATE: Koush's new Superuser is also compatible with my apps!
2. Why doesn't my Max frequency settings NOT "stick" when using intellidemand governor with FauxClock App?
Intellidemand will AUTOMATICALLY UNDERCLOCK when there's a CONSTANT load for greater than 3 minutes. (Load spikes will NOT trigger the auto underclock, only CONSTANT loads). After the load is gone, it will restore back to original Max Clock. Constant load will drain the battery quite quickly, intellidemand governor will detect this behavior and automatically underclock to save more battery without ANY user intervention at all!
3. Why does the CPU freq slider move when I touch the screen?
Qualcomm's closed source mpdecision is the culprit. mpdecision raise the minimum CPU frequency to 1.026 GHz to "cheat" or increase UI smoothness. While this is a good idea, it is too aggressive and overkill causing unnecessary battery drains. And because it is closed sourced, it is NOT POSSIBLE to tweak its behaviors. I highly recommend turning off mpdecision when using my kernels in combination with intellidemand/intelli_plug
4. What is Intelli_plug? How do I use it?
Intelli_plug is my open source solution to Qualcomm's closed source mpdecision. Intelli_plug is enabled automatically upon boot, so NO need to turn on or off. However, it conflicts with mpdecsion, so I HIGHLY recommend turning off mpdecision when using my kernels! To turn off mpdecision, either use fauxclock app under CPU page or use terminal / init.d script and write "stop mpdecsion"
5. What is Eco Mode in FauxClock App?
Eco Mode is a special power savings mode part of the intelli_plug where the kernel automatically reconfigures its decisions in real time and optimizes to use only 2 out of 4 cores. Cores 3 and 4 are turned off completely.
6. My Gamma/Color settings do NOT stick when I removed FauxClock App from memory!
FauxClock app MUST be running to retain the colors. This is a limitation of the stock kernel and FauxClock app was designed to overcome this issue, so therefore it has to be running and be in memory (Avoid all Task Killers!!!)
7. If FauxClock has to be running all the time, does it CAUSE MORE DRAIN?
NO, FauxClock is a normal behaving app which does NOT HOLD or request ANY wakelocks from Android system. Therefore it does NOT cause any drain at all while running (matter of fact, it's suspended most of the time until it's needed)
8. What is "SnakeCharmer" ?
SnakeCharmer is an extension that I created to tame the Qualcomm Krait CPUs. Due to asynchronous SMP cpu design, each CPU can have its own independent min/max frequencies. SnakeCharmer allows you to set a specific max cpu frequency to all cores at the same time, so if you want to UNDERCLOCK your CPUs to a specific frequency, you should enable it under FauxClock.
9. I enabled "SnakeCharmer" but I occasionally see it still goes to max 1.512 GHz, why?
SnakeCharmer works flawlessly. FauxClock app is a Java app which runs on top of Linux. Sometimes it gets out of sync with the kernel, so it will display a frequency that's higher than the maximum "SnakeCharmer" frequency. This is a PURE DISPLAY issue with FauxClock App. SnakeCharmer works advertised! (Confirmed using CPUSpy by multiple users).
10. I have BOTH FauxClock and FauxDisplay apps but I seemed to lost the Screen Adjustment Tab under FauxClock? (Nexus 4 Only)
FauxDisplay (aka Advanced Gamma Control has full 27 controls unlocked, it supersedes the basic controls provided by FauxClock
11. What is Turbo Boost and how do I enable it? (Nexus 4 ONLY)
Turbo Boost is similar to Intel's Turbo Boost for the x86 CPUs. It increase the clock frequencies when 2 or less cores are active. (TB-U allows up to 1.9.44 GHz, TB-M allows up to 1.836 GHz). To enable turbo boost, simply slide the CPU max frequency slider all the way to the right!
12. Why can't I Undervolt below 600mv?
Ever since I created the UV interface for Qualcomm phones on 2010, 600mv minimum voltage has been chosen for a reason. There are typically 2~4 different "binnnings" for the same CPU chip (each binning has their own voltage tables) and therefore NOT ALL CHIPS are created equal. The 600mv limit was put through many different tests and was found to be stable ACROSS many many different chips/binnings combinations (No crash or sleep-of-death aka SOD) and it has been proven time and time again to be a good value for minimum voltage value.
SOC Sleep States demystified! (Corrected for incorrect information thanks for G+ comments!)
Often times users using many apps like CPU Spy will say post how much time their phone spent in "deep sleep" and thinking that "deep sleep" is only 1 state, unfortunately, it is WRONG. For many modern CPUs there are several C-States (sleep states), and the term "deep sleep" does NOT correctly describe them all.
Just like in real life, there are several stages of "sleep", the shallowest sleep is C0 State. As in real life, C0 state is very easy to wake up from with almost NO latency at all (real life will be like grogginess, so C0 is just like when you first doze off but any little distraction will instantly wake you up). The deeper the sleep, the harder it is to wake up from. It takes longer for CPU to re-initialize itself to a waking state (just like real life where once you enter REM sleep, it's very hard to wake up from it).
For most processors, C3 is the Deepest sleep state. C3 state is ALMOST like turning it off using the absolutely minimum power.
C0 - Shallowest sleep (dozing off) with instant wake up
C1 - slightly deeper sleep with slight latency when waking up
C2 - deeper sleep with longer latency when waking up
C3 - really deep sleep (like REM sleep in real life) with longest latency when waking up
My pyramid (Sensation 4G) kernel has Intellidemand Governor 2.0 (Grand daddy of the Mako's Intellidemand governor) where I disabled ALL hotplugging when screen is on (ie, both cores stays ON the WHOLE TIME) but I enabled C2 state for both processors, so even though at first you think it may draw more battery than hotplugging (turning off the core when not using), many of my users have experienced better battery life than with hotplugging (Hotplugging is VERY expensive, the act of turning cores on/off drains battery as well).
On Nexus 4 (Mako), for some reason, Qualcomm has decided to only allow for C0 state (the shallowest sleep) and so the "deep sleep" isn't really that deep. With my FauxClock app + my kernel, I give you all the "deeper" sleep states so when idling, you phone can experience deeper sleep. There's a hardware bug for Krait processors where the secondary cores, 1~3, cannot achieve deeper sleep state independently, so hotplugging is still necessary to save power for cores 1~3 but for core 0 (and core 0 is the master CPU and it's NEVER hotplugged) being able to go into deeper sleep state will help to conserve more power.
FauxClock is designed with forward compatibility. With the newer Qualcomm Krait 600/800 series, they have fixed a few of the hardware bugs from the Krait processors, and so for those newer SOCs, you can go into deeper sleep with all cores like the like older 8x60 SOCs.
Yea! Glad to see you came with me from the Amaze forums! Can't wait to flash soon!
I remember you from the hercules forums. Nice to see you here! Looking forward to using your kernels.
Well well well... Look who's here. Nice to see you working on This beast man. I'm excited to see what you have in store for us.
Oh and where are my manners... Happy Thanksgiving man.
Sent from the Nexus 4 Drinking Club...
"It's not drinking alone if you are with people on an internet forum"
Oh **** faux is here, now it's a party
Sent from my Nexus 4 using xda app-developers app
STFU! Faux!? Oh, it's ON now baby!!!
Sent from my Nexus 4 using xda premium
Holy crap! I'm gonna cry! First kernel I ever flashed was a Faux123. My phone needs to get here....
Source?
doesnt boot
edit:
well, boots, but not into your kernel.
using fastboot flash causes no boot.
edit the edit:
wtf. works now. right on man.
randomblame said:
Source?
Click to expand...
Click to collapse
You can find it on his profile, as per usual
https://github.com/faux123/mako
EDIT: actually, it doesn't seem to be updated. But anyway, I'm sure faux will update it when he finishes recovering from post-turkey stress
r2DoesInc said:
doesnt boot
edit:
well, boots, but not into your kernel.
using fastboot flash causes no boot.
Click to expand...
Click to collapse
exaclty what i was going to say...tried boot, but no go, simply boots without changing kernel ; and flash doesn't work.
Also, doesnt run @ 1.8. Itll reboot and then hang till you reflash the kernel.
Pesonally I'd suggest staying away from this until it was a bit more tested.
Oh man.
Now the situation has gotten real. Nice one faux.
r2DoesInc said:
Also, doesnt run @ 1.8. Itll reboot and then hang till you reflash the kernel.
Pesonally I'd suggest staying away from this until it was a bit more tested.
Click to expand...
Click to collapse
you do realize that not every CPU is going to be able to oc that high? Some won't oc at all. Some will go higher. Just saying......
Damn faux anyway way we can get a flash able after u get some time? Not near a comp right and want to try this bad boy! Thanks
wont boot...
got a lockup at 1.7 and reboot loop after till i flashed the kernel again
---------- Post added at 03:13 PM ---------- Previous post was at 03:13 PM ----------
tweaked said:
you do realize that not every CPU is going to be able to oc that high? Some won't oc at all. Some will go higher. Just saying......
Click to expand...
Click to collapse
...yes
derp
Page 1: Information
Page 2: Changelog and Downloads
Page 3: Additional info and FAQ
Instructions:
Make sure you are on the latest bootloader version before flashing this or any other custom kernel. Search for a flashable zip or use fastboot and the google factory images.
Download Kernel to internal SD card. Flash in recovery. Reboot. Congratulate yourself for wisely installing the best nexus 7 kernel.
A complete list of changes is available at my Github.
Source: https://github.com/Metallice/android_kernel_grouper
Recommended Settings:
The only app supported for changing any kernel parameters and settings is TricksterMod - https://play.google.com/store/apps/details?id=com.bigeyes0x0.trickstermod
CPU governor - TouchDemand with default parameters (default)
I/O Scheduler -
- ROW for pure read speed. Fast reads which are often the most important on mobile. Similar concerns like deadline.
- BFQ for more consistent performance. Slower than Deadline and ROW, but prevents stutters while downloading in background
Max Frequency - 1.2Ghz (Stock max for 2+ cores) (for lollipop it might be a good idea to use 1.3Ghz)
- Note: Tegra sets the max frequency to 1.5Ghz at boot, make sure to change it manually or have an app set it at boot to avoid battery loss. If you have a program such as
TricksterMod set it at boot make sure to include at least a 60 second "delay" in applying boot settings.
- Note 2: DO NOT USE THE APP "SYSTEM TUNER" TO SET FREQUENCIES. CONFLICTS WITH AUDIO PERFLOCK IN KERNEL. Do NOT use system tuner to set frequencies as it conflicts with audio performance lock in this kernel. Will prevent you from lowering your maximum frequency. Use Trickstermod.
GPU Max Freq - 446Mhz (maintains good battery life while smoothing out some games. Anything greater than 446Mhz is so heavily bottlenecked by RAM that it's essentially worthless. 600Mhz might give you 1 or 2 extra FPS for significantly worse heat, battery life, and stability)
- Possible frequencies - To be completed later
Fsync - On
Dynamic Fsync - On (be aware of data loss concerns, even if they actually are minimal.)
SmartDimmer/PRISM - On (off for a63 and lower)
zRAM - off/none (default) (For lollipop it may help with multitasking at the price of speed, although you really shouldn't be trying to heavily multitasking with a 2012 N7 anyway) (Not very useful on android 4.x with >=1GB RAM, for lollipop it's not really helpful >=3Gb)
Data remounting scripts - already included in ramdisk. Additional scripts not needed.
I DO NOT RECOMMEND, nor will I support, any kind of optimization/superdupercharge/placebo script. All settings are already optimized in kernel and ramdisk. Using these scripts or tweaks will only lead to problems and performance degradation.
__________________________________________
If you'd like to buy me some caffeine so I can continue to fit studying and kernel-ing in my busy schedule, feel free to donate below. Thanks so much for all of your support! Clicking the thanks button is always appreciated too
Alpha Changelog (stable feature list above):
a77 - remove CM12.1 specific stuff from ramdisk
a76 - Fix for 5.1
a75 - 5.1 Lollipop update and patches
Click to show complete changelog
a74 -
Fix for TricksterMod. Sync with cm12 ramdisk. Fake update dmcrypt to allow TRIM on encrypted devices (untested). Set ROW as default scheduler.a73 -
Lollipop! Updated toolchain. Removed touch2wake due to the wakeup issues it created for some. Other stuff.a69 -
Quick fix to allow overclocking on stock roms.
a68 -
Update to latest 4.4.3 kernel source
Sync with latest CM 4.4.3 ramdisk
Update to 4.8 toolchain
F2FS support
Zip installation supports all permutations of ext4/f2fs layouts
Based on work by frantisek.nesveda, but modified to support all layouts and be more flexible
Make sure to go to his thread -HERE- and click the thanks button!
Upgrade to BFQ v7r4
Adjust touchboost values
Enable Kernel Samepage Merging - I've gone back and forth on this. For now, enabled.
Probably some other changes I'm forgetting.
a67 - Update + sync ramdisk from cm11 to enable native USB OTG. Add thermal charging shut off. Some kconfig tweaks.
a66 - Only hold wakelock is touch/slide to wake is enabled. Tweak default BFQ values a bit.
a65 - Update BFQ from 5.1 to 6r2. Set BFQ as default for testing. Tweak Deadline and CFQ (Franco's CFQ values). If CFQ is still causing reboots for some, I will revert it to stock in next build. Cgroups timer slack controller. Enable RCU priority boosting for testing.
a64 - merge 4.4 kernel changes. Update ramdisk for 4.4
a63.1 - CM hotfix
a63 - Add Tegra 4 SmartDimmer (ported from TripNRaVeR's port for the One X). It either works much better or is completely broken. Either way, it's an improvement from the old SmartDimmer. Add necessary ramdisk change for PAC rom. Add dm9620 usb ethernet support. Switch back to linaro 4.7 toolchain from google 4.6 (used in mr2 for stability reasons).
a62 - Add double tap to wake thanks to flar2 and sgt. meow. Add configurable timer to keep double tap to wake active after screen shut off. Remove Fsync toggle. Pointless and confusing with Dynamic Fsync available now. Update Dynamic Fsync from faux123. Set backlight levels back to defaults and disable otf_scaling. Some random stuffs.
New sysfs:
/sys/android_touch/wake_timeout
Value is in seconds. Defaults to 60. Set to 0 to keep double tap to wake permanently active at the price of battery.
a61 - Enable compass driver. Add Dynamic Fsync by Faux123. Disable Fsync off at boot. Enable Dynamic Fsync at boot. Remove wifi pm fast/max toggle as it is now pointless and won't work since 4.3 kernel update. Add an older, but simpler, version of usb host mode by mehrvarz. Fixed and enabled many 4.3 config options relating to things like selinux.
a60 - More ramdisk fixes
a59 - Update cm10.2 ramdisk to fix storage issues. Fix 00su init.d.
a58 - Incorporate cm10.2 ramdisk.
a57 - Update to 4.3 kernel base. 4.3 stock only. Ramdisk base courtesy of Francisco Franco. Fsync off at boot since the internal storage is just so appallingly slow.
a56 - Add back some missing config options removed in a55 to support various features. No CIFS support. Couldn't get it to boot for some reason.
a55 - Add v2 of Tegra AHB patch set. Remove and revert USBHOST patches. Revert to almost stock kernel config for testing (will probably revert back later). Revert to stock PA ramdisk for testing. Tweak default TouchDemand parameters for bettter performance. Hard-code deadline and cfq tuneables thanks to the work by those in Franco's thread - details in commitlog on github. Set deadline as default I/O scheduler. Add core hotplugging lock during touch boost/input to interactive governor based on implementation in stock interactive governor (not fully tested). Other minor, inconsequential changes.
a54 - Remove AHB bus drivers and patches.
a53 - USBHOST support and patches. WiFi adhoc IBSS support.
a52 - revert voltage table changes
a51 - fix flickering at brightness level 13 when smartdimmer was enabled by setting SD min to 10. Re-enable a 3g modem reset assignment fix. It was disabled in a49/a50; let's see if re-enabling it causes 3g drops to return (Otherwise TCP proportional rate reduction was the cause). Re-enable wifi p2p patch that was disabled in a49 under the impression it wasn't included in the stock kernel when it actually is (whoops). Increase the some DVFS voltages so that that they are at least as high pre-a50 (according to DVFS debug showing actual running voltage) and not more than 25mV greater than pre-a50. Hard-code default pm_qos_max_cpus as 4 instead of ULONG_MAX. Fixes aesthetic bug where the default tegra hotplug max_cores was 2147483647 (For the curious - it is 2^31 − 1, the maximum value for a 32-bit signed integer in computing).
Oh, and change thread title to accord with new XDA requirements.
a50 - re-enable dynamic edp. Rework some edp limits. Rework DVFS voltage tables to better match frequencies, YMMV. Removed 1.7GHz max frequency option as it was pretty split whether your device could run it or not. If people were more responsible and wouldn't complain about issues when running 1.7 or higher I would leave it in, but unfortunately that's just not the case. So it saves me headaches in the future. Sorry. It's a minor increase from 1.6GHz and most can do 1.6 just fine.
a49 - add some rwsem patches. Revert TCP proportional patch. Revert a wifi p2p patch. Fully stock /net and drivers/net in source now. Add custom min/max backlight interface. I'll add more info when I'm not so busy. Removed zRam support.
Change your max backlight (min - 255) - /sys/module/board_grouper_panel/parameters/max_backlight
Change your min backlight (1 - max) - /sys/module/board_grouper_panel/parameters/min_backlight
Enable/Disable on-the-fly backlight level redistribution through available brightness slots based on new min/max using math below (0/1) - /sys/module/board_grouper_panel/parameters/otf_scaling
- brightness = min_backlight + DIV_ROUND_CLOSEST(((max_backlight - min_backlight) * max((brightness - 10),0)),245);
a48 - actually upload a kernel that is mr1 + row patches + flash fix
a47 - mr1 + row patches + flash fix accidentally uploaded old kernel version...
a46 - disable have_efficient_unaligned_access. Add USB Host mode charging patches.
a45 - Fix adobe flash corruption. Add ARM unaligned access and enable have efficient unaligned access. Make sure slider min brightness and auto-brightness min have the same backlight value.
a44 - Start over at mr1. Add ROW patches. Add LZ4 compression.
a43 - revert all network and wireless patches since mr1.
a42 - revert some config options. Fix fixed_mode on boot for multiboot. Sched_mc_power_savings set to 0 instead of 2 to see how it affects wakeup.
a41 - ARM cpu topology and relevant patches. Enable multi-core scheduling. Enable maximum multi-core scheduling power savings for testing. Switch back to LZ4 ramdisk compression as Multiboot supports it now. Increase touchdemand sampling down factor since sampling rate was decreased previously.
a40 - Revert SLQB. Add latest usb host mode charging from mehrvarz's repo. Force detect/report usb as ac, no apparent benefit. Enabled a config SVIPC or something... I forget. Enabled rndis support from CM.
a39 - SLQB allocator. Switch back to Gzip ramdisk compression for multirom.
a38 - Fix adobe flash playback. Super fast Lz4 compressed for ramdisk and kernel. Arm unaligned efficient memory access. Some misc. wifi and network patches. Many other changes. No guarantees.
__________________________________________________
Downloads:
Alphas 5.1 -
a77 - https://www.androidfilehost.com/?fid=23991606952601904
a76 (CM12.1) - https://www.androidfilehost.com/?fid=23991606952601166
Click to show downloads for older versions of Android
Alphas 5.1 -
a75 - https://www.androidfilehost.com/?fid=95916177934553111
Alphas 5.0 -
a74 - https://www.androidfilehost.com/?fid=95916177934528566
a73 - https://www.androidfilehost.com/?fid=95784891001616369
Alphas 4.4 -
a69 - http://d-h.st/kI7
a68 - http://d-h.st/gPV
a67 - http://goo.im/devs/Metallice/Nexus7/4.4.x/M-Kernel_a67.zip
a66 - http://goo.im/devs/Metallice/Nexus7/4.4.x/M-Kernel_a66.zip
a65 - http://goo.im/devs/Metallice/Nexus7/4.4.x/M-Kernel_a65.zip
a64 - http://goo.im/devs/Metallice/Nexus7/4.4.x/M-Kernel_a64.zip
Milestone 4.3.x Releases -
mr2 (4.3.x)
http://goo.im/devs/Metallice/Nexus7/Milestones/M-Kernel_mr2.zip
Alphas 4.3 (post mr2) -
a63.1 - http://goo.im/devs/Metallice/Nexus7/4.3.x/M-Kernel_a63.1.zip
a63 - http://goo.im/devs/Metallice/Nexus7/4.3.x/M-Kernel_a63.zip
a62 - http://goo.im/devs/Metallice/Nexus7/4.3.x/M-Kernel_a62.zip
Alphas 4.3 (pre mr2) -
a61 - http://goo.im/devs/Metallice/Nexus7/4.3.x/M-Kernel_a61.zip
a60 - http://goo.im/devs/Metallice/Nexus7/4.3.x/M-Kernel_a60.zip
a59 - http://goo.im/devs/Metallice/Nexus7/4.3.x/M-Kernel_a59.zip
a58 - http://goo.im/devs/Metallice/Nexus7/4.3.x/M-Kernel_a58.zip
a57 - http://goo.im/devs/Metallice/Nexus7/4.3.x/M-Kernel_a57.zip
Milestone 4.2.x Releases -
mr1 (4.2.x)
http://goo.im/devs/Metallice/Nexus7/Milestones/M-Kernel_mr1.zip
Alphas 4.2.x -
a56 - http://goo.im/devs/Metallice/Nexus7/4.2.x/M-Kernel_a56.zip
a55 - http://goo.im/devs/Metallice/Nexus7/4.2.x/M-Kernel_a55.zip
a54 - http://goo.im/devs/Metallice/Nexus7/4.2.x/M-Kernel_a54.zip
a53 - http://goo.im/devs/Metallice/Nexus7/4.2.x/M-Kernel_a53.zip
a52 - http://goo.im/devs/Metallice/Nexus7/4.2.x/M-Kernel_a52.zip
__________________________________________________
Legacy downloads available at http://goo.im/devs/Metallice/Nexus7
THIS POST/GLOSSARY NO LONGER UPDATED DUE TO TIME CONSTRAINTS
Glossary of terms:
(that one may not be as familiar with as things like CPU and GPU)
Hotplugging - the process of turning CPU cores on and off.
G core(s) - One of four ARM A9 CPU cores found in the Tegra 3 SoC
LP (core) - The ARM A9 "Low-Power" CPU core found in the Tegra 3 SoC in addition to the 4 G cores. The LP core, contrary to what many seem to believe, does not run in tandem with the 4 G cores.
Runnable Threads (hot plugging) - Limits turning on more cpu cores based on the average number of running threads
Touchdemand - A modified ondemand-based governor that I designed and configured to better suit the Tegra 3 and android based on my observations
Variant -
Scheduler -
Other things
FAQ:
What's the difference between the mr(#) version/download and the a(#) version/download? Which should i download? What do these acronyms mean/stand for?
The mr# (ex. mr1) stands for milestone release number #. The milestone builds are the stable, bug-free, and thoroughly, extensively, and expansively tested builds of m-kernel.
The a# (ex. a38) stands for alpha build number #. The alpha builds listed under downloads are all of the alpha builds after the latest milestone build listed in reverse chronological and "morphological" (? FIX) order. It is the continuation of the "alpha branch" of m-kernel, and is basically the latest milestone with a ton of patches, fixes, and changes that are completely UNTESTED by anyone but me. The number and substantiality of changes since the latest milestone obviously vary and also depends on the number of alpha builds since the latest milestone release. An alpha build isn't guaranteed to be stable, working, and bug-free. They are testing builds leading up to the next milestone
Do you recommend setting the maximum number of cores to 2?
I don't necessarily recommend everyone do this, for it really comes down to personal preference. However, limiting the maximum cores to two is a very simple change to make that will slightly improve battery, with little to no impact on performance. Android 4.x is highly optimized for dual-core processing. There is no part of the Android 4.x OS that needs more than 2 cores for a smooth experience, and likewise there are few to no android applications that need 2 cores.
For the most part, the 3rd and 4th g cores are only activated during time sensitive actions such as opening an app for the first time (i.e. not previously opened and cached in RAM) and during screen rotation. These are short lived operations meaning those 3rd and 4th g cores are quickly turned off afterwards. In essence a small hit to battery life for even smaller benefits.
Why won't my minimum frequency go below 340MHz?!?
As long as you don't use system tuner, the minimum frequency does go below 340MHz. The minimum frequency is temporarily raised to 340MHz during an audio event to prevent audio playback problems when using ondemand and similar governors. The minimum frequency returns to the previous value afterwards. Some apps may show the minimum frequency as 340MHz because clicking the app to open it created a sound causing the minimum to temporarily rise. The app does not change when the minimum frequency goes back to its previous value.
Why can't over clock the GPU as high as I can on other kernels!?!
You can. You have to raise the voltage for the top GPU slot. Other kernels do this automatically and to fixed values. The amount necessary depends on the GPU frequency you are trying to run and your device. No devices are alike and the voltage necessary at whatever frequency will vary considerably from device to devices. Be aware that having to overvolt to run a certain frequency may mean suggest that you shouldn't run that frequency anyway. Raising the GPU frequency and voltage has risks to consider
What is this tegra 3 "variant" or whatever? How do I find it? What does it meeeeaaaannnn??!!?
You can find this info in /sys/kernel/debug/t3_variant
In the stock kernel/source, each device sku is recognized and assigned four ID values. For the CPU there is a primary "cpu speedo id" and a secondary "cpu process id". For the SOC, or core (think LP core, RAM, GPU, etc), there is a primary "soc speedo id" and a secondary "soc process id."
Each "pair" of ids is used to choose the respective voltage tables for the components they represent. I'm going to ignore the soc/core ids as they aren't relevant to my point and are the same for all our devices.
The CPU voltage tables are represented by ( cpu_speedo_id # , cpu_process_id #). The voltage tables that share the same first number, the cpu_speedo_id, all end with the same MHz value. To make things simple, Tegra uses the maximum frequency in the voltage table to determine the maximum frequency. All of our Nexus 7 Tegra 3s share the same cpu_speed_id, corresponding to a maximum frequency of 1.3GHz.
The second number, the cpu_process_id, differs between all of our N7 T3's. Faux123 and everyone refers to value as our "variant." This value, cpu_process_id determines the voltages for each frequency in the table. For each increase in cpu_process_id, the RANGE of voltages for the voltage table is compressed by 25mV (i.e. the voltage for the top frequency is decreased by 25mV while the bottom stays at 800mV and the middle frequency voltages are adjusted accordingly).
Therefore, in a direct sense, the cpu_process_id, or "variant", HAS NOTHING TO DO WITH CPU FREQUENCY. I'll repeat this. YOUR CPU_PROCESS_ID OR VARIANT HAS NO DIRECT CONNECTION TO THE MAXIMUM FREQUENCY CAPABILITIES OF YOUR CHIP. Variant/cpu_process_id refers to the voltage tolerance of your cpu. While there may be correlation or secondary connection to the maximum frequency capabilities of your chip, there is not direct connection. Additionally, cpu_process_id HAS NOTHING TO DO WITH YOUR SOC/CORE AT ALL, WHICH INCLUDES YOUR GPU/LP/RAM. A high cpu_process_id tells you nothing about your core and how high you can clock your GPU.
TL;DR - Variant, or more accurately cpu_process_id, refers to voltage tolerance, and has no direct connection to the max frequency abilities of your chip, and definitely has absolutely no relationship to your core/GPU.
To do:
Core voltages quirks.
Max freq delay necessity.
Why doesn't the kernel come with recommended settings?
One more
Re: [Kernel[3G+Wifi] M-Kernel - mr1
Sweet will flash this and give you some results later
Sent from my VS920 4G using Tapatalk 2
Re: [Kernel[3G+Wifi] M-Kernel - mr1
azoller1 said:
Sweet will flash this and give you some results later
Sent from my VS920 4G using Tapatalk 2
Click to expand...
Click to collapse
+1 I got a good feeling about this one
Sent from my SGH-T999 using xda app-developers app
tdizzle404 said:
+1 I got a good feeling about this one
Sent from my SGH-T999 using xda app-developers app
Click to expand...
Click to collapse
I really hope you're making a joke... I've had a thread in android development for a while now... 37 versions...
Re: [Kernel[3G+Wifi][4.2.2] M-Kernel - mr1
So really there is no need for gpu over clock unless for a benchmark?
Sent from my VS920 4G using Tapatalk 2
azoller1 said:
So really there is no need for gpu over clock unless for a benchmark?
Sent from my VS920 4G using Tapatalk 2
Click to expand...
Click to collapse
Says who? Me? Where?
No of course that's not true. GPU overclock can have benefits. Minimal due to RAM bottlenecking, but it will still marginally imrprove FPS in some cases.
I love your work metallica, we really appreciate it
I remember you made 5(+) different versions just because for 2 people having wifi issues...
You really spend a lot of time at this and this is a great kernel.
Thanks!
Re: [Kernel[3G+Wifi][4.2.2] M-Kernel - mr1
Metallice said:
I really hope you're making a joke... I've had a thread in android development for a while now... 37 versions...
Click to expand...
Click to collapse
No joke here ive had decent results with your kernel I'm just commenting on the update
Sent from my SGH-T999 using xda app-developers app
Re: [Kernel[3G+Wifi][4.2.2] M-Kernel - mr1
Oc GPU to 520 and when I left trickster It blacked out and rebooted
Sent from my Nexus 7 using Tapatalk 2
Nothing to say at the moment but gotta post in it so I get subscribed. Keep up the good work!
I had just posted in the original M-kernel thread and couldnt edit my last post (probably cuz its being moved) . I was unable to set cpu max core to 4 w/o system freezing up. I just upgraded to mr1 and it shows 4 cores active and no freeze ups so far. I will leave everything to stock for now.
Cool you finally moved to "original" forum, makes it alot easier for me to navigate since I am usually in this forum anyways..
thxs
d
azoller1 said:
Oc GPU to 520 and when I left trickster It blacked out and rebooted
Sent from my Nexus 7 using Tapatalk 2
Click to expand...
Click to collapse
Hi, you just need to increase the GPU voltage a little bit before you overclock it to 520mhz, hope that helps
Re: [Kernel[3G+Wifi][4.2.2] M-Kernel - mr1
azoller1 said:
Oc GPU to 520 and when I left trickster It blacked out and rebooted
Sent from my Nexus 7 using Tapatalk 2
Click to expand...
Click to collapse
Maybe you should try reading the FAQ :/
Sent from my Nexus 7 using Tapatalk HD
Re: [Kernel[3G+Wifi][4.2.2] M-Kernel - mr1
Congrats my friend. What a journey!
How,s it feel to be in the big leagues
Edit: mr1 flashed. Keeping it default for now. Seems very smooth. Another excellent kernel. Thank you for everything.
Cheers, FReaKRaNT
Re: [Kernel[3G+Wifi][4.2.2] M-Kernel - mr1
thanks for the hard work the kernel works great and the FAQ was very helpful.
Sent from my Nexus 7 using Tapatalk 2
Απ: [Kernel[3G+Wifi][4.2.2] M-Kernel - mr1
Guys does flash working for u without any problems?
Edit:I'm on Francos kernel now. I just flash this kernel without wipe cache and dalvkin?
Sent from my Nexus 7 using Tapatalk HD
Cool you're in Original Dev now. Congrats Metallice.
Downloading mr1 now. :good:
Introduction
This is a kernel for XT1572/XT1575 built from stock sources (marshmallow-6.0.0-release branch) with cherry picks from other kernels and some ports/mods done by me. It started as a personal build tailored to my preferences but just thought I'd share in case somebody might find it useful. My main goal is building the smoothest kernel I can get so performance is top priority.
This kernel is for stock ROM MPH24.49-18*
Disclaimer
Although I have experience with Linux kernels on desktops and servers this is my first Android kernel. I've been running this kernel on my XT1572 for a few days and seems pretty stable but that doesn't mean it's risk free. In fact I wouldn't dare to install it if you don't have a proper backup and some basic skills to deal with unexpected situations.
Features
Aroma Installer
CPU profile scripts (see this)
Color control (KCAL)
Frandom
Updated to kernel version 3.10.101
Overclocking (a53: 1536MHz a57:2016MHz)
Underclocking (302MHz)
Additional CPU governors (ElementalX, Intelliactive, Lionheart, BioShock, BluActive, Wheatley, InteractiveX/Interactive, Impulse, Zzmoove)
Additional I/O schedulers (SIO, FIOPS, Zen, BFQ, SIOPLUS)
Bricked Hotplug
Updated ZRAM driver
Updated Lowmemorykill driver
Basic init.d support
KSM and UKSM
Voltage readings
Fsync on/off
Touchboost on/off
Vibration control
KEXEC Hardboot (MultiROM support)
Patched cdrom code (DriveDroid support)
DoubleTap2Wake/Sweep2Wake/Sweep2Sleep (EXPERIMENTAL)
Power efficient workqueues
Support for additional FS: NTFS, NFS, CIFS
Additional Xpad drivers (read this)
Device as USB trackpad/keyboard driver (read this)
WiFi module optimizations
Many minor optimizations
Optimization flags
UBER Toolchain 4.9
Installation instructions
Download ZIP and flash from TWRP/Flashify. Read the following notes carefully before flashing.
Important notes:
This kernel is still experimental, make a proper backup first
You need to be rooted
DO NOT play with DT2W/S2W before reading the release notes and the update
In case you want to tune some parameters (ie: CPU frecuencies) I recommend you install EX Kernel Manager, Kernel Adiutor or Kernel Adiutor-Mod.
If you're using Kernel Adiutor to control vibration or TCP congestion read this.
Questions? Read the FAQ before posting.
Download
Latest version is v0.14 (see release notes)
https://www.androidfilehost.com/?w=files&flid=49225
Donations
Although quite a deal of the important work has been done by the developers mentioned in the Credits section I spend many hours working on this. If you feel like helping me out I'd appreciate some tiny donations to cover some minor expenses.
Thanks to all of you who have donated, it's very much appreciated.
Profiles
One of the FAQ in most kernel related threads is "What are the best settings for .....?". This is the 10 million question since the usage pattern can be very different for each user. However, I understand less experienced users will appreciate some hints in this department, so that's why I'm posting some basic settings you can use as a starting point.
It's your job to further tune them to suit your needs. You should be able to modify these settings with whatever Kernel Control App you like the best, although not all settings are available in every app, in such a case tune those you can. The list is not complete (just the most importante settings) and is loosely based on Kernel Adiutor arrangement.
Please, keep in mind these are subjective values (based of personal preferences or popularity) and some people might like other settings for whatever reasons.
Performance Profile: Very smooth and responsive but average battery life
CPU
LITTLE Cluster
CPU Governor: bluactive
CPU Max Frequency: 1536MHz
CPU Min Frequency: 302MHzBIG Cluster
CPU Governor: bluactive
CPU Max Frequency: 2016MHz
CPU Min Frequency: 302MHz
NOTE: If you get N/A or weird values when trying to change settings on BIG cores it means both have been hotunplugged. To work around this select "performance" governor, make your desired changes and then select you previous governor.CPU Boost
Input Boost Frequency Core 1: 960MHz
Hotplug
MSM MPDecision
Minimum CPU online: 2
Maximum CPU online: 6
Max Cores Screen Off: 2
Idle Frequency: 384MHz
Thermal
Core Control: Off
VDD Restriction: Off
Temperature Throttle: On
GPU
Max Frequency: 600MHz
Min Frequency: 180MHz
Govenor: cpufreq
I/O
Scheduler: noop
Read-ahead: 1024KB
Balanced Profile: Above average battery life with good performance on most situations
CPU
LITTLE Cluster
CPU Governor: interactive
CPU Max Frequency: 1440MHz
CPU Min Frequency: 302MHzBIG Cluster
CPU Governor: interactive
CPU Max Frequency: 1632MHz
CPU Min Frequency: 302MHz
NOTE: If you get N/A or weird values when trying to change settings on BIG cores it means both have been hotunplugged. To work around this select "performance" governor, make your desired changes and then select you previous governor.CPU Boost
Input Boost Frequency Core 1: 960MHz
Hotplug
MSM MPDecision
Minimum CPU online: 2
Maximum CPU online: 5
Max Cores Screen Off: 2
Idle Frequency: 768MHz
Thermal
Core Control: Off
VDD Restriction: Off
Temperature Throttle: On
GPU
Max Frequency: 600MHz
Min Frequency: 180MHz
Govenor: msm-adreno-tz
I/O
Scheduler: noop
Read-ahead: 1024KB
Battery Profile: Good battery life at the expense of somewhat limited performance
CPU
LITTLE Cluster
CPU Governor: ondemand
CPU Max Frequency: 1440MHz
CPU Min Frequency: 302MHzBIG Cluster
CPU Governor: ondemand
CPU Max Frequency: 1632MHz
CPU Min Frequency: 302MHz
NOTE: If you get N/A or weird values when trying to change settings on BIG cores it means both have been hotunplugged. To work around this select "performance" governor, make your desired changes and then select you previous governor.CPU Boost
Input Boost Frequency Core 1: 960MHz
Hotplug
MSM MPDecision
Minimum CPU online: 1
Maximum CPU online: 3
Max Cores Screen Off: 2
Idle Frequency: 960MHz
Thermal
Core Control: Off
VDD Restriction: Off
Temperature Throttle: On
GPU
Max Frequency: 450MHz
Min Frequency: 180MHz
Govenor: simple_ondemand
I/O
Scheduler: noop
Read-ahead: 1024KB
Thanks To/Credits
vadimtk
flar2
franciscofranco
nimrodsv
anarkia1976
savoca
myfluxi
AudioGod
osm0sis
nychitman1
jollaman999
imoseyon
showp1984
HashBang173
neobuddy89
rehpyc
Alcolawl
soniCron
Spasticdroid
XDA:DevDB Information
Frankenclark, Kernel for the Moto X Style (Pure)
Contributors
dirtyhank
Source Code: https://github.com/dirty-hank/frankenclark/
Kernel Special Features:
Version Information
Status: Beta
Current Beta Version: 0.14
Created 2016-01-10
Last Updated 2016-10-11
Changelog
v0.14 (2016-08-29)
Proper KCAL control (thanks to @Spasticdroid)
Updated xpad driver for compatibility with gamepads/controllers (thanks to @Spasticdroid)
Driver to use device as USB trackpad and keyboard (thanks to @Spasticdroid)
Misc minor updates (see github)
100Hz version uses stock compiler flags
v0.13 (2016-06-21)
Update to Linux Kernel 3.10.102
Misc minor updates (see github)
New start-up CPU governor profiles: bluactive, maddog and silverfish
v0.12 (2016-05-15)
Disable DT2W/S2W while phone call is in progress
New CPU governors: impulse, zzmoove
New and updated CPU profile scripts
Runtime CPU profile switcher script (see release notes)
Minor changes to Aroma installer
v0.11.1 (2016-05-01)
Aroma Installer update (see release notes)
v0.11 (2016-04-27)
Aroma Installer
Better camera focus
Less CPU usage from DT2W/S2W
Minor updates and bugfixes
v0.10 (2016-04-03)
Updated lowmemorykiller driver
BFQ and SIOPLUS I/O schedulers
Updated ZRAM driver (on by default)
User togglable WLAN wakelocks
Basic init.d support (see release notes)
Misc minor updates
v0.9 (2016-03-20)
Update to Linux Kernel 3.10.101
Bug fixes
Changes from Google update to N5X and N6P (see release notes)
v0.8 (2016-03-06)
Update to Linux Kernel 3.10.99
Power efficient workqueues
NTFS support
NFS and CIFS support (you'll probably need additional user space binaries)
v0.7.1 (2016-02-28)
Workaround for the dimmed screen upon unlock bug when DT2W/S2W is enabled
v0.7 (2016-02-21)
Hotplug thresholds tuned to keep BIG cores offline more often
KEXEC Hardboot (MultiROM support)
Patched cdrom code (full DriveDroid support)
DoubleTap2Wake/Sweep2Wake/Sweep2Sleep (HIGHLY EXPERIMENTAL, Read this)
v0.6 (2016-02-07)
Vibration control (non-haptic)
Relaxed CPU macros for better power usage
File hosting now on AndroidFileHost
v0.5.2 (2016-02-03)
Fixed USB and WiFi Tethering
Minor tweaks
v0.5.1 (2016-02-01)
Changes to installer
v0.5 (2016-01-31)
Update to Linux Kernel 3.10.95
InteractiveX governor (as patches to the interactive gov)
Bricked Hotplug
KSM and UKSM (disabled by default, use Kernel Adiutor to enable)
Many minor optimizations
WiFi module optimizations
Modules recompilation
Disabled core_ctl (due to broken module after some internal changes to kernel)
Voltage readings (any attempt to modify values is silently ignored)
v0.4.1 (2016-01-24)
Prevent msm_performance from messing with the user selected min/max CPU frequencies
v0.4 (2016-01-23)
New CPU governors (ElementalX, Intelliactive, Lionheart, BioShock, BluActive, Wheatley)
New I/O scheduler (Zen)
Default I/O scheduler set to noop with a read ahead of 1024kb
Fixed bug CVE-2016-0728
Minor optimizations
Introduce ZIP installer (Anykernel2)
v0.3 (2016-01-18)
Color control (KCAL)
frandom support
New optimization flags
ZRAM disabled by default
v0.2 (2016-01-14)
Updated to Linux kernel 3.10.94
Underclocking (302MHz)
v0.1 (2016-01-10)
First public version
FAQ
I get random reboots, what is happening?
This kernel overclocks both clusters by default (a53: 1536MHz a57:2016MHz) and although this is very safe for most devices some CPUs are in the lowest spot of the binning spectrum and can't handle O/C very well. In such a case use a kernel control app (see the OP for references) to limit the maximum CPU frequencies, play with them until you find stable values for your device.
What are the best settings for battery life/performance/whatever?
That's hard to tell as every user is different. You can find some basic profiles in the OP you can use as a starting point. Notice the differences between then and build you own.
Why do some BIG cluster settings display N/A?
Why can't I change some settings on the BIG cluster?
If you get N/A or weird values when trying to change settings on BIG cores it means both are offline ("hotunplugged"). To work around this select "performance" governor, make your desired changes and then select you previous governor. You can also disable hotplug, make the changes, and enable hotplug again.
DoubleTap2Wake doesn't work sometimes. How can I get it to work all the time?
When device goes into suspend mode first tap is often missed (I suspect this is caused by Moto Sensor Hub). If you tap three times and get the timing right you'll probably make it work most of the time. As an alternative, Sweep2Wake works almost all the time
DT2W/S2W is acting weird or disabling itself
Make sure Moto Display is disabled. Open the Moto app, click on the stars in the top right corner, select Display and set to Off
Can I use this kernel in ROM X/Y/Z?
This is for stock ROM MPH24.49-18 only. It'll probably work on any stock based ROM but not guaranteed.
I use stock ROM but WiFi is not working
Due to some internal changes all modules had to be recompiled (WiFi included). In order to expose the new modules without modifying the system partition I had to implement a hack that requires root. Make sure you're properly rooted.
What's the deal with ZRAM?
ZRAM is a technique to increase memory available to the apps at the expense of CPU time. Memory space from apps not being used is compressed into a memory swap area and uncompressed on the fly whenever needed. As you can imagine this compress/uncompress process burns CPU cycles, potentially leading to worse battery life, lag and higher temperatures. Since this device comes with 3GB I can only think of one scenario where ZRAM can be beneficial: heavy multitaskers who care more about apps not reloading than battery life. For the rest of users enabling ZRAM doesn't make much sense in my opinion, and that's why it's disabled by default.
UPDATE: v0.10 includes an updated ZRAM driver that improves performance significantly. So much so that the benefits seem to outweigh the costs and it's been enabled by default.
What's the deal with KSM/UKSM?
Since many apps use the same libraries/resources it's very likely that at any given time there are multiple copies of the same data on different memory locations. KSM/UKSM tries to take advantage of that fact by scanning memory pages periodically and consolidating that multiple copies into a single shared copy. Much as like ZRAM it can have a good effect on heavy multitasking performance but at the expense of CPU cycles, and thus it's only recommended in the same scenario as ZRAM. Disabled by default
Ok, so do I enable ZRAM/KSM/both/neither?
I honestly think most users will be better off not using neither. If you feel like you need extra RAM I'd try KSM first, then ZRAM. Using both at the same time is overkill unless you are an ultra multitasker, in which case you should probably get a 4GB device anyway
How do I get WiFi on 6.0.1?
It's a modem version mismatch issue, you need to downgrade the modem. See this post.
Love to see more options! Thanks for sharing!!
Yeah this will be very good
Only One think that would be awesome try to implement the double tap to wake
Awesome! More custom kernels are always welcome are there many governors to choose from?
krohme said:
Awesome! More custom kernels are always welcome are there many governors to choose from?
Click to expand...
Click to collapse
Right now only the stock governors are available but I plan on adding a few
Can't we install it through twrp???
guraki said:
Can't we install it through twrp???
Click to expand...
Click to collapse
Yes, TWRP supports boot image flashing
I lost root after the kernel install....
---------- Post added at 03:22 PM ---------- Previous post was at 02:39 PM ----------
Seems to work fine!!! Any battery life expectations?
guraki said:
I lost root after the kernel install....
---------- Post added at 03:22 PM ---------- Previous post was at 02:39 PM ----------
Seems to work fine!!! Any battery life expectations?
Click to expand...
Click to collapse
As I said on the OP my main goal is performance/smoothness, so I haven't specifically sought better battery life. That being said I'm getting about the same battery life as stock with better performance, that works for me.
Nevertheless, I'm very interested on how it works for other configurations and usage patterns.
@dirtyhank could you please add hotplugging to the kernel? Preferably one that allows you to select how many cores to run as well as which ones, as in run the two A57s and turn off the four A53s. Currently I'm running two A53s at 1.2Ghz and the remaining four cores are always off.
The screenshot is from Lolipop, and it is the only reason why I havent upgraded to MM. Turning off cores definitely makes a difference on battery life.
Also, if possible, adding a lower speed to the min speed. Will gladly test anything you thow my way. Thanks in advance.
Is there any chance for a CM13 version and a DT2W fork from elementalx?
sir-harlekin said:
Is there any chance for a CM13 version and a DT2W fork from elementalx?
Click to expand...
Click to collapse
DT2W maybe, CM13 unlikely.
very nice thank you! slowly slowly we getting more and more things. Just making sure this is only for stock based rom/s Thanks!!
cerobles1 said:
@dirtyhank could you please add hotplugging to the kernel? Preferably one that allows you to select how many cores to run as well as which ones, as in run the two A57s and turn off the four A53s. Currently I'm running two A53s at 1.2Ghz and the remaining four cores are always off.
The screenshot is from Lolipop, and it is the only reason why I havent upgraded to MM. Turning off cores definitely makes a difference on battery life.
Also, if possible, adding a lower speed to the min speed. Will gladly test anything you thow my way. Thanks in advance.
Click to expand...
Click to collapse
What kernel are you using on LP?
patt2k said:
very nice thank you! slowly slowly we getting more and more things. Just making sure this is only for stock based rom/s Thanks!!
Click to expand...
Click to collapse
Yep, stock ROM, I'll edit the OP
dirtyhank said:
Yep, stock ROM, I'll edit the OP
Click to expand...
Click to collapse
Awesome gonna flash this soon
I hope a port for CM based roms might be possible in the future! Thanks for sharing your work and replying so quickly!
dirtyhank said:
Yep, stock ROM, I'll edit the OP
Click to expand...
Click to collapse
Getting bootloop on TruePure rom 2.4. Anything I can try to avoid bootloops?
Hey guys and girls,
So straight to Topic.
The Kirisakura-Harmony is based on the latest google sources. On top of it are the latest EAS patches directly from Linaro. It also includes a few Audio Patches from CAF. Power Gating is disabled so you can use this kernel with @chdloc ´s excellent, I am wholeheartedly recommending it, biquads mod. If you grasp what you can do with it, you will never need an equalizer in your life again. So this is also an audio oriented kernel.
As I said I am still learning. The Feature list Comes here:
- Based on the latest Sources from Google for Android Q/10
- Upstreamed to 3.18.140
- Schedutil included again
- GPU Adrenoboost
- Wake gestures from flar2
- KCAL from savoca and ported by tbalden
- HBM enabled and accessible for the user
- Backlight dimmer is added
- FIOPS, SIO and MAPLE I/O Scheduler included
- Updated BFQ I/O Scheduler
- I managed to merge some Audio Patches from CAF, which should enhance Audio
- Power Gating disabled so you can use @chdloc ´s biquad mod
- Vibration Control
- Sound Control
- sdcardfs
- Sched and latest Schedutil (with latest upstream patches is also default)
- Updated EAS Machinery
- USB fast charge
Instructions for Android P
How to flash the Kernel:
1. Download the kernel.zip to your device
1a. Optional: While it may not be necessary all times, you may want to restore stock boot.img, re-root with magisk and optionally install twrp.zip if coming from another kernel. Before reporting issues make sure you do that! Thank you!
You only need to do either 2a OR 2b
2a. Boot to TWRP and flash my kernel.zip. Root will be preserved!
or
2b. Flash kernel zip in EX Kernel Manager or FKM app. Root will be preserved!
3. After booting up make sure to set schedutil as default CPU governor (check apply on reboot option) to fully profit from the kernel´s changes!
4. Enjoy your device now!
Android 10 Download:
Download:
https://www.androidfilehost.com/?w=files&flid=300707
Download for PIE
Download:
https://www.androidfilehost.com/?w=files&flid=198589
Oreo Kernel Stuff
Download:
https://www.androidfilehost.com/?w=files&flid=152851
Changelog-Mainline:
0.1
- Initial release
0.2
-added safetynet patch
0.3
- Add GPU OC
- Update wake gestures
- Many new Performance Patches
- Updated dm verity
0.4_1
- More performance tweaks
- Made my kernel a flashable zip <-- I hope you guys are satisfied now
0.5
- add Slimbus OC <-- Increases Audio Quality
- Various crypto Patches
- More Patches that may help with Performance
- added wakelock Patches
- added a few alsa patches
0.6
- added soundcontrol
- disabled some logging stuff
- some more tweaks
0.7
-enabled few other tcp congestion algorithms <-- westwood is now default
- set default iosched to deadline as it works best with eas kernels if we trust the documentation
0.8
- added sdcardfs <-- take a look at the FAQ on how to enable it
- added in two new governors, alucardsched and darknesssched
- merged in some other commits. take a look at my github
0.9
- when deactivating kernel side dt2w and s2w, one is still able to use the stock google dt2w implementation
- code updates for both alucardsched and darknesssched <--- if anyone has time please test and report back how they work with 0.9
- added option for GPU boost <--- disabled by default, take a look at the faq please
- update to cpuidle <--- deep sleep is improved for me
- the simple_ondemand GPU governor is now usable and does not crash upon choosing
- fix an issue were tasks were not given properly to cpusets
- a few other changes, please take a look at my github
0.9_5
- fixed a typo which would the user not choose msm-adreno-tz GPU governor after choosing simple_ondemand <--- also have no worries I implemented a patch that will let you choose only GPU governors that will not crash
- a few more commits for schedutil and sdcardfs
0.10
- all security patches
- some patches that may help with efficiency
- many patches to schedutil,sched, and walt (many)
- few patches to sdcardfs
- tuned WALT values a bit
- other things I forgot, check my github
0.11
- I added a few additional commits to adrenoboost, it is now more conservative and suited for daily use. I run it on moderate boost and don´t notice any battery drain
- performance of the fingerprint reader may be improved <-- I need feedback from you, don´t use it myself
- update to slimbus OC
- a few patches that may help with stability and performance in general
- many patches to schedutil , it is the recommended governor now in conjunction with nohint.zip
- introduced a new governor, called helix_schedutil based on schedutil; thanks to @ZeroInfinity
I had a little play with it, if anyone finds better values I can include them.
- for more details check my github
- please check this post prior to flashing: https://forum.xda-developers.com/showpost.php?p=71415045&postcount=210
Changelog for 0.12:
- added blu active governor
- updates to helix_schedutil, alucardsched and darknesssched
- updates to sdcardfs
- maybe some performance improvements <-- please give feedback
- other things look at my github
- made a non oc version
- please check this post prior to flashing: https://forum.xda-developers.com/showpost.php?p=71502126&postcount=241
Changelog for 0.13
- Implemented CPU_Input_Boost by sultanxda <--- disabled by default, if you experience scrolling lag activate it in EXKM, CPU Tab
- Implemented a new sched governor called energy-dcfc (Dynamic Capacity and Frequency Capping), more information in second and third post
- Some adjustements for schedutil
- Updated helix_schedutil
- some improvements to alucardsched and darknesssched
- adjusted WALT to final parameters
- bumped up and improved BFQ, thanks @DespairFactor <-- new default
- introduced Maple I/O scheduler
- updated sdcardfs
- please check this post prior to flashing: https://forum.xda-developers.com/showpost.php?p=71502126&postcount=241
Changelog for 0.14
- Added April Security Patches
- Updates to Schedutil, Sched, energy-dcfc
- Introduced a new EAS governor called pwrutil <-- more information on the second post
- Some upstream patches
- some more crypto patches
- updated wakelock blockers
- for other things look at my github
- please check this post prior to flashing: https://forum.xda-developers.com/showpost.php?p=71502126&postcount=241
Changelog for 0.16
- Linux Kernel Version is now 3.18.51
- Applied May security Patches
- many other little improvements and changes
Changelog-Rebase:
- Features EAS 1.2 Machinery
- May security update
- Linux version 3.18.53
- Includes all features from mainline except the EAS Governors (sched and schedutil are included) and CPU Boost.
- IO switcher
- some patches to schedutil
1.24
Updated sdcardfs
little performance tweak
updates to low power mode
1.28
- IO switcher
- some patches to schedutil
1.29
- performance tweak
1.32
- 3.18.55
- June Security Update
1.36
- updated sdcardfs
- EAS patch
- Linux Bump to 3.18.56
- ipv6, net and ext4 patches
1.40
- Linux Version now at 3.18.59
- July Security Patches
- updated sdcardfs
- little patch for sched
- boost now also ufs storage controller upon turning on the screen additionally to boost ddr bandwidth(even faster wakeup)
- extended recharge rate when battery is near full (aids longevity of our battery)
Changelog-Harmony:
4.00
https://forum.xda-developers.com/showpost.php?p=75835635&postcount=1105
5.01
https://forum.xda-developers.com/showpost.php?p=76106520&postcount=1129
6.00
https://forum.xda-developers.com/showpost.php?p=77515614&postcount=1166
6.01
https://forum.xda-developers.com/showpost.php?p=77533981&postcount=1178
6.02
https://forum.xda-developers.com/showpost.php?p=77588617&postcount=1180
6.04
https://forum.xda-developers.com/showpost.php?p=77758260&postcount=1188
6.05
https://forum.xda-developers.com/showpost.php?p=77776533&postcount=1189
6.06
https://forum.xda-developers.com/showpost.php?p=78125103&postcount=1198
6.07
https://forum.xda-developers.com/showpost.php?p=78342154&postcount=1209
7.00
https://forum.xda-developers.com/showpost.php?p=78916917&postcount=1243
7.01
https://forum.xda-developers.com/showpost.php?p=78968314&postcount=1251
8.10
https://forum.xda-developers.com/showpost.php?p=79506878&postcount=1287
10.0
https://forum.xda-developers.com/showpost.php?p=80581575&postcount=1301
10.1.0
https://forum.xda-developers.com/showpost.php?p=81119421&postcount=1311
FAQ:
Q: Which app do you recommend to apply changes to the kernel?
A: EX Kernel Manager from @flar2 is a great choice. He is constantly updating it.
Q: Which CPU governor I can choose freely and not hinder the EAS?
A: schedutil
Q: what is GPU boost and how should I choose the boost level?
A: I also implemented GPU Boost.
if you use the default GPU governor which is msm-adreno-tz you will have the option of GPU boost in EXKM. if you choose simple_ondemand not.
I think GPU Boost is not really needed on this phone as it raises GPU freqs aggressively enough for most tasks. So I leave it disabled at default.
It was originally introduced on the HTC 10, to counter an issue whereby the GPU failed to scale up aggressively enough, to run some not demanding games properly in 60fps locked. But there are some performance junkies (like me) who want to try such things.
So you can enable this setting and it has 3 profiles. Low, medium and high. It defines how aggressively the GPU gets scaled up.
I found GPU boost on low to be quite a good all day setting. Maybe a little bit more performance and not a too big hit on battery.
Medium and High are definitely more battery hungry and you should do this only for gaming or benchmarks.
Q: What is the difference of WALT and PELT and how does it affect me?
A: https://forum.xda-developers.com/showpost.php?p=71336204&postcount=179
Credits:
@Eliminater74 for bringing me into the game and the Inspiration
@flar2 for all his work
@tbalden
@savoca
@franciscofranco
@DespairFactor for the zip and the help
@Alucard24
@ZeroInfinity
@RenderBroken for helping me out
@dorimanx
@Sultanxda
if i forgot anyone just pm me and I will gladly add you
Source: https://github.com/freak07
Info Post
So this post will be dedicated to information about EAS in general.
Another amazing write up about alucardsched by a talented new dev @joshuous:
This is what I understand from tracing the Alucardsched code. I apologise if my understanding is incorrect.
Firstly, next frequency selection with Schedutil (very simple):
Code:
next_freq = 1.25 * Max_freq * current_util / max_util;
Now, here's a quick overview of one cycle of frequency selection in Alucardsched:
1. You have two key extra tunables: PUMP_INC_STEP and PUMP_DEC_STEP
2. Current utilisation here refers to the system's current demand. It is calculated using:
Code:
curr_util = (util * (100 + tunables->boost_perc)) / max_utilisation
The "util" is a value determined by the EAS scheduler.
3. Target load here refers to what processor is currently supplying. It is calculated using:
Code:
target_load = (current_freq * 100) / max_freq;
4. The key idea is to ensure that supply satisfies demand. That is, target load ≈ current load.
5. If target_load <= current_load (too little supply), then we want to increase frequencies to match the system’s load. For Alucardsched, frequency is increased by jumping up PUMP_INC_STEP number of steps in the OPP table. (By OPP table, I refer to the available frequencies that you can switch to)
6. If target_load > current_load (too much supply), then we want to decrease frequencies to match the system’s load. For Alucardsched, frequency is decreased by jumping down PUMP_DEC_STEP number of steps in the OPP table.
7. Do note that Alucardsched jumps several frequency steps, compared to Schedutil and Interactive which try to jump immediately to a calculated next frequency. In this way, Alucardsched doesn't care about the specific value of the next speed. It's like driving a car, and deciding to increase gears by several steps instead of deciding to jump immediately to a specific gear.
Extra Tunables
FREQ_RESPONSIVENESS
PUMP_INC_STEP_AT_MIN_FREQ
PUMP_DEC_STEP_AT_MIN_FREQ
Sometimes you want the "pumping" behaviour to behave differently at lower and higher frequencies. FREQ_RESPONSIVENESS can be seen as the mark that divides the low and high frequencies. If the current frequency is less than FREQ_RESPONSIVENESS, the number of frequency skips will be PUMP_INC_STEP_AT_MIN_FREQ and PUMP_DEC_STEP_AT_MIN_FREQ instead of the usual PUMP_INC_STEP and PUMP_DEC_STEP.
How is it used? If your frequency is low (lower than FREQ_RESPONSIVENESS) and your system demand is high, you ideally want to boost frequency speeds quickly. This is when PUMP_INC_STEP_AT_MIN_FREQ kicks in. PUMP_INC_STEP_AT_MIN_FREQ is usually (and should be) a larger value than PUMP_INC_STEP. When your frequency is high (higher than FREQ_RESPONSIVENESS) and your system demand is high, you don't want to be jumping so many steps up otherwise you will hit max frequencies too quickly (overkill). I'm pretty sure you can figure out how PUMP_DEC_STEP and PUMP_DEC_STEP_AT_MIN_FREQ works after having read this paragraph
Tldr;
Schedutil: simpler
Alucardsched: more tunable
Code:
IF CURRENT_FREQ < FREQ_RESPONSIVENESS:
PUMP_INC_STEP_AT_MIN_FREQ and PUMP_DEC_STEP_AT_MIN_FREQ are used
ELSE:
PUMP_INC_STEP and PUMP_DEC_STEP are used
PUMP_INC_STEP_AT_MIN_FREQ should be larger than PUMP_INC_STEP.
Note: There is however a potential problem (if you may call it one) with Alucardsched: just like Interactive you rely almost entirely on heuristics (trial and error) to control your frequency jumps instead of letting the system choose it for you, like in Schedutil. In that way, Alucardsched detracts from the goal of Schedutil to provide a simple frequency choosing mechanism. Without the proper tuning to meet your specific usage, it is likely that your frequencies will overshoot or undershoot past the needed load on Alucardsched (just like in Interactive). I would recommend that you play with the tunables to see what works best for you.
Here is information about energy-dcfc (Dynamic Capacity and Frequency Capping):
This new governor is based on schedutil. It uses target_load variables as thresholds to let the governor decide when to cap the frequencies for both clusters. These variables are called "load1_cap" and "load2_cap". Load1_cap corresponds to target_load1 meaning anything that is below target_load1, it caps using load1_cap. Anything above target_load1 and below target_load2, use load2_cap. Anything above target_load 2 and the maximum frequency will be used.
As a result of this behaviour, bit shift value must be set to 1. Anything higher than 1 and frequency scaling will be extremely slow. This is because the lower the maximum frequency, the lower the next frequency target is because the frequency range is being limited.
AS OF V009: The governor has now incorporated @Kyuubi10 's schedutil dynamic formula change. When load is below target_load1 it will use add bitshift in the formula. If load is above target_load1 but below target_load2, it won't use any bit shifting at all. If load is more than target_load2, it will subtract bitshift in the formula. This has proven to be very efficient with a touchboost-like behaviour when scrolling (Up to the capped frequency of this governor), then steady performance in between, and on heavy workloads it will not just stay on maximum frequency, in fact it will hover around 1.3-1.9GHz to ensure thermals are good as well as battery endurance.
This governor is aimed with maximum efficiency in mind. Do not expect outstanding performance with this governor.
helix_schedutil explained by @Kyuubi10
To understand Helix_schedutil you must first understand the original schedutil algorithm.
Here it is:
next_freq = maxfreq + (maxfreq >> bitshift) * util/maxcapacity
Explanation:
The most obvious difference of this algorithm is that it moves away from the idea of scaling frequencies up or down which were used in previous generations of governors.
Instead the aim of the above algorithm is to calculate the most appropriate frequency for the TOTAL CPU load.
NOTE: This is TOTAL load on CPU, not just load for the current frequency step as Interactive used to calculate with.
Now, for you numberphiles like myself that like understanding algorithms... Let's break it down:
"util/maxcapacity = Load."
The above creates a percentage value in decimal format (80% = 0.8) which represents the TOTAL load on CPU.
the algorithm now reads the following way:
next_freq = maxfreq + (maxfreq >> bitshift) * load
"maxfreq + (maxfreq >> bitshift)"
Essentially the aim of the above is to ensure that next_freq is always a little higher than the exact value needed to cover the load.
Bitshift: (paraphrasing @ZeroInfinity) in programming the ">>" mathematical function allows for shifting the binary values towards the direction of the arrows by "N" times.
In this case it is towards the right.
The relationship between "N" and the calculation in the "()" is as follows:
Bitshift = 1 = maxfreq/2
Bitshift = 2 = maxfreq/4
Bitshift = 3 = maxfreq/8
If the "+()" didn't exist in the algorithm, the chosen frequency would be exactly enough to cover the load.
If load is 0.6, aka 60%, all you need is a frequency = 60% of max frequency.
This would be bad since it doesn't leave any capacity/bandwidth leftover for inevitable bumps in load, nor space for EAS itself to run. Thus inevitably creating lags.
To keep a bit of free bandwidth you add "(maxfreq >> bitshift)".
Finally the problem I encountered, if bitshift = 2, then the result of the algorithm is that any load above 0.8 will result in a next_freq HIGHER than maxfreq. - This is your tipping point. As any load higher than 80% will wake up a new CPU.
Which means you have still about 20% of the CPU's max capacity being unused. Such a CPU is only 80% efficient.
Therefore by increasing bitshift to 3, the algorithm reads:
"maxfreq+(maxfreq/8)*load = next_freq"
This way you can use 89% of capacity before reaching max frequency of the CPU.
With bitshift=4 it reads:
"maxfreq+(maxfreq/16)*load = next_freq"
This allows you to use up to 94% total CPU load before reaching max frequency.
While this is great for improving efficiency at the higher frequencies, it doesn't leave enough bandwidth when calculating lower frequencies, and creates lag when load spikes at lower frequencies.
Update to the explanation:
After being inspired by the concept of @ZeroInfinity's new governor - Energy-DCFC, I decided to carry out a couple of tests on HTC 10 using variations of Helix_Schedutil.
The focus was stress-testing by increasing the current frequency load above 100%. (AKA Use up all of the bandwidth of the current frequency step.)
After the testing me and Zero worked on this new version of Helix_Schedutil.
The current behaviour of the governor is the following:
- Boost frequencies when load is below Target_Load1. (Boost can be increased by DECREASING bit_shift1 value.)
- Between Target_Loads there is no bit_shift at all. The governor just uses the following algorithm instead - (max_freq*util/max = next_freq)
- Loads higher than Target_Load2 will be THROTTLED. Bit_Shift2 here is subtracted rather than added. (Throttle effect can be increased by DECREASING bit_shift2 value.)
The result is that low freqs have spare bandwidth to avoid lags, middle frequencies leave no extra bandwidth at all, while higher frequencies are throttled to save battery.
Another focus of the governor update is to reduce overhead as much as possible. This results in a very responsive governor which isn't overly demanding on battery life.
Schedtune.boost values recommended for use with this governor:
Top_App: 5
Foreground: -50
Background: -50
Global: -50
Energy-DCFC is still recommended for those who prefer battery life over performance, but if you prefer greater performance then this governor can be used without making you feel guilty about wasting battery.
correction a misconception:
Some people describe tipping point as the load threshold which the governor uses to decide whether to ramp up or down.
While if you look into the behaviour of the governor it may appear that it behaves in such a way, it is technically incorrect.
As I mentioned previously this new algorithm moves away from the behaviour of legacy governor algorithms which focus on the current frequency load.
This governor does no ramping up or down.
It isn't even aware of the current frequency load, as it only knows the load relative to max capacity.
The misconception appears based on a property of the algorithm that results in a consistent load at any chosen frequency. This is a coincidental result of the algorithm, even though the algorithm is completely unaware of it.
Tipping point is in fact the load percentage at which the CPU reaches max frequency and any increase in load forces it to wake up a new core
here is some Information about pwrutil governor:
This new governor is based on schedutil.
A much simpler yet very effective governor based on schedutil. All this changes is the calculation to get the next frequency. Rather than using bit shift to calculate tipping point and what not, we don't use it at all. This is much much more efficient if you use my program called "schedutilCalculator" to calculate what the next frequency is. For example, a load of 25% with a max freq of 2150400 will get 500MHz as next frequency. A load of 50% will get 1GHz as next frequency. A load of 75% will get 1.5-1.6GHz as next frequency. A load of 100% will get 2.15GHz as next frequency. You can see the lower the load, the much lower the frequency selection will be, but the higher the load and the higher the frequency selection is. So it can go from a very low powered state with 50% load and under, to a high performance state from 75% load and above.
Includes a tunable called "utilboost" which is basically a load multiplier - it makes load higher than it is perceived by the governor, thus making next frequency selection higher. Remember utilisation does not equal load. The equation of calculating load is util / max capacity of a CPU (which should be 1024). So 512 / 1024 = 0.5 (50% load).
UTIL BOOST IS NOT MEANT TO BE USED WITH SCHEDTUNE.BOOST AT THE SAME TIME! EITHER USE ONE OR THE OTHER OR ELSE PERFORMANCE WILL BE OVERKILL AND BATTERY LIFE WILL DRAIN MUCH FASTER!!!
Util boost is supposed to be a replacement of schedtune.boost. schedtune.boost applies boosting to both clusters, whereas util boost allows boosting per-cluster so users can have much more control.
how to gather logs:
There are several apps that can do this process for you, Here is one: PlayStore: SysLog
And here is another: PlayStore: Andy Log (ROOT)
ramopps: is an oops/panic logger that writes its logs to RAM before the system
crashes. It works by logging oopses and panics in a circular buffer. Ramoops
needs a system with persistent RAM so that the content of that area can
survive after a restart.
logcat: the logoutput of the Android system
kernel log: (kmsg / dmesg): the kernel messages
Additionally there's the last_kmsg which is a dump of the kernel log until the last shutdown.
radio log: the log outpur ot your System / BB / RIL communication
4
ramopps:Some Documentation on Ramopps
Normal Logcat:
Radio Logcat:
Ramoops:
Via adb:
adb shell su -c cat /sys/fs/pstore/console-ramoops > kmsg.txt
Via terminal on phone:
su
cat /sys/fs/pstore/console-ramoops > /sdcard/kmsg.txt
Kernel Log:
Kernel Log:
adb shell su -c dmesg > dmesg.log
Last_Kmsg:NOTE:
New location of last_kmsg on Android 6.0 and above: /sys/fs/pstore/console-ramoops
adb shell su -c "cat /proc/last_kmsg" > last_kmsg.log
NOTES:
-v time will include timestamps in the logcats
-d will export the complete log.
If you want to save a continuous log you can remove the -d parameter - then you need to cancel the logging process via CTRL+C.
To export a continuous kernel log use adb shell su -c "cat /proc/kmsg" > dmesg.log (and cancel it via CTRL+C again).
PS: This Document was taked from another XDA Thread Called: [Reference] How to get useful logs
URL: http://forum.xda-developers.com/showthread.php?t=2185929
Also check this one out: [Tutorial] How To Logcat
I only Revived it a bit for ramopps.
I will update this more at a later time..
Excellent work my friend thanks for supporting the Pixel XL I hope you get lots of joy from your new hobby!
Will flash in the morning and see how it goes...
Most of those audio patches you backported seem to be interesting, specially the ones that are meant to reduce power comsumption. Will pick. Suggestion, you don't need to specify the slot in the fastboot command, just fastboot flash kernel kernel_binary
can you disable storage force-encryption？thanks！
Sent from my Pixel XL using XDA Labs
Are the safetynet patches implemented by any chance?
franciscofranco said:
Most of those audio patches you backported seem to be interesting, specially the ones that are meant to reduce power comsumption. Will pick. Suggestion, you don't need to specify the slot in the fastboot command, just fastboot flash kernel kernel_binary
Click to expand...
Click to collapse
When I did only fastboot flash, I ended up twice with a system that somehow didn’t know which boot slot to boot to.
Each reboot it would boot into the different boot slot. The only thing that resolved this was to flash the factory image from google.
Even specifying the boot slot via fastboot did not alter this behaviour.
Somewhere in the q & a section someone is describing the problem too. It occured the first time after using fastboot flash kernel command.
almightysiman said:
can you disable storage force-encryption？thanks！
Click to expand...
Click to collapse
I will look into it.
ghostENVY said:
Are the safetynet patches implemented by any chance?
Click to expand...
Click to collapse
No I didn’t implement them yet. I will look into it.
Let us know when you'll have a flashable zip for this! Sounds good!
Thanks for another kernel option!
Sent from my Pixel XL using XDA Labs
Freak07 said:
When I did only fastboot flash, I ended up twice with a system that somehow didn’t know which boot slot to boot to.
Each reboot it would boot into the different boot slot. The only thing that resolved this was to flash the factory image from google.
Even specifying the boot slot via fastboot did not alter this behaviour.
Somewhere in the q & a section someone is describing the problem too. It occured the first time after using fastboot flash kernel command.
Click to expand...
Click to collapse
Well, I've been using that command since day 1. I've flashed countless times, it never failed to boot once...
franciscofranco said:
Well, I've been using that command since day 1. I've flashed countless times, it never failed to boot once...
Click to expand...
Click to collapse
are you running stock rom? I believe you, if you say, you never had issues.
I ran into the issue I described earlier. It would Change Slots upon each reboot and nothing except flashing back stock Google Image fixes it.
new kernel 0.2 is available
I added safetynet patch and another commit that may help with Performance
Download is here or in the OP
https://www.androidfilehost.com/?fid=529152257862702410
It's great to see development for our beloved Pixel XL! I'll be checking this out. I thank you friend!
Freak07 said:
It also includes a few Audio Patches from CAF.
Click to expand...
Click to collapse
Anything related to aptX Bluetooth?
CZ Eddie said:
Anything related to aptX Bluetooth?
Click to expand...
Click to collapse
Don’t know. What are you searching for exactly?
Hey
I updated the kernel to 0.3
Main changes are:
- Add GPU OC to 652mhz like the performance edition of our soc
- Update wake gestures
- Many new Performance Patches
- Updated dm verity
Download is here:
https://www.androidfilehost.com/?fid=745425885120707916
Lots of sweet features and commits. Definitely keeping my eye on this kernel. :good:
Can you make it TWRP flashable please?
Sent from my Pixel XL using XDA Labs