public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Alex Williamson <alex.williamson@hp.com>
To: Russell King <rmk+lkml@arm.linux.org.uk>
Cc: linux-kernel <linux-kernel@vger.kernel.org>, michael.knight@exar.com
Subject: Re: Exar ST16C2550 rev A2 bug
Date: Fri, 03 Dec 2004 14:06:11 -0700	[thread overview]
Message-ID: <1102107971.7078.34.camel@tdi> (raw)
In-Reply-To: <1101659181.2838.41.camel@mythbox>

Russell,

On Sun, 2004-11-28 at 09:26 -0700, Alex Williamson wrote:
> On Sun, 2004-11-28 at 11:10 +0000, Russell King wrote:
> > On Wed, Nov 17, 2004 at 11:26:47AM -0700, Alex Williamson wrote:
> > 
> > Can you check whether this patch solves it?  I'd rather not rely on
> > size_fifo() to do the right thing in every circumstance.
> 
>   I have a system on order with one of these bad UARTs.  I'll be happy
> to check the patch when it arrives (hopefully this week).

   No system yet, hopefully soon :^(

> > Essentially, if we find an EFR, we check whether the UART reports
> > DVID/DREV values corresponding to the known problem scenario, and
> > if so, we essentially ignore the EFR.
> > 
> > What I don't know is whether these DVID/DREV values correspond to
> > a real device which does have an EFR.  Maybe Exar people can shed
> > some light on this?
> 
>    I'll see if I can get an engineering contact from Exar to confirm.

   Michael Knight from Exar is CC'd.  Unfortunately it sounds like the
DVID/DREV registers are the same as another Exar product that does have
a valid EFR.  So this would restrict functionality on that part as well.
Perhaps a hybrid test, something like:

static int broken_efr(struct uart_8250_port *p)
{
	/*
	 * 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(p) == 0x0201 && size_fifo(p) == 16)
		return 1;

	return 0;
}

...

	if (!broken_efr(up)) {
		autoconfig_has_efr(up);
		return;
	}
...

   I think we know size_fifo() works on these parts, so we'd limit our
reliance on size_fifo().  If any more UARTs come alone with this issue
we could add them to the test.  Thoughts?  I can incorporate this into
your patch and test it when I get a system with these parts.  Thanks,

	Alex


> > ===== drivers/serial/8250.c 1.92 vs edited =====
> > --- 1.92/drivers/serial/8250.c	2004-11-19 07:03:10 +00:00
> > +++ edited/drivers/serial/8250.c	2004-11-28 11:02:32 +00:00
> > @@ -479,6 +479,34 @@
> >  }
> >  
> >  /*
> > + * Read UART ID using the divisor method - set DLL and DLM to zero
> > + * and the revision will be in DLL and device type in DLM.  We
> > + * preserve the device state across this.
> > + */
> > +static unsigned int autoconfig_read_divisor_id(struct uart_8250_port *p)
> > +{
> > +	unsigned char old_dll, old_dlm, old_lcr;
> > +	unsigned int id;
> > +
> > +	old_lcr = serial_inp(p, UART_LCR);
> > +	serial_outp(p, UART_LCR, UART_LCR_DLAB);
> > +
> > +	old_dll = serial_inp(p, UART_DLL);
> > +	old_dlm = serial_inp(p, UART_DLM);
> > +
> > +	serial_outp(p, UART_DLL, 0);
> > +	serial_outp(p, UART_DLM, 0);
> > +
> > +	id = serial_inp(p, UART_DLL) | serial_inp(p, UART_DLM) << 8;
> > +
> > +	serial_outp(p, UART_DLL, old_dll);
> > +	serial_outp(p, UART_DLM, old_dlm);
> > +	serial_outp(p, UART_LCR, old_lcr);
> > +
> > +	return id;
> > +}
> > +
> > +/*
> >   * This is a helper routine to autodetect StarTech/Exar/Oxsemi UART's.
> >   * When this function is called we know it is at least a StarTech
> >   * 16650 V2, but it might be one of several StarTech UARTs, or one of
> > @@ -490,7 +518,7 @@
> >   */
> >  static void autoconfig_has_efr(struct uart_8250_port *up)
> >  {
> > -	unsigned char id1, id2, id3, rev, saved_dll, saved_dlm;
> > +	unsigned int id1, id2, id3, rev;
> >  
> >  	/*
> >  	 * Everything with an EFR has SLEEP
> > @@ -540,21 +568,13 @@
> >  	 *  0x12 - XR16C2850.
> >  	 *  0x14 - XR16C854.
> >  	 */
> > -	serial_outp(up, UART_LCR, UART_LCR_DLAB);
> > -	saved_dll = serial_inp(up, UART_DLL);
> > -	saved_dlm = serial_inp(up, UART_DLM);
> > -	serial_outp(up, UART_DLL, 0);
> > -	serial_outp(up, UART_DLM, 0);
> > -	id2 = serial_inp(up, UART_DLL);
> > -	id1 = serial_inp(up, UART_DLM);
> > -	serial_outp(up, UART_DLL, saved_dll);
> > -	serial_outp(up, UART_DLM, saved_dlm);
> > -
> > -	DEBUG_AUTOCONF("850id=%02x:%02x ", id1, id2);
> > -
> > -	if (id1 == 0x10 || id1 == 0x12 || id1 == 0x14) {
> > -		if (id1 == 0x10)
> > -			up->rev = id2;
> > +	id1 = autoconfig_read_divisor_id(up);
> > +	DEBUG_AUTOCONF("850id=%04x ", id1);
> > +
> > +	id2 = id1 >> 8;
> > +	if (id2 == 0x10 || id2 == 0x12 || id2 == 0x14) {
> > +		if (id2 == 0x10)
> > +			up->rev = id1 & 255;
> >  		up->port.type = PORT_16850;
> >  		return;
> >  	}
> > @@ -634,8 +654,16 @@
> >  	serial_outp(up, UART_LCR, 0xBF);
> >  	if (serial_in(up, UART_EFR) == 0) {
> >  		DEBUG_AUTOCONF("EFRv2 ");
> > -		autoconfig_has_efr(up);
> > -		return;
> > +
> > +		/*
> > +		 * 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) {
> > +			autoconfig_has_efr(up);
> > +			return;
> > +		}
> >  	}
> >  
> >  	/*
> > 
> 
-- 
Alex Williamson                             HP Linux & Open Source Lab


  reply	other threads:[~2004-12-03 21:06 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-11-17 18:26 Exar ST16C2550 rev A2 bug Alex Williamson
2004-11-28 11:10 ` Russell King
2004-11-28 16:26   ` Alex Williamson
2004-12-03 21:06     ` Alex Williamson [this message]
2004-12-13 22:15       ` Alex Williamson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1102107971.7078.34.camel@tdi \
    --to=alex.williamson@hp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=michael.knight@exar.com \
    --cc=rmk+lkml@arm.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox