Related
Hello everyone!
Here is a little script I wrote for setting frequencies, voltages, governor and I/O scheduler in your phone running Nova ROM. Largely inspired by knzo's own script I decided to write my own for two reasons: understand the black magic behind it and teach myself the basics of shell scripting. To achieve this I got rid of the overhead and rewrote the remaining as shortly as possible. Since I've been the only one to test it so far I'd be really glad if anyone else gives it a try as well.
However, if you decide to go forward and give it a try, I'm going to assume that you're already advanced enough to know what you're doing. It doesn't hurt to backup your /data partition first and only then start experimenting. It's not unheard of to make a mesh of your data because services and applications crashed due to too much over-clocking or under-volting. If you're already familiar with knzo's and Huexxx's work then it's not going to kill you (or your phone). Anyway, be careful!
With that out of the way I'll say few words about the script itself. Here is how the main menu looks like:
Code:
MAIN MENU
1. Set frequency and voltage
[1100/54(54),800/44(44),600/34(35),300/20(24)]
2. Set governor [SmartassV2]
3. Set I/O scheduler [vr]
4. Set current values at boot
5. Reboot
0. Quit
The menu items speak mostly for themselves. Current values are fetched from corresponding system files and are shown in square brackets (with calibrated voltages in parentheses). The current values are there for you and visible inside sub-menus as well. After changing the values you have an option to set these values to be loaded at boot time and tell the phone to reboot as well to see if your choices are bootable.
Keep in mind that the choices you have made here may look stable while running the script and doing parallel stress testing perhaps but they may not be bootable! I've added a watchdog to guard you and if it so happens that your phone hangs while booting then the script will not apply your settings next time. Take out your battery and try again. If you're lucky then your /data partition is unaffected and you can go on unharmed. If you push it too hard then it is very likely you'll have to lean on your backups.
Back to introducing the script. What I did differently from knzo was the method how the settings are applied. No matter where and what you change, all the values are dynamically written to a separate script and then this script gets executed. The same script is used inside init.d and I had to add a condition there which checks if we are running from init.d or not. This has to do with the "stubborn" governor which gets overwritten by some process at boot. Therefore I added 15 second sleep there to set it just a little bit later.
Also different from knzo's script is the way how governor and scheduler choices are shown. Namely, these lists are created dynamically from available values.
The script also checks if you are root or not and tells you a friendly message if you need to su first.
About installing it. I haven't yet learned anything about how to install this script with as few hassles as possible and you'll have to get this script into your phone manually for now. Just copy this on your sdcard over the USB or bluetooth or any way you like, move it to /system/xbin for example, set execute permissions and run it. I'll definitely teach myself the ways of APK next. And will write a standalone application afterwards
And now for something technical. As this is my very first shell script ever then there are couple of things that might not be done most elegantly.
1) Boot detection relies solely on the existence of ANDROID_SOCKET_zygote environment variable which is empty now at boot and gets initialized sometimes later. Things will not work as intended any more if the Zygote decides to do something differently in the future. What would be better indicator here?
2) User detection uses stderr output from whoami which seems to be 'unknown uid 0' for root now and 'unknown uid 10008' for ordinary user. Is it OK to rely on that or is there a change that it'll say something else on other phones?
Well, that's it. The script itself is attached here and I tried to write some comments there as well to help you read it better.
I hope this is of some use to anybody besides me and thanks for reading so far. All your comments are very welcome!
Regards,
Aprold
Hi,
I'm not going to use it at least for now because I'm doing a battery marathon... and I dont' want to reboot my phone.
I'll take a look at the script to extract some useful knowledges for sure.
In order to make a flashable zip, it's so easy! Download my Huexxx's Nova v8 Stuff, decompress the zip and look inside. The most important thing is the update script, but is very easy.
You only have to modify the script, add or remove things to the folder structure and compress it with you favorite compressor into a zip. Thats all.
Regards and good work!
Another theme... Do you manually set your voltajes from the script?
Take a depp look at my UV posts (disasembling the Myth, UV script, Nova v8 Stuff) and you will learn some useful info regarding the fact that impose certain voltage values it useles taking into account that Smartreflex subsystem will set the values it wants!
Regards.
Setting voltages is manual job right now because there is really not much you can do automatically. This Smartreflex behaviour is quite limiting indeed. If you use higher voltages then calibrated voltages will be higher as well. If you try to go lower then you'll hit the wall somewhere where SR thinks it can't go lower any more. It would be possible to detect this "wall" automatically by decrementing vsel values and staying with values where calibrated voltages don't want to go any lower and I might just add this as a menu option to my script this evening and test if it is reliable with different voltages. I also tried to go outside the SR "window" and ended up hanging my phone every time. It seems to hold on to entered voltages only so far and if the difference grows too big it lets go. My "wall" values are around 54, 44, 34, and 24 (Huexxx's values were a little bit lower) and I fly out of the "window" with ~15 % lower values and the phone hangs.
EDIT:As Huexxx has corrected me below there is no way one can affect calibrated voltages when SR is active. Therefore I'm not going to modify my script, too.
aprold said:
If you use higher voltages then calibrated voltages will be higher as well.
Click to expand...
Click to collapse
I am in disagree with you... In my case, using different voltage values (from very high to ultra low according to the frevolt table supplied with nova) ended in the same calibrated values.
Regards.
I stand corrected. It is indeed so and then there is really nothing one can do to affect current voltages
aprold said:
I stand corrected. It is indeed so and then there is really nothing one can do to affect current voltages
Click to expand...
Click to collapse
This isn't entirely true... you can affect to current voltages in order to UV a little bit. If suggested voltaje by SR is 34, wou can push 33 or 32 without problems and SR effectively takes the value. This is what I've implemented with my Nova v8 Stuff, UV and AUV to set it on boot.
Regards.
Sadly this is not the case with my phone. The "wall" that I mentioned is around 54, 44, 34, 24 for me and I even if I try to lower the calibrated values are still the same ±1 depending on how the calibration went.
aprold said:
Sadly this is not the case with my phone. The "wall" that I mentioned is around 54, 44, 34, 24 for me and I even if I try to lower the calibrated values are still the same ±1 depending on how the calibration went.
Click to expand...
Click to collapse
Are 54, 44, 34 and 24 the calibrated values when you push stock voltages?
Then, if you try 53, 43, 33 and 23, it should take 53, 43, 33 and 23 with calibrated at least with some value... In my case sometimes one of the values stucks on stock calibrated one, but the rest do the job.
Regards.
Huexxx said:
Then, if you try 53, 43, 33 and 23, it should take 53, 43, 33 and 23 with calibrated at least with some value
Click to expand...
Click to collapse
Nope. I did a few measurements today and this is how it looks on my phone:
Code:
1100 800 600 300
1 [COLOR="Red"]66[/COLOR] [COLOR="Green"]55[/COLOR] [COLOR="Red"]56[/COLOR] [COLOR="Green"]45[/COLOR] [COLOR="Red"]46[/COLOR] [COLOR="Green"]35[/COLOR] [COLOR="Red"]36[/COLOR] [COLOR="Green"]25[/COLOR]
2 [COLOR="Red"]65[/COLOR] [COLOR="Green"]54[/COLOR] [COLOR="Red"]55[/COLOR] [COLOR="Green"]45[/COLOR] [COLOR="Red"]45[/COLOR] [COLOR="Green"]35[/COLOR] [COLOR="Red"]35[/COLOR] [COLOR="Green"]25[/COLOR]
3 [COLOR="Red"]64[/COLOR] [COLOR="Green"]54[/COLOR] [COLOR="Red"]54[/COLOR] [COLOR="Green"]45[/COLOR] [COLOR="Red"]44[/COLOR] [COLOR="Green"]35[/COLOR] [COLOR="Red"]34[/COLOR] [COLOR="Green"]25[/COLOR]
4 [COLOR="Red"]63[/COLOR] [COLOR="Green"]55[/COLOR] [COLOR="Red"]53[/COLOR] [COLOR="Green"]45[/COLOR] [COLOR="Red"]43[/COLOR] [COLOR="Green"]35[/COLOR] [COLOR="Red"]33[/COLOR] [COLOR="Green"]25[/COLOR]
5 [COLOR="Red"]62[/COLOR] [COLOR="Green"]55[/COLOR] [COLOR="Red"]52[/COLOR] [COLOR="Green"]45[/COLOR] [COLOR="Red"]42[/COLOR] [COLOR="Green"]35[/COLOR] [COLOR="Red"]32[/COLOR] [COLOR="Green"]25[/COLOR]
6 [COLOR="Red"]61[/COLOR] [COLOR="Green"]55[/COLOR] [COLOR="Red"]51[/COLOR] [COLOR="Green"]45[/COLOR] [COLOR="Red"]41[/COLOR] [COLOR="Green"]35[/COLOR] [COLOR="Red"]31[/COLOR] [COLOR="Green"]25[/COLOR]
7 [COLOR="Red"]60[/COLOR] [COLOR="Green"]54[/COLOR] [COLOR="Red"]50[/COLOR] [COLOR="Green"]45[/COLOR] [COLOR="Red"]40[/COLOR] [COLOR="Green"]35[/COLOR] [COLOR="Red"]30[/COLOR] [COLOR="Green"]25[/COLOR]
8 [COLOR="Red"]59[/COLOR] [COLOR="Green"]55[/COLOR] [COLOR="Red"]49[/COLOR] [COLOR="Green"]45[/COLOR] [COLOR="Red"]39[/COLOR] [COLOR="Green"]35[/COLOR] [COLOR="Red"]29[/COLOR] [COLOR="Green"]25[/COLOR]
9 [COLOR="Red"]58[/COLOR] [COLOR="Green"]54[/COLOR] [COLOR="Red"]48[/COLOR] [COLOR="Green"]44[/COLOR] [COLOR="Red"]38[/COLOR] [COLOR="Green"]34[/COLOR] [COLOR="Red"]28[/COLOR] [COLOR="Green"]25[/COLOR]
10 [COLOR="Red"]57[/COLOR] [COLOR="Green"]54[/COLOR] [COLOR="Red"]47[/COLOR] [COLOR="Green"]44[/COLOR] [COLOR="Red"]37[/COLOR] [COLOR="Green"]35[/COLOR] [COLOR="Red"]27[/COLOR] [COLOR="Green"]24[/COLOR]
11 [COLOR="Red"]56[/COLOR] [COLOR="Green"]53[/COLOR] [COLOR="Red"]46[/COLOR] [COLOR="Green"]44[/COLOR] [COLOR="Red"]36[/COLOR] [COLOR="Green"]35[/COLOR] [COLOR="Red"]26[/COLOR] [COLOR="Green"]24[/COLOR]
12 [COLOR="Red"]55[/COLOR] [COLOR="Green"]54[/COLOR] [COLOR="Red"]45[/COLOR] [COLOR="Green"]44[/COLOR] [COLOR="Red"]35[/COLOR] [COLOR="Green"]35[/COLOR] [COLOR="Red"]25[/COLOR] [COLOR="Green"]25[/COLOR]
13 [COLOR="Red"]54[/COLOR] [COLOR="Green"]54[/COLOR] [COLOR="Red"]44[/COLOR] [COLOR="Green"]44[/COLOR] [COLOR="Red"]34[/COLOR] [COLOR="Green"]35[/COLOR] [COLOR="Red"]24[/COLOR] [COLOR="Green"]25[/COLOR]
14 [COLOR="Red"]53[/COLOR] [COLOR="Green"]54[/COLOR] [COLOR="Red"]43[/COLOR] [COLOR="Green"]44[/COLOR] [COLOR="Red"]33[/COLOR] [COLOR="Green"]35[/COLOR] [COLOR="Red"]23[/COLOR] [COLOR="Green"]24[/COLOR]
15 [COLOR="Red"]52[/COLOR] [COLOR="Green"]54[/COLOR] [COLOR="Red"]42[/COLOR] [COLOR="Green"]44[/COLOR] [COLOR="Red"]32[/COLOR] [COLOR="Green"]35[/COLOR] [COLOR="Red"]22[/COLOR] [COLOR="Green"]24[/COLOR]
16 [COLOR="Red"]51[/COLOR] [COLOR="Green"]54[/COLOR] [COLOR="Red"]41[/COLOR] [COLOR="Green"]44[/COLOR] [COLOR="Red"]31[/COLOR] [COLOR="Green"]35[/COLOR] [COLOR="Red"]21[/COLOR] [COLOR="Green"]24[/COLOR]
17 [COLOR="Red"]50[/COLOR] [COLOR="Green"]54[/COLOR] [COLOR="Red"]40[/COLOR] [COLOR="Green"]44[/COLOR] [COLOR="Red"]30[/COLOR] [COLOR="Green"]35[/COLOR] [COLOR="Red"]20[/COLOR] [COLOR="Green"]24[/COLOR]
Reds are entered and greens are calibrated voltages.
And here is a small visual aid too:
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
aprold said:
Click to expand...
Click to collapse
You guys have too much free time!
Anyway, I do enjoy these statistics so keep them coming.
Seems that after all UV doesn't even work?
Look at this:
This is the result of my script into oscarbg13's OB from HtcMania. (Spanish forum). It seems to be working flawlessly.
Look at the data:
- In Current Calibrated Values you can see the calibrated Nova v8 voltages; the calibrateed voltages before my script. Look at the 4th value... it seems to be bad calibrated because 32 is the nominal value.
- In Current Recalibrated Values you can see the values after a recalibration. At this specific case, 1st and 2nd value are higher than previous, while 4th value has reached the correct value.
- With the last version of my script, I take the min walues between both calibrations for each frequency: 1st and 2nd from initial calibration, and 4th from recalibration.
- In New Calibrated Values we have the final values, and as you can see all of them are a unit lower than the minimal value for that frequency.
I'm going to do the last modification to my script in order to add a 'UV depth' and then get a custom UV. Then, setting the 'UV depth' to 0, what we gain is a syste to ensure:
- All the values are well calibrated.
- All the values use the minimal value suggested by smartreflex system without any UV.
Aprold, to say that in my case, when the phone is not recently booted, recalibration seems to don't properly work. The best time to recalibrate is at boot time.
Regards.
Huexxx, yes I have read your script and I understand what you're doing there. You simply take two sets of calibrated values and then try to set new voltages which are 1 less than minimum of these two. Perhaps this has some effect on some devices but as you can see from the graph above it doesn't really matter which values you set - the outcome is generally the same for me. The values I took for the graph were all from boot-time calibration. And I should say that drawing this graph in Excel 2010 brought up a lot of @%$%#'s and (%#&(^%'s because the last time I was using Excel 2003 for that kind of a job. Who came up with an idea of ribbon menu anyway?!?
aprold said:
Huexxx, yes I have read your script and I understand what you're doing there. You simply take two sets of calibrated values and then try to set new voltages which are 1 less than minimum of these two. Perhaps this has some effect on some devices but as you can see from the graph above it doesn't really matter which values you set - the outcome is generally the same for me. The values I took for the graph were all from boot-time calibration. And I should say that drawing this graph in Excel 2010 brought up a lot of @%$%#'s and (%#&(^%'s because the last time I was using Excel 2003 for that kind of a job. Who came up with an idea of ribbon menu anyway?!?
Click to expand...
Click to collapse
Once used to 2010 style, I like it so much!
Your case seems to be a aislated case, because I've probed my script on some OBs.
Can you try my script, with depth equal to 1 and post /data/nova/auto/avdlog here?
Regards!
Huexxx said:
Can you try my script, with depth equal to 1 and post /data/nova/auto/avdlog here?
Click to expand...
Click to collapse
Kind of dull result:
Code:
Current frequency values: 1100 800 500 300
Current calibrated values: 54 44 34 24
Current recalibrated values: 54 44 34 24
New calibrated values: 54 44 34 24
Tried it several times, once I saw 23 instead of 24 and once 43 instead of 44 there, but it really seems to be the limit for my phone
I'm sorry, your phone seems effectively to have a wall.
All I can say is that the situation is not the same for everybody, and your phone is the first I've seen with this behaviour.
Maybe the best feature of my script apart from apply or not a certain ammount of UV is the possibility to ensure that the four voltages are well calibrated.
I've seen some OBs (including mine) that at certain startup leave some uncalibrated voltages, and this can be the reason why some people report a excesive waste of battery in standby; maybe at the latest boot the voltage for min freq. was bad calibrated.
I'll enjoy a lot with Gingerbread, I think!
my /data/nova/auto/avdlog
Code:
Current frequency values: 1100 800 500 300
Current calibrated values: 53 43 32 23
Current recalibrated values: 53 43 32 23
Auto UV Depth: 1
New calibrated values: 53 42 31 22
And what does it mean?
redy2006 said:
my /data/nova/auto/avdlog
Code:
Current frequency values: 1100 800 500 300
Current calibrated values: 53 43 32 23
Current recalibrated values: 53 43 32 23
Auto UV Depth: 1
New calibrated values: 53 42 31 22
And what does it mean?
Click to expand...
Click to collapse
This mean:
- Your values seems to be well calibrated at startup, before my script, because the calibrated and recalibrated values are the same.
- When applying the UV, all goes well, because your 1100 max freq disables the UV over it (remains at 53) while the other values decrease one unit.
If all goes well and you don't experience any problems, you will be saving a bit at standby and at intermediate freqs too if your governor uses them. Of course don't expect so much, but everything help.
Look at my last boot:
Code:
Current frequency values: 900 700 500 300
Current calibrated values: 50 41 32 22
Current recalibrated values: 50 41 32 21
Auto UV Depth: 1
New calibrated values: 49 41 31 20
In my case look at min freq voltage, recalibrating it I've obtained 21, then the UV applied decrements it one unit to 20. In my case UV is applied to max freq too because is lower than 1 GHz.
Regards.
---------- Post added at 03:57 PM ---------- Previous post was at 03:56 PM ----------
Maybe this discussion would be moved to my thread... We are flooding aprold's thread!
What is the best %(size) of swappiness? i have 60 now how about 30 or 40
goldenr said:
What is the best %(size) of swappiness? i have 60 now how about 30 or 40
Click to expand...
Click to collapse
Definition: Swappiness is tendency of kernel to move memory(Real ram) to swap partition/file.
So, Swappiness 100 = move to swap partition/file more. (Many ram, high latency)
Swappiness 0 = move Don't move unless memory(Real ram) is really full. (Less ram, low latency)
So, heavy game = Swappiness 50-100 (Noticable lag at start but, smooth later on)
Smooth operation = Swappiness 0-50
m_plus kernel for Nexus 4 (mako)!
Hi all, since _motley has been MIA of late and his work was my favorite kernel for the Nexus 4, I have decided to continue his work in his absense. As a result much of this thread will look very similar to _motley's original thread here: http://forum.xda-developers.com/showthread.php?t=2021437. I would like to personally thank _motley for his work and dedication to this project, I only hope I can keep his loyal users happy in his absence.
Disclaimer: As usual, I am not responsible for anything that may or may not happen to your device as a result of using this kernel or any other flashable zips posted by me in this thread.
Features
Highly customizable with scripts. See post #2 for all the tuning options.
Google 3.4 base. All stock features are of course supported (camera, NFC etc.)
Compiler optimizations (-O2 + others) - using 2012.12 Linaro toolchain
Full ramdisk install with init.d support for stock/AOSP (CM already has support, for stock you must install busybox!)
CPU Overclock steps 1.56, 1.62, and 1.67GHz (default freq is still stock on boot, OC is optional)
304MHz lowest CPU freq step added with lower voltage than stock, since the device spends a lot of time at this frequency.
Safe UV by default for nominal, fast, and faster binned chips.
Voltage control - be careful to not save the setting on boot until you are 100% sure it is stable! (thanks faux123! + my tweaks)
In-kernel auto_hotplug (thanks to thalamus). I have added and exposed all the tuning parameters and a debug mode to userspace.
Customized in-kernel thermal solution smart scaling, dynamic polling, and configurable throttle temp.
Custom PowerHAL module (spam-free Android log from PowerHAL events)
Controllable touchboost frequency and duration
Gamma and Sound control (thanks faux123!)
Fsync control (3 modes)
USB Force Fast Charge
I/O schedulers - SIO(optimized), deadline (optimized), row, cfq, noop, and fiops
TCP Congestion Control (several choices available) - veno is the default
Governors - Interactive (default), OnDemand, PowerSave, Conservative
CIFS, NFS, NTFS r/w, TUN - built-in, no need for any kernel modules
Other misc patches and tweaks (see github link at the bottom of this post)
GPL compliant - source is kept up to date at github.com and released at the time the kernel is released to the public via this post. Demand that other devs do the same!
Requirements (please read carefully and visit the other dev threads as necessary)
Boot-loader must be unlocked and you must have a custom recovery installed (CWM or TWRP).
Have your ROM zip on your /sdcard so you can restore your whole ROM if necessary.
Do a complete backup using custom recovery so you can restore your boot.img and ROM if necessary!
System Tuner is recommended for monitoring/tuning the CPU, especially for voltage control. Other kernel apps like faux123's will likely work as well, but they have not been tested.
AOSP ROMs including stock - for init.d support, you must have a working busybox install in /system/xbin.
Installation
Check the requirements above and read release notes below for the build # you are installing for any extra instructions!
If coming from another kernel, read the instructions in red below and follow them before flashing.
Flash the the kernel zip using your custom recovery.
Optional: if you want to revert back to what you had, restore your backup of your boot.img in recovery. Another option for reset back to stock is to flash the stock reset zip above. For other custom ROMs, dirty flash your custom ROM in recovery to get your default kernel and ramdisk back.
If you have issues and are coming from another custom kernel or ROM, follow these instructions first before the install. Many custom kernels are changing the ramdisk or other binaries that require a reset before moving back to stock or another kernel.
Reset for Stock ROM - flash this reset package that includes the stock kernel, ramdisk, thermald, mpdecision, and PowerHAL binary. This can also be used if you are using the stock ROM and want to go back to stock.
Download - N4_422_stock_kernel_and_components.zip
MD5 - f801fc7702e29d85447e9b6fdc880549
Reset for any non-stock ROMs like CM, AOKP etc - dirty flash your current ROM or nightly zip then your gapps in recovery (just flash, no wiping). This will give you back your original ramdisk, kernel, and other binaries that other kernel devs may have tweaked, renamed, replaced etc.
Builds
Personal Request: If you plan to make unofficial builds with features not included in the builds posted by me, please don't link them in the thread, all this does is result in confusion especially if someone has a problem with something you have added, it is much easier for me to provide support if I know that everyone in the thread is running the same builds I am. If you want to make a kernel with these features, feel free to start another thread so that they can be discussed and supported as appropriate.
Current Buildbot Status:
Source: https://github.com/thracemerin/kernel-Nexus4
As with _motley's builds, the stable version will be a base build which includes the ramdisk and other component binaries to make the kernel work as expected, you will need to flash the stable version prior to flashing any experimental versions or something may not work as expected.
All files are now available from goo.im: http://goo.im/devs/thracemerin/mako/m_plus
Note: Due to goo.im file naming rules I had to change the name of the zip to m_plus from m+, this has no effect on the content, the ones on goo.im are identical to those that were on dev-host other than the names.
Change Logs
Note: The builds below are for 4.2.2 only, for the latest 4.3 alpha builds check the last few pages of the thread. *4.3 builds will appear on goo.im when they are closer to being official production builds.
This thread is for 4.2.X versions only, use the following threads for 4.3:
JW Builds: Thread not available yet, Alpha 3 is still here: http://forum.xda-developers.com/showpost.php?p=43993185&postcount=860
JS Builds: http://forum.xda-developers.com/showthread.php?t=2385840
Build 10 (Exp) - July 15, 2013
Note: You must be on Build 1 or later. (Build 8 if you are on MIUI)
Various patches to the kernel to prevent out of bounds access to memory (see github for details)
Added sweep2wake, it is disabled by default, see post 2 for info (thanks to show-p1984)
Added a patch to fix some unusual behavior with the LEDs (thanks to CM)
Build 9 (Exp) - July 3, 2013
Note: You must be on Build 1 or later. (Build 8 if you are on MIUI)
Added the simple GPU governor for Qualcomm Adreno GPUs thanks to Faux123 (set as default, no need for the script required in the Alpha). Tunables explained in Post 2.
Build 8.1 (Exp) - June 20, 2013
Note: You must be on Build 1 or later. (Build 8 if you are on MIUI)
Actually reverted some of the msm_hsic patches because they seem to cause data drops (I only pretended I did in Build 8, oops )
Build 8 (Exp) - June 18, 2013
Note: You must be on Build 1 or later.
Reverted some of the msm_hsic patches because they seem to cause data drops
Now build with the Linaro 4.8.2.2013.06 toolchain
Switched the allocator from SLUB to SLAB because SLUB wouldn't boot when compiled with 4.8
Various fixes to allow building with 4.8
Build 7 (Exp) - May 26, 2013
Note: You must be on Build 1 or later.
goo.im seems to be a little flaky this afternoon, alternative downloads here: http://forum.xda-developers.com/showpost.php?p=41865828&postcount=416
Patches to freezer from Colin Cross
More patches to workqueue from CAF
Patches to the cpufreq driver from CAF
Reverted lowest frequency step to 384MHz (See Post 3 for why)
Fixed board-mako-regulator.c to allow for UV to work (Warning: Reset your UV settings if you have UV below 850mV, if you flashed the previous alphas this is probably not necessary.)
Reset undervolting to stock from Google, just in case the above causes problems for new adopters (You still have full access to undervolt to 600mV if your chip can handle it)
Added the change pointed out by veyka here: http://forum.xda-developers.com/showpost.php?p=41730297&postcount=380
Some more patches to the hsic controller that were in my other project but not this one.
Build 6 (Exp) - May 19, 2013
Note: You must be on Build 1 or later.
CAF changes to cpufreq
CAF changes to workqueues
Build 5 (Exp) - May 12, 2013
Note: You must be on Build 1 or later.
CAF patches to block.
CAF patches to the charging and battery management system.
CAF patches to the video driver.
Build 4 (Exp) - May 5, 2013
Note: You must be on Build 1 or later.
A few more sched patches from CAF
Patches to android lowmemory killer from CAF
Headphone poweramp controls (thanks to Faux123)
Build 3 (Exp) - May 3, 2013
Note: You must be on Build 1 or later.
Various sched patches that were in _motley's 4.2.1 kernel and not his 4.2.2 kernel
FIOPS i/o scheduler is back
192mhz frequency step added (thanks to showp1984)
Note: The ramdisk currently forces the minimum to 304mhz so i added an init.d script to force it to 192mhz so I didn't have to redo the ramdisk.
I'll fix this in the next base build.
If you still want to use 304mhz as your lowest step, see post 3 for details on how to do this.
Note 2: The voltage is the same as the one _motley used for 304mhz for stability reasons, it will still use less power, but feel free to uV it if you like.
Build 2 (Exp) - April 30, 2013
Note: You must be on Build 1 or later.
Update ROW i/o scheduler to the latest from CAF, now default i/o scheduler
FIOPS i/o scheduler was removed because _motley added FIOPS and ROW as 1 commit and messing with ROW screwed it up.
Hardcode ROW magic values (thanks to franciscofranco & osm0sis)
Update interactive governor to the latest from CAF (it may be a little less aggressive)
Krait Retention (thanks to CAF, faux123)
Build 1 (Base) - April 29, 2013
Everything from _motley's b49 build up to this point.
Built with the linaro 2013.04 gcc-4.7 toolchain
Thanks
Google - For AOSP sources
LG - for building the N4
Qualcomm/CAF - for their updates to the N4 kernel
_motley - for all his work on this kernel
faux123 - patches included that were initially written by him
franciscofranco - patches included that were initially written by him
showp-1984 - patches included that were initially written by him
anyone else i've neglected to include, if you feel you deserve to be thanked by name by all means PM me
Tunables should be the same as _motley's kernel so I'm quoting him here:
(All the tunables that are discussed in _motley's thread http://forum.xda-developers.com/showthread.php?t=2021437 should work the same way on this kernel)
_motley said:
Setting custom RGB color settings via sysfs
This can be done from the adb shell on your PC, or any terminal app. If you change them, they will not persist after a reboot. However, you can set them in an init.d script if you found another color combination that you like better than the one I have used.
Code:
echo "255 255 255" > /sys/devices/platform/kcal_ctrl.0/kcal
echo 1 > /sys/devices/platform/kcal_ctrl.0/kcal_ctrl
Command 1 sets the color and Command 2 commits them. Stock is 255 255 255.
Setting custom Gamma settings via sysfs - Exp kernel build 31+ only - thanks to faux for sharing his code
Warning: changing these values can be potentially be dangerous to your display if you make a mistake. For those that feel comfortable with what they are doing and want to experiment, please report back and share your findings.
Important, please read!
There are ten digits in the string separated by one space
First digit is a checksum and is never stored. The checksum is simply the sum of the other 9 numbers. This is to make it harder to so the interface is respected and you are forced to think about what you are doing.
There are 3 sysfs interfaces for gamma, one for each color:
Code:
#!/system/bin/sh
# Show the current configuration and the checksum
cat /sys/devices/platform/mipi_lgit.1537/kgamma_red
cat /sys/devices/platform/mipi_lgit.1537/kgamma_green
cat /sys/devices/platform/mipi_lgit.1537/kgamma_blue
Update:
Recently molesarecoming started opening this up and showing us what the values can be used to adjust. Franco then suggested that the white and grays should be swapped in moles original work. So, for init.d values using this interface, we have the following "banks" if values if we agree with Franco on the swap of the whites and grays.
Code:
R: checksum, g_white, g_mids, g_black, 0, g_contrast, g_brightness, g_saturation, g_grey, 2
G: checksum, g_white, g_mids, g_black, 0, g_contrast, g_brightness, g_saturation, g_grey, 2
B: checksum, g_white, g_mids, g_black, 0, g_contrast, g_brightness, g_saturation, g_grey, 2
(the zero in position 5's and the 2's in position 10 are recommended to be left alone since they are currently unknowns)
Minus the checksum, the 27 values mirror the 3 color arrays (3 x 9 = 27) in the actual LG LCD driver. Minus the unknowns, we are left with 21 values. Note that every one of the variables can have their value tweaked by color (saturation for red, saturation for green etc.), however, it is recommended that you start with all the values of one type being the same and then tweak from there if you really want to fine tune.
You have a lot of power in your hands even without fine tuning. Many will argue that fine tuning isn't required. If you look at the stock settings by Google in post 2, they took advantage of fine tuning for whatever reason. Even though many don't like these settings by Google, it shows how flexible the interface can be.
Instructions:
1) Start with a preset config (LG or Google) as shown further below. This is a set of 3 lines, 10 numbers for each line.
2) Tweak columns for their values as above. For example, we tweak contrast and brightness as in faux's original app. We could also do the same for saturation, blacks, whites, grays etc.
Example: start with LG presets with numbers to adjust:
383 114 21 118 0 10 4 80 48 2
383 114 21 118 0 7 4 80 48 2
383 114 21 118 0 5 1 80 48 2
3) Now update the checksum in column 1 (first digit = sum of last 9 digits)
397 114 21 118 0 10 4 80 48 2
394 114 21 118 0 7 4 80 48 2
389 114 21 118 0 5 1 80 48 2
4) Create a script inside a text file - my recommendation for your first test
Code:
#!/system/bin/sh
# Set data color pro presets from shared Google spreadsheet (thanks user acer73!)
# Use LG presents as your starting values and then adjust columns 6 & 7 from the spreadsheet
echo "397 114 21 118 0 10 4 80 48 2" > /sys/devices/platform/mipi_lgit.1537/kgamma_red
echo "394 114 21 118 0 7 4 80 48 2" > /sys/devices/platform/mipi_lgit.1537/kgamma_green
echo "389 114 21 118 0 5 1 80 48 2" > /sys/devices/platform/mipi_lgit.1537/kgamma_blue
#Set the complimentary RGB values for this calibration
echo "248 248 248" > /sys/devices/platform/kcal_ctrl.0/kcal
echo 1 > /sys/devices/platform/kcal_ctrl.0/kcal_ctrl
5) Run the script (or you can echo each line manually to test from adb if you prefer).
6) Turn the screen off and on for the gamma change to take effect.
7) Check the dmesg output for any clues and to see the output of the result.
8) Place the script into your /system/etc/init.d/ folder (or equivalent) for a permanent color change!
Screen refresh (added in b37) - this should only be called by apps or scripts while adjusting and testing colors "live" with the motley or faux sysfs interface. It should NOT be implemented on startup via init.d or by apps since it will compete with the normal power on process.
Code:
echo 1 > /sys/devices/platform/mipi_lgit.1537/refresh_screen
Presets:
Code:
#!/system/bin/sh
# Set LG presets (motley stock) - i.e. popular partial revert of Google's tweaks just before release
echo "383 114 21 118 0 0 0 80 48 2" > /sys/devices/platform/mipi_lgit.1537/kgamma_red
echo "383 114 21 118 0 0 0 80 48 2" > /sys/devices/platform/mipi_lgit.1537/kgamma_green
echo "383 114 21 118 0 0 0 80 48 2" > /sys/devices/platform/mipi_lgit.1537/kgamma_blue
Code:
#!/system/bin/sh
# Set stock Google presets (from kernel source code)
echo "332 64 68 118 1 0 0 48 32 1" > /sys/devices/platform/mipi_lgit.1537/kgamma_red
echo "332 64 68 118 1 0 0 48 32 1" > /sys/devices/platform/mipi_lgit.1537/kgamma_green
echo "364 32 35 116 0 31 16 80 51 3" > /sys/devices/platform/mipi_lgit.1537/kgamma_blue
Spreadsheet with shared settings
https://docs.google.com/spreadsheet/ccc?key=0AoDp2qRui0u0dGE4T2gtSDBTRHVFSldPS2RrX1Rya0E#gid=0
FSYNC Control
Notes: I thought about combining these options, but many kernel apps already support these two options. So, I have them both and they can be controlled in combination to give us the 3 modes. If you set fsync_enabled = 0 it will be OFF regardless of how Dyn_fsync_active is set.
3 Modes:
Dynamic (default in b35 and higher)- fsync is asynchronous when screen is on, when screen is off it is committed synchronously
dynamic fsync ON
fsync ON
Code:
echo 1 > /sys/kernel/dyn_fsync/Dyn_fsync_active
echo 1 > /sys/class/misc/fsynccontrol/fsync_enabled
Off (best performance, less safe) - fsync is always asynchronous (b32 and prior builds)
dynamic fsync OFF
fsync OFF
Code:
echo 0 > /sys/kernel/dyn_fsync/Dyn_fsync_active
echo 0 > /sys/class/misc/fsynccontrol/fsync_enabled
Stock (safest) - fsync is always committed synchronously
dynamic fsync OFF
fsync ON
Code:
echo 0 > /sys/kernel/dyn_fsync/Dyn_fsync_active
echo 1 > /sys/class/misc/fsynccontrol/fsync_enabled
There is a lot of info out there on fsync, that will not be discussed here. I have run fsync off on several devices for awhile now and haven't experienced any issues. If you are using a device that is not stable and crashes alot, I recommend enabling it via init.d or script manager on boot. Hopefully your N4 is as stable as is mine.
USB Force Fast Charge
You can turn it on with popular apps (like Trickster MOD) that support the common sysfs toggle as shown below.
If you don't like it or don't want to use it, it is off by default.
Turn ON:
Code:
echo 1 > /sys/kernel/fast_charge/force_fast_charge
Turn OFF:
Code:
echo 0 > /sys/kernel/fast_charge/force_fast_charge
Notes:
When it is ON, you will not be able to connect your phone to your PC (adb, mtp etc.). This is expected behavior.
To start charging: turn fast charge ON, plug the USB cable into your PC, and charge up.
To stop charging: unplug the USB cable and turn fast charge OFF. Now you can plug back into your PC for normal trickle charging, adb/mtp etc.
Tip: if you see it connect to your PC (media device or adb), it isn't working. Unplug the cable, wait a couple seconds and plug it in again.
Boostpulse control - Experimental build only
Trickster MOD works great to play with these.
How long does it boost when Android senses touch? (in b10 and b14 it is above_hispeed_delay)
Code:
/sys/devices/system/cpu/cpufreq/interactive/boostpulse_duration
What freq does it boost to?
Code:
/sys/devices/system/cpu/cpufreq/interactive/hispeed_freq
Turn touchboost OFF/ON (in b10 and b14 only)
Code:
/sys/devices/system/cpu/cpufreq/interactive/input_boost
Thermal Throttling and Hotplug Control - Experimental build only
Warning: these do not have to be changed from the defaults and could potentially be dangerous if you make a mistake. For those that know what they are doing and want to experiment with settings, scripts etc. please report back your findings.
msm_thermal:
Throttle temp in C. Default is 70, valid range is 45 to 80 (recommend to not go over 75):
Code:
/sys/module/msm_thermal/parameters/throttle_temp
Minimum freq used in throttle down before returning to max, default is 7 = 1.13GHz. Range is 4 to 8 (810Mhz to 1.24GHz)
This is the index in the frequency table as seen in Trickster MOD, System Tuner etc. It is zero based (i.e. 304MHz is zero).
Code:
/sys/module/msm_thermal/parameters/min_freq_index
Turn on thermal debugging so you can see what is happening in the kernel log:
Code:
/sys/module/msm_thermal/parameters/thermal_debug
auto_hotplug:
Load based hotplugging parameters. I have taken _thalamus' base (thanks!) and have exposed most of the tuning parameters to userspace.
Turn off/on hot_plug debugging Y/N, default N, this spams the kernel log like crazy, turn on only when troubleshooting/testing
Code:
/sys/module/auto_hotplug/parameters/debug
Load at which a CPU is taken offline, 40-125, default 80:
Code:
/sys/module/auto_hotplug/parameters/disable_load_threshold
Load at which an extra CPU is put online, 130-250, default 200:
Code:
/sys/module/auto_hotplug/parameters/enable_load_threshold
Load at which all CPU's are enabled, 270-550, default is 400 (or 100 x number of cores):
Code:
/sys/module/auto_hotplug/parameters/enable_all_load_threshold
Sample rate in milliseconds, converted to jiffies at runtime, 10-50ms, default 20:
Code:
/sys/module/auto_hotplug/parameters/min_sampling_rate
Number of samples in the circular buffer, 5-50, default 10 (more samples = less aggressive; less samples = more aggressive):
Code:
/sys/module/auto_hotplug/parameters/sampling_periods
Maximum number of cores online (regardless of load) when screen is on, 1-4, default 4 (tune down for battery savings):
Code:
/sys/module/auto_hotplug/parameters/max_online_cpus
Minimum number of cores online (regardless of load) when screen is on, 1-4, default 1 (tune up for performance/bench-marking):
Code:
/sys/module/auto_hotplug/parameters/min_online_cpus
Vibration Intensity
You can also use Trickster MOD to set this.
Example increase intensity:
Code:
echo "90" > /sys/class/timed_output/vibrator/amp
To go back to stock:
Code:
echo "70" > /sys/class/timed_output/vibrator/amp
Why are the base voltage tables different on some phones
What CPU do you have? Nominal, Fast, Faster ...or Slow
The phones with the lower default voltage values use the "fast" or "faster" frequency table, consider yourself lucky. This explains why some can't UV as much as others since they are starting with lower mV's to start. These are built in factory tolerances that depend upon the binning of your chip. I am familiar with the same thing in the tegra3 world where I have had more experience. So, don't worry as this is commonly done in this industry. Hopefully folks don't go freaking out because they have a nominal chip like I do. It's probably good for a dev to have a nominal chip so we can better honor the limits.
http://en.wikipedia.org/wiki/Product_binning
How do I tell what I have?
If you boot up your phone fresh and look at the dmesg output (kernel log) while the messages are still there, you will find one of the following output messages where it selects it's frequency plan depending on the binning of the chip.
Code:
adb shell dmesg | grep PVS
acpuclk-8064 acpuclk-8064: ACPU PVS: Nominal
-or-
acpuclk-8064 acpuclk-8064: ACPU PVS: Fast
-or-
acpuclk-8064 acpuclk-8064: ACPU PVS: Faster
-or-
acpuclk-8064 acpuclk-8064: ACPU PVS: Slow
I have tweaked all the frequency tables nominal, fast, and faster (as well as slow to compensate for the lower freq) to keep them similarly scaled relative to stock. If you don't like the safe defaults (already UV'ed), then use voltage control and come up with your own preferred values.
Click to expand...
Click to collapse
C State Information
(thanks to faux123 - more info here: https://plus.google.com/109078966818501160423/posts/9R8fjQdHDXD)
faux123 recommends C0, C1 and C3 here: http://forum.xda-developers.com/showpost.php?p=40151528&postcount=9775
C0 (WFI) - Shallowest Sleep (default enabled)
Code:
enable: echo 1 > /sys/module/pm_8x60/modes/cpu0/wfi/idle_enabled
disable: echo 0 > /sys/module/pm_8x60/modes/cpu0/wfi/idle_enabled
C1 (Retention) - slightly deeper sleep
Code:
enable: echo 1 > /sys/module/pm_8x60/modes/cpu0/retention/idle_enabled
disable: echo 0 > /sys/module/pm_8x60/modes/cpu0/retention/idle_enabled
C2 (Stand Alone Power Collapse) - deeper sleep
Code:
enable: echo 1 > /sys/module/pm_8x60/modes/cpu0/standalone_power_collapse/idle_enabled
disable: echo 0 > /sys/module/pm_8x60/modes/cpu0/standalone_power_collapse/idle_enabled
C3 (Power Collapse) - deepest sleep
Code:
enable: echo 1 > /sys/module/pm_8x60/modes/cpu0/power_collapse/idle_enabled
disable: echo 0 > /sys/module/pm_8x60/modes/cpu0/power_collapse/idle_enabled
Simple GPU Governor Tunables
Code:
/sys/module/msm_kgsl_core/parameters/simple_laziness
Laziness: Adjusts the number of times the governor skips ramp down requests. (Higher = better performance, higher battery drain)
Code:
/sys/module/msm_kgsl_core/parameters/simple_ramp_threshold
Threshold: Adjusts the threshold to ramp up or down the GPU frequencies. (Lower = better performance, higher battery drain)
To enable sweep2wake:
Code:
echo 1 > /sys/android_touch/sweep2wake
Frequently Asked Questions
Q: You gave us 192Mhz, now you removed it and set 304Mhz back to 384Mhz, why?
A: Good question, there had always been some speculation in this thread and others that frequencies below 384Mhz were not in fact being set correctly, show-p1984 managed to run his device at 27Mhz with no stability issues (this should be impossible) so we did some quick and rather unscientific benchmarking in this thread and found that there didn't seem to be any difference in CPU performance between 192Mhz and 304Mhz (and there should have been), I then speculated that 304Mhz was also not being set, after a little more unscientific benchmarking I determined that there was no difference in performance from 304Mhz to 384Mhz either, so based on this I don't see any reason to allow these frequencies.
Q: I don't want to use the 192mhz frequency, how can I disable it? (Build 3-6)
A: One of the four options below will fix it:
You can delete my script, it's located at /system/etc/init.d/01cpu and reboot, this will set you back to 304mhz minimum.
You can remove it from the zip file (same location in the zip hierarchy) before you flash.
You can use your favorite kernel tuner (trickster, fauxclock, etc...) to switch the minimum frequency back to 304mhz and set it on boot.
You can change the /system/etc/init.d/01cpu script to set whatever minimum frequency you want (it has to be a valid one from the table)
Q: If the 192mhz and 304mhz steps use the same undervolt settings, how can 192mhz use less power?
A: The formula for power consumption is: P = f * c * V ^ 2
Where: P = power consumption, f = frequency, c = capacitance and V = voltage
So: since c is constant in this case, and we'll assume you've used the lowest UV possible (600mV)
At 304mhz: P = 304 * c * 600 ^ 2
At 192mhz: P = 192 * c * 600 ^ 2
This means that 304mhz uses approximately 1.58 times more power than 192mhz over the same time.
Q: There are a bunch of fixes for the delayed notification issues in various threads, what should the settings be for this kernel?
A: The following values should be set in your /system/etc/wifi/WNCSS_qcom_cfg.ini (depending on your ROM you may have different values), these are the Google stock values and appropriate for this kernel.
Code:
McastBcastFilter=3
HostArpOffload=0
gEnableSuspend=3
You can set these values by flashing this: wlan_revert.zip - MD5 - 381013687035626bcb1cbaf609ea4311
Q: Does this kernel include the ARP offload patch?
A: No, and for those of you following my other thread here: http://forum.xda-developers.com/showthread.php?t=2102986 you will know that there is an issue where our WiFi chip responds to ARP requests with a bad MAC address during deep sleep, this results in problems with direct connect (WiFi direct, AirDroid, etc...) and can cause issues with certain types of routers and networks that do not cache ARP addresses for long, as a result I no longer use it in my other kernel either. I am using a different solution which solves the problem for me and many others but has a slight battery life hit, I will post a flashable zip to modify the binaries to include this fix at a later time, but for now if you wish to include this fix do the following.
Code:
open /system/etc/wifi/WNCSS_qcom_cfg.ini in your favorite file editor
find the line that currently reads gEnableSuspend=3
change the line to read gEnableSuspend=2
save the file
reboot your device.
Q: I flashed this kernel and my battery life sucks! WTF?
A: Clearly I didn't design this kernel to drain your battery (nor did _motley) and in my experience most battery drain issues are app related and not kernel related. In order to help me help you solve the problem, please download Better Battery Stats either from the Play Store (costs money, but I strongly encourage supporting the dev) or the free version from XDA and provide me with a dump file for a few hours of use so I can see what is going on with your device, if you don't do this I will assume the battery drain is your fault and will ignore your complaint.
Q: Can you add feature x from kernel y?
A: Maybe, I'm not going to take this kernel and stuff it full of every single idea anyone has while lying in bed trying to fall asleep, but if the feature seems like something that most would use and it's in a reasonable state of working (ie. not something that someone else just started working on) then I will consider adding it, absolutely no promises in this regard.
Q: I got a random reboot, SOD, other bug that must be kernel related, what do I do?
A: Provide me with appropriate logs (dmesg, logcat, last_kmsg (see my sig)) and instructions on how you caused this if possible, if I can't reproduce the issue and I can't see it in the logs there is nothing I can do. Be as detailed about what you were doing at the time it happened, more information is always better than less.
Q: If _motley comes back what will happen with this project?
A: Well, I don't want to step on any toes here, this was originally _motley's work, what happens to it long term if he returns will ultimately be up to him. If he wants to continue from where he left off and merge his own changes beyond b49, I may keep going as a separate project, if he wants to fork me and continue from the point I'm at when he returns that's ok with me too and I'd probably stop if that were the case, but we're speaking in hypotheticals here, anything is possible.
Q: Touch control doesn't work! Why not?
A: Touch control requires a module that is compiled by the author and provided as a pre-compiled binary. I'm not specifically looking to break it's functionality, but changes I make may cause it to stop working at any time between releases, the only way to get this fixed is to speak to the author of the addon and have him recompile the module. If he needs my assistance with anything specific to this kernel, I will do my best to help him out.
Pre-release (Alpha) Builds
These builds are the latest builds produced by the buildbot from the wip branch.
WARNING: These builds should be considered alpha, may contain a lot of bugs, may be unstable, and may be partially or completely non-functional. That being said, I am usually running these builds so if they are really badly broken I'll remove them ASAP.
http://goo.im/devs/thracemerin/mako/m_plus/wip
Current Buildbot Status:
Current Alpha: None, use Build 10!
What's changed:
Thanks for continuing Motleys kernel, waiting for links to download and flash.
Build 1 is up, happy flashing :victory:
Thank you very much for the kernel, I'm glad to see the motley's great work doesn't get forgotten.
PS: a benchmark for the ones that like it, stock settings and sabermod rom.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
I hope _motley is alright. Thank you for continuing to develop this great kernel in his absence.
Will you be including the new Prima drivers and retention patches introduced by kszaq to fix some of the wifi problems? I know it's not a solution for everyone, but I personally thought it worked well with no battery hit and some others seem to agree.
Anyway, thank you for your work and good luck with _m+ .
mko000 said:
I hope _motley is alright. Thank you for continuing to develop this great kernel in his absence.
Will you be including the new Prima drivers and retention patches introduced by kszaq to fix some of the wifi problems? I know it's not a solution for everyone, but I personally thought it worked well with no battery hit and some others seem to agree.
Anyway, thank you for your work and good luck with _m+ .
Click to expand...
Click to collapse
Krait retention, yes.
Prima/ARP Offload, not right now, there is a workaround and better explanation for why in post 3, I'll continue to work on it in my other thread, if I get to a fully working solution, then absolutely. The current issue with the Prima driver makes my phone unusable for something I do on a daily basis which is why I will not do it currently (I want to be able to use this kernel as my daily driver).
Flashed the CM build, all fine thanks! Felt the smoothness of Motleys kernel again.
Very nice! Um, I took a look at your git, but i couldn't work out what you added over b49 heh, mind giving a quick summery?
Sent via Nexus 4
veyka said:
Very nice! Um, I took a look at your git, but i couldn't work out what you added over b49 heh, mind giving a quick summery?
Sent via Nexus 4
Click to expand...
Click to collapse
Nothing atm, this release was just a stable start to move forward on and proof that I had the infrastructure set up to actually build with linaro gcc-4.7. I'll have another release in a day or two with some new stuff
Plus, it avoids having to get people to get b37 & b49 from _motley's thread before moving forward with builds here.
thracemerin said:
Nothing atm, this release was just a stable start to move forward on and proof that I had the infrastructure set up to actually build with linaro gcc-4.7. I'll have another release in a day or two with some new stuff
Plus, it avoids having to get people to get b37 & b49 from _motley's thread before moving forward with builds here.
Click to expand...
Click to collapse
Cheers! So i wasn't being a brainless derp then
Sent via Nexus 4
thracemerin said:
Krait retention, yes.
Prima/ARP Offload, not right now, there is a workaround and better explanation for why in post 3, I'll continue to work on it in my other thread, if I get to a fully working solution, then absolutely. The current issue with the Prima driver makes my phone unusable for something I do on a daily basis which is why I will not do it currently (I want to be able to use this kernel as my daily driver).
Click to expand...
Click to collapse
Hey fellow super android lol nice work with this kernel. I'm gonna give this a whirl and see how it performs. Thanks for continuing motley's kernel.
thracemerin said:
Nothing atm, this release was just a stable start to move forward on and proof that I had the infrastructure set up to actually build with linaro gcc-4.7. I'll have another release in a day or two with some new stuff
Plus, it avoids having to get people to get b37 & b49 from _motley's thread before moving forward with builds here.
Click to expand...
Click to collapse
I guess I'll wait a few more days then
Sent from my Nexus 4 using xda app-developers app
iamhacked said:
I guess I'll wait a few more days then
Sent from my Nexus 4 using xda app-developers app
Click to expand...
Click to collapse
I can push build 2, I just haven't tested it hardly at all and if it blows someone's device up I'd feel bad.
thracemerin said:
I can push build 2, I just haven't tested it hardly at all and if it blows someone's device up I'd feel bad.
Click to expand...
Click to collapse
take your time. dont rush. i know people are chomping at the bit for something new but ignore them.
or post a test build and let us blow up our phones haha :good:
Hi, if I may make a request, do you think it's possible to lower the minimum allowed voltage?
Sent from my Nexus 4 using xda app-developers app
Logi_Ca1 said:
Hi, if I may make a request, do you think it's possible to lower the minimum allowed voltage?
Sent from my Nexus 4 using xda app-developers app
Click to expand...
Click to collapse
It's 600mV right now, correct?
Yup, it's 600mv now. I was thinking that since the phone spends most of its time at 384mhz, and for me that frequency is totally stable at 600mv, it's probably possible that the voltage at 384mhz can go even lower. However I noticed that most of the other kernels have higher minimum allowed voltages, so there may be a reason for that that I'm not seeing here.
Sent from my Nexus 4 using xda app-developers app
I use the 900F version. For most of us, the phone is more asleep than it' s in operation. That's why choosing the correct ROM & Kernel is essential for your battery.
I wanted to figure out which ROM is best regarding battery life when the screen is off and how to reach the best result.
Calculation:
BetterBatteryStats Calculation.
If I look at my stats: View attachment BetterBatteryStats-2016-10-18_184154319.txt I can see the voltage went down from 4327 to 4143 (-184) in 1168 minutes. That's 60 x 184 / 1168 = 9.45%/hour, which is correctly showing in BBS. Now I translate this to percentages: 9.45% voltage decrease x 4% battery decrease / 184 = 0.205%/hour battery. This is again correct according to BBS. I guess this is a fair calculation. the voltages seem to go up and down all the time, so I don't understand how it's an exact calculation but ok.
A thing that doesn't make this calculation 100% right is the number of % decrease. I have a good example of 3 battery stats that I saved in the same period of time: 22hours and 58 min, then one a few hours after that, and then last one that's one hour after the last one.
Stage 1. View attachment 22h58.txt -------96% (60 x 126 / 1379 min = 5,48% voltage/hour x 4 % drain / 126 V drain = 0.17% /hour
Stage 2. View attachment 1d32min.txt ----96% ( 94 minutes later it reached Stage 2 = 0.16%/ hour. With the SAME % = 96% ! (Makes sense)
Stage 3. View attachment 1d2h.txt --------95% ( 130 min after Stage 2 I saved another log = 0.187% / hour. You see, it just turned 95% and it goes way up again.
Conclusion: Try to save the BBS as far as you can get to the end of the % to get the lowest %/hour calculation. You'd think: Try Battery History and calculate the exact time and use these minutes in your calculation. But then I realized that the voltage has to change as well, and as I do not know the voltage, the calculation would be messed up. So best is to do as shown above, try to save the BBS manually as far as you can get to the end of the %.
Settings:
Screen off all the time. Just try to peak once or twice a day for one second.
Disabled: NFC, wifi, BT, Location, screen settings: standard screen, double tap to sleep, no rotation, no color adaptation, balanced battery mode, no ambiant color but standard, no notification lights, no gestures.
Disable auto update Google Play Store, even on Wifi, disable all Sync on Googleaccount, disable Location Services
For Touchwiz I used the Barebone Cleaner.
General apps installed Section 3: Whatsapp (not logged in), Battery History, CNN, NOS, NU.nl, Line (not logged in), MyMail (not logged in)
Battery savers:
- Section 1: Amplify, Powernap, AppOpsXposed, BBS---------------------------------Terminated as of 16/10/2016
- Section 2: Greenify------------------------------------------------------------------------Terminated as of 15/10/2016
- Section 3: Amplify, Powernap, AppOpsXposed, BBS, Greenify --------------------In Progress since 17/10/2016
- Section 4: Amplify, Powernap, AppOpsXposed, BBS, Greenify, Forcedoze ------In Progress since 17/10/2016
Conclusion: (as of 01/11/2016)
CM13 is much more stable regarding battery life than Phoenix. At this moment I can suggest CM13 with the following settings:
Ondemandplus, internal + external IO = noop, undervolt -25, aggressive multicore saving, disabled greenify, enable other battery savers as shown above.
Section 4::
Phoenix ROM-------------------------------------0.8%/hr Enabled Greenify, forcedoze, uninstalled Kernel adiutor so default kernel settings.
CM13 + boefla 3.3 beta5-------------------------0.24%/hr. Enabled Greenify, Enabled forcedoze, multicore saving aggressive, 2 cores max, ondemandplus, noop, noop, undervolt light, rest same as below.
CM13 + boefla 3.3 beta5-------------------------0.42%/hr. Enabled Greenify, Enabled forcedoze, multicore saving ON, Interactive, bfq, bfq, no udnervolt, rest same as below.
CM13 + boefla 3.3 beta5-------------------------0.35%/hr. Enabled Greenify, Enabled forcedoze, multicore saving ON, Ondemand, rest same as below.
CM13 + boefla 3.3 beta5-------------------------0.30%/hr. Disabled Greenify, disabled forcedoze, aggressive multicore saving etc, same as below.
CM13 + boefla 3.3 beta5-------------------------0.21%/hour. Disabled Greenify, aggressive multicore saving , same as below.
CM13 + boefla 3.3 beta5-------------------------0.231%. View attachment 0111.txt Ondemandplus, internal + external IO = noop, undervolt -25, aggressive multicore saving, disabled greenify, zzmoove 2 cores max, GPU 320mhz max
CM13 + boefla 3.3 beta5-------------------------0.256%/hr. Governor: Ondemandplus, Internal IO = Noop, Undervolting -25, Installed ForceDoze and activated in Xposed, limited some more Wakelocks, and Activated Greenify again and selected all the options in Experimental.
CM13 + boefla 3.3 beta5-------------------------0.305%hour. View attachment 3920399 Governor: Ondemandplus, Greenify autohibernation disabled and deselected all the Xposed options and limited the cleaner service of greenify in Amplify that caused many alarms.
CM13 + boefla 3.3 beta5-------------------------0.24%/hour. View attachment 20h56.txt Boeffla config app: OnDemand Governor., Internal IO Noop. Can't say I' m excited. Greenify had a lot of wakelocks, I' ll stop the auto hibernate option in Greenify in the next test.
Section 3:: The BetterbatteryStats (BBS) are published from now on.
Phoenix ROM -------------------------------------0.26%/hour. View attachment 2710.txt The same settings as the 0,16%/hour but still a significant difference. I guess it's just different every freaking time. I' m done with Phoenix, next few tests will be on CM13 with boeffla to see a clear pattern on which is best. (with and without governors)
No Kernel auditor installed, no IO scheduler etc, just as it comes with the ROM. the Kernel auditor had some wakelocks so I blame the low score to this app. Changed in dev options: Limit background processes to : No background processes and Do not keep activities.
Phoenix ROM -------------------------------------0.38%/hour View attachment 2610.txt Basic settings as the 0,16%/hour. BBS show a perfect clean run. Seems like one day its lower than the other day.. I guess it's just random luck to get a low %/hour.
Phoenix ROM -------------------------------------0.545%/hour View attachment 26102.txt Governor: Interactive, io Internal: Noop. Rest same. Cant explain it, seems a huge difference to my record. Weird.
Phoenix ROM -------------------------------------0.227%/hour View attachment 2510.txt
Looks like changing the governor isn't helping, so I recommend to stick to Interactive (which was default anyways)
Governor CPU: Ondemand, rest is basic (IO = Cfq, aggressive multicore saving = Disabled - somehow it makes my phone reboot every time in combination with Ondemand and IO Noop, disabled touch boost)
Phoenix ROM -------------------------------------0.33%/hour View attachment 2410.txt
Kernel auditor app installed: Governor: interactive. IO governer: Noop for internal. No touchboost. Multicore Saving: Aggressive. Rest is same as below.
Phoenix ROM -------------------------------------0.16%/hour! View attachment BetterBatteryStats-2016-10-23_153051029.txt Calculation, see method above. When I look at the BBS log when it turned 95%, I see it went up to 0,18%/hour. View attachment BetterBatteryStats-2016-10-23_174102656.txt. I think it's best to let the Battery history app let you save the timestamps when it turned 95% to get the exact moment and calculate the exact % so it could have been lower if I knew the last second before it turned 95%.
CM14, Haggert Kernel ---------------------------0.48%/hour.........Couldnt install Amplify, AppOppsXposed and special features in Greenify cus there's no Xposed for CM14 yet.. Bummer, guess we have to wait. Installed Powernap and SuperDoze and DisabledServices.
CM13 + Boeffla 3.3 beta4 ------------------------0.5% and 0,4%/hour, okay that didn't work... View attachment 3910944 & View attachment 3910945
Boeffla config: GPU governor Powersave, CPu: Light undervolt, external IO to cfq. Governor Ondemandplus, uninstalled Screenoff app, batterymode: power save, battery optimization (settings android) for all battery savers. (were off)
CM13 + Boeffla 3.3 beta2 ------------------------0.205%/hour View attachment BetterBatteryStats-2016-10-18_184154319.txt. Calculation, see above.
Sweet. Could be higher when stopping the test at 95%.
When it reached 96% the average was 0.24%/hr = average 246 min.. (984 / 4%) (23:15 -> 15:39 timestamps 96% = 984 min. 60 x 4 / 984 = 0.24% per hour.
Amplify showed me more wakelocks in the past 19 hours so I limited those as well. Its like a learning process. I' ll tweak more and do a new test below. Exciting stuff! =)
I installed the boeffla config, and put the governor on: Ondemand and scheduler IO both on NOOP. No widgets on homescreen.
CM13 + Boeffla 3.3 beta4------------------------ Again 0.23%/hour. View attachment 3909923 . I saved another log a few hours before this one and it shows less voltage then the last log, how is that possible??? View attachment 3909924
I disabled the Keep awake function in Privacy Guard of Google Services Framework, disabled some other wakelocks that showed up. Clock was giving me many alarms so disabled the deskclock_on_quarter_hour alarm to 2400 secs. Deleted WakelockDetector (not using anyways). Added Greenify to Powernap. Boeffla config: CPU Voltage: Undervolting seems to work (initially it kept rebooting but I put the IO for external to default in boeffla config) The rest: Same settings as test above.
Section 1:
CM13 + Boeffla 3.3 beta2 ------------------------0.6%/hour View attachment 3907816
Phoenix ROM 14.2 ------------------------------- 0.4%/hour View attachment 3907818
Section 2: (TESTS TERMINATED)
Timestamp calculation: Write down the exact time when you take out the charger. Wait a few hours, open the battery history and write down the latest timestamp it saved.
If I look at the percentage in my battery history: 100% = 11:54:39 @ 17-10-2016. It turned 96% at 15:36:43 the same day. According to the real time stamps: This is 222 minutes for 4% = 1.08%/hour.
Greenify with Xposed settings: Agressive doze, Wakeup Time Coalescing, Dont remove Notifications, Deep Hibernation, GCMPush, Greenifying system apps, reveal hidden sync.
Phoenix ROM 14.2 ------------------------------- 329/89/91 minutes (No explanation on the 329min, looks like an error...)
CM13 + Boeffla 3.3 beta1------------------------ 192 minutes (whatsapp not logged in)
OMEGA ROM------------------------------------- 172 minutes
CM13, ROM Kernel------------------------------- 161 minutes (whatsapp not logged in)
Alexander Rom, ROM Kernel------------------- 141 minutes
CM14 (11-10-2016) + ROM Kernel haggertk--- 140 minutes
Resurrection Remix------------------------------ 129 minutes
CM13, Boeffla 3.2---------------------------------- 74 minutes
Specification tests
Test 1: CM13, Boeffla 3.2 - 100, 99 (31 min), 98 (30 min), 97 (13 min), 96 (13 min), 95, (26 min), 94 (26 min), 93 (63 min), 92, (240 min), 91 (168 min). Average: 68 min.
Test 2: CM13, Boeffla 3.2 - 100, 99 (119 min), 98 (35 min), 97 (64 min), 96 (79 min). Average: 74 min.
Test 3: Alexander Rom, ROM Kernel - 100, 99 (27 min), 98 (21 min), 97 (30 min), 96 (53 min), 95 (106 min, 94 (192 min), 93 (513 min!!), 92 (189 min). Average: 141 min.
Test 4: CM13, ROM Kernel, Screen on for nearly 2 minutes, so could have been higher. - 100, 99 (56min), 98 (34 min), 97 (96 min), 96 (111 min), 95 (178 min), 94 (150) min), 93 (419 min), 92 (240 min). Average: 161 min.
Test 5: Resurrection Remix: 99 (32 min), 98 (12 min), 97 (29 min). 96 (86 min). 95 (91 min), 94 (522 min). Average: 129 min[/U][/B]
Test 6: Omega, 99 (44 min), 98 (27 min), 97 (80 min), 96 (123 min), 95 (126 min), 94 (157 min), 93 (520 min). Average: 172 min
Test 7: CM14 (cm-14.0-20161006-UNOFFICIAL-klte, HaggertK kernel): 100, 99 (103 min), 98 (120 min), 97 (150 min), 96 (141 min). Average 128 min.
Test 8: Phoenix Rom, I had my screen on for 1 second for 5 times in these 3 days. No whatsapp logged in, just installed. Okay, this is starting to mindblow me.. So I started with 100% and took out the charger at @ 19:48 on 08-10-2016. I stopped at 19:02 (it turned 87% on this moment) on the 11/10. that's an average of... 329min..
Specification: 99 (161 min), 98 (152 min), 97 (209 min), 96 (238 min), 95 (242 min), 94 (284 min), 93 (898 min), 92 (438 min), 91 (307 min), 90 (360 min), 89 (324 min), 88 (336 min), 87 (326 min)
Total wakelocks in those 3 days are very few! System UI 4x, SCPM Client 9x, Samsung Keyboard 1x. That must explain it.
Test 9: CM13 + Updated Boeffla 3.3[/SIZE][/B] (beta 3.3). Took the charger out on 11-10-2016 @ 23:11. On 13-10-2016 at 16:33 it turned 87%. That's an average of.. 192 min Wakelocks: System UI 4x, Greenify 1x, Clock 5x, Phone 1x. Even less than the Phoenix, so it's surprising that it drains more battery.. Results are better than before the update, but not anywhere near Phoenix.
Test 10. CM14 (11-10-2016) + ROM Kernel haggertk + Android 7 Gapps 9.8.77 + No Greenify + No Xposed. Started on 20:38 13/10. Ended on 14-10-2016, it turned 91% on 17:35. This is an average of.. 140 min.. Not anywhere near Phoenix.
Test 11. Phoenix ROM, Surprising, started on 15-10-2016 on 00:55. Now at 12:49 it's 91%. That's an average of 89 minutes! Thats way worse than the first test. No differences in settings between the Phoenix Rom tests.. The 329 Min must be an error.
The 2nd and 3rd test show 89 and 91 minutes. HUGE Difference. I can't explain the difference so I did a 4th test:
Test 4 - Phoenix: Installed: Betterbatterystats, Amplifying, Greenify etc according to this thread: http://forum.xda-developers.com/android/general/guide-extreme-battery-life-t3095884. Then let the screen off for a few hours. Limit the highest wakelocks. RILJ0 seemed to be a high wakelock, so limit it to 800 seconds. And the ContextManager to 99999 seconds. I put in another Simcard, charged to 100%, reboot. Let it charge for 10 min, Reset Amplify, take out charger. Started on 16/10/2016 @ 16:45:00. At 17/10 at 05:09 it turned 95%. Average: 148 minutes....
I'm starting to wonder how I got to 329 min in the first test after amplifying wakelocks, alarms, services, greenifying, powernap etc.
Test 13. CM13 + Boeffla 3.3 beta2. No widgets on homescreen, everything disabled. Installed Amplify and limited most used wakelocks, alarms and services. Powernap enhanced mode, appsxposed disabled Google Services. In Progress, started at 11:54.
Update Phoenix Rom in first Post!
Looks nice, thanks for testing this. Boeffla got updated yesterday, so it would be nice to see CM13 updated, as it was broken.
Wysłane z mojego SM-G900F
Are you open to request? for what roms and kernel to use?
BrX91 said:
Looks nice, thanks for testing this. Boeffla got updated yesterday, so it would be nice to see CM13 updated, as it was broken.
Wysłane z mojego SM-G900F
Click to expand...
Click to collapse
Thanks, I'll install CM13 and install Boeffla now, and let screen off untill 87% because that's what the current percentage is. I updated the Phoenix Rom, this is the final conclusion.
The CM13 will then probably take 3 days to get a final result, but that's okay, it's worth it to conclude so please have patience
Yes, You can also do it yourself and install the basic Rom without apps, install greenify and Xposed and post the results here. (Its tempting to put the screen on but do it just for 1 second. I did it 5 times in 3 days. Make sure u put another working Simcard in your S5, otherwise it wouldn't be fair for comparison
Could you do a test of cm13 and 14 but with updated play services. People are reporting that play services from 9683 are the cauz effect battery drains.
Allright, will update my final results of CM13 in 3 hours. The new playservice is what version, 9877? On phoenix I had the same version as on Cm13 so.. and I always greenify all Google system apps including play services and disable auto update. I'll flash CM14 with newest Play services and test it
ikzouhetnietweten said:
Allright, will update my final results of CM13 in 3 hours. The new playservice is what version, 9877? On phoenix I had the same version as on Cm13 so.. and I always greenify all Google system apps including play services and disable auto update. I'll flash CM14 with newest Play services and test it
Click to expand...
Click to collapse
Yeah thats the one. But could you try without greenify. Just the rom and Gapps so we could see what real life battery people could expect to get if they don't use any tweaks or apps.
This could also help to show the difference between a bare system and one with battery saving apps to see if they even work or just placebos.
I did use the last Play Service version in the test CM14 by the way. This is because Android 7 Gapps has already the latest version 9877. But Ok, I'll test CM14 without Greenify and Xposed installed now, and flash the gapps pico Android 7 like I did before. I doubt it's gna be anything different but sure it shows the difference between Greenify and without sure.
I Updated new tests, I now use the Amplify + Powernap + AppopsXposed + BBS. New tests on the way
ikzouhetnietweten said:
I Updated new tests, I now use the Amplify + Powernap + AppopsXposed + BBS. New tests on the way
Click to expand...
Click to collapse
Cool. Could you make another section at the top mentioning the most battery full? Roms in like 1st 2nd and 3rd please.
ikzouhetnietweten said:
I Updated new tests, I now use the Amplify + Powernap + AppopsXposed + BBS. New tests on the way
Click to expand...
Click to collapse
Hi. Very nice with this tests.
Can you make test with 100% to 0% with Antutu Tester (or other app like this?)
Keep up
Sent from my SM-G903F using XDA-Developers mobile app
htb2050 said:
Cool. Could you make another section at the top mentioning the most battery full? Roms in like 1st 2nd and 3rd please.
Click to expand...
Click to collapse
I' m not sure what you mean by the most battery full?
il3gal said:
Hi. Very nice with this tests.
Can you make test with 100% to 0% with Antutu Tester (or other app like this?)
Keep up
Sent from my SM-G903F using XDA-Developers mobile app
Click to expand...
Click to collapse
Thanks! I'll keep on testing and testing untill I reach the limit of the S5
Well, that's gna be really bad for my battery I' m affraid And it gets super hot too, I already did it once with my S3. I am curious about the off screen, but you can always do the test yourself with a basic phone and debloat it and do the test and publish it here. I could put it in the thread.
By the way, I have a new update on the last test, 0,2% per hour.
Are you using the last nightly of CM? Or snapshot?
Arthur King said:
Are you using the last nightly of CM? Or snapshot?
Click to expand...
Click to collapse
Yeah Use the last nightly, I dont know what Snapshot is
You should look to doing something like this, http://forum.xda-developers.com/showthread.php?t=3269557
Sent from my SM-G900F using Tapatalk
I get 0.2/hr (according to gsam battery) *most* of the time. This with xXx No Limits rom (v1.6 LP).
f0xy said:
You should look to doing something like this, http://forum.xda-developers.com/showthread.php?t=3269557
Sent from my SM-G900F using Tapatalk
Click to expand...
Click to collapse
Tnx, Had a lookat it, it's mostlysettings and kernels for the nexus but tnx for info, I' ll try to do the Min freq and highest freq setting on the boeffla config app, but I think this is already in the CPU Ondemand Governor. First I' ll try the current Phoenix Kernel and use a governor with the Kernel audiator app.
taco9 said:
I get 0.2/hr (according to gsam battery) *most* of the time. This with xXx No Limits rom (v1.6 LP).
Click to expand...
Click to collapse
Okay interesting, could you try to install the BBS app, and upload a log here and tell me your settings? Tnx.
I'll update the phoenix login a bit, it's gna be near or lower than the 0.2%/hr record that I currently have.
New update, 0,16% battery per hour. We still haven't found our limit lol. Going strong....
Hey there,
so with all that Amplify and other Battery optimization apps and stuff you're using, is your phone actually still working? I mean are you receiving messages of any sort while the Screen is off, or only after you turn the screen back on?
And how is the signal strength/mobile connection at your place? Cause I can tell from living in what seems like a bunker to radio waves that poor or frequently fluctuating signal strength does increase battery drain. Also don't worry about those misleading results you get, Androids battery usage isn't as constant as one would like it to be.
Collecting multiple results would increase your battery usages accuracy at this point, but nonetheless your test results are giving a nice hint into the direction which things go. Keep up!
This is a noob-friendly configuration for setting up custom kernel.
Device- Z00L sd410
Kernel- Poison kernel (v4) Thanks to @Riad khan
ROM- CosmicOS Nougat Thanks to @prakharluv
Kernel manager used- Kernel Adiutor
External memory- 16GB uhs1 microSD card.
Configurations are balanced between performance and battery with slightly upper edge for battery savings
Settings-
1. CPU-
Set minimum frequency to 200MHz.
Set maximum frequency to 1152MHz (optional and battery friendly).
Choose "Impulse" as cpu governor.
(I chosen impulse because its amongst the best for balanced battery and performance)
(optional- In cpu governor tunables, choose hispeed_freq to 400MHz)
2. Thermal- enable core control
3. GPU-
(Not for gaming)
GPU maximum frequency- 310MHz
GPU minimum frequency- 200MHz
GPU Governor- msm-adreno-tz
Adreno idler- switched on
Down differential- 40
Idle wait- 15
Workload- 5
4. Screen-
I prefer 'Perfection' color profile. The settings for this profile-
Red - 237
Green - 235
Blue - 255
min RGB value - 35
Saturation intensity - 40
Screen hue - 1515
Screen value - 125
Screen contrast - 127
5. Sound control-
(choose your preferred values)
my configuration-
Headphone and speaker gain - 5
Lock microphone gain- on
6. I/O scheduler-
(both for internal and external storage)
scheduler- fiops
read ahead values- 2048
7. Virtual memory-
zRAM- 510MB
8. Misc-
TCP congestion algorithm- cubic
leave rest of the settings unchanged.
You will easily get 5:30Hrs to 6:00Hrs SOT with moderate usage.
Lastly,
I am not a pro. These settings are just to help those who are new to custom kernels.
If you have better configurations, feel free to share, as good things are always welcomed.
SS attached for my battery consumption with mild to moderate usage
Thanks
What about snapdragon 615 variant ?
suhailmalik said:
What about snapdragon 615 variant ?
Click to expand...
Click to collapse
I don't own that device so, unable to provide any suitable configuration for it.
Did u enable hotplug autosmp? If yes, what's your config for the hotplug?
No. I guess autoSMP isn't implemented in the kernel properly. It isn't working.
And in future updates, if it gets corrected, the most suitable configuration would be, those given by @pokipokipxorn in his own kernel thread.