FORUMS
Remove All Ads from XDA

[KERNEL][GPL][4.2.2][July 10][b10] m_plus kernel for mako

5,458 posts
Thanks Meter: 5,829
 
Post Reply Email Thread
m_plus kernel for Nexus 4 (mako)!

Hi all, since _motley has been MIA of late and his work was my favorite kernel for the Nexus 4, I have decided to continue his work in his absense. As a result much of this thread will look very similar to _motley's original thread here: http://forum.xda-developers.com/show....php?t=2021437. I would like to personally thank _motley for his work and dedication to this project, I only hope I can keep his loyal users happy in his absence.

Disclaimer: As usual, I am not responsible for anything that may or may not happen to your device as a result of using this kernel or any other flashable zips posted by me in this thread.

Features
  • Highly customizable with scripts. See post #2 for all the tuning options.
  • Google 3.4 base. All stock features are of course supported (camera, NFC etc.)
  • Compiler optimizations (-O2 + others) - using 2012.12 Linaro toolchain
  • Full ramdisk install with init.d support for stock/AOSP (CM already has support, for stock you must install busybox!)
  • CPU Overclock steps 1.56, 1.62, and 1.67GHz (default freq is still stock on boot, OC is optional)
  • 304MHz lowest CPU freq step added with lower voltage than stock, since the device spends a lot of time at this frequency.
  • Safe UV by default for nominal, fast, and faster binned chips.
  • Voltage control - be careful to not save the setting on boot until you are 100% sure it is stable! (thanks faux123! + my tweaks)
  • In-kernel auto_hotplug (thanks to thalamus). I have added and exposed all the tuning parameters and a debug mode to userspace.
  • Customized in-kernel thermal solution smart scaling, dynamic polling, and configurable throttle temp.
  • Custom PowerHAL module (spam-free Android log from PowerHAL events)
  • Controllable touchboost frequency and duration
  • Gamma and Sound control (thanks faux123!)
  • Fsync control (3 modes)
  • USB Force Fast Charge
  • I/O schedulers - SIO(optimized), deadline (optimized), row, cfq, noop, and fiops
  • TCP Congestion Control (several choices available) - veno is the default
  • Governors - Interactive (default), OnDemand, PowerSave, Conservative
  • CIFS, NFS, NTFS r/w, TUN - built-in, no need for any kernel modules
  • Other misc patches and tweaks (see github link at the bottom of this post)
  • GPL compliant - source is kept up to date at github.com and released at the time the kernel is released to the public via this post. Demand that other devs do the same!

Requirements (please read carefully and visit the other dev threads as necessary)
  • Boot-loader must be unlocked and you must have a custom recovery installed (CWM or TWRP).
  • Have your ROM zip on your /sdcard so you can restore your whole ROM if necessary.
  • Do a complete backup using custom recovery so you can restore your boot.img and ROM if necessary!
  • System Tuner is recommended for monitoring/tuning the CPU, especially for voltage control. Other kernel apps like faux123's will likely work as well, but they have not been tested.
  • AOSP ROMs including stock - for init.d support, you must have a working busybox install in /system/xbin.

Installation
  • Check the requirements above and read release notes below for the build # you are installing for any extra instructions!
  • If coming from another kernel, read the instructions in red below and follow them before flashing.
  • Flash the the kernel zip using your custom recovery.
  • Optional: if you want to revert back to what you had, restore your backup of your boot.img in recovery. Another option for reset back to stock is to flash the stock reset zip above. For other custom ROMs, dirty flash your custom ROM in recovery to get your default kernel and ramdisk back.

If you have issues and are coming from another custom kernel or ROM, follow these instructions first before the install. Many custom kernels are changing the ramdisk or other binaries that require a reset before moving back to stock or another kernel.

Reset for Stock ROM - flash this reset package that includes the stock kernel, ramdisk, thermald, mpdecision, and PowerHAL binary. This can also be used if you are using the stock ROM and want to go back to stock.
Download - N4_422_stock_kernel_and_components.zip
MD5 - f801fc7702e29d85447e9b6fdc880549
Reset for any non-stock ROMs like CM, AOKP etc - dirty flash your current ROM or nightly zip then your gapps in recovery (just flash, no wiping). This will give you back your original ramdisk, kernel, and other binaries that other kernel devs may have tweaked, renamed, replaced etc.

