[KERNEL] [3.1.10] Olympus (Atrix 4G) Kernel Project

[PolesApart]

@krystianp @Zn7mkUKzN1r8aCIV I think I've found why the wlan is not taking the cpu out of deep sleep. At least for the bcmdhd scenario (I didn't look to see how bcm4329 was hooked).

On bcmdhd there are two modes of operation. With so-called Out-of-Band Interrupts and without. With it, there's a dedicated pin for irq. This pin could be set to wake the cpu as usual. The thing is that in current setup, we're using the driver without OOB interrupts, i.e. notifications in form of interrupts comes from SDIO events. The bcm chip is programmed to drive it's pin as a interrupt selectively, so it probably just sets idle when OOB mode is not in use, therefore we couldn't simply cheat and enable_irq_wake() (or something) on the pin, as it would either do nothing or permanently inhibit deep sleep.

I enabled the OOB interrupts and although the system boots up to the lock screen, it reboots in the sequence, probably from a crash - and I lack the machinery (jtag?) to capture the kernel dump at that point.

With the bcmdhd, the steps would be to fix whatever is causing this, and then see if there's need for enable_irq_wake() or something.

 

[attrixnor]

Hello Dev Team
could you precise the actual source kernel link to use for this kernel. (because Krystianp kernel seems to be not updated since one month, PolesApart kernel seems ok )
why don't you use the same github for futur update ?
although , thank for all

 

[PolesApart]

Hello Dev Team
could you precise the actual source kernel link to use for this kernel. (because Krystianp kernel seems to be not updated since one month, PolesApart kernel seems ok )
why don't you use the same github for futur update ?
although , thank for all

The official kernel, currently maintained by @krystianp for both cm9, cm10 and Z's kitkat is at https://github.com/CyanogenMod-Atrix/android_kernel_motorola_olympus/ .

The branch I maintain is forked from it, it's *way* experimental and for Z's kitkat only. Also I'm not part of the dev team or actually any team, <sarcasm>I'm just a trouble maker trying to burn it's own phone</sarcasm>.

I'm merging fixes/updates from different sources and if and only if they prove useful and minimally stable, I'll ask krystianp to merge. Of course he may cherry pick anything in there. The ext4 fixes (hmmm perhaps I didn't push these yet, but if not, will soon) all comes from upstream, the mm changes comes from faux123 and other sources. IIRC There's also a few memory leaks that comes from upstream (either linux itself or google android branch).

I currently cannot recommend people to try my branch as some changes may set your house on fire, kill your neighbor, or, more likely, bring some damage to your phone or data loss. If and only if I see some improvement such as make the phone reboots less, then I'll post an experimental zip update to kitkat's thread, as I don't want to unnecessarily bother krystianp as I'll be the one to blame for whatever.

 

[attrixnor]

ok, it's clear now
but for me you have join the dev team

 

[PolesApart]

Bluetooth wake

I've tracked down the following messages to bcm4329_rfkill.c
It seems the desired effect of enabling/disabling wakepads for the bluetooth pins are not exactly working.

<3>[  122.179910] Failed gpio lp0 enable for irq=353, error=-22
<3>[  122.193628] Failed gpio lp0 enable for irq=353, error=-22 
<4>[  123.193661] ------------[ cut here ]------------
<4>[  123.193704] WARNING: at kernel/irq/manage.c:510 irq_set_irq_wake+0xbc/0xec()
<4>[  123.193714] Unbalanced IRQ 353 wake disable
<4>[  123.193720] Modules linked in: bcmdhd
<4>[  123.193757] [<c0014418>] (unwind_backtrace+0x0/0xec) from [<c004d1f4>] (warn_slowpath_common+0x54/0x64)
<4>[  123.193774] [<c004d1f4>] (warn_slowpath_common+0x54/0x64) from [<c004d234>] (warn_slowpath_fmt+0x30/0x40)
<4>[  123.193790] [<c004d234>] (warn_slowpath_fmt+0x30/0x40) from [<c009009c>] (irq_set_irq_wake+0xbc/0xec)
<4>[  123.193820] [<c009009c>] (irq_set_irq_wake+0xbc/0xec) from [<c03018d8>] (enter_lpm+0x54/0x84)
<4>[  123.193848] [<c03018d8>] (enter_lpm+0x54/0x84) from [<c006b1f0>] (__run_hrtimer.isra.33+0x44/0xd4)
<4>[  123.193866] [<c006b1f0>] (__run_hrtimer.isra.33+0x44/0xd4) from [<c006bb0c>] (hrtimer_interrupt+0x104/0x27c)
<4>[  123.193882] [<c006bb0c>] (hrtimer_interrupt+0x104/0x27c) from [<c00131ac>] (ipi_timer+0x38/0x40)
<4>[  123.193897] [<c00131ac>] (ipi_timer+0x38/0x40) from [<c0008338>] (do_local_timer+0x60/0x74)
<4>[  123.193918] [<c0008338>] (do_local_timer+0x60/0x74) from [<c000de14>] (__irq_usr+0x34/0xc0)

 

[Zn7mkUKzN1r8aCIV]

I've tracked down the following messages to bcm4329_rfkill.c
It seems the desired effect of enabling/disabling wakepads for the bluetooth pins are not exactly working.

<3>[  122.179910] Failed gpio lp0 enable for irq=353, error=-22
<3>[  122.193628] Failed gpio lp0 enable for irq=353, error=-22 
<4>[  123.193661] ------------[ cut here ]------------
<4>[  123.193704] WARNING: at kernel/irq/manage.c:510 irq_set_irq_wake+0xbc/0xec()
<4>[  123.193714] Unbalanced IRQ 353 wake disable
<4>[  123.193720] Modules linked in: bcmdhd
<4>[  123.193757] [<c0014418>] (unwind_backtrace+0x0/0xec) from [<c004d1f4>] (warn_slowpath_common+0x54/0x64)
<4>[  123.193774] [<c004d1f4>] (warn_slowpath_common+0x54/0x64) from [<c004d234>] (warn_slowpath_fmt+0x30/0x40)
<4>[  123.193790] [<c004d234>] (warn_slowpath_fmt+0x30/0x40) from [<c009009c>] (irq_set_irq_wake+0xbc/0xec)
<4>[  123.193820] [<c009009c>] (irq_set_irq_wake+0xbc/0xec) from [<c03018d8>] (enter_lpm+0x54/0x84)
<4>[  123.193848] [<c03018d8>] (enter_lpm+0x54/0x84) from [<c006b1f0>] (__run_hrtimer.isra.33+0x44/0xd4)
<4>[  123.193866] [<c006b1f0>] (__run_hrtimer.isra.33+0x44/0xd4) from [<c006bb0c>] (hrtimer_interrupt+0x104/0x27c)
<4>[  123.193882] [<c006bb0c>] (hrtimer_interrupt+0x104/0x27c) from [<c00131ac>] (ipi_timer+0x38/0x40)
<4>[  123.193897] [<c00131ac>] (ipi_timer+0x38/0x40) from [<c0008338>] (do_local_timer+0x60/0x74)
<4>[  123.193918] [<c0008338>] (do_local_timer+0x60/0x74) from [<c000de14>] (__irq_usr+0x34/0xc0)

Do you have any clues to fix it? me thinks only K / M know how to do these irq stuffs with tegra2 soc... Thx a lot for being still around

 

[PolesApart]

Do you have any clues to fix it? me thinks only K / M know how to do these irq stuffs with tegra2 soc... Thx a lot for being still around

I'm looking a bit deeper. It seems that the approach for the bluetooth module to wake the cpu isn't formally right, altough it might be working anyway (or not, but I don't think we would notice).

On another subject, I've enabled the ram console (which saves the last syslog entries on /proc/last_kmsg in case of a crash) and I'm using it to debug the wifi w/ the dedicated irq handler (as per one of my previous messages). There's a NULL pointer dereference in the driver, although fixing it won't make the driver work, it'll only prevents a reboot. But I was bored and decided to debug the reboots triggered by leaving the phone idle when powered on battery and both mobile data and wifi on, and then checking /proc/last_kmsg.
I don't like what I don't see in there: I expected a kernel crash, that would be (relatively) easy to fix. What I see instead (repeatedly) is the phone leaving deep sleep, the wifi reconnecting to AP, and crashing afterwards. No indication of a driver problem, so it can either means the crash is very bad deep inside an irq handler or some other deep low-level thing (that could crash before the system had a chance to log it), or it's not triggered by the tegra cpu at all.

I have a few theories but no data to support them. One is that there's a bad interaction between the CPCAP (the power controller, it's actually a Texas Instruments TPS65950 / TWL5030 which Motorola rebrands), the modem and the CPU. The CPCAP is responsible for powering all devices and it have a builtin firmware with some monitors and both software and hardware watchdogs. If something is not done in the right sequence or time, the CPCAP may assert a hard reset on everything (that would mean a reboot). For instance, suppose for some reason on our side (i.e. kernel) we leave some CPCAP notification masked out, i.e. the cpu don't wake up from deep sleep to service this notification. CPCAP could assume the cpu crashed and assert a reboot. If the modem crashes and is not serviced by the cpu while in deep sleep, the CPCAP could detect that (I don't have evidence that it does) and reboot too.

