Related
VIBRANT edition of the Platypus Revolutions kernel
This Project is inactive/low activity for a longer period of time
Kernel
CM7 & MIUI only
NEO series
(since May 24th '11)
Do you want to discuss on this kernel, get the news on the current state of development, or test kernels even fresher than fresh ?
connect via webchat from your browser:
http://webchat.quakenet.org/
and join #platypus-kernel
(recommended)
Fire up your IRC client, and join via client
the server (for now is) : irc.quakenet.org
port : 6667
Channel : #platypus-kernel
(thanks to Tk for the layout idea )
before you ask for any ETAs:
The first rule of CyanogenMod [and this project]: DO NOT ASK FOR AN ETA!
---------------------------------------------------------------------------------------
First step before install & kernel switch:
Always have this cleaning script on your internal SD card ready
If you're
- switching kernels,
- have issues with auto-rotation,
- the cam,
- bootloops
- want to remove init script
- recover from a failed overclock attempt
please give either:
- lippol94's updated cleaning script (apply via CWM recovery): http://www.multiupload.com/XFH1GCK4MB
or
- WiwiPouPou's SYSTEM CLEANER SCRIPT (also apply via CWM recovery): (http://forum.xda-developers.com/showpost.php?p=14805606&postcount=21739)
a try
the kernel already applies some cleaning steps during install but sometimes that's not enough ...
---------------------------------------------------------------------------------------
Introduction:
Hi guys,
this is my first modded kernel for the SGS (CM7/MIUI only)
I first needed to test it to make sure that it'll be stable & boot at the first place
so far it's very fast & responsive & smooth
This thread shall serve as the center for my testing kernels (stability & functionality-wise)
DISCLAIMER: the kernel (binary) and driver modules are provided as is. If problems occcur they most probably are from upstream and can be fixed with the newest version. Since I'm doing this in my free spare time as a hobby (quenching my thirst for tweaks & performance) updates will occur irregularly as time permits and I see fit (most probably when new features & bugfixes arrive). YOU are responsible for the actions that you take (such as over- or underclocking), etc. You agree that I can not be held liable for any potential damage that arises from your actions in combination with or the usage of this kernel and other related parts.
Kudos:
* Google, Andy Rubin & the whole Android crew
* Linus Torvalds & the kernel hackers for upstream Linux
* cyanogen & all the devs out there hacking on this
* Supercurio for enriching our media experience of this smartphone
* codeworkx, coolya, guiper, atinm - the whole teamhacksung|cmsgsteam crew and all other hackers working on CM7
* laststufo, hardcore, nikademus, existz and all the other kernel hackers on the SGS forum
* zen-kernel team for inspiration to create a kernel, too
* all other contributors (devs, users, etc.) who make this possible
The purpose of these kernels is extensive stability testing addressing the following sticking points:
- overall stability & functioning of the kernel and phone
- call drops, missed calls, etc.
- lags (suggestions for improvements are welcome)
- auto-rotation, sensors, etc.
- Voodoo Control Plus [any crashes ? compatibility problems ?]
- working on CM7 or MIUI ?
- scheduler, sound, video synchronisation & lags: Tap Tap Revenge 4 (especially at the beginning of songs)
- scheduler, sound, video synchronisation and any other issues: doodle dash (while shooting & sound activated)
- proper pmem memory layout & settings: proper functioning of Google Googles
for those who love SAUCE (Source):
old source:
ALL MY SAUCE for QUORRA KernalZ ^^
new source:
android_kernel_samsung_aries
(fork and 1:1 update to upstream kernel source - changes in different branches)
(latest changes sometimes might not be in [yet] but in the whole repo everything should be available)
current UV & OC stable values:
Recommended apps for OC/UV:
- Pimp my CPU (also available here on XDA for those who don't have a credit card, etc.)
- Xan's VoltageControl
on stability testing:
http://forum.xda-developers.com/showpost.php?p=13255871&postcount=5
(start with "Q: I'm new in OC/OV operations so please could you explain to me how to set it in the best way?")
the following OC/UV values are only applicable for kernels with the old OC/UV implementation (max. 1.3 GHz)
my current UV (undervolt) stable Values :
old OC/UV implementation (morfic, bilboa1/kang, TheEscapist):
1300000 0 (haven't tested 1.3 GHz much yet)
1200000 -25
1000000 -50
800000 -75
600000 -100
400000 -100
200000 -125
100000 -150
edit:
1200000 -50
1000000 -75
800000 -75
600000 -225
400000 -125
200000 -150
100000 -175
thanks jetcz !
new OC/UV implementation (morfic, bilboa1/kang, TheEscapist - Tk-Glitch):
Tk-Glitch said:
Note that these UV settings will be unstable on many devices. It's only informative.
1600 MHz - 1.500v / -> That's high and many devices will fail on this frequency. Find working UV for you if any.
1500 MHz - 1.500v / -> That's high and many devices will fail on this frequency. Find working UV for you if any.
1440 MHz - 1.475v / -75mv
1400 MHz - 1.450v / -75mv
1300 MHz - 1.400v / -75mv
1200 MHz - 1.350v / -75mv
1000 MHz - 1.250v / -50mv - If you have stability issues, try to let this one by default.
800 MHz - 1.200v / -75mv
400 MHz - 1.050v / -100mv
200 MHz - 0.950v / -150mv
100 MHz - 0.950v / -200mv - (can be very different between two devices)
More volts is not always equal to more stability. Try to add more UV (less volts) if the frequency you're trying to achieve is unstable.
Considering all phones will respond differently to OC/UV, to tweak the values to suit your device will be required.
By default, no overclock/undervolt is applied. You'll need to use one of the tools below to adjust the frequencies and voltages.
Note : Never ever use SetCPU with this kernel. You could encounter many stability problems like random reboots or bootloops.
Click to expand...
Click to collapse
3D performance and games:
recommended apps:
[root] Chainfire3D
1st backup post (kernels)
Kernels:
kernels are listed in descending order
older -> newer (newest at the bottom - for now)
NEO 07
Link: http://forum.xda-developers.com/showpost.php?p=14731525&postcount=137
NEO 09
Link: http://forum.xda-developers.com/showpost.php?p=15044144&postcount=206
NEO 10
Link: http://forum.xda-developers.com/showpost.php?p=15141552&postcount=232
NEO 09-redux_V5
[Gingerbread bootloader support + access to external (micro)SD - no hourly battery drain anymore !]
http://forum.xda-developers.com/showpost.php?p=16298709&postcount=310
NEO 16 codename: Beast
http://forum.xda-developers.com/showpost.php?p=16552743&postcount=380
NEO 17 -r12 codename: Butterfly
http://forum.xda-developers.com/showpost.php?p=17339844&postcount=500
NEO 17 -r18 codename: Butterfly
http://forum.xda-developers.com/showpost.php?p=18268541&postcount=566
NEO 18-update1 codename: funky fish
NEO XX.1-update1 codename: mighty rhino
http://forum.xda-developers.com/showpost.php?p=20000100&postcount=630
ALL USERS MUST UPDATE (this fixes yet another potential data loss trigger)
2nd backup post (Changelogs)
Changelog list:
currently obsolete
3rd backup post (modems list)
modems:
Description:
Modems play a crucial role in how much battery drains in standy.
e.g. if you have a good signal area and the modem still has high
"Time without a signal" indicator under Cell standby you still will get bad standby time
make sure you have little to no "Time without a signal" in Cell standby
there also somewhat seems to be a connection between "Time without a signal" and high "Android OS" number in battery use (!)
Following modems are only compatible with new radio (modem) partition layout:
radio-cm-7-GalaxyS-JVP-signed.zip (4.29 MB)
md5sum: fb38dbf82daf0720fd2328f5f649013e radio-cm-7-GalaxyS-JVP-signed.zip
For more modems & bootloaders please go to siky_dude's Modem Thread:
[CM7/MIUI][28.08.11] Modems + Bootloaders(MD5)
[SGS / i9000 Thread so some frequencies might be missing, e.g. 850 MHz]
for more modems please refer to a modem thread in the Vibrant Forums section
4th backup post (results)
Results & FAQ/Documentation
Results:
(04/27/2011) Results for platypus-kernel_20110427_18_quorra_r1:
- broken auto-rotation & sensors for some [insert ROM (CM7 ? MIUI ?)]
- stable
(05/03/2011) Results for CM7_SGS_platypus-kernel_20110503_17_quorra-r4_exp
- high battery drain, either due to kernel config or optimization flags, fixed with >= quorra r5 (2nd update)
FAQ / Documentation
@bootloop / boot post victims ^^
Hi guys,
could you please try to replace the existing kernel on your MIUI or CM7 nightly CWM-Package with my kernel, modules and its scripts ?
then install that updated package (with the new kernel, modules and scripts)
after that all should work
the bootloops seem to be an issue with bml_over_mtd (broken sectors on the SSD on your phone)
I'll investigate this and see if anything needs to be rewritten and/or updated in that regard
Thanks !
Overclocking / Undervolting:
Q: I'm new in OC/OV operations so please could you explain to me how to set it in the best way?
A: start with -50 mV (delta from default value) other values probably are too low
my testing includes:
- Angry Birds Rio (several missions)
- Gun Bros (for some time)
- mp3 playback, (flac playback - optional)
- surfing the web via browser, opening up bit.ly links from cmsgsteam twitter feed
- watching youtube video
- watching video via rockplayer lite or mobo video player
- running benchmarks (Smartbench 2011, quadrant standard, an3dbenchXL, anTutuBench)
- Labyrinth Lite (for gravity sensor), auto-rotation (also for sensor)
when 1 GHz (1,2 or 1,3) is OK - go lower with undervolt value (e.g. -75 mV)
after it gets un-stable - go back to last known stable value
then you can limit max frequency to lower one, e.g. 800 MHz
and repeat testing for that frequency
for more info: checkout shaolin95's Mini Overclocking Guide:
Link: http://forum.xda-developers.com/showthread.php?p=12910471#post12910471
LED Support FAQ
Q: Do LED notification require an app, such as BLN, etc ?
A: No. It uses Android's and Cyanogen settings, other apps are not required, although some that are designed for regular LEDs may work.
Q: How to I turn off LED notifications, scheduled or/and complete turn off?
A: Use Cyanogen's Quiet Hours feature (settings>cyanogen>sound>quiet hours) and check "Dim the LEDs during quiet hours" (in reality it will turn them off on the SGS). If you schedule a complete day, then LED notifications will be off all the time.
Q: How do I setup per app, find other LED settings etc?
A: Settings>cyanogen>interface>LED notifications
Q: What to do with LED color settings?
A: We have only one color, so that doesn't work. Use Green as default setting. Some non-bright colors turn off notification, as it's the equivalent as diming LEDs (note that on real LEDs if you dim them too much they look like off too anyway, the difference is that it's gradual. On the SGS the LEDs can be only on or off, not gradual)
Q: How can I troubleshot my system, I can use ADB but...
A: adb logcat | grep lights (on linux) will show you Android requests to turn LED on or off. "status" tells you what we decide will be interpreted as "turn LED on" (1= on, 0 = off)
adb shell cat /proc/kmsg for live view (or adb shell dmesg if you're using adb after the issues occurs - careful the backlog is limited in size so don't be too slow)
notify_led_on and notify_led_off are requests to the kernel to turn LED on or off.
touch key write/read errors (cypress) are non-fatal failures to ask the touch key to do something (eg lit up the LED), when the hardware goes crazy or there's a logical error in the code (can be both)
touch key recovery routine or "stopped responding" are either hardware errors, either a logical error where the driver would try to write something the touchkey doesnt understand. in some occasion lock&unlock fix those as a work around, of course a permanent fix is required
Voodoo Color settings:
Q: I don't have that nice ice-ish white color on my screen anymore - you suck !
Q: my screen looks like someone pissed on the screen - you suck !
(sorry for the language ^^)
A: I love you too ^^
download Voodoo Control or Voodoo Control Plus
Screen RGB multipliers:
- Red: 321*
- Green: 321*
- Blue: 429*
Screen v1 gamma hack:
- use Alt. settings
- or if you prefer others - use: "Reset to 2.3.3 defaults", "Punchy settings" (punchy could lead to a great screen while locking the screen and having "screen off" animation disabled)
other recommended settings:
Also a lil tip for people who use voodoo color!
1 )Color Profiles: Voodoo Profile V1
2 ) Screen v1 gamma hack :
- 50 red
- 53 green
- 44 blue
3 ) SRB multipliers:
Red ="2300875360"
Green ="2300875360"
Blue ="2709919680"
With those adjustment, black colors are BLACK and white colors are WHITE. Everyone should try this.
Click to expand...
Click to collapse
SGS CM7 nightlies wiki
http://sgscm7nightlies.pbworks.com/w/page/41483487/FrontPage
Android OS bug, :
(thanks to ceriko ! and his awesome guide for DarkyROM 10.1)
If your battery drains very fast and your battery stats mentions Android OS above 10%, often between 40 and 60%, sometimes more, this is the best to do as far as I know:
- Remove the 2/3 system files as per the beginning part of this guideguide about batterie issues.
- Install WatchDog and open (I set it to "moderate", then I close it, that's all), this app will warn you whenever an app or a process miss-behaves by draining the battery excessively. It will not fix it but just flag it and you will see a notification.
- Reboot usually stops the drain for a while until it naturally comes back, so reboot whenever you see Android OS above 10% and rising or after you see WatchDog mentioning "Suspend" process using too much battery (the suspend process hanging is the Android OS bug).
- Some apps trigger it, most common are Gameloft games (blame Samsung, not the games/apps). No need to use apps or games for this drain to happen, it also happens straight after boot once phone has been fully charged.
This bug can not be fixed by anyone but Samsung. Some never see it, some will experience it everyday no matters what they do... It's just annoying and unfair but that's the same on all Gingerbread releases by Samsung (JVK, JVB, JVO, JVH). Apparently even the SGS2 has this...
screenstate scaling aka my governor won't change after screen locked:
So what is this all about ?
it's an init script that is put in to /system/etc/init.d
and switches between the configured governors in the script
depending on whether the screen is on (AWAKE_GOVERNOR) or off (SLEEP_GOVERNOR)
in most cases your phone is off - in that case it would be good to use a governor which doesn't fire up the cpu frequency too fast since you don't need it (no GUI, smooth scrolling, etc. needed while the screen is off - lol),
so conservative governor is set
when using the phone (screen on) it really depends on what you want to do: e.g. latency & smoothness is crucial: try smartass2, smartass, ondemand;
you're mainly browsing & reading stuff: try ondemandb, conservative (the screen is already burning enough battery so you don't need another component burning yet more)
only use one governor at a time
e.g.
AWAKE_GOVERNOR
# AWAKE_GOVERNOR
# AWAKE_GOVERNOR
SLEEP_GOVERNOR
# SLEEP_GOVERNOR
# SLEEP_GOVERNOR
that means lines with "#" are commented out and not used by the script
e.g.
# AWAKE_GOVERNOR
AWAKE_GOVERNOR
# AWAKE_GOVERNOR
SLEEP_GOVERNOR
# SLEEP_GOVERNOR
# SLEEP_GOVERNOR
also would work (intentionally not filled in any governors)
5th backup post (you never know )
yet to be declared
MIUI kernels == MIUI + CM7 prior to RIL switch to Samsung's (closed source) RIL
CM7 kernels == CM7 with newer RIL only
Kernel
CM7 & MIUI only
NEO 04-energy
(energy efficient build for max battery runtime, efficiency & smoothness)
(NEO_01 was internal build)
before you ask for any ETAs:
The first rule of CyanogenMod [and this project]: DO NOT ASK FOR AN ETA!
Changelog (from NEO_03):
- fugumod security hardening re-added
- optimized memcopy & memmove for maximal efficiency & speed
- optimized for size (less cache-misses & leaner and [perhaps] faster system)
- optimized for NEON-usage
- conservative-governor ONLY (one governor to rule them all) - battery consumption + performance == win + win
- FIQ-console disabled (probably less overhead + battery savings)
- LED notifications disabled - only LED light timeout enabled (battery savings)
- printk time-stamps disabled (probably less overhead + battery savings)
- fixed HD Video recording + mic recordings (sound works again)
- "old" OC-UV-implementation OC until 1.3 GHz
- re-added Nick Piggin's inode integrity patches (2 of them) - (more stability & perhaps some saved cpu cycles -> battery)
- re-added several of the previously not included patches from quorra kernel-base
not yet included:
- fugumod security improvements (thanks to nikademus for sharing the source !)
- bluetooth l2cap powersave mode
- and many more
current stable UV values (for me)
1000 -50 mV
800 -75 mV
600 -225 mV
400 -125 mV
200 -150 mV
100 -250 mv
Download Link:
Mirror #1:
CM7 / new RIL:
CM7_VIBRANTMTD_20110529-10_r_platypus-revolutions-kernel_0_NEO_04-energy.zip
MIUI / CM7 / old RIL:
CM7_VIBRANTMTD_20110529-09_MIUI_platypus-revolutions-kernel_0_NEO_04-energy.zip
(thanks to Roland for hosting !)
Mirror #2:
this post
Troubleshooting & short-FAQ:
- WIFI & stuff not working ?
lippui94 cleaning script, then wipe dalvik, then fix permissions, then kernel - eventuall governor switch - , then wipe dalvik, then wipe cache, then fix permission
- reboots during calling ?
please report ASAP !
this is supposed to be fixed & a non-issue [if it's still happening try with different nightly]
- Radio (phone function) not working ?
new RIL kernels only work with nightlys > #12 on the SGS (including #12)
- phone is not as smooth as with previous kernel releases
yeah - sorry, might be due to the fact that I'm forced to use stock toolchain (less optimized toolchain)
sticking points to test & feedback:
- call drops, reboots during calling & potential instabilities
- general stability (if this also happens on stock: post but add a note that it's from stock - thanks !)
- BT & WIFI switching
- HD video recording & playback (is smooth for me during playback, recording with HD & Youtube HD works)
- mic recording, HD video + sound (tested & should work)
- iptables
- battery runtime
- smoothness
Link to old thread + 2nd mirror (thread):
http://forum.xda-developers.com/showpost.php?p=14260897&postcount=392
hitman818 said:
It says nightly #12, do you mean the one that came out today, cm7.1.0?
Sent from my SGH-T959 using XDA Premium App
Click to expand...
Click to collapse
please read all of it
#12 on the SGS (including #12)
Click to expand...
Click to collapse
it's a different numbering scheme
kernel with new RIL applies to:
SGS: >= #12
CAPTIVATE: >= #14
VIBRANT: >= #9
I think ill stick with neo 3 it is the only kernel with working bln on miui. And is very fast and stable no complaints.
i just flashed neo 4 on lasted cm7 build. getting no service..
I just tried the old ril one and I had no service either on the new cm7 update.
Yeah, no service for me either
Sent from my SGH-T959 using XDA App
So far so good for me, flashed the old RIL on CM7 V8 and everything is working.
good on latest miui im running with UV its a little slow, does undervolting too much reduce speed or just stability?
gamikzone said:
good on latest miui im running with UV its a little slow, does undervolting too much reduce speed or just stability?
Click to expand...
Click to collapse
Reduced stability=reduced speed
If u want BLN to work try NEO3
nickmcminn60 said:
Reduced stability=reduced speed
If u want BLN to work try NEO3
Click to expand...
Click to collapse
what exactly does bln do? and i was able to improve the speed these are my rates that i find as a good UV
1300 0
1200 0
1000 -25
800 -25
600 -50
400 -50
200-75
100-75
gamikzone said:
what exactly does bln do? and i was able to improve the speed these are my rates that i find as a good UV
1300 0
1200 0
1000 -25
800 -25
600 -50
400 -50
200-75
100-75
Click to expand...
Click to collapse
BLN uses the capacitive buttons as a notification LED for when you get a text, an email, or something. In the newest builds of CM7, however, it has been disabled.
Sent from my SGH-T959 using XDA App
BLN - Overrated IMO
BLN = Big Lame Nothin'
or
BLN = Battery Leeching Nuisance
END OF LINE
w8 wtf?
galaxy S modems on the Vibrant?...
please tell me that's not what your doing...
apollo15rover said:
BLN = Big Lame Nothin'
or
BLN = Battery Leeching Nuisance
END OF LINE
Click to expand...
Click to collapse
opinions are li......
WARNING:THIS METHOD CAN BE DANGEROUS. DONT DO ANYTHING IF YOU DO NOT KNOW WHAT YOU DO.I AM NOT RESPONSIBLE IF YOU TRANSFORM YOUR PHONE INTO A BRICK.
Horse Power 2x eXtreme SuperSonic SR4R
Welcome to HP Development, If you like my work, you can buy me a beer
I dont work for donations but they do help and helped in the past to counter accidential expenses that comming unplanned. And helped me to buy caffeine for my development.
Here are the list of Donators who have donated so far. I'd like to thank everybody including users of HP Kernels for support, without support and contribution it cant reach till here:
Names of Donators who donated since development of HP Kernels:
-SuperSkill (multi time donator, greatest contributors of development)
-Striatrum_bdr (My neuro protective donator)
-yann73(Multi Time Donators)
-Carburano( Thanks my friend)
-Civato(Thanks my friend)
-wapz
-Basil 123
-Steieve
-psonic2k
-PhunKee
-zerocoolrider
-fuxman
-skylight
-shreeprajay
-patiiet
-Omar Cornejo Sanchez
-abwyatt,-
-tablighs
-Rehborn-
-Jonas Andrulis
-Chris Daßler
- Bert van Hoesel
-Miguel Angel Mulero Martinez
-DARIO FRANZONI,
-Antonello Picerno
-sorry if i've forgot anybody's name please remind me if i've
HP Pro SuperSonic SR4
Changelogs(Kernel Specific)
-too long list of changelogs
-Included all changes since SS1 to SS21
-HP Pro RT Scheduler removed temporarily for stability issue
-Compiled with HP Pro SuperSonic ToolChain for maxium Performance, snappiness and fluidity
Compiled with HP Pro SuperSonic ToolChain.
HP Pro SuperSonic ToolChain Features: (Based on GCC Linaro Sources)[/U][/B]
(-) Tegra specific optimization
(-) Toolchain Target flags has been optimized in same manner as the kernel drivers are written
(-) "Optimizing as the way program is written". I have overy observed all the codes by , as they're written and used same appropriate optimizations
(-) By observing codes 1st thing that comes in mind is Structures & Unions. Used Target Optimizations for it: '-fpack-struct and mstructure-size-boundary=32' for proper alignments of Structures and Unions for faster access
(-) fivopts for variable strength optimizations
(-) fforce-mem with fomit-frame-pointer for faster pointer access
(-) Except tegra codes most of the kernel codes have inlined functions. All functions inlined for faster access of codes. By inlining functions it can be accessed as fast as macro
(-) Code assembly and linking with ArmV7-A architecture's Cortex-A9 cpu's Virtulizations, Integer Division Float and Multi-Processing CPU Extensions
(-) CortexA9 Processor has support for Array Prefetching same like windows does SW based Prefetch. This CPU features during runtime loads longer arrays in advance in CPU memory via AX/BX registers. Which can significantly improve runtime execution and overall snappiness. Target toolchain optimized with array-prefetch optimizations to compile codes with array pre-fetch instructions
(-) By observing Tegra and LG drivers, there are very few short loops, which needs no optimizations, thus graphite loop optimizations disabled.
(-) LTO( Link Time Optimizations) for removal of unused codes during linking stage and re-sections of functions and data for faster access
(-) As armv7-a architecture supports Unaligned Access, instead of disabling, its optimized with 8K access
(-) This is the same toolchain that has been used since 5 months to speedup SuperSonic Test builds for Stock Kernel. No extra blind optimizations used for issue of stability but only as drivers and kernel codes are written "Target specific optimizations" for maxium possible performance
(-) toolchain: Complete set of Used CFLAGS_FOR_TARGET: -O0 -finline-functions -fpack-struct=8 -mstructure-size-boundary=32 -fpreferch-loop-arrays -fivopts -fforce-mem -fomit-frame-pointer CFLAGS_FOR_BUILD: -O0 -march=atom -mtune=atom( as my cpu is atom) Cflags:-O0 -finline-functions
Download
OC Version: https://www.dropbox.com/s/1byhged9oqw5a6n/HP_Pro_SuperSonic_SR4R_OC.zip
No-OC Version: https://www.dropbox.com/s/uvnq7fppcsd8z7e/HP_Pro_SuperSonic_SR4R_No-OC.zip
BIG THANKS TO SUPERSKILL & SHREEPRAJAY FOR PROVIDING ALL HP KERNEL MIRRORS WORKING LINK, IF ANYBODY ELSE HAS ALSO MIRRORED PLEASE PM ME THE LINKS
Downlaod HP Krnls(Latest Build is SR3R2/R:
https://www.box.com/s/5995c4bdcf9abb4e375f
Download HP Performance Packs
https://www.box.com/s/d2a5c32bd3cc0e5d174f
An APP To Control On-The-Fly features of RC12, A Big Thanks to Developer Keshav0001, Who without saying Created an application and still progressing, He is New to XDA as needed 10 or more posts:
Downloads:
search in Market "HorsePower 2x OTF Kernel Tweaker"
Horse Power 2x eXtreme 16/24/32BPP RC12-R(RC Release)
This kernel is based on LG V20Q sources. This kernel is competible and should only be flashed with STOCK MCR FROYO and GINGERBREAD. NOT COMPETIBLE WITH CM AND MIUI
Cryptic Changelogs History:
PHP:
Code:
+Fixed core cpu memory leak
+ Fixed group scheduler"s cpu memory leak, no need to restart phone every 100 hours.
+[B][U](SR3R2)[/U][/B] Reverted to original BackLight drivers as request of many users [B][U](SR3R2)[/U][/B]
+[B][U](SR3R2)[/U][/B] Fixed missing codes in PowerSave [B][U](SR3R2)[/U][/B]
+[B][U](SR3R2)[/U][/B] Fixed with NoOC Version without compcache [B][U](SR3R2)[/U][/B]
+[B][U](SR3R)[/U][/B] Fixed missing definition of CPU memory leak. After hours by hours, days by days more smoothness w/o slow down due to memory leak [B][U](SR3R)[/U][/B]
+[B][U](SR3R)[/U][/B] Full SMP support, enhancing Real Time Dual Core Performance for Multi-Tasking And activated PowerSave profile 4,5,6 [B][U](SR3R)[/U][/B]
+[B][U](SR3R)[/U][/B] Full IP Tables supported, by an upgraded IP Tables [B][U](SR3R)[/U][/B]
+[B][U](SR3R)[/U][/B] Included farajep's backlight driver (Thanks to farajep for making source available) [B][U](SR3R)[/U][/B]
+[B][U](SR3R)[/U][/B] Quick responsiveness and smoothness like SR3 [B][U](SR3R)[/U][/B]
+[B][U](SR3R)[/U][/B] Longest battery performance [B][U](SR3R)[/U][/B]
+[B][U](SR3R)[/U][/B] Fixed freeze, no need to apply +mV patch. One version for all devices [B][U](SR3R)[/U][/B]
+[B][U](SR3R)[/U][/B] Fast WiFi browsing [B][U](SR3R)[/U][/B]
+[B][U](SR3R)[/U][/B] More smooth scrolling [B][U](SR3R)[/U][/B]
+[B][U](SR3)[/U][/B] Introducing OTF V2.0 including Strong Vibrator OTF Function and many bug fixes. To activate strong vibrater just set value "1" in /data/spica/strong_vibe and save, Instantly strong vibrator driver will be activated. To enable boot time Strong Vibrator support set value "1" to /data/spicabootcfg/strong_vibe. For +mV versions and BPP patch InstallKernel first than apply patches for that reffer post #2 after this [B][U](SR3)[/U][/B]
+[B][U](SR3)[/U][/B] Fixed EndCall BSOD(Thanks to Vadonka) [B][U](SR3)[/U][/B]
+[B][U](SR3)[/U][/B] Extra responsiveness with Low Latency Realtime Processing [B][U](SR3)[/U][/B]
+[B][U](SR3)[/U][/B] Mega Smooth UI performance and Rock Solid Stability [B][U](SR3)[/U][/B]
+[B][U](SR3)[/U][/B] Longest battery life. 2 versions available one with my modded battery driver and another with DS battery driver(jumpy-funky reading but long battery life) (Thanks to DS available sources) [B][U](SR3)[/U][/B]
+[B][U](RC12-R)[/U][/B] Longest battrery performance on v20q source kernel with RevisedOTF PowerSave functionality [B][U](RC12-R)[/U][/B]
+[B][U](RC12-R)[/U][/B] Mega Smooth UI Smoothness, You'll really be amazed by never seen smoothness [B][U](RC12-R)[/U][/B]
+[B][U](RC12-R)[/U][/B] RockSolid Stability [B][U](RC12-R)[/U][/B]
+[B][U](RC12-R)[/U][/B] Fully Functional Spica Revised OTF Pack, Lesser freeze free re-mastered values for powersave, gentle yet effective, Selected target values for powersave to significantly reduce battery drainage, PowerSave profile 1-6 (tutorial soon to be written) [B][U](RC12-R)[/U][/B]
+[B][U](RC12-R)[/U][/B] Fixed InCall BSOD previously reported with TestBuilds [B][U](RC12-R)[/U][/B]
+[B][U](RC12-R)[/U][/B] By default screen off max freq setted to 503 Mhz as always, You can exclusively play with different values On-The-Fly with RevisedOTF Functionalities for music listenings w/o distortion or for incoming call as per your needs by setting MaxScreenOff CPU freq values of choice by GUI Application (Thanks to Kaunshik001) or by writing values to /data/spica/maxscreenofffreq. No need to reply on pre-set values. [B][U](RC12-R)[/U][/B]
+[B][U](RC12)[/U][/B] On-the-fly Pack, Exported many HW controlled values from static to dynamic at userspace level (Originally I was inspired by the the concept of Xmister)([B]Credits to Xmister[/B])[B][U](RC12)[/U][/B]
+[B][U](RC12)[/U][/B] On-the-fly VDEFREQ/GPUFREQ/MINCPU1ON/MAXCPU1OFF/SUSPEND_CORE_MV/POWERSAVE/NITROS/SCREENOFFMAXFREQ/DDR2_MIN_KHZ/LPDDR2_MIN_KHZ Support. No need to reboot/restart daemon. It works on kernel syscalls. It takes effect in notime.[B][U](RC12)[/U][/B]
+[B][U](RC12)[/U][/B] On-the-fly [B]VDEFREQ [/B]change support. Responsible file is located in /data/spica/vdefreq & /proc/spica/vdefreq. You can change the value in any of these both files. I preffer user-friendly /data/spica/vdefreq. Edit values with ES file explorer and just save file. No need to change permissions. It takes effect instantly. Default value is 600000. Supported Values in between 600000-700000. Any values above 600000 will OC it w/o increasing supplying voltage. For safety concern no values except in range will be accepted. To enable boot-time support select values in /data/spicabootcfg/vdefreq [B][U](RC12)[/U][/B]
+[B][U](RC12)[/U][/B] On-the-fly [B]GPUFREQ[/B] change support. Responsible file is located in /data/spica/gpufreq & /proc/spica/gpufreq. You can change the value in any of these both files. I preffer user-friendly /data/spica/gpufreq. Edit values with ES file explorer and just save file. No need to change permissions. It takes effect instantly. Default value is 280000. Default value is 300000 Supported Values in between 280000-350000. Any values above 280000 will OC it w/o increasing supplying voltage. For safety concern no values except in range will be accepted.To enable boot-time support select values in /data/spicabootcfg/gpufreq [B][U](RC12)[/U][/B]
+[B][U](RC12)[/U][/B] On-the-fly [B]MINCPU1ON[/B] freq change support. Means during upword scaling at what freq 2nd core will be activated. Responsible file is located in /data/spica/mincpu1on & /proc/spica/mincpu1on. You can change the value in any of these both files. I preffer user-friendly /data/spica/mincpu1on. Edit values with ES file explorer and just save file. No need to change permissions. It takes effect instantly. Default value is what you see after boot. Supported Values in between 216000-1100000. Default value of spica kernel is 810000 For safety concern no values except in range will be accepted.To enable boot-time support select values in /data/spicabootcfg/mincpu1on [B][U](RC12)[/U][/B]
+[B][U](RC12)[/U][/B] On-the-fly [B]MAXCPU1OFF[/B] freq change support. Means at what max freq 2nd core will be off during returning phaze. Responsible file is located in /data/spica/maxcpu1off & /proc/spica/maxcpu1off. You can change the value in any of these both files. I preffer user-friendly /data/spica/maxcpu1off. Edit values with ES file explorer and just save file. No need to change permissions. It takes effect instantly. Default value is what you see after boot. Supported Values in between 216000-1100000. Default value of spica kernel is 860000 For safety concern no values except in range will be accepted.To enable boot-time support select values in /data/spicabootcfg/maxpu1off [B][U](RC12)[/U][/B]
+[B][U](RC12)[/U][/B] On-the-fly [B]MaxScreenOffFreq[/B] support. Means During screen off what will be the max freq.Responsible file is located in /data/spica/screenoff_maxcpufreq & /proc/spica/screenoff_maxcpufreq. You can change the value in any of these both files. I preffer user-friendly /data/spica/maxcpu1off. Edit values with ES file explorer and just save file. No need to change permissions. It takes effect instantly. Default value is what you see after boot. Supported Values in between 216000-999000. For safety concern no values except in range will be accepted.To enable boot-time support select values in /data/spicabootcfg/screenoff_maxcpufreq. [B][U](RC12)[/U][/B]
+[B][U](RC12)[/U][/B] On-the-fly [B]DDR2 MINIMUM FREQUENCY[/B] support. It's theminimum frequency of DDR2(SDRAM).Responsible file is located in /data/spica/ddr2_min_khz & /proc/spica/ddr2_min_khz. You can change the value in any of these both files. I preffer user-friendly /data/spica/ddr2_min_khz. Edit values with ES file explorer and just save file. No need to change permissions. It takes effect instantly. Default value is what you see after boot. Supported Values in between 10000-50000. Default value is 50000 For safety concern no values except in range will be accepted.To enable boot-time support select values in /data/spicabootcfg/ddr2_min_khz. [B][U](RC12)[/U][/B]
+[B][U](RC12)[/U][/B] On-the-fly[B] LPDDR2 MINIMUM FREQUENCY[/B] support. It's theminimum frequency of LPDDR2.Responsible file is located in /data/spica/lpddr2_min_khz & /proc/spica/lpddr2_min_khz. You can change the value in any of these both files. I preffer user-friendly /data/spica/lpddr2_min_khz. Edit values with ES file explorer and just save file. No need to change permissions. It takes effect instantly. Default value is what you see after boot. Supported Values in between 1000-18000. Default value is 18000 For safety concern no values except in range will be accepted.To enable boot-time support select values in /data/spicabootcfg/lpddr2_min_khz. [B][U](RC12)[/U][/B]
+[B][U](RC12)[/U][/B] On-the-fly [B]SUSPENDED CORE VOLTAGE SUPPLY[/B] support. It's theminimum frequency of CORE VOLTAGE WHEN Core is in suspend state.Responsible file is located in /data/spica/suspend_core_mv & /proc/spica/suspend_core_mv. You can change the value in any of these both files. I preffer user-friendly /data/spica/suspend_core_mv. Edit values with ES file explorer and just save file. No need to change permissions. It takes effect instantly. Default value is what you see after boot. Supported Values in between 600-1000. Default value is 1000 For safety concern no values except in range will be accepted.To enable boot-time support select values in /data/spicabootcfg /suspend_core_mv. [B][U](RC12)[/U][/B]
+[B][U](RC12)[/U][/B] Dynamic On-The-Fly '[B]powersave'[/B] profile. Which accepts value from '0' to '6'. During 'powersave' kernel smartly adjust various thresholds of voltage to lower possible values. "0' value means disable(Defult) "1" light powersave "2" moderate powersave "3" aggressive powersave "4" Profile "1" during screen off "5" Profile "2" during only screen off "6" Profile "3" during screen off only(POWERSAVE doesnt touch UV). Make sure 'nitros' mode disable aka value '0' Responsible file location /data/spica/powersave and boot time file location /data/spicabootcfg/powersave [B][U](RC12)[/U][/B]
+[B][U](RC12)[/U][/B] Dynamic On-The-Fly "[B]Nitros[/B]" -"Performance" mode. It accepts two values, "0" Disable "1"Enable. During "Nitros" Profile Kernel sets max fail-safe values (It doesnt touch OC). File location /data/spica/nitors and boot time file location /data/spicabootcfg.Make sure 'powersave' is disabled aka value '0'[B][U](RC12)[/U][/B]
+[B][U](RC12)[/U][/B] V20Q Sources merged[B][U](RC12)[/U][/B]
+[B][U](RC12)[/U][/B] Slight loud crystal clear volume in headphone[B][U](RC12)[/U][/B]
+[B][U](RC12)[/U][/B] Optimized SCHED_RR & SCHED_FIFO[B][U](RC12)[/U][/B]
+[B][U](RC11-R)[/U][/B] Fixed CpuFreq of 2nd Core not syncing with 1st core's cpufreq. NOW Very quicker 2nd core activation and very quicker 2nd core suspension. Thus fastest realtime resposnses and excellent reduced battery drainage. Standby battery drainage with OC/UV ~1-2mA [B][U](RC11-R)[/U][/B]
+[B][U](RC11-R)[/U][/B] Re-injected Compcache and removed ZRAM [B][U](RC11-R)[/U][/B]
+[B][U](RC11-R)[/U][/B] Modified Deadline Scheduler's FIFO parametrs to 20 instead of 16 for quicker response [B][U](RC-11R)[/U][/B]
+[B][U](RC11)[/U][/B] More snapier, stable and performance oriented [B][U](RC11)[/U][/B]
+[B][U](RC11)[/U][/B] Featuring ZRAM/(Previously known as CompCache) HW Compressed RAM with SWAP_FREE_NOTIFY feature [B][U](RC11)[/U][/B]
+[B][U](RC11)[/U][/B] Fixed freeze issue by re-compiling GCC HardFolat ARM tool chain [B][U](RC11)[/U][/B]
+[B][U](RC11)[/U][/B] OC/UV & VOODOO remerged [B][U](RC11)[/U][/B]
+[B][U](RC10)[/U][/B]Removed LG's lowmemorykiller.c and added same modified by me for assured oom optimal functionality with no possible memory leak[B][U](RC10)[/U][/B]
+[B][U](RC10)[/U][/B]Longest battery performance among all HP KRNLS. Extended battery life[B][U](RC10)[/U][/B]
+[B][U](RC10)[/U][/B]NVMAP enabled to kill processes envoked by GPU to assure GPU mem functionality without allocation of static GPU memory[B][U](RC10)[/U][/B]
+[B][U](RC10)[/U][/B]Enabled Android pMem functionality[B][U](RC10)[/U][/B]
+[B][U](RC10)[/U][/B]Patched tegra framebuffer to allow pseudo color palate support on same x,y axis with >/= 16 bits support[B][U](RC10)[/U][/B]
+[B][U](RC10)[/U][/B]Quicker apps response[B][U](RC10)[/U][/B]
+[B][U](RC10)[/U][/B]Extended most efficious multi-tasking[B][U](RC10)[/U][/B]
+[B][U](RC10)[/U][/B]ARM Hard Float VFP support. Compilation along with ARMHF tool chains[B][U](RC10)[/U][/B]
+[B][U](RC9)[/U][/B] Fully based on Official released V20L sources, Merged all HP kernel changes since beta to RC8 with V20L[B][U](RC9)[/U][/B]
+[B][U](RC9)[/U][/B]More optimized scheduling, Quicker APP response and More smooth UI (Taken from SR3 Test release)[B][U](RC9)[/U][/B]
+[B][U](RC9)[/U][/B]Fixed wifi with dynamic msallocation (Taken from SR3 Test build)[B][U](RC9)[/U][/B]
+[B][U](RC9)[/U][/B]More optimized for power saving (Taken from SR3 Test build)[B][U](RC9)[/U][/B]
+[B][U](RC9)[/U][/B]SMBFS file system support as a module (Taken from SR3 Test build) [B][U](RC9)[/U][/B]
+[B][U](SR2)[/U][/B] Power Saving optimizations [B][U](SR2)[/U][/B]
+[B][U](SR2)[/U][/B] More optimized for smoother responce [B][U](SR2)[/U][/B]
+[B][U](SR2)[/U][/B] Merged changes of RC7 & RC8 without JRCU daemon[B][U](SR2)[/U][/B]
+[B](RC8-Revised)[/B] Fixed EMC core UV issue and Max OCed reverted back to 1408Mhz[B][U](RC8-Revised)[/U][/B]
+[B][U](RC8)[/U][/B] JRCU as daemon support[B][U](RC8)[/U][/B]
+[B][U](RC8)[/U][/B] OCed upto 1.55 Ghz Normal Vibrator Version[B][U](RC8)[/U][/B]
+[B][U](RC8)[/U][/B] More possible optimizations for lesser battery drainage[B][U](RC8)[/U][/B]
+[B][U](RC7)[/U][/B] Watchdog Support added: Tegra ODM Watchdog support as a module[B][U](RC7)[/U][/B]
+[B][U](RC7)[/U][/B] SDRAM related EMC core voltage undervolted to -50mV[B][U](RC7)[/U][/B]
+[B][U](RC7)[/U][/B] More possibly optimized for better possible battery[B][U](RC7)[/U][/B]
+[B][U](RC7)[/U][/B] Max OC frequency back to 1.4Ghz[B][U](RC7)[/U][/B]
+[B][U](SR1)[/U][/B] Strong Vibrator driver, Both version availibility with Strong Vibrator driver and with Default vibrator driver [B][U](SR1)[/U][/B]
+[B][U](SR1)[/U][/B] Best hand-picked stuff from RCs, Default frequencies of CPU towards 1.4Ghz[B][U](SR1)[/U][/B]
+[B][U](SR1)[/U][/B] Assured Stability, Better Performance and energy-saving battery performance[B][U](SR1)[/U][/B]
+[B][U](RC6)[/U][/B] TEMP info fixed[B][U](RC6)[/U][/B]
+[B][U](RC6)[/U][/B]Minor debug clean-ups[B][U](RC6)[/U][/B]
+[B][U](RC6)[/U][/B] In-call volume mute issue in Froyo fixed[B][U](RC6)[/U][/B]
+[B][U](RC5)[/U][/B] OCed upto 1.5Ghz, New freq steps 216,389,655,816,1015,1216,1408,1504[B][U](RC5)[/U][/B]
+[B][U](RC5)[/U][/B] Declaration of NVODM FULL VOLTAGE in mV undefined ,Depends now on FUSE functionality .Low and Critical NVODM voltage in mV selected 9400 & 8800 respectively in NVODM initialization file[B][U](RC5)[/U][/B]
+[B][U](RC5)[/U][/B] All Kernel drivers from SU660 GB sources except power,odm_kit,base,nvos fixed for the competibility and merged[B][U](RC5)[/U][/B]
+[B][U](RC5)[/U][/B] "Anticipatory" I/O scheduler as mainline scheduler[B][U](RC5)[/U][/B]
+[B][U](RC5)[/U][/B] Compiled with GCC-4.6.2 Linaro tool chain with Voku's favourite -Ofast flags. Removed tegra specific flags and added ARM standard graphic optimized flags for cortex-a9. CFLAGS_KERNEL and MODFLAGS: -Ofast -pipe -mcpu=cortex-a9 -mtune=cortex-a9 -mfpu=vfpv3-d16 -mfloat-abi=soft -floop-block -floop-interchange -floop-strip-mine -ffast-math -funsafe-loop-optimizations -funsafe-math-optimizations -fbranch-target-load-optimize2[B][U](RC5)[/U][/B]
+[B][U](RC4)[/U][/B] Dual SPI drivers supporting HSPA+ from su660[B][U](RC4)[/U][/B]
+[B][U](RC4)[/U][/B] Wifi modules fixed for re-loading issue and Quicker connect after several hours (Needs testing)[B][U](RC4)[/U][/B]
+[B][U](RC4)[/U][/B] Regluator & RTC drivers from SU660[B][U](RC4)[/U][/B]
+[B][U](RC4)[/U][/B] Battery driver reverted to modified RC1 driver[B][U](RC4)[/U][/B]
+[B][U](RC3)[/U][/B] Featuring BPP(Bits-Per-Pixel) On-The-Fly Support, select bits in init.d/bpp file and reboot[B][U](RC3)[/U][/B]
+[B][U](RC3)[/U][/B] Modified star_battery_charger.c to allow extra-voltage charge [B][U](RC3)[/U][/B]
+[B][U](RC3)[/U][/B] Some drivers previously merged from SU660 reverted as of no visible improvement , And new NVOS NVDDK CORE drivers merged from SU660[B][U](RC3)[/U][/B]
+[B][U](RC3)[/U][/B]SCHED_FIFO optimizations for quicker SCHED operations [B][U](RC3)[/U][/B]
+[B][U](RC3)[/U][/B]Voodoo and missing batt temp in RC2 fixed with RC3[B][U](RC3)[/U][/B]
+[B][U](RC3) [/U][/B] More optimized SCHED_OTHER & SCHED_RR/FIFO for optimum I/O operation[B][U](RC3)[/U][/B]
+[B][U](RC 2)[/U][/B]NEW released su660's V20D GB kernel sources' WLAN module, MMC, USB, I2C, MTD, SPI, NVRM, NVODM, ODM_KIT, STAR, POWER dirvers fixed for the competibility and merged[B][U](RC 2)[/U][/B]
+[B][U](RC 2)[/U][/B]Ext2 support enabled.[B][U](RC 2)[/U][/B]
+[B][U](RC1)[/U][/B] Fixed pre-mature reboots on Terminal Emulator, USB debugging, Script Manager, Compeitble with Andrev OC Daemon APP, fixed reboot on restart daemon service.[B][U](RC1)[/U][/B]
+[B][U](RC1)[/U][/B] Optimized for Quicker APPs response[B][U](RC1)[/U][/B]
+[B][U](RC1)[/U][/B] 32BPP/24BPP Tegra-FB enabled kernel. For 32BPP, Enabled Virtual A8R8G8B8 32BPP to 24BPP to 18BPP panle color with changed RGB and Transperency OFFSET and LENGTH[B][U](RC1)[/U][/B]
+[B][U](RC1)[/U][/B] Heridant topogigi's vold.fstab in installation zip file, for preventing unmounted SD issue on other ROMs [B][U](RC1)[/U][/B]
+[B][U](RC1)[/U][/B] tocuhscreen fix credits to pastime[B][U](RC1)[/U][/B]
+[B](Beta1.1)[/B] Re-strctured modded battery driver with Beta1. OverHeat suspenstion now supports 410-550 TEMP instead of 450-550. Assured up-to 50% lesser battery drainage. Battery driver now supports scaling through 3360 to 4182 mv instead of 4150mv[B].(Beta1.1)[/B]
+Mega-smooth UI Fluidity/smoothness and higher benchmarks
+Quicker UI and/or APP responsiveness
+Efficient multi-tasking
+OC/UV Codes merged from Cpsjuste Sources([B]Thanks cpsjuste ,impertius sources available[/B])
+Voodoo codes from [B]Supecorio[/B] sources(Thanks)
+Ext4 supported
+Competible with V20 l/j/g/i/c/e/q/p/o/l/m And Froyo MCR
If you appreciate my work than feel free to Support My O2x Development
Recommendation:
-Battery calibration. After calibration let it disachrge full for the first time then full charge. Then you're ready to go! Full discharge needs to be done ONLY ONCE after calibration.
Procedure:
-charge phone full when its off, start phone. Charge till it shows full status. Charge more for 15mins untill you see battery voltage at 4182mv. Then calibrate battery with Battery Calibration App.
HP TB Sources: https://github.com/spica234/HP-TestBuild-Repo-upwords-Sr3R
HP 2x Kernel Sources since RC1 to Sr3R2: https://github.com/spica234/HP-2X-V20Q
HP 2x Deprecated Sources since RC1 to RC11 https://github.com/spica234/HP-Krnl-2.6.32.9
revOTF Patch Attached in the post!
Various Patches
+10mV Patch:
http://www.box.com/s/5vbo951za4x0yyx9jvn8
+15mV Patch:
http://www.box.com/s/ei3elm0d7ey30a2pbfvh
BPP Patch Default 24BPP:
http://www.box.com/s/3ikgfufphfb3bl5x7805
Flashing now! What are the differences from the first beta in Topogigi's thread?
Ah: "And I've released beta1.1 with major battery fix and more UI responsiveness".
Great
wapz said:
Flashing now! What are the differences from the first beta in Topogigi's thread?
Click to expand...
Click to collapse
Knwon issues are persistent. Got not much time for it. But it has been overall optimized for more fluid UI responsiveness and more efficient lesser battery drain. this time modded battery driver lessens battery drains and consumptions more than previous test versions.
Thanks for your work!!!
Just flashed beta 1.1 on Topogigi 1.9, will report if i notis any bugs.
A huge tanks to u and all other devs that has finally made me happy white my hardware.
Sent from my LG-P990 using xda premium
Thanks , something new to play, yeahhh
The kernel version is listed correctly now as well
Yes
wapz said:
The kernel version is listed correctly now as well
Click to expand...
Click to collapse
Sent from my LG-P990 using Tapatalk
beta1 in standby (3G, wifi off) use my battery 1-2mA
very GOOD!!!
that is extremely low, nicee
for most efficient effect you need battery calibration as we ve different battery driver this time
PAIIITET said:
beta1 in standby (3G, wifi off) use my battery 1-2mA
very GOOD!!!
Click to expand...
Click to collapse
Sent from my LG-P990 using Tapatalk
i know this dev from samdroid.net (galaxy spica) and i have to say...he's good
At 22% now, will start full recharge too 100% and wipe stats.
Charge full first during phone is off. Then start phone and charge to 100% full status shown , wait till more 15mins 15 minutes more till you see 4182 mv . Then calibrate battery via battery calibration app.
wapz said:
At 22% now, will start full recharge too 100% and wipe stats.
Click to expand...
Click to collapse
Sent from my LG-P990 using Tapatalk
Hey man nice to c u inhere i miss spica still:/ you got lg 2x?
ker0ltjuh said:
i know this dev from samdroid.net (galaxy spica) and i have to say...he's good
Click to expand...
Click to collapse
Sent from my LG-P990 using Tapatalk
So this kernel reduces battery drain upto 50%? Lets say I do happen to do something wrong, I can always smart flash right?
Does GPS work for you mates, or this is Topo's ROM problem?
downloaded, installed without any problems and now to test the battery, thanks for the work spica
You can restore if youve backed up
Soulj4h said:
So this kernel reduces battery drain upto 50%? Lets say I do happen to do something wrong, I can always smart flash right?
Click to expand...
Click to collapse
Sent from my LG-P990 using Tapatalk
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
Hello all.
After about a month of researching and testing with the Galaxy S5, I'm finally happy with my SmartKernel profile, with the interactive governor carefully tuned, using known resources and countless trials and errors, as well as other various tweaks, like VM and I/O scheduler, and decided to publish on it's own thread.
The main resources I've used for the Interactive governor tuning includes the well known:
Android Modders Guide;
[GUIDE] Advanced Interactive Governor Tweaks; Buttery smooth and insane battery life! for Nexus 5X; and it's twin
[GUIDE] Advanced Interactive Governor Tweaks; Buttery smooth and insane battery life! for HTC Evo 4G.
First of all, this tweaks should be a little sensible to the ROM, kernel, apps, and other tweaks your using. Like, I just found out that Havoc pie style quicktile settings use way more juice then if I turn it off and go back to Oreo default. Bellow you will see the apps I mainly crafted this profile in mind.
For reference: I have a klte with latest Oreo Havoc installed, nano OpenGapps, Magisk and the SmartPack kernel. For apps I use Facebook lite, cause the normal app is just a big hog, whatsapp and instagram social apps. Chrome. I don't use the Google App or Greenify(uninstall/delete velvet). And play lots of games like Clash Royale, Star Wars Force Arena and Arena of Valor. BetterBatteryStats.
And a lot of random apps that normally don't stay on the background.
DESCRIPTION
On the SmartPack manager profile:
. HIghly Efficient Interactive Governor Tunables (most important part);
. No Touchboost or any other boost, only the governor dictates to CPU in which clock it should to be;
. Overclock disabled, but can be enabled at you will;
. No underclock, I do undervolt my CPU but this you need to find your specific device numbers, mine won't cut;
. LazyPlug Hotplug with all 4 cores on all the time (better performance while using and battery savings while at idle);
. I/O Schedulers: ZEN (the L-Speed profile complement this part, with it's scheduler tunables);
. READ-AHEAD internal 1024kb (for 16GB or more) and external 512 kb (for my 8GB SDCard, adjust accordingly to yours SD Card size conform described here
. Adreno Idler disabled: it doesn't make any effect;
. Speaker Driver Leakage disabled and Boeffla Sound enabled with 0 gain as it does make a difference, at least with ViperFX magisk module installed;
. Screen minimum RGB set to 1 (0 won't stick), for a darker dark on our AMOLED, plus some tweaks;
. Led blinking fade enable;
. VM tweaks: dirty_ratio 30 and dirty_background_ratio 15; for minor battery improvement, with a perceptible lower termperature/cpu usage and almost imperceptible performance hit;
. VM tweaks: page-cluster 1; for better multitasking/memory management
. VM tweaks: oom_dump_tasks 0; disable depuration of dumping tasks, less cpu needed.
. LMK values: 32 48 64 128 176 208 (MBs)
L-Speed Profile
. Logging and I/O stats disabled;
. Animations speed set to 0.25x;
. System battery save trigger at 20%;
If you need to provide or read logs, enable logging and i/o stats back on l speed; i/o stats and oom_dump_tasks 1 on smartpack manager
INSTALLATION
Unzip the attached file and import with SmartPack Manager:
The attached profile should be imported, applied and marked as to run "On Boot" to make effect. It will only work with SmartPack Manager and Kernels for both Nougat and Oreo, maybe even Pie. Just try it, and report back. If you wanna fine tune it. You need to use an app or enable the "show cpu clocks" option if your rom supports it (like Havoc, RR and many more), and monitor at which frequencies the lags happens, while doing the jobs you want the CPU to be efficient at. And mainly tweak the target_load according, maybe above_high_speed delays of 1,7GHz clock and above. You need to read the guides more in-dept too see exactly how to do it, but I'll paste here the most important parts on how to tweak this settings more to your Galaxy S5, with your particularly apps and ROM:
soniCron said:
Optimize Idle Frequency
Now that you've got the base configuration, we need to tweak it so that the CPU stays at your efficient idle frequency (384Mhz in this case) without spontaneously jumping when your phone is actually idle. To do this, open a CPU monitor that displays the current core frequencies (I like CoolTool, but you can use what you like as long as it doesn't significantly impact the CPU use--you're best off using a passive monitor and checking the results after 30-60 seconds of no activity), watch the frequencies and see how often they go above your efficient idle frequency when you're not doing anything at all, and adjust the following:
timer_rate - If your idle frequency is not being exceeded much, adjust this downward in increments of 5000 until it is, then increase it by 5000. If your idle frequency is being exceeded often, adjust this upward in increments of 5000 until your CPU primarily stays at or below your desired idle frequency.
above_highspeed_delay - Only if your timer_rate has matched or exceeded 50000 and still won't stay at or below your desired idle frequency most of the time, set timer_rate to 50000 and adjust the "20000" portion of the value upwards in increments of 5000 until the idle frequency has stabilized.
The lower these two values are, the more snappy/lag free your system will be. So try to get them as low as possible without the idle frequency being exceeded too much, as this inversely affects the snappiness and efficiency of your phone when you're not doing anything. Lower = snappier but uses more CPU when you're not doing anything (such as reading a webpage); higher = less snappy but stays in a power saving state more often reducing CPU use when you're not interacting with the device. These are the most critical in determining your idle power savings, so keep that in mind if you want the most battery life!
Enhance Task Responsiveness
Now use the efficiency and nominal clock rate correlations you made for your master clock rate list in the section above and adjust your frequencies to suit your usage patterns. For example, I had web page scrolling as my 710Mhz/864Mhz rates, so I will open a web page and scroll and see how everything feels. If it feels sluggish, I will increase all the references to "710000" in both above_highspeed_delay and target_loads upwards to the next available clock rate until that task is smooth. What you are looking for is constant poor/sluggish performance when the task you're testing for is using its highest CPU use. If the task becomes sluggish/stuttery as it winds down (such as a scrolling webpage slowing to a stop), we will address that next, so do not take that behavior into consideration as you adjust these values! If the task is smooth until (or after) it slows down, then you have reached your optimal clock rate and can move on.
If you need to exceed your nominal clock rate for a particular task, first measure it again just to be sure you had it correct. If you did indeed have it correct, leave it at your nominal clock rate and adjust the value after the colon next to the task frequency you're tuning downward in increments of 5. For example, if my setting of "864000:80" is still not sufficient, I will adjust it first to "864000:75", then "864000:70", and so on until the task is smooth. However, it almost certainly won't come to this, but if you reach ":50" and the task still isn't performing how you want, set it back to ":80" and increase the clock step once more, then decrease the ":80" until it is smooth.
Do the same for each other frequency in your master clock rate list until you are satisfied. If you have chosen to use more than 2 primary clock rates, add them and use ":##" values between the two surrounding frequency values.
Fix Stuttering
Now that you have adjusted your frequencies for optimal high CPU use in each given task, you may notice some stuttering as the task winds down. (Such as a scrolling webpage slowing to a stop.) If this bothers you, you can tweak this at the expense of some (minor) battery life by adjusting min_sample_time up in increments of 5000 until you are satisfied.
If you have exceeded a value of 100000 for the min_sample_time setting and still are not satisfied, change it back to 40000 and increase (and re-optimize) your idle frequency by one step. This will impact battery life more, but less than if you were to keep increasing the value of min_sample_time.
Adjust High Load Clock Rates
You're almost done! Now you can leave everything as is and be satisfied with your amazing, buttery smooth, snappy experience, or you can optionally tweak things further to either increase the responsiveness of high load tasks (such as loading image previews in Gallery) or increase battery life somewhat.
Adjust the final delay value in above_highspeed_delay to suit your needs. The default ("150000") means that the CPU load at the highest set frequency (default "1026000") will have to be sustained for 150ms before it allows the load to go above that frequency. Increasing this value will prevent the CPU from reaching higher frequencies (which may be unnecessary) as often, saving battery life. This will come at the expense of burst-type high CPU load tasks. Reducing it will allow the CPU to reach higher frequencies more often, at the expense of battery life. However, adjusting this is probably unnecessary, as it will most likely not yield any perceptible difference in performance. It is recommended to leave this value at its default.
Click to expand...
Click to collapse
Besides CPU Voltage and Battery, all tabs on the manager are modified and tuned to achieve best performance, while having best efficiency possible. Is not a battery or a performance, but a efficiency profile.
Refer to this thread if you wanna undervolt your device with a well know secure margin for the CPU Snapdragon 801 2.5ghz MSM8974AC, which our Galaxy S5 contains:
[GUIDE] Snapdragon 805/801/800/600 Clock & Voltage (PVS bin) guide by HD2Owner I've managed to achieve much lower voltages then PSV15+ devices (refer to the sheets).
I also attached the excel spreadsheet I've made with all this thread information, both governor guide equations on target loads, undervolting guide findings, and made my own base calculations and settings. Feel free to use, modify, and discuss it with me. You will see that I based the most efficient clocks in an original thought about which ones are the most efficient, instead of plotting the differentials between voltages of each clocks, I did plotted the difference of the clock divided by voltage, which on itself should be how much voltage 1 mhz uses, on each clock rate. So, the higher the number, more speed each clock rate give us by voltage used. It's kinda complicated and idk if I explained it the right way, and even if it really makes sense under scrutiny, but I couldn't think why not myself, so, any inputs are welcome.
I own my thanks to all the following XDA fellows, without them, I could not have achieved this:
@sunilpaulmathew for the SmartPack Kernel which is the only kernel for the S5 that can turn that damned MPDecision off and SmartPack Manager;
@soniCron for both of the governos Guides;
@Saber for the Android Modders Guide which is immensely helpful.
CHANGELOGS
L-Speed Profile (download the app on PlayStore):
011118 lspeed profile
- first release
031118 lspeed profile
- Removed most tweaks, only left minor stuff, refer to the OP.
L Speed profile is not really needed, SmartPack will do 99% of the job.
SmartPack Manger Profile (download the kernel and the app here):
301018
- first release.
011118 smartpack profile:
- A few Interactive governor tweaks;
- Removed Virtual Memory and LMK tweaks, let it on default or use L-Speed to optimize, as it does a much better job then me.
031118 smartpack profile:
- Governor tunning: better high load management;
- Included back only 3 sane VM configurations, no more freezing, better cooling (less cpu needed, while performance barely took a hit)
- Sane LMK configurations, kills apps not being used faster, retain some multitasking while not let it slow down the device
081118 smartpack profile:
- target_load (no changes up to 1497600) ...1728000:89 1958400:91 2265600:95 -> ...1728000:88 1958400:90 2265600:95
- above_hispeed 20000 1190400:60000 1497600:64000 1728000:77000 1958400:84000 2265600:130000 -> 20000 1190400:60000 1728000:68000 1958400:79000 2265600:110000
- external storage read-ahead from 512 -> 2048 (because I've gone from a 8GB to a 32 GB SDCard, ADJUST YOURS ACCORDINGLY TO https://androidmodguide.blogspot.com/p/io-schedulers.html)
- cleaned unused and already default values from profile
101118 smartpack profile:
- Turned Alucard off, accidentally activated it with Lazyplug also enabled, not good!
- Managed to go 1 point higher on freq 1497 MHz, the 2 hotplugs enabled were messing with me trying to test this change before, also 1 point lower on the idle freq 268 MHz for smoother scrolling while still staying at freq 268 while idle. And some more high load optimizations now that I only got 1 hotplug enabled as it should always be.
- target_loads from 268800:29 ... 1497600:86 1574400:5 1728000:88 1958400:90 2265600:95 to -> 268800:28 ... 1497600:87 1574400:5 1728000:89 1958400:91 2265600:94
- above_hispeed 20000 1190400:60000 1728000:68000 1958400:79000 2265600:110000 -> 20000 1190400:60000 1728000:74000 1958400:82000 2265600:120000
- dirty_background_ratio 15 -> 10
221118 smartpack profile:
. Reverted new SmartPack Kernel v14r4 changes to Virtual Memory back to original default configurations, if you've have had reboots this should fix it, please report back here and/or the kernel's thread;
. More changes to Interactive governor aiming to optimize high load scenarios according to the profile philosophy:
. above_hispeed_delay 20000 1190400:60000 1728000:74000 1958400:82000 2265600:120000 -> 20000 1190400:60000 1728000:74000 1958400:80000 2265600:105000;
. Enabled fast charge configurations, set at 1200 mhA as I found it's a good charging speed without heating the phone too much on my hot city, nothing you can't change at your will.
241218 smartpack profile:
. Restored missing min_sample_time tunable since 081018 profile
. dirty_ratio 30 -> 25
. General cleanup
. Tested on Pie
@justjr
Nice work friend. Great to see that your finally open a place to share your findings. In my opinion, your profile should work on any klte device with minimum kernel support. I haven't seen much SmartPack specific stuff in your profile except some hotplug related things. So, if you make it as a shell script instead of KA/SP-Kernel Manager profile, it shall be beneficial for everyone. Anyway, as usual, I'll kang your changes to my kernel default profile
sunilpaulmathew said:
@justjr
Nice work friend. Great to see that your finally open a place to share your findings. In my opinion, your profile should work on any klte device with minimum kernel support. I haven't seen much SmartPack specific stuff in your profile except some hotplug related things. So, if you make it as a shell script instead of KA/SP-Kernel Manager profile, it shall be beneficial for everyone. Anyway, as usual, I'll kang your changes to my kernel default profile
Click to expand...
Click to collapse
I think this profile should work on original Kernel Adiutor, or any fork of it, shouldn't it?
It should work on any other kernel if the changes really stick, and uses the same paths, but MPDecision will mess with frequencies all the time. It would still follow the governor tunables anyway, but it will interfere with it and in the end will not gain too much efficiency out of it.
Actually I only state it is for SmartPack specifically because of the fact that is the only one I can disable MPDecision on our device, and because I included all the tweaks other then just governor tweaks.
Actually I'm kinda lazy right now, but I could do a shell script if any demand for it shows up.
justjr said:
I think this profile should work on original Kernel Adiutor, or any fork of it, shouldn't it?
It should work on any other kernel if the changes really stick, and uses the same paths, but MPDecision will mess with frequencies all the time. It would still follow the governor tunables anyway, but it will interfere with it and in the end will not gain too much efficiency out of it.
Actually I only state it is for SmartPack specifically because of the fact that is the only one I can disable MPDecision on our device, and because I included all the tweaks other then just governor tweaks.
Actually I'm kinda lazy right now, but I could do a shell script if any demand for it shows up.
Click to expand...
Click to collapse
Well, official KA (free version) doesn't allow to import profiles (paid feature), but all other mods does.
and yes, it is supposed to work on every klte device as long as the sysfs paths exist. Means it should work on any custom Kernel with lazyplug support (most of the other stuff are actually included in the stock kernel itself). Of course, the default settings provided by the kernel devs might conflict. e.g., as you said, MPDecision, although the line "stop mpdecison" in your profile will disable it. By the way, I'm not the only one who disabled mpdecision and relay on other hotplugs in this klte community
sunilpaulmathew said:
Well, official KA (free version) doesn't allow to import profiles (paid feature), but all other mods does.
and yes, it is supposed to work on every klte device as long as the sysfs paths exist. Means it should work on any custom Kernel with lazyplug support (most of the other stuff are actually included in the stock kernel itself). Of course, the default settings provided by the kernel devs might conflict. e.g., as you said, MPDecision, although the line "stop mpdecison" in your profile will disable it. By the way, I'm not the only one who disabled mpdecision and relay on other hotplugs in this klte community
Click to expand...
Click to collapse
Oh, really? Which one? I must had missed it. I've tested all kernels I could find. At least all the remotely up-to-date, like venom, tuned and boeffla kernels. I didn't see any option to change hotplugs on any. There were hotplug profiles, to keep cores online and stuff, but everyone of them keep changing min and max frequency at MPDecision will.
justjr said:
Oh, really? Which one? I must had missed it. I've tested all kernels I could find. At least all the remotely up-to-date, like venom, tuned and boeffla kernels. I didn't see any option to change hotplugs on any. There were hotplug profiles, to keep cores online and stuff, but everyone of them keep changing min and max frequency at MPDecision will.
Click to expand...
Click to collapse
Boeffla and Venom largely depends on MPDecision. However, as I remember correctly (on the basis of the code review, not from my experience, I never used it by myself), the Tuned kernel by @fbs disabled MPDecision upon booting to work well with its own Tuned hotplug.
sunilpaulmathew said:
Boeffla and Venom largely depends on MPDecision. However, as I remember correctly (on the basis of the code review, not from my experience, I never used it by myself), the Tuned kernel by @fbs disabled MPDecision upon booting to work well with its own Tuned hotplug.
Click to expand...
Click to collapse
I tested it too. And although he claims he uses hes own hotplug, it behave the same as boeffla and venom, it has the same profiles, and it does changes min and max freq out of my control.
justjr said:
I tested it too. And although he claims he uses hes own hotplug, it behave the same as boeffla and venom, it has the same profiles, and it does changes min and max freq out of my control.
Click to expand...
Click to collapse
no it doesn't change any freqs
it works by disabling or enabling cores, just that.
if any cpu reaches the maximum frequency, it enables one more core (as the other ones are already giving their best)
if any cpu reaches the minimum frequency too many times, it disables it (as it doesn't seem to be needed)
so in any moment you can have all 4 cores enabled or only 1. even with display on or off, it doesn't matter
mpdecision will NEVER let you use just 1 core, and it doesn't react as fast: battery hog
fbs said:
no it doesn't change any freqs
it works by disabling or enabling cores, just that.
if any cpu reaches the maximum frequency, it enables one more core (as the other ones are already giving their best)
if any cpu reaches the minimum frequency too many times, it disables it (as it doesn't seem to be needed)
so in any moment you can have all 4 cores enabled or only 1. even with display on or off, it doesn't matter
mpdecision will NEVER let you use just 1 core, and it doesn't react as fast: battery hog
Click to expand...
Click to collapse
Alright, sorry then, it seems my memories got clouded or something, as I've tested it about a month ago. I might go back any day just to test that. Thanks for giving us one more kernel option! :good:
UPDATE OP WITH
Description
Changelogs
New profile 011118, changelog:
. Few governor tweaks
. Removed Virtual Memory and LMK tweaks, let it on default or use L-Speed to optimize, it does a much better job then me
Also uploading the L-Speed profile I use so those who want to use it like I do, but you can choose any VM and LMK profile that fits your needs on the app. Just don't use the governor tuner because it will mess with my tunings, and l-speed governor tuning is a generic one for all devices, VM and LMK is OK to use generic tweaks, but not on governor.
@sunilpaulmathew I took a look at l-speed virtual memory and lmk profiles and they make incredible sense, take a look yourself, they may be what you need to put o that spectrum profiles, because above all they are device independent and do make a noticeable difference.
Is it valide for stock rom (6.0)?
lollazzo said:
Is it valide for stock rom (6.0)?
Click to expand...
Click to collapse
What kernel? It should work if the kernel have lazyplug or alucard hotplug, if is the late you just have to enable it.
Updates
SmartPack Manager Profile 031118:
. Governor tunning: better high load management;
. Included back only 3 sane VM configurations, no more freezing, better cooling (less cpu needed, while performance barely took a hit)
. Sane LMK configurations, kills apps not being used faster, retain some multitasking while not let it slow down the device
LSpeed Profile 031118:
. Removed most tweaks, only left minor stuff, refer to the OP.
L Speed profile is not really needed, SmartPack will do 99% of the job.
OP: descriptions for both profiles updated.
New profile.
I returned to Nougat, RR 5.8.5, same configs works awesomely and the device is cooler/faster then with Oreo. But still will works the same with both N/O and even Pie, not tested.
I also reinstalled Hearthstone as a high load app so I could tune the governor better for it, and up to 1490 MHz nothing is changed, and changed a bit target_loads and above_hispeed of the clocks above it so Hearthstone (and any other high load apps, or, using split screen with youtube) runs smoother/without lags and tasks like opening an app will finish faster, and also go back to a lower clock faster because of that. So, in the end it stays most of the time at lower clocks anyway, only difference is that it will jump faster when needed for less waiting time/lag.
Just to clarify, this is not suppose to waste battery, or drain it faster. As an efficiency profile the goal is to do the job you the want faster the possible, ramping up to the clocks that the jobs demands, without lags (or minimal lags) and go back to idle/lower clocks as soon as high clocks aren't needed anymore, so it don't overstay at a higher clocks then it's needed, very simple.
So, going to a high clock doesn't mean less battery life, finishing a job fast and going back to idle is the key to achieve more battery life, specially during deep sleep, when you really want your device go back to deep sleep fast, but also at any other time. Watching youtube, browsing and using low demand apps still uses the same clocks.
Also, on top of that you will spend more time USING the device instead of WAITING for it to finish a job. Battery life is very subjective, and SoT doesn't mean nothing IRL, I mean, are you spend that SoT waiting for a job to finish or to actually use the device?
081118 smartpack profile:
- target_load (no changes up to 1497600) ...1728000:89 1958400:91 2265600:95 -> ...1728000:88 1958400:90 2265600:95
- above_hispeed 20000 1190400:60000 1497600:64000 1728000:77000 1958400:84000 2265600:130000 -> 20000 1190400:60000 1728000:68000 1958400:79000 2265600:110000
- external storage read-ahead from 512 -> 2048 (because I've gone from a 8GB to a 32 GB SDCard, ADJUST YOURS ACCORDINGLY TO https://androidmodguide.blogspot.com/p/io-schedulers.html)
- cleaned unused and already default values from profile
File attached on OP.
I don't use SD card so what do I do?
razor17 said:
I don't use SD card so what do I do?
Click to expand...
Click to collapse
In that case nothing is needed, the configurations related to the absent sd card will not be applied.
Ok guys. I was wondering why my device was heating a lot more these last 2 days. Turns out both Alucard and Lazyplug were accidentally activated on 081119 profile. Turn one of them off and everything will be a lot better. Sorry for that. I will upload a new profile very soon.
edit:
101118 smartpack profile:
- Turned Alucard off, accidentally activated it with Lazyplug also enabled, not good!
- Managed to go 1 point higher on freq 1497 MHz, the 2 hotplugs enabled were messing with me trying to test this change before, also 1 point lower on the idle freq 268 MHz for smoother scrolling while still staying at freq 268 while idle. And some more high load optimizations now that I only got 1 hotplug enabled as it should always be.
- target_loads from 268800:29 ... 1497600:86 1574400:5 1728000:88 1958400:90 2265600:95 to -> 268800:28 ... 1497600:87 1574400:5 1728000:89 1958400:91 2265600:94
- above_hispeed 20000 1190400:60000 1728000:68000 1958400:79000 2265600:110000 -> 20000 1190400:60000 1728000:74000 1958400:82000 2265600:120000
- dirty_background_ratio 15 -> 10
I will give this a try. Hope it works well...
Yeah.
You know, try it and report back. I don't see any reports, so I assume is working well for people.
Any reports are welcome.
lentm said:
I will give this a try. Hope it works well...
Click to expand...
Click to collapse
Enviado de meu SM-G900M usando o Tapatalk
justjr said:
Yeah.
You know, try it and report back. I don't see any reports, so I assume is working well for people.
Any reports are welcome.
Enviado de meu SM-G900M usando o Tapatalk
Click to expand...
Click to collapse
No problems so far...greats for daily use..scrolling smoother than default..but pubg still laggy on lower res...may i know which rom are u using?
Introduction:
Hello everyone!
The idea to this 'project' did blossom after having an conversation with @pkgnex in the past about the general idea of creating something else that follows what he started with his PK's Tuning Script for Pixel 2 (XL) but with a twist, mainly as a complement to his own thread that you can find here, but also with a completely different vision and focus on what the script itself should achieve (and deliver) for kind of results for myself and for all of you personally, of course, that wants to try it out and use it as a "daily driver".
Shortly explained.
This script is created with the goal of improving both battery life and performance on our Pixel 3a (XL) devices, and after a whole range of configurations and various set-ups, I've come up with something that, in my eyes, is worth sharing with all of you so that you can try it out yourself and judge on your own, with constructive feedback on what can be improved or added in future releases - if desired. My philosophy is, and will always be, this:
If something can be improved or altered in a positive way so the average user can feel and see a difference, then go for it. Non stop.
The latest release can be found here.
Disclaimer:
This is presented as "what if". If this modification screws up or breaks anything for you, I am not the one to be held responsible. It's a free will to try out this kind of changes/modifications/addons/tweaks, just don't blame the inventors for eventual bad results and/or screw-ups.
Note: This script is not recommended to be modified or customized by the user.
Features:
Reduced battery consumption
Device specific enhancements for best possible balance between battery life & performance
Enabled, and fully configured, Boeffla generic kernel wakelock blocker
Disabled a lot of useless stuff at kernel level (Improves battery life as well as performance)
CPUSet improvements & optimizations
Power efficiency enhancements
Wide IO block tuning (Reduces the possibility of hiccups, lags and overhead)
Possibly other miscellaneous things I've forgotten to write down here, both big and small.
Requirements/what you need for getting this script fully working:
An unlocked bootloader
Your own specific choice of kernel
Latest possible version of Magisk
Busybox for Android NDK Magisk Module by @osm0sis
Patience
Installation/How-To use & abuse:
1) Download the attached ZIP
2) Extract the script
3) Move the script to the following location;
/data/adb/service.d and give it the following & needed file permissions (0755)
4) Reboot your phone, let Android boot to the launcher and let Magisk boot service do its crucial magic (takes a few seconds before the scripts is fully up and running around behind the scenes)
5) Enjoy!
Note: If you still are unsure how to do for making my kernel configuration / modification work & be up and running behind the scenes, then please read @Phalanx7621 phenomenal guide here or check out @Phalanx7621 in-depth video here. The installation method is the same for all generations of released Pixels!
Credits:
@franciscofranco for all the information on which kernel wakelocks that is safe to block
@Phalanx7621 for his phenomenal how-to guide
@Lord Boeffla for his awesome generic kernel wakelock blocker
@pkgnex for inspiring me walking into this partially unknown territory.
@flar2 for his excellent EXKM application and ElementalX Kernel
@osm0sis for his Magisk Busybox module
Everyone that I've forgotten to mention here
Telegram:
If you want to try out betas / previews of my script before they are officially released, or just hangout and chat a little, then join the official Telegram group here
To-Do list:
Optimize and properly tune things even further for best possible balance between battery life, system responsivness and performance
Contributors:
@xFirefly93
Created: 2019-07-06
Last updated: 2019-07-21
Update!
Note: It is recommended that you reboot your phone after you have applied v1.0 so the customized changes / improvements takes full effect and is fully up & running as intended.
Version v1.0 (Initial release):
- Initial test release for Google Pixel 3a (XL)
- Enabled, and tuned, Boefflas wakelock blocker
- Enabled the backlight dimmer per default
- Disabled some useless kernel stuff for less overhead
- Some additional high quality customizations & improvements
If you optionally want to donate a beer or five as a way to show your appreciation for all the dedicated hours and work that I am putting into this mod on a daily rate - then this link is the way to go!
Enjoy!
I try it thanks a lot
Update!
Note: It is recommended that you reboot your phone after you have applied v1.1 so the customized changes / improvements takes full effect and is fully up & running as intended.
Version v1.1 (Semi-major release):
- Adjusted the task scheduler for better system responsivness
- Added my own Schedutil governor profile for a better balance between performance and battery life through the whole day
If you optionally want to donate a beer or five as a way to show your appreciation for all the dedicated hours and work that I am putting into this mod on a daily rate - then this link is the way to go!
Enjoy!
Update!
Note: It is recommended that you reboot your phone after you have applied v1.2 so the customized changes / improvements takes full effect and is fully up & running as intended.
Be aware that you have to flash the Busybox Magisk module by @osm0sis for getting the newest enhancements, that is featured / included on v1.2, up and running as intended!
Version v1.2 (Major release):
- Added a few crucial filesystem tweaks for improved performance (Credits goes to @pkgnex for this contribution. Be aware that you have to flash the Busybox Magisk module for getting those modifications up and running as fully intended)
- Fully removed all of the alternative task scheduler values / settings (they was only causing random freezes and lagspikes)
- Slightly adjusted the default stock CPUSet values for hopefully improved power efficiency as well as system responsivness
- Cleaned up the script on a few minor typos and what not
- Disabled a few minor CPU related loggers (experimental)
- Reduced suspend latency by enabling console_suspend
- Added a few tweaks for overall better network performance
- Shifted to Westwood TCP congestion algorithm per default
- Disabled the useless Adreno GPU frequency throttling tunable
- Disabled RCU expedited and 'replaced' it with RCU normal for improved real-time latency, CPU utilization and energy efficiency
If you optionally want to donate a beer or five as a way to show your appreciation for all the dedicated hours and work that I am putting into this mod on a daily rate - then this link is the way to go!
Enjoy!
Does 'Boefflas wakelock blocker' also get enabled on stock kernel? I am thinking of getting my Mother the 3a as a present, but would prefer to stick to stock. If not I can flash EX Kernel.
xFirefly93 said:
Update!
Note: It is recommended that you reboot your phone after you have applied v1.2 so the customized changes / improvements takes full effect and is fully up & running as intended.
Be aware that you have to flash the Busybox Magisk module by @osm0sis for getting the newest enhancements, that is featured / included on v1.2, up and running as intended!
Version v1.2 (Major release):
- Added a few crucial filesystem tweaks for improved performance (Credits goes to @pkgnex for this contribution. Be aware that you have to flash the Busybox Magisk module for getting those modifications up and running as fully intended)
- Fully removed all of the alternative task scheduler values / settings (they was only causing random freezes and lagspikes)
- Slightly adjusted the default stock CPUSet values for hopefully improved power efficiency as well as system responsivness
- Cleaned up the script on a few minor typos and what not
- Disabled a few minor CPU related loggers (experimental)
- Reduced suspend latency by enabling console_suspend
- Added a few tweaks for overall better network performance
- Shifted to Westwood TCP congestion algorithm per default
- Disabled the useless Adreno GPU frequency throttling tunable
- Disabled RCU expedited and 'replaced' it with RCU normal for improved real-time latency, CPU utilization and energy efficiency
If you optionally want to donate a beer or five as a way to show your appreciation for all the dedicated hours and work that I am putting into this mod on a daily rate - then this link is the way to go!
Enjoy!
Click to expand...
Click to collapse
My pixel didn't go Deep sleep with 1.2
MrPhilo said:
Does 'Boefflas wakelock blocker' also get enabled on stock kernel? I am thinking of getting my Mother the 3a as a present, but would prefer to stick to stock. If not I can flash EX Kernel.
Click to expand...
Click to collapse
It does only exist on a few selected custom kernels.
djisma86 said:
My pixel didn't go Deep sleep with 1.2
Click to expand...
Click to collapse
Deep sleep is fine for me here. Go and check which partial wakelocks that is screwing up your phone by using BBS.
How do I know it's working? Set the permissions to 755.
Sent from my Pixel 3a XL using Tapatalk
arenaboy007 said:
How do I know it's working? Set the permissions to 755.
Click to expand...
Click to collapse
The changelog isn't needed inside the service.d folder.. ;p
And.. Have you created a logs folder inside your internal storage on your device, and tried with rebooting once?
xFirefly93 said:
The changelog isn't needed inside the service.d folder.. ;p
And.. Have you created a logs folder inside your internal storage on your device, and tried with rebooting once?
Click to expand...
Click to collapse
I have not created a logs folder yet. How do I generate one? So far I moved the file in the service.d folder and media/0 folder.
Sent from my Pixel 3a XL using Tapatalk
arenaboy007 said:
I have not created a logs folder yet. How do I generate one? So far I moved the file in the service.d folder and media/0 folder.
Sent from my Pixel 3a XL using Tapatalk
Click to expand...
Click to collapse
You don't have to do it yourself, the automatically folder creation will be featured on v1.3, which will be released either tomorrow or at Friday.
I've to try a few minor things out first before firing it up into the wild.
I have placed the script in both the service.d and 0 folder, but no logs have been generated after reboot? I already have busybox installed too.
Edit: I noticed that some settings within EX Kernel manager have been changed, like cubic to Westwood, and fiops to cfq. I guess it worked?
Sent from my Pixel 3a XL using Tapatalk
arenaboy007 said:
I have placed the script in both the service.d and 0 folder, but no logs have been generated after reboot? I already have busybox installed too.
Edit: I noticed that some settings within EX Kernel manager have been changed, like cubic to Westwood, and fiops to cfq. I guess it worked?
Click to expand...
Click to collapse
Just make a new empty folder on the sdcard. /sdcard/logs/ Then reboot your device. After boot has completely finished wait 30-60 seconds. Then look into the new logs folder. You should see a new log file in the folder. The log tells you that the script has run successfully.
12paq said:
Just make a new empty folder on the sdcard. /sdcard/logs/ Then reboot your device. After boot has completely finished wait 30-60 seconds. Then look into the new logs folder. You should see a new log file in the folder. The log tells you that the script has run successfully.
Click to expand...
Click to collapse
It worked! I created a log folder and on next reboot saw a log inside. Thank you!
Sent from my Pixel 3a XL using Tapatalk
Not for teasing far too much right now but.. The weird maxing out on the LITTLE cluster cores have finally been fixed once and for all!
Thanks to everyone that reported about this issue that I sadly enough introduced.
xFirefly93 said:
Not for teasing far too much right now but.. The weird maxing out on the LITTLE cluster cores have finally been fixed once and for all!
Thanks to everyone that reported about this issue that I sadly enough introduced.
Click to expand...
Click to collapse
Is it possible for you to set the min clock speed to 300mhz for both clusters? This clock speed is available on the elementalx kernel.
Sent from my Pixel 3a XL using Tapatalk
arenaboy007 said:
Is it possible for you to set the min clock speed to 300mhz for both clusters? This clock speed is available on the elementalx kernel.
Click to expand...
Click to collapse
I can give it a try.
Update!
Note: It is recommended that you reboot your phone after you have applied v1.3 so the customized changes / improvements takes full effect and is fully up & running as intended.
Version v1.3 (Minor release):
- Added the needed commands so the logs folder, and the output message, will be automatically generated after each completed boot sequence (Thanks to @crian for giving a few seconds of his time helping me out with this contribution. You rock, dude!)
- Simplified a few explanations of what each section does
- Fully enabled the RET idle power state for both clusters (may, or may not, lead to slightly improved battery life for everyone)
- Most likely fixed the minor issue with the weird all over the place maximum CPU frequency bouncing on the whole LITTLE cluster
If you optionally want to donate a beer or five as a way to show your appreciation for all the dedicated hours and work that I am putting into this mod on a daily rate - then this link is the way to go!
Enjoy!
Update!
Note: It is recommended that you reboot your phone after you have applied v1.4 so the customized changes / improvements takes full effect and is fully up & running as intended.
Version v1.4 (Minor release):
- Disabled RET idle state for all of the cores again (it wasn't showing any major notable power savings as expected)
- Fully disabled the 'block_validity' mount option for the /system partition (this slightly improves overall system performance)
- Enabled power efficient workqueues (improves battery life - was actually enabled on v1.3, it was just I that forgot to mention it)
If you optionally want to donate a beer or five as a way to show your appreciation for all the dedicated hours and work that I am putting into this mod on a daily rate - then this link is the way to go!
Enjoy!