* serial: 8250 fails to detect Exar XR16L2551 correctly
@ 2005-07-05 14:19 David Vrabel
2005-07-06 18:57 ` Russell King
0 siblings, 1 reply; 14+ messages in thread
From: David Vrabel @ 2005-07-05 14:19 UTC (permalink / raw)
To: rmk+serial; +Cc: Linux Kernel
[-- Attachment #1: Type: text/plain, Size: 904 bytes --]
Hi,
The 8250 serial driver detects the Exar XR16L2551 as a 16550A. The
XR16L2551 has an EFR register and sleep capabilities (UART_CAP_FIFO |
UART_CAP_EFR | UART_CAP_SLEEP). However, broken_efr() thinks it's a
buggy Exar ST16C255x.
Any suggestion on how to differentiate between the two parts? Exar have
made the ST16C255x with the same registers as the XR16L255x...
Perhaps it's okay for the ST16C255x to be detected as something with
UART_CAP_EFR | UART_CAP_SLEEP even if it doesn't work? i.e., by removing
broken_efr().
Also, the initial IER test was failing (after a soft reboot) with the
XR16L2551 part since the sleep mode bit was set but was read-only. It
seems sensible to make this test only look at the lower 4 bits.
David Vrabel
--
David Vrabel, Design Engineer
Arcom, Clifton Road Tel: +44 (0)1223 411200 ext. 3233
Cambridge CB1 7EA, UK Web: http://www.arcom.com/
[-- Attachment #2: serial-XR16550 --]
[-- Type: text/plain, Size: 3035 bytes --]
%state
pending
%patch
Index: linux-2.6-working/drivers/serial/8250.c
===================================================================
--- linux-2.6-working.orig/drivers/serial/8250.c 2005-07-04 13:43:13.000000000 +0100
+++ linux-2.6-working/drivers/serial/8250.c 2005-07-05 15:08:05.000000000 +0100
@@ -249,6 +249,14 @@
.fcr = UART_FCR_ENABLE_FIFO | UART_FCR_R_TRIG_10,
.flags = UART_CAP_FIFO | UART_CAP_UUE,
},
+ [PORT_XR16550] = {
+ .name = "XR16550",
+ .fifo_size = 16,
+ .tx_loadsz = 16,
+ .fcr = UART_FCR_ENABLE_FIFO | UART_FCR_R_TRIG_01 |
+ UART_FCR_T_TRIG_00,
+ .flags = UART_CAP_FIFO | UART_CAP_EFR | UART_CAP_SLEEP,
+ },
};
static _INLINE_ unsigned int serial_in(struct uart_8250_port *up, int offset)
@@ -573,6 +581,15 @@
up->port.type = PORT_16850;
return;
}
+ /* The Exar XR16L255x has an DVID of 0x02. This will misdetect the
+ * Exar ST16C255x (A2 revision) which has registers like the XR16L255x
+ * but doesn't have a working sleep mode. However, it's safe to claim
+ * sleep capabilities even if they don't work. See also
+ * http://www.exar.com/info.php?pdf=dan180_oct2004.pdf */
+ if (id2 == 0x02) {
+ up->port.type = PORT_XR16550;
+ return;
+ }
/*
* It wasn't an XR16C850.
@@ -585,7 +602,7 @@
*/
if (size_fifo(up) == 64)
up->port.type = PORT_16654;
- else
+ else if(size_fifo(up) == 32)
up->port.type = PORT_16650V2;
}
@@ -611,19 +628,6 @@
up->port.type = PORT_16450;
}
-static int broken_efr(struct uart_8250_port *up)
-{
- /*
- * Exar ST16C2550 "A2" devices incorrectly detect as
- * having an EFR, and report an ID of 0x0201. See
- * http://www.exar.com/info.php?pdf=dan180_oct2004.pdf
- */
- if (autoconfig_read_divisor_id(up) == 0x0201 && size_fifo(up) == 16)
- return 1;
-
- return 0;
-}
-
/*
* We know that the chip has FIFOs. Does it have an EFR? The
* EFR is located in the same register position as the IIR and
@@ -661,7 +665,7 @@
* (other ST16C650V2 UARTs, TI16C752A, etc)
*/
serial_outp(up, UART_LCR, 0xBF);
- if (serial_in(up, UART_EFR) == 0 && !broken_efr(up)) {
+ if (serial_in(up, UART_EFR) == 0) {
DEBUG_AUTOCONF("EFRv2 ");
autoconfig_has_efr(up);
return;
@@ -828,7 +832,7 @@
#endif
scratch3 = serial_inp(up, UART_IER);
serial_outp(up, UART_IER, scratch);
- if (scratch2 != 0 || scratch3 != 0x0F) {
+ if ((scratch2 & 0x0f) != 0 || (scratch3 & 0x0f) != 0x0F) {
/*
* We failed; there's nothing here
*/
Index: linux-2.6-working/include/linux/serial_core.h
===================================================================
--- linux-2.6-working.orig/include/linux/serial_core.h 2005-07-04 13:43:13.000000000 +0100
+++ linux-2.6-working/include/linux/serial_core.h 2005-07-05 15:07:58.000000000 +0100
@@ -39,7 +39,8 @@
#define PORT_RSA 13
#define PORT_NS16550A 14
#define PORT_XSCALE 15
-#define PORT_MAX_8250 15 /* max port ID */
+#define PORT_XR16550 16
+#define PORT_MAX_8250 16 /* max port ID */
/*
* ARM specific type numbers. These are not currently guaranteed
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: serial: 8250 fails to detect Exar XR16L2551 correctly 2005-07-05 14:19 serial: 8250 fails to detect Exar XR16L2551 correctly David Vrabel @ 2005-07-06 18:57 ` Russell King 2005-07-06 20:20 ` Alex Williamson 2005-07-07 13:20 ` David Vrabel 0 siblings, 2 replies; 14+ messages in thread From: Russell King @ 2005-07-06 18:57 UTC (permalink / raw) To: David Vrabel, Alex Williamson; +Cc: Linux Kernel [-- Attachment #1: Type: text/plain, Size: 2028 bytes --] On Tue, Jul 05, 2005 at 03:19:40PM +0100, David Vrabel wrote: > The 8250 serial driver detects the Exar XR16L2551 as a 16550A. The > XR16L2551 has an EFR register and sleep capabilities (UART_CAP_FIFO | > UART_CAP_EFR | UART_CAP_SLEEP). However, broken_efr() thinks it's a > buggy Exar ST16C255x. Grumble! > Any suggestion on how to differentiate between the two parts? Exar have > made the ST16C255x with the same registers as the XR16L255x... If they're 100% identical in terms of the registers, then it's probably impossible to differentiate between the two. > Perhaps it's okay for the ST16C255x to be detected as something with > UART_CAP_EFR | UART_CAP_SLEEP even if it doesn't work? i.e., by removing > broken_efr(). I don't know - maybe Alex Williamson can try your patch out. > Also, the initial IER test was failing (after a soft reboot) with the > XR16L2551 part since the sleep mode bit was set but was read-only. It > seems sensible to make this test only look at the lower 4 bits. ... or maybe this can be used to test for the buggy version. > Index: linux-2.6-working/drivers/serial/8250.c > =================================================================== > --- linux-2.6-working.orig/drivers/serial/8250.c 2005-07-04 13:43:13.000000000 +0100 > +++ linux-2.6-working/drivers/serial/8250.c 2005-07-05 15:08:05.000000000 +0100 > @@ -249,6 +249,14 @@ > .fcr = UART_FCR_ENABLE_FIFO | UART_FCR_R_TRIG_10, > .flags = UART_CAP_FIFO | UART_CAP_UUE, > }, > + [PORT_XR16550] = { > + .name = "XR16550", > + .fifo_size = 16, > + .tx_loadsz = 16, > + .fcr = UART_FCR_ENABLE_FIFO | UART_FCR_R_TRIG_01 | > + UART_FCR_T_TRIG_00, The docs I've just pulled of Exar's site imply that the XR16L2551 doesn't have a transmit trigger threshold, so UART_FCR_T_TRIG_00 shouldn't be specified here. Also, is there a reason for restricting the RX trigger level to 4 instead of 8 bytes? -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 Serial core [-- Attachment #2: serial-XR16550 --] [-- Type: text/plain, Size: 3035 bytes --] %state pending %patch Index: linux-2.6-working/drivers/serial/8250.c =================================================================== --- linux-2.6-working.orig/drivers/serial/8250.c 2005-07-04 13:43:13.000000000 +0100 +++ linux-2.6-working/drivers/serial/8250.c 2005-07-05 15:08:05.000000000 +0100 @@ -249,6 +249,14 @@ .fcr = UART_FCR_ENABLE_FIFO | UART_FCR_R_TRIG_10, .flags = UART_CAP_FIFO | UART_CAP_UUE, }, + [PORT_XR16550] = { + .name = "XR16550", + .fifo_size = 16, + .tx_loadsz = 16, + .fcr = UART_FCR_ENABLE_FIFO | UART_FCR_R_TRIG_01 | + UART_FCR_T_TRIG_00, + .flags = UART_CAP_FIFO | UART_CAP_EFR | UART_CAP_SLEEP, + }, }; static _INLINE_ unsigned int serial_in(struct uart_8250_port *up, int offset) @@ -573,6 +581,15 @@ up->port.type = PORT_16850; return; } + /* The Exar XR16L255x has an DVID of 0x02. This will misdetect the + * Exar ST16C255x (A2 revision) which has registers like the XR16L255x + * but doesn't have a working sleep mode. However, it's safe to claim + * sleep capabilities even if they don't work. See also + * http://www.exar.com/info.php?pdf=dan180_oct2004.pdf */ + if (id2 == 0x02) { + up->port.type = PORT_XR16550; + return; + } /* * It wasn't an XR16C850. @@ -585,7 +602,7 @@ */ if (size_fifo(up) == 64) up->port.type = PORT_16654; - else + else if(size_fifo(up) == 32) up->port.type = PORT_16650V2; } @@ -611,19 +628,6 @@ up->port.type = PORT_16450; } -static int broken_efr(struct uart_8250_port *up) -{ - /* - * Exar ST16C2550 "A2" devices incorrectly detect as - * having an EFR, and report an ID of 0x0201. See - * http://www.exar.com/info.php?pdf=dan180_oct2004.pdf - */ - if (autoconfig_read_divisor_id(up) == 0x0201 && size_fifo(up) == 16) - return 1; - - return 0; -} - /* * We know that the chip has FIFOs. Does it have an EFR? The * EFR is located in the same register position as the IIR and @@ -661,7 +665,7 @@ * (other ST16C650V2 UARTs, TI16C752A, etc) */ serial_outp(up, UART_LCR, 0xBF); - if (serial_in(up, UART_EFR) == 0 && !broken_efr(up)) { + if (serial_in(up, UART_EFR) == 0) { DEBUG_AUTOCONF("EFRv2 "); autoconfig_has_efr(up); return; @@ -828,7 +832,7 @@ #endif scratch3 = serial_inp(up, UART_IER); serial_outp(up, UART_IER, scratch); - if (scratch2 != 0 || scratch3 != 0x0F) { + if ((scratch2 & 0x0f) != 0 || (scratch3 & 0x0f) != 0x0F) { /* * We failed; there's nothing here */ Index: linux-2.6-working/include/linux/serial_core.h =================================================================== --- linux-2.6-working.orig/include/linux/serial_core.h 2005-07-04 13:43:13.000000000 +0100 +++ linux-2.6-working/include/linux/serial_core.h 2005-07-05 15:07:58.000000000 +0100 @@ -39,7 +39,8 @@ #define PORT_RSA 13 #define PORT_NS16550A 14 #define PORT_XSCALE 15 -#define PORT_MAX_8250 15 /* max port ID */ +#define PORT_XR16550 16 +#define PORT_MAX_8250 16 /* max port ID */ /* * ARM specific type numbers. These are not currently guaranteed ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: serial: 8250 fails to detect Exar XR16L2551 correctly 2005-07-06 18:57 ` Russell King @ 2005-07-06 20:20 ` Alex Williamson 2005-07-07 13:20 ` David Vrabel 1 sibling, 0 replies; 14+ messages in thread From: Alex Williamson @ 2005-07-06 20:20 UTC (permalink / raw) To: Russell King; +Cc: David Vrabel, Linux Kernel On Wed, 2005-07-06 at 19:57 +0100, Russell King wrote: > On Tue, Jul 05, 2005 at 03:19:40PM +0100, David Vrabel wrote: > > The 8250 serial driver detects the Exar XR16L2551 as a 16550A. The > > XR16L2551 has an EFR register and sleep capabilities (UART_CAP_FIFO | > > UART_CAP_EFR | UART_CAP_SLEEP). However, broken_efr() thinks it's a > > buggy Exar ST16C255x. > > Grumble! Double grumble... > > Perhaps it's okay for the ST16C255x to be detected as something with > > UART_CAP_EFR | UART_CAP_SLEEP even if it doesn't work? i.e., by removing > > broken_efr(). > > I don't know - maybe Alex Williamson can try your patch out. I can, but not till next week when I can get into the office and dig up the box with the broken A2 rev UARTs. Let me know if you need an answer before then. Thanks, Alex -- Alex Williamson HP Linux & Open Source Lab ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: serial: 8250 fails to detect Exar XR16L2551 correctly 2005-07-06 18:57 ` Russell King 2005-07-06 20:20 ` Alex Williamson @ 2005-07-07 13:20 ` David Vrabel 2005-07-11 19:00 ` Alex Williamson 1 sibling, 1 reply; 14+ messages in thread From: David Vrabel @ 2005-07-07 13:20 UTC (permalink / raw) To: Russell King; +Cc: Alex Williamson, Linux Kernel [-- Attachment #1: Type: text/plain, Size: 1798 bytes --] Russell King wrote: > On Tue, Jul 05, 2005 at 03:19:40PM +0100, David Vrabel wrote: > >>The 8250 serial driver detects the Exar XR16L2551 as a 16550A. The >>XR16L2551 has an EFR register and sleep capabilities (UART_CAP_FIFO | >>UART_CAP_EFR | UART_CAP_SLEEP). However, broken_efr() thinks it's a >>buggy Exar ST16C255x. >> >>... >> >>Also, the initial IER test was failing (after a soft reboot) with the >>XR16L2551 part since the sleep mode bit was set but was read-only. It >>seems sensible to make this test only look at the lower 4 bits. > > ... or maybe this can be used to test for the buggy version. I've redid the patch and added a check for this. Alex, could you test this version, please. >>Index: linux-2.6-working/drivers/serial/8250.c >>=================================================================== >>--- linux-2.6-working.orig/drivers/serial/8250.c 2005-07-04 13:43:13.000000000 +0100 >>+++ linux-2.6-working/drivers/serial/8250.c 2005-07-05 15:08:05.000000000 +0100 >>@@ -249,6 +249,14 @@ >> .fcr = UART_FCR_ENABLE_FIFO | UART_FCR_R_TRIG_10, >> .flags = UART_CAP_FIFO | UART_CAP_UUE, >> }, >>+ [PORT_XR16550] = { >>+ .name = "XR16550", >>+ .fifo_size = 16, >>+ .tx_loadsz = 16, >>+ .fcr = UART_FCR_ENABLE_FIFO | UART_FCR_R_TRIG_01 | >>+ UART_FCR_T_TRIG_00, > > > The docs I've just pulled of Exar's site imply that the XR16L2551 > doesn't have a transmit trigger threshold, so UART_FCR_T_TRIG_00 > shouldn't be specified here. Also, is there a reason for restricting > the RX trigger level to 4 instead of 8 bytes? That's a cut-n-paste mistake. It should be like the 16550A. David Vrabel -- David Vrabel, Design Engineer Arcom, Clifton Road Tel: +44 (0)1223 411200 ext. 3233 Cambridge CB1 7EA, UK Web: http://www.arcom.com/ [-- Attachment #2: serial-XR16550 --] [-- Type: text/plain, Size: 3342 bytes --] %state pending %patch Index: linux-2.6-working/drivers/serial/8250.c =================================================================== --- linux-2.6-working.orig/drivers/serial/8250.c 2005-07-06 16:24:21.000000000 +0100 +++ linux-2.6-working/drivers/serial/8250.c 2005-07-07 14:11:50.000000000 +0100 @@ -249,6 +249,13 @@ .fcr = UART_FCR_ENABLE_FIFO | UART_FCR_R_TRIG_10, .flags = UART_CAP_FIFO | UART_CAP_UUE, }, + [PORT_XR16550] = { + .name = "XR16550", + .fifo_size = 16, + .tx_loadsz = 16, + .fcr = UART_FCR_ENABLE_FIFO | UART_FCR_R_TRIG_10, + .flags = UART_CAP_FIFO | UART_CAP_EFR | UART_CAP_SLEEP, + }, }; static _INLINE_ unsigned int serial_in(struct uart_8250_port *up, int offset) @@ -573,6 +580,26 @@ up->port.type = PORT_16850; return; } + /* The Exar XR16L255x has an DVID of 0x02. This will misdetect the + * Exar ST16C255x (A2 revision) which has registers like the XR16L255x + * but doesn't have a working sleep mode. See also + * http://www.exar.com/info.php?pdf=dan180_oct2004.pdf */ + if (id2 == 0x02) { + unsigned int ier; + + up->port.type = PORT_XR16550; + + /* If we can't set the sleep mode bit then it may be a buggy + * ST16C255x. FIXME: This test is currently unverified. */ + serial_out(up, UART_IER, UART_IERX_SLEEP); + ier = serial_in(up, UART_IER); + serial_out(up, UART_IER, 0); + if ((ier & UART_IERX_SLEEP) != UART_IERX_SLEEP) { + up->capabilities &= ~(UART_CAP_EFR | UART_CAP_SLEEP); + up->port.type = PORT_16550A; + } + return; + } /* * It wasn't an XR16C850. @@ -585,7 +612,7 @@ */ if (size_fifo(up) == 64) up->port.type = PORT_16654; - else + else if(size_fifo(up) == 32) up->port.type = PORT_16650V2; } @@ -611,19 +638,6 @@ up->port.type = PORT_16450; } -static int broken_efr(struct uart_8250_port *up) -{ - /* - * Exar ST16C2550 "A2" devices incorrectly detect as - * having an EFR, and report an ID of 0x0201. See - * http://www.exar.com/info.php?pdf=dan180_oct2004.pdf - */ - if (autoconfig_read_divisor_id(up) == 0x0201 && size_fifo(up) == 16) - return 1; - - return 0; -} - /* * We know that the chip has FIFOs. Does it have an EFR? The * EFR is located in the same register position as the IIR and @@ -661,7 +675,7 @@ * (other ST16C650V2 UARTs, TI16C752A, etc) */ serial_outp(up, UART_LCR, 0xBF); - if (serial_in(up, UART_EFR) == 0 && !broken_efr(up)) { + if (serial_in(up, UART_EFR) == 0) { DEBUG_AUTOCONF("EFRv2 "); autoconfig_has_efr(up); return; @@ -828,7 +842,7 @@ #endif scratch3 = serial_inp(up, UART_IER); serial_outp(up, UART_IER, scratch); - if (scratch2 != 0 || scratch3 != 0x0F) { + if ((scratch2 & 0x0f) != 0 || (scratch3 & 0x0f) != 0x0F) { /* * We failed; there's nothing here */ Index: linux-2.6-working/include/linux/serial_core.h =================================================================== --- linux-2.6-working.orig/include/linux/serial_core.h 2005-07-06 16:24:21.000000000 +0100 +++ linux-2.6-working/include/linux/serial_core.h 2005-07-07 14:11:35.000000000 +0100 @@ -39,7 +39,8 @@ #define PORT_RSA 13 #define PORT_NS16550A 14 #define PORT_XSCALE 15 -#define PORT_MAX_8250 15 /* max port ID */ +#define PORT_XR16550 16 +#define PORT_MAX_8250 16 /* max port ID */ /* * ARM specific type numbers. These are not currently guaranteed ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: serial: 8250 fails to detect Exar XR16L2551 correctly 2005-07-07 13:20 ` David Vrabel @ 2005-07-11 19:00 ` Alex Williamson 2005-07-11 19:46 ` Russell King 0 siblings, 1 reply; 14+ messages in thread From: Alex Williamson @ 2005-07-11 19:00 UTC (permalink / raw) To: David Vrabel; +Cc: Russell King, Linux Kernel On Thu, 2005-07-07 at 14:20 +0100, David Vrabel wrote: > I've redid the patch and added a check for this. Alex, could you test > this version, please. This detects the A2 ST16C255x as an XR16550, so apparently the sleep check doesn't work. I contacted Exar about these two seemingly identical UARTs, and they say that the A2 ST16C255x should be compatible with the XR16550 so perhaps we don't need to special case the A2 UART at all. Unfortunately, when I use the UART for a console, I get garbled output from the time the UART is detected until we hit userspace. I wonder if this has something to do with the early console registration with a conflicting type... I'll see if I can figure out what's going on. Have you used the XR16550 as a console on your system? Perhaps it's as simple as the baud getting reset via the has_efr check. I'm trying to use the system with a 115.2k baud rate. Thanks, Alex -- Alex Williamson HP Linux & Open Source Lab ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: serial: 8250 fails to detect Exar XR16L2551 correctly 2005-07-11 19:00 ` Alex Williamson @ 2005-07-11 19:46 ` Russell King 2005-07-11 20:00 ` Alex Williamson 0 siblings, 1 reply; 14+ messages in thread From: Russell King @ 2005-07-11 19:46 UTC (permalink / raw) To: Alex Williamson; +Cc: David Vrabel, Linux Kernel On Mon, Jul 11, 2005 at 01:00:08PM -0600, Alex Williamson wrote: > On Thu, 2005-07-07 at 14:20 +0100, David Vrabel wrote: > > > I've redid the patch and added a check for this. Alex, could you test > > this version, please. > > This detects the A2 ST16C255x as an XR16550, so apparently the sleep > check doesn't work. I contacted Exar about these two seemingly > identical UARTs, and they say that the A2 ST16C255x should be compatible > with the XR16550 so perhaps we don't need to special case the A2 UART at > all. Unfortunately, when I use the UART for a console, I get garbled > output from the time the UART is detected until we hit userspace. There was a bug in this area - does it happen with latest and greatest kernels? -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 Serial core ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: serial: 8250 fails to detect Exar XR16L2551 correctly 2005-07-11 19:46 ` Russell King @ 2005-07-11 20:00 ` Alex Williamson 2005-07-11 20:17 ` Russell King 0 siblings, 1 reply; 14+ messages in thread From: Alex Williamson @ 2005-07-11 20:00 UTC (permalink / raw) To: Russell King; +Cc: David Vrabel, Linux Kernel On Mon, 2005-07-11 at 20:46 +0100, Russell King wrote: > On Mon, Jul 11, 2005 at 01:00:08PM -0600, Alex Williamson wrote: > > On Thu, 2005-07-07 at 14:20 +0100, David Vrabel wrote: > > > > > I've redid the patch and added a check for this. Alex, could you test > > > this version, please. > > > > This detects the A2 ST16C255x as an XR16550, so apparently the sleep > > check doesn't work. I contacted Exar about these two seemingly > > identical UARTs, and they say that the A2 ST16C255x should be compatible > > with the XR16550 so perhaps we don't need to special case the A2 UART at > > all. Unfortunately, when I use the UART for a console, I get garbled > > output from the time the UART is detected until we hit userspace. > > There was a bug in this area - does it happen with latest and greatest > kernels? Yes, I'm using a git pull from ~5hrs ago. How recent was the bug fix? It worked fine before I applied David's patch, the A2 UART was detected as a 16550A. Thanks, Alex -- Alex Williamson HP Linux & Open Source Lab ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: serial: 8250 fails to detect Exar XR16L2551 correctly 2005-07-11 20:00 ` Alex Williamson @ 2005-07-11 20:17 ` Russell King 2005-07-11 21:17 ` Alex Williamson 0 siblings, 1 reply; 14+ messages in thread From: Russell King @ 2005-07-11 20:17 UTC (permalink / raw) To: Alex Williamson; +Cc: David Vrabel, Linux Kernel On Mon, Jul 11, 2005 at 02:00:57PM -0600, Alex Williamson wrote: > On Mon, 2005-07-11 at 20:46 +0100, Russell King wrote: > > There was a bug in this area - does it happen with latest and greatest > > kernels? > > Yes, I'm using a git pull from ~5hrs ago. How recent was the bug > fix? It worked fine before I applied David's patch, the A2 UART was > detected as a 16550A. Thanks, The fix for this went in on 21st May 2005, so obviously it's not actually fixed. -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 Serial core ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: serial: 8250 fails to detect Exar XR16L2551 correctly 2005-07-11 20:17 ` Russell King @ 2005-07-11 21:17 ` Alex Williamson 2005-07-13 17:04 ` Alex Williamson 0 siblings, 1 reply; 14+ messages in thread From: Alex Williamson @ 2005-07-11 21:17 UTC (permalink / raw) To: Russell King; +Cc: David Vrabel, Linux Kernel On Mon, 2005-07-11 at 21:17 +0100, Russell King wrote: > On Mon, Jul 11, 2005 at 02:00:57PM -0600, Alex Williamson wrote: > > On Mon, 2005-07-11 at 20:46 +0100, Russell King wrote: > > > There was a bug in this area - does it happen with latest and greatest > > > kernels? > > > > Yes, I'm using a git pull from ~5hrs ago. How recent was the bug > > fix? It worked fine before I applied David's patch, the A2 UART was > > detected as a 16550A. Thanks, > > The fix for this went in on 21st May 2005, so obviously it's not > actually fixed. No, I think this is a problem with the broken A2 UARTs getting confused in serial8250_set_sleep(). If I remove either UART_CAP_SLEEP or UART_CAP_EFR from the capabilities list for this UART, it behaves normally. Also, just commenting out the UART_CAP_EFR chunks of set_sleep make it behave. I'll ping Exar for more data. Thanks, Alex -- Alex Williamson HP Linux & Open Source Lab ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: serial: 8250 fails to detect Exar XR16L2551 correctly 2005-07-11 21:17 ` Alex Williamson @ 2005-07-13 17:04 ` Alex Williamson 2005-07-13 18:03 ` Alex Williamson 2005-07-14 13:46 ` Russell King 0 siblings, 2 replies; 14+ messages in thread From: Alex Williamson @ 2005-07-13 17:04 UTC (permalink / raw) To: Russell King; +Cc: David Vrabel, Linux Kernel On Mon, 2005-07-11 at 15:17 -0600, Alex Williamson wrote: > No, I think this is a problem with the broken A2 UARTs getting > confused in serial8250_set_sleep(). If I remove either UART_CAP_SLEEP > or UART_CAP_EFR from the capabilities list for this UART, it behaves > normally. Also, just commenting out the UART_CAP_EFR chunks of > set_sleep make it behave. I'll ping Exar for more data. Thanks, Hi Russell, I don't know enough about the extended UART programming model, but I notice that when UART_CAP_EFR and UART_CAP_SLEEP are set on a UART, we set the UART_IERX_SLEEP bit in the UART_IER immediately after it's found and configured. It's from this point until we hit userspace and clear that bit that output from the UART is garbled. Are UARTs supposed to output data with sleep mode enabled? Are there known working configs where a UART w/ EFR and SLEEP are able to be used as a serial console? This system with the A2 rev ST16C2550 part that's not working is the only one I have with a console UART w/ these capabilities. Just trying to make sure that there's not a latent bug that we enable a bad sleep mode when the UART is being used for the console. Thanks, Alex -- Alex Williamson HP Linux & Open Source Lab ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: serial: 8250 fails to detect Exar XR16L2551 correctly 2005-07-13 17:04 ` Alex Williamson @ 2005-07-13 18:03 ` Alex Williamson 2005-07-14 14:40 ` David Vrabel 2005-07-14 13:46 ` Russell King 1 sibling, 1 reply; 14+ messages in thread From: Alex Williamson @ 2005-07-13 18:03 UTC (permalink / raw) To: Russell King; +Cc: David Vrabel, Linux Kernel On Wed, 2005-07-13 at 11:04 -0600, Alex Williamson wrote: > Just trying to make sure that there's not a latent bug that we enable > a bad sleep mode when the UART is being used for the console. Yes, this is the problem. When a UART is specified as the console using "console=uart,...", the console index is not initialized. This causes the uart_console() check to mis-identify the port and we enable sleep mode when we don't intend to do so. Not sure how to fix it yet, but I assume we need to go back through after the serial ports are enumerated, and un-suspend the console port. David, would you mind trying this on the XR16L255x part? (ie. don't use console=ttyS, use console=uart,...) Thanks, Alex -- Alex Williamson HP Linux & Open Source Lab ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: serial: 8250 fails to detect Exar XR16L2551 correctly 2005-07-13 18:03 ` Alex Williamson @ 2005-07-14 14:40 ` David Vrabel 0 siblings, 0 replies; 14+ messages in thread From: David Vrabel @ 2005-07-14 14:40 UTC (permalink / raw) To: Alex Williamson; +Cc: Russell King, Linux Kernel Alex Williamson wrote: > > David, would you mind > trying this on the XR16L255x part? (ie. don't use console=ttyS, use > console=uart,...) Thanks, I wasn't even aware you could do this... These are the serial ports I have: ttyS0 at MMIO 0xc8000000 (irq = 15) is a XScale IXP425 internal ttyS1 at MMIO 0xc8001000 (irq = 13) is a XScale " " ttyS2 at MMIO 0x53000000 (irq = 21) is a XR16550 XR16L2551 ttyS3 at MMIO 0x53000008 (irq = 21) is a XR16550 " I tried console=uart,mmio,0x53000000,115200 and my board didn't print anything to the console and the boot failed somewhere before starting network (I don't know exactly where or why since I couldn't see any messages). Using console=ttyS2,115200 works fine. What's 8250_early.c for anyway? console=ttyS... has always worked fine for me. David Vrabel -- David Vrabel, Design Engineer Arcom, Clifton Road Tel: +44 (0)1223 411200 ext. 3233 Cambridge CB1 7EA, UK Web: http://www.arcom.com/ ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: serial: 8250 fails to detect Exar XR16L2551 correctly 2005-07-13 17:04 ` Alex Williamson 2005-07-13 18:03 ` Alex Williamson @ 2005-07-14 13:46 ` Russell King 2005-07-15 20:39 ` Alex Williamson 1 sibling, 1 reply; 14+ messages in thread From: Russell King @ 2005-07-14 13:46 UTC (permalink / raw) To: Alex Williamson; +Cc: David Vrabel, Linux Kernel On Wed, Jul 13, 2005 at 11:04:56AM -0600, Alex Williamson wrote: > On Mon, 2005-07-11 at 15:17 -0600, Alex Williamson wrote: > > No, I think this is a problem with the broken A2 UARTs getting > > confused in serial8250_set_sleep(). If I remove either UART_CAP_SLEEP > > or UART_CAP_EFR from the capabilities list for this UART, it behaves > > normally. Also, just commenting out the UART_CAP_EFR chunks of > > set_sleep make it behave. I'll ping Exar for more data. Thanks, > > Hi Russell, > > I don't know enough about the extended UART programming model, but I > notice that when UART_CAP_EFR and UART_CAP_SLEEP are set on a UART, we > set the UART_IERX_SLEEP bit in the UART_IER immediately after it's found > and configured. Ah, I see what's happening. We're detecting the port and doing the autoconfig. Then we're checking to see if it's the console, and if not putting it into low power mode. Then we try to register the console, which may result in this UART becoming a console. So now we have a console which is in low power mode. Bad bad bad. No cookie for the serial layer today. > Are there known working configs where a UART w/ EFR and SLEEP are > able to be used as a serial console? No idea - I'm completely reliant on other folk to report problems with the 8250 driver with their random versions of UARTs which are out in the field. I only have 16450, 16550A and 16750 UARTs here. Hmm, I need to consider killing register_serial() and the associated code in serial_core.c earlier so I can sanely fix this problem. I think it's time to give the remaining register_serial() users an extra push... I haven't seen _any_ activity from the remaining users, so I might have to take the attitude that "if they don't care, I don't care about breaking their code" which would be rather shameful as far as the users go. (but hey, user pressure might wake up the maintainers.) -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 Serial core ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: serial: 8250 fails to detect Exar XR16L2551 correctly 2005-07-14 13:46 ` Russell King @ 2005-07-15 20:39 ` Alex Williamson 0 siblings, 0 replies; 14+ messages in thread From: Alex Williamson @ 2005-07-15 20:39 UTC (permalink / raw) To: Russell King; +Cc: David Vrabel, Linux Kernel On Thu, 2005-07-14 at 14:46 +0100, Russell King wrote: > Then we try to register the console, which may result in this UART > becoming a console. So now we have a console which is in low power > mode. Bad bad bad. No cookie for the serial layer today. I don't know if this is a possible short term option, but the code David proposes would work fine on the A2 rev ST16C255x parts as long as UART_CAP_SLEEP in not included in the list of capabilities. The check for the A2 part would not be needed (esp. since it doesn't work). When the console detection code is fixed up, this flag could be included, and I'd be happy to test it. This would at least give us both usable UARTs until we can work out the other kinks. Thanks, Alex -- Alex Williamson HP Linux & Open Source Lab ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2005-07-15 20:40 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2005-07-05 14:19 serial: 8250 fails to detect Exar XR16L2551 correctly David Vrabel 2005-07-06 18:57 ` Russell King 2005-07-06 20:20 ` Alex Williamson 2005-07-07 13:20 ` David Vrabel 2005-07-11 19:00 ` Alex Williamson 2005-07-11 19:46 ` Russell King 2005-07-11 20:00 ` Alex Williamson 2005-07-11 20:17 ` Russell King 2005-07-11 21:17 ` Alex Williamson 2005-07-13 17:04 ` Alex Williamson 2005-07-13 18:03 ` Alex Williamson 2005-07-14 14:40 ` David Vrabel 2005-07-14 13:46 ` Russell King 2005-07-15 20:39 ` Alex Williamson
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).