[Kernel][19.06.2024][4.14.336][A12][A13] Kirisakura 9.2.0 for Pixel 4/XL aka FLORAL (2024)

Update to 2.1.0

Hey guys and girls,

So here´s the next update. I guess you all have noticed by now, that I try to not constantly update the kernel, immediately for every single new commit that makes its way into the kernel.
This has mainly two reasons. I want the kernel to be tested thoroughly. I´m not trying to develop a very close to stock kernel, but I still want it to be stable. Testing needs time and some issues only creep up after a while.
The other reason I´m short on time lately and updating the thread takes time.

Short explanation on some logs I examined, the new CAF-Merge and the December update from Google.

Regarding the logs. I further dug through the source and while testing we stumbled upon a few things.

I took a look at the log @rickysidhu_ send me a few days ago. It´s unfortunately caused by a warning that´s also present in the stock kernel on the Pixel 3 and I saw the same on a log from one of my testers. @rickysidhu_ confirmed it happens on EX-Kernel on the Pixel 4 as well, which is very close to stock. So I´m sure it isn´t something I introduced.
I never encountered the warning or the following reboot on my own device, so it might be something network related tied to a very specific scenario or some sequence of events.
I´m aware of the issue and still looking for a solution.

problem number two is connected to another issue one of my testers run into.
Looking at the log I found this commit from Google present in the stock kernel related to a problem where the device fails to switch between suspend and resume.
It essentially forces a kernel panic, when the device is stuck between suspend and resume. This issue appears to be quite rare, but it happens more frequently for some people.
It seems to me Google had no other choice, than to implement that non-desirable "workaround" for the issue.
If this happens the radar chip and some thermal driver related code seems to be at play.

If you encounter a reboot, immediately go to sys/fs/pstore, zip up the contents and upload them here for me. Give all details about your setup and I will look at the logs.

This brings us to the December update from Google.
Google now enforces warm reboots on thermal related shutdowns. That means logs are kept intact in case a random reboot happens.
I think this is directly related to the suspend/resume issue described above. So google is aware of the issue and seems to work on it.

On the good side, they worked on the face-detection driver and made it work more quickly and efficiently.
Google maxed out PCIe speeds, and fixed an encryption related problem which both impacted file system performance as well
Follow this link for an androbench taken on the December update

There are many other little improvements from Google in the December drop, so the wait was definitely worth it for me.

The last point is reserved for some of my own changes.

The nextgen-CAF tag is now merged to the most recent state to what´s available on the CAF-repos. This second merge brought again many fixes from CAF-Upstream and I can tell the kernel runs better than before from the logs and usage.
I was able to revert a few "emergency" google fixes in the source and replace them again with CAF-Upstream solutions. Some of these reverts seemed over a year old and seemingly forgotten by Google. This might have been the issue for some deep sleep issues. I didn´t encounter a single instance where my phone was left with broken deepsleep for over 2 weeks now.
Additionally I merged an upstream solution for PM/Wakeup driver from kernel/common, which reduces unnecessary logspam and also improves sleeping behaviour/operation.
Since there are some problems with sleep/suspend/resume behaviour on the Pixel 4, I wanted to give this a few weeks before it gets in the release kernel.
Alongside these commits, the Google and CAF drivers which make use of the upstream PM/Wakeup solution, were updated to work properly.

The CAF-Tag brought many improvments to SOC-related driver and EAS- Implementation as well. I certainly haven´t noticed any negative performance issues for now. Hundreds of files were updated. Take a look at github if you´re interested in detailed changes.

Removal of kernel side enforced HBM.

There are currently two ways to enable HBM on this kernel, either use the kernel side enforced HBM (toggleable in EXKM) or enable the hidden factory disabled HBM from Google.

After some Pixel 4 owners reported issues with the HBM toggle in EXKM, I decided to remove this implementation from the kernel for now.
The Pixel 4 and the Pixel 4XL share different BL values. Which made toggling HBM on the Pixel 4 reset the brightness to 1/4 of maximal brightness.
The HBM mode enforced by the kernel makes the display drop to 60hz, maxes the brightness out and renders the brightness slider non-functional.

However enabling the HBM mode baked into stock kernel, but disabled by Google leaves the display at 90hz and the brightness slider functional.
It´s described in the following artice: How to enable disabled factory HBM from Google on the Pixel 4/XL

Since that method works way more smoothly, I decided to remove the kernel side enforced HBM from my kernel.
So refer to that XDA article above for high brightness mode, in case you want it enabled.

A word of warning however. HBM is one of the mods, that can damage your device and Google could arguably deny any warranty claim, if you decided to use it.

Google made the Pixel 4/XL devices only use HBM on HDR video playback.
That might have a few reasons other than to save battery or to "limit" and leave users with a dimmer display.

Yes limiting the maximum brightness saves a bit battery especially when 90hz is used. I guess we all like a bit more battery life.
However what also needs to be seen is the relation of battery life versus increased usability in sunlight by HBM!

