From 16873ab749601d7393a28c989ec146e81ffc61b3 Mon Sep 17 00:00:00 2001 From: marcel Date: Thu, 29 Aug 2013 16:26:04 +0000 Subject: Work-around a timing problem with the ITE IT8513E now that the core calls ns8250_bus_ipend() almost immediately after ns8250_bus_attach(). As it appears, a line break condition is being signalled for almost all received characters due to this. A delay of 150ms seems enough to allow the H/W to settle and to avoid the problem. More analysis is needed, but for now a regression has been addressed. Reported by: kevlo@ Tested by: kevlo@ --- sys/dev/uart/uart_dev_ns8250.c | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/sys/dev/uart/uart_dev_ns8250.c b/sys/dev/uart/uart_dev_ns8250.c index 1c337ca..2fad76c 100644 --- a/sys/dev/uart/uart_dev_ns8250.c +++ b/sys/dev/uart/uart_dev_ns8250.c @@ -453,7 +453,19 @@ ns8250_bus_attach(struct uart_softc *sc) ns8250->ier |= ns8250->ier_rxbits; uart_setreg(bas, REG_IER, ns8250->ier); uart_barrier(bas); - + + /* + * Timing of the H/W access was changed with r253161 of uart_core.c + * It has been observed that an ITE IT8513E would signal a break + * condition with pretty much every character it received, unless + * it had enough time to settle between ns8250_bus_attach() and + * ns8250_bus_ipend() -- which it accidentally had before r253161. + * It's not understood why the UART chip behaves this way and it + * could very well be that the DELAY make the H/W work in the same + * accidental manner as before. More analysis is warranted, but + * at least now we fixed a known regression. + */ + DELAY(150); return (0); } -- cgit v1.1