Subject: Re: Do 16650 or 16950 UARTs work for anyone?
To: None <cube@cubidou.net>
From: Thor Lancelot Simon <tls@rek.tjls.com>
List: current-users
Date: 08/11/2007 21:50:35
On Sat, Aug 11, 2007 at 09:26:58PM -0400, Thor Lancelot Simon wrote:
> On Sun, Aug 12, 2007 at 01:31:17AM +0200, Quentin Garnier wrote:
> > 
> > I have a number of console servers using a 8-port PCI card that uses an
> > OX16PCI954:
> 
> Do these work if you build your kernel with options COM_16650?  With my
> OX16PCI952, this appears to cause a flow-control deadlock -- possibly
> because it thinks the FIFO is the wrong size, so, with autoflow on,
> it never hits the CTS trigger point (that's all I can think of offhand;
> the code looks generally correct and hasn't changed in a very long time).

It's the setting of sc->fifolen.  It doesn't work with it set to the
correct value for a 1695x (128) and it doesn't work with it set to the
value currently used for 16650 (32) and I suspect it won't work with a
16650 with that setting either.  The problem is that unless you explicitly
change the way the trigger levels are used by writing a bit in one of the
config registers that we don't touch, the 16[69]50 scale the FIFO and
flow-control trigger points so software that assumes a 16550 will work.
You can end up with the chip in a state where it never interrupts (FIFO
trigger point set wrong) or never goes CTS (flow-control trigger point
set wrong).

The code currently in our tree may have been tested on a 16850, which
silently adjusts the values so you can't deadlock.  Or it may have
somehow lost a hunk that DTRT with the watermarks on big-FIFO chips.
Anyway, it doesn't work right.  It works properly if sc->fifolen is
set to 16, including the hardware flow control (at least, as far as I
can test it).

I'm going to change the code so it sets sc->fifolen=16 if it detects
16650, and turn COM_16650 on by default -- I assume it was off because
it was broken.

Thor