I'll keep digging on spare time

 

[Zn7mkUKzN1r8aCIV]

I'm looking a bit deeper. It seems that the approach for the bluetooth module to wake the cpu isn't formally right, altough it might be working anyway (or not, but I don't think we would notice).

On another subject, I've enabled the ram console (which saves the last syslog entries on /proc/last_kmsg in case of a crash) and I'm using it to debug the wifi w/ the dedicated irq handler (as per one of my previous messages). There's a NULL pointer dereference in the driver, although fixing it won't make the driver work, it'll only prevents a reboot. But I was bored and decided to debug the reboots triggered by leaving the phone idle when powered on battery and both mobile data and wifi on, and then checking /proc/last_kmsg.
I don't like what I don't see in there: I expected a kernel crash, that would be (relatively) easy to fix. What I see instead (repeatedly) is the phone leaving deep sleep, the wifi reconnecting to AP, and crashing afterwards. No indication of a driver problem, so it can either means the crash is very bad deep inside an irq handler or some other deep low-level thing (that could crash before the system had a chance to log it), or it's not triggered by the tegra cpu at all.

I have a few theories but no data to support them. One is that there's a bad interaction between the CPCAP (the power controller, it's actually a Texas Instruments TPS65950 / TWL5030 which Motorola rebrands), the modem and the CPU. The CPCAP is responsible for powering all devices and it have a builtin firmware with some monitors and both software and hardware watchdogs. If something is not done in the right sequence or time, the CPCAP may assert a hard reset on everything (that would mean a reboot). For instance, suppose for some reason on our side (i.e. kernel) we leave some CPCAP notification masked out, i.e. the cpu don't wake up from deep sleep to service this notification. CPCAP could assume the cpu crashed and assert a reboot. If the modem crashes and is not serviced by the cpu while in deep sleep, the CPCAP could detect that (I don't have evidence that it does) and reboot too.

I'll keep digging on spare time

learnt a lot from your writings, Thx. finally flashes of light in this endless tunnel

 

[PolesApart]

What I could find out is that we have these GPIOs being passed to the irq_set_irq_wait() at some point or another:
TEGRA_GPIO_PU1
TEGRA_GPIO_PM0
TEGRA_GPIO_PM1
TEGRA_GPIO_PT0
TEGRA_GPIO_PU1

The problem is that none of them are allowed in deepest sleep level (LP0), so the API is complaining. It seems that the API has provisions for blocking LP0 entry and selecting LP1 instead (where the Interrupt controller should remain functional and any interrupt can wake the cpu again), but for some reason it's barking instead. I don't think it's successfully blocking LP0 entry, and it seems intentional.

If it would accept the IRQs and force LP1, any could wake the system, which I think could cost a lot in terms of battery (but perhaps I'm wrong: how often do these fire? These interrupts seems to be masked in/out as necessary, at least they could be). I suspect some tuning would be required to work that way. Anyway the support for LP1/LP0 arbitration seemed a bit too fragile, perhaps it was incomplete by the time the kernel was sourced.

On the other hand, and it's our scenario today, having these periferals behaving as they do now, they won't be serviced when the phone sleeps.

To make the long story short, I do believe that in the state the kernel it is today, it's better to leave this unchanged for now. The possible non-conformant scenario today is the wifi, as it can't wake the system. I plan to dig a little into it later (trying to fix the bcmdhd to work when CONFIG_BCMDHD_HW_OOB=y). The rest of the IRQs aren't really needed (AFAIK) as wake sources. The bluetooth module seems to - somehow - be able to take the phone out of the deep sleep, I don't know if the right pin is doing this or if it is through the serial port( tegra serial ports seems to be in the wakeup-capable list). Sometimes it takes quite a while, but my bluetooth headphone seems to be able to connect to the phone in 95% of the attempts. And in those 5% that it fail, I do believe it connects fine in the 2nd attempt, I never had to wake up the screen in order to do that (like I need to do with the wifi).

Sorry for flooding this, @krystianp is probably aware of all that, but I wish to share where I was pooking around and perhaps document it here so other people can contribute too.

On a side note, I'm looking at it because I was able to advance on the diagnostics (at least I think so, comparing to what I didn't know), but the main issues we would really have to tackle are the random reboots and the battery drain. I'm convinced that even if we had a perfect dynamic deep sleep setting today (we already have a static one, i.e. the phone really consumes little power when sleeping) from the kernel point of view, it would really contribute very little to the overall battery uptime ability: the main source of consumption seems to come from userspace wakelocks. The most hungry ones today accordingly to diagnostics programs seems to be the google cell location ones. But this is probably not caused directly by this: on the old android days, we had almost no wakelock straight in the kernel. And even on android userspace, there were modest usage and IIRC the api was a little different. In our case we had a nvidia middleware in both user and kernel space managing most of this stuff. Now android makes heavy use of it and kernel have internal usage too, so the semantics are different but google put a lot of testing efforts and cpu processing power evolves faster than battery, yet we have current generation phones with equal-or-higher idle-time. I suspect the RIL was fine-tuned, yet ours probably comes from the old days, without this tuning. Perhaps it caches google location requests/reports, have the modem configured to report them less often or just when changing, etc.

Sorry for the long thread, guys, I got carried away.

 

[PolesApart]

Progress

@Zn7mkUKzN1r8aCIV With a small patch and a change to .config wifi is now working fine in deep sleep. I'm not sure if this is enough to make notifications arrive in a decent time, but it's a must have.

This is the patch.
As you know I have made a lot of changes to my fork at github, so I can't be 100% sure this will work on the mainstream kernel, but I don't see why not.

Cheers!
P.S..: I'll test a little longer, and if we have demand I can push an update zip w/ a kernel image on kitkat thread for people to test.

 

[Zn7mkUKzN1r8aCIV]

@Zn7mkUKzN1r8aCIV With a small patch and a change to .config wifi is now working fine in deep sleep. I'm not sure if this is enough to make notifications arrive in a decent time, but it's a must have.

This is the patch.
As you know I have made a lot of changes to my fork at github, so I can't be 100% sure this will work on the mainstream kernel, but I don't see why not.

Cheers!
P.S..: I'll test a little longer, and if we have demand I can push an update zip w/ a kernel image on kitkat thread for people to test.

So you fixed wifi wakelock!!! I will try to setup the phone to test your patch Thx. a lot!!!

 

[attrixnor]

great news
for sure ,i think your contribution is appreciate by all atrix users
thanks for your work

 

[PolesApart]

So you fixed wifi wakelock!!! I will try to setup the phone to test your patch Thx. a lot!!!

This change requires the CONFIG_BCMDHD_HW_OOB=y in kernel config in order to do anything, but I'm having decent results. Posted a compiled test kernel on your thread today. Sometimes I see erratic behavior i.e. Typing on SSH takes a few secs to come back from deep sleep. But I think the fact that I'm far from my Wi-Fi AP have something to do with it.

On a side-note (but kernel related), I remember you were trying to setup Kitkat to support full-device encryption. It seems we would need to port/merge dm-verify into kernel in order to support that. I don't know what else we would require (I've bookmarked this: http://nelenkov.blogspot.com.br/2014/05/using-kitkat-verified-boot.html - but haven't read it yet).

It seems this will become a standard (mandatory?) feature as of Android L.

 

[Zn7mkUKzN1r8aCIV]

This change requires the CONFIG_BCMDHD_HW_OOB=y in kernel config in order to do anything, but I'm having decent results. Posted a compiled test kernel on your thread today. Sometimes I see erratic behavior i.e. Typing on SSH takes a few secs to come back from deep sleep. But I think the fact that I'm far from my Wi-Fi AP have something to do with it.

On a side-note (but kernel related), I remember you were trying to setup Kitkat to support full-device encryption. It seems we would need to port/merge dm-verify into kernel in order to support that. I don't know what else we would require (I've bookmarked this: http://nelenkov.blogspot.com.br/2014/05/using-kitkat-verified-boot.html - but haven't read it yet).

It seems this will become a standard (mandatory?) feature as of Android L.

For full-device (actually /data) encryption, the major problem from 10.1 -> 11.0 is that /data cannot be umounted to start the encryption process. I tried many many ways (safe boot (longpress reboot), manually disabled services and so on, /data simply does not umount to start with.

I was thinking of compiling a static vold to run in recovery (given /data is unmount in recovery mode) to start encryption, but seems Android L is going to have encryption as default, I am on the sideline at this moment...

Again thx. for fixing the wifi wakelock bug!!!

 

[ravilov]

For full-device (actually /data) encryption, the major problem from 10.1 -> 11.0 is that /data cannot be umounted to start the encryption process. I tried many many ways (safe boot (longpress reboot), manually disabled services and so on, /data simply does not umount to start with.

That happens when there's a process running that has files open on a specific mountpoint. lsof usually helps to identify such processes. Most likely it is some system service, such as battd.

 

[rhcohen]

For full-device (actually /data) encryption, the major problem from 10.1 -> 11.0 is that /data cannot be umounted to start the encryption process. I tried many many ways (safe boot (longpress reboot), manually disabled services and so on, /data simply does not umount to start with.

I was thinking of compiling a static vold to run in recovery (given /data is unmount in recovery mode) to start encryption, but seems Android L is going to have encryption as default, I am on the sideline at this moment...

Again thx. for fixing the wifi wakelock bug!!!

This is a bit off the current sub-thread -- but with such amazing progress lately on the kernel, I thought I would ask -- I will likely have some time in the next month to help on kernel debug/development. An issue that I had concluded was kernel related was the random behavior of the microphone in Skype and some other apps -- sometimes the mic works, sometimes the other party just gets white noise. I previously posted a problem that I think is related, which is stereo recording apps (e.g. RecForge) sometimes recording one only one channel. I see these problems (skype and recording apps) with both CM10.1 and CM11, but not if I go back to CM10 (different kernel), so I think it is somewhere in the current kernel. Any thoughts about where to look?

 

[PolesApart]

This is a bit off the current sub-thread -- but with such amazing progress lately on the kernel, I thought I would ask -- I will likely have some time in the next month to help on kernel debug/development. An issue that I had concluded was kernel related was the random behavior of the microphone in Skype and some other apps -- sometimes the mic works, sometimes the other party just gets white noise. I previously posted a problem that I think is related, which is stereo recording apps (e.g. RecForge) sometimes recording one only one channel. I see these problems (skype and recording apps) with both CM10.1 and CM11, but not if I go back to CM10 (different kernel), so I think it is somewhere in the current kernel. Any thoughts about where to look?

As @krystianp have been working on audio issues for quite a while now, I recommend you start by studying the github changes of his latest changes (I personally prefer latest-to-oldest reading) and trying to understand them. I myself know nothing about audio in both kernel and userspace (I think the last time I looked in ALSA code it was just merged in Linux kernel, by about linux 2.0. Boy, I'm getting old).

I myself would like to work in everything battery charging related, so that we would have fine charging and discharging statistics, including charging up to 100%, whatever that means. But I'm also clueless of where to start at this point, and a bit short on spare time.

Another areas I would like to look at are getting 5GHz Wifi to work (I suspect it's not kernel related, though, at least the sources from where I've merged bcmdhd updates are supposed to be ok on that regard) and HDMI. It seems HDMI is pretty much functional accordingly to Krystianp's video(s) on youtube, I think we just need to detect the plug event somehow and direct it to some form of "enable this output" command. I'll try to manually do this last part and if it works, we're in game.

 

[rhcohen]

As @krystianp have been working on audio issues for quite a while now, I recommend you start by studying the github changes of his latest changes (I personally prefer latest-to-oldest reading) and trying to understand them. I myself know nothing about audio in both kernel and userspace (I think the last time I looked in ALSA code it was just merged in Linux kernel, by about linux 2.0. Boy, I'm getting old).

I myself would like to work in everything battery charging related, so that we would have fine charging and discharging statistics, including charging up to 100%, whatever that means. But I'm also clueless of where to start at this point, and a bit short on spare time.

Another areas I would like to look at are getting 5GHz Wifi to work (I suspect it's not kernel related, though, at least the sources from where I've merged bcmdhd updates are supposed to be ok on that regard) and HDMI. It seems HDMI is pretty much functional accordingly to Krystianp's video(s) on youtube, I think we just need to detect the plug event somehow and direct it to some form of "enable this output" command. I'll try to manually do this last part and if it works, we're in game.

Thank you for the suggestions. RE audio I will have a look. Last time I had posted about this (months ago) github commits were way behind the kernel zips that @krystianp was posting at dropbox; seems like that has changed. RE 5GHz Wifi, it works on my phone. As does battery charging to 100%. (I am running CM11 v3 with your 1027 kernel). So hard to work on these problems when they are only problems on some variations of the same model phone. So getting back to audio, it would be nice to know if Skype works every time for anyone, and if so, what are the particulars of that phone (CM version, kernel, and hardware specifics).

 

[Mustkeg]

As @krystianp have been working on audio issues for quite a while now, I recommend you start by studying the github changes of his latest changes (I personally prefer latest-to-oldest reading) and trying to understand them. I myself know nothing about audio in both kernel and userspace (I think the last time I looked in ALSA code it was just merged in Linux kernel, by about linux 2.0. Boy, I'm getting old).

I myself would like to work in everything battery charging related, so that we would have fine charging and discharging statistics, including charging up to 100%, whatever that means. But I'm also clueless of where to start at this point, and a bit short on spare time.

Another areas I would like to look at are getting 5GHz Wifi to work (I suspect it's not kernel related, though, at least the sources from where I've merged bcmdhd updates are supposed to be ok on that regard) and HDMI. It seems HDMI is pretty much functional accordingly to Krystianp's video(s) on youtube, I think we just need to detect the plug event somehow and direct it to some form of "enable this output" command. I'll try to manually do this last part and if it works, we're in game.

I pulled some logs while switching between AUTO, 5GHZ only and 2,4 GHz only.
AUTO is frequency band '0'. 5GHz is '1'. 2.4GHz is '2'.
The 'Failed to initiate AP scan' messages would appear "endless" if I didn't switch back to AUTO or 2.4GHz only.

I/WifiService(579):  WifiService trying to set frequency band to 0 with persist set to true
I/wpa_supplicant(6130):  wlan0: CTRL-EVENT-SCAN-STARTED 
I/WifiService(579):  WifiService trying to set frequency band to 1 with persist set to true
E/wpa_supplicant(6130):  wpa_driver_nl80211_driver_cmd: failed to issue private commands
W/wpa_supplicant(6130):  wlan0: Failed to initiate AP scan
W/wpa_supplicant(6130):  wlan0: Failed to initiate AP scan
W/wpa_supplicant(6130):  wlan0: Failed to initiate AP scan
W/wpa_supplicant(6130):  wlan0: Failed to initiate AP scan
I/WifiService(579):  WifiService trying to set frequency band to 2 with persist set to true
I/wpa_supplicant(6130):  wlan0: CTRL-EVENT-SCAN-STARTED

Hope that helps!

 

[Fozix]

5GHz Wifi, it works on my phone

What is your version of radio module? And how you checked that 5 GHz works?
And can you specify all settings? Channels, band, etc.