Subject: Re: issues with com and non-PCI platforms.... a proposal
To: None <email@example.com>
From: Warner Losh <firstname.lastname@example.org>
Date: 03/07/2006 07:00:37
From: "Garrett D'Amore" <email@example.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:
in the softc and
#define GETREG(x) bus_space_read_1(bst, bsh, sc_regoffs[x])
#define GETREG(x) bus_space_read_1(bst, bsh, x)
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.