[Stock-Kernel-4.3] XzInnere v5.0 [Linaro] 29-March

Search This thread

alnikki25k

Inactive Recognized Developer
May 16, 2012
1,309
2,680
Gainesville
Note!


Features

Gamma Control - HOW-TO
DoubleTap2Wake - HOW-TO
Sweep2Wake - HOW-TO
Advanced Xperia Recovery - HOW-TO (Only v5 and above)
Based on 10.4.1.B.0.101 kernel sources
Xperia Advanced Recovery Bootloader
CPU overclock upto 1.944 GHz
Undervolting
Built with Linaro 4.8.3 toolchain using -O3 optimisation
Updated Prima WLAN drivers
Additional CPU governors - SmartMAX | SmartMAX_eps | Intellidemand 5.0 | Intelliactive | Preservative
Tweaked SIO and added FIOPS, Zen, VR, BFQ (7.2) and ROW block schedulers
USB force fastcharge
Updated Ondemand and interactive governor
Compressed kernel using XZ
Tweaked voltage regulators
Interactive GPU Governor
Uses CPUQuiet from Nvidia

Installation instructions


Un-Installation instructions

Use the AROMA Installer in the zip to uninstall

Credits

Sony - I love what they do and only wish they got more recognition. They deserve it.
faux123 - For almost all kernel features
DoomLord - For the RAMDISK


Donors


Source

http://bitbucket.org/nikhiljan93/xzkernel

XDA:DevDB Information
[Stock-Kernel] XzInnere [Linaro-4.8.3], a Kernel for the Sony Xperia Z

Contributors
alnikki25k
Kernel Special Features:

Version Information
Status: Stable
Current Stable Version: 5.0
Stable Release Date: 2014-03-29

Created 2014-01-27
Last Updated 2014-03-28
 

alnikki25k

Inactive Recognized Developer
May 16, 2012
1,309
2,680
Gainesville
Reserved

HOTPLUG CONTROL, GOVERNORS, SAMPLE CONFIGS:

Thanks to n3ocort3x

With cpuquiet + load stats governor u get a brilliant battery life while keep it snappy.
I recommend leaving the governor on load stats (hotplug depended on load) to get the best results.


If you want to keep it balanced, and yeah, most users want that:

governor: smartmax
cpuquiet governor: load_stats


If you want ultimate performance:

governor: interactive (up treshold 65) or smartmax (lower tresholds)
cpuquiet governor: load_stats



SMARTMAX GOVERNOR
===============

awake_ideal_freq 594000
boost_freq 1242000
suspend_ideal_freq 384000
touch_poke_freq 1242000

Leave the rest untouched



For a more power-saving governor (Recommended)


Thanks to bedalus

This is just for the record, and for those interested. The previous version of Preservative worked like a combination of smartass and conservative. It would scale straight up to the optimum frequency if there was any load (like smartass), then scale up one step at a time (like conservative) if the load was above the required threshold. This worked pretty well, and helped keep the frequency low. But sometimes it was keeping it low for too long, and a few users (myself included) noticed occasional hangs, presumably caused by a pile up of critical code that didn't get executed in time.

To improve responsiveness, but keep the frequency as low as possible was quite a challenge. I took the existing logic and chucked most of it in the bin...

