Subject: Re: issues with com and non-PCI platforms.... a proposal
To: Garrett D'Amore <>
From: Kurt J. Lidl <>
List: tech-kern
Date: 03/07/2006 00:02:01
On Mon, Mar 06, 2006 at 07:13:58PM -0800, Garrett D'Amore wrote:
> I have a few hardware platforms that have a basically compatible 16550
> chip on them, but they do something "funny".
> E.g. one chip maps registers at 4 byte offsets.

I've seen one of those (not running netbsd, but...)

> Fundamentally though, these are all 16550 variants or workalikes.
> Right now there are two approaches I've seen to solving this in NetBSD:
>     1) clone the com driver and change it to fit your local needs.  the
> aucom driver is a good example of this.
>     2) use a separate bus space.  I don't know of any existing examples
> outside of my AR5212 com driver.  In this case I had to implement a
> pretty hefty amount of bus space logic *in com_arbus.c".  This seems
> ugly and unwieldy.
> My proposal is to *change* com so that instead of using fixed offsets,
> it uses a register look up table.  E.g.
> bus_offset_t   sc_regoffs[NCOM_PORTS];
> #define   GETREG(x)   bus_space_read_1(bst, bsh, sc_regoffs[x])

For whatever it is worth, this is how the port of BSD/OS to the
UUNET Languardian worked.  It has a 16450 compatible serial chip,
and a hacked up version of the com driver found there, that implements
something very similar to this scheme.

In this case, the hardware is a 68040LC @ 25Mhz, and it doesn't fully
decode the address space where the I/O chips are located, so you
can only read in long words of information, and then have to mask
off the byte of data that represents the 8 bits of information you
really wanted.

> Objections I expect to hear are primarily performance related w.r.t.
> older (non-FIFO) parts.  Do folks still use these and expect to be able
> to do so for high performance applications?  I think if your ability to
> service the interrupt and keep up with the line is limited by an extra
> register index, then you probably are trying to drive your line too
> fast. ;-)

As long as it runs at 9600 bps on the commonly available platforms,
you'd get no complaint from me...  Mostly one tends to see these things
used for serial console access, and not so much for running hard-charging
serial applications like PPP links...