Subject: issues with com and non-PCI platforms.... a proposal
To: None <>
From: Garrett D'Amore <>
List: tech-kern
Date: 03/06/2006 19:13:58
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.

Another does the same, but changes which end of the 32-bit word the
registers are located at.

Yet another has the transmit and receive data registers in separate offsets.

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])

Then the various attachment points can populate these registers as they
see fit.

This would probably reduce the need for some port-specific com drivers
(aucom at least, and I think I saw other examples but I'll withhold
names), and it would clean up my logic in the AR5312 port quite a bit.

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. ;-)

Let me know what folks think.  I'd love to clean this code up a bit.

Assuming folks are agreeable, I'd like to have willing volunteers for
testers too, since I don't have all the various incarnations of serial
ports that are out there.


Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
Phone: 951 325-2134  Fax: 951 325-2191