On Thu, 8 Feb 2007, Edwin Olson wrote: > > >> 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".
That's right. Or "end of URB" if you want to be more precise. > 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. Correct. > 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 see. Yes, it will. > 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! I was confused at first between your host driver and your device driver; it looked like you were saying the host was an embedded platform. Now it makes sense, and your understanding is correct. > >> (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? No, they aren't. In fact they aren't performed in process context at all; they are done in interrupt context. The callbacks can't occur out of order because the host controller driver processes the URBs in the order they were submitted. They can't occur concurrently on SMP systems partly because the driver's data structures are protected by a spinlock (it's more complicated than that but you get the idea) and partly because the callbacks tend to occur while handling USB controller hardware interrupt requests, which cannot be nested. Alan Stern ------------------------------------------------------------------------- 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 _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
