serial: 8250 fails to detect Exar XR16L2551 correctly

serial: 8250 fails to detect Exar XR16L2551 correctly

[David Vrabel]

[-- 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

Re: serial: 8250 fails to detect Exar XR16L2551 correctly

[Russell King]

[-- 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

Re: serial: 8250 fails to detect Exar XR16L2551 correctly

[Alex Williamson]

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

Re: serial: 8250 fails to detect Exar XR16L2551 correctly

[David Vrabel]

[-- 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

Re: serial: 8250 fails to detect Exar XR16L2551 correctly

[Alex Williamson]

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

Re: serial: 8250 fails to detect Exar XR16L2551 correctly

[Russell King]

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

Re: serial: 8250 fails to detect Exar XR16L2551 correctly

[Alex Williamson]

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

Re: serial: 8250 fails to detect Exar XR16L2551 correctly

[Russell King]

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

Re: serial: 8250 fails to detect Exar XR16L2551 correctly

[Alex Williamson]

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

Re: serial: 8250 fails to detect Exar XR16L2551 correctly

[Alex Williamson]

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

Re: serial: 8250 fails to detect Exar XR16L2551 correctly

[Alex Williamson]

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

Re: serial: 8250 fails to detect Exar XR16L2551 correctly

[Russell King]

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

Re: serial: 8250 fails to detect Exar XR16L2551 correctly

[David Vrabel]

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/

Re: serial: 8250 fails to detect Exar XR16L2551 correctly

[Alex Williamson]

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