Mourta-Kernel-3.4 A new beginning [update 2015-03-12]

[Guest Mourta]

Will the Kernel be compatible with Android Lollipop?

 

This kernel is compatible with all Android versions, more so than any other kernel currently available for tegra 3 because i just enabled tegra 4 support for video, we have full support for the sync sub system, the flexible video formats is something i've grabbed from 3.10 (actually if you review the kernel it's about half and half).

 

In short, no other kernel is as compatible.

 

Though when i'm done, you should be able to use my patch set, apply it to any linux kernel (3.18 for example) and spend less than three hours fixing .rej's to have a booting version.

 

I'm going to push this one to this commit c8f8a4ea7c87363565858873311c5622e8d3e686 which is the last commit where there is support for tegra 3, i will then start fixing warnings and clean up the code to a point where it's as standard as it can be while still working with our device, after that i'll produce a patch that includes just absolutely needed additions, then you can add my patches one by one to optimize it.

[Guest Mourta]

I'm not gonna blame you for not reading through 10 pages of this thread but you could atleast use the search button.

Yes it'll be in future versions, you can find info on it in almost every page.

 

It already is... in the version you have. ;)

 

I have another one coming for you guys and ... this is something else...

 

You know when you just installed my ROM for the first time and thought... this is fast.... you're going to get that feeling again. ;)

[Guest easy4me]

Sure, there is no problem doing so, it's directly implementable as a patch from my 3.1.10 kernel, if that is a request i'll implement it.

That's what I meant - what about CPU OC... It's a request...

BTW, keep up your work, your development is close to a fully working L build (it's also the only ROM which is able to boot ATM). And you also have included great improvements to Iodak's work in this kernel.

Edited December 23, 2014 by easy4me

[Guest Mourta]

That's what I meant - what about CPU OC... It's a request...

BTW, keep up your work, your development is close to a fully working L build (it's also the only ROM which is able to boot ATM). And you also have included great improvements to Iodak's work in this kernel.

 

I'm upgrading the kernel and building a new ROM, you'll have to wait until we have latest stable because adding more things to the kernel at this point means that i'll have more .rej files to deal with when i upgrade it to latest stable linux.

[Guest creedence]

Version 11.27 with Omni works well mistaken. Great, great, great!

[Guest Mourta]

New version isn't universal, i can't edit every single possible init to fix the problems but i do know there are people out there who can.

 

It's pretty easy, look at your init and look at my booted kernel, if there are discrepancies  then change that in the init.

[Guest Cesar06]

Screenshot no works with this kernel! =/

[Guest tool_king]

Screenshot no works with this kernel! =/

That's just not right.

[Guest tool_king]

Screenshot no works with this kernel! =/

That's just not right. Edited December 24, 2014 by tool_king

[Guest Mourta]

Screenshot no works with this kernel! =/

 

 

Works fine for me.

[Guest Mourta]

Moving along with the development, the new stuff will be scrapped for 3.4 until further notice, i'm standardizing the code to move on to the last known version that has support with Tegra3 and then upgrading what is possible to Tegra 4 (some things can't move to that, video can, audio can, cam functions cannot).

 

So while i will release a final version of 3.4 it's just a step on the way to bigger and better things.

[Guest Mayazcherquoi]

Moving along with the development, the new stuff will be scrapped for 3.4 until further notice, i'm standardizing the code to move on to the last known version that has support with Tegra3 and then upgrading what is possible to Tegra 4 (some things can't move to that, video can, audio can, cam functions cannot).

 

So while i will release a final version of 3.4 it's just a step on the way to bigger and better things.

So I'm guessing this is off the table then?

Well i do expect to release 3.16 with lollypop around new years. Tegra 4 blobs.

[Guest Mourta]

So I'm guessing this is off the table then?

 

I'm rushing to get it done.

 

Look, this is the way this story goes:

 

To 3.4 almost every file rewritten since to get a standard version that can be upgraded with standard Linux, addition of 3.10 version as far as it carries our version of Tegra and then some for the video and that doesn't even matter, that isn't in the Linux original kernel, our android stuff is an addition on top of the standard Linux kernel.

 

What i'm saying is that i can't upgrade the 3.4 and keep the upgrade to 3.10 while standardizing everything to produce that 3.16 kernel.

 

Lollypop is already done and up running, it has been for weeks, it's just that my chosen codebase has been so unstable that i chose not to release it.

 

So if you follow along what i have said then you'd realize that it's very much on time that i scrap support for this for what comes next.

 

I cannot for the world of me understand how you figure that that is off the table when this is a statement of discontinuing 3.4 for now to work on exactly that?

[Guest abhi08638]

What's your opinion on having two cores always on? I feel like the constant hotplugging hurts more than helps the battery drain, plus it could be much smoother.

[Guest ottomanhero]

Abhi, I've been doing some testing on core management and Imo it scales up too agressively, talking about this kernel and most of the kernels out there and having less cores on really helps with battery life, more than underclocking.

You are right about it draining battery life.Most of the time cores just all turn on running on 1.5 ghz only to scale down a few seconds later, wasting a good amount of battery life.

E.g. switching to an app from recents turns 4 cores on.While this does require some processing power, same task can be done with 2 cores on @ 1.5 ghz while saving a lot of battery life considering android users always multitask and recents is used quite a lot.2 Cores are enough for UI smoothness, 3rd and 4th should only be turned on for heavy tasks that would otherwise lag/have low performance with only 2 cores running.

Also there are the cases where 4 cores turn on with around 22% usage only to scale down after a few seconds (possibly due to CPU governor reacting after cpuquiet)

So maybe there could be a special configuration where 3rd and 4th cores are harder to turn on than 2nd.I think runnable had some settings on this, I'll have the time to play around with it next week.If I remember correctly stock ROM scaling behavior is like this.But it was barely any good in games, 3rd and 4th would barely turn on, causing lags.It needs to be configured carefully.

[Guest abhi08638]

Abhi, I've been doing some testing on core management and Imo it scales up too agressively, talking about this kernel and most of the kernels out there and having less cores on really helps with battery life, more than underclocking.

You are right about it draining battery life.Most of the time cores just all turn on running on 1.5 ghz only to scale down a few seconds later, wasting a good amount of battery life.

E.g. switching to an app from recents turns 4 cores on.While this does require some processing power, same task can be done with 2 cores on @ 1.5 ghz while saving a lot of battery life considering android users always multitask and recents is used quite a lot.2 Cores are enough for UI smoothness, 3rd and 4th should only be turned on for heavy tasks that would otherwise lag/have low performance with only 2 cores running.

Also there are the cases where 4 cores turn on with around 22% usage only to scale down after a few seconds (possibly due to CPU governor reacting after cpuquiet)

So maybe there could be a special configuration where 3rd and 4th cores are harder to turn on than 2nd.I think runnable had some settings on this, I'll have the time to play around with it next week.If I remember correctly stock ROM scaling behavior is like this.But it was barely any good in games, 3rd and 4th would barely turn on, causing lags.It needs to be configured carefully.

Thanks for the input! I completely agree, the scaling seems too erratic and I'd say if you're not a gamer then having only 2 cores always on at 1.3 GHz is the best option. This is my current setup and so far it works a lot better and the screen wake up time is instant. After trickster mod has run on boot, I use a script I made to set cpuquiet to userspace and set core 0 and 1 to on and cores 2 and 3 to off. IMO, the other two cores are completely unnecessary if you do not play games. I just hope that its possible to have a per core config or bricked hotplug governor, although its only for Qualcomm CPUs

Edit: forgot the mention that heat output is increased by a fraction but its still negligible. I'll post some battery results in a best case scenario for this setup once its depleted

Edited January 13, 2015 by abhi08638

[Guest abhi08638]

Alright so with only two cores always on at 1.5 GHz, always on airplane mode with WiFi enabled and everything greenified with near 0% idle drain, the battery has not improved much. Heat output is usually around 45°C. I estimate another half jour till I reach 0 so it totals at 3.5 hours as usual.

[Guest nikpik]

Thanks for the input! I completely agree, the scaling seems too erratic and I'd say if you're not a gamer then having only 2 cores always on at 1.3 GHz is the best option. This is my current setup and so far it works a lot better and the screen wake up time is instant. After trickster mod has run on boot, I use a script I made to set cpuquiet to userspace and set core 0 and 1 to on and cores 2 and 3 to off. IMO, the other two cores are completely unnecessary if you do not play games. I just hope that its possible to have a per core config or bricked hotplug governor, although its only for Qualcomm CPUs

Edit: forgot the mention that heat output is increased by a fraction but its still negligible. I'll post some battery results in a best case scenario for this setup once its depleted

can you share your script with us?

[Guest abhi08638]

can you share your script with us?

#!/system/bin/sh

echo "userspace" > /sys/devices/system/cpu/cpuquiet/current_governor

echo 1 > /sys/devices/system/cpu/cpu1/online

echo 0 > /sys/devices/system/cpu/cpu2/online

echo 0 > /sys/devices/system/cpu/cpu3/online

--------------------

Be sure to turn off any kernel apps. Of you change anything then it well reset these and you'll have to run the script again

[Guest Mourta]

What's your opinion on having two cores always on? I feel like the constant hotplugging hurts more than helps the battery drain, plus it could be much smoother.

 

We're using cpuquiet, not hotplugging kernels, we are not hotplugging anything at all.

 

We're merely putting cores into quiescent states and out of them, not any different than scaling governors.

 

You'll be moving 4 cores at all times with this current implementation so...

[Guest Mourta]

Thanks for the input! I completely agree, the scaling seems too erratic and I'd say if you're not a gamer then having only 2 cores always on at 1.3 GHz is the best option. This is my current setup and so far it works a lot better and the screen wake up time is instant. After trickster mod has run on boot, I use a script I made to set cpuquiet to userspace and set core 0 and 1 to on and cores 2 and 3 to off. IMO, the other two cores are completely unnecessary if you do not play games. I just hope that its possible to have a per core config or bricked hotplug governor, although its only for Qualcomm CPUs

