Messages in this thread | | | Date | Tue, 24 Jan 2006 11:24:42 +0900 (JST) | Subject | Re: [PATCH] serial: serial_txx9 driver update | From | Atsushi Nemoto <> |
| |
>>>>> On Mon, 23 Jan 2006 19:49:30 +0000, Russell King <rmk+lkml@arm.linux.org.uk> said: >> Yes, in this case I will read ABCDEFG without error, and then H >> with an overrun error. But the UART still hold "I" in its "read >> buffer". The "read buffer" is exist outside the receiver FIFO. So >> if 'J' comes in later, I will read "IJ". There is no way to clear >> the "read buffer" except resetting the UART.
rmk> Ok, so if someone sent you ABCDEFGHIJ, all before you could read rmk> anything from the UART, where I causes an overrun, you'll read rmk> ABCDEFGHJ, but the status associated with H will indicate an rmk> overrun condition?
Partially incorrect. With or without the patch, "H" will indicate an overrun.
If someone sent me "ABCDEFGHI(...long delay...)J", all before I could read "ABCDEFGH", NUL with TTY_OVERRUN, then "IJ". With the patch, I will read "ABCDEFGH", NUL with TTY_OVERRUN, then "J".
I do not want to read "I" after long delay. Dropping the "I" is not a problem while I can know that an overrun happened there.
rmk> Your overrun behaviour is near enough to typical 8250 behaviour rmk> that you can use the helper provided - uart_insert_char(). This rmk> eliminates the special flag handling you seem to have created.
I suppose typical 8250 will drop "I". The TXX9 UART does not (it is described in the datasheet. Not a bug).
I have been using uart_insert_char() and it helps me to pass NUL (with TTY_OVERRUN) after "H" char. But the it is not enough to handle this queer behavior.
--- Atsushi Nemoto - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |