[KERNEL][Mar 10][b49] _motley kernel for the N4 (add faux sound control)

_motley kernel for the Nexus 4

Disclaimer: You know the gig...I am not responsible for damaging your device or voiding your warranty. Play at your own risk!

ROM devs/cooks: If you want to use this kernel in your ROM, I am fine with that, but please include a "thanks" AND a link back to this thread. Thanks!

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

1. Check the requirements above and read release notes below for the build # you are installing for any extra instructions!
2. If coming from another kernel, read the instructions in red below and follow them before flashing.
3. Flash the the kernel zip using your custom recovery.
4. 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.
4.2.1 View attachment N4_421_stock_kernel_and_components.zip
4.2.2 View attachment N4_422_stock_kernel_and_components.zip
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

Build 49 - 2013-03-10 (stable) - Android 4.2.2

• Added faux123's "Sound Control: Sound control for WCD93xx codec" for testing (thanks!)

AnyKernel UPDATE ONLY - must already be on b37 or higher first! Anykernel is the same for both Stock/AOSP and CM 10.1
View attachment motley_anykernel_422_nexus_4_build_49.zip

Build 48 - 2013-03-09 (stable) - Android 4.2.2

• Turned off touchscreen accuracy filter by default and allow users to turn them on via the same interface (see git for all the details). In the commit comments on github, I also document how the stock kernel already allows these adjustments, but now we have easier control of them individually. Let me know if this fixes issues for those having them.
• Reverted back the changes for notification delays. They didn't fix anything. If you swapped out your prime WiFi INI file, I recommend changing back to stock for now.

AnyKernel UPDATE ONLY - must already be on b37 or higher first! Anykernel is the same for both Stock/AOSP and CM 10.1
View attachment motley_anykernel_422_nexus_4_build_48.zip

Build 44 - 2013-03-04 (beta) - Android 4.2.2

• Updated touchscreen Accuracy Filter Control with franco's cleanup patch. Reverting back to a single threaded workqueue should hopefully help fix the touchscreen issues some reported.
• Per Google's kernel devs, we should not have CONFIG_NF_CONNTRACK_SIP/CONFIG_NF_NAT_SIP turned on in the config. Testing is under way (introduced in b43 posted in the thread).

AnyKernel UPDATE ONLY - must already be on b37 or higher first! Anykernel is the same for both Stock/AOSP and CM 10.1
View attachment motley_anykernel_422_nexus_4_build_44.zip

Build 42 - 2013-03-02 (beta) - Android 4.2.2

• Added faux123 Speaker Amp Control by request for testing (thx!)
• Added franciscofranco touchscreen Accuracy Filter Control by request for testing (thx!)
• Reverted "Mako Gamma: allow values greater than 31 for array positions 5 and 6". Brought to faux's attention and his app is now fixed, so this is no longer needed. Values should be capped at 31 like we have always known.

AnyKernel UPDATE ONLY - must already be on b37 or higher first! Anykernel is the same for both Stock/AOSP and CM 10.1
View attachment motley_anykernel_422_nexus_4_build_42.zip

Build 40 - 2013-02-25 (stable) - Android 4.2.2

• Added upstream smp patches from 4.2.1 back into 4.2.2 build
• Added optimized ARM RWSEM algorithm backin into 4.2.2 build

AnyKernel UPDATE ONLY - must be on b37 or higher first! Anykernel is the same for both Stock/AOSP and CM 10.1
View attachment motley_anykernel_422_nexus_4_build_40.zip

Build 39 - 2013-02-20 (stable) - Android 4.2.2

• Added usb/hsic patches into 4.2.2 build
• Turned off prima debugging in 4.2.2 build

AnyKernel UPDATE ONLY - must be on b37 or higher first! Anykernel is the same for both Stock/AOSP and CM 10.1
View attachment motley_anykernel_422_nexus_4_build_39.zip

Build 38 - 2013-02-17 (stable) - Android 4.2.2

• Loosen up validation for gamma interface to allow values greater than 31 for array positions 5 and 6.

AnyKernel UPDATE ONLY - must be on b37 or higher first! Anykernel is the same for both Stock/AOSP and CM 10.1
View attachment motley_anykernel_422_nexus_4_build_38.zip

Build 37 - 2013-02-17 (stable) - First build with 4.2.2 support added

• 4.2.2 - rebased upon android-msm-mako-3.4-jb-mr1.1, ramdisk updated etc.
• All major features added back in, but I have left a few patches out (hsic etc.) so we can evaluate before adding them back in.
• Back to b32 colors, from here out you are on your own using the gamma interface of choice.
• Fixed issue where fsync was still on like in previous builds. Dynamic fsync is now the default (see post 2)
• Added franco gamma interface, so the kernel can support all popular interfaces until/if a standard interface is adopted.
• Added refresh_screen sysfs (see post 2). This should only be called by apps or scripts while adjusting colors "live" with the motley or faux interface and NOT implemented on startup via init.d or apps since it will compete with the normal power on process and the colors will be set twice.
• Use a 4.2.2 ROM and binaries. I will not troubleshoot any issues if you use this on 4.2.1 ROMs and binaries

