On Thu, 6 Apr 2006, Tommi Kyntola wrote: > Actually we're using both, but the 300MHz I was referring to earlier has ohci. > > I read through the control message handling again, and while I was searching > for timeouts earlier this time I checked the transfer size manipulation and > indeed > it passes the control message (given that it's no more than 4096) relatively > directly to the controller dma. (regardless of whether it's uhci or ohci, it > would seem)
It's not entirely clear what you mean here. Certainly uhci-hcd does not do this. It breaks the message up into 64-byte chunks and passes the chunks individually to the controller's DMA unit. > Our electronics engineer (also responsible for the firmware) had stated > earlier that only 64byte packets are possible, but he seems to have neglected > the > fact that downloads using control messages are handled by the EZ usb > controller directly. There's a difference between packets and messages. Your engineer was correct; the device can accept only 64-byte packets. But messages can be much larger. > The download in 2 4kb control transfers now takes only > 7 or 8 ms each, totaling to 15ish ms, which is quite an improvement over the > 600ish ms I experience earlier with 2.6.XX kernels. So the problem we had has > been solved. Good. > ((Oh, another thing while we're at it. As I now understand it, the ochi/uchi > controller HW then slices the 4096 TD into 64 byte usb frames that go down > the cable, yes? You're using the wrong words. In OHCI the hardware does do this, but with UHCI it's done by the driver. And it's not the TD that gets sliced up; the data buffer gets sliced up into 64-byte chunks each of which gets its own TD. Each TD then is associated with a single transaction and each transaction is three packets: token, data, and handshake. With UHCI you get only one transaction per frame, but if you're transferring 4096 bytes in 8 ms then obviously your throughput is higher, more like 8 transactions per frame. > And obviously the same thing happens with bulk messages. Given that the > EZusb would seem > to only have 64 bytes of memory for the incoming packet handling of bulk > messages. > Is it possible to send larges bulk messages (multiples of 64) to the EZusb > endpoint > which would then handle them one-by-one, but in one big transfer? Yes. "Transfer" is a logical concept; it exists only on the host computer. On the bus and to the device, the whole thing appears as a sequence of 64-byte data packets. It doesn't matter whether those packets are all part of a single big transfer or are submitted as multiple smaller transfers; to the device they appear the same. Only the timing is different. > If so, then our card engineer has missed something quite essential about > the EZusb > specs... and there's quite a bit we can do also to speed up the bulk > transfers > that follow the software download... )) This has nothing to do with the device specs; it's a matter of how Linux handles USB transfers. However I wouldn't be at all surprised if you find you can speed up your bulk transfers in the same way as you sped up the firmware download. > However, I'm still wondering why the usleep(1000) between the 64 byte control > transfers speeded up the process as a whole (i.e. it dropped the rate from > 4ms/packet down to 3ms/packet). Not having looked into it any further, > > I'm guessing that's a side-effect of the urb enqueuing mechanism or > some other anomaly that relates to the bandwidth control. > In either case it seems fishy. It's hard to say for certain, especially because you're using two different kinds of hardware. With uhci-hcd, new transfers can start only at 1-ms frame boundaries. Likewise, results of a completed transfer are reported only at the end of a frame. So when a transfer completes, it's too late to submit a new transfer to begin in the current frame since the current frame has already started. A new transfer can't begin until the next frame, and since the transfers requires 3 frames to complete (that's 1 ms per transaction and 3 transactions, not 3 ms per packet), you end up waiting 4 ms. Alan Stern ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ [email protected] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