Edit: forgot the mention that heat output is increased by a fraction but its still negligible. I'll post some battery results in a best case scenario for this setup once its depleted

 

This is idiotic, you won't get battery life out of it (this chipset will supply power to two cores that are not in use whether you want to or not) and you will lose out on the race to idle (get it done and then rest) function that is implemented in the latest cpuquiet.

 

The heat output will increase if there is more power output, this is basic physics.

 

You don't have a single clue how SMP works, how it can actually save battery to have four kernels working to complete a task faster (since they will be drawing power at all times) and how cpuquiet works).

 

I would make a bet that you haven't spent five minutes looking at any code or the schematics for the CPU before coming up with this hair brained idea of yours and yet you think you know better than those who actually designed the chipset, cpuquiet and the devs that implement it.

 

Here's a clue, you really, really do not.

[Guest abhi08638]

This is idiotic, you won't get battery life out of it (this chipset will supply power to two cores that are not in use whether you want to or not) and you will lose out on the race to idle (get it done and then rest) function that is implemented in the latest cpuquiet.

The heat output will increase if there is more power output, this is basic physics.

You don't have a single clue how SMP works, how it can actually save battery to have four kernels working to complete a task faster (since they will be drawing power at all times) and how cpuquiet works).

I would make a bet that you haven't spent five minutes looking at any code or the schematics for the CPU before coming up with this hair brained idea of yours and yet you think you know better than those who actually designed the chipset, cpuquiet and the devs that implement it.

Here's a clue, you really, really do not.

My mistake, thanks for the clarification. Not really familiar with the implementation of tegra's cpuquiet, only Qualcomm's mpdecision. Won't happen again.

[Guest Mourta]

My mistake, thanks for the clarification. Not really familiar with the implementation of tegra's cpuquiet, only Qualcomm's mpdecision. Won't happen again.

 

Sorry for being harsh but yeah, MPD is quite different in that it actually runs off the cores instead of putting them in a quiescent state, i experimented with it in my old kernel (along with intelliplug) but found that using cpuquiet with a sensible plugging governor was the best idea for battery life, i do believe that we were going on 4.5 hours of fairly heavy usage screen on time before i abandoned the project to move on to this one, i left it in a state where it's stable and i intend to do the same to this one when i'm moving to 3.10-16 if you are interested i do have a finished set of a kernel implementation of MPD that doesn't require external programs and can be controlled via sysfs.

 

Unfortunately this won't do much more than to leave the cores at 51Mhz and being unused either, you cannot turn off cores on this chipset, i've tried in my own implementations and it works as far as turning them off completely, the only problem was that it turns off the entire CPU and now you only have the LP0 core to work with until next reboot, great for battery life but a ZTE blade version 1 will be ten times faster in comparison. So... not a great idea after all.

 

If you want to review my work on this i'm happy to share it with you though, if you have experience with QC's implementation you'll feel right at home.

[Guest abhi08638]

Sorry for being harsh but yeah, MPD is quite different in that it actually runs off the cores instead of putting them in a quiescent state, i experimented with it in my old kernel (along with intelliplug) but found that using cpuquiet with a sensible plugging governor was the best idea for battery life, i do believe that we were going on 4.5 hours of fairly heavy usage screen on time before i abandoned the project to move on to this one, i left it in a state where it's stable and i intend to do the same to this one when i'm moving to 3.10-16 if you are interested i do have a finished set of a kernel implementation of MPD that doesn't require external programs and can be controlled via sysfs.

Unfortunately this won't do much more than to leave the cores at 51Mhz and being unused either, you cannot turn off cores on this chipset, i've tried in my own implementations and it works as far as turning them off completely, the only problem was that it turns off the entire CPU and now you only have the LP0 core to work with until next reboot, great for battery life but a ZTE blade version 1 will be ten times faster in comparison. So... not a great idea after all.

If you want to review my work on this i'm happy to share it with you though, if you have experience with QC's implementation you'll feel right at home.

No need for apologies, were all friends here.

I had no idea you already experimented with it and since you're saying that it basically is the equivalent of using MSM Limiter on min freq for cores 2 and 3, it seems pretty inefficient since it goes against the whole "race to idle" ideology. I don't think me looking at the code would help much since you have more years of experience than I have been alive. I completely trust where you intend to go with the kernel and its implementation.

[Guest juantech]

I'm upgrading the kernel and building a new ROM, you'll have to wait until we have latest stable because adding more things to the kernel at this point means that i'll have more .rej files to deal with when i upgrade it to latest stable linux.

Hello Mourta, the next week i will have the LG Optimus 4x HD, i was searching the best kernel and i think what this is the best, you had realized a great job with this.

Im new in flashings roms and kernels, i only used flashtool before for flash an stock rom to my Xperia u, i dont understand much english sorry some things i didnt understand for this too.

Could someone explain me how install the last version of kernel and rom of mourta?

And Mourta you sayed what you are working on 5.0 lollipop and the final version of this kernel, these two will be compatible?

Sorry i viewed all the entire thread 3 times but i dont understand much english and not much about kernels.

Edited January 16, 2015 by juantech