Stock/AOSP with init.d support: View attachment motley_422_n4_exp_build_37_initd.zip
-or-
CM 10.1: View attachment motley_422_build_37_CM.zip

Previous builds and release notes:


Inert PowerHAL library
This is a shell PowerHAL library that allows Android to function and stops the input boostpulse requests
(same as included in b8 and b10 Exp kernels).It was originally released for testing b12, but can be used in other builds. Personally, I would only flash the "inert PowerHAL" if you are using OnDemand full-time and no longer using interactive (set on boot), OR if you are using interactive and want to completely remove the boostpulse requests coming from Android. In the later case, UI performance may be sacrificed a bit for better battery.
View attachment motley_inert_powerhal.zip

Mirror site - thanks tlongren! - will typically be updated within a day after I post
http://www.longren.org/nexus4/motley

Git repo:
https://github.com/motley-git/kernel-Nexus4

(http://www.gnu.org/copyleft/gpl.html)

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.


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:

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.
(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


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.



Presets:






Spreadsheet with shared settings
https://docs.google.com/spreadsheet/ccc?key=0AoDp2qRui0u0dGE4T2gtSDBTRHVFSldPS2RrX1Rya0E#gid=0


FSYNC Control

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

3 Modes:

Dynamic (default in b35 and higher)- fsync is asynchronous when screen is on, when screen is off it is committed synchronously
dynamic fsync ON
fsync ON

Off (best performance, less safe) - fsync is always asynchronous (b32 and prior builds)
dynamic fsync OFF
fsync OFF

Stock (safest) - fsync is always committed synchronously
dynamic fsync OFF
fsync ON
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:

Turn OFF:

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)

What freq does it boost to?

Turn touchboost OFF/ON (in b10 and b14 only)

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):

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).

Turn on thermal debugging so you can see what is happening in the kernel log:

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

Load at which a CPU is taken offline, 40-125, default 80:

Load at which an extra CPU is put online, 130-250, default 200:

Load at which all CPU's are enabled, 270-550, default is 400 (or 100 x number of cores):

Sample rate in milliseconds, converted to jiffies at runtime, 10-50ms, default 20:

Number of samples in the circular buffer, 5-50, default 10 (more samples = less aggressive; less samples = more aggressive):

Maximum number of cores online (regardless of load) when screen is on, 1-4, default 4 (tune down for battery savings):

Minimum number of cores online (regardless of load) when screen is on, 1-4, default 1 (tune up for performance/bench-marking):


Vibration Intensity

You can also use Trickster MOD to set this.

Example increase intensity:

To go back to stock:

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.


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.

If there is interest I'd be willing to do some updates on this kernel (or at least publish the ones I already did) in _motley's absence, until he comes back at least.

Sent from my Nexus 7 using Tapatalk 2

Would anyone want to test yet another attempt to fix delayed notifications bug? Yesterday Qualcomm released Prima driver v3.2.2.2 on CAF's git, so I decided I would give it a try. The previous fixes we tested relied on merging only one patch from their git and I thought it wasn't enough, so I merged the whole driver. I tested it overnight and got promising results, so I thought you may also want to give it a try.

One thing you need to know is that the driver also needs new firmware which is on ROM side. There are also some new values in WiFi configuration file. Default values from CAF differ from what we have for our N4s, so I copied the ones that we had and left all new parameters to their default values, except for the one that allows controlling Power Saving mode from Android (I switched it on). I also changed McastBcastFilter value to 3.

I provide you a flashable anyKernel zip with new firmware included. All you need to do is to flash this one file (motley_anykernel_422_nexus_4_custom_build_prima_3.2.2.2.zip) over any Motley's kernel and test away. It is based on b49 with some customizations to my taste (sorry, no OC, CIFS and NTFS!). You can find the source code on my GitHub.

If you want to go back to original Motley's kernel, you would need to flash original firmware (it's in prima_original_n4_firmware.zip) and then any kernel of your choice.

Please let me know about your battery life on this and what's your qcom_rx_wakelock, especially on busy networks.

Edit: You can download patched kernel from here.

Edit 2: I noticed that the "reset" zip was badly derped. If you want to go back to original WiFi firmware, please reflash your ROM (no wipe needed!).

There you go: Motley's b49 kernel with Prima v3.2.2.2 drivers and Retention patches. I've also attached a reset kernel in case anyone wants to go back to stock Prima drivers (it includes stock kernel).