A2109 Kernel Experiments

I made a fresh install of AOSP (I used before CM12.1 but found that it is a bit less stable then AOSP) and again try kernel 3.4.

At first it is faster then kernel 3.1 but the more I used the tablet it become slower and slower and also the tablet became hot in the right side. Then i reboot to kernel 3.1 and it works as usual in 3.1.
 
Is it possible to modify the kernel and lower a bit the CPU and GPU frequencies to make some testing?
 
I made a fresh install of AOSP (I used before CM12.1 but found that it is a bit less stable then AOSP) and again try kernel 3.4.

At first it is faster then kernel 3.1 but the more I used the tablet it become slower and slower and also the tablet became hot in the right side. Then i reboot to kernel 3.1 and it works as usual in 3.1.

Hmmm... Damn, AOSP is VERY hard to maintain, currently.

I'm assuming we still have the same problem of unpredictable sudden hangs (the whole thing about powergating of the GPU). I did test Angry Bird2 and it seems to quickly grind the tablet to a halt. Not a complete hang, but not usable either. Did you see the same problem with AOSP? How long did you test?

Is it possible to modify the kernel and lower a bit the CPU and GPU frequencies to make some testing?

Ehmmm.... Possibly, but not easily. I do know that there's one setting to disable GPU powergating, and I have no idea what that would mean for battery life. I'll test that later, but first I want to do another Lollipop build for security reasons. I did manage to port the kernel patches to 3.1.
 
@joebine, I think that disabling powergating for 3D works to fix the hangs. I've spent quite some time surfing the web today and playing Angry Birds 2 (on AOSP), no hangs yet, and battery drain seems acceptable:

Code:
diff --git a/drivers/video/tegra/host/t30/t30.c b/drivers/video/tegra/host/t30/t30.c
index 0f05701..2c161a9 100644
--- a/drivers/video/tegra/host/t30/t30.c
+++ b/drivers/video/tegra/host/t30/t30.c
@@ -124,7 +124,7 @@ struct nvhost_device_data t30_gr3d_info = {
        .powergate_ids = { TEGRA_POWERGATE_3D,
                           TEGRA_POWERGATE_3D1 },
        NVHOST_DEFAULT_CLOCKGATE_DELAY,
-       .can_powergate = true,
+       .can_powergate = false,
        .powerup_reset = true,
        .powergate_delay = 250,
        .moduleid       = NVHOST_MODULE_NONE,
 
Just fixed loading to 100%

*EDIT* This message was somewhat terse :)

I'm cleaning up a kernel patch for the charger that I took from Lenovo's original sources. It works around a problem that certain registers aren't updated anymore on kernel 3.4 with nvidia's driver. I've gotten the charger to detect a 2A wall charger, which greatly speeds up charger times, and I've gotten the charger to continue until the battery reaches 100%. Together with the previous patch, this means that kernel 3.4 seems good enough for most practical use. The only problem left is no sound over bluetooth.
 
Last edited:
Here are two new kernel images. You still need to manually disable HW overlays to use them normally, but they should be stable now, and they charge normally.

For AOSP: kernel-3.4-aosp-5.1.img (md5: de6988521c877879bd7b7a29f5c61556)
For CM-12.1: kernel-3.4-cm-12.1.img (md5: 5fa9ecc13b8fc5d10444fb7d626bc9bd)

NOTE - for proper testing you really need to wipe cache and dalvik cache. Also, it sometimes doesn't boot on first boot, just try it twice. And finally, make sure that you've turned up brightness quite high, somehow CM otherwise often turns up with a dark screen.

These images are based on the same kernel that Ziyann used for grouper on Marshmallow. So that's the perspective :)
 
Last edited:
I Try kernel 3.4 with AOSP 5.1.1 for almost 3 hours non stop and it is working really well even better then kernel 3.1.

- I didn't get any hangs.
- After 3 hours the battery was at 15% and it was full when i start using it.
- I notice that the tablet become hot in the top part of it, hotter than usual compare to my other tablet with kitkat but still working well.

I will try to recharged it over night to see. I will get back tomorrow.

Great job PJBrs
 
Last edited:
@joebine Thanks very much for the quick test!

Are you 100% sure that your new kernel booted correctly? You can check the version in a shell (e.g., install terminal or open shell via abd) with the following command:

Code:
uname -r

(Not entirely sure that AOSP has this though...)

Output should be:
Code:
3.4.67-g62fb6a2-dirty

Hadn't checked this exact version yet myself, but it *should* work...
 
Are you 100% sure that your new kernel booted correctly? You can check the version in a shell (e.g., install terminal or open shell via abd) with the following command:

The command listed did not worked but in tablet properties it say:

3.4.67-g62fb6a2-dirty

Also, I unplug the tablet this morning (at around 6 AM) and the battery was at 96% and it was on charge (original Lenovo 2A charger) for 7 hours.

I left the tablet on the counter all day while I was at work and when I take it at 5h30 PM the battery was charged at 70% so it lost a lot of battery power for doing nothing.
 
This morning the tablet was recharged to 96% ...:(

Sigh... That's the strangest thing. On CM it works. So I tried with AOSP. I got it up to 98% and then it stalled... GRRRRR!!!

I left the tablet on the counter all day while I was at work and when I take it at 5h30 PM the battery was charged at 70% so it lost a lot of battery power for doing nothing.

Mine did so too yesterday, but after that battery use leveled out. Further hacking on the charger.
 
Still working well, better then kernel 3.1 but CM12.1 is less stable then AOSP.
Okay. (Agreed.) Did it charge to 100% like mine?l

I've tried to completely put back the Lenovo changes to the charger driver but it didn't really work. Trouble starts pretty soon with a "Scheduling while atomic" bug. The driver then loads normally, but we don't get interrupts.

I have an idea though. My impression is that when the battery is almost full, the charger needs to detect this and stop with "fast charging." I did work around the interrupt problem and re-implemented a "kernel thread" that is able to monitor the main status registers for the charger. There are only six, and they change according to charging type (fast charging, taper charging, ...), charger type (USB, AC), and some other info I don't understand. I'm assuming that they'll change specifically when the charger reaches ~ 96%. And then we should change the charging strategy.

Working on it.
 
Last edited:
Back
Top