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

Werner Almesberger werner at openmoko.org
Mon Feb 9 21:47:14 CET 2009

Paul Fertser
> http://docs.openmoko.org/trac/ticket/1376

Thanks ! This one fell completely through the cracks :-( Wish we
had a competent bugmaster who does nothing but track such items ...

Andy Green wrote:
> Werner says he's eyeballed the code and doesn't see a problem.
> Therefore I don't see that there is a "multi character" handshake
> granularity in the GSM device from all this.  Do you see how to work
> that out from this?

Hmm, this one is a different sort of problem.

The software should respond "immediately" to changes in CTS. What
it does then is that it sets a flag that no more data should be sent
to the UART. That flag gets checked whenever there is a TX interrupt,
not only when we enqueue a new message. So far so good.

However, if I'm reading the code right, there's a huge TX FIFO in
the hardware: 64 bytes. I don't see any sign of hardware-assisted
flow control being used in the driver.

According to uartfax.c, the UART is a 16750:

This chip does have hardware-assisted flow control. You enable it
by setting bit 5 in MCR (cleared after reset). However, some of
the bits used in the Calypso driver differ or don't exist in the
16750 data sheet, so I don't know if the flow control is actually

Okay, this should be easy to fix:

1) add some way, AT command or whatever, to make the modem send
   lots of data, perhaps in an endless loop

2) make the CPU just ignore the data, force CTS with "gpio", and
   watch on a scope how long it takes the modem to react. Repeat
   a few times to get the range of possible responses.

3) set bit 5 (AFE) in MCR and retry

4) if this doesn't fix it, we can at least reduce the amount of
   data sent after CTS gets deasserted. This would be done by
   splitting FIFO_SIZE into RX_FIFO_SIZE and TX_FIFO_SIZE, and
   shrinking TX_FIFO_SIZE according to taste.

   GTA01 would need this to be set to just 1-2 bytes, which sucks.
   For GTA02, something like 30 should be fine.

Dieter, this is mainly wrestling with the firmware. Can you take
care of this one ? I can help if you need anything on the
Linux/kernel side.

- Werner

More information about the openmoko-kernel mailing list