Eric Lowe wrote:
> Oh, btw to throw a wrench in the works, it looks like qemu simulates a
> 16450. Since we are hopeful to get OpenSolaris OS's working as a guest
> OS under qemu (currently Belenix and Nevada install both bomb out in
> the ata driver) we should keep support for the 16450, or help Fabrice
> update the serial emulation to a 16550. :)
I'll keep that in mind. Probably I'll just continue to support 16450
for now. It would be good to get the emulation updated to 16550, though.
-- Garrett
>
> - Eric
>
> Garrett D'Amore wrote:
>> 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
