James Carlson wrote: > 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. >
Actually, I've spent some time with embedded parts. Most of them have 16550 work-alikes. There are a few other common variations as well, but they start to have weird limitations or be used for special things (like 9-bit data, which we lack an API for in Solaris.) Or they are used where cost is such a factor that even a 16550's complexity is too much. (Typically microcontrollers.) Solaris isn't used (that I'm aware of) on any platforms where this is likely to be an issue. Even if we did a MIPS port, the 16550 interface is still the most common way to talk to a serial port. I think this is largely true for PowerPC as well (though I've heard rumors of zs-ish ports on macs.) ARM processors have a different variant, but we don't run on ARM. And I've not heard any rumors of any attempt to change that. (Though I'd _love_ to tackle a port to MIPS. There are some interesting MIPS parts out on the market, including a 16-core 1GHz-ish part that probably _needs_ an OS like Solaris to really shine.) > 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. > This would be true if we were looking at supporting a bunch of other UART-ish parts. We aren't, as far as I know. Even zs, as far as I know, is dead. I think se might still be alive for synchronous stuff, but I don't know that anyone us doing anything for async comm with it. In any case, the synchronous ports have different APIs, and I'm not ready to tackle them yet. FWIW, the newer uart framework will probably lend itself to creation of a GSD-like device if anyone really needs it. Then we'd have something like pcser->uart->gsd (module dependencies). Right now I'm keeping it all in uart.c. > >> 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. ;-} > I intentionally have _not_ looked. (I did find 82510 datasheets, but I'm now fairly confident that the part is irrelevant.) > >>> 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? > Agreed. But for some things, like stop and start flow control characters, we have an API already, but we don't make use of the hardware features. That would be a good start, I think. > >> 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. > According to the 16550 datasheet, the timer should be 4 character times. Yes, its latency, but its small enough that even at 1200 baud you should never notice it. Go slower, and it becomes a problem. Because even interactive typing at 300 baud you will start to notice the incurred delays. Running a mouse at 300 baud, the delay would make it unusable. (Approximately 100 milliseconds.) The solution to this problem that I'm using is to shorten the fifo trigger threshold to 1 character if the baud rate is low (currently slower than 1200). I can make this a tunable if there is value in it. > >> 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. > See above for an explanation of why I think this isn't a problem in my code. However, I think I've seen evidence of an attempt by old code to use a host-driven poll instead of the timeout interrupt. That would give long latencies, for sure. But no current driver for Solaris or NetBSD that I've looked at does this. > >> 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 ... > We weren't. I consider the latency you're talking about to be uninteresting (4 character times) in the typical case, and avoidable (1 character rx threshold trigger) in the few cases where it is interesting. -- Garrett D'Amore, Principal Software Engineer Tadpole Computer / Computing Technologies Division, General Dynamics C4 Systems http://www.tadpolecomputer.com/ Phone: 951 325-2134 Fax: 951 325-2191 _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
