mpc52xx_uart.c - Port Overruns

[Damien Dusha]

Dear List,

I am writing to ask about some particular behaviour we saw with the MPC5121
PSC UART, using the 2.6.24 Freescle BSP kernel, although examining the code
of the linux-2.6-denx tree (git commit
7cb16ec2590815a67e5fb5c8994ead536613d922), the behavior is almost identical
except for incrementing an overrrun counter.

In particular, yesterday we observed a port overrun (from the overrun flags
being set when looking with the BDI) on one of our PSC Ports.   When it was
observed, we saw that every second byte coming from the serial port was
0x00.

Examining the interrupt routine of the mpc52xx_uart.c:

static inline int
mpc52xx_uart_int_rx_chars(struct uart_port *port)
{
<snip>
        tty_insert_flip_char(tty, ch, flag);
        if (status & MPC52xx_PSC_SR_OE) {
            /*
             * Overrun is special, since it's
             * reported immediately, and doesn't
             * affect the current character
             */
            tty_insert_flip_char(tty, 0, TTY_OVERRUN);
            port->icount.overrun++;
        }
<snip>
}

So, from my deduction, it is inserting a 0x00 for every overrun error that
occurs, however, the overrun flag is never cleared.  Therefore fro every
byte that is received, the overrup flag is still set and therefore we're
observing the 0x00 being inserted for every "real" byte coming into the port


Is there a particular reason why the overrun flag is not cleared? That is,
parity, framing and breaks are acknowledged with:

            /* Clear error condition */
            out_8(&PSC(port)->command, MPC52xx_PSC_RST_ERR_STAT);

But the overrun isn't cleared.   Is there are particular reason why?  Is
userspace meant to detect this condition and reset the port?  Was it
automatically cleared on the 5200 when reading the status, but the 5121 is
exhibiting strange behavior?

Best regards,
Damien Dusha.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20090703/79362197/attachment.htm>