From: "Garrett D'Amore" <garrett_damore@tadpole.com>
Subject: issues with com and non-PCI platforms.... a proposal
Date: Mon, 06 Mar 2006 19:13:58 -0800

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

In FreeBSD we support the Japanese "pc98" platform (NEC PC-9801 and
PC-9821 series of machines).  These machines often have standard
devices glued into the system in non-standard ways.  These machines
are all low performance by today's standards (the fastest one I was
able to buy was 400MHz, and the fastest I've been able to track down
via overclocking pages is 600MHz).

> 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 is the approach that we take with the pc98 hardware on FreeBSD.
This approach has the advantage of being able to say something like:

#ifdef __HAS_ODD_COM_OFFSETS
bus_offset_t	sc_regoffs[];
#endif
in the softc and

#ifdef __HAS_ODD_COM_OFFSETS
#define   GETREG(x)   bus_space_read_1(bst, bsh, sc_regoffs[x])
#else
#define   GETREG(x)   bus_space_read_1(bst, bsh, x)
#endif

For those machines that only support traditional 16550 register
layouts.  If all register access goes through the macros, then you
can have the best of both worlds...

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

Warner