<DocScrutinizer05>
one problem I suspect is with suspend-to-ram which is not a sensible mode for OMAP
<DocScrutinizer05>
the problem with modem as well as any power consumption issues may well be caused by improper implementation of this suspend state
<DocScrutinizer05>
one of the reasons to port maemo fremantle
<DocScrutinizer05>
it's known to provide proper power management on this platform
<DocScrutinizer05>
largely reduced number of kernel device drivers to check since they are "new"
<DocScrutinizer05>
suspend to ram also might have real hw problems, e.g with dangling/floating lines
<DocScrutinizer05>
OMAP isn't meant to suspend to RAM, it suspends in situ in the static CPU registers
<DocScrutinizer05>
the whole suspend concept been a botch born from a pinch OM been in, between available SoCs and the availablitiy of zero-clock on those
<wpwrak>
so OMAP's standby is inefficient ... because you can't shut down the power rails ?
<wpwrak>
floating lines sound more like a sw problem than hw. well, if they only float in "static"standby :)
<wpwrak>
i suppose you already searches for pull-ups and pull-downs ?
<DocScrutinizer05>
this is with wlan and IRC active!
<DocScrutinizer05>
N900
<wpwrak>
nice :)
<DocScrutinizer05>
do that with suspend-to-ram!
<DocScrutinizer05>
;-P
<DocScrutinizer05>
NB the device yells as soon as my name gets highlighted on IRC
<DocScrutinizer05>
with GTA02 and even usual distros on GTA04 you have a hard time getting 10h standby in this situation
<DocScrutinizer05>
ooh, I forgot: of course GSM modem onine as well
<DocScrutinizer05>
OMAP is particularly inefficient when USB fsckng mentorgraphics musb-core gets involved
<DocScrutinizer05>
ther are at least 3 power domains you need to take care about: CPU<->musb bus, musb-core itself, musb <-ULPI-> PHY
<DocScrutinizer05>
the whole crap eats 60mA just for being activated
<DocScrutinizer05>
and I guess when you mess up with deactivation, some data lines might float in undefined states
<DocScrutinizer05>
somebody did statistics and found a very strange 2mA granularity of suspend-to-RAM quiescent current
<DocScrutinizer05>
I guess 2mA for each data line that happens to be 1 (or 0) while other end is suspended, or sth like that
<DocScrutinizer05>
you recall similar problem with GTA02 display driver? deactivating video data and the video bus ate some 30mA worst case
<DocScrutinizer05>
depending on last pixel that been pending to get transfered to LCD
<DocScrutinizer05>
only cloudy memories here, but we definitely had sth like that
xiangfu has joined #qi-hardware
<DocScrutinizer05>
the GTA04 shouldn't eat more than ~10mA without any powerhogs like LEDs and TX and amps enabled. The OS guys need to check that first
<DocScrutinizer05>
unless we reach proper power consumption in idle, we don't even need to look at suspend at all