GTA01 shared UART vs. flow control (bug #788)
balrogg at gmail.com
Tue Jan 22 17:33:30 CET 2008
On 22/01/2008, Werner Almesberger <werner at openmoko.org> wrote:
> This is a discussion we're taking from bugzilla to the list, for
> greater convenience. The whole background can be found here:
> Here's a quick summary. I just stumbled into this one yesterday,
> so please excuse (and correct) any misunderstandings.
> The problem:
> GTA01 shares its 1st UART between the serial kernel console (i.e.,
> the debug board) and the GSM modem. The UART signals are switched
> between console and GSM with the GSM_EN line. GSM_EN (and another
> signal, simulating the modem's "on" button), is controlled by
> writing to /sys/bus/platform/devices/.../power_on
> The GSM modem has hardware flow control but the console doesn't.
> So what happens is that, if flow control is enabled and the UART
> is switched to the serial console, the next printk will hang the
> kernel, waiting for flow control to signal that data can be sent.
Well, I'd define the problem completely differently.
The s3c24xx serial driver does busywaiting in the main thread, and
generally sucks in many ways. IMHO it's not so difficult to fix (but
the only way I can prove that it's not difficult is by fixing it, so
you're free to not trust me now). This is a bug, it's an upstream bug
obviously but because of the console switching this project is
probably the first to hit it.
When hardware flow control is enabled and the hardware keeps the rts
signal low, the UART *should* block the input, so this behaviour is
correct (forcing flow control off would be doing something different
than the user requested, i.e. trying to be smarter than the user, we
know what this leads to from looking at a different popular OS), the
FIFO should fill and the driver should start dropping new characters
or indicate to the source of characters that it's stuck for the moment
- I think some other serial drivers handle this ok.
More information about the openmoko-kernel