uart vs sio differences ?
scottl at samsco.org
Tue Dec 9 17:42:02 UTC 2008
Scott Long wrote:
> Mike Tancsa wrote:
>> At 05:39 PM 12/8/2008, Mike Tancsa wrote:
>>> What it appears to be is that as long as data is coming in, even at
>>> 1200bps, the ioctl FIONREAD returns zero and an actual read does not
>>> return any data until there is either a pause in the data coming in
>>> or possibly when we do a xmit/write at which point the accumulated
>>> data is available for us to read.
>>> We dont know if this is due to the hardware fifo or something in the
>>> driver itself.
>> OK, I think we found the issue!
>> Not sure if the semantics are exactly right, but adding
>> to device.hints fixed the issue!
>> The next question-- is there a way to do this with the ucom driver as
>> well ? We are seeing the same issue with it.
> It's pretty sad that the uart driver can't keep up with the 16550 at
> full FIFO depth, though I can see exactly why. Even though the driver
> will normally use a fast interrupt handler, that handler does nothing
> but schedule the sio swi thread. Well, I shouldn't say that that's the
> only thing it does; it also does a spinwait on a home-rolled semaphore
> with the swi thread, something that I'm not sure I understand. Maybe
> the author thought that there was a risk of missed wakeups of the swi?
> That aside, I think what needs to happen is for the driver to use the
> interrupt handler to pull the bytes out of the hardware and into an
> internal lockless ring buffer, then schedule the swi to process the ring
> buffer. I'll see if I can come up with some code for this today. Not
> sure if the same can be done for ucom since the USB stack below it
> presents a lot more complications and overhead.
Bah, that's what I get for reading code before I'm awake. The uart
driver does do exactly what I suggest it should. It has a 384 byte ring
buffer, which should be more than enough. So I wonder if the spin-wait
on the swi semaphore is what is killing it, though.
More information about the freebsd-current