* David Brownell <david-b@xxxxxxxxxxx> [081102 11:26]: > On Sunday 02 November 2008, Rick Bronson wrote: > > > Is that what you saw too? > > > > Yep, that's what I saw, but only if I had DEBUG_LL=y. Without that > > I had nothing except "Uncompressing Linux........". > > I don't have DEBUG_LL=y ... if you had some kind of network > link configured over USB, could you SSH in? (I can.) > > > > I guess we don't see this problem on the other 2 ports since they > > are mapped MT_MEMORY_SO and not MT_DEVICE (L4_34XX_PHYS). > > Hmm, inconsistency is to be avoided. :) > > I wonder what the root cause is ... is the driver missing > various barriers needed to make MT_DEVICE work? Or is the > MT_DEVICE incorrect in the first place? "git whatchanged" > didn't show any recent changes that seemed (on a quick > glance) to affect I/O at that level. Maybe it was one of > the other TTY changes interacting here. Yeah I don't know what may have changed, or have things just gotten faster now with cortex since 2.6.27? Anyways, this patch fixes the issue for me without marking things strongly ordered. Rick, does this work for you? Regards, Tony
>From 57eea529292418a20a119c5b18d7636cf44992ae Mon Sep 17 00:00:00 2001 From: Tony Lindgren <tony@xxxxxxxxxxx> Date: Fri, 31 Oct 2008 16:47:42 -0700 Subject: [PATCH] serial: Flush posted write on 34xx to make 8250 work On omap34xx, we need to flush posted writes for TX. Signed-off-by: Tony Lindgren <tony@xxxxxxxxxxx> diff --git a/drivers/serial/8250.c b/drivers/serial/8250.c index 5f383d8..629a16c 100644 --- a/drivers/serial/8250.c +++ b/drivers/serial/8250.c @@ -413,6 +413,13 @@ serial_out(struct uart_8250_port *up, int offset, int value) case UPIO_MEM: writeb(value, up->port.membase + offset); +#ifdef CONFIG_ARCH_OMAP + /* Flush posted write for TX */ + if (cpu_is_omap34xx() && is_omap_port(up) && + (save_offset == UART_TX || save_offset == UART_IER || + save_offset == UART_LCR)) + value = serial_in(up, UART_LCR); /* Safe to read */ +#endif break; case UPIO_RM9000:
