[Atrix 4G Android Development] 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, [MENTION=4641721]krystianp[/MENTION] 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.