[KERNEL] valexKernel [SM-P600 | CM13/AOSP 6.x ]

[Andmoreagain]

Hmm, the s-pen is still causing occasional freezes so this is not just because of the user namespace. It's not as frequent as before though but I remember these sorts of freezes occasionally happening with stock kernels/ROMs as well. Maybe it's just that Samsung's drivers are poorly written, I don't know. It's very hard to tell what's causing this since I haven't made any changes to the wacom/spen drivers, and both logcat and dmesg aren't being very helpful either.

Although this isn't as much of an issue in v3.1, it still irritates me to the bone. I'll find a solution or die trying, so I guess I'm off then to compile a build with every single debug option enabled lol. I won't be making another release until this buggy behavior has been fixed for good.

 

[enotar]

Can you describe what freeze, spen, windows or tablet and you have to reboot? Could it be framework issue?

Yeah.... got the same.

Sent from my SM-G920I using Tapatalk

 

[r4yN]

I was wondering... since you're having problems with HMP/GTS (f*ck samsung and their lack of support), maybe In-Kernel-Switcher (CPU migration) is the way to go?
Looking at the wikipedia-entry on the big.little architecture, IKS appears to be a simpler approach (with 4 virtual cores and per-core switching). It might not be as powerful as GTS (you're still limited to 4 cores max), but it should be a lot more power efficient than the current cluster-switching (with per-core switching, independent core frequencies and the ability to shut down unused cores)

IKS is said to be part of the Linux 3.11 / 3.13 kernel and iirc you said you were backporting linux 3.13 features, so maybe it's worth a try?

https://en.m.wikipedia.org/wiki/ARM_big.LITTLE

(i could be totally wrong on this, I'm not a developer)

 

[DirkStorck]

Maybe stupid question but does this mean we are currently not using 8 cores? ?

 

[Orion116]

Maybe stupid question but does this mean we are currently not using 8 cores? ?

Right

Sent from my SM-P600 using Tapatalk

 

[DirkStorck]

Hm didn't notice that ? is this because of this kernel or general problem of AOSP? ?

 

[Orion116]

Hm didn't notice that ? is this because of this kernel or general problem of AOSP? ?

You have only been using four cores alternating even on TW. AOSP developers are trying to fix this.

Sent from my SCH-R530U using Tapatalk

 

[DirkStorck]

You have only been using four cores alternating even on TW. AOSP developers are trying to fix this.

Sent from my SCH-R530U using Tapatalk

Thanks for the info ? and the work ?

 

[Tarasque174]

I tried this on Temasec ROM and I like it better then the stock kernel. Tab feels quicker and more responsive now. Battery life seems to be better also. Been running it for 2 days now.

 

[mikmock]

No issues with rubber tipped stylus

Hmm, the s-pen is still causing occasional freezes so this is not just because of the user namespace. It's not as frequent as before though but I remember these sorts of freezes occasionally happening with stock kernels/ROMs as well. Maybe it's just that Samsung's drivers are poorly written, I don't know. It's very hard to tell what's causing this since I haven't made any changes to the wacom/spen drivers, and both logcat and dmesg aren't being very helpful either.

Although this isn't as much of an issue in v3.1, it still irritates me to the bone. I'll find a solution or die trying, so I guess I'm off then to compile a build with every single debug option enabled lol. I won't be making another release until this buggy behavior has been fixed for good.

Before you go into Bug Mode I would like to chime-in & advise that I once removed the s-pen just to see what it looked like, stuck it back in & never touched it since. Recently I began using a standard type rubber tipped stylus for basically checking little boxes and keyboard accuracy & have never had an issue what-so-ever, of coarse i have absolutly no artistic talent when it comes to drawing so this maybe of no importance to the issue.
Additionally...
IMHO your work on the Valex kernel is outstanding :good::good::good: and its compatability with Temasek is most excellent (excluding the drawing issue which i too would believe falls more on a Samsung driver issue than your kernel). Hopfully you will squash the s-pen bug quickly & be able to concentrate on the Linux/kernel mods.

Good luck in bugland, thanks for your awesome kernel work & where is your "Donate" link? (you will surely need beverages while hunting)

 

[Andmoreagain]

Before you go into Bug Mode I would like to chime-in & advise that I once removed the s-pen just to see what it looked like, stuck it back in & never touched it since. Recently I began using a standard type rubber tipped stylus for basically checking little boxes and keyboard accuracy & have never had an issue what-so-ever, of coarse i have absolutly no artistic talent when it comes to drawing so this maybe of no importance to the issue.
Additionally...
IMHO your work on the Valex kernel is outstanding :good::good::good: and its compatability with Temasek is most excellent (excluding the drawing issue which i too would believe falls more on a Samsung driver issue than your kernel). Hopfully you will squash the s-pen bug quickly & be able to concentrate on the Linux/kernel mods.

Good luck in bugland, thanks for your awesome kernel work & where is your "Donate" link? (you will surely need beverages while hunting)

It must have something to do with the memory management (mm) updates. It's basically on par with Linux 3.7 at the moment, though a few things are still in 3.4 territory. I'm going to try to sync mm and arch/arm/mm completely with 3.7 and see if that fixes the issue. Otherwise I'll just have to hard reset the branch to an earlier point in history and do more frequent testing between the cherry-picks and merges.

The whole area of memory management is probably the most sensitive part of the kernel when it comes to making changes to it, but then again these are all mainline commits. It's a bit strange how it's only affecting the wacom/s-pen input drivers. Most likely the culprit is just one single commit that needs to be reverted lol.

Unfortunately I don't have much time to maintain my kernel at the moment since I just started my first semester at uni (multimedia) but I'll fix this as soon as I find the time to go through this.

As for a donation button, I should definitely arrange that. For those who are hungry for true octa support then I'm also working on a bare-bone kernel project based on Android's 3.14 kernel branch (gonna try migrating to 3.18 later on since it has better support for our SoC). I've pulled in most of the core drivers needed for booting, but porting over the LCD display driver is posing an issue because it's a territory that I'm simply not familiar with. A co-worker just got me in contact with a programmer who's willing to take a look at it but he expects some payment in return.

The ultimate goal for the new kernel is also utilizing its multiplatform support. That way, the same kernel image could be successfully flashed on literally any Exynos5420-based device. Maybe I should just start a new thread for this and cross-post it over at the Tab S/Note Pro/Note 3 forums as well...

 

[Orion116]

It must have something to do with the memory management (mm) updates. It's basically on par with Linux 3.7 at the moment, though a few things are still in 3.4 territory. I'm going to try to sync mm and arch/arm/mm completely with 3.7 and see if that fixes the issue. Otherwise I'll just have to hard reset the branch to an earlier point in history and do more frequent testing between the cherry-picks and merges.

The whole area of memory management is probably the most sensitive part of the kernel when it comes to making changes to it, but then again these are all mainline commits. It's a bit strange how it's only affecting the wacom/s-pen input drivers. Most likely the culprit is just one single commit that needs to be reverted lol.

Unfortunately I don't have much time to maintain my kernel at the moment since I just started my first semester at uni (multimedia) but I'll fix this as soon as I find the time to go through this.

As for a donation button, I should definitely arrange that. For those who are hungry for true octa support then I'm also working on a bare-bone kernel project based on Android's 3.14 kernel branch (gonna try migrating to 3.18 later on since it has better support for our SoC). I've pulled in most of the core drivers needed for booting, but porting over the LCD display driver is posing an issue because it's a territory that I'm simply not familiar with. A co-worker just got me in contact with a programmer who's willing to take a look at it but he expects some payment in return.

The ultimate goal for the new kernel is also utilizing its multiplatform support. That way, the same kernel image could be successfully flashed on literally any Exynos5420-based device. Maybe I should just start a new thread for this and cross-post it over at the Tab S/Note Pro/Note 3 forums as well...

Sounds like a plan?

Sent from my SM-P600 using Tapatalk

 

[Andmoreagain]

Also this: https://bitbucket.org/sigma-1/valexkernel-lt03wifi/commits/branch/V4-dev

I was testing out a small MCPM/octa core hack last night from the 3.8 ChromeOS kernel where I appended to the zImage a minimalistic dt blob describing only the eight cores and the CCI. It boots into a black screen and gets no further than that.

One thing I noticed by looking at the 3.4 exynos5410-smdk5410.dts file was that it also contained some i2c nodes, which I left out in my exynos5420-universal5420.dts. The display and touchscreen are connected via i2c so maybe that's the reason for the display not working correctly once it got past the bootloader. I'm going to throw together a more comprehensive dts and dtsi files to see if they make any difference. Even though the device drivers don't have OF/ DT support, the i2c's themselves seem to support it and maybe they even rely on it if the build is configured with DT support.

At least the DT blob compiled this time. Last time I tried something similar the dt compiler just came up with some weird syntax error.

Maybe this is something worth exploring a bit further, or maybe I should just move on and put my entire focus on my 3.14 development tree once I've fixed the s-pen/mm issue with valexKernel.

Backporting is generally easier than forward-porting, but if I'm going to spend more time on this whole MCPM nonsense I'll probably end up in a mental institution haha!

 

[Andmoreagain]

You have only been using four cores alternating even on TW. AOSP developers are trying to fix this.

Regarding this, if we are going for a full board-file-to-device-tree migration and a newer kernel version there are some things that need to be taken into account as far as Android itself goes, and it has mostly to do with the GPU userspace drivers.

On one hand we have these: https://github.com/sigma-1/libdrm_exynos
But libdrm is not enough for full open source GPU support. There used to be a project trying to accomplish full hw acceleration with Mali GPUs but I'm not exactly sure if it's still operational.

On the other hand there are the proprietary drivers from ARM, but they haven't really provided any userspace drivers for Android on their website, only the fbdev/X11 variants for Exynos 5 dev boards running standard Linux distros.

The kernelspace drivers are hard to integrate properly but the version currently implemented in my 3.14 tree is r4p0 and it has platform support for exynos5420 (Arndale Octa) thanks to the Linaro guys. The userspace drivers are still missing though so that's something that needs to be resolved.

 

[legolas93]

Hi. I've just bought P600 and i'm waiting for it to arrive.

Yours seems a really interesting work.
Maybe i will try to help you.
(Mmm..No, as now I don't think i can port the LCD driver eheh)

But i've got some questions:
- V3 is based on v2.0 - RC2 or v2.0 - MCPM-testing? If it based on v2.0 - MCPM-testing, are stability issues solved?
- V2 is good for SPEN? Maybe i can help you in finding the commit that need to be reverted..

And the last one for now:
I read that you are trying with Linux 3.14. seems we cannot use stock Mali driver. Is this correct?
Seems a bit of a problem.. Did you do another test with MCPM/octa core hack from 3.8 with i2c bits added?


PS: Which ROM are you testing your kernel with?

 

[enotar]

Any way to have Fsync off? Thanks

Sent from my SM-P600 using Tapatalk

 

[Koserman]

Your kernel is running flawlessly on Temasek's V16.2. Thank you very much!

 

[mosimchah]

Nevermind

---------- Post added at 11:08 AM ---------- Previous post was at 11:07 AM ----------

Your kernel is running flawlessly on Temasek's V16.2. Thank you very much!

The latest version is 17.0

Sent from my SM-P600 using XDA Free mobile app

 

[Koserman]

I haven't updated to the latest version which is why I specified what version I was on.

 

[Kpod]

Not bad. I'm running latest Temasek, found CM great but something was royally messed with sketchbook pro performance. So not wanting to go back to stock, I tried out this kernel. Profit! Can't wait to see what else is coming downstream.
Here are my benchmark results, close.