here´s a comparison shot with a camera on manual controls. One in a dark corner of the room and one in the "not so bright" German winter sun.
https://photos.app.goo.gl/wmN56Gd6unhvXBym8

As you can see the difference isn´t really big. I wouldn´t say enabling HBM makes usability in the sun better by a huge margin. Even the super bright displays of other phones are not comfortable to use in bright sun.

With the method above every can try by themselves if they increased brightness is worth the increased power consumption and decide for themselves.

Now the warning. Google deliberately made HBM only available on HDR Video playback. That means moving content with less chance of burn in.
Since we don´t have documentation about the safety limites of the displays available, you´re touching ground that isn´t clearly labeled as safe for the display on a daily basis.
Rendering static images on highest brightness in HBM, may "benefit" and accelerate burn in.
If you´re not using HBM and make a warranty claim for burn in, law is on your side when asking for a replacement. If you decide to use HBM and overwrite googles intentions, your in another zone.

Anyway have fun with the release. I´m very satisfied with the kernel so far

Small update on the magisk module:

Magisk Module fixing the stock powerhal behaviour:
The power hal of the pixel 4 is partially controlled by a config file. On stock the setup of the power-hal causes the kernel to not idle at 576mhz on the little cluster after some random length of uptime, depending on usage and setup.
This module fixes this behaviour. It´s not critically needed, but may increase battery life a tiny bit.

On stock this config file sets up the power hal to boost top-app schedtune boost to 30 upon interaction and after the boost duration is finished, back to a value of 10.
There are different groups for tasks. top-app tasks are ui-critical tasks, rt-tasks, all that are critical for a smooth experience of the phone.
Setting top-app schedtune boost to 30 causes the follwoing: The scheduler will expect tasks of the top-app group to use 30% more CPU time than they (probably) actually will, and the CPU-frequency governor will speed up the processor accordingly. "Boosting" a process in this way, thus, does not affect its scheduling priority, but it will affect the speed of the CPU on which it ends up running.
The problem is resetting the value back to 10, when no interaction is happening. This seems to cause the little cluster to idle at 1036mhz after the phone is up and running a few hours on 4.14 kernels.
With my module the value gets reset back to 0 instead of 10, when the phone is not being interacted with
As you can see this is not kernel related, but a userspace thing, that just influences how the kernel handles load. So it can´t be fixed in the kernel, it needs to be fixed in userspace.
That´s why I created this magisk module. It can be used on the stock kernel and other kernels as well!

I recommend using the module as I´m using it myself

V2 boosts the CPU cores to max for 5 seconds instead of only 1, when launching the camera app to ensure smoother operation.

The changes introduced by the new CAF-Tags were tested for over a week without a single issue reported by my testers
A huge thanks to them at this place again.
@wrongway213
@Mrcactuseater
@MArtyChubbs
@ilal2ielli
@toastyp
@Alcolawl

Detailed changelog below.

Enjoy!

Changelog:

Kernel Base
- Merge all Google related changes from December Security Drop
- Next-Gen CAF-Tag updated to LV.AU.0.1.0.r2-00200-qtiquingvm.0
- revert some Google changes, which could lead to a non deep sleep behaviour and replace them with CAF-Upstream solutions
- additionally merge upstream solution for PM/Wakeup driver, which reduces unnecessary logspam and also improves sleeping behaviour
- update Google and CAF drivers to make use of the upstream PM/Wakeup solution
- linux-stable upstream to latest 4.14.158
- update AK3 zip to latest state (thanks to @osm0sis )

Features:
- Remove kernel enforced HBM (only disadvantages at the moment, use this instead: how to activate factory disabled HBM from Google
- make WLAN driver more lightweight and user power efficient workingqueues
- remove an unnecessary wakelock from the WLAN driver (the wlan has more than enough ways to acquire wakelocks)

Further Kernel Changes:
- look at github

Other changes:
- look at github

Magisk Module:
- update to v2
- boost cpu-cores to max when opening the camera app 5 seconds instead of only 1 second to ensure smoother operation until all necessary firmware and drivers are loaded

Have fun flashing and enjoy your device with latest linux-stable

Why is linux-stable important?

I wish you all a nice day/evening!

Download is below

Download:

Kernel: https://www.androidfilehost.com/?fid=4349826312261667498

Magisk Module: https://www.androidfilehost.com/?fid=4349826312261667499

How to flash the Kernel:

1. Make sure you are rooted and either EXKM or FKM is installed. Download the kernel.zip to your device.
1a. If you used the SQLITE3 Magisk Module and the GPay Fix Magisk Module in the past look at this post: click me

2. Optionally: Flash the magisk module provided in the release post!

3. Flash kernel zip in EXKM or FKM app. Root will be preserved!

4. Reboot and profit! Before reporting any issues make sure to read the first three posts of this thread!
Instructions can be found in the OP too!

Have fun, enjoy the kernel and your phone.

If you like my work please consider a donation.
Donations are not mandatory but very welcome.
If you like my work and want to buy me a coffee/green tea: http://paypal.me/freak07