Garrett D'Amore writes: > I started with this in concept, and decided that there just wasn't much > value in it, and a generic 16550-ish UART driver was a lot more sensible.
Possibly so, but my concern is especially with embedded usages. Although 16550-compatible parts have taken over the desktop (somewhat unfortunately, as others such as Cirrus did much better long ago), the embedded area is much more diverse. I wouldn't want to have a robust 16550-ish implementation and a pile of lousy other ones. That seems like a loss to me. > I'm staying the hell away from zs! :-) Besides, I don't have datasheets > for the part. I don't blame you. But I'll bet I can find the datasheets available on the web. ;-} > > One issue to deal with on deep-FIFO parts is that you may want to > > interrupt on "special" characters, such as 7E in PPP or C0 on SLIP, to > > avoid latency on framed protocols, or even just 11/13 on ordinary > > in-band flow control. Doing this likely means some sort of new > > interfaces for those protocols to signal the need for expedited > > handling of certain sequences. > > > > The 16950 can do stuff like this. So can some really old parts, such as the CD1400. > I've not considered doing much in the > way of new 16950 support yet. For now I'm only going to do pure 16550, > but the newer parts can make use of a larger fifo. (I'll not assume > more than 16 chars deep, though.) It's not so much an issue of chip support as it is an issue of interfaces: how do we get the driver to turn this feature on when needed? > The latency considerations don't worry me too much, because at high > speeds the latency will be low, and at low speed my lower fifo > thresholds will trigger an interrupt before it gets deep enough to take > very long to process. Actually, the latency issues are _really_ annoying. With TCP/IP header compression in place, a packet with a single byte in it -- a keystroke, say -- becomes a 7 byte message on the wire. That easily fits in the FIFO, and there it rots until the timer kicks and sends it upwards. > The worse case probably occurs for 9600 baud, at which point the latency > could be up to 8 character times (plus a tiny bit more to allow for > interrupt handling latency). We're talking about an induced latency of > ~10 milliseconds. I'm talking about the FIFO-not-empty-but-not-yet-full idle buffer timer. If that's set as low as 10ms, that might not be horrible, though it might be noticable by some people. I've seen much higher settings, though. > The deepest 16550-compatible FIFO I know about is 16950, which has a > 128-byte FIFO (which is not enabled by default). At 9600, this is still > not too long -- latency on the order of 100 milliseconds. At high > speeds (57600 is a good example), its much less (1/6 in the case of 57600). I'm not sure we're talking about the same latency ... -- James Carlson, KISS Network <[EMAIL PROTECTED]> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
