Related
This thread is for those following the battery calibration thread that would like to help build tools to read and set some advanced battery values, and ultimately recalibrate in learning mode.
It takes its inspiration from this forum thread over at precentral :
http://forums.precentral.net/palm-pre/256967-find-out-how-good-bad-your-battery.html
See HOW-TO in post 3 below, or in-thread post from mtw4991, for instructions on using app to calibrate
reference material
battery manufacturer technical info
DS2784 data sheet - http://datasheets.maxim-ic.com/en/ds/DS2784.pdf
Storing Fuel Gauge Parameters in the DS2784 - http://pdfserv.maxim-ic.com/en/an/AN4043.pdf
Lithium-Ion Cell Fuel Gauging with Maxim Battery Monitor ICs - http://pdfserv.maxim-ic.com/en/an/AN131.pdf
code
cyanogenmod github repository / kanged HTC code - http://github.com/CyanogenMod/cm-kernel/blob/android-msm-2.6.34/drivers/power/ds2784_battery.c
HTC Desire - http://developer.htc.com/ (use HTC Desire kernel source code download)
edit 2010/11/17: source code for battery driver mods - http://github.com/thelogin/n1batcal/
edit 2010/12/15: source code for app -
app availability
available from the Android Marketplace
link: https://market.android.com/details?id=net.jonrichards.batterycalibrator.ui (thanks, McFroger3!)
reference info
thread at precentral which was the inspiration for this thread - http://forums.precentral.net/palm-pre/256967-find-out-how-good-bad-your-battery.html
spreadsheet of registers - https://spreadsheets.google.com/ccc...VNzdXpqWVdFejNGM1pLWmc&hl=en&authkey=CJ_ItagO
related apps
Dr. Battery on the Pre - http://discussion.treocentral.com/homebrew-apps/260947-dr-battery.html
specific code references
(with reference to the manufacturer battery info above)
1 - CONTROL REGISTER FORMAT - page 12 - UVEN—Undervoltage Enable
1 - CAPACITY ESTIMATION ALGORITHM - page 21 - Figure 3: Top-Level Algorithm Diagram
1 - page 24
from Active Empty Voltage (VAE) - includes Aging Capacity (AC) and Age Scalar (AS)
CAPACITY ESTIMATION OPERATION - Learn Function ("A continuous charge from empty to full results in a learn cycle." then "First, the active empty point must be detected."!!)
1 - page 25 - STATUS REGISTER FORMAT
(to be completed)
with thanks to RogerPodacter for his help in compiling this list
progress status and useable findings
status
we have made mods to the kernel code (based on 2.6.35.x) to
make any register writable
make the following registers readable: AGE, Vae (ACTIVE_EMPTY_VOLT), and Status Reg (STS)
allow read/write of these registers via virtual files
remove pseudo-extended battery charging
edit 2010/11/17: created a "dumpreg" file to show all registers and their current values
edit 2010/11/17:
work is being done on a GUI app with the following initial functionality:
show when learn mode is hit
save age when learn mode is complete
the following functionality may be in:
option to restore age when app launched
HOW-TO
mtw4991 said:
How to calibrate your battery using the Battery Calibrator App....
(original text: http://forum.xda-developers.com/showpost.php?p=9583271&postcount=340)
1. Use the battery calibrator app v.1.3.0 to do the following:
a. Open the app and go to menu>settings and check all boxes. Auto-on airplane mode is optional
b. set your age to 100 using the battery app under the Learn Prep tab and press Save
c. set your full40 to 1452mAh in the same tab if using the stock capacity OEM battery and press Save
NOTE: set your full40 to 1650mAh or higher if using an aftermarket battery and save
2. In the Learn Prep tab:
a. set your aEvolts to 3201 (type on each line: Register:0x 66 Value: a4 and press save)
b. set your stop charging current to <20mA (Register:0x 65 Value: 06 and press save)
c. if Capacity/mAh drops to near empty prior to 3201mV being reached, the app will automatically raise capacity by 200mAh so phone doesn't auto-shutdown prior to reaching 3201mV
3. Achieving Learn Mode with the app:
a. turn learn mode on in Learn Mode tab
NOTE: to hit learn mode you must keep your current mA above -200mA draw at the empty point! The app will automatically enable GPS polling to keep you above the required minimum current draw.
b. wait for mV to drop to 3201mV (the learn mode pop-up box will appear & learnf button will light up)
c. insert charger IMMEDIATELY! (You will see a pop-up message saying Learn Mode is active.)
d. turn off and close any open apps you have running, but leave Battery Calibrator open.
e. put phone into airplane mode so that you don’t get unexpected current draw near the full point.
f. set SetCPU profile to disable overclocking. (set min/max to the same value, ie. 998\998max)
g. charge for a full 4 hrs with stock battery and screen off, 5 hrs for larger capacity batterys.
NOTE: if you want to, you can actually use your phone until the charge reaches 80-90%, then use airplane mode and DO NOT touch the phone, peek, turn on the screen....DO NOTHING but walk away til time is up.
h. unplug and reboot, your new age should be set automatically. Learn is now complete and your phone should now charge to 100% and die at 0-1%. Also, some have reported having to manually power down/power up with the new app to have age reset by the application. If age isn’t change upon reboot, try power off/power on.
4. Learn Failure:
If your new age shows 94% upon rebooting, then learn mode failed and you need to do it again, paying close attention as charging nears 80% and above. This is where learn mode can be lost by rogue apps, auto-updates, calls, etc pulling the current down below the minimum prematurely.
Note1: As current gets close to <50-60mA don't touch the phone or you may artifically increase the current draw pulling it below 20mA and it will end the learn cycle prematurely. Airplane mode helps prevent that.
Note2: Learn mode cannot be achieve with the phone off. Leave the phone on until learn is complete and the battery status register shows 0x81. Done!
How to perform a Capacity Test for your battery. Credit goes to the infamous Temasek!
Prepare for another learn cycle
This time we will do what I call a capacity test.
Perform another learn cycle.
Once cycle completed do not reboot. Check your battery log using an app like OS Monitor. See your highest achieved capacity at 99-100% before it completed its charge. The capacity should drop below your full40. Read the log properly. The highest achieved capacity before it drop below your full40 will be your new full40 value.
With your new full40 value, perform yet another learn cycle.
Enjoy your new calibrated battery!
Click to expand...
Click to collapse
HOW-TO2:
http://forum.xda-developers.com/showpost.php?p=24599586&postcount=284 (as requested by St4hli)
Initial investigation and analysis
OK, so I'm going to try and use the following repositories in github and in this order:
AOSP > pershoot > CyanogenMod > others
as I'd like it as generic as possible and ideally integrate any patches at the highest level.
Not being an expert in github, you'll have to excuse any obvious noobness! I couldn't see any of the 2784 battery stuff in AOSP so I'm guessing the CM team used the Desire kernel source from developer.htc.com to integrate the files. Actual code here:
http://member.america.htc.com/download/RomCode/Source_and_Binaries/bravo_54b7033a.tar.gz
------
At:
http://github.com/CyanogenMod/cm-kernel/blob/android-msm-2.6.34/drivers/power/ds2784_battery.c
we see device info struct as:
Code:
char raw[DS2784_DATA_SIZE]; /* raw DS2784 data */
struct battery_status status;
struct power_supply bat;
struct workqueue_struct *monitor_wqueue;
struct work_struct monitor_work;
struct alarm alarm;
struct wake_lock work_wake_lock;
with battery_status struct as:
Code:
u8 percentage; /* battery percentage */
u8 charge_source;
u8 status_reg;
u8 battery_full; /* battery full (don't charge) */
i.e. not many properties.
However, from the corresponding include file at:
http://github.com/CyanogenMod/cm-kernel/blob/android-msm-2.6.34/drivers/power/w1_ds2784.h
there are lots of defined registers, including several AGE and FULL_40.
Our 2784 code has both read and write functions (w1_ds2784_read/write), which are used in function ds2784_battery_read_status.
** Objective 1**
title:
to read some additional values such as AGE and FULL_40 and output them.
suggested implementation:
add in some other properties corresponding to AGE and FULL_40 values, populate these in the read function, parse them in the parse_data function, then output them at line 325 of the ds2784_battery.c file. Yes there will be lots of repetition, but the code is easily and quick to modify.
ideal implementation:
write a new app that outputs these but also outputs the status_reg value too. We can then use this to determine if and when our batteries go into "learning" mode. More below.
code-level:
1) modify struct battery_status, adding:
Code:
u16 age;
u16 full_40;
etc, with any other interesting ones too. Might as well grab all of them and output so we can hand-pick the ones that are useful.
2) from line 244 in parse_data, add something like:
Code:
s->age = raw[DS2784_REG_AGE_SCALAR];
etc
may have to convert from hex.
*****************
THEN I opened the HTC ds2784_battery.c and was amazed at what I saw!
*****************
*their* battery_info struct contains:
Code:
u8 level; /* formula */
u8 level_last;
u32 full_bat; /* Full capacity of battery (mAh) */
u32 full_level; /* Full level for battery control */
u8 guage_status_reg;/* guage status*/
u32 acr;
u32 active_empty;
their ds2784_device_info struct:
Code:
int guage_status_reg; /* battery status register offset=01h*/
int full_mah; /* battery full mah */
long full_charge_count; /* Full charge counter */
int acr;
int active_empty;
int full_level; /* Full level for battery control */
OK nothing earthshattering so far, BUT their Calculate_Full_mAh function uses the FULL_40 stuff.
** Objective 2 **
title: write values to registers
implementation: to be discussed once we have the values from Objective 1 and we still need it (i.e. learning mode does not exist or work to recalibrate).
Wrap-up:
The HTC charging code (from line 854) uses the following logic:
Code:
percent < 95, batt full = false
if status_reg = full and current <= 80 and percent = 100
then *IF IT HAS BEEN ONE HOUR OR MORE ON FULL CHARGE*!!!
then stop charging
WOW.
Nice thread. I'll give you a hand with this. Do you still need help getting your kernel compiling set up?
dvgrhl said:
Nice thread. I'll give you a hand with this. Do you still need help getting your kernel compiling set up?
Click to expand...
Click to collapse
yeah - how best to do this? what about gtalk? <mylogin>@gmail.com if you are OK with that. Will be online in two mins
loginwithnoname, very nice summary and overview. the HTC driver is what most interests me. i guess there would be zero chance of using the HTC code and logic, since it seems they A) use the better values of full_capacity, etc rather than the nexus "conservative" estimation. and B) theirs looks a little more straight forward than the nexus one.
where did you find the HTC driver? i cant seem to find it.
nice work!
just in case you still interested, here is the AOSP source code that pershoot used. well he used his code, then he posted this link in the other thread and said this is his current source he's using.
EDIT: sorry i meant this link
EDIT2: geez, still was cm code. i'll find it real quick.
finally:
http://android.git.kernel.org/?p=ke...54cfa3b22c61dd50eae;hb=android-msm-2.6.35-wip
RogerPodacter said:
the HTC driver is what most interests me. i guess there would be zero chance of using the HTC code and logic, since it seems they A) use the better values of full_capacity, etc rather than the nexus "conservative" estimation. and B) theirs looks a little more straight forward than the nexus one.
Click to expand...
Click to collapse
I think their code is old-hat given what we've done in the other thread, apart from the fact they wait an hour before deeming the battery "fully charged". I don't think as techies/devs we need that though.
thelogin said:
I couldn't see any of the 2784 battery stuff in AOSP so I'm guessing the CM team used the Desire kernel source from developer.htc.com to integrate the files. Actual code here:
http://member.america.htc.com/downlo...4b7033a.tar.gz
where did you find the HTC driver? i cant seem to find it.
Click to expand...
Click to collapse
Click to expand...
Click to collapse
aw, come on Rog! that'll be http://developer.htc.com then click the download button for HTC Desire kernel source code
theloginwithnoname said:
I think their code is old-hat given what we've done in the other thread, apart from the fact they wait an hour before deeming the battery "fully charged". I don't think as techies/devs we need that though.
aw, come on Rog! that'll be http://developer.htc.com then click the download button for HTC Desire kernel source code
Click to expand...
Click to collapse
ha i found the HTC developer site, and grabbed the 74mb source kernel for the desire, but i'm at my work computer which i have no admin rights to do anything. how could i view that code? i was hoping for online repositories like github.
RogerPodacter said:
i'm at my work computer which i have no admin rights to do anything. how could i view that code? i was hoping for online repositories like github.
Click to expand...
Click to collapse
It's a .tar.gz so you need to unzip it then extract it. If you're on Windows, I'm told WinZip will unzip/extract it for you (I used 7-Zip); if you're on linux, tar -zxvf <file>.tar.gz will do it for you...
i wont clutter up this thread anymore, but winzip was the first thing i tried. its a strange winzip used here though, so its expected.
theloginwithnoname said:
** Objective 1**
title:
to read some additional values such as AGE and FULL_40 and output them.
suggested implementation:
add in some other properties corresponding to AGE and FULL_40 values, populate these in the read function, parse them in the parse_data function, then output them at line 325 of the ds2784_battery.c file. Yes there will be lots of repetition, but the code is easily and quick to modify.
ideal implementation:
write a new app that outputs these but also outputs the status_reg value too. We can then use this to determine if and when our batteries go into "learning" mode. More below.
Click to expand...
Click to collapse
rather than doing it at line 325, wouldnt it make more sense to modify lines 103-118:
PHP:
unsigned n;
mutex_lock(&battery_log_lock);
seq_printf(sf, "timestamp mV mA avg mA uAh dC %% src mode reg full\n");
for (n = battery_log_tail; n != battery_log_head; n = (n + 1) & BATTERY_LOG_MASK) {
struct battery_status *s = battery_log + n;
seq_printf(sf, "%9d %5d %6d %6d %8d %4d %3d %s %s 0x%02x %d\n",
s->timestamp, s->voltage_uV / 1000,
s->current_uA / 1000, s->current_avg_uA / 1000,
s->charge_uAh, s->temp_C,
s->percentage,
battery_source[s->charge_source],
battery_mode[s->charge_mode],
s->status_reg, s->battery_full);
}
mutex_unlock(&battery_log_lock);
return 0;
how easy would it be to just add on to this? i suck bad a code and talk out my arse, barely enough to see what's going on. i dont even know where to come up with
seq_printf(sf, "%9d %5d %6d %6d %8d %4d %3d %s %s 0x%02x %d\n",
which seems like where the actual data is coming from for each parameter being output. cant we just add our get_full40, scalar, etc onto that output string?
theloginwithnoname said:
code-level:
1) modify struct battery_status, adding:
Code:
u16 age;
u16 full_40;
etc, with any other interesting ones too. Might as well grab all of them and output so we can hand-pick the ones that are useful.
2) from line 244 in parse_data, add something like:
Code:
s->age = raw[DS2784_REG_AGE_SCALAR];
etc
may have to convert from hex.
Click to expand...
Click to collapse
I think the parse function is line 320, i dont see anything at line 244. so the parse and then pr_info is what is output when we see our dmesg log? for the simplest and quickest result, i think adding registers to the batt_log i posted up above would be the path of least resistence, no? (ignore if i make no sense, i'm noob with code).
then objective 2 would be writing back to the register...
this driver also talks about read/write the bits, which i dont know if we looked thru this one yet. its definitely part of all this i think.
cm-kernel / drivers / w1 / w1.h
http://github.com/CyanogenMod/cm-kernel/blob/android-msm-2.6.34/drivers/w1/w1.h
at least i hope it is relevant!
theloginwithnoname said:
yeah - how best to do this? what about gtalk? <mylogin>@gmail.com if you are OK with that. Will be online in two mins
Click to expand...
Click to collapse
Sorry man, I had a hell of a day at work and didn't even get on IM at all or check back on this thread. My IM is my name at gmail.com, so tomorrow I will make sure to be online if you want. I am PST. Have you tried following the guide here: http://wiki.cyanogenmod.com/index.p...m_source#Install_development_support_packages? I assume so. Where do you get stuck at?
Definitely looking forward to this
Something like the Desire one would be nice too,
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
I've been wanting to check the "health" of my battery like how they do on Thinkpads forever.
It shows values like "Design Capacity" & "Full Charge Capacity" to let you see how much your battery is worn. Sometimes I feel like my battery life issues is not with Cyanogen but with the actual battery itself (bought it 2 months used so i dunno how well the other person treated it, came in box and had all original stuff (sealed) tho no scratches!! ) I was thinking to buy another battery and see but might as well get a Seidio then if that's the case
So in that case, the main battery should be "1400 mAh" battery but maybe it's current charge capacity is only 1000mAh so that's why my talk/usage time is low.
Not sure this helps, but just to spark some thinking i grabbed this from page 25 of the spec sheet for the ds2784.
http://datasheets.maxim-ic.com/en/ds/DS2784.pdf
STATUS REGISTER FORMAT
The status register contains bits that report the device status. All bits are set internally. The CHGTF, AEF, SEF, and LEARNF bits are read only. The UVF and PORF bits can be cleared by writing a zero to the bit locations.
PHP:
ADDRESS 01h
BIT 7 - CHGTF
BIT 6 - AEF
BIT 5 - SEF
BIT 4 - LEARNF
BIT 3 - X
BIT 2 - UVF
BIT 1 - PORF
BIT 0 - X
CHGTF—Charge-Termination Flag. CHGTF is set to indicate that the voltage and average current register values have persisted above the VCHG and below the IMIN thresholds sufficiently long to detect a fully charged condition. CHGTF is cleared when RARC is less than 90%. CHGTF is read only.
AEF—Active-Empty Flag. AEF is set to indicate that the battery is at or below the active-empty point. AEF is set when the voltage register value is less than the VAE threshold. AEF is cleared when RARC is greater than 5%. AEF is read only.
Click to expand...
Click to collapse
good spot Rog - I might need to decompile all the tech info and add it as a technical analysis post here. Will be a few days before I can do this though.
I'll post these links here for completeness, it kinda wraps everything up with examples of everything. You really should read when you have a sec.
http://pdfserv.maxim-ic.com/en/an/AN3584.pdf
http://pdfserv.maxim-ic.com/en/an/AN131.pdf
http://pdfserv.maxim-ic.com/en/an/AN4043.pdf
http://pdfserv.maxim-ic.com/en/an/AN3463.pdf
been looking over the code, and i'm pretty sure for phase #1, step #1, to grab the info we need we'd have to add the following line 51, line 224-226, and line 325 and 331:
we need to define the additional variable:
PHP:
48 int current_avg_uA;
49 int charge_uAh;
51 int full40_uAh /*This variable added*/
We need to parse the additional data (MSB and LSB for full40):
PHP:
221 /* RAAC is in units of 1.6mAh */
222 s->charge_uAh = ((raw[DS2784_REG_RAAC_MSB] << 8) |
223 raw[DS2784_REG_RAAC_LSB]) * 1600;
224 /* full40 has same conversion units of 1.6mAh */
225 s->full40_uAh = ((raw[DS2784_REG_FULL_40_MSB] << 8) |
226 raw[DS2784_REG_FULL_40_LSB]) * 1600;
and finally, simplest way i see it is to just add it to the dmesg log (at least right now, later we can do whatever with it):
PHP:
ds2784_parse_data(di->raw, &di->status);
324
325 pr_info("batt: %3d%%, %d mV, %d mA (%d avg), %d.%d C, %d mAh, %d full40 mAh\n",
326 di->status.percentage,
327 di->status.voltage_uV / 1000, di->status.current_uA / 1000,
328 di->status.current_avg_uA / 1000,
329 di->status.temp_C / 10, di->status.temp_C % 10,
330 di->status.charge_uAh / 1000,
331 di->status.full40_uAh / 1000); /*added this output to dmesg log*/
332 return 0;
333 }
the only thing i am not sure on is the conversion units for full40, i cant find it yet. we could just not convert it at all and end up with a large raw value, but that would mess up the dmesg log readability. for above i just assumed it was the same conversion as charge capacity (very well could be the same).
next i'll attempt the same for age scalar.
besides, there is another way to find the full40 value, its the one that your dmesg log jumps to when you hit full charge, but you have to be at +40 C temperature (that's what full40 is, its the max our battery can hold at 40C since the higher the temp, the more capacity our battery can hold). in my case, my getfull40 is 1369 mAh.
should i post this in the battery thread and see if pershoot would compile a test kernel for me? i'd try this out.
EDIT: i'm almost positive this will work, so i'll see how to add in age scalar before posting it in the other thread for pershoot.
Read the Known Issues section of this post below along with the FAQ a few posts down before posting.
A few people have asked about I9100 builds of my Daily Driver kernel for the SGH-I777. I normally hate blind development, but since most I9100 guys are doing it for I777 targets, I may as well try going the other way. Since it fails the definition of being a "daily driver" as I own an I777 and not I9100 - it will not be using the Daily Driver name.
This should be compatible with most stock-derived Gingerbread firmwares, with a few exceptions listed below. It is NOT compatible with CM7/MIUI or any other AOSP-derived firmware. It is NOT compatible with ICS and WILL NOT BE until ICS kernel source for the I9100 is released. At that point a new thread will be created for those kernels. I am testing it currently with self-deodexed/debloated/Hellraised XWLA4.
The following firmware bases are likely to deliver poor battery life with this kernel due to wifi bugs in the firmware:
XXKI3, UCKK6, XWKK5 - especially UCKK6 and XWKK5
This kernel series is intended to be similar in spirit to my Daily Driver series for the Infuse at http://forum.xda-developers.com/showthread.php?t=1212795
It is built from sources at https://github.com/Entropy512/linux_kernel_sgh-i777/commits/oc_codeworkx, and initramfs at https://github.com/Entropy512/initramfs_sgh-i777/commits/master
My general goals are to focus on stability and battery life. If it comes to a tradeoff between performance and the above two, I will choose stability/battery life. In general I will choose stability first, with the exception of undervolting.
I keep my initramfs clean - There are no tweaks or other automated scripts built into this kernel. For a collection of tweaks I am working on and documentation on them, see http://forum.xda-developers.com/showthread.php?t=1378080
Current features:
I9100 Update3 base
Touchscreen drivers from I777 source code base
codeworkx's cpuidle patch - should improve battery life a bit. In most cases it will likely not improve things much, but in rare cases it will result in significant improvements. (I only have one partially-reproducible test case on the Infuse so far)
JHash 3
BFQ I/O scheduler
CIFS module in initramfs
CWM 5.0.2.8 compiled from CM7 sources on 2/28/2012
"insecure" kernel (meaning root in ADB)
CPU governor set to Conservative by default to conserve some battery - this will make your device slightly less responsive, use SetCPU or a similar app to return to ondemand if you want it, or reduce the conservative polling interval
Filesystem readahead tweaks in initramfs
netarchy's Sleep of Death fix
netarchy's conservative governor tuning patch - should improve responsiveness of devices when using the conservative governor if you reduce the polling interval (misnamed as sample_rate) - the I9100 community calls this "lionheart" even though it's really only a 2-line patch
Battery charge current monitoring (CurrentWidget) support - only reports charge current and not discharge, and reports a value 2.85 times the actual current. Use CurrentWidget's "operation on value" to divide by 2.85.
Miscellaneous bugfixes pulled from Ninphetamine and CM7 sources - see github for details
/system/etc/init.d support in initramfs - Note that this only runs stuff in /system/etc/init.d - ROM developers or you need to create it. Attached is an example script that will change the CPU frequency governor to ondemand if placed in /system/etc/init.d and set to executable
Four "use at your own risk" features that trade performance for stability - See Post #4 for details
Standard bootanimation support
/proc/last_kmsg crash debugging support
NFS modules in initramfs - note that they must be insmodded in a specific order: sunrpc.ko, lockd.ko, then nfs.ko
Fix for fuel_alerted perma-wakelocks
Fix for wifi tethering on I9100 ROMs that have been Hellraised to I777
Bump up TCP buffer sizes in initramfs to match that of the Infuse - may help network performance in some cases
cpuidle driver from Tab 7 Plus kernel - allows entry into AFTR more often - includes MFC interoperability fix (Should not break video playback.)
Support Bluetooth HID on newer firmware bases
3-step GPU clock/voltage control
Extended hotplug tuning
Support for Xan's ExTweaks universal tuning app - https://market.android.com/details?id=com.darekxan.extweaks.app
Planned features, short term:
Determine if issues with PINlock when running I9100 firmwares on I777 have kernel involvement, and fix them if this is the case.
Planned features, mid-term:
Potentially my first departure from "standard" governors, with a focus on improving hotplugging logic
Planned features, long-term:
Improved battery charge algorithm for faster charging - Initial research indicates we have an alternate battery charger chip (MAX8922) that differs from the MAX8997 used in the I9100. We DO have an 8997 also - but on our device for some reason Samsung decided to use an alternate chip instead of using the 8997's built-in charging. This means we have far fewer options (90,400,660 mA) in terms of charge rates compared to the I9100 (from 200 to 950 in 50 mA steps). So we might not be able to implement any fancy charging algorithms.
Features not planned:
BFS process scheduler - I have only once ever seen a test case where this clearly outperformed the mainline Linux scheduler (multithread x264 encoding) - The mainline schedule was fixed in the next release and BFS now has no performance benefits
Any feature that trades off stability or data integrity for performance unless it can be disabled entirely and defaulted to "off"
Any feature that cannot have functionality tested without a paid app. Interface-only checks don't cut it - I don't want users complaining that the app they paid for didn't work because an interface check worked but function didn't
Touch recovery - too prone to unintentional user input in dangerous situations. I will reconsider this with ICS.
ARM_TOPOLOGY/SCHED_MC - See http://forum.xda-developers.com/showpost.php?p=23193259&postcount=100 for details
Known issues:
Power management regression somewhere between 12/8/11 and 1/2/12 - Intermittent high drain without high AOS or reduced deep sleep percentage when on some wifi networks - seems more likely if GPS is used when connected to wifi. Wifi with high AOS/reduced deep sleep is not a kernel problem. This appears to only happen on some firmwares - it happens on XXKI3 but not XWKL1. It is likely connected to a wifi power management bug in some firmwares. A debugging feature in 2/7 and later will allow identification of such firmwares - see http://forum.xda-developers.com/showpost.php?p=22581928&postcount=1777 for details
Some people have reported touchkey lights becoming disabled until the screen is turned off and back on again. Under investigation - seems to mainly happen on firmwares with BLN-modded liblights even if the BLN app isn't used
Internal and External SD card are swapped in CWM currently
Keymap is a little funky in CWM for I9100 users. VolUp/VolDn to move, Power to select is reported to work, but bottom keys are funky. Working on it
A few users have reported that when Hellraising I9100 firmwares to I777, they are unable to set up a PIN-lock. If this occurs for I9100 users on their own devices, I need to look into initramfs fixes and this will be my top priority.
Basic flashing instructions for .tar releases (NOTE - There are currently no releases in this category. These instructions only remain for heimdall+ZIP users:
(Tested on Linux, not tested MacOS/Windows but should work) Heimdall - Extract the contents of the tar file, enter download mode, and flash with the following command line:
Code:
heimdall flash --kernel zImage
Flashing instructions for .zip releases:
Flash in CWM, or extract the zImage and use the Heimdall instructions above.
Please do not ask how to enter download mode or install Heimdall/Odin in this thread - these are basic generic skills anyone flashing custom firmwares on Samsung devices should know and plenty of documentation exists elsewhere. If you really need to ask, use the General forum, or if created, the Q&A forum. I want to try to keep this thread clean and only with bug reports and issues specific to this release, not general HOWTO or troubleshooting posts. Some of the information you need is in jivy26's FAQs thread at http://forum.xda-developers.com/showthread.php?t=1288112 - Reading at least the first post of this thread in its entirety is STRONGLY recommended.
Bug reports:
If you have a crash (reboot all the way to Galaxy S I9100 screen), use ADB dump the contents of /proc/last_kmsg and post
If you have oddball behavior, include a clearly reproducible test case with your report, or use ADB to obtain a dmesg and logcat capturing the odd behavior at the time of error.
Similar to flashing - using ADB and obtaining last_kmsg, dmesg, and logcat dumps are basic skills that anyone working with custom firmwares on Android devices should have. If you need help with these, do some searching, or post in the General forum or Q&A forum.
Firmware ("ROM") Developers:
While I cannot restrict anyone from putting this kernel into a ROM as long as links are given to the github sources for GPL compliance, I request that anyone who includes this kernel in a firmware release does the following out of courtesy:
Link to this thread
Clearly indicate in your firmware changelog which Daily Driver kernel release is included in your firmware release whenever you change DD releases - this lets users identify whether a fix is present in the kernel they're using or not
Kernel Developers:
Similar to my request for ROM developers, while I can't restrict you from doing anything, I ask as a courtesy that if you cherry-pick my commits, you do the following:
Please don't rebase my commits into a large multi-feature without consulting me - rebasing related bugfixes together is OK.
Please try not to implement lots of unrelated features or bugfixes in a single git commit - it makes it hard to reimplement that when Samsung drops new sources or releases a new device
ALL OF MY RELEASES ARE NAMED BY RELEASE DATE - MMDDYYYY. See the changelog for differences between Experimental (exp) and non-exp versions for days where dual releases are made.
Change Log
The primary change log will be kept in my I777 kernel thread at http://forum.xda-developers.com/showpost.php?p=18129037&postcount=2
Unless I9100-specific items are implemented, this post will simply indicate which I777 release the kernel corresponds to.
3/7/2012:
Corresponds to Daily Driver 3/7/2012
03/05/2012:
Corresponds to Daily Driver 3/5/2012
03/04/2012-B:
Corresponds to Daily Driver 3/4/2012-B
03/04/2012:
Corresponds to Daily Driver 3/4/2012
03/03/2012-B:
Corresponds to Daily Driver 3/3/2012-B
03/03/2012:
Corresponds to Daily Driver 3/3/2012
Initial release was bad, that was an I777 build. Reuploaded at 4:22 PM Eastern Standard time on 3/3 - Redownload if you downloaded before that
3/02/2012:
Corresponds to Daily Driver 3/02/2012
2/28/2012:
Corresponds to Daily Driver 2/28/2012
IMPORTANT: Internal/External sdcards have been swapped in CWM to be consistent with Android standards!
2/26/2012:
Corresponds to Daily Driver 2/26/2012
Initial release, 02/15/2012:
I know it's dated 2/15 and not 2/26, because that's when it was built. Thanks to khartaras for indicating that it isn't at least a horrible turd when used on an I9100.
This release corresponds to the 2/15/2012-C release of I777 Daily Driver
Here Be Dragons
This post is for features present in the kernel that are "use at your own risk" - They have either potential or guaranteed negative side effects if used.
Overclocking (CPU):
Enable using SetCPU or a similar app
USE AT YOUR OWN RISK. DO NOT REPORT BUGS OR PROBLEMS IF YOU ARE OVERCLOCKING OR UNDERVOLTING. IF YOU EXPERIENCE ANY STABILITY PROBLEMS, DISABLE ALL OC/UV
Overclocking (GPU):
See Ninphetamine kernel for documentation - Same control method
USE AT YOUR OWN RISK. DO NOT REPORT BUGS OR PROBLEMS IF YOU ARE OVERCLOCKING. IF YOU EXPERIENCE ANY STABILITY PROBLEMS, DISABLE ALL OC
Per-File fsync() disable:
This allows you to disable per-file write forced syncs. (e.g. if an app tries to force a write straight to disk, it'll just go to cache). This achieves the same goal as the modded sqlite hacks seen in tweaks such as USAS, however it can be disabled at runtime.
WARNING: THIS CAN CAUSE DATA LOSS OR CORRUPTION IN A CRASH
To enable, do the following in a terminal, or add it to an init.d script (look at my ondemand script as an example):
Code:
echo "1" > /sys/module/sync/parameters/fsync_disabled
And to disable (return to the default):
Code:
echo "0" > /sys/module/sync/parameters/fsync_disabled
Good for around 200 points of epeen in the database benchmarks in Antutu or 500-600 points of epeen in Quadrant. Real-world benefit: Probably not worth the data integrity risk, but you've got a choice now.
Backlight Notifications (BLN):
This allows the touchkey backlights to be used for notifications. Some stock apps (such as stock MMS) don't support it. Supposedly services.jar mods can change this.
This WILL drain your battery when a notification is active due to a wakelock that holds deep sleep. Sorry, it's either this or instability for the time being.
In addition to the BLN control app, the ROM needs a modified liblights file for this to work
Attached here - Liblights - both BLN-modified (extracted from VillainROM 3.0) and stock I777
To install, take the file and push it to /system:
Code:
adb remount
adb push <file> /system/lib/hw/lights.SGH-I777.so
adb chmod 644 /system/lib/hw/lights.SGH-I777.so
Then reboot
Note that on a Hellraised ROM, you need to replace SGH-I777 with GT-I9100. This includes manually ported ROMs like Cognition 777
Like my prerooted system image, this file is compressed using 7-Zip to prevent people from trying to flash it with CWM
OK, right now this post only has documentation of one "special but safe" feature:
To enable debugging of high deleted_wake_locks time, I've set this up to allow wake_lock_destroy() to be debugged without enabling DEBUG_WAKE_LOCK (which spams dmesg with a ton of stuff not needed for wake_lock_destroy() debugging). To enable, add 32 to the value of /sys/module/wakelock/parameters/debug_mask - This defaults to 3, so the proper value is 35.
Code:
echo "35" > /sys/module/wakelock/parameters/debug_mask
Return this to 3 to set it back to the default.
With this, you'll see wake_lock_destroy debugging information in your dmesg output. This is only needed if you have very high deleted_wake_locks times.
The following is known to cause deleted_wake_locks:
Turning off wifi will convert all wlan wakelocks into deleted_wake_locks
FAQ
Q: I installed this and still don't have root?
A: I keep a clean initramfs. There are NO tweak scripts in it, and no autoinjection scripts. To root your device, flash one of ChainsDD's Superuser packages in CWM
Q: I don't like the default I/O governor, why is it this way?
A: Clean initramfs (if you need to flash a kernel cleaner script after my kernel, I have failed or an app cluttered up your init.d) - If you want to change the default governor and tune the filesystem, see my init.d scripts thread.
Q: Why is it so laggy by default?
A: I don't believe in having half my patches tuning default values of things the user can change. In addition, as stated above - battery life is valued over performance, so default governor settings will be biased towards battery. My personal recommendation if you wish to increase performance (at the cost of battery life) is to drop the sample_rate for the conservative governor using SetCPU or a similar tool - this will significantly improve performance. It provides nearly all of the benefits of the original "lionheart" without allowing the sample_rate to go dangerously low. In a future release I'm going to drop the minimum a little bit more.
Q: Something went wrong. I'm using some stupid comprehensive tweakscript. Y U NO FIX?
A: I will not support anyone who is using a comprehensive tweak script (Thunderbolt, V6 Supercharger, etc. - ESPECIALLY V6 Supercharger, as its developer has multiple times in the past put in dangerous tuning options. For example, he disabled the panic reboot timeout, which combined with Samsung's ****ty wifi driver on the Tab 7 Plus, led to multiple Tabs draining their battery all the way to the battery's failsafe cutoff.) If a specific individual tweak causes a problem, let me know - but you'd better know EXACTLY which tweak it is. In addition to the above issues with V6SC, many "tweak scripts" achieve their goals by trading filesystem integrity for performance, and irresponsibly don't warn the user about this fact. See, for example, the fsync disable feature above - it's dangerous, but don't say I didn't warn you it was.
Q: What voltages do you use?
A: This is irrelevant. Every device is different, if a given set of voltages worked on all devices, Samsung would've made it stock. I will report any discussion of voltage recommendations to the moderator for cluttering the thread. If you're undervolting, you need to take responsibility and do it on your own.
Q: Why don't you support AOSP firmwares (CM7, etc.)?
A: I know that the CM team frowns upon alternate kernels as it makes their testing job more difficult. Similarly, supporting too many firmware bases makes my job more difficult. Out of respect for the skills of codeworkx and atinm, I will not release kernels that could make their life harder. I periodically give them the heads-up on patches that I think are important though.
Q: What's with the toilet humor of the name?
A: Long ago in the Infuse community, there was a person (lemons) that was starting to do some smali hacks (camera modding and such), and was planning on eventually releasing a ROM. He was a pretty good guy, and had lots of potential. He and others joked that since it was his first attempt, it should be called ****ROM. Sadly, lemons never followed through and just disappeared, so for months, ****ROM never became a reality. Eventually it was realized in the form of a deodexing/porting/basic modding guide for I777 users at http://forum.xda-developers.com/showthread.php?t=1505685. In addition - I hate hype and marketing, better to set expectations low and let the code prove itself on its own merits. Since I'm blind-developing, I can't just say it's my daily driver because in this case, I am unfortunately not eating my own dogfood.
Q: Why don't you base on 2.6.35.14?
A: That would be my Experimental series. It's temporarily on hold for a variety of reasons but will return once I finish reimplementing some patches. The great thing about git branching is I've been able to maintain .7 and .14 trees simultaneously with ease.
Q: Sometimes my touchscreen is unresponsive right after a wakeup, why?
A: It seems, based on reports from khartras and teiglin, that TouchScreenTuner does not play well with the I777 touchscreen drivers. I'm not sure if it's even necessary with them - in the months since October, the only time I have ever received touchscreen complaints from I777 users was when running I9100 update3 touchscreen drivers. TST may just be working around broken drivers...
Reserved for ?????
Thanks for this. I will try later.
Again very thanks.
Enviado do meu Galaxy S2 usando TapaTalk
Going to try this kernel for the sole reason that I think you're a great guy on here and I enjoy reading your informative posts - you always seek to educate rather than put people down.
Thanks Entropy.
Uploaded a new release, this has just a few small patches, bringing it up to the same base as Daily Driver 2/26/2012
As a compulsive lurker, reader and searcher, ive been looking forward to this release..
Alongside Pulser and Ninpo, your informative postings and professional ethic enable users like myself to maximize the potential of our devices.
Thanks mate, i have no doubt this will be brilliant..
Thanks Entropy, I've missed your work since I moved from Infuse over here instead of to I777-land. I do have a question, though--I note the only "nonstandard" I/O scheduler you included was BFQ. Do you find sio/vr problematic, or do they just not provide any benefit from your perspective?
teiglin said:
Thanks Entropy, I've missed your work since I moved from Infuse over here instead of to I777-land. I do have a question, though--I note the only "nonstandard" I/O scheduler you included was BFQ. Do you find sio/vr problematic, or do they just not provide any benefit from your perspective?
Click to expand...
Click to collapse
I'm considering adding these - I've found that alternate governors/schedulers often cause more problems than they solve.
Thanks for sharing your kernel with us i9100 users Enthropy. I really like your stability+ battery approach. Will be giving the kernel a good go.
Sorry...this kernel is comparible with jkay brightness profile?
Inviato dal mio GT-I9100 usando Tapatalk
coloxim said:
Sorry...this kernel is comparible with jkay brightness profile?
Inviato dal mio GT-I9100 usando Tapatalk
Click to expand...
Click to collapse
No - And right now, I am unaware of any kernel that is. As much as I like JKay's work, I believe he lacks understanding of how screen brightness works on the I9100 and I777.
Even JKay is unaware of any kernels that support those profiles. See entry 12 in his FAQ.
To implement additional brightness steps, an additional gamma table for each brightness step needs to be implemented - https://github.com/Entropy512/linux_kernel_sgh-i777/blob/master/drivers/video/samsung/ld9040_gamma.h
So until FAQ section 12 has clearly defined (and achievable) requirements for compatibility, or JKay declares a specific kernel compatible in FAQ section 12 of his mod, I won't be doing anything. Creating a custom gamma table entry is not easy as it requires a LOT of tweaking and good colorimeter hardware. Supercurio has done it at high brightness levels to my knowledge, but I don't think he's done it for low brightness levels and I don't think he's added extra gamma tables for additional brightness steps.
Edit: I have seen that Speedmod and Redpill do change the table entries for the lowest two brightness settings - however, they don't add any new bins, so the brightness change is achieved even on JKay profiles that don't supposedly require kernel support. e.g. JKay's "dark, requires kernel support" are pointless because the only kernels that actually provide dimmer minimum backlight do so even with his profiles that don't claim to require custom kernels. (And the "super dark" and "dark" profiles will behave the same regardless of kernel.)
What's interesting is hardcore did it for only two of three available panel types. Either two of Samsung's panel types are brighter than others, or hardcore did this without testing on some panel variants and just thought "the numbers are different, I'll change them". I'll look into playing with this as it would be nice to have lower minimum brightness, but it's somewhat low priority as it's easy to simply make things look like **** if you're not careful.
its possible to make your kernel fully compatible with the cmw manager of chainfire
for now some fonctions are desactivate
anyway i m testing it now and all seems to be good
So far so good mate.
Batterylife we will see in a day or two but all in all running fine.
Thanks and go ahead with ur work.
CHEERS ;-)
Sent from my Galaxy S2 - I9100 with SensatioN Rom!
F3nr1s said:
its possible to make your kernel fully compatible with the cmw manager of chainfire
for now some fonctions are desactivate
anyway i m testing it now and all seems to be good
Click to expand...
Click to collapse
Others have asked me this - if he has compatibility guidelines posted somewhere, I'll take a look at them.
{
"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"
}
Battery in deep sleep is exceptional, 2% lost in 5 hours with WiFi enabled and emails syncing.
Sent from my GT-I9100 using XDA App
Facality
weird name for a kernel..or for pretty much anything..dude
Welcome to the Perseus kernel! I thought it would be a nice catchname considering the Galaxy/Universe/Pegasus themes.
I'm trying to be more cutting-edge in terms of development in this kernel. In contrast to other kernels and philosophies of other developers, I don't believe giving the users more choice is a very smart thing to do. As such you won't find a dozen different governors or twenty different settings for this kernel. There is a optimal, or at least, most optimal setting on which the devices operate both in terms of performance and power management. For the average user this kernel will brings lots of benefits to battery life, screen improvement, fluidity and sound enhancements without having to set up any of the configurations.
The kernel comes with a configuration application called STweaks, and is installed automatically with the kernel. You will find all advanced options in there.
Don't be scared by the alpha denomination of the kernel, I'm just taking the traditional naming scheme where alpha designates feature development, beta is feature-completeness, and final will actually be when I'll actively stop developing the kernel. The kernel is very stable, and any bugs are fixed in hotfix versions (alpha x.y)
The kernel is also being maintained and released cross-device for the I9305 (S3 LTE), N7100 (Note 2) and N7105 (Note 2 LTE) and shares the same base-source.
Features / changelist:
Perseus alpha36.3 (26/04):
Fixed slice lookup issue on ABB: It's recommended you put your slices back to default before flashing if you changed them to borderline stability values. Please upgrade.
Perseus alpha36 (22/04):
Adaptive Body Bias control (ABB). (Experimental feature)
Body biasing is taking advantage of transistor body effect for binning the chip depending on its quality. In fact, this is used on the latest Samsung SoCs both for reducing power consumption and validating bad chips by adjusting their electrical characteristics.
The body bias is dictated by the voltage applied to the transistor gate (The usual voltages you're all used to) minus the voltage applied to the transistor body. The resulting bias can change the transistor's electrical characteristics in two possible ways:
Before reading on: A transistor's voltage and operating frequency is defined/limited mostly on its threshold voltage. Wikipedia has a neat visual representation of this; voltage must raise to a certain point for the transistor to be able to switch and operate. This threshold voltage can be highly dependant on temperature, influenced by the body effect, and defined by the manufacturing process. What we're doing nowdays with undervolting is to get as near as possible to the upper bound of this threshold voltage.
With that in mind:
Forward Body Bias
A FBB is defined when the bias of the gate voltage minus body voltage is positive, meaning the gate voltage is higher than the body voltage. This has the effect of reducing the threshold voltage. By reducing it, you can achieve lower voltages, or be able to clock the transistor higher. However the side-effect of lowering the threshold voltage is that you are sacrificing power leakage, meaning that the lower the threshold voltage becomes, the higher leakage current in the transistor becomes. This leakage power rises exponentially with a linear lowering of the threshold voltage. This is what is called static transistor leakage.
Reverse Body Bias
A RBB is defined when the bias of gate voltage minus body voltage is negative, meaning the gate voltage is lower than the body voltage. it has the direct opposite effect of FBB, it raises the threshold voltage thus you would need a higher gate voltage for switching, but however you also dramatically decrease static leakage.
What happens is that you want to use RBB when idling, and a reduced RBB, or even FBB at very high clocks.
Samsung currently uses this on top of voltage scaling to bin their chips. Here's an excerpt of the stock body biasing on the 4412 Prime chip (I'm using that one as an example as it has better adjusted ABB values over the Rev 1.1 chips).
{
"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"
}
To find out your ASV group: You can read out your ASV group in /sys/devices/system/abb/abb_info now.
I have rewritten the ABB scaling logic/driver for CPU, GPU, MIF and INT voltages.
In the current implementation, since it would be insane to have paired-up gate-body voltages divides the frequency range in several slices; even Samsung uses only three voltage ranges on the DVFS scale. I divided the frequency ranges as follows:
CPU: Divided into four slices, with frequency ranges of 200], 800], 1600] and ]1600 Mhz.
GPU: Three slices: 160], 533] and ]533 Mhz.
MIF and INT: Both only two slices with the bottom frequencies for each as middle-threshold.
As mentioned above, controls can be found in /sys/devices/system/abb/ and the entries are self-explanatory. You can also change the frequency slice limits per sysfs, however in STweaks I only included the voltages for each slice only for now.
Disclaimer
{ And that's about it in that regard. I have tried testing things over last couple of weeks, but I haven't come to a solid conclusion yet beyond what's presented by the stock characteristics: It's up to you people to do some advanced testing on the matter. My limited empirical testing in terms of voltages tells me it works as intended, but if a user with advanced measuring equipment would do similar testing to what I did back on the 4210 it would be perfect. }
zRAM: Switched over from LZO to Snappy compression algorithm, this provides much faster compression and decompression than the LZO implementation which was in the current kernel. I updated the Snappy libraries to the latest original CSNAPPY implementation, so this is extremely new.
Some kernel internal updates to speed up hotplugging and improve I/O latencies.
A correctly (Unlike basically every other kernel out there till now) applied load averaging patch regarding fixing a Moiré pattern in the scheduler load calculations which was floating around.
Fixed mono and equalizer switches in the sound engine. (Thanks to sorgelig for beating me to it)
Fixed led controls to behave correctly with user-space apps.
mDNIe digital brightness reduction:
You can now lower the brightness to basically nothing via this: it uses the mDNIe engine to digitally remove luminance from the RGB channel values, as opposed to reducing brightness via a proper backlight/display driver. The side effect of this is that you lose colour resolution somewhat, but is a practical and working method to reduce the too bright minimum values of our displays.
You have three configurables:
A reduction rate which you want to apply, this is the intensity of the darkening you want to achieve.
The take-over point; the backlight driver gets fed brightness values from 0-255 (In reality values below 20 have no effect). The take-over point is the point where the digital brightness reduction starts, on a reverse scale. The reduction is applied linearly from 0, (Full reduction taking place), to the take-over point (Zero reduction). The stock slider doesn't go below 20 in the interface, so practically the full reduction rate is never applied unless you use a third-party brightness controller app, just to keep that in mind, but in practice it doesn't matter.
Auto-brightness input-delta: This is needed because the stock framework is retarded in the values it forwards to the kernel, you can adjust this to avoid having brightness reduction when you don't want it on auto-brightness.
Somebody needs to edit config_autoBrightnessLevels, config_autoBrightnessLcdBacklightValues in framework-res.apk\res\values\arrays.xml to fix this.
Optionally, if you use a third-party app like Custom Auto Brightness which allows backlight values of down to 0, you can avoid this problem.
The register hook needs to be enabled to be able to use this function.
Increased the maximum brightness by 50 candela: the manual controls were limited to 250cd as maximum as opposed to 300cd which was only usable during auto-brightness, and unusable for any third-party apps.
Unaligned memory access throughout the kernel when applicable.
Switched over to GCC 4.7.3 Linaro toolchain for compiling.
Perseus alpha35 (06/04):
Further rewrote the in-kernel audio controls:
Threw out the old detection methods for something more robust.
This particularly enables non-cellular applications such as Skype, Viber, and so on to be detected correctly. A "calling" state now includes any and all use-cases where the audio is outputted via the phone's earpiece. This fixes microphone levels for such apps to correctly use the calling sensitivity value.
Added microphone level for camera use, this state is enabled whenever a camera stream is active. It should give more options into adjusting things to your likings.
By now the sound engine has only little similarities to Boeffla, any bugs and feedback now go directly to me.
Developers only: MHS: Added a new small tool for tracking media use and reporting it to other in-kernel drivers. Capable of detecting video recording, decoding and camera streams for now. See commit for more info.
mDNIe control changes:
Removed several controls in STweaks simply because people misunderstood them or misused them, or they simply had no rational use.
Video detection, now with the help of MHS, is no longer limited to the stock video player. Any video players using hardware decoding will now be able to make use of edge enhancement, HDR and DNR, this includes any web-based players and the YouTube app.
Custom LED controls implemented; Exposed most variable controls for the notification LED via sysfs and STweaks (LED tab). :
Control LED brightness. Currently the OS dictates, depending on brightness detected by the light-sensor, wether to run the LED in a low-power mode or in a high-power mode, you can now set brightness for both.
Blinking control, this is basically the shape of the wave-pattern that the LED blinks in, you have several controls, best described the data-sheet description:
The fade-in time period is TT1 in the graph, while the fade-out period is TT2.
Slope (1/2/3/4) detention time represents DT1,2,3,4 in the graph, it controls how "steep" the four different curves are.
The LED fading checkbox simply switches between having the detention times controlled by the sliders to having them to 0 (Stock blinking behaviour).
Increased default zRAM size to 400mB. This won't override your STweaks setting, so only new users will see the new value. Others should please adjust the value manually to your liking.
Sources:
https://github.com/AndreiLux/Perseus-S3
Credit and thanks:
gokhanmoral, netarchy, and anybody credited in the commits.
TL;DR: before flashing aside from known issues in the second post.
This isn't an AOSP kernel. I won't work with CM and AOSP derivatives.
DOESN'T WORK ON SAMSUNG JELLYBEAN 4.2.1 ROMS.
Known issues [Updated 02/12]
None
Older changelogs
Perseus alpha34 (22/03):
Updated sound engine. Based on Boeffla (Andip71)sound but custom fork with rewritten system interface and some other code re-factorings.
Should fix all FM Radio issues.
Brings us saturation prevention for the equalizer.
Privacy mode.
Microphone level control
You now have control over the speaker equalizer via sysfs, please visit /sys/class/misc/wolfson-control/ the controls are self-explanatory.
I removed the equalizer pre-sets from STweaks, if you want, set them manually:
Bass-extreme: 12 8 3 -1 1
Bass and Treble: 10 7 0 2 5
Treble: -5 1 0 4 3
Classic: 0 0 0 -3 -5
Pleasant for ears: 4 3 2 3 1
Eargasm: 12 8 4 2 3
I recommend HeadphoneAmpControl (thread - Play Store) for controlling the volume directly on a hardware level; it will overwrite the digital volume of the OS and use the hardware amplifiers only.
Enabled ZRam by default with disk size of 200mB and swappiness of 90%.
The ZRam control is found in the I/O Tab in STweaks. Set it to 0 to turn it off completely, any other value to turn swap on. Changing value takes about ~10-20 seconds depending how loaded the disk is with swap pages so don't piss your pants if it doesn't react immediately.
Applied a requested patch which allows PCs to be booted off from the phone storage.
Perseus alpha33.2 (27/02):
Master profile is correctly calibrated.
Detailed calibration report: Download
Advanced colour management report: Download
All thanks goes to Slimer777 for his excellent work.
Perseus alpha33 (26/02):
Revamped and hopefully final version of mDNIe controls:
The controls work now on two levels: First we have a master sequence that overrides any and all of Samsung's settings; currently this version is released without calibration, however in the next minor version it will be updated with proper professional screen calibration. See the Note 2 thread to see what to expect here too. The master sequence is calibrated to sRGB norms on a precision level equalling and even surpassing the iPad3/4.
The master sequence works as as the calibrated base; for people not wanting to bother further with any more controls, you simply enable this and you're done.
Second part is the register hook, it catches effect values and modifies them by applying delta values available as controls in STweaks and in /sys/class/misc/mdnie/hook_control/.
Leaving both these options will give you Samsung's default values, plus the black crush fix.
The register hook, while used on Samsung's profiles, is not capable to alter effects which are not integrated in that screen profile's value sequence, the "Movie" profile for example lacks some effects present in the "Dynamic" profile. The same is valid when having different scenarios, the "Camera" scenario will use different effects in its base than the "UI" scenario. To fully explore all possible effects, use the Master profile as it integrates all effect values known.
Each control has a master kill-switch which enables or disables the effect. This varies by profile and scenario, so you have control to only "toggle" the switch, whatever its state may be in.
Digital noise reduction - Reduces and flattens out grain. Advanced controls are found in the hook_control folder with the dnr_ prefix.
High dynamic range - A HDR effect which brings out details in dark and extremely bright scenes.
Digital edge enhancement - An edge enhancement effect. What we previously called "sharpening". Divided in controls for radius, amount and threshold. Read the Wikipedia page for more information. More advanced controls found in the sysfs under the de_ prefix.
For the above three effects, scenario consideration is taken into account. You can enable/disable them depending when you want it to be applied. Please be aware only the stock applications trigger the scenarios. I will try to enable at least the video scenario depending on when the hardware decoder is active in the future so that they are enabled also in third-party video players.
Chroma saturation control - Same as in previous version but with fixed labels.
Colour temperature control - By default this is disabled on all profiles, however, if your screen has a tint to it, this is the first control you should try to fix as it alters temperature on all channels.
The SCR controls are colour channel filters working on the Red, Green, Blue, Yellow, Cyan, Magenta, White, and Black channels.
Imagine the controls as manipulating the corners of the RGB cube:
(Credit to Wikipedia for the graphic)
By controlling the RGB coordinates of each corner/channel we can mould the cube into a different shape. At the same time the cube is projected onto a hexagon; the perimeter of the hexagon represents the colour hue, the radius of the hexagon from the middle represents chroma. We can use the chroma saturation controls to "push in" each corner of the cube, while moulding the corner's directions with the RGB controls. The RGB coordinates can be transformed into the HSL space space if needed, however I didn't include this function yet as I don't feel the need for it.
STweaks has controls for the RGBYCMW channels, the K (Black) channel I left out because it makes no sense in altering it, but can be found in the sysfs folder.
Several controls have a "factory setting" switch, this are the burned in-hardware values for some controls, they overwrite the controls themselves.
Additionally to the controls exposed to STweaks, there are several other effects and modifiers exposed in the sysfs interfaces. This also includes the gamma curve controls for levels 0-255 in steps of 16.
There are also some additional unidentified configurables which I wasn't able to properly give a name to or had no effects: Dithering, ABC (Seems to give a gamma brightness boost), SCC, UC, and MCM (Colour temperature) configurables whose exact effect isn't documented.
Perseus alpha32 (29/01):
Charging control implemented. This is my own version.
Charging currents:
Charging currents are dictated by input and charging current limits. The input current is the current flowing into the device through the USB port at 5V. The charging current is the current delivered to the battery at usually 4.35V. The device can have a higher charging current than input current because of the voltage differential, usually a 15% discrepancy. You can also have much higher input currents than charging currents, this can be useful when you are using the device in situations like gaming and charging your battery at the same time, provided your charger actually can provide the power.
There are 3 USB charger type categories: DCP / Dedicated Charging Ports which also includes AC chargers, but also special USB plugs; SDP / Standard Downstream Ports which usually includes almost all data enabled USB ports, and CDP / Charging Downstream Ports which includes also data enabled USB ports but which are designed to provide more power, usually on newer laptops where the USB port has a lightning logo next to it. More info here. - Technical explanation here.
Charging logic:
Stable margin removal option. The charger chip is capable of detecting unstable charging sources; it dynamically reduces the input current in 100mA steps until it detects a stable voltage input [We don't have the charger chip datasheet, so the technical explanation is a bit blurry here on how it decides that it's unstable]. It further reduces it by 100mA as a safety margin, you can disable this now.
Complete disabling of unstable power detection. This simply ignores unstable power sources and leaves the input current limit at its set up value. This will fix charging problems people have been reporting. However, please use it at your own risk, the S3 chargers which have had these symptoms clearly have some issue in their hardware so you might actually kill them with this option enabled as there is no protection from the phone's side anymore.
The actual input current limit can be read out in /sys/devices/platform/samsung-battery/power_supply/battery/current_max, so you can see the real limit there, it's the closest thing we have to the actual charging current on stock values since there is no hardware to read out the live currents.
Voltage control:
Hard voltage control: 4.20, 4.35V, and 4.40V charging voltages are available. This is included for anybody running on third-party batteries, whom most of them have a 3.7V battery chemistry as opposed to the 3.8V on the stock battery. These batteries should be charged at 4.2V instead of 4.35V.
Soft voltage control: As opposed to the hard voltage control which is the voltage which the charger chip provides to the battery while charging, the soft-voltage is the battery voltage itself. 3.7V batteries have a top-off voltage of 4.2V and 3.8V again 4.35V. The default limit on the stock battery is 4.30V before the charger logic stops and considers the battery as full. This is also merely provided for 3rd party batteries which should be charged at lower voltages. If you overcharge your battery beyond these what are safe considered voltages, such as raising the default 4.30 top-off voltage to the design 4.35V or even higher, you are running into the risk of damaging the battery or even causing it to melt-down. Use at your own discretion.
mDNIe sharpness and RGB/YCM chroma saturation control in STweaks:
I started implementing sharpness control in STweaks and went a bit over-board instead of a simple checkbox; You now have controls over the mDNIe registers as a delta offset value compared to the stock register values. I'm applying the offset to all mDNIe profiles and scenarios which have the specific post-processing effect active in that specific scenario. Meaning, that you start with the default profile; Dynamic / Standard / Natural / Movie and have the delta offset applied on top of that.
Sharpness delta. This is what brought most of the quality difference in hardcore's original tweaks. You can now fine-tune it to your own taste, and also take into regard that it produces a different effect for each screen profile while having the same delta - the base values between the profiles are different.
DE control - I don't know what this actually does and I couldn't discern much difference between the values, but it used to be disabled in hardcore's tweaks.
Chroma saturation control: This is composed of 2 values for each RGB/YCM channel. See the Munsell color system for a visual representation of the values controlled here. The chroma curve control describes the curve weight based on chroma intensity, the chroma gain is the chromatic gain that is being applied on the respective channel. Chromatic saturation weight is again another multiplier for all channels combined. I have not managed to properly identify the chroma grey threshold and its effects.
Basically this is like an RGB control on steroids, and enables you to tune your screen to your own liking and calibrate it as you wish. Please note that not all scenarios in the profiles have chroma saturation effects, the Movie profile for example has no effect applied to the UI so chromatic control has no effect on it.
I also want to state that the above are my deductions and theories on the descriptions of these controls, I'm not familiar enough on colour theory to be able to confidently say that these descriptions are correct, and the controls are a work-in-progress for now. Experts are welcome to contribute here.
Front buffer early suspend delay option for those who have issues with the CRT animation.
Did some refactoring on the Mali drivers and fixed a bug which may have caused less capable undervolting than the stock implementation.
Perseus alpha31 (09/01):
Removed my own security fixes and replaced them with the official Samsung one. I guess it can now be disclosed: exynos-mem was only one of multiple entry-points for the memory exploit. We discovered the s5p-smem exploit ourselves back in December but kept it quiet, I fixed that one back in version 29.2 without mentioning. Nobody was secure from a smart exploiter up until then, SuperCurios or Chainfire's software fixes are also just patching a single hole in what is a Swiss cheese. Kernels >v31 and beyond stock LLA are now the only truly protected ones.
Samsung's fix for the sudden death syndrome (SDS) included. It is caused by eMMC failure on phones with VTU00M internal memory chips with revision 0xF1. You can check your phone with the "eMMC Brickbug Check" in the Play Store (Ignore the message if it says you're not affected, the type and revision is what matters). The patch is a firmware soft-patch that is applied on every boot and MMC resume, it is not a permanent fix. You will need to stay forever on kernels which include the patch, this also includes updated recoveries and their embedded kernels.
Some other minor MMC changes extracted from Update 7 sources.
Harmonized some mif/int max voltages with the Note 2 limits.
Perseus alpha30 (06/01):
Internal and memory voltage control. This is the first and only working implementation out there. Memory interface voltage is exactly what it the name implies, the voltage on the chip-to-chip interface from the SoC to the memory chip. Internal voltage is the whole SoC voltage excluding CPU, GPU, and the MIF. This includes all auxiliary function blocks such as the ISP/Image signal processor, camera interfaces, I/O interfaces, display controller and the MFC/Multi function codec hardware video de-/en-coder.
Internal voltage respectively memory voltage table is found in /sys/devices/cpu/busfreq/ as int_volt_table or mif_volt_table
The frequencies are defined as OPP's (Operating performance points), internal frequency and memory frequency (And voltages) together as a pair form an OPP. If you want to change the voltages through the sysfs files, keep in mind how you change them. MIF voltages are stored independently with each OPP step. INT voltages are stored in respect of their frequency key.
Default OPP steps are: 400200, 267200, 267160, 160160, 133133, 100100. The first three numbers represent the memory frequency, the other three the internal base frequency. For example 267200 means the memory interface is at 267MHz (533MHz DDR) and the internal frequency is 200MHz.
The voltages in STweaks are sorted out through some magic and are frequency unique, I recommend using that for controlling them.
Busfreq logic control added into STweaks, this includes all the already available configurables in the stock kernel with added explanations and I supplemented it with a sampling rate parameter.
Some minor source updates from Samsung regarding some new sensor drivers.
Replaced pegasusq's runqueue detection logic with a new more superiror and precise in-scheduler collection logic, I found that the real runqueues are much less than what was previously reported. This should help a lot with hotplugging.
Enabled AFTR by default since we are now running very often in single-core mode. Keep in mind this mode is WFI Idle + LPA + AFTR.
Fixed a kernel bug which was eating up randomness entropy. This is related to that whole seeder business - please don't use any of those fixes. I also disabled virtual addresss randomization and at the same time disabled entropy generation from the block layer, which should avoid I/O overheads.
Perseus alpha29.2 (24/12):
Another minor (major) release due to security. Please update.
I screwed up something touchscreen related in v29 that disabled Flexrate requests, fixed now.
Changed Flexrate requests so that they don't scale down in their sub-samples anymore. This should improve fluidity.
Perseus alpha29 (18/12):
I'm doing a quick release because of the security fix, not very feature rich.
Fixes the exynos-mem security hole. This is my own fix and will not break camera. Read about it here. You don't need to use Chainfire's or Supercurio's fixes, in fact, you shouldn't use them because of the camera.
Updated Wifi drivers.
Added GPU utilization control to sysfs and STweaks.
Changed default GPU thresholds to more relaxed values (75/17)
Added block device read-ahead control to STweaks. Additionally set the default read-ahead for internal memory to 256kB and 1mB for SD cards.
29.1: - Reverted the Wifi drivers back and did some CMA adjustments to see if that fixes some random reboots of people.
Perseus alpha28 (13/12):
28.1: I reverted the striked out changes due to exFat. I changed my mind due to demand. I apologize for the chaos.
On your SD card showing up as damaged: it is not.
I made a decision in terms of exFat compatibility; either I advance the kernel with newer upstream Linux versions or stay back and keep compatibility with the exFat modules. While I have nothing against proprietary modules or such, not being able to adapt them to the kernel is not optimal. You can format your cards to FAT32 or ext4 without much issue. Please back up your data and format your card accordingly before flashing v28.
[*]Updated the block system to Linux kernel 3.3.
Introduced FIOPSv2, ROWv4, ZEN, BFQv5 as new I/O schedulers;
FIOPS is the new default scheduler, it's a CFQ like fairness scheduler optimized for solid state storage. ROW should be the actual better performer here as it has superior logic, but I didn't set it as default because of some lags when installing applications. ZEN is just a mix of SIO and Deadline and nothing special. BFQ seems to underperform. I recommend the first two over everything else, and added the latter two just for comparison's sake.
Added dynamic Fsync control (Faux123). It disables Fsync only when the screen is on. Enabled by default (Fsync off).
Changed some logic on when the adaptive scaling voltages are applied in the kernel init sequence. This fixes GPU voltages not being applied at boot and also fixes the wrong default voltages being displayed in STweaks.
STweaks tab for I/O with scheduler selection for each device block and also dynamic Fsync.
New script side feature in the uci.sh framework: When inserting an override.profile file into the profile folder (/data/.perseus), the entries in the override profile will supersede the ones in your default profile. You can use to make CWM zips to turn off set at boot flags or to share targeted settings with others. The override is applied once at boot after which the profile deletes itself.
Perseus alpha27 (02/12):
Sources updated with various updates from N8000u1 base. Included are following important changes;
CMA memory allocation has been altered and page handling in the kernel in regard to CMA affected pages has been dramatically improved, this should fix the high load of the "migration" process users have had since initial Jellybean kernels.
Updated wireless drivers.
Adds a delay to SD Card host controller power-down, which I assume is to prevent some corruption. There is a specific change to Toshiba 19nm manufactured SD Cards, these are mostly the latest SanDisk 64GB cards. Together this may fix issues users have had.
Updates the camera interface, Video4Linux and Jpeg2x drivers and this fixes compatibility with 4.1.2 ROMs. Backwards compatibility is retained.
Other updates which are more transparent to the end-user.
New PegasusQ logic:
- We now have additional conditionals on the hotplug logic which checks the total load across all cores and is able to bias towards a specified core count if the load is low. This is useful because previously we could have had frequency spikes and lots of low-load threads triggering a hotplug-up while in reality it wasn't needed. The core count is more biased on keeping 2 cores online in most cases now unless really needed.
- The way freq_step is handled has changed. We now take the remainder of load space above the up threshold and dissect it into three slices each having different frequency increase step sizes. The first two slices are each of up threshold differential size, lop-sided towards the lower end of the load scale. We specify the slice size and freq_step delta in regard to the original freq_step.
- A new fast-down scaling logic; if frequency is beyond a certain threshold, we take a heightened up_threshold value solely on the down scaling logic to scale down more aggressively from the higher frequencies.
STweaks. This is my custom implementation of the kernel side, based on Gokhan Moral's initial implementation.
- CPU overclocking and voltages interface.
- Configurables for all CPU governor settings.
- GPU overclocking and voltage interface.
- Interface for audio enhancements.
Perseus alpha26 (14/11):
Updated MTP drivers back to the newest version. Fixes some inconsistencies which some people had.
Further increased MMC command timeout from Linux default 300ms to 3s in trying to finally squash errors and "unexpectedly removed SD card" after resume.
Ported Gokhan Moral's mDNIe interface and also added colour tone modes on top of the scenarios. System interfaces are found in /sys/class/misc/mdnie . Input syntax is the same as the output syntax, or, single register-value pairs as a single line in the output format, except 0xFF which is a terminator value.
Increased default sampling rate down to 30ms from 50ms for a bit more fluidity.
LTE devices only: Updated some power management functions on the MDM modem from latest sources; this will drastically decrease the amount of wakelocks on mobile data and improve battery life.
26.1
Disabled net_os_rxfilter_add_remove userspace/ROM filter management in the Wifi driver to prevent the operating system of enabling unwanted pass-through multicast and broadcast filters while in standby.
Perseus alpha25 (23/10):
Raised and fixed USB, MISC charging rate to 900mA.
Enabled OTG car dock, smart dock and music dock charging. Alternatively this can be triggered if you short pins 4 and 5 of the USB connector with a 40.2kΩ, 64.9kΩ or 619kΩ resistor.
MTP fixed on OSX devices.
Fixed ROM power savings feature, this was originally broken because of the addition of overclocking, and the same interface that Samsung uses for limiting CPU speed in power savings mode also limits the max frequency to factory defaults. This is now fixed and powersavings mode will throttle to 1000MHz.
Fixed mis-configuration of the default audio settings to improve sound quality, sorry about that.
Ripped out the old GPU scaling mechanisms and scaling logic and replaced it by something new.
The old mechanism was getting overly complicated and was a remnant of the Galaxy S2 where we merely had 2 frequency steps originally; this was fine then, but isn't anymore today. The threshold fuçkery was confusing to a lot of people and people generally misconfigured their settings with inane values.
The new scaling logic follows a more CPU governor-like approach: Scaling up logic is basically the same as before: the GPU will scale up to the next frequency step when the load reaches a certain threshold. Up-scaling takes place step by step. The up-scaling threshold is now global and a single value applies for all frequency steps.
Scaling down in the new logic resembles more like the ondemand method; The scaling down takes place when the load goes under a certain threshold. This threshold is dictated by the up-threshold minus a down-differential. By default they are 90 and 10. Triggering this condition we scale down into a dynamic frequency target capable of accommodating and dictated by the load level. In plain words, we can scale from max frequency immediately down to the lowest one. This will improve power consumption.
Ripped out the old GPU control interfaces and rewrote it with something new to accommodate the new logic. Your old scripts won't work anymore.
We now have 10 frequency steps to the user's disposition; defaults are: 54 108 160 266 350 440 533 640 733 800.
The new system interface targets can be found in /sys/devices/system/gpu/ .
- freq_table outputs a list of the current frequency table. You can use this interface for configuring the frequencies themselves in two ways:
Pair-wise target setting: echo 533 500 > /sys/devices/system/gpu/freq_table will change the 533 step frequency to 500.
Whole-table echo: echo 54 108 160 266 350 440 500 640 733 800 > /sys/devices/system/gpu/freq_table
In the above example you end up with the same end-result over the stock settings.
Valid clock frequencies are as follows: 54, 108, 160, 200, 266, 275, 300, 350, 400, 440, 500, 533, 600, 640, 666, 700, 733, 750, 800.
- volt_table outputs the voltages to the corresponding frequencies.
Pair-wise target setting: echo 533 1025 > /sys/devices/system/gpu/volt_table will change's 533MHz's voltage to 1025mV.
Whole-table echo in the same format as freq_table. Valid voltages are 600mV => x <= 1200mV.
- thresholds sets the two global threshold settings. echo 90 10 > /sys/devices/system/gpu/thresholds . Remember that the first is the up-threshold and the second is the down-differential. The down differential may not be higher than (99 - up value).
- min_freq and max_freq set the limits of the current DVFS policy. By default we're scaling from 160MHz to 440MHz (Same as stock).
echo 533 > /sys/devices/system/gpu/max_freq will enable the top limit to 533MHz and basically overclock the device.
echo 108 > /sys/devices/system/gpu/min_freq in the same way sets the lower limit.
25.3:
- current_freq shows the current frequency. This is if somebody likes to make a monitoring app or something.
- time_in_state shows the time spent in µS on each frequency step. Echo 0 to it (by default disabled) to disable it, 1 to enable monitoring, and any other numerical value to reset the timekeeping back to 0.
Perseus alpha24 (09/10):
Galaxy Note 2 source and kernel merge. Various platform fixes included from patching up from update5.
Fixed Mali GPU interface bugs relating to staycount, and lowered undervolt-soft limit down to 600mV.
5 step GPU scaling, for now. Change your scripts.
Fixed black crush on the display. Vastly better black levels are now of order.
Perseus alpha23 (27/09):
Changed some auxiliary CPU clock dividers for frequencies 1600,1704,1800 MHz. These frequencies should use less power now and also should be more easily reached with more stability or lower voltage depending on your device.
Fixed CPUPower driver (Back from alpha20); this will now skew the reported processing capacity of CPU0 in the lower frequencies up until 500MHz to be 8 times greater than CPU1-3, what it does now is that the scheduler will even more migrate tasks onto CPU0 to avoid idle wakeups on the remaining CPUs, resulting in increased power efficiency. For high load > 500MHz, the driver reverts back to the default power configuraitons.
Reset the regulator configurations to their physical minima; you can now undervolt to 600mV on the GPU. Sorry I missed this before.
New feature: Dynamic Screen Frequency Scaling.
This decreases the display controller frequency in tandem with the CPU speed. Usually when you have low activity on the screen; i.e. low re-draw rates, then you mostly also have logically low CPU load. I wrote a scaling mechanic to switch between high display frequency (60Hz), and low display frequency (40Hz) in accordance to CPU scaling. This is tied in in the CPUFreq governor, in this case PegasusQ. We have three new governor configurables found in /sys/devices/system/cpu/cpufreq/pegasusq/ (Or alternatively just use SetCPU):
lcdfreq_enable: Enables or disables the mechanic, disabled by default.
lcdfreq_kick_in_down_delay: The amount of samples to wait on below the threshold frequency before entering low display frequency mode. Default value is 5 for now, a.k.a. in most cases 250ms unless accelerated flexrate is active on low load (fingers touching the screen), then depending on situation it might get as low as 62.5ms.
lcdfreq_kick_in_freq: The frequency threshold below which the low display frequency kick-in will be active. Default is 500MHz, and should probably stay as such, setting it higher will cause lags as we'd be using 40Hz in an interactive situation.
For the curious: I made a rudimentary time_in_state state accounting sysfs in /sys/devices/platform/samsung-pd.2/s3cfb.0/graphics/fb0/lcdfreq/time_in_state for testing purposes. Currently it shows wrong time values for 60Hz as the driver gets initialized before the high resolution timer, and I'll fix that later, but the 40Hz time statistics are correct.
Notice: There will be now conflicts between this and user-space controlled TwDVFS service/app. The service would limit screen frequency to 40Hz while using the camera app, this will be now overridden. I also thought the service would do more but I could not find it scaling for anything else than the camera, so it's pretty much useless in my mind, and you could theoretically remove it.
Feedback 23.3: This feature causes flickering on bright colours and low brightness. Enable it at your own will.
Changed the functionality to boost to 60Hz on any touch interaction, regardless of CPU speed.
Please provide feedback on fluidity and battery life.
Perseus alpha22 (22/09):
Update to update5 source code. Only compatible with Samsung Jellybean ROMs.
Stacks with my previous memory changes: total memory: 857mB for now.
Implemented timer slack controller.
Backported the scheduler NoHz load computation fixes, this should dramatically improve PegasusQ's hot-plugging decision making.
Further reduced Mali sampling rate down to 50ms and changes the default thresholds to more aggressive power savings and clear-cut scaling. Removed 10ms regulator switching latency. I measured a 10% battery improvement in GLBenchmark 2.1 Egypt Battery - 50% Brightness 60 FPS.
config.gz support.
Alpha21 is the same as above but without update5 and for ICS. This is the last kernel for ICS, I'll not longer support it.
Perseus alpha20 (9/09):
Gökhan Moral's port of Voodoo Sound implemented. Currently no configuration interface is available, so if you wish to play with the settings, refer to the sysfs interfaces in /sys/class/misc/scoobydoo_sound/ . If you wish to change the device name, you must do echo 0 > /sys/class/misc/scoobydoo_sound_control/enable , followed by an echo output to the same file with the target device driver name. You can use this to change the device path to /sys/class/misc/voodoo_sound/ and sub-sequentially make a certain configuration application work. Please do not ask me for support on the latter. You can disable the sound modifications completely by the same method, by of course not re-enabling it afterwards.
Changed the Wifi packet filter to block out all but mDNS multi-cast packets.
Increased mmc timeout for bad quality SD cards.
Perseus alpha19 (1/09):
Updated Samsung source base up to update4, includes changes to the Wifi driver and various other small fixes
Added ARM topology support for the scheduler to be able to use sched_mc levels. This should increase cpu idle power consumption by decreasing idle wake-ups. For the moment disabled by default, and cpu_power doesn't seem to correctly work.
Swap support.
mDNIe sharpening improvement, courtesy of hardcore.
Decreased Mali utilization timeout to 100ms down from 1s which improves reaction time on instant GPU loads (Lock screen is best example).
New valid GPU frequencies : 54, 108, 160, 200, 266, 275, 300, 333, 350, 400, 440, 500, 533, 600, 640, 666, 700 Mhz
Increased user-space memory by 48mB to have a total of 825mB useable RAM; this comes from reduced DMA memory spaces on the part of:
- The Mulfi Function Codec a.k.a. the hardware decoding and encoding unit memory space from 50176kB to 28672kB
- The camera interface imaging subsystem from 12080kB to 10240kB
- The front-camera firmware block-space from 15360kB to 14336kB
- The ION heap size for the Video4Linux driver from 71680kB to 48128kB
In the case of the ION/V4L and MFC heap sizes I determined it by setting a benchmark for all the HD sample videos listed here to not have any detrimental effect before and after the changes. Below 41mB is the size for which the Planet Earth birds scene at 1080p high profile 4.1 40mbps video starts to lag. Keep in mind that there is no way this would be considered normal quality as this is basically un-recoded Blu-Ray quality and most videos are vastly under this bit-rate.
I note that I also haven't found any detriment in use of the cameras including the modded 30mbps camera quality.
Disabled the Kies daemon, I see no point in it and it uses up memory uselessly. Obviously Kies won't work any-more, if you want you can start the service yourselves manually.
Perseus alpha18 (11/07):
Updated Samsung source base up to update3, includes various fixes to fuelgauge battery reporting on full charge, MHL code, video media drivers, Wifi driver updates, gyroscope, MAX77686 battery charger changes, increased max display brightness, a buttload of LCD panel changes, and changes to the pixel refresh rate driver (This thing is controlled by the TwDVFSapp by the way and decreases screen power consumption at runtime).
ro.secure=1 again now but with an insecure adbd as root included.
LFB ramdisk.
Compiled with Linaro 4.6.2 and some higher level optimizations.
Keep in mind that running the new kernel on older ROMs can cause some funny behaviour, so update your ROM if so.
Perseus alpha17 (9/07):
Rewrote flexrate request code for pegasusq: I apologize for releasing the previous version in the state that it was, shame on me.
Now upon receiving a flexrate request and active ones, the governor delays hot-plugging sampling logic so that accelerated sampling is being taken into account and hot-plug sampling is normalized for the standard sampling rate. All sub-samples are being averaged into a normal sized sample at the end of the normalized period. This no longer interferes with the runqueue read-outs as they were being reset too fast and generally accelerated hot-plugging in a bad manner.
Changed touchscreen flexrate requests to 12500µS sampling rates over 4 periods to synchronize with the default pegasusq sampling rate.
I consider this chapter to be done and a success as far implementing flexrates as a viable and working alternative to touch-boost to increase responsiveness without having the bad battery-life side-effects of the touch booster.
Performance governor is now core-aware, previously as no other hot-plugging logic was available, the governor would start with whatever number of online cores were available at that time and stay like that. This made Performance useless for it's designed purpose, that being bringing maximum performance. It now brings up all available cores online upon start and turns all additional cores back offline on governor stop. It is now by far the best and consistent governor for benchmarking.
Removed unused cpu_freq_up, cpu_freq_down, and several other flexrate related governor parameters in Pegasusq as they were either not used, or senseless.
Default Pegasusq parameters changed:
- Sampling-down factor reduced to 1 from 2, this caused reduced sampling speed upon reaching maximum frequency. It now scales (possibly down) faster.
- Frequency steps reduced from 40% to 21% of maximum frequency, this causes it to scale in 300MHz steps for the default maximum policy of 1400MHz. As we now have flexrates to scale faster I did not notice any negative effects on performance and this should help battery-wise on load-"spiky" applications, and in general.
- Increased runqueue-length thresholds for the hot-plugging logic by a flat 75 for all conditions. In my opinion and experience they were too low and caused to keep the cores needlessly online. This now reduces for "average low" use the online-time of the third core considerably.
- Increased the hot-plug frequency conditions for the 4th core.
Updated the kernel from upstream to 3.0.36.
Memcopy and string function improvements, won't bring any noticeable differences.
Compilier optimizations (Roughly the same as Ninphetamine's) are now in. VFP uses the NEON libraries now. I couldn't measure any increase in any synthetic benchmarks with this though.
LFB exFat modules.
Perseus alpha16 (3/07):
Disabled touchscreen touch booster; this previously locked the CPU frequency at 800MHz, memory interface to 400MHz and bus frequency to 200MHz at any time the finger touched the screen.
Implemented flexrate capability into pegasusq; additionally added a frequency threshold above which flexrate requests are ignored. Currently this is set at 800MHz but is configurable in the governor tunables.
Enabled quality of service requests in the touchscreen driver, this currently triggers a flexrate request at a sampling period of 15ms over the governor default of 50ms, and over 5 periods, giving 75ms of heightened reactivity. It also sends a direct memory access throughput quality of service request to the the linux power management quality of service interface to guarantee a 266MHz bus frequency for 142ms. Still need to check if that the last part works correctly.
Perseus alpha14 (21/06):
Only Mali platform changes.
Remove Samsung integrated checks on in the Pegasus platform that prevented the GPU control interfaces to work. Overclocking, undervolting, and the rest now properly work.
Removal of the CPU frequency lock to 1200MHz if the GPU is at 440MHz, this is excessive as 3D load heavy applications usually do not tax the CPU that far, and is an unnecessary power consumption burden.
The thermal control unit temperature throttling causes to fix the voltage to a fixed value when throttling is in place; this is useless considering frequency is not limited, making the whole thing senseless. Thus removed.
Perseus alpha13 (20/06):
Rebased sources on a Linux branch for commit completedness. All commits reapplied and cleaned. New repo.
CIFS included as module
Busybox removed. This should be part of the ROM.
Perseus alpha12 (14/06):
Added enhanced init.d support as per dk_zero-cool's implementation.
SHA-1 improvements
Added exception to the module loading logic for the exFat driver module thus making it work. (Credit to gokhanmoral)
Perseus alpha11 (10/06):
ro.secure=0
Recovery renamed as busybox in /sbin. I'll compile a proper busybox later on, or remove it alltogether when a recovery with autoinstall is released by CF or somebody else.
Perseus alpha10 (8/06):
Overclocking up to 1800MHz. Voltages in ASV table are somewhat scaled up until 1600MHz, after that you're on your own and have to optimize yourself.
Intel claims maximum sustainable safe voltage for 32nm HKMG to be 1.4V, above that may cause electron migration to the silicon and permanently deteriorate your chip. 1700 and above only for avid overclockers and benchmark freaks. Credit to tvanhak for playing lab rat with his phone.
Samsung frequency limitation removed to scale above 1400MHz, full credit goes to Gokhanmoral for finding this hack in the kernel as it is in a very sneaky location.
Perseus alpha7 (5/06):
Reduced regulator voltage initialization minimum to 600mV, you can now undervolt that far. Be aware of crashes.
Added SIO scheduler
Some network and CRC related patches
Perseus alpha6 (4/06):
UV_mV_table support, apps like SetCPU work now.
If you have a voltage set at for example 1187500µV the output will be rounded up to be displayed at 1188mV. If you set a voltage non multiple of 12.5mV then for example, 1190mV, it will round it to the nearest valid step, being 1187.5mV. UV_uV_table is there for finer grained control but no app suports that yet.
Perseus alpha3 (4/06):
Mali: disable state tracking
Mali: GPU frequency, scaling and voltage control
Governor pegasusq: make up_threshold_at_min_freq and freq_for_responsiveness configurable values. This is the reason the Galaxy S3 is so smooth, it has super aggressive scaling values for the governor until default 500MHz.
Enabled 1500MHz per defconfig and added voltage values to ASV table for it
Added UV_uV_table for voltage control on the CPU; this is not compatible for any programm which supports undervolting right now, we need UV_mV_table for that and since we have 12.5mV steps being fed to Vdd it's not compatible for now.
Boot partitions are made visible.
Knowledge base
I'm going over time to update this post with some informations. It may be unsorted, unfinished or un-editorialized for the time being.
2) Hardware
The Galaxy Note 2 will be coming out with a new 4412 versioned Rev 2.0, where as the one currently in the S3 is versioned Rev 1.1. The new chip will be launched at 1.6GHz default clock. What is interesting is that they have increased the base clock from 800MHz to 880MHz, most of the SoC internals feed off this clock, meaning that we're going to have 10% clock boost in the internal bus and memory speeds.
Now as a side note: One thing that I haven't understood from the press releases back in May, is that there were this "internal 128bit bus" mentioned, with some idiotic websites taking that tidbit and claiming the chip was a 128bit architecture. Whatever. Anyway, the reason for this is that the way the Samsung SoCs internally function: they are separated in a "left bus" and a "right bus". The left bus is connected to the memory controllers and is also just called the MIF/Memory Interface. The right bus is called the "internal bus" and is connected to the ARM cores and everything else. The biggest difference here between the 4412 and the previous Samsung iterations was that both these were running at the same clock. In the 4412 the internal bus is running at half the memory interface bus, this corresponds to the increase to 128bit in the internal bus.
Now I got curious due to all this talk about the A6 and this tidbit:
"K3PE7E700F-XGC2" the last two characters refer to the clock speed. The iPhone 4S was [under]clocked at 800 Mhz. "K3PE4E400B-XGC1" was the A5's part number. E4 refers to 2 Gb LPDDR2 die and because A5 features a dual-channel LPDDR2 memory with two 32-bit die. 2 GB x 2 = 512 mb of RAM. C1 was the clock speed which was 2.5ns which indicates a 400MHz clock frequency. Two channels result in the A5 clock speed of 800MHz. So the A6 has C2 which is 1.9ns which indicates a 533 MHz clock frequency. 533 x 2 is ~1066 GHz.
Click to expand...
Click to collapse
Both the A6 and 4412 use the same memory, only difference being what seems to be a revision serial character. I was talking a few months ago how the 4412 showed a good 30% bandwidth improvement over the 4210, and credited this to it running 1066mbps memory instead of 800mbps; but in reality that is not the case.
I went over the source code of the busfrequency driver in the S3, and found that actually there is an entry for the internal frequency to run at 266MHz (128bit), but that entry is disabled in the driver; because the memory interfaces don't exceed 400MHz. The bus speed is defined in (MIF/INT) pairs and top speed available is 400200 (400MHz memory, 200 internal). Well this is interesting we can overclock our device's memory then if there's headroom! Well that idea quickly faded as I found that the C2C (Chip-to-chip) interface to the memory isn't capable of being clocked to 533MHz because simply the C2C clock divider register simply doesn't allow a divider value needed for that frequency, only being able to run 400MHz(and lower) and 800MHz. Basically we can't use the fast memory because it seems the clock dividers don't allow it. Anyway, coincidentally the i9305 sources were released two days ago and it included all the Note 2 sources and so on, so what Samsung did was simply increase the MPLL base clock from 800 to 880MHz, actually increasing the frequency of a load of things like the camera interface and who knows what at the same time.
What this also means is that Samsung increased effective bandwidth by 30% without increasing the memory speed. This indicates much improved memory controllers, and also why it easily beats the Tegra 3 and others in memory benchmarks.
Another new addition to the REV 2.0 chip is that we'll be running 533MHz for the Mali clock by default. We were already experimenting with this on the S3 and pretty much made the GPU run up to 700MHz, of course, it gets quite warm and battery hungry, but it's neat nonetheless.
3) Reserved memory spaces
There is the current reserved memory space breakdown, with red as Perseus changes over stock:
#Secure spaces on fixed memory addresses
Front-camera firmware & heap: fimc0: fmic1 =
0x65800000 - 0x66700000 => 15360K (0xF00000) => 14336K
Multi function codec B memory space: mfc-normal =
0x64000000 - 0x64400000 => 4096K
ION device memory allocator reserved space: ion =
0x5F200000 - 0x63800000 => 71680K (0x4600000) => 48128K
Multi function codec device reserved space: device_mfc =
0x5C800000 - 0x5CA80000 => 2560K (0x280000)
Multi function codec A memory space (Virtually contiguous to MFC, practically has a physical memory hole): mfc-secure =
0x5C100000 - 0x5C800000 => 7168K (0x700000)
0x5F000000 - 0x5F200000 => 2048K (0x200000)
Bootloader: sectbl =
0x5C000000 - 0x5C100000 => 1024K (0x100000)
# non secure
Camera imaging subsystem: fimc_is => 12080K (0xBCC000) => 10240K
Display interface and frame buffer: fimd => 8192K (0x800000)
Main-camera firmware & heap: fimc0 => 62464K (0x3D00000)
Audio buffer: srp => 1024K (0x100000)
Good start dude, i will release my kernel in 2 days max too, just need to finish a few things and it's done
Sent from my Desire HD using Tapatalk 2
simone201 said:
Good start dude, i will release my kernel in 2 days max too, just need to finish a few things and it's done
Sent from my Desire HD using Tapatalk 2
Click to expand...
Click to collapse
Desire HD? Did you already get rid of your S2? Thanks. Do you have your device or also waiting for the blue one?
AndreiLux said:
Desire HD? Did you already get rid of your S2? Thanks. Do you have your device or also waiting for the blue one?
Click to expand...
Click to collapse
Haha yeah i sold it to buy a GS3, i ordered the white one from amazon.it but it is taking ages -.-"
BTW, look at my repo, i have done some great new mods if someone wants to use other govs than pegasusq (that is way better but you know, it's always good to have a choice)
Sent from my Desire HD using Tapatalk 2
Nice AndreiFlux let's test
Gesendet von meinem GT-I9300
simone201 said:
BTW, look at my repo, i have done some great new mods if someone wants to use other govs than pegasusq (that is way better but you know, it's always good to have a choice)
Click to expand...
Click to collapse
Great work. Personally I'm not going to allow anything other than Pegasusq though, I just don't see the point. The users can use your kernel if they want choice
AndreiLux said:
Great work. Personally I'm not going to allow anything other than Pegasusq though, I just don't see the point. The users can use your kernel if they want choice
Click to expand...
Click to collapse
Yeah you're right, that's why i will stay with pegasusq by default
My mods are good to use the cores as you want, like it was with Tegrak's 2nd Core
Sent from my Desire HD using Tapatalk 2
Hi
is a bootanimation possible with this kernel or is it in a future version planed?
Bootanimations on the S3 are supposedly in a proprietary format now, so we'll have to see about it. As said, for now it's baby steps as long as I'm not able to molest the flash counter on the device myself.
Wifi is not working on this Kernel
Kevinkuensken said:
Wifi is not working on this Kernel
Click to expand...
Click to collapse
Yes, me too...
+1
Same issue with wifi...
Kevinkuensken said:
Wifi is not working on this Kernel
Click to expand...
Click to collapse
I guess it boots well then! Reuploaded a new version for Wifi, please test if you want to.
AndreiLux said:
I guess it boots well then! Reuploaded a new version for Wifi, please test if you want to.
Click to expand...
Click to collapse
Strange, modules not loaded?
For me it worked perfectly from first build, using fully stock ramdisk
Sent from my Desire HD using Tapatalk 2
AndreiLux said:
I guess it boots well then! Reuploaded a new version for Wifi, please test if you want to.
Click to expand...
Click to collapse
Still no wifi with Alpha3.1
Mopral said:
Still no wifi with Alpha3.1
Click to expand...
Click to collapse
Same here
simone201 said:
Strange, modules not loaded?
For me it worked perfectly from first build, using fully stock ramdisk
Sent from my Desire HD using Tapatalk 2
Click to expand...
Click to collapse
Hmmm. I'm reverting to fully untouched ramdisk now, alpha3.2 uploaded.
Hello everyone,
after countless hours of work here it finally is. The first working EAS kernel for our beloved HTC U 11.
Important question: What is EAS?
Energy Aware Scheduling (EAS) is an enhancement to Linux power management, unifying CPU power control under the Linux kernel. EAS extends the Linux kernel scheduler to make it fully aware of the power/performance capabilities of the CPUs in the system, to optimize energy consumption for advanced multi-core SoCs including big.LITTLE. With EAS, the Linux kernel will use the task load and a CPU ‘Energy Model’ to control task placement to select the optimal CPU to run on.
Google thinks, EAS is the way to go for the future. With this kernel you can get pixel (2) experience even before the pixel (2) is released.
Interesting links for further research:
http://www.linaro.org/blog/core-dump/energy-aware-scheduling-eas-progress-update/
https://developer.arm.com/-/media/d...overview_and_integration_guide_r1p3.pdf?la=en
DISCLAIMER:
I had to rewrite and cut out a lot of code to get EAS working. Due to this the prebuilt WLAN and texfat modules are no longer working for this kernel. There are conflicts because I moved to far away from HTC´s codebase.
Because of this I had to compile the WLAN driver from source and integrate it as a module in the kernel zip. To get texfat working I had to built the exfat-nofuse driver from @dorimanx into the kernel.
To allow the kernel to fully operate we need to disable HTC´s PNPMGR.
That means in case you want to go back to a HMP kernel you will have to either backup the wlan module and the pnpmgr files manually or do a nandroid/dirty flash your rom (which is way easier).
This also caused WLAN calling not to work!
Features:
- EAS for 4.4 with patches from 4.9 eas-dev
- Upstreamed to latest 4.4.170
- Rootless interface supported
- Enabled NOOP, DEADLINE, CFQ, MAPLE, TRIPNDROID and BFQ IO scheduler
- Enabled advanced TCP Congestion Control
- Included GPU Boost
- S2S across navbar area
- KCAL color calibration
- Backlight Dimmer
- Button Mapper Support
- Fsync On/Off support
- Green Pulsating Notification LED @tbalden)
- Fingerprint Double Tap to sleep support @tbalden)
- Button Light Notification from @tbalden
- Gradient Charging LED from @tbalden
- Squeeze Control (squeeze to wake/peek/sleep; squeeze to swype) from @tbalden
- Flashlight notification from @tbalden
- Vibrating Notification reminder from @tbalden
- Notification Boost from @tbalden
- Generic wakelock blocker
- Completely rewritten CPU-Boost for EAS (thanks to @RenderBroken) along with Dynamic Stune Boost from @joshuous
- included BFQ IO Scheduler for 4.4 kernels
- USB Fastcharge
- Various CAF improvements
- upstream patches from kernel/common
- Locking Backports from 4.9 Kernel
- OOM_Reaper, OOM_Kill Backport from 4.9 kernel
- Lowmemorykiller Backport from 4.9 Kernel
- RCU backport from 4.9 kernel
Instructions:
1. Please dirty flash your rom to have a clean ramdisk
2. Backup your current setup in twrp
3. flash the zip file/s according to your favorite install method in twrp
4. reboot
5. If you dont want to use @tbalden ´s rootless kernel apps, but traditional root via supersu or magisk delete the uci....cfg file from the root of your sdcard
6. Enjoy your phone
Download:
OREO: https://www.androidfilehost.com/?w=files&flid=251050
Nougat: https://www.androidfilehost.com/?w=files&flid=229307
Changelog:
1.003:
https://forum.xda-developers.com/showpost.php?p=73283377&postcount=174
https://forum.xda-developers.com/showpost.php?p=73283388&postcount=175
ZERO_BETA_2
https://forum.xda-developers.com/showpost.php?p=73500972&postcount=233
ZERO_GAMMA_4
https://forum.xda-developers.com/showpost.php?p=73533313&postcount=296
ZERO_GAMMA_6
2.0
https://forum.xda-developers.com/showpost.php?p=73806358&postcount=386
3.0
https://forum.xda-developers.com/showpost.php?p=73874622&postcount=424
CAF_1.0
https://forum.xda-developers.com/showpost.php?p=73983865&postcount=493
CAF 1.10
https://forum.xda-developers.com/showpost.php?p=74055104&postcount=626
CAF 1.20
https://forum.xda-developers.com/showpost.php?p=74103333&postcount=676
CAF 1.30
https://forum.xda-developers.com/showpost.php?p=74135102&postcount=687
CAF 1.31
https://forum.xda-developers.com/showpost.php?p=74163796&postcount=703
CAF 2.00
https://forum.xda-developers.com/showpost.php?p=74202067&postcount=719
CAF 2.10
https://forum.xda-developers.com/showpost.php?p=74270321&postcount=755
CAF 3.0
https://forum.xda-developers.com/showpost.php?p=74476266&postcount=792
CAF 3.1
https://forum.xda-developers.com/showpost.php?p=74677436&postcount=845
OREO 1.0
https://forum.xda-developers.com/showpost.php?p=75636045&postcount=918
OREO 1.3
https://forum.xda-developers.com/showpost.php?p=75675979&postcount=938
OREO 2.0
https://forum.xda-developers.com/showpost.php?p=75843285&postcount=955
OREO 4.0
https://forum.xda-developers.com/showpost.php?p=76020308&postcount=987
OREO 5.0
https://forum.xda-developers.com/showpost.php?p=76287809&postcount=1029
OREO 7.0
https://forum.xda-developers.com/showpost.php?p=76625681&postcount=1053
OREO 10.0
https://forum.xda-developers.com/showpost.php?p=77187817&postcount=1082
OREO 11.0
https://forum.xda-developers.com/showpost.php?p=77588328&postcount=1107
OREO 12.0
https://forum.xda-developers.com/showpost.php?p=77757572&postcount=1113
OREO 13.1
https://forum.xda-developers.com/showpost.php?p=78144426&postcount=1146
OREO 15.0
https://forum.xda-developers.com/showpost.php?p=78815371&postcount=1170
Credits and Thanks:
I want to say thank you to all those who helped me along my way, who answered all my questions and took their time to support me. Huge thanks to @tbalden @Eliminater74 @Captain_Throwback @RenderBroken
Additionally a huge thanks to @RenderBroken for doing the main work on getting EAS on the android 4.4 kernel. Without him this wouldn´t exist. Drop him a thanks on his threads or show your appreciation with a little donation.
This credit also goes out to @joshuous who works together with @RenderBroken.
Credits:
@flar2 for his complete work
@tbalden for his led tricks, adreno boost etc
@Flinny for helping me with compiling the kernel!
@savoca for Kcal
@Eliminater74 for bringing me into the kernel game
@Sultanxda
@eng.stk
@osmosis
@frap129
@velimirchek for all the testing and support
@tomascus for the nougat base!!
@jsaxon2 for helping me with the OREO magisk module!
and all others that helped me on my way
also for the OREO Kernel Testers!
@zhuchella
@aadeshiscool
@Snah001
@ffh2303
@cjrivera04
@Derepinar
@p50kombi
@CharliesTheMan
@jsaxon2
Donations:
Donations are not mandatory but very welcome..
If you like my work: http://paypal.me/freak07
Source: https://github.com/freak07/OCEAN_OREO_EAS
So this post will be dedicated to information about EAS in general.
Here is a good breakdown on EAS vs traditional HMP (which the other kernels here are using)
Right here we go.
EAS is a completely different breed compared to the conventional HMP system, where it serves an entirely different purpose of achieving the optimal balance between performance and efficiency, with the latter taking the top spot. EAS achieves that via cleverer tasks placement, by which the system determines which is the more efficient cluster for the task to be processed by, as well as categorising the different tasks into cgroups (top-app, foreground and background, in order from highest priority to lowest priority respectively) by which each cgroup receives its sliver of the available firepower (cpuset). EAS also offers the capability of inflating the perceived load, that's determined by the load trackers, of the task in any of the cgroups via its schedtune.boost setting, and whether the task should be processed by all the cpu cores available or only by the cluster the task has been placed on via its schedtune.prefer_idle setting. One of the key features of EAS is lifting almost all the processing from the governor to the CPU scheduler (no it is not the I/O scheduler, something different) and letting it take much much more control, leaving the CPU governor to only do the frequency determination part, which unsurprisingly relies heavily on data supplied by the scheduler. With all that said, it is easily deduced that EAS is not all about governors and governor settings and the like, rather a much cleverer solution that serves the purpose of seeking the best balance between performance and efficiency, and to ensure the CPU is not overdoing a task or the CPU governor is overshooting a simple task, which would attribute to needlessly draining a lot of power as a natural consequence. EAS is about ensuring you get the smoothest UI possible while retaining as much power as possible. However, that does not mean that EAS is lame poor when it comes to performance. Sometimes, if not in most cases, this cleverer tasks placement makes tasks get processed faster, a point that is already proved quite well by the EAS-supporting non-OOS based custom ROMs like VertexOS, ZeNiTy-RR and PAEX. Conserving battery does not necessarily mean crushing performance. This explains that app launches are on-par with HMP if not ahead of it sometimes.
Now on to your question. After going through that brief explanation of EAS, i think your question is actually invalid, since it is not an apple-to-apple comparison anymore. EAS seeks for the optimal balance between performance and efficiency. Should there be a commit to improve performance while not being at the expense of efficiency, EAS should have that stuffed in, whereas HMP is prioritising performance higher than efficiency by design. What Burnout does is taking HMP and making it even more performance oriented, hence it is very unlikely to face micro lags with it. However, HMP still misses the cleverer tasks placement, which can show its canines if you have so much processes going in the background, where in that area EAS takes the lead quite noticeably.
Conclusion: You should try and see what suits you more. But something i can safely say is, EAS is more than satisfactory when it comes to performance from the perspective of a man that always seeks the best performance available, and with the battery gains you yield with EAS, it can go better.
Hope i helped and clear the confusion.
-TDK
A short Explanation on WALT vs PELT. This kernel uses WALT.
RenderBroken said:
An amazing write up by a talented dev @joshuous:
PELT and WALT
Time for me to flex the analogy muscles.
Just to set things straight, PELT and WALT are different load tracking metrics that try to determine the load of the system. The load will eventually be used by the frequency governor to set the frequency. Think of them (the load tracking metrics) as an employee who is dedicated to announcing how quickly customers are coming into your burger restaurant. The frequency governor is the burger chef, who isn't able to see the number of customers entering, so he has to rely on the announcer in order to know the rate at which he is making burgers. The announcer can say that there are "many" customers, and the chef has to decide how fast to make the burgers based on how he interprets "many".
One announcer can say that 10 customers is "many", while another may say that 20 is "many". An announcer may also attempt to predict the number of customers that will enter based on how many he sees at the current point in time. In this way, burger output is more 'bursty'. For example, there are 10 customers ("many"), then no customers ("none"), then 15 customers ("very many"). The chef works hard, then thinks he can take a break for a moment, then suddenly has to work like crazy to dish out burgers for 15 customers. An oversimplified analogy to WALT.
On the other hand, another announcer may observe a trend of customers and apply some prediction to guess how many customers might come through the door. Using the same customer sequence as before, he may instead tell the chef "many", "some", then "many". So the chef may make burgers even when there are no customers, in anticipation of future customers, but he won't be worked so darn hard all of a sudden. This is less bursty and more consistent. An oversimplified analogy to PELT.
In the same way there are different chefs (e.g. Sched and Schedutil). They have different interpretations of what "many" means to them. That's why their burger outputs may be different even when having the same announcer.
So which is better? It all boils down to your workload, and even so it is difficult to make a conclusion. All I can say is that you must test each mechanism for over a week and check your active drain rate (Ex Kernel Manager is good for this). Active drain rate is a much better measure than SOT. And make sure to keep jumping back and forth between the two to account for anomalies.
Edit: On another note, to complete the analogy... Interactive and HMP is more similar to the chef being the announcer as well. Except for he is able to see less than a dedicated announcer can. I.e the chef (interactive governor) can't look at the queue outside his restaurant but only the ones in his restaurant (so he is partly blind). A dedicated announcer can look at customers inside and outside the restaurant though.
Do note that this has little to do with EAS per se. EAS is a different beast that focuses on optimizing which customers is assigned to which chefs. I'll probably write the analogy for this another time if there is a demand for it
Click to expand...
Click to collapse
FAQ
Q: I got the SD is corrupted message after booting and my sdcard is formatted as exfat. What should I do?
A: Reboot to Recovery mount USB storage, unmount it and reboot.
Q: I switched kernels and now my wlan isn´t working?
A: that is because I have to use my own wlan module. restore system of your nandroid. or extract stock wlan module from custom rom.
Q: My device does not sleep and the reason is media scanner is holding the device awake. What to do?
A: There can be a strange case where the exfat nofuse driver I have to use in order for external sdcard to work creates an infinite folder loop.
It can be solved if you check your sdcard with a file manager for a folder like android/data/com.xyz.app/files/files/files/files...... and so on.
Go to twrp recovery move the infinite file folder to the root of external sdcard. Then it can be easily deleted. Before moving the file deleting it is not possible.
Q: How to set up the cleanslate LED/Notification Light/BLN options?
A: Take a look at this post: https://forum.xda-developers.com/showpost.php?p=72710244&postcount=2
Not needed as per Version 3.0
Q: Netflix isn´t playing videos?
A: go to settings -> dev options -> untick disable hw overlays, watch netflix and don´t forgot to tick the option again after using netflix ( say thank you to HTC for not releasing the new source)
So allright guys. This will be the section where you will fine information on how to fine tune the EAS kernel if you aren´t satisfied with my default settings.
So as you can see in a kernel manager like EXKM for example we have an input boost on this kernel.
The 4 little cores ( aka the little cluster) gets boosted to 1171.200mhz for 1500ms when you interact/touch your screen by default.
This ensures scrolling/fling/app loading smoothness.
Now you say, only core 0 gets boosted. But if you look at the source you will see the cpu boost driver works only for both clusters and single cores. This is done by design.
If you want to additionally boost the big cluster (because you aren´t satisfied with above mentioned scrolling/fling/app loading etc) you have to define the boost frequency for core 4 also.
Writeup for dynamic stune boost v1 (OLD)
Now a writeup on dynamic stune boost by @joshuous
For those who are not sure what Stune (schedtune) boosting is, it is an EAS feature that allows you to bias frequencies higher or lower for certain task groups.
Android defines the following task groups that you can boost:
1. Top-app: The task that you're directly working on, or the task that you see. This mostly refers to the app that you're currently interacting with.
2. Foreground: Tasks that are not the top-app, but are still part of the user experience (e.g. the surfaceflinger display thread and audio threads)
3. Background: Tasks that are not part of the user experience (e.g. some random task running in the background that you don't care about)
4. System-background: Similar to background, but specifically for system tasks
5. Root: anything that else that does not belong to the other categories
Why do we need Schedtune boosting when we already have the cpu-boost feature?
cpu-boost works by allowing the user to set the specific boost frequencies and duration for clusters. But how do you know whether the frequency you specified is too little or too much? If you specify 1000 MHz boost for Little cluster, is that overkill for typing, or is it too miniscule for scrolling in a content-heavy app like Google Calendar? You end up facing a dilemma of choosing between increased battery drain or increased smoothness. Personally, I find that cpu-boost is rather inflexible and doesn't scale according to the user's needs.
So how does Schedtune boosting work?
Let's first talk about Schedutil governor. It works by using utilisation data provided by the [Linux] Completely Fair Scheduler. The 'CFS Scheduler' (not I/O scheduler erherm), in simple words, decides which tasks should be assigned to which CPU cores. Based on the Scheduler's knowledge of the tasks it allocates to cores, it can directly sends signals about the cores' utilisation to the Schedutil governor. Think of utilisation as the number of customers that a chef needs to serve at this point in time. The Schedutil governor uses the utilisation value and tells the chef how fast he must cook (what frequency the core should run at).
Now sometimes you may have certain customers (who are part of the Top-App Company) who are in a hurry to get their food and rush back to work. You need to serve the Top-App customers urgently, so you ask the chef to cook even faster than usual. You can think of Schedtune boosting as artificially inflating the number of customers (boosting the utilisation value) to get your chef to cook faster.
The beauty of Schedtune boosting over cpu-boost is that you don't need to fix a frequency to boost to. Instead, the Schedutil governor will give certain tasks a little bit more oomph. If the original unboosted frequency for scrolling is 600 MHz, Schedutil may boost it a little bit more to 750 MHz, for example. If the unboosted frequency for scrolling in calendar is 1000 MHz, perhaps Schedutil may boost it to 1300 MHz. It all depends on the boost value you want to set.
Give Schedtune boosting a go
Analogies aside, you can adjust the boost value in /dev/stune/{top-app, foreground, background, system-background}/schedtune.boost. Usually we mostly care about boosting top-app. Schedtune boost basically boosts the utilisation value by a certain factor. For example, if you set a boost value of 10, the utilisation (not the frequency) is boosted by 10%. A larger utilisation value will cause Schedutil to select a higher frequency.
Try setting the value in /dev/stune/top-app/schedtune.boost to a value between 10-20. Turn off cpu-boost. Enable GPU profile rendering and watch the magic. If your results are like mine, you'll see very low bars which means that it's really smooth. Launch CPU Float app and observe the frequencies. You might notice that they run at a very low frequency compared to the default cpu-boost value, yet it is even smoother. Why is Schedtune boosting producing smoother experience at a lower frequency? I have no freaking clue :S.
Now what is Dynamic Schedtune Boosting?
The issue with setting schedtune boosting (in /dev/stune/*) is that it boosts 24/7 and could drain a bit more battery. There are some situations when you may not want to boost, such as watching YouTube (Top-app task). Boosting is beneficial for mostly touch activity, such as scrolling or typing. The solution I implemented was extending the cpu-boost feature to apply schedtune boost only during touch activities. Other than touch events, schedtune boost won't run 24/7 and drain excess battery.
Getting started with Dynamic Stune Boost
To get started do the following:
1. Enable cpu-boost
2. Set all cpu-boost frequencies to zero
3. Set the boost duration to 1500ms (you can vary it depending on your needs)
4. Edit the boost value in /sys/module/cpu_boost/parameters/dynamic_stune_boost to between 10-20. Feel free to adjust this value. Make sure to set /dev/stune/top-app/schedtune.boost to 0, otherwise it may overwrite dynamic schedtune boost.
5. Turn on GPU Profile Rendering to analyse smoothness of frames.
6. Enjoy and report back your findings in terms of your tunable values, smoothness and battery drain.
tldr; If your brain hurts, just follow the instructions in "Getting started with Dynamic Stune Boost"
Now you may see that I don´t use the dynamic schedtune boost by default. That is because most tasks got assigned to the little cores when activating it and it actually performs worse. This will get solved in some time and I may update the guide then again.
But for now it is not recommended to turn on the dynamic stune boost.
Current setting are
dev/stune/schedtune.boost is at 5
dev/stune/top/app/schedtune.boost is at 15.
input boost is enabled for the little cluster (core 0) at 1171.200mhz for 1500 ms
If you want to experiment with different schedtune.boosts for global, background, foreground and top-app and found good values please share them with us here in the thread
A workaround for you experiment guys that want to enable the dynamic schedtune boost is:
1. Set /dev/stune/top-app/schedtune.boost to 5-10
2. Set dynamic stune boost to 10-20 (I like 20)
The issue with dynamic stune boost is that it only (at the moment) boosts the frequencies of the cluster that a top-app task resides in. So why were there still performance issues? That's because top-app tasks preferred to stay on Little cores, which is likely overcrowded already. That means that the top-app task have to compete with the other tasks on the same overcrowded core for computing power. Imagine it like having a huge pizza (high frequency), but so many people have to share it such that you only get a tiny piece. This is why a task can run on the less-crowded Big cluster at a much lower frequency but still perform better than running on a crowded Little cluster with high frequency.
Now, setting the /dev/stune/top-app/schedtune.boost to 5 does two things. Firstly, it increases the perceived load of the individual top-app task, consequently biasing Schedutil to select a higher frequency (not by much). Secondly and most importantly, since the perceived load is higher (imagine a very hungry person), EAS decides that it needs to be shifted to the Big cluster (larger pizza). 5 was chosen because it's around the tipping point to cause the shift. Use 10 if it's not smooth enough.
Dynamic stune boost doesn't influence tasks to be shifted to the Big cluster, which is why top-app tasks tended to stay on Little cluster.
Combining both steps, we can influence top-app tasks to run on Big cluster (step 1), and a larger Dynamic Stune Boost value will cause the frequency to ramp up during touch interactions on the Big cluster where top-app tasks run (step 2). No unnecessary boosting when watching YouTube woohoo!
Tldr; You're in a pizzeria. Regular schedtune boost shifts you to a less crowded table. Dynamic schedtune boost increases the size of your pizza. Your stomach rejoices
Writeups about dynamic schedtune boost v2 from @Mostafa Wael and @joshuous
Dynamic SchedTune Boosting v2
Couple of weeks ago, Joshuous wrote a new feature, namely Dynamic SchedTune Boosting, that’s been incorporated in recent RenderZenith kernel builds, which essentially alters the value of schedtune.boost for the top-app cgroup dynamically on touch events, to conserve battery. But still, the solution was not that flawless, since it didn’t migrate the task to the big cores when essential as Joshuous previously explained. A quick workaround was to increase the value of /dev/stune/top-app/schedtune.boost to 1 (at least) to allow the utilization of the big cores when required. Many of you may be wondering why that was necessary. Well, hopefully I can break it down a bit for you.
Given the task that needs processing, the find_best_target() function – that is responsible for placing the tasks on the suitable cluster – iterates firstly on the big cluster when the SchedTune boost value is greater than 0, whereas the little cluster will be iterated firstly, should the value of SchedTune boost be equal to or less than 0, to save power. What SchedTune boost does is inflating the task and CPU utilisation fed to the scheduler, and therefore impacting the OPP selection and allowing the task to be placed on the big core(s) if needed. What the older version of Dynamic SchedTune Boosting did was rather inflating the value of utilisation going into Schedutil governor, that is then used to determine the frequency step to be selected for the task via a linear formula, which consequently increases the calculated frequency. But since the value of utilisation going into the scheduler is not inflated, the placement of the task on the corresponding core(s) won’t be impacted and therefore, the task won’t be moved to a big core instead. In essence, the older version would only increase the frequency and not impact the tasks placement on the cores. This caused a drastic performance difference compared to what you get when setting the SchedTune Boost value statically.
With the new v2 version, Dynamic SchedTune Boosting will directly change the value of /dev/stune/top-app/schedtune.boost directly, addressing the issue of only inflating the utilisation data going to the schedutil governor, and therefore the tasks should be able to move to the big cluster when demanded as well as increasing the CPU frequency. This will allow us to safely leave the value of /dev/stune/top-app/schedtune.boost at 0 and save some power for low-medium workload scenarios, since the tasks will be moved to the big cluster on touch with no issues.
-TDK
with a little addition from @joshuous
Very well explained Mostafa
And thanks for saving me the time
To add on, don't be alarmed to see /dev/stune/top-app/schedtune.boost having the same value as dynamic_stune_boost when you want to edit it because your touches trigger the boosting. Just write the value you want into the file and save. It will automatically update the default stune boost value when the boosting stops. To confirm it, you can connect your phone to computer and do
adb shell cat /dev/stune/top-app/schedtune.boost
to confirm that it has changed. You gotta wait a second or so before you issue that command.
I would recommend keeping the /dev/stune/top-app/schedtune.boost at 1 or higher if you want lower latency when Dynamic Stune Boost kicks in. Reason being that default stune boost of 1 somewhat ensures that most of the top-app tasks are already on Big cluster so that we don't have to suddenly migrate too many tasks from Little to Big when Dynamic Stune Boost kicks in.
If you don't type much, and watch videos or listen to music mostly, then setting default stune boost to zero may save you more battery
following this link you will also find a goog explanation on how things work with EAS. It is quite simplified but good to get the general idea of it.
https://forum.xda-developers.com/showpost.php?p=74054394&postcount=526
Proper Way to Report a Bug
ramopps: is an oops/panic logger that writes its logs to RAM before the system
crashes. It works by logging oopses and panics in a circular buffer. Ramoops
needs a system with persistent RAM so that the content of that area can
survive after a restart.
logcat: the logoutput of the Android system
kernel log: (kmsg / dmesg): the kernel messages
Additionally there's the last_kmsg which is a dump of the kernel log until the last shutdown.
radio log: the log outpur ot your System / BB / RIL communication
4
ramopps: Some Documentation on Ramopps
Normal Logcat:
Code:
adb logcat -v time -d > logcat.log
Radio Logcat:
Code:
adb logcat -b radio -v time -d > logcat_radio.log
Ramoops:
Code:
adb shell su -c cat /sys/fs/pstore/console-ramoops > kmsg.txt
Kernel Log:
Code:
adb shell su -c dmesg > dmesg.log
Last_Kmsg: NOTE:
New location of last_kmsg on Android 6.0 and above: /sys/fs/pstore/console-ramoops
Code:
adb shell su -c "cat /proc/last_kmsg" > last_kmsg.log
NOTES:
-v time will include timestamps in the logcats
-d will export the complete log.
If you want to save a continuous log you can remove the -d parameter - then you need to cancel the logging process via CTRL+C.
To export a continuous kernel log use adb shell su -c "cat /proc/kmsg" > dmesg.log (and cancel it via CTRL+C again).
PS: This Document was taked from another XDA Thread Called: [Reference] How to get useful logs
URL: http://forum.xda-developers.com/showthread.php?t=2185929
Also check this one out: [Tutorial] How To Logcat
I only Revived it a bit for ramopps.
I will update this more at a later time..
[DMESG Help Commands]
Code:
Usage:
dmesg [options]
Display or control the kernel ring buffer.
Options:
-C, --clear clear the kernel ring buffer
-c, --read-clear read and clear all messages
-D, --console-off disable printing messages to console
-E, --console-on enable printing messages to console
-F, --file <file> use the file instead of the kernel log buffer
-f, --facility <list> restrict output to defined facilities
-H, --human human readable output
-k, --kernel display kernel messages
-L, --color[=<when>] colorize messages (auto, always or never)
colors are enabled by default
-l, --level <list> restrict output to defined levels
-n, --console-level <level> set level of messages printed to console
-P, --nopager do not pipe output into a pager
-r, --raw print the raw message buffer
-S, --syslog force to use syslog(2) rather than /dev/kmsg
-s, --buffer-size <size> buffer size to query the kernel ring buffer
-u, --userspace display userspace messages
-w, --follow wait for new messages
-x, --decode decode facility and level to readable string
-d, --show-delta show time delta between printed messages
-e, --reltime show local time and time delta in readable format
-T, --ctime show human readable timestamp (may be inaccurate!)
-t, --notime don't print messages timestamp
--time-format <format> show time stamp using format:
[delta|reltime|ctime|notime|iso]
Suspending/resume will make ctime and iso timestamps inaccurate.
-h, --help display this help and exit
-V, --version output version information and exit
Supported log facilities:
kern - kernel messages
user - random user-level messages
mail - mail system
daemon - system daemons
auth - security/authorization messages
syslog - messages generated internally by syslogd
lpr - line printer subsystem
news - network news subsystem
Supported log levels (priorities):
emerg - system is unusable
alert - action must be taken immediately
crit - critical conditions
err - error conditions
warn - warning conditions
notice - normal but significant condition
info - informational
debug - debug-level messages
[LOGCAT Help Commands]
Code:
Usage: logcat [options] [filterspecs]
options include:
-s Set default filter to silent.
Like specifying filterspec '*:S'
-f <filename> Log to file. Default is stdout
-r <kbytes> Rotate log every kbytes. Requires -f
-n <count> Sets max number of rotated logs to <count>, default 4
-v <format> Sets the log print format, where <format> is:
brief color long printable process raw tag thread
threadtime time usec
-D print dividers between each log buffer
-c clear (flush) the entire log and exit
-d dump the log and then exit (don't block)
-t <count> print only the most recent <count> lines (implies -d)
-t '<time>' print most recent lines since specified time (implies -d)
-T <count> print only the most recent <count> lines (does not imply -d)
-T '<time>' print most recent lines since specified time (not imply -d)
count is pure numerical, time is 'MM-DD hh:mm:ss.mmm'
-g get the size of the log's ring buffer and exit
-L dump logs from prior to last reboot
-b <buffer> Request alternate ring buffer, 'main', 'system', 'radio',
'events', 'crash' or 'all'. Multiple -b parameters are
allowed and results are interleaved. The default is
-b main -b system -b crash.
-B output the log in binary.
-S output statistics.
-G <size> set size of log ring buffer, may suffix with K or M.
-p print prune white and ~black list. Service is specified as
UID, UID/PID or /PID. Weighed for quicker pruning if prefix
with ~, otherwise weighed for longevity if unadorned. All
other pruning activity is oldest first. Special case ~!
represents an automatic quicker pruning for the noisiest
UID as determined by the current statistics.
-P '<list> ...' set prune white and ~black list, using same format as
printed above. Must be quoted.
filterspecs are a series of
<tag>[:priority]
where <tag> is a log component tag (or * for all) and priority is:
V Verbose (default for <tag>)
D Debug (default for '*')
I Info
W Warn
E Error
F Fatal
S Silent (suppress all output)
'*' by itself means '*:D' and <tag> by itself means <tag>:V.
If no '*' filterspec or -s on command line, all filter defaults to '*:V'.
eg: '*:S <tag>' prints only <tag>, '<tag>:S' suppresses all <tag> log messages.
If not specified on the command line, filterspec is set from ANDROID_LOG_TAGS.
If not specified with -v on command line, format is set from ANDROID_PRINTF_LOG
or defaults to "threadtime"
[/QUOTE]
That's great achievement, congrats and thanks for bringing eas to the u11!
congrats!
Also @damanrico this might interest you. For me every lag the u11 with the stock hmp implementation had is eliminated with EAS.
To everyone.
Just set input boost to 1,401ghz for the small cluster in ex kernel manager.
duration to 1500ms
And
dev/stune/top-app/schedtune.boost to 20
Edit:
dev/stune/schedtune.boost to 5
Please experiment with this settings. I want this completely smooth.
Make sure to use schedutil governor!
Freak07 said:
Also @damanrico this might interest you. For me every lag the u11 with the stock hmp implementation had is eliminated with EAS.
To everyone.
Just set input boost to 1,401ghz for the small cluster in ex kernel manager.
duration to 1500ms
And
dev/stune/top-app/schedtune.boost to 20
dev/stune/schedtune.boost to 5
Please experiment with this settings. I want this completely smooth.
Make sure to use schedutil governor!
Click to expand...
Click to collapse
For me it is smooth as baby a$$ in this short time I am using it ..
I'd like to try this...any chance for a Magisk-compatible version? I don't ever write directly to system anymore...
Flashed it and my wifi won`t turn on at all.
grega_slo said:
Flashed it and my wifi won`t turn in at all.
Click to expand...
Click to collapse
Are you on magisk?
Nope.
Latest Viper coming from elemetalx kernel.
grega_slo said:
Flashed it and my wifi won`t turn on at all.
Click to expand...
Click to collapse
Freak07 said:
Are you on magisk?
Click to expand...
Click to collapse
Same here, wifi not turning on. I'm on US Unlocked 1.16 firmware running magisk version of Viper rom 1.5
I'll see if I can grab log files later today, but I'm at work now.
grega_slo said:
Nope.
Latest Viper coming from elemetalx kernel.
Click to expand...
Click to collapse
Can you extract the file qca_cld3_wlan.ko out of the directory /system/lib/modules/qca_cld3 from my Zip
And push it to /system/lib/modules/qca_cld3
overwrite the existing module, set permissions to 644 rw-r--r-- and reboot?
And see if that fixes it?
What version of the phone do you have?
jsaxon2 said:
Same here, wifi not turning on. I'm on US Unlocked 1.16 firmware running magisk version of Viper rom 1.5
I'll see if I can grab log files later today, but I'm at work now.
Click to expand...
Click to collapse
Would you also try this?
Can you extract the file qca_cld3_wlan.ko out of the directory /system/lib/modules/qca_cld3 from my Zip
And push it to /system/lib/modules/qca_cld3
overwrite the existing module, set permissions to 644 rw-r--r-- and reboot?
And see if that fixes it?
What version of the phone do you have?
Freak07 said:
Would you also try this?
Can you extract the file qca_cld3_wlan.ko out of the directory /system/lib/modules/qca_cld3 from my Zip
And push it to /system/lib/modules/qca_cld3
overwrite the existing module, set permissions to 644 rw-r--r-- and reboot?
And see if that fixes it?
What version of the phone do you have?
Click to expand...
Click to collapse
just did that and it worked
Edit: European dual sim
velimirchek said:
just did that and it worked
Click to expand...
Click to collapse
Yup +1
Thank you both. Did a silly mistake. Will upload new zip soon. The wlan module didn’t get flashed.
Freak07 said:
Thank you both. Did a silly mistake. Will upload new zip soon. The wlan module didn’t get flashed.
Click to expand...
Click to collapse
FYI I made a Magisk version of the zip that doesn't flash anything to system and a separate Magisk support module, and it seems to be working okay (I have working Wi-Fi, if that's any indication). Is there any way for me to know for sure that everything is working as it should?
{
"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"
}
DESCRIPTION
Hey guys, I have started a custom Kernel based on LineageOS sources with 98% CAF. So I would like to share my own performance and usability improvements with minimal feature and enhancements on top. The intention is to have a minimal light-weight kernel that is very fine tuned for the device.
FEATURES
Minimal Kernel with a stripped defconfig base to be more streamlined and have less memory footprint
User space display color calibration (KCAL) with screen calibrated against iPhone 8 Plus, also helps reducing screen retention
Schedutil governor making use of EAS features with updates from Linux 4.4 and 4.12
Up to date with LineageOS sources for maximum compatibility and security bugfixes
Memory and cache subsystem optimizations, you will feel it
Adaptive LMK enabled by default
Transparent Hugepages are enabled
ZRAM/Swap partition is disabled by default
BFQ IO scheduler set by default to avoid slow-downs on task intensive scenarios
No overclocking was chosen to avoid unnecessary heat, optimizations were focused on other different areas
Kernel Samepage Sharing enabled with deferred timer by default to gain some memory usage optimizations, the process sleeps on regular basis and I've profiled it so that there's no battery drains due to it
Simple temperature controls for msm_thermals exposed
Compiled with GCC 6.x optimized toolchain and -O3 plus other hardware specific flags
Undervolted the Adreno 530 GPU voltage rail to keep things cooler
CAF Rebase on major portions of the Kernel has helped lower the memory footprint a lot
ES9218 Quad DAC automatic toggling working inside the kernel for headphone HIFI playback, please read here for details
DOWNLOADS
AnyKernel: Click Here (Or check top of the post, download tab)
Extended Screen AnyKernel : Click Here (Maintained by @iDefalt)
(Recommended) Stock Tasha XML Audio Mixer FIles : Click Here
(Recommended) Stock Thermal Engine with Tweaked Values Flashable : Click Here
(Recommended) Vulkan Adreno GPU Drivers with correct SELinux labels and permissions : Click Here
SOURCE
V20-Kernel-Gamma GitHub Source
NOTES
Here is a GeekbenchV4 result example : http://browser.geekbench.com/v4/cpu/10667886
KNOWN BUGS
Changing CPU governors will greatly impact EAS and give erratic behaivour -- please check here, here and here. This is an EAS only Kernel.
I would also like to thanks to various people who contribute tremendously such as:
@x86cpu
@EvilHowl
@USA-RedDragon
@savoca
@albinoman887
@emdroidle
@Rashed97
@joshuous
@RenderBroken
and many others!
<< If you like my work here is my hat, please donate! >>
XDA:DevDB Information
Gamma Kernel, Kernel for the LG V20
Contributors
Omar-Avelar
Source Code: https://github.com/oxavelar/V20-Kernel-Gamma
Kernel Special Features:
Version Information
Status: Stable
Current Stable Version: 105.0.0
Stable Release Date: 2019-09-21
Created 2018-05-09
Last Updated 2019-09-21
CHANGELOG
105.0.0 - Increased responsiveness by adjusting input boost and stune values. Updated the thermal mod values again, revert LA.UM.6.5.r1-11700-8x96.0 to fix green tint crashes and updated to AnyKernel3.
103.0.0 - Merging LA.UM.6.5.r1-11700-8x96.0.
102.0.0 - Update SDCARDFS driver. And updated the thermal mod values to account for GPU undervolt.
101.0.1 - Re-enabled -O3 optimizations and increased little cores boost.
101.0.0 - Compiled with Linaro GCC 8.3.
99.0.0 - Experimental performance values.
90.0.0 - Adding dynamic_stune_boost_ms as part of input boost schedtune.
88.0.0 - Performance increase while phone is used.
87.0.0 - Dynamic schedtune adjustments.
86.0.0 - BFQ enhancements and fixing the last watchdog timer bites.
85.0.0 - Merging LA.UM.6.5.r1-10900-8x96.0 with stability fixes and no green-screen crashes. Tweaking further the input boost frequencies, and enabling IO wait boost on big.LITTLE cores. More BFQ merges from upstream Kernel.
84.0.0 - Back to the performance levels, after being stable for 24 hours without green screening on tag LA.UM.6.5.r1-09800-8x96.0.
83.0.0 - Revert a merge which I believe be the culprit of the kernel panics. Tag is now based on LA.UM.6.5.r1-09800-8x96.0.
82.0.0 - Synced wireless drivers, as I think this was causing kernel panics.
80.0.0 - Merge LA.UM.6.5.r1-10600-8x96.0, fixing infrared and updating AnyKernel.
78.0.0 - Align memlat with gpubw frequency tables to prevent jerking. Backporting a few of BFQ Linux 5.0 mainline changes and enhancements into Linux 3.14.
77.0.0 - Further tweak schedtune values and dynamic boosting.
76.0.0 - Enable schedtune 3.0 boosting, finer Kernel CPU boosting, and disabling user-space perfd.
74.0.0 - Extracting more performance by tweaking BCL and memory bandwidth scaling again.
73.0.0 - Optimized BFQ a tad bit, and some power saving features on the memory bandwidth scaling ramp values on idle.
72.0.0 - Updated BFQ-v8r12 for 3.14 and some UFS clock scaling tweaks for the IO subsystem.
71.0.0 - iowait_boost_enable save and restore working. Keeping this enabled for MSM8996 EAS as well as keep allow_attach just like Wahoo.
70.0.0 - Add debug.gralloc.gfx_ubwc_disable=0, as well as reverting to default OpenGL renderer due to whatsapp camera glithces and other misc glitches depending on GPU driver.
68.0.0 - Adjusting allocstall_threshold.
67.0.0 - Updated AnyKernel files and fixed a regression caused by down_thres that was there for a lot of builds.
66.0.0 - Enabling Skia OpenGL rendering by default. Also please update the "(Recommended) Stock Thermal Engine with Tweaked Values Flashable" file, updated some timer values to keep the smoothness consistency overall with this Kernel version better with these thermal and timer values.
65.0.0 - Relaxing memlat to see how much battery improvements we get from this.
64.0.0 - Updated the EAS timer values and the memory subsystem. Re-increased the freq mitigation freq back again to 1.3 GHz on big cluster for less jank.
63.0.0 - Carved out the memory map back of some ADSP devices and modem back to what LGE is using, let's see if this fixes the sporadic Kernel panics on H990DS.
62.0.0 - Further tweaked our GPU Adreno drivers setprop values on boot.
60.0.0 - Overhauled the charging code by removing a lot of factory junk and taking some pieces from Alice. Tweaked a tad bit the the memlat governor values again.
59.0.0 - Changes in MTP handling that came from LGE to see if it helps the Kernel panics seen with MTP file transfers. (Tired to see if the panel can be bumped to 90 Hz refresh rate but decided to not include as screen seems to not be responding after trying it for a while...).
58.0.0 - Shaved off 4 MiB from unused msm8996pro-*.dtsi files.
57.0.0 - Better charging mitigation. Updated to CONFIG_LGE_PM_CHARGING_SCENARIO_V18.
56.0.0 - Charging detection logic clean-up based on CAF and less of LGE's.
55.0.0 - Merged the charger controller scenarios code with Oreo.
54.0.0 - MDSS display cleanup and memlat tweaks. Should feel snappier. Merged a few USB Type-C code portions from the Oreo source, hopeful fixed h918 static on boot as well with my experiments.
53.0.0 - Charger logic detection was taking longer sometimes, fixed this. And removed some extra dtsi junk that helped shave 300 KiB of Kernel image size.
52.0.0 - Backported a few things from newer schedutil. And fixed h910 static on boot I had introduced due to my own experiments.
51.0.0 - Converged to only two panel files, "dsi-panel-sw49407-dsc-qhd-cmd.dtsi" and "dsi-panel-sw49407-dsc-qhd-cmd-global.dtsi", experimental. Fixed on mem subsystem tweaks not being honored due to me starting perfd earlier than expected by mistake.
50.0.0 - Converged on single "dsi-panel-sw49407-dsc-qhd-cmd.dtsi" file. Added lge,skip-auto-mute in the audio *.dtsi. Increased the panel qcom,switch-freq-khz to 800 based on latest Oreo sources as well.
49.0.0 - LGE's Panel & MDSS extra clean-up.
47.0.0 - Re-adjusted the thermal and tasha files, updated the lpm cpuidle and memory subsystem parameters.
46.0.0 - Updated memory sybsystem parameters, and re-ajdusted thermal and tasha files.
45.0.0 - LA.UM.6.5.r1-09800-8x96.0 merge and ramdisk module debugging disable fixes.
44.0.0 - More MSM ISP CAF merges that keep LGE compatibility intact.
43.0.0 - firmware_class: make firmware caching disabled by default. Since NETLINK wakelocks are disabled in our Kernel keeping this disabled makes the most sense.
42.0.0 - Re-did the BCL freq mitigation to override Elsa variant for now, reverted the anx7688 firmware and updated the screen calibration further.
40.0.0 - Re-did the BCL voltage and freq mitigation changes to make the phone usable when battery levels drop and prevent any potential kernel panics.
39.0.0 - Re-introduced MSM_PERFORMANCE and tamed a tiny bit the memory scaling subsystem to keep a better active power consumption.
38.0.0 - fs: sdfat: Update to version 2.0.8 and more ARM64 related memory optimizations.
37.0.0 - Display color calibration was re-adjusted using iPhone panel as reference again. It got shifted a little bit after *.dtsi merges months ago and just had noticed.
36.0.0 - Major cleanup in the qpnp-smbcharger.c portion. Playing with BCL removal.
35.0.0 - Keeping ULPS and LP11 both in the *.dtsi files for the Panel and tuned further with micro-benchmarks.
34.0.0 - Changing compiler flags a little bit. Adding explicitly the LP64 ARM ABI, and using UPSTREAM: arm64: lib: improve copy_page to deal with 128 bytes at a time. Reverted the arm64 prefetchers during memcpy, and re-introduced the msm_thermal sysfs entries that I had take out during debug.
33.0.0 - Fixed a MSM ISP Bug when taking photos from certain applications was fixed. It would sometimes crash when taking pictures from Whatsapp with the recent merges I have been trying and the bug went unnoticed by me. Fixed USB not charging under certain USB cables as well as qpnp-smbcharger.c code cleanup.
32.0.0 - MSM ISP Upstream changes that improve msm-camera daemon performance. Also noticed this has improved focusing speed with the camera.
31.0.0 - Performance boosts changes to memory scaling and latency had to be adjusted after using CONFIG_SCHED_AUTOGROUP to take into account.
30.1.0 - Rebased now from LA.UM.6.5.r1-09300-8x96.0 CAF and CONFIG_SCHED_AUTOGROUP is being enabled.
29.0.0 - BCL big freq fixes from ls997 Oreo's source as well merge on USB's ANX7688 code.
28.0.0 - Stopping and restarting perfd when doing cpu tweaks to be safer on the state of EAS when changing things up. Fix for Ok google, returned LGE's VTS.
27.0.0 - Removing sched while keeping schedutil, updating the BCL masks, and removing LGE's VTS. Updating GCC's Linaro 6.4 to the 2018 pre-builts.
24.1.0 - Triggering enable-cpu-tweaks on events enable-low-power, property:sys.perf.profile=1 to see if it fixes gaming performance profile switching.
24.0.0 - mmc: move to a SCHED_FIFO thread, power: make sync on suspend optional.
23.0.0 - Disabling BCL hotplugging for voltage based while still keeping the temperature one. Added a commit to prevent writeback dirtying by multiple threads.
22.0.0 - Added updating of the BCL masks during EAS schedutil changes, one suspect on limiting to 1 GHz. Investigating if low-battery power mode also could impact this in the meantime.
21.0.0 - Updated the Kernel scheduler tunables.
20.0.0 - Remove duplicate commit in IRQ subsystem, and letting LineageOS use the default EAS cpusets and DVR values instead. Setting saturation again after boot-complete.
19.0.0 - Re-introducing CONFIG_LGE_PM_LGE_POWER_CLASS_CHARGER_SLEEP in Oreo as well as minor changes in memory subsystem scaling again.
18.0.0 - Removing backlight levels override on boot -- this was a leftover from Nougat time where cache-build might have happened at boot, so I had used this to lower heat generation but it's not needed. Tweaked a little the memory subsystem scaling timer interrupts now that msm_irqbalance is enabled in recent Oreo builds.
17.0.0 - Letting LOS handle msm_irqbalance now as this was enabled recently on LOS 15.1 July 12th 2018 build.
16.0.0 - Started msm_irqbalance by default on boot, disabled lp11 and enabled allow mdss phy powerdown during idle screen.
15.0.0 - Smoother memlat ramp and tuned the schedTune DVR cpusets a bit for better performance overall.
14.0.0 - Fix for touch not working when the phone boots connected to charger, more deep sleep enhancements and addition to H990 and H990DS to the builds.
13.0.0 - Update to Oreo TouchScreen firmware and more MDSS PLL merge fixes that help deep sleep.
12.0.0 - Missing MDSS Oreo merges are now in place.
11.0.0 - Added IPA_WS as a default in the wakelock blocker, as well as enabling CONFIG_PM_SLEEP which if missing would in turn cause some ueventd wakeups.
10.0.0 - Fixed video recording, disabled CONFIG_RMNET_DATA_DEBUG_PKT. Full fix for USB OTG and added missing slimport drivers. Tweaked the random wakeup values, added some extra cpusets based on Marlin's android-cts-8.0_r8/init.common.rc and fixed some BFQ IO possible hang.
8.2.0 - Removed LGE's battery manager alarms.
8.1.0 - Fixed potential wireless packet loss, reverted the potential video recording fix from previous build.
8.0.0 - Further tweaked the wlan_rx_wake wakelock, added a potential video recording fix identified, migrated the audio and thermal workers to power efficient queues, and added an arm64 prefetching optimization for memcpy (the last 3 changes got into LineageOS as well).
7.0.0 - Better deep sleep enhancements with the charger infrastructure borrowed from the V30 Kernel Oreo sources.
6.0.0 - Full fix for 6a00000.ssusb wakelocks while keeping fast charging enabled.
4.1.0 - Tuned further the wakelocks to avoid any wireless packet loss. As well as adding [timerfd] into the block list.
3.0.0 - Added boeffla_wl_blocker to tame NETLINK wakelock, this wakelock is caused by IPC between the wireless driver in the Kernel and Android. This was the reason why when on wireless the battery would drain more compared than radio.
2.0.0 - Rolled back the OTG fixes so that the phone deep sleeps well, and patched the "6a00000.ssusb" wakelock by reverting a few files. Enabled a few more battery savings from EAS that should help battery.
1.0.0 - Synced the NFC driver with Lineage, OTG fixes by @x86cpu. Adjusted the DAC impedance thresholds per LG's Oreo Kernel, as well as disabling store mode and factory cable detection on newer Oreo LG's PM stack.
0.9.99 - Initial version, with KCAL, GPU Undervolting, EAS schedutil, memory subsystem tweaks, and so far working and booting LineageOS 15.1 with better input frequency values due to lack of perfd. Re-introduced the Virtual Thermal Sensor (VTS) for even better thermal management when using the LG's stock thermal flashable.
Thanks, flashing in the morning! ??
Good job Omar, will flash this and report later
Where's 1.0.0? Also, can we use one of your GPS fixes from the previous kernel topic?
Just flashed yesterday and used it for a day. Performance is good, although not significantly better than the stock LOS kernel and things ran pretty smooth overall.
However battery life was straight up horrible, especially in standby. I went to sleep with 95% battery but even with Naptime enabled (forced doze) I woke up with the battery at 60%. The phone was losing more battery in standby than while I was actually using it. So for now I'm back on the stock LOS kernel but hopefully new builds will fix battery.
Ruckamongus said:
Where's 1.0.0? Also, can we use one of your GPS fixes from the previous kernel topic?
Click to expand...
Click to collapse
The GPS fixes are already in Lineage-15.1 AFAIK, no need!
droidrzr1610 said:
Just flashed yesterday and used it for a day. Performance is good, although not significantly better than the stock LOS kernel and things ran pretty smooth overall.
However battery life was straight up horrible, especially in standby. I went to sleep with 95% battery but even with Naptime enabled (forced doze) I woke up with the battery at 60%. The phone was losing more battery in standby than while I was actually using it. So for now I'm back on the stock LOS kernel but hopefully new builds will fix battery.
Click to expand...
Click to collapse
0.9.9 was decent in this front, 0.9.99 had some bugs as I was testing out (idle power consumption is one). That is why I have not released 1.0.0 as I want to iron everything out for the first release. These are experimental builds and feedback is greatly welcome as I prepare to fix it all!
I'm trying to figure out this dac Volume situation, how do I get the volume to kick in. It still sounds stock to me. I don't have much volume as I used to on a stock rom. Do I have to have the impedance to kick it in or can I bypass it like I used to
lowridincrew said:
I'm trying to figure out this dac Volume situation, how do I get the volume to kick in. It still sounds stock to me. I don't have much volume as I used to on a stock rom. Do I have to have the impedance to kick it in or can I bypass it like I used to
Click to expand...
Click to collapse
Manually editing the mixer file to force high impedance doesn't work on AOSP roms. Only stock. The code is there for it to work automatically, but if your headphones don't have a resistance of higher than 50 ohms, than it won't activate. I haven't seen anyone test with high impedance headphones to actually see if it works though. Code is there, but still unknown if it works. I had no luck getting it to activate.
Just a thanks and a quick recap of my post on the unofficial thread Omar!
Long-time lurker and H918 abuser on the 10p Firmware and modem here.
Just wanted to post on here and give my sincerest thanks to x86cpu, Omar-Avelar and all the devs responsible for breathing new life into my V20!
I haven't been this excited to use it since I first got the dang piece of lazily coded korean garbage back in 2016.
Reminds me of my Note 4 days, man that thing has also had a long ass run.
I've tried so many ROMs, kernels, zips and hacks.
Lost count of how many times I debloated, rebloated, went stock, went AOSP, flashed and unflash magisk.
Good Lord, If I knew performance could EVER have been this good in an AOSP like rom and if it weren't
for the removable battery, I probably should have gone with a Pixel or something.
Definitely feels faster since I replaced the battery before flashing, definitely recommend you guys consider replacing it if you've used it for a year or so and it's starting to die at like 15-30%.
Running it since the 05/12 build, on the 05/16 build now. Currently using the EAS Gamma Kernal as well, not sure if that comes with problems of it's own.
Will test accordingly with the unofficial kernel at some point.
Performance is amazing! This thing zips through all my apps and notifications like a champ.
On the LG UI (Bleh) it used to bog down so fast and get super slow.
Got like 120-ish apps running on the thing, no problem!
What Works
2.4 GHZ Tethering (Tested on iPad)
Bluetooth Tethering (Tested on iPad)
USB File Transfers
ADB Debugging and connected via USB
Ambient Display
Smart Lock
Bluetooth to my Honda Civic
(was weird, had to pair FROM the phone Not the car, works great)
Bluetooth to my Jabra Headset
Google Dialer
Android Messages
Netflix
Hulu
Plex
Chrome
Snapchat
Whatsapp
Facebook
Instagram
Tumblr
Twitter
Telegram
Google Assistant when opened from the home button or app icon
Fingerprint Unlock
Google Pay
Visual Voicemail using T-Mobile
(sometimes fails to connect, rarely)
CStark27's Google Camera
Safety Net and Magisk 16.0, Youtube Vanced
Powers my High Impedance Headphones, Not as loud as Stock LG
IR Remote function, using the "Peel" remote app off the play store
"Cast"ing to my Xbox One and other "Cast"able devices
What Doesn't
Speakerphone, and the Mic in general. Not as "Clear" as Stock.
Callers say I keep breaking up?
Wifi Calling wasn't that great a feature anyway but, I feel like the dialer or calling services on Stock were more normal sounding-ish?
Maybe I'll try that Magisk Low Mic Fix module some time...
Bluetooth clarity is pretty good for the most part.
5GHZ Wifi Tethering
Voice activating Google Assistant using "OK Google"
General Battery Drain concerns, still prefer LOS to stock.
Probably forgot some other stuff but super happy with all the improvements and hard work by the XDA community.
(Protip, update the ROM, optional kernel, GAPPs same options as before, AND then magisk. Had to redo it all when I killed Google Play by just flashing the ROM and Kernel, boy what a mistake that was! note: Using Google Dialer and some more google apps than nano.)
GAPPS Aroma 5/12 with the following options.
GoogleAssistant
BatteryUsage
CalculatorGoogle
CarrierServices
Chrome
ClockGoogle
CloudPrint
ContactsGoogle
DialerFramework
DialerGoogle
DMAgent
Docs
Drive
Duo
ExchangeGoogle
FaceDetect
FaceUnlock
Fitness
GCS
GooglePay
GoogleTTS
KeyboardGoogle
Maps
Messenger
Movies
PackageInstallerGoogle
PixelIcons
PixelLauncher
PlayGames
PrintServiceGoogle
ProjectFi
Sheets
Slides
Search
Speech
StorageManagerGoogle
Street
TagGoogle
Talkback
Translate
VRService
Wallpapers
WebViewGoogle
ClockStock
Email
KeyboardStock
Launcher
MMS
+Browser
+Gallery
+MMS
# End User's gapps-config
New version called "v0.9.9rc.zip" is up. Seeing how battery life goes for this one and performance. It is still missing partial panel update and USB OTG, haven't had too much spare time lately...
toastyp said:
Manually editing the mixer file to force high impedance doesn't work on AOSP roms. Only stock. The code is there for it to work automatically, but if your headphones don't have a resistance of higher than 50 ohms, than it won't activate. I haven't seen anyone test with high impedance headphones to actually see if it works though. Code is there, but still unknown if it works. I had no luck getting it to activate.
Click to expand...
Click to collapse
I think it is easily doable to fake the impedance with a sysfs argument to force high-Z mode. It is in my to-do things , unless someone beats me first... but I am also a little concerned that it could damage some headphones if too much current goes into them... mmmm
Which app is recommended to manage kernel settings?
Omar-Avelar said:
I think it is easily doable to fake the impedance with a sysfs argument to force high-Z mode. It is in my to-do things , unless someone beats me first... but I am also a little concerned that it could damage some headphones if too much current goes into them... mmmm
Click to expand...
Click to collapse
with my less than 50ohm headphones I can't get sound out of the dac when forcing the dac into into hi-fi (low) mode (by changing the. c file)
and when not forcing it just stays in bypass mode when checking via terminal with either it
tinymix | grep Es9
dmesg -w | grep -iC 0 es9
it appears some stuff from lge's sound stuff is missing in the kernel and I've been stuck at the no sound part for a while and once I fixed that I thought of using sysfs too
I'll update with what stock does and what lineage does, with and without my modifications, later my notes on this are scattered everywhere.... (also I'm not that experienced with programming so it's possible I did something wrong :silly: )
Dr_DjEnder said:
with my less than 50ohm headphones I can't get sound out of the dac when forcing the dac into into hi-fi (low) mode (by changing the. c file)
and when not forcing it just stays in bypass mode when checking via terminal with either it
tinymix | grep Es9
dmesg -w | grep -iC 0 es9
it appears some stuff from lge's sound stuff is missing in the kernel and I've been stuck at the no sound part for a while and once I fixed that I thought of using sysfs too
I'll update with what stock does and what lineage does, with and without my modifications, later my notes on this are scattered everywhere.... (also I'm not that experienced with programming so it's possible I did something wrong :silly: )
Click to expand...
Click to collapse
I'm interested in anything that might be missing for the Lineage kernel too, as I thought i got it all. Thanks.
Anyone here using VS995 after dirty santa exploit? When I run the AnyKernel installer with the vs995 version of the kernel, it says my device is not supported since after the exploit it shows up as a US996. When I try using the US996 version, bad things happen. I'm able to boot, but there's a lot of screen glitching once I'm at my home screen.
@x86cpu
I should have clarified the stuff I think is missing is for the DAC as they are called when the DAC is active and when the user skips tracks but regardless the files and changes are in:
and heres my commit of exactly what changed (its a bit messy): https://github.com/Devoark/android_kernel_lge_msm8996/commit/200e2d43c89bf98c2bd2c79f1767a60277234803
include/sound/apr_audio-v2.h
sound/soc/msm/qdsp6v2/lge_dsp_sound_effect.h
sound/soc/msm/qdsp6v2/lge_dsp_sound_mabl.h
sound/soc/msm/qdsp6v2/lge_dsp_sound_normalizer.h
sound/soc/msm/qdsp6v2/msm-audio-effects-q6-v2.c
sound/soc/msm/qdsp6v2/msm-compress-q6-v2.c
sound/soc/msm/qdsp6v2/q6asm.c
-----------------------------------------------------------------------------------------------
Right for the other Stuff
On stock lineage without any kernel mods this is the sequence for me with my <50ohm headphones
https://pastebin.com/JH8cS9Yc
Modified Lineage Kernel For the DAC
https://pastebin.com/uQgyHm3b
And stock LGE ROM DAC behavior :
https://pastebin.com/3XUNNLDq
The main problem with lineage's kernel is that it doesn't assign a headset type (1, 2, 3) for low, high-imp, and aux. Then the amp isnt being turned on, in es9218_startup, which is part of another set of functions that aren't called which is why i think the DAC isn't outputting sound, or at least would get us closer to a working Hi-Fi Mode. So by forcing it on and assigning the Headset a static value it allows the DAC to proceed into Hifi mode in bypass2hifi, and es9218_sabre_wcdon2bypass_put confirms that but now there is no sound output through the headphone jack (well its odd the first track that is played is in the es9218 bypass so there IS sound, but when you skip a track or start another audio stream it THEN puts the DAC in Hi-Fi mode then theres no sound :silly: )
Now the dac calls functions in LGE stock ROM that arent called in Lineage among them are :
Code:
lge_dsp_sound_offload_playback_number_put: current_be_id = 3, lge_effect_be_id = 3
es9218_headset_type_put (headset-type)
es9218_startup (called)
es9218_startup : state = BYPASS : goto HIFI !!
es9218_set_thd(): Headset Type = #
es9218_sabre_amp_start(): Headset Type = #
es9218_startup(): exit
es9218_pcm_hw_params(): entry , bps : 16 , rate : 48000 //////// (bit 16/24) and the sampling rate
es9218_pcm_hw_params(): Rev-B PCM Format Running
es9218_pcm_hw_params(): exit, ret=0
+++++++++++++++++++++++++++++++++++++
lge_dsp_sound_effect_allparam_put: value 1
+++++++++++++++++++++++++++++++++++++
+++++++++++++++++++++++++++++++++++++
lge_dsp_sound_mabl_devicespeaker_put: value 0
+++++++++++++++++++++++++++++++++++++
+++++++++++++++++++++++++++++++++++++
lge_dsp_sound_mabl_monoenable_put: value 0
+++++++++++++++++++++++++++++++++++++
Chances are I'm doing something wrong here but its where if gotten with this with the limited time I have anyone who wants to check out the commits they are here:
https://github.com/Devoark/android_kernel_lge_msm8996/commits/lineage-15.1st/sound
Ill continue to work on this when I can but I've mostly run out of ideas of what to do to call the missing functions and some clean up of what I've done I feel is really needed.
Dr_DjEnder said:
@x86cpu
I should have clarified the stuff I think is missing is for the DAC as they are called when the DAC is active and when the user skips tracks but regardless the files and changes are in:
and heres my commit of exactly what changed (its a bit messy): https://github.com/Devoark/android_kernel_lge_msm8996/commit/200e2d43c89bf98c2bd2c79f1767a60277234803
include/sound/apr_audio-v2.h
sound/soc/msm/qdsp6v2/lge_dsp_sound_effect.h
sound/soc/msm/qdsp6v2/lge_dsp_sound_mabl.h
sound/soc/msm/qdsp6v2/lge_dsp_sound_normalizer.h
sound/soc/msm/qdsp6v2/msm-audio-effects-q6-v2.c
sound/soc/msm/qdsp6v2/msm-compress-q6-v2.c
sound/soc/msm/qdsp6v2/q6asm.c
-----------------------------------------------------------------------------------------------
Right for the other Stuff
On stock lineage without any kernel mods this is the sequence for me with my <50ohm headphones
https://pastebin.com/JH8cS9Yc
Modified Lineage Kernel For the DAC
https://pastebin.com/uQgyHm3b
And stock LGE ROM DAC behavior :
https://pastebin.com/3XUNNLDq
The main problem with lineage's kernel is that it doesn't assign a headset type (1, 2, 3) for low, high-imp, and aux. Then the amp isnt being turned on, in es9218_startup, which is part of another set of functions that aren't called which is why i think the DAC isn't outputting sound, or at least would get us closer to a working Hi-Fi Mode. So by forcing it on and assigning the Headset a static value it allows the DAC to proceed into Hifi mode in bypass2hifi, and es9218_sabre_wcdon2bypass_put confirms that but now there is no sound output through the headphone jack (well its odd the first track that is played is in the es9218 bypass so there IS sound, but when you skip a track or start another audio stream it THEN puts the DAC in Hi-Fi mode then theres no sound :silly: )
Now the dac calls functions in LGE stock ROM that arent called in Lineage among them are :
Code:
lge_dsp_sound_offload_playback_number_put: current_be_id = 3, lge_effect_be_id = 3
es9218_headset_type_put (headset-type)
es9218_startup (called)
es9218_startup : state = BYPASS : goto HIFI !!
es9218_set_thd(): Headset Type = #
es9218_sabre_amp_start(): Headset Type = #
es9218_startup(): exit
es9218_pcm_hw_params(): entry , bps : 16 , rate : 48000 //////// (bit 16/24) and the sampling rate
es9218_pcm_hw_params(): Rev-B PCM Format Running
es9218_pcm_hw_params(): exit, ret=0
+++++++++++++++++++++++++++++++++++++
lge_dsp_sound_effect_allparam_put: value 1
+++++++++++++++++++++++++++++++++++++
+++++++++++++++++++++++++++++++++++++
lge_dsp_sound_mabl_devicespeaker_put: value 0
+++++++++++++++++++++++++++++++++++++
+++++++++++++++++++++++++++++++++++++
lge_dsp_sound_mabl_monoenable_put: value 0
+++++++++++++++++++++++++++++++++++++
Chances are I'm doing something wrong here but its where if gotten with this with the limited time I have anyone who wants to check out the commits they are here:
https://github.com/Devoark/android_kernel_lge_msm8996/commits/lineage-15.1st/sound
Ill continue to work on this when I can but I've mostly run out of ideas of what to do to call the missing functions and some clean up of what I've done I feel is really needed.
Click to expand...
Click to collapse
Exteremly helpful, I can see where the missing kernel code it. Quite a bit more than you have as well. But it does identify where and the CONFIG_ options missing. Thanks. I'll see what I can do to add to my UNOFFICIALS.
---------- Post added at 15:25 ---------- Previous post was at 15:05 ----------
Dr_DjEnder said:
@x86cpu
Chances are I'm doing something wrong here but its where if gotten with this with the limited time I have anyone who wants to check out the commits they are here:
https://github.com/Devoark/android_kernel_lge_msm8996/commits/lineage-15.1st/sound
Ill continue to work on this when I can but I've mostly run out of ideas of what to do to call the missing functions and some clean up of what I've done I feel is really needed.
Click to expand...
Click to collapse
What device do you have as I can build a test one for that device? (if us996 indicated if you had to use Dirty Santa or not).
I'm using a us996 US Cellular so I used dirty santa
Dr_DjEnder said:
I'm using a us996 US Cellular so I used dirty santa
Click to expand...
Click to collapse
I got the changes in, but need some tweaking to get it built correctly. LGs code sucks for this.