On Tuesday 09 January 2007 5:50 pm, YunChuan Qin wrote: > Thanks for david's reply. I am really clear that why the dvevm board cann't > support a USB web camera.
Lack of ISO support is a different issue than "more than 4 endpoints". If lack of ISO support is not listed in the release notes, it should have been. In fact, all of the restrictions which I summarized here were supposed to have been release noted. > And now ,I have a additional question about this: > If I add ISO transfer support to the usb driver, how much work must be done > to it? I'm assuming you mean on host side... When you get an ISO URB, the transfer is already broken into packets using urb->iso_frame_desc[]. You'd use that to segment transfers, and to report their completion status, which is more straightforward with PIO than with DMA. And you'd need to pay careful attention to endpoint hardware setup, including issues like double buffering and maxpacket ... especially to supprt things like 16-bit QVGA at 30 FPS, which requires double buffering at more than 512 bytes per packet. > 2007/1/10, David Brownell <[EMAIL PROTECTED]>: > > > > On Monday 08 January 2007 7:19 pm, YunChuan Qin wrote: > > > spue35.pdf says the dm6446 usb controller Supports 4 simultaneous RX and > > TX > > > endpoints, more can be supported by dynamically switching, Does the USB > > host > > > driver support endpoint more than 4? > > > > Within limits, yes -- the endpoint FIFOs get recycled. > > > > - Control transfers always use ep0, no matter which device they go to. > > > > - Bulk TX and RX use dedicated endpoints; the code in the MontaVists > > kernels uses ep1 and ep2 in unidirectional mode, the code in the > > GIT tree uses ep1 in bidirectional mode. > > > > - Periodic transfers (only interrupt mode supported for now, no ISO > > yet) use the remaining endpoints (two in the 2.6.10 MVL code, and > > three in the GIT tree). > > > > So clearly any number of endpoints can be addressed, but that "switching" > > is not arbitrary. Once a hardware endpoint is assigned to a transfer, > > it's not reassigned until that transfer is complete. > > > > That produces two limitations of note: (1) control and bulk transfers > > can starve others in that same direction, if the target device is NAKing > > That's the normal operational mode for e.g. USB network adapters: post a > > read, eventually it succeeds with packet in hand. (2) since periodic > > transfers normaly re-issue, those endpoints get tied down for longer than > > is strictly necessary ... e.g. a keyboard, mouse, and hub could be polled > > sequentially on one FIFO, given fancier code, but instead each one now > > consumes its own endpoint. Removing those two limitations isn't what > > I'd call straightforward, especially since the CPPI DMA documentation > > is extremely vague about aborting transfers. > > > > - Dave > > > > > > > > > -- > blog site:blog.csdn.net/freasy > _______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
