Re: uart vs sio differences ?

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