(Remember, it's keeping the frequency low, and not UV that saves power - read this thread, especially post #2 for more background on this issue)

...what came to replace it was a fairly original hybrid, inspired by ondemand. Ondemand works by jumping to the top frequency when there is any load. This is usually overkill. So, you might have been at 100% CPU utilisation at 384MHz, so ondemand will jump straight to 1512MHz. However, when it gets there, the utilisation is now only 30%, so it will scale down to 486MHz.

Preservative now works a little like this. Whatever frequency it is currently at, if the utilisation hits 100%, it will scale up. But scaling up to max like ondemand? In the example above, this was the worst kind of overkill. Scaling up to max just to find scaling up one step would have been sufficient. But do we need to scale up one step, or as many as possible? There's no way to know for sure. You have to scale up before you can measure if the extra CPU cycles were enough or not.

This issue is what Preservative attempts to overcome: if the load is high, it will scale up, but not always to max. Let's label the frequency steps: 384=A 486=B 594=C 702=D 810=E 918=F 1026=G 1134=H 1242=I 1350=J 1458=K 1512=L

Conservative would take 11 calls to the governor to get from A to L, if L was required. Ondemand would go straight there. Ondemand is often overkill, conservative is often underkill. I'd like a compromise. Here's what Preservative would do:

Code:
L <- 4th step selected by preservative
K <- 3rd step selected by preservative
J <- 2nd step selected by preservative
I
H
G <- 1st step selected by preservative
F
E
D
C
B
A <- sat here until there is load

It splits the difference between whichever frequency it is at and the top frequency, and jumps there. If it is still under high load, it will do it again. So if it is idling, then needs to get to the top, it takes three more calls than ondemand, but seven less than conservative. Not only that, but it has also skipped over a large chunk of the slower steps that conservative would crawl through.

Scaling down also works in a similar way. Preservative will work out what step would be sufficient to manage the load, then jump halfway to that step on the first call. This is because, unlike ondemand, there is no down-threshold. Preservative will scale up when the load exceed the up threshold, but as soon as this is no longer the case, it will start attempting to scale back down to save power. It does not wait for load to reduce to drop below a certain point. Loads fluctuate. If went straight back to A, only to come back back to L, it would have to scale through G J and K again. However, dropping to G then D then B before A means if it does have to scale back up towards L, it doesn't have as far to climb, meaning less calls to the governor, and that the best step can be achieved quicker.

There has also been an adjustment to the up threshold. When the device is idle, the up threshold will automatically adjust to be more relaxed about scaling up. This means while the device is idle (e.g. when you are just reading some text) it becomes increasingly sensitive to changes in demand. When you touch the screen it will extremely responsive.

Conversely, when the device is hitting the top frequency, the up threshold will become increasingly strict. So if you are gaming, and putting a lot of load on the CPU, it will aim to be as efficient as possible, and only scale up if it really has to, to ensure that no cycles are wasted at these high power hungry frequencies.

Whenever it goes from hitting L to hitting A, or visa versa, the threshold will reset to default. The sysfs location of this tunable remains at:

Code:
/sys/devices/system/cpu/cpufreq/up_threshold

It will accept values of up to 127, higher being more power-saving. The default is 100, but editing the file changes this value. If you want to use a different value on a permanent basis, add the line

Code:
[B]echo 84 > /sys/devices/system/cpu/cpufreq/up_threshold[/B]

to /etc/init.d/00config

and it will then restore your setting of 84 (or whatever) every time you reboot. Remember it will be overwritten if you flash updates to the kernel, so make a copy of your edited file. However, I believe 100 is a pretty good default.
 
Last edited:

alnikki25k

Inactive Recognized Developer
May 16, 2012
1,309
2,680
Gainesville
Reserved

Changelog

Next-Release-TO-DO

XzI - v6

Kitkat - 230 Sources
Massive changelog
Large amounts of debugging code removed


Current-Release

XzI - v5

Intelliactive CPU governor
New! Advanced Xperia Recovery Bootloader
New! Preservative CPU Governor (Read more)
Kernel mode NEON
MSM CPU Frequency Limiter / a.k.a Snake Charmer(in faux app) support
Kernel Futex tweaks
MSM Memcopy enhancements from Motorola Mobility
Higher Bus Speeds @ Lower cache clocks = Higher performance @ Lower Temperatures + More Power Savings
Generic tweaks

Previous releases



XzI - v4


Sony 10.4.1.B.0.101 Sources
Tap2Wake/Sweep2Wake using evgen method
New Power-Aware Workqueue algorithms
AROMA Installer
XzDualRecovery
Lots of debugging removed
BFQ-v7r1
Interactive GPU Governor
Removed Simple GPU Governor
Removed MultiROM


XzI - v3


MultiROM Xperia for Xperia Z - http://www.youtube.com/watch?v=9f9gG1sRNog
- Initial implementation. Not functional. Just testing boot.
Revert Power-Supply drivers back to 4.2.2
Intellidemand Governor 5.0


XzI - v2


Lower undervolt to 600 mV
Sound Control 2.0
Gamma Control
SLUB updates
Updated Adreno drivers
Use O3 Optimisation
Tune BFQ
System Config Clean-up - Quite experimental


XzI - v1





Download

 
Last edited:

Kocane

Senior Member
Apr 29, 2012
1,673
308
Cool! Good job. What would you say is the advantage in this kernel over XzKernel?
 

Kocane

Senior Member
Apr 29, 2012
1,673
308
Yup. May not include that. But will have Gamma control.

You sure you cant make a version with doubletap? I dont need very advanced kernel, just some governors and stuff and now I got used to the tapping as well : (

BTW, how about the wakelock fixes and so from XzKernel, are they included here?
 

o0oP5

Senior Member
Sep 24, 2012
123
13
Exactly what i need, a battery oriented / balanced kernel, while keeping it slim.. Keep up the good work!

Waiting for gamma control.. ??

Edit Note: i've missed the part which state that double tap wont be included here.. Sorry..

Sent from my C6602 using Tapatalk
 
Last edited:

Top Liked Posts

  • There are no posts matching your filters.
  • 33
    Note!


    Features

    Gamma Control - HOW-TO
    DoubleTap2Wake - HOW-TO
    Sweep2Wake - HOW-TO
    Advanced Xperia Recovery - HOW-TO (Only v5 and above)
    Based on 10.4.1.B.0.101 kernel sources
    Xperia Advanced Recovery Bootloader
    CPU overclock upto 1.944 GHz
    Undervolting
    Built with Linaro 4.8.3 toolchain using -O3 optimisation
    Updated Prima WLAN drivers
    Additional CPU governors - SmartMAX | SmartMAX_eps | Intellidemand 5.0 | Intelliactive | Preservative
    Tweaked SIO and added FIOPS, Zen, VR, BFQ (7.2) and ROW block schedulers
    USB force fastcharge
    Updated Ondemand and interactive governor
    Compressed kernel using XZ
    Tweaked voltage regulators
    Interactive GPU Governor
    Uses CPUQuiet from Nvidia

    Installation instructions


    Un-Installation instructions

    Use the AROMA Installer in the zip to uninstall

    Credits

    Sony - I love what they do and only wish they got more recognition. They deserve it.
    faux123 - For almost all kernel features
    DoomLord - For the RAMDISK


    Donors


    Source

    http://bitbucket.org/nikhiljan93/xzkernel

    XDA:DevDB Information
    [Stock-Kernel] XzInnere [Linaro-4.8.3], a Kernel for the Sony Xperia Z

    Contributors
    alnikki25k
    Kernel Special Features:

    Version Information
    Status: Stable
    Current Stable Version: 5.0
    Stable Release Date: 2014-03-29

    Created 2014-01-27
    Last Updated 2014-03-28
    17
    Reserved

    HOTPLUG CONTROL, GOVERNORS, SAMPLE CONFIGS:

    Thanks to n3ocort3x

    With cpuquiet + load stats governor u get a brilliant battery life while keep it snappy.
    I recommend leaving the governor on load stats (hotplug depended on load) to get the best results.


    If you want to keep it balanced, and yeah, most users want that:

    governor: smartmax
    cpuquiet governor: load_stats


    If you want ultimate performance:

    governor: interactive (up treshold 65) or smartmax (lower tresholds)
    cpuquiet governor: load_stats



    SMARTMAX GOVERNOR
    ===============

    awake_ideal_freq 594000
    boost_freq 1242000
    suspend_ideal_freq 384000
    touch_poke_freq 1242000

    Leave the rest untouched



    For a more power-saving governor (Recommended)


    Thanks to bedalus

    This is just for the record, and for those interested. The previous version of Preservative worked like a combination of smartass and conservative. It would scale straight up to the optimum frequency if there was any load (like smartass), then scale up one step at a time (like conservative) if the load was above the required threshold. This worked pretty well, and helped keep the frequency low. But sometimes it was keeping it low for too long, and a few users (myself included) noticed occasional hangs, presumably caused by a pile up of critical code that didn't get executed in time.

    To improve responsiveness, but keep the frequency as low as possible was quite a challenge. I took the existing logic and chucked most of it in the bin...

    (Remember, it's keeping the frequency low, and not UV that saves power - read this thread, especially post #2 for more background on this issue)

    ...what came to replace it was a fairly original hybrid, inspired by ondemand. Ondemand works by jumping to the top frequency when there is any load. This is usually overkill. So, you might have been at 100% CPU utilisation at 384MHz, so ondemand will jump straight to 1512MHz. However, when it gets there, the utilisation is now only 30%, so it will scale down to 486MHz.

    Preservative now works a little like this. Whatever frequency it is currently at, if the utilisation hits 100%, it will scale up. But scaling up to max like ondemand? In the example above, this was the worst kind of overkill. Scaling up to max just to find scaling up one step would have been sufficient. But do we need to scale up one step, or as many as possible? There's no way to know for sure. You have to scale up before you can measure if the extra CPU cycles were enough or not.

    This issue is what Preservative attempts to overcome: if the load is high, it will scale up, but not always to max. Let's label the frequency steps: 384=A 486=B 594=C 702=D 810=E 918=F 1026=G 1134=H 1242=I 1350=J 1458=K 1512=L

    Conservative would take 11 calls to the governor to get from A to L, if L was required. Ondemand would go straight there. Ondemand is often overkill, conservative is often underkill. I'd like a compromise. Here's what Preservative would do:

    Code:
    L <- 4th step selected by preservative
    K <- 3rd step selected by preservative
    J <- 2nd step selected by preservative
    I
    H
    G <- 1st step selected by preservative
    F
    E
    D
    C
    B
    A <- sat here until there is load

    It splits the difference between whichever frequency it is at and the top frequency, and jumps there. If it is still under high load, it will do it again. So if it is idling, then needs to get to the top, it takes three more calls than ondemand, but seven less than conservative. Not only that, but it has also skipped over a large chunk of the slower steps that conservative would crawl through.

    Scaling down also works in a similar way. Preservative will work out what step would be sufficient to manage the load, then jump halfway to that step on the first call. This is because, unlike ondemand, there is no down-threshold. Preservative will scale up when the load exceed the up threshold, but as soon as this is no longer the case, it will start attempting to scale back down to save power. It does not wait for load to reduce to drop below a certain point. Loads fluctuate. If went straight back to A, only to come back back to L, it would have to scale through G J and K again. However, dropping to G then D then B before A means if it does have to scale back up towards L, it doesn't have as far to climb, meaning less calls to the governor, and that the best step can be achieved quicker.

    There has also been an adjustment to the up threshold. When the device is idle, the up threshold will automatically adjust to be more relaxed about scaling up. This means while the device is idle (e.g. when you are just reading some text) it becomes increasingly sensitive to changes in demand. When you touch the screen it will extremely responsive.

    Conversely, when the device is hitting the top frequency, the up threshold will become increasingly strict. So if you are gaming, and putting a lot of load on the CPU, it will aim to be as efficient as possible, and only scale up if it really has to, to ensure that no cycles are wasted at these high power hungry frequencies.

    Whenever it goes from hitting L to hitting A, or visa versa, the threshold will reset to default. The sysfs location of this tunable remains at:

    Code:
    /sys/devices/system/cpu/cpufreq/up_threshold

    It will accept values of up to 127, higher being more power-saving. The default is 100, but editing the file changes this value. If you want to use a different value on a permanent basis, add the line

    Code:
    [B]echo 84 > /sys/devices/system/cpu/cpufreq/up_threshold[/B]

    to /etc/init.d/00config

    and it will then restore your setting of 84 (or whatever) every time you reboot. Remember it will be overwritten if you flash updates to the kernel, so make a copy of your edited file. However, I believe 100 is a pretty good default.
    14
    Reserved

    Changelog

    Next-Release-TO-DO

    XzI - v6

    Kitkat - 230 Sources
    Massive changelog
    Large amounts of debugging code removed


    Current-Release

    XzI - v5

    Intelliactive CPU governor
    New! Advanced Xperia Recovery Bootloader
    New! Preservative CPU Governor (Read more)
    Kernel mode NEON
    MSM CPU Frequency Limiter / a.k.a Snake Charmer(in faux app) support
    Kernel Futex tweaks
    MSM Memcopy enhancements from Motorola Mobility
    Higher Bus Speeds @ Lower cache clocks = Higher performance @ Lower Temperatures + More Power Savings
    Generic tweaks

    Previous releases



    XzI - v4


    Sony 10.4.1.B.0.101 Sources
    Tap2Wake/Sweep2Wake using evgen method
    New Power-Aware Workqueue algorithms
    AROMA Installer
    XzDualRecovery
    Lots of debugging removed
    BFQ-v7r1
    Interactive GPU Governor
    Removed Simple GPU Governor
    Removed MultiROM


    XzI - v3


    MultiROM Xperia for Xperia Z - http://www.youtube.com/watch?v=9f9gG1sRNog
    - Initial implementation. Not functional. Just testing boot.
    Revert Power-Supply drivers back to 4.2.2
    Intellidemand Governor 5.0


    XzI - v2


    Lower undervolt to 600 mV
    Sound Control 2.0
    Gamma Control
    SLUB updates
    Updated Adreno drivers
    Use O3 Optimisation
    Tune BFQ
    System Config Clean-up - Quite experimental


    XzI - v1





    Download

    10
    XzI - v5 uploaded!

    Please consider donating

    Changelog

    Code:
    [B]Intelliactive CPU governor
    New! Advanced Xperia Recovery Bootloader
    New! Preservative CPU Governor (Read more)
    Kernel mode NEON 
    MSM CPU Frequency Limiter / a.k.a Snake Charmer(in faux app) support
    Kernel Futex tweaks
    MSM Memcopy enhancements from Motorola Mobility
    Higher Bus Speeds @ Lower cache clocks = Higher performance @ Lower Temperatures + More Power Savings
    Generic tweaks[/B]
    10
    Sony's sources are up. I'll work on XzI-4 today. :good: