Re: uart vs sio differences ?

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!
>>
>> http://www.freebsd.org/cgi/query-pr.cgi?pr=121421
>>
>> Not sure if the semantics are exactly right, but adding
>>
>> hint.uart.0.flags="0x100"
>> hint.uart.1.flags="0x100"
>> hint.uart.2.flags="0x100"
>> hint.uart.3.flags="0x100"
>>
>> 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.
>>
>>         ---Mike
> 
> 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.
> 
> Scott
> 

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.

Scott