[PATCH] Make the Startech UART detection 'more correct'.

[PATCH] Make the Startech UART detection 'more correct'.

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 2019 bytes --]

Hello.  The following patches (vs 2.4 and 2.6) make the Startech UART
detection 'more correct'  The problem is that on with the Motorola
MPC82xx line (8245 for example) it has an internal DUART that it claims
to be PC16550D compatible, and it has an additional EFR (Enhanced
Feature Register) at offset 0x2, like on the Startech UARTS.  However,
it is not a Startech, and when it's detected as such, FIFOs don't work.
The fix for this is that the Startech UARTs have a 32 byte FIFO [1] and
the MPC82xx DUARTs have a 16-byte FIFO [2], to check that the FIFO size
is correct for a Startech.

2.4:
===== drivers/char/serial.c 1.34 vs edited =====
--- 1.34/drivers/char/serial.c	Sun Jul  6 22:33:28 2003
+++ edited/drivers/char/serial.c	Fri Sep  5 15:44:11 2003
@@ -3740,7 +3740,7 @@
 	if (state->type == PORT_16550A) {
 		/* Check for Startech UART's */
 		serial_outp(info, UART_LCR, UART_LCR_DLAB);
-		if (serial_in(info, UART_EFR) == 0) {
+		if (serial_in(info, UART_EFR) == 0 && size_fifo(info) != 16) {
 			state->type = PORT_16650;
 		} else {
 			serial_outp(info, UART_LCR, 0xBF);

2.6:
===== drivers/serial/8250.c 1.34 vs edited =====
--- 1.34/drivers/serial/8250.c	Sun Jun 15 02:21:11 2003
+++ edited/drivers/serial/8250.c	Fri Sep  5 15:43:23 2003
@@ -467,7 +467,7 @@
 	 * Only ST16C650V1 UARTs pass this test.
 	 */
 	serial_outp(up, UART_LCR, UART_LCR_DLAB);
-	if (serial_in(up, UART_EFR) == 0) {
+	if (serial_in(up, UART_EFR) == 0 && size_fifo(up) != 16) {
 		DEBUG_AUTOCONF("EFRv1 ");
 		up->port.type = PORT_16650;
 		return;

I must admit however, that after reading both datasheets, I'm not sure
if the correct test is for && size_fifo() == 32 or != 16, or if it
matters.  Comments?

This was originally fixed by Greg Allen[3].

[1]: http://www.exar.com/products/uartnote.pdf
[2]: http://e-www.motorola.com/brdata/PDFDB/docs/MPC8245UM_CH12.pdf
[3]: http://www.geocrawler.com/archives/3/8358/2002/3/0/8228902/
-- 
Tom Rini
http://gate.crashing.org/~trini/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH] Make the Startech UART detection 'more correct'.

[Russell King]

On Mon, Sep 08, 2003 at 01:54:31PM -0700, Tom Rini wrote:
> Hello.  The following patches (vs 2.4 and 2.6) make the Startech UART
> detection 'more correct'  The problem is that on with the Motorola
> MPC82xx line (8245 for example) it has an internal DUART that it claims
> to be PC16550D compatible, and it has an additional EFR (Enhanced
> Feature Register) at offset 0x2, like on the Startech UARTS.  However,
> it is not a Startech, and when it's detected as such, FIFOs don't work.
> The fix for this is that the Startech UARTs have a 32 byte FIFO [1] and
> the MPC82xx DUARTs have a 16-byte FIFO [2], to check that the FIFO size
> is correct for a Startech.

size_fifo() is claimed to be unreliable at detecting the FIFO size,
so I don't feel safe about using it here.

I'd suggest something like:

	serial_outp(port, UART_LCR, UART_LCR_DLAB);
	efr = serial_in(port, UART_EFR);
	if ((efr & 0xfc) == 0) {
		serial_out(port, UART_EFR, 0xac | (efr & 3));
		/* if top 6 bits return zero, its motorola */
		if (serial_in(port, UART_EFR) == (efr & 3)) {
			/* motorola port */
		} else {
			/* ST16C650V1 port */
		}
		/* restore old value */
		serial_outb(port, UART_EFR, efr);
	}

If you can guarantee that the lower two bits will always be zero, you can
drop the frobbing to ignore/preseve the lower two bits.

-- 
Russell King (rmk@arm.linux.org.uk)	http://www.arm.linux.org.uk/personal/
Linux kernel maintainer of:
  2.6 ARM Linux   - http://www.arm.linux.org.uk/
  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
  2.6 Serial core

RE: [PATCH] Make the Startech UART detection 'more correct'.

[Stuart MacDonald]

From: linux-kernel-owner@vger.kernel.org 
> size_fifo() is claimed to be unreliable at detecting the FIFO size,
> so I don't feel safe about using it here.

"Claimed" being the operative word. This claim predates my involvement
with the serial driver (IIRC tytso is reporting someone's claim
second-hand), however, my company has always used this test in various
test apps, and never had it fail, and this predates my employment with
them.

So. A number of possibilities: someone thought it was unreliable, but
they were incorrect; it was unreliable, but because the software was
wrong; it was unreliable, but only on certain very old hardware that I
personally have no knowledge of its existance.

I've never seen any concrete details about what goes wrong either,
just a simple claim of unreliability.

The premise is simple enough. Put the uart into internal loopback mode
(the rx and tx pins on the chip become on-die connected to each other,
date never leaves the chip), transmit 256 characters at a known baud
rate, wait for at least the time it takes to transmit these characters
plus some to be safe, and see how many are left in the rx fifo, which
should be full.

> I'd suggest something like:
> 
> 	serial_outp(port, UART_LCR, UART_LCR_DLAB);
> 	efr = serial_in(port, UART_EFR);
> 	if ((efr & 0xfc) == 0) {
> 		serial_out(port, UART_EFR, 0xac | (efr & 3));
> 		/* if top 6 bits return zero, its motorola */
> 		if (serial_in(port, UART_EFR) == (efr & 3)) {
> 			/* motorola port */
> 		} else {
> 			/* ST16C650V1 port */
> 		}
> 		/* restore old value */
> 		serial_outb(port, UART_EFR, efr);
> 	}
> 
> If you can guarantee that the lower two bits will always be 
> zero, you can
> drop the frobbing to ignore/preseve the lower two bits.

Does the Motorola chip have an ID register at all? Certainly using the
fifo size is a weak test and should only be a last resort.

..Stu

Re: [PATCH] Make the Startech UART detection 'more correct'.

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 994 bytes --]

On Tue, Sep 09, 2003 at 03:12:30PM -0400, Stuart MacDonald wrote:
> From: linux-kernel-owner@vger.kernel.org 
[snip]
> > I'd suggest something like:
> > 
> > 	serial_outp(port, UART_LCR, UART_LCR_DLAB);
> > 	efr = serial_in(port, UART_EFR);
> > 	if ((efr & 0xfc) == 0) {
> > 		serial_out(port, UART_EFR, 0xac | (efr & 3));
> > 		/* if top 6 bits return zero, its motorola */
> > 		if (serial_in(port, UART_EFR) == (efr & 3)) {
> > 			/* motorola port */
> > 		} else {
> > 			/* ST16C650V1 port */
> > 		}
> > 		/* restore old value */
> > 		serial_outb(port, UART_EFR, efr);
> > 	}
> > 
> > If you can guarantee that the lower two bits will always be 
> > zero, you can
> > drop the frobbing to ignore/preseve the lower two bits.
> 
> Does the Motorola chip have an ID register at all? Certainly using the
> fifo size is a weak test and should only be a last resort.

No, there is not an ID on the motorola duarts.

-- 
Tom Rini
http://gate.crashing.org/~trini/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH] Make the Startech UART detection 'more correct'.

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 2691 bytes --]

On Tue, Sep 09, 2003 at 05:18:59PM +0100, Russell King wrote:

> On Mon, Sep 08, 2003 at 01:54:31PM -0700, Tom Rini wrote:
> > Hello.  The following patches (vs 2.4 and 2.6) make the Startech UART
> > detection 'more correct'  The problem is that on with the Motorola
> > MPC82xx line (8245 for example) it has an internal DUART that it claims
> > to be PC16550D compatible, and it has an additional EFR (Enhanced
> > Feature Register) at offset 0x2, like on the Startech UARTS.  However,
> > it is not a Startech, and when it's detected as such, FIFOs don't work.
> > The fix for this is that the Startech UARTs have a 32 byte FIFO [1] and
> > the MPC82xx DUARTs have a 16-byte FIFO [2], to check that the FIFO size
> > is correct for a Startech.
> 
> size_fifo() is claimed to be unreliable at detecting the FIFO size,
> so I don't feel safe about using it here.
> 
> I'd suggest something like:
> 
> 	serial_outp(port, UART_LCR, UART_LCR_DLAB);
> 	efr = serial_in(port, UART_EFR);
> 	if ((efr & 0xfc) == 0) {
> 		serial_out(port, UART_EFR, 0xac | (efr & 3));
> 		/* if top 6 bits return zero, its motorola */
> 		if (serial_in(port, UART_EFR) == (efr & 3)) {
> 			/* motorola port */
> 		} else {
> 			/* ST16C650V1 port */
> 		}
> 		/* restore old value */
> 		serial_outb(port, UART_EFR, efr);
> 	}

Okay, from Kumar Gala (cc'ed) I've got the following patch for 2.4:
===== drivers/char/serial.c 1.34 vs edited =====
--- 1.34/drivers/char/serial.c	Sun Jul  6 22:33:28 2003
+++ edited/drivers/char/serial.c	Tue Sep  9 16:50:22 2003
@@ -3741,7 +3741,10 @@
 		/* Check for Startech UART's */
 		serial_outp(info, UART_LCR, UART_LCR_DLAB);
 		if (serial_in(info, UART_EFR) == 0) {
-			state->type = PORT_16650;
+			serial_outp(info, UART_EFR, 0xA8);
+			if (serial_in(info, UART_EFR) != 0)
+				state->type = PORT_16650;
+			serial_outp(info, UART_EFR, 0);
 		} else {
 			serial_outp(info, UART_LCR, 0xBF);
 			if (serial_in(info, UART_EFR) == 0)

And I forward ported this up to 2.6 as:
===== drivers/serial/8250.c 1.36 vs edited =====
--- 1.36/drivers/serial/8250.c	Tue Sep  9 07:22:12 2003
+++ edited/drivers/serial/8250.c	Tue Sep  9 16:49:07 2003
@@ -469,8 +469,13 @@
 	 */
 	serial_outp(up, UART_LCR, UART_LCR_DLAB);
 	if (serial_in(up, UART_EFR) == 0) {
-		DEBUG_AUTOCONF("EFRv1 ");
-		up->port.type = PORT_16650;
+		serial_outp(up, UART_EFR, 0xA8);
+		if (serial_in(up, UART_EFR) != 0) {
+			DEBUG_AUTOCONF("EFRv1 ");
+			up->port.type = PORT_16650;
+		} else
+			DEBUG_AUTOCONF("Motorola 8xxx DUART ");
+		serial_outp(up, UART_EFR, 0);
 		return;
 	}

Better?

-- 
Tom Rini
http://gate.crashing.org/~trini/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH] Make the Startech UART detection 'more correct'.

[Kumar Gala]

I was wondering what the status of this patch was for the 2.4 side?

thanks

- kumar

On Tuesday, September 9, 2003, at 06:51 PM, Tom Rini wrote:

> On Tue, Sep 09, 2003 at 05:18:59PM +0100, Russell King wrote:
>
>> On Mon, Sep 08, 2003 at 01:54:31PM -0700, Tom Rini wrote:
>>> Hello.  The following patches (vs 2.4 and 2.6) make the Startech UART
>>> detection 'more correct'  The problem is that on with the Motorola
>>> MPC82xx line (8245 for example) it has an internal DUART that it 
>>> claims
>>> to be PC16550D compatible, and it has an additional EFR (Enhanced
>>> Feature Register) at offset 0x2, like on the Startech UARTS.  
>>> However,
>>> it is not a Startech, and when it's detected as such, FIFOs don't 
>>> work.
>>> The fix for this is that the Startech UARTs have a 32 byte FIFO [1] 
>>> and
>>> the MPC82xx DUARTs have a 16-byte FIFO [2], to check that the FIFO 
>>> size
>>> is correct for a Startech.
>>
>> size_fifo() is claimed to be unreliable at detecting the FIFO size,
>> so I don't feel safe about using it here.
>>
>> I'd suggest something like:
>>
>> 	serial_outp(port, UART_LCR, UART_LCR_DLAB);
>> 	efr = serial_in(port, UART_EFR);
>> 	if ((efr & 0xfc) == 0) {
>> 		serial_out(port, UART_EFR, 0xac | (efr & 3));
>> 		/* if top 6 bits return zero, its motorola */
>> 		if (serial_in(port, UART_EFR) == (efr & 3)) {
>> 			/* motorola port */
>> 		} else {
>> 			/* ST16C650V1 port */
>> 		}
>> 		/* restore old value */
>> 		serial_outb(port, UART_EFR, efr);
>> 	}
>
> Okay, from Kumar Gala (cc'ed) I've got the following patch for 2.4:
> ===== drivers/char/serial.c 1.34 vs edited =====
> --- 1.34/drivers/char/serial.c	Sun Jul  6 22:33:28 2003
> +++ edited/drivers/char/serial.c	Tue Sep  9 16:50:22 2003
> @@ -3741,7 +3741,10 @@
>  		/* Check for Startech UART's */
>  		serial_outp(info, UART_LCR, UART_LCR_DLAB);
>  		if (serial_in(info, UART_EFR) == 0) {
> -			state->type = PORT_16650;
> +			serial_outp(info, UART_EFR, 0xA8);
> +			if (serial_in(info, UART_EFR) != 0)
> +				state->type = PORT_16650;
> +			serial_outp(info, UART_EFR, 0);
>  		} else {
>  			serial_outp(info, UART_LCR, 0xBF);
>  			if (serial_in(info, UART_EFR) == 0)
>
> And I forward ported this up to 2.6 as:
> ===== drivers/serial/8250.c 1.36 vs edited =====
> --- 1.36/drivers/serial/8250.c	Tue Sep  9 07:22:12 2003
> +++ edited/drivers/serial/8250.c	Tue Sep  9 16:49:07 2003
> @@ -469,8 +469,13 @@
>  	 */
>  	serial_outp(up, UART_LCR, UART_LCR_DLAB);
>  	if (serial_in(up, UART_EFR) == 0) {
> -		DEBUG_AUTOCONF("EFRv1 ");
> -		up->port.type = PORT_16650;
> +		serial_outp(up, UART_EFR, 0xA8);
> +		if (serial_in(up, UART_EFR) != 0) {
> +			DEBUG_AUTOCONF("EFRv1 ");
> +			up->port.type = PORT_16650;
> +		} else
> +			DEBUG_AUTOCONF("Motorola 8xxx DUART ");
> +		serial_outp(up, UART_EFR, 0);
>  		return;
>  	}
>
> Better?
>
> -- 
> Tom Rini
> http://gate.crashing.org/~trini/
> <mime-attachment>

Best way to detect received call on dumb modem ...

[Lewis Brown]

Hello,

I'm trying to detect incoming calls on a dumb modem but dealing with a
driver that doesn't implement TIOCMIWAIT or TIOCGICOUNT. I'm puzzled how
best to go forward in an efficient way.

Any help would be greatly appreciated.

lb

Re: Best way to detect received call on dumb modem ...

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 753 bytes --]

On Sat, 2003-11-01 13:43:23 -0700, Lewis Brown <lewisb@denveronline.com>
wrote in message <000001c3a0b8$ce82efa0$0200000a@francois>:
> Hello,
> 
> I'm trying to detect incoming calls on a dumb modem but dealing with a
> driver that doesn't implement TIOCMIWAIT or TIOCGICOUNT. I'm puzzled how
> best to go forward in an efficient way.

select() on the fd and wait until you receive "RING"? However, what's a
"dumb" modem?

MfG, JBG

-- 
   Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg
    fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!
   ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

RE: Best way to detect received call on dumb modem ...

[Lewis Brown]

Sorry for not being more specific.

I thought a 'dumb' modem was one that had been taken out of command mode
and thus does not respond to AT commands; at least that's what I meant.


I should say that this is an old problem that I haven't worked on in
over 9 months, so I've forgotten some of the details of my problem.  I
think that in dumb state, the modem can't send RING, CONNECT, etc., so
one must detect DSR, DTR, RNG, etc.  At least that's what I want to do.

When I wrote this program the first time, it worked great and was really
fast.  Then I moved it to the real hardware, a DIGI RAS box, which
didn't have all the standard IOCTLs.  The program now requires the
modems to be in command mode; I have to parse the stream for RING,
CONNECT, OK, etc;  and it is slow and very prone to error.  Seems the
modems are always going haywire this way.  I want to go back to dumb
mode and work as close as possible to the hardware.  I need speed and
reliability.

Any suggestions are much appreciated.
lb

-----Original Message-----
From: linux-serial-owner@vger.kernel.org
[mailto:linux-serial-owner@vger.kernel.org] On Behalf Of Jan-Benedict
Glaw
Sent: Saturday, November 01, 2003 2:14 PM
To: linux-serial@vger.kernel.org
Subject: Re: Best way to detect received call on dumb modem ...


On Sat, 2003-11-01 13:43:23 -0700, Lewis Brown <lewisb@denveronline.com>
wrote in message <000001c3a0b8$ce82efa0$0200000a@francois>:
> Hello,
> 
> I'm trying to detect incoming calls on a dumb modem but dealing with a
> driver that doesn't implement TIOCMIWAIT or TIOCGICOUNT. I'm puzzled
how
> best to go forward in an efficient way.

select() on the fd and wait until you receive "RING"? However, what's a
"dumb" modem?

MfG, JBG

-- 
   Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen
Krieg
    fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im
Irak!
   ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM |
TCPA));


-
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Best way to detect received call on dumb modem ...

[David Lawyer]

On Sat, Nov 01, 2003 at 09:15:38PM -0700, Lewis Brown wrote:
> Sorry for not being more specific.
> 
> I thought a 'dumb' modem was one that had been taken out of command mode
> and thus does not respond to AT commands; at least that's what I meant.

How do you get the modem into this mode?  When you connect to another
modem, AT command mode is lost, but then you can't get any rings since
you are using the phone line.

> 
> I should say that this is an old problem that I haven't worked on in
> over 9 months, so I've forgotten some of the details of my problem.  I
> think that in dumb state, the modem can't send RING, CONNECT, etc., so
> one must detect DSR, DTR, RNG, etc.  At least that's what I want to do.

Sure, you can tell it not to send result codes or words, but it's still
in AT command mode and still responds to AT commands.  Is this what
you're doing?

> When I wrote this program the first time, it worked great and was really
> fast.  Then I moved it to the real hardware, a DIGI RAS box, which
> didn't have all the standard IOCTLs.  The program now requires the
> modems to be in command mode; I have to parse the stream for RING,
> CONNECT, OK, etc;  and it is slow and very prone to error.  Seems the
> modems are always going haywire this way.  I want to go back to dumb
> mode and work as close as possible to the hardware.  I need speed and
> reliability.
> 
> Any suggestions are much appreciated.
> lb
> 
[snip]
			David Lawyer

RE: Best way to detect received call on dumb modem ...

[Steve Tell]

On Sat, 1 Nov 2003, Lewis Brown wrote:

> Sorry for not being more specific.
> 
> I thought a 'dumb' modem was one that had been taken out of command mode
> and thus does not respond to AT commands; at least that's what I meant.

(That's what I thought too... or else a modem that never had an AT or any 
other fancy command set to begin with)
 
Configure the modem to auto-answer when DTR is asserted and when when 
phone rings, and to only assert CD (carrier detect) when it really has a 
carrier.

Then call open(2) on the tty without O_NONBLOCK/O_NDELAY.  DTR will get
asserted to enable the modem, and then the open(2)  will block until the
modem answers and establishes a connection with the calling modem.

This is how modems and getty(8) worked on unixes 20+ years ago... 
(well, except that the 1200bps modems modems were the fast ones)

Steve
 
> I should say that this is an old problem that I haven't worked on in
> over 9 months, so I've forgotten some of the details of my problem.  I
> think that in dumb state, the modem can't send RING, CONNECT, etc., so
> one must detect DSR, DTR, RNG, etc.  At least that's what I want to do.
> 
> When I wrote this program the first time, it worked great and was really
> fast.  Then I moved it to the real hardware, a DIGI RAS box, which
> didn't have all the standard IOCTLs.  The program now requires the
> modems to be in command mode; I have to parse the stream for RING,
> CONNECT, OK, etc;  and it is slow and very prone to error.  Seems the
> modems are always going haywire this way.  I want to go back to dumb
> mode and work as close as possible to the hardware.  I need speed and
> reliability.
> 
> Any suggestions are much appreciated.
> lb
> 
> -----Original Message-----
> From: linux-serial-owner@vger.kernel.org
> [mailto:linux-serial-owner@vger.kernel.org] On Behalf Of Jan-Benedict
> Glaw
> Sent: Saturday, November 01, 2003 2:14 PM
> To: linux-serial@vger.kernel.org
> Subject: Re: Best way to detect received call on dumb modem ...
> 
> 
> On Sat, 2003-11-01 13:43:23 -0700, Lewis Brown <lewisb@denveronline.com>
> wrote in message <000001c3a0b8$ce82efa0$0200000a@francois>:
> > Hello,
> > 
> > I'm trying to detect incoming calls on a dumb modem but dealing with a
> > driver that doesn't implement TIOCMIWAIT or TIOCGICOUNT. I'm puzzled
> how
> > best to go forward in an efficient way.
> 
> select() on the fd and wait until you receive "RING"? However, what's a
> "dumb" modem?
> 
> MfG, JBG
> 
>