Re: code review request: simple usb stream interface (susi)

>> On my embedded platform, it is fairly expensive to do write-merging in 
>> order to send maximum length packets. (In other words, on my device, my 
>> "write" syscalls have a 1:1 correspondence with USB packets; when these 
>> packets are less than 64 bytes, I only get one packet per 1ms USB frame.)
>>     
>
> Why only one per frame?  Why not more?  Is that a limitation of the host
> controller driver on your platform?
>   
My understanding is that when the host controller is performing a read, 
it interprets the first short packet (less than 64 bytes in my case) as 
"end of data". The host could keep sending IN tokens until the device 
NAKs it, but it doesn't seem to do this. In other words, if the device 
is sending 150 bytes, it must send three packets exactly 64 + 64 + 22 
bytes. If it starts off with a 30 byte packet, that'll be the only 
packet that frame, because the host will interpret that to mean that 
only 30 bytes were available to be read.
 
Consequently, on the device end, even if I have several packets queued 
up to send to the host, the IN transaction will end on the first packet 
that is less than 64 bytes. My embedded device does not perform any 
write merging (a write syscall = a packet), and so my packets are often 
less than 64 bytes. Since there is only one pending read URB in my 
current driver code, I only get the first packet, because the host 
controller interprets that as the end of the transfer. When the next 
frame comes along, there's a fresh read URB, so the host pulls in the 
next packet, but it too is (usually) short. I end up getting one packet 
per frame.

Having multiple reads pending will cause the host controller to continue 
requesting data (to service the other URBs) until the device actually 
NAKs the IN token-- at least that's my hope.

I'm not able to find a section in the USB spec that defines this 
behavior, but the datasheet for my usb device (LPC2378) describes it 
this way, and it's consistent with the behavior I see on my ICH8 ECHI 
hub. I would very much welcome any clarifications/confirmations!

>> (Could read callbacks be called out of order or 
>> concurrently on an SMP machine?)
>>     
>
> No.  Nor could write callbacks. 
Is this because all callbacks are performed on the hub thread?

Thanks for all of the extremely helpful discussion and code reviews! I 
think I've got most of the problems Oliver pointed out fixed, and the 30 
second "lock up" upon disconnecting a device is now gone, hurrah! I'm 
going to do a little more in-house testing here, but I'll be back... :)

-Ed

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel