[pkg-fso-maint] debian: issues with latest packed fso

arne anka openmoko at ginguppin.de
Sat Jun 13 12:36:32 UTC 2009


> I read that on Michael Lauer comments #55:
>
>   #1024 will not be fixed by a hardware exchange. All current
>   distributions have a satisfying workaround, the real issue is still
>   undergoing research wrt. GSM firmware.
>
> Still I do not know which are these workarounds.

the only one _i_ know, is the already mentioned "no deep sleep ever".

>> ti_calypso_deep_sleep = never
>>
>> in frameworkd.conf.
>
> I do not remember I have experienced similar problems, thus I have never
> played with that value, sorry.

oh, i only played with it hoping for longer standby.

> Do you mean that disabling deep-sleep (which I guess is something
> implemented in hardware) and with proper power management (implemented
> in software) you will increase stand-by time?

here comes, how i understand it:

1)
disabling deep sleep is, afaiu, done by an at command (SLEEP=2).
since the modem thus never reaches the deep sleep state, it will consume  
more power than when deep sleeping -- and decrease standby.
when using deep sleep, standby may increase by up to 25%, but that will  
work only if the calypso really does deep sleep. if not, it will wake up  
frequently, causing far more drain than SLEEP=2.
if one does not like SLEEP=2, one has to get a hw fix, which is not  
recommended due to the amount of work and increased likelihood to break  
the fr.

conclusion: SLEEP=2 / ti_calypso_deep_sleep=never decreases standby  
compared to SLEEP=4 / ti_calypso_deep_sleep=always because the best power  
save state is never reached.

fso has iirc an algorithm, that tries to detect if deep sleep is usable or  
not. with my fr and the current debianized fso that algorithm apparently  
fails.


2)
improved power management by the kernel (and in userspace?) should  
increase standby independently of deep sleep -- and may make the  
differences between SLEEP=4 (deep sleep) and SLEEP=2 (no deep sleep)  
marginal.

1) and 2) are independent of each other, inhowfar the independently  
achieved increase in standby adds up, i don't really know.
but out of _personal_ interest, once i get the opportunity, _i_ will get  
that hw fix for #1024; just to get rid of it.

still, it would be nice to have some timeline for a newer fso ...

ps:  could you please send me your bank account data again? while cleaning  
up my inbox i deleted that mail, too.



More information about the pkg-fso-maint mailing list