Builds
Personal Request: If you plan to make unofficial builds with features not included in the builds posted by me, please don't link them in the thread, all this does is result in confusion especially if someone has a problem with something you have added, it is much easier for me to provide support if I know that everyone in the thread is running the same builds I am. If you want to make a kernel with these features, feel free to start another thread so that they can be discussed and supported as appropriate.

Current Buildbot Status:

Source: https://github.com/thracemerin/kernel-Nexus4

As with _motley's builds, the stable version will be a base build which includes the ramdisk and other component binaries to make the kernel work as expected, you will need to flash the stable version prior to flashing any experimental versions or something may not work as expected.

All files are now available from goo.im: http://goo.im/devs/thracemerin/mako/m_plus
Note: Due to goo.im file naming rules I had to change the name of the zip to m_plus from m+, this has no effect on the content, the ones on goo.im are identical to those that were on dev-host other than the names.

Change Logs
Note: The builds below are for 4.2.2 only, for the latest 4.3 alpha builds check the last few pages of the thread. *4.3 builds will appear on goo.im when they are closer to being official production builds.

This thread is for 4.2.X versions only, use the following threads for 4.3:
JW Builds: Thread not available yet, Alpha 3 is still here: http://forum.xda-developers.com/show...&postcount=860
JS Builds: http://forum.xda-developers.com/show....php?t=2385840

Build 10 (Exp) - July 15, 2013
Note: You must be on Build 1 or later. (Build 8 if you are on MIUI)
  • Various patches to the kernel to prevent out of bounds access to memory (see github for details)
  • Added sweep2wake, it is disabled by default, see post 2 for info (thanks to show-p1984)
  • Added a patch to fix some unusual behavior with the LEDs (thanks to CM)

Build 9 (Exp) - July 3, 2013
Note: You must be on Build 1 or later. (Build 8 if you are on MIUI)
  • Added the simple GPU governor for Qualcomm Adreno GPUs thanks to Faux123 (set as default, no need for the script required in the Alpha). Tunables explained in Post 2.
Build 8.1 (Exp) - June 20, 2013
Note: You must be on Build 1 or later. (Build 8 if you are on MIUI)
  • Actually reverted some of the msm_hsic patches because they seem to cause data drops (I only pretended I did in Build 8, oops )
Build 8 (Exp) - June 18, 2013
Note: You must be on Build 1 or later.
  • Reverted some of the msm_hsic patches because they seem to cause data drops
  • Now build with the Linaro 4.8.2.2013.06 toolchain
  • Switched the allocator from SLUB to SLAB because SLUB wouldn't boot when compiled with 4.8
  • Various fixes to allow building with 4.8
Build 7 (Exp) - May 26, 2013
Note: You must be on Build 1 or later.
goo.im seems to be a little flaky this afternoon, alternative downloads here: http://forum.xda-developers.com/show...&postcount=416
  • Patches to freezer from Colin Cross
  • More patches to workqueue from CAF
  • Patches to the cpufreq driver from CAF
  • Reverted lowest frequency step to 384MHz (See Post 3 for why)
  • Fixed board-mako-regulator.c to allow for UV to work (Warning: Reset your UV settings if you have UV below 850mV, if you flashed the previous alphas this is probably not necessary.)
  • Reset undervolting to stock from Google, just in case the above causes problems for new adopters (You still have full access to undervolt to 600mV if your chip can handle it)
  • Added the change pointed out by veyka here: http://forum.xda-developers.com/show...&postcount=380
  • Some more patches to the hsic controller that were in my other project but not this one.
Build 6 (Exp) - May 19, 2013
Note: You must be on Build 1 or later.
  • CAF changes to cpufreq
  • CAF changes to workqueues
Build 5 (Exp) - May 12, 2013
Note: You must be on Build 1 or later.
  • CAF patches to block.
  • CAF patches to the charging and battery management system.
  • CAF patches to the video driver.
Build 4 (Exp) - May 5, 2013
Note: You must be on Build 1 or later.
  • A few more sched patches from CAF
  • Patches to android lowmemory killer from CAF
  • Headphone poweramp controls (thanks to Faux123)
Build 3 (Exp) - May 3, 2013
Note: You must be on Build 1 or later.
  • Various sched patches that were in _motley's 4.2.1 kernel and not his 4.2.2 kernel
  • FIOPS i/o scheduler is back
  • 192mhz frequency step added (thanks to showp1984)
    Note: The ramdisk currently forces the minimum to 304mhz so i added an init.d script to force it to 192mhz so I didn't have to redo the ramdisk.
    I'll fix this in the next base build.
    If you still want to use 304mhz as your lowest step, see post 3 for details on how to do this.
    Note 2: The voltage is the same as the one _motley used for 304mhz for stability reasons, it will still use less power, but feel free to uV it if you like.
Build 2 (Exp) - April 30, 2013
Note: You must be on Build 1 or later.
  • Update ROW i/o scheduler to the latest from CAF, now default i/o scheduler
  • FIOPS i/o scheduler was removed because _motley added FIOPS and ROW as 1 commit and messing with ROW screwed it up.
  • Hardcode ROW magic values (thanks to franciscofranco & osm0sis)
  • Update interactive governor to the latest from CAF (it may be a little less aggressive)
  • Krait Retention (thanks to CAF, faux123)

Build 1 (Base) - April 29, 2013
  • Everything from _motley's b49 build up to this point.
  • Built with the linaro 2013.04 gcc-4.7 toolchain


Thanks
  • Google - For AOSP sources
  • LG - for building the N4
  • Qualcomm/CAF - for their updates to the N4 kernel
  • _motley - for all his work on this kernel
  • faux123 - patches included that were initially written by him
  • franciscofranco - patches included that were initially written by him
  • showp-1984 - patches included that were initially written by him
  • anyone else i've neglected to include, if you feel you deserve to be thanked by name by all means PM me
The Following 100 Users Say Thank You to thracemerin For This Useful Post: [ View ] Gift thracemerin Ad-Free
29th April 2013, 09:11 PM |#2  
thracemerin's Avatar
OP Senior Member
Flag Toronto
Thanks Meter: 5,829
 
Donate to Me
More
Tunables should be the same as _motley's kernel so I'm quoting him here:

(All the tunables that are discussed in _motley's thread http://forum.xda-developers.com/show....php?t=2021437 should work the same way on this kernel)

Quote:
Originally Posted by _motley

Setting custom RGB color settings via sysfs

This can be done from the adb shell on your PC, or any terminal app. If you change them, they will not persist after a reboot. However, you can set them in an init.d script if you found another color combination that you like better than the one I have used.

Code:
echo "255 255 255" > /sys/devices/platform/kcal_ctrl.0/kcal
echo 1 > /sys/devices/platform/kcal_ctrl.0/kcal_ctrl
Command 1 sets the color and Command 2 commits them. Stock is 255 255 255.

Setting custom Gamma settings via sysfs - Exp kernel build 31+ only - thanks to faux for sharing his code
Warning: changing these values can be potentially be dangerous to your display if you make a mistake. For those that feel comfortable with what they are doing and want to experiment, please report back and share your findings.

Important, please read!
  • There are ten digits in the string separated by one space
  • First digit is a checksum and is never stored. The checksum is simply the sum of the other 9 numbers. This is to make it harder to so the interface is respected and you are forced to think about what you are doing.

There are 3 sysfs interfaces for gamma, one for each color:
Code:
#!/system/bin/sh
# Show the current configuration and the checksum
cat /sys/devices/platform/mipi_lgit.1537/kgamma_red
cat /sys/devices/platform/mipi_lgit.1537/kgamma_green
cat /sys/devices/platform/mipi_lgit.1537/kgamma_blue
Update:
Recently molesarecoming started opening this up and showing us what the values can be used to adjust. Franco then suggested that the white and grays should be swapped in moles original work. So, for init.d values using this interface, we have the following "banks" if values if we agree with Franco on the swap of the whites and grays.
Code:
R: checksum, g_white, g_mids, g_black, 0, g_contrast, g_brightness, g_saturation, g_grey, 2
G: checksum, g_white, g_mids, g_black, 0, g_contrast, g_brightness, g_saturation, g_grey, 2
B: checksum, g_white, g_mids, g_black, 0, g_contrast, g_brightness, g_saturation, g_grey, 2
(the zero in position 5's and the 2's in position 10 are recommended to be left alone since they are currently unknowns)

Minus the checksum, the 27 values mirror the 3 color arrays (3 x 9 = 27) in the actual LG LCD driver. Minus the unknowns, we are left with 21 values. Note that every one of the variables can have their value tweaked by color (saturation for red, saturation for green etc.), however, it is recommended that you start with all the values of one type being the same and then tweak from there if you really want to fine tune.

You have a lot of power in your hands even without fine tuning. Many will argue that fine tuning isn't required. If you look at the stock settings by Google in post 2, they took advantage of fine tuning for whatever reason. Even though many don't like these settings by Google, it shows how flexible the interface can be.

Instructions:
1) Start with a preset config (LG or Google) as shown further below. This is a set of 3 lines, 10 numbers for each line.

2) Tweak columns for their values as above. For example, we tweak contrast and brightness as in faux's original app. We could also do the same for saturation, blacks, whites, grays etc.

Example: start with LG presets with numbers to adjust:
383 114 21 118 0 10 4 80 48 2
383 114 21 118 0 7 4 80 48 2
383 114 21 118 0 5 1 80 48 2

3) Now update the checksum in column 1 (first digit = sum of last 9 digits)

397 114 21 118 0 10 4 80 48 2
394 114 21 118 0 7 4 80 48 2
389 114 21 118 0 5 1 80 48 2

4) Create a script inside a text file - my recommendation for your first test

Code:
#!/system/bin/sh
# Set data color pro presets from shared Google spreadsheet (thanks user acer73!)
# Use LG presents as your starting values and then adjust columns 6 & 7 from the spreadsheet
echo "397 114 21 118 0 10 4 80 48 2" > /sys/devices/platform/mipi_lgit.1537/kgamma_red
echo "394 114 21 118 0 7 4 80 48 2" > /sys/devices/platform/mipi_lgit.1537/kgamma_green
echo "389 114 21 118 0 5 1 80 48 2" > /sys/devices/platform/mipi_lgit.1537/kgamma_blue

#Set the complimentary RGB values for this calibration
echo "248 248 248" > /sys/devices/platform/kcal_ctrl.0/kcal
echo 1 > /sys/devices/platform/kcal_ctrl.0/kcal_ctrl
5) Run the script (or you can echo each line manually to test from adb if you prefer).

6) Turn the screen off and on for the gamma change to take effect.

7) Check the dmesg output for any clues and to see the output of the result.

8) Place the script into your /system/etc/init.d/ folder (or equivalent) for a permanent color change!

Screen refresh (added in b37) - this should only be called by apps or scripts while adjusting and testing colors "live" with the motley or faux sysfs interface. It should NOT be implemented on startup via init.d or by apps since it will compete with the normal power on process.

Code:
echo 1 > /sys/devices/platform/mipi_lgit.1537/refresh_screen

Presets:

Code:
#!/system/bin/sh
# Set LG presets (motley stock) - i.e. popular partial revert of Google's tweaks just before release
echo "383 114 21 118 0 0 0 80 48 2" > /sys/devices/platform/mipi_lgit.1537/kgamma_red
echo "383 114 21 118 0 0 0 80 48 2" > /sys/devices/platform/mipi_lgit.1537/kgamma_green
echo "383 114 21 118 0 0 0 80 48 2" > /sys/devices/platform/mipi_lgit.1537/kgamma_blue

Code:
#!/system/bin/sh
# Set stock Google presets (from kernel source code)
echo "332 64 68 118 1 0 0 48 32 1" > /sys/devices/platform/mipi_lgit.1537/kgamma_red
echo "332 64 68 118 1 0 0 48 32 1" > /sys/devices/platform/mipi_lgit.1537/kgamma_green
echo "364 32 35 116 0 31 16 80 51 3" > /sys/devices/platform/mipi_lgit.1537/kgamma_blue
Spreadsheet with shared settings
https://docs.google.com/spreadsheet/...rX1Rya0E#gid=0


FSYNC Control

Notes: I thought about combining these options, but many kernel apps already support these two options. So, I have them both and they can be controlled in combination to give us the 3 modes. If you set fsync_enabled = 0 it will be OFF regardless of how Dyn_fsync_active is set.

3 Modes:

Dynamic (default in b35 and higher)- fsync is asynchronous when screen is on, when screen is off it is committed synchronously
dynamic fsync ON
fsync ON
Code:
echo 1 > /sys/kernel/dyn_fsync/Dyn_fsync_active
echo 1 > /sys/class/misc/fsynccontrol/fsync_enabled
Off (best performance, less safe) - fsync is always asynchronous (b32 and prior builds)
dynamic fsync OFF
fsync OFF
Code:
echo 0 > /sys/kernel/dyn_fsync/Dyn_fsync_active
echo 0 > /sys/class/misc/fsynccontrol/fsync_enabled
Stock (safest) - fsync is always committed synchronously
dynamic fsync OFF
fsync ON
Code:
echo 0 > /sys/kernel/dyn_fsync/Dyn_fsync_active
echo 1 > /sys/class/misc/fsynccontrol/fsync_enabled
There is a lot of info out there on fsync, that will not be discussed here. I have run fsync off on several devices for awhile now and haven't experienced any issues. If you are using a device that is not stable and crashes alot, I recommend enabling it via init.d or script manager on boot. Hopefully your N4 is as stable as is mine.

USB Force Fast Charge

You can turn it on with popular apps (like Trickster MOD) that support the common sysfs toggle as shown below.

If you don't like it or don't want to use it, it is off by default.

Turn ON:
Code:
echo 1 > /sys/kernel/fast_charge/force_fast_charge
Turn OFF:
Code:
echo 0 > /sys/kernel/fast_charge/force_fast_charge
Notes:
  • When it is ON, you will not be able to connect your phone to your PC (adb, mtp etc.). This is expected behavior.
  • To start charging: turn fast charge ON, plug the USB cable into your PC, and charge up.
  • To stop charging: unplug the USB cable and turn fast charge OFF. Now you can plug back into your PC for normal trickle charging, adb/mtp etc.
  • Tip: if you see it connect to your PC (media device or adb), it isn't working. Unplug the cable, wait a couple seconds and plug it in again.

Boostpulse control - Experimental build only

Trickster MOD works great to play with these.

How long does it boost when Android senses touch? (in b10 and b14 it is above_hispeed_delay)
Code:
/sys/devices/system/cpu/cpufreq/interactive/boostpulse_duration
What freq does it boost to?
Code:
/sys/devices/system/cpu/cpufreq/interactive/hispeed_freq
Turn touchboost OFF/ON (in b10 and b14 only)
Code:
/sys/devices/system/cpu/cpufreq/interactive/input_boost
Thermal Throttling and Hotplug Control - Experimental build only
Warning: these do not have to be changed from the defaults and could potentially be dangerous if you make a mistake. For those that know what they are doing and want to experiment with settings, scripts etc. please report back your findings.

msm_thermal:

Throttle temp in C. Default is 70, valid range is 45 to 80 (recommend to not go over 75):
Code:
/sys/module/msm_thermal/parameters/throttle_temp
Minimum freq used in throttle down before returning to max, default is 7 = 1.13GHz. Range is 4 to 8 (810Mhz to 1.24GHz)
This is the index in the frequency table as seen in Trickster MOD, System Tuner etc. It is zero based (i.e. 304MHz is zero).
Code:
/sys/module/msm_thermal/parameters/min_freq_index
Turn on thermal debugging so you can see what is happening in the kernel log:
Code:
/sys/module/msm_thermal/parameters/thermal_debug
auto_hotplug:
Load based hotplugging parameters. I have taken _thalamus' base (thanks!) and have exposed most of the tuning parameters to userspace.

Turn off/on hot_plug debugging Y/N, default N, this spams the kernel log like crazy, turn on only when troubleshooting/testing
Code:
/sys/module/auto_hotplug/parameters/debug
Load at which a CPU is taken offline, 40-125, default 80:
Code:
/sys/module/auto_hotplug/parameters/disable_load_threshold
Load at which an extra CPU is put online, 130-250, default 200:
Code:
/sys/module/auto_hotplug/parameters/enable_load_threshold
Load at which all CPU's are enabled, 270-550, default is 400 (or 100 x number of cores):
Code:
/sys/module/auto_hotplug/parameters/enable_all_load_threshold
Sample rate in milliseconds, converted to jiffies at runtime, 10-50ms, default 20:
Code:
/sys/module/auto_hotplug/parameters/min_sampling_rate
Number of samples in the circular buffer, 5-50, default 10 (more samples = less aggressive; less samples = more aggressive):
Code:
/sys/module/auto_hotplug/parameters/sampling_periods
Maximum number of cores online (regardless of load) when screen is on, 1-4, default 4 (tune down for battery savings):
Code:
/sys/module/auto_hotplug/parameters/max_online_cpus
Minimum number of cores online (regardless of load) when screen is on, 1-4, default 1 (tune up for performance/bench-marking):
Code:
/sys/module/auto_hotplug/parameters/min_online_cpus

Vibration Intensity

You can also use Trickster MOD to set this.

Example increase intensity:
Code:
echo "90" > /sys/class/timed_output/vibrator/amp
To go back to stock:
Code:
echo "70" > /sys/class/timed_output/vibrator/amp
Why are the base voltage tables different on some phones

What CPU do you have? Nominal, Fast, Faster ...or Slow

The phones with the lower default voltage values use the "fast" or "faster" frequency table, consider yourself lucky. This explains why some can't UV as much as others since they are starting with lower mV's to start. These are built in factory tolerances that depend upon the binning of your chip. I am familiar with the same thing in the tegra3 world where I have had more experience. So, don't worry as this is commonly done in this industry. Hopefully folks don't go freaking out because they have a nominal chip like I do. It's probably good for a dev to have a nominal chip so we can better honor the limits.

http://en.wikipedia.org/wiki/Product_binning

How do I tell what I have?
If you boot up your phone fresh and look at the dmesg output (kernel log) while the messages are still there, you will find one of the following output messages where it selects it's frequency plan depending on the binning of the chip.

Code:
adb shell dmesg | grep PVS
acpuclk-8064 acpuclk-8064: ACPU PVS: Nominal
-or-
acpuclk-8064 acpuclk-8064: ACPU PVS: Fast
-or-
acpuclk-8064 acpuclk-8064: ACPU PVS: Faster
-or-
acpuclk-8064 acpuclk-8064: ACPU PVS: Slow

I have tweaked all the frequency tables nominal, fast, and faster (as well as slow to compensate for the lower freq) to keep them similarly scaled relative to stock. If you don't like the safe defaults (already UV'ed), then use voltage control and come up with your own preferred values.

C State Information
(thanks to faux123 - more info here: https://plus.google.com/109078966818...ts/9R8fjQdHDXD)
faux123 recommends C0, C1 and C3 here: http://forum.xda-developers.com/show...postcount=9775
C0 (WFI) - Shallowest Sleep (default enabled)
Code:
enable: echo 1 > /sys/module/pm_8x60/modes/cpu0/wfi/idle_enabled
disable: echo 0 > /sys/module/pm_8x60/modes/cpu0/wfi/idle_enabled
C1 (Retention) - slightly deeper sleep
Code:
enable: echo 1 > /sys/module/pm_8x60/modes/cpu0/retention/idle_enabled
disable: echo 0 > /sys/module/pm_8x60/modes/cpu0/retention/idle_enabled
C2 (Stand Alone Power Collapse) - deeper sleep
Code:
enable: echo 1 > /sys/module/pm_8x60/modes/cpu0/standalone_power_collapse/idle_enabled
disable: echo 0 > /sys/module/pm_8x60/modes/cpu0/standalone_power_collapse/idle_enabled
C3 (Power Collapse) - deepest sleep
Code:
enable: echo 1 > /sys/module/pm_8x60/modes/cpu0/power_collapse/idle_enabled
disable: echo 0 > /sys/module/pm_8x60/modes/cpu0/power_collapse/idle_enabled
Simple GPU Governor Tunables
Code:
/sys/module/msm_kgsl_core/parameters/simple_laziness
Laziness: Adjusts the number of times the governor skips ramp down requests. (Higher = better performance, higher battery drain)
Code:
/sys/module/msm_kgsl_core/parameters/simple_ramp_threshold
Threshold: Adjusts the threshold to ramp up or down the GPU frequencies. (Lower = better performance, higher battery drain)

To enable sweep2wake:
Code:
echo 1 > /sys/android_touch/sweep2wake
The Following 18 Users Say Thank You to thracemerin For This Useful Post: [ View ] Gift thracemerin Ad-Free
29th April 2013, 09:11 PM |#3  
thracemerin's Avatar
OP Senior Member
Flag Toronto
Thanks Meter: 5,829
 
Donate to Me
More
Frequently Asked Questions

Q: You gave us 192Mhz, now you removed it and set 304Mhz back to 384Mhz, why?
A: Good question, there had always been some speculation in this thread and others that frequencies below 384Mhz were not in fact being set correctly, show-p1984 managed to run his device at 27Mhz with no stability issues (this should be impossible) so we did some quick and rather unscientific benchmarking in this thread and found that there didn't seem to be any difference in CPU performance between 192Mhz and 304Mhz (and there should have been), I then speculated that 304Mhz was also not being set, after a little more unscientific benchmarking I determined that there was no difference in performance from 304Mhz to 384Mhz either, so based on this I don't see any reason to allow these frequencies.

Q: I don't want to use the 192mhz frequency, how can I disable it? (Build 3-6)
A: One of the four options below will fix it:
  1. You can delete my script, it's located at /system/etc/init.d/01cpu and reboot, this will set you back to 304mhz minimum.
  2. You can remove it from the zip file (same location in the zip hierarchy) before you flash.
  3. You can use your favorite kernel tuner (trickster, fauxclock, etc...) to switch the minimum frequency back to 304mhz and set it on boot.
  4. You can change the /system/etc/init.d/01cpu script to set whatever minimum frequency you want (it has to be a valid one from the table)

Q: If the 192mhz and 304mhz steps use the same undervolt settings, how can 192mhz use less power?
A: The formula for power consumption is: P = f * c * V ^ 2
Where: P = power consumption, f = frequency, c = capacitance and V = voltage
So: since c is constant in this case, and we'll assume you've used the lowest UV possible (600mV)
At 304mhz: P = 304 * c * 600 ^ 2
At 192mhz: P = 192 * c * 600 ^ 2
This means that 304mhz uses approximately 1.58 times more power than 192mhz over the same time.

Q: There are a bunch of fixes for the delayed notification issues in various threads, what should the settings be for this kernel?
A: The following values should be set in your /system/etc/wifi/WNCSS_qcom_cfg.ini (depending on your ROM you may have different values), these are the Google stock values and appropriate for this kernel.
Code:
McastBcastFilter=3
HostArpOffload=0
gEnableSuspend=3
You can set these values by flashing this: wlan_revert.zip - MD5 - 381013687035626bcb1cbaf609ea4311

Q: Does this kernel include the ARP offload patch?
A: No, and for those of you following my other thread here: http://forum.xda-developers.com/show....php?t=2102986 you will know that there is an issue where our WiFi chip responds to ARP requests with a bad MAC address during deep sleep, this results in problems with direct connect (WiFi direct, AirDroid, etc...) and can cause issues with certain types of routers and networks that do not cache ARP addresses for long, as a result I no longer use it in my other kernel either. I am using a different solution which solves the problem for me and many others but has a slight battery life hit, I will post a flashable zip to modify the binaries to include this fix at a later time, but for now if you wish to include this fix do the following.

Code:
open /system/etc/wifi/WNCSS_qcom_cfg.ini in your favorite file editor
find the line that currently reads gEnableSuspend=3
change the line to read gEnableSuspend=2
save the file
reboot your device.
Q: I flashed this kernel and my battery life sucks! WTF?
A: Clearly I didn't design this kernel to drain your battery (nor did _motley) and in my experience most battery drain issues are app related and not kernel related. In order to help me help you solve the problem, please download Better Battery Stats either from the Play Store (costs money, but I strongly encourage supporting the dev) or the free version from XDA and provide me with a dump file for a few hours of use so I can see what is going on with your device, if you don't do this I will assume the battery drain is your fault and will ignore your complaint.

Q: Can you add feature x from kernel y?
A: Maybe, I'm not going to take this kernel and stuff it full of every single idea anyone has while lying in bed trying to fall asleep, but if the feature seems like something that most would use and it's in a reasonable state of working (ie. not something that someone else just started working on) then I will consider adding it, absolutely no promises in this regard.

Q: I got a random reboot, SOD, other bug that must be kernel related, what do I do?
A: Provide me with appropriate logs (dmesg, logcat, last_kmsg (see my sig)) and instructions on how you caused this if possible, if I can't reproduce the issue and I can't see it in the logs there is nothing I can do. Be as detailed about what you were doing at the time it happened, more information is always better than less.

Q: If _motley comes back what will happen with this project?
A: Well, I don't want to step on any toes here, this was originally _motley's work, what happens to it long term if he returns will ultimately be up to him. If he wants to continue from where he left off and merge his own changes beyond b49, I may keep going as a separate project, if he wants to fork me and continue from the point I'm at when he returns that's ok with me too and I'd probably stop if that were the case, but we're speaking in hypotheticals here, anything is possible.

Q: Touch control doesn't work! Why not?
A: Touch control requires a module that is compiled by the author and provided as a pre-compiled binary. I'm not specifically looking to break it's functionality, but changes I make may cause it to stop working at any time between releases, the only way to get this fixed is to speak to the author of the addon and have him recompile the module. If he needs my assistance with anything specific to this kernel, I will do my best to help him out.
The Following 15 Users Say Thank You to thracemerin For This Useful Post: [ View ] Gift thracemerin Ad-Free
29th April 2013, 09:12 PM |#4  
thracemerin's Avatar
OP Senior Member
Flag Toronto
Thanks Meter: 5,829
 
Donate to Me
More
Pre-release (Alpha) Builds

These builds are the latest builds produced by the buildbot from the wip branch.

WARNING: These builds should be considered alpha, may contain a lot of bugs, may be unstable, and may be partially or completely non-functional. That being said, I am usually running these builds so if they are really badly broken I'll remove them ASAP.

http://goo.im/devs/thracemerin/mako/m_plus/wip

Current Buildbot Status:


Current Alpha: None, use Build 10!

What's changed:
The Following 17 Users Say Thank You to thracemerin For This Useful Post: [ View ] Gift thracemerin Ad-Free
29th April 2013, 09:23 PM |#5  
gianton's Avatar
Recognized Contributor
Flag Thessaloniki
Thanks Meter: 9,810
 
Donate to Me
More
Thanks for continuing Motleys kernel, waiting for links to download and flash.
29th April 2013, 09:36 PM |#6  
thracemerin's Avatar
OP Senior Member
Flag Toronto
Thanks Meter: 5,829
 
Donate to Me
More
Build 1 is up, happy flashing
The Following 4 Users Say Thank You to thracemerin For This Useful Post: [ View ] Gift thracemerin Ad-Free
29th April 2013, 09:45 PM |#7  
Senior Member
Thanks Meter: 389
 
More
Thank you very much for the kernel, I'm glad to see the motley's great work doesn't get forgotten.

PS: a benchmark for the ones that like it, stock settings and sabermod rom.
29th April 2013, 09:48 PM |#8  
Senior Member
Thanks Meter: 177
 
More
I hope _motley is alright. Thank you for continuing to develop this great kernel in his absence.

Will you be including the new Prima drivers and retention patches introduced by kszaq to fix some of the wifi problems? I know it's not a solution for everyone, but I personally thought it worked well with no battery hit and some others seem to agree.

Anyway, thank you for your work and good luck with _m+ .
29th April 2013, 09:54 PM |#9  
thracemerin's Avatar
OP Senior Member
Flag Toronto
Thanks Meter: 5,829
 
Donate to Me
More
Quote:
Originally Posted by mko000

I hope _motley is alright. Thank you for continuing to develop this great kernel in his absence.

Will you be including the new Prima drivers and retention patches introduced by kszaq to fix some of the wifi problems? I know it's not a solution for everyone, but I personally thought it worked well with no battery hit and some others seem to agree.

Anyway, thank you for your work and good luck with _m+ .

Krait retention, yes.

Prima/ARP Offload, not right now, there is a workaround and better explanation for why in post 3, I'll continue to work on it in my other thread, if I get to a fully working solution, then absolutely. The current issue with the Prima driver makes my phone unusable for something I do on a daily basis which is why I will not do it currently (I want to be able to use this kernel as my daily driver).
The Following 4 Users Say Thank You to thracemerin For This Useful Post: [ View ] Gift thracemerin Ad-Free
29th April 2013, 09:56 PM |#10  
gianton's Avatar
Recognized Contributor
Flag Thessaloniki
Thanks Meter: 9,810
 
Donate to Me
More
Flashed the CM build, all fine thanks! Felt the smoothness of Motleys kernel again.

Click image for larger version

Name:	uploadfromtaptalk1367268949855.jpg
Views:	5163
Size:	47.7 KB
ID:	1922957 Click image for larger version

Name:	uploadfromtaptalk1367268970465.jpg
Views:	5098
Size:	65.3 KB
ID:	1922959
29th April 2013, 11:37 PM |#11  
veyka's Avatar
Retired Forum Moderator
Flag Norfolk
Thanks Meter: 2,696
 
More
Very nice! Um, I took a look at your git, but i couldn't work out what you added over b49 heh, mind giving a quick summery?

Sent via Nexus 4
Post Reply Subscribe to Thread

Tags
kernel, m_plus, nexus 4, _m+, _motley

Guest Quick Reply (no urls or BBcode)
Message:
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes