Russell,
> 1.2073.10.1 05/03/04 21:19:20 [email protected].(none)[rmk] +1 -0
> [ARM PATCH] 2472/1: Updates 8250.c to correctly detect XScale UARTs
>
> Patch from George Joseph
>
> Modifications to autoconfig_16550a to add a testcase
> to detect XScale UARTS.
>
> Signed-off-by: George Joseph
> Signed-off-by: Russell King
Breaks my UARTS.
I'm not thrilled with this patch but 8250.c has similar warts so I
guess it's not too bad. Ideally we could refactor this a bit so if
this isn't acceptable let me know and I'll do that instead.
===== drivers/serial/8250.c 1.96 vs edited =====
Index: kernel-taniwha-2.6.11post-cw3/drivers/serial/8250.c
===================================================================
--- kernel-taniwha-2.6.11post-cw3.orig/drivers/serial/8250.c 2005-03-06 01:10:38.677251721 -0800
+++ kernel-taniwha-2.6.11post-cw3/drivers/serial/8250.c 2005-03-06 01:13:26.288802003 -0800
@@ -642,7 +642,9 @@
static void autoconfig_16550a(struct uart_8250_port *up)
{
unsigned char status1, status2;
+#ifdef CONFIG_ARM
unsigned int iersave;
+#endif /* CONFIG_ARM */
up->port.type = PORT_16550A;
up->capabilities |= UART_CAP_FIFO;
@@ -738,6 +740,11 @@
return;
}
+ /* We only do this check for ARM build because it seems to
+ * falsely trigger on (some) PCs which breaks things.
+ * Besides, if this is XScale specific why do all platforms
+ * need this code and why is it here? */
+#ifdef CONFIG_ARM
/*
* Try writing and reading the UART_IER_UUE bit (b6).
* If it works, this is probably one of the Xscale platform's
@@ -771,6 +778,7 @@
DEBUG_AUTOCONF("Couldn't force IER_UUE to 0 ");
}
serial_outp(up, UART_IER, iersave);
+#endif /* CONFIG_ARM */
}
/*
On Sun, Mar 06, 2005 at 01:33:21AM -0800, Chris Wedgwood wrote:
> Breaks my UARTS.
>
> I'm not thrilled with this patch but 8250.c has similar warts so I
> guess it's not too bad. Ideally we could refactor this a bit so if
> this isn't acceptable let me know and I'll do that instead.
If it breaks here (due to your ports being "embraced and extended") it
could well break elsewhere, and wrapping it in CONFIG_ARM doesn't solve
that.
I'm not sure what the solution to this is, but unless we can autodetect
the port "type", it rather screws the current direction of 8250, which
has been to move away from port types to a set of port capabilities.
I wonder if its possible to get hold of any documentation for your
misdetected serial port...
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
On Sun, Mar 06, 2005 at 10:19:12AM +0000, Russell King wrote:
> If it breaks here (due to your ports being "embraced and extended") it
> could well break elsewhere, and wrapping it in CONFIG_ARM doesn't solve
> that.
Yeah, I forgot other ARM stuff might have regular UART(s) which
potentially would break here too.
> I'm not sure what the solution to this is, but unless we can
> autodetect the port "type", it rather screws the current direction
> of 8250, which has been to move away from port types to a set of
> port capabilities.
Well, as I see it there are three types of serial port knowledge:
(1) Ports we know for (almost) certain we have. For x86* we can
probably assume ttyS0 has some fairly standard values like 0x3f8,4
and if not expect the user to specify otherwise.
(2) Ports we know for (almost) certain we don't have. We have
#ifdef's for this in places already. Basically things like PPC
and ARM/XScale UARTs won't be found on PCs (though the reverse is
clearly not true).
(3) Everything else.
If (1) & (2) end up being pretty limited and the bulk of 8250.c is
required for (3) then changing things around probably isn't worth
while at all.
> I wonder if its possible to get hold of any documentation for your
> misdetected serial port...
I assumed it's part of the AMD-768 southbridge but the documentation
for that mentions no UARTs so I wonder if it's an external chip
hanging of the LPC bus? I'll have a closer look tomorrow if that will
help.