James Carlson wrote: > Garrett D'Amore writes: > >> This is very, very useful information. Thanks. >> >> Both asy.c and su_driver.c are very, very crufty, and (quite honestly) >> suffer from some poor design. >> > > Indeed. Actually, all of the serial drivers in Solaris could use a > serious overhaul. > > At one point, I started working on a "GSD" (generic serial driver, > akin to GLD) to implement all of the common POSIX bits with simple > callbacks for the chip-specific bits. I ran out of spare cycles > during the day to think about it, but I suppose I might look at it > again. (If someone else with time could do it, that'd be even > better.) >
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. > Besides just plain old async serial I/O, there's the big problem of > synchronous I/O. That's a crime scene. We adopted the architecture > brought in by the 'zs' driver, and it's alien. It abuses DLPI (!), > just plain looks nothing like UNIX, and leaves the AT&T sys/termiox.h > interfaces adrift in the source base. > I'm staying the hell away from zs! :-) Besides, I don't have datasheets for the part. > It'd be nice to see that (zs and se) worked over. > > >> I'm rewriting much of my new uart >> framework from scratch, but I'm ditching 82510 support, and I might even >> require a FIFO. (I've not decided on that yet or not. My design is >> starting to demonstrate behavior that there is no difference between a >> fifo-less UART and a deep fifo apart from reliability/performance at >> high baud rates.) >> > > There probably shouldn't be much difference. > > 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. 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.) 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. 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. 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). -- 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
