Request for comments, messing with sys/dev/ic/com.c

[Brad Spencer <brad%anduin.eldar.org@localhost>]

Hello...

I have been working on a driver for the SC16IS7xx family of UARTs.
These are, more or less, a single or dual 16C450+ behind a I2C or SPI
bus instead of a computer bus.  Sorry for the length of all this.

I was able to reuse nearly all of sys/dev/ic/com.c, just attaching a
alternative frontend to it.  The results are at:

http://www.netbsd.org/~brad/SC16IS7XX.tar

The reason for the request for comments is that com.c is used in quite a
number of places and I didn't want to break it for anything else.  The
summary of the changes are as follows:

1) usually com.c runs with a high IPL.  In order to be able to access
the I2C or SPI bus, this can't be the case.  So a new hw_flag was added
called COM_HW_SOFTIRQ.  If this is true, com.c will make every effort to
run at IPL_SOFTSERIAL and drop and reacquire any spin locks.  In
addition, a couple control structures were changed out if SOFTIRQ is
enabled.  If there is a request for emulated IRQs this is done in the
upper part of the driver (actually in the bus driver that attaches the
tty port) and not com.c as the dual channel SC16IS7xx shares the
interrupt with both channels.  There was a use of a soft interrupt and
in the SOFTIRQ mode this was changed into a workqueue.  The reason being
that I had panics if it was a soft interrupt.  Since COM_HW_SOFTIRQ is
an option, none of the changes to com.c should effect anything else.

2) a new subtype was defined called COM_TYPE_SC16IS7XX which is set in
the frontend part of the driver much like the BCM AUX UART does.  The
chip will pretty much work without this as the registers are pretty much
a normal 16C450 with some additions, but the chip has a 64 byte FIFO and
some additional features and it was simpler to make a new subtype.

3) The chip supports a prescaler which may be identical to the 16650 and
16950.  No support existed in com.c for that.  I added another hardware
flag that will make some primitive use of it.  One could do the same
thing that was done for COM_TYPE_HAYESP, that is try to automatically
use it, but I mostly didn't bother as the prescaler use seems to mostly
be when the baud rate clock oscillator is very high and the baud rate
formula can't reach some of the lowest baud rates.  The frontend part of
the attachment provides a sysctl that can be used to turn the prescaler
on if that is desired.


The bus part of the attachment can make use of FDT on systems that have
that and it conforms to many of the directives in the published binding
for this chip family.  In particular, you can define a GPIO PIN to be
used with the chip's interrupt line.  Another quirk that one has to deal
with when working with this chip family is that it doesn't have a
standard oscillator frequency.  The breakout boards use and have used a
large variety of frequencies and chip supports a very wide range.  In
order to deal with this, you can either define the frequency in the FDT
overlay or use a provided sysctl to change it.

I am looking mostly for constructive comments if I did something
terrible.  The use of this chip might not be high outside of myself and
I want to make sure I don't break anything else.


What drove this effort was an interest in improving the latency, jitter
and drift from NMEA side of GPS modules that are being used as stratum-1
clock NTP clocks.  I have been using FTDI USB based UARTs and have
noticed that there is quite a bit of jitter and drift, probably from the
USB side, and while the PPS pulse deals with this usually, sometimes the
drift is bad enough that ntpd pulls the source for a bit.  I will say
that the tests with the SC16IS7xx chip running over SPI at 1Mhz are much
better than the FTDI chip for this use case so far.




-- 
Brad Spencer - brad%anduin.eldar.org@localhost