Occasional fail to initiate resume by incoming call, easy workaround proposed

Andy Green andy at openmoko.com
Mon Feb 9 14:51:12 CET 2009

Hash: SHA1

Somebody in the thread at some point said:
| Andy Green <andy at openmoko.com> writes:
|> Somebody in the thread at some point said:
|> | Calypso will not generate any interrupt until it sees CTS_MODEM fall
|> | for the first time after powering on. That leads to inability to
|> | trigger a first resume by calling or sending an SMS after turning on
|> | GSM and suspending.
|> |
|> | Userspace workaround:
|> |
|> | After the Calypso is powered on, do "echo 1 >
|> | /sys/bus/platform/devices/neo1973-pm-gsm.0/flowcontrolled; echo 0 >
|> | /sys/bus/platform/devices/neo1973-pm-gsm.0/flowcontrolled"
|> Shouldn't this be dealt with as part of the neo1973-pm-gsm ON action?
| Well that depends on the timing. I'm not sure it will work right after
| powering on, probably 1-2 sec delay will be needed. And it should be
| fixed in modem firmware anyway.

Not everybody will upgrade their modem firmware: but if it's possible to
fix it there then yes, it's the best place.

I look a look in the neo1973-pm-gsm stuff and we separately allowed
control of power_on and reset already, which was maybe not the best
idea.  But actually whether we msleep() in there or in an init / script
it's the same end result.

Maybe what we should do there is deprecate the reset control thing, bind
the sequencing for reset into the power_on thing along with toggling the
flowcontrolled state.  That's what we did for GTA03, sort of one stop
shop for powering it on with minimal knowledge about the device needed
then on rootfs.

- -Andy
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org


More information about the openmoko-kernel mailing list