James Carlson wrote:
> Garrett D'Amore writes:
>
>> 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.)
>>
>
> Embedded PPC systems are very much different.
>
Lets consider them when the need arises, then. Frankly, I have no
hardware or experience with PPC to do anything interesting on them.
>
>> 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 wasn't thinking of ARM or MIPS. Sounds like fun for somebody. ;-}
>
Heh. Well, I have neither hardware nor time (unless someone funds it)
for such a port. But I really, really would be interested in doing a
MIPS64 port. It would be a challenging and interesting project.
>
>>> 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.
>>
>
> What about PowerQUICC, or whatever its successor is?
>
NFI. But, again, I don't know anything about synchronous comm, so I'm
hesitant to start off in that direction.
This whole project started mostly because I have an Ultra 20, it doesn't
have an onboard ISA serial port, and the multiport serial card I
purchased isn't supported by Solaris. (Neither was the USB serial
dongle I purchased. I've since returned that item.)
Scatching an itch in this fashion is almost _exactly_ how the "afe"
ethernet driver I wrote came into existence. :-)
>
>>> 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.
>>
>
> Maybe. I don't think it maps well into the "this is an interesting
> character" problem.
>
No, but it has its own uses (for flow control). There are a lot of neat
things on 16950 that we could do but have no API for, like extremely
high baud rates or 9-bit data.
Frankly, the whole termio serial management API is pretty crufty. But
I'm not prepared to undertake major changes to it. I just want my damn
PCI card to work. :-)
Along this road, I'm trying to include the support necessary so that
asy.c, su_driver.c, and pcser.c can be merged into a common framework.
That's a nice feature, but it isn't necessarily intrinsic to the problem
I'm trying to solve, which is enabling my hardware to work. :-)
Hopefully other people can benefit from my effort here. :-)
>
>>> 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.
>>
>
> Hmm. OK. We do have special hacks ("immediate" mode) just for the
> serial mouse case. The new driver should probably obey those.
>
Funny thing is, the "immediate" mode on su_driver.c is pointless. It
never uses a fifo trigger greater than one.
I found a lot of dead/pointless code in both su_driver.c and asy.c. It
feels good to clean house. :-)
>
>> 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.
>>
>
> If we're only talking about 4 character times on all the hardware
> you're planning to support, then I agree it shouldn't be an issue.
>
>
Well, its true for the hardware I know about.
--
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
