lkml.org 
[lkml]   [2006]   [Jan]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH] serial: serial_txx9 driver update
From
>>>>> 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/

\
 
 \ /
  Last update: 2006-01-24 03:27    [W:0.092 / U:0.292 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site