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

[Joerg Reisenweber]

Dieter, could you look into that?

To whom it may concern: It also seems it turned out the kernel UART driver 
written by TI doesn't correctly handle STX/ETX resp. RTS/CTS handshake in a 
by-character granularity. A nice cause for buffer overruns, if that's a 
correct observation.

A third thing: in kernel we should mask/disable the calypso IRQ during calypso 
powerdown time, as it certainly isn't expected to see IRQs from a power-down 
modem, and state of this line during power-down isn't very well defined - 
might be floating. This could cause bogus resumes.

/j

Am Mo  9. Februar 2009 schrieb Paul Fertser:
> Hi,
> 
> Not exactly kernel issue, but since it is very low-level and affects
> all distributions, i hope this ML is appropriate enough.
> 
> Short summary:
> 
> 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"
> 
> Long story:
> 
> For quite some time i wondered why sometimes my FR doesn't resume on
> incoming call while pressing power button works perfectly.
> 
> Joerg was extremely helpful on IRC and spent considerable time
> discussing all kinds of wild guesses, ways to reproduce, possible
> races, irq handling techniques, testpoints access etc. Without his
> help i'd given up long time ago. Werner, mwester, lindi and Kensan
> also took part in discussions and gave plenty of good hints.
> 
> Finally a reproducible testcase was constructed and with a help of
> Werner's gpio tool it became obvious how the interrupt line works and
> why it fails for the first time.
> 
> Calypso is supposed to generate interrupt (via IO1 line, connected to
> EINT1/GPF1 at SoC side) in every case when it has some data to send to
> SoC but CTS_MODEM (NRTS0/GPH1) prohibits sending. It does that by
> pulling the line up and pulls the line down after CTS_MODEM is
> de-asserted (pulled down). The kernel is configured to react on edge
> rise, so the interrupt is generated and if device is suspended, resume
> is initiated.
> 
> The problem can be seen right after powering on the modem because it
> doesn't pull the IRQ line low on init and therefore it is unable to
> generate rise. Joerg believes that it's a firmware bug and should be
> fixed in the next version. If CTS_MODEM fall is somehow generated once
> (with sysfs node or suspending and resuming by other means), calypso
> finally pulls the line low and after that works as expected.
> 
> Sounds easy, doesn't it? ;)
> 
> -- 
> Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
> mailto:fercerpav at gmail.com
> 
> 
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://lists.openmoko.org/pipermail/openmoko-kernel/attachments/20090209/3a75e74e/attachment.pgp