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 - [email protected]
