> > > > > > You still need to fix this to use dma_alloc_coherent(), and its > > > > > > sibling function to use dma_free_coherent(). > > > > > > > > > > > > ... > > > > > > > > > > This buffer is synced using dma_sync_single_*/dma_(un)map_single when > > > > > the request is queued and when the transmission is complete. To > > > > > > > > No. See <linux/usb_gadget.h> for the definition of > > > > usb_ep_alloc_buffer(); > > > > it says explicitly that such mapping calls are not required. > > > > > > > > The only portable way to guarantee that is to allocate coherent memory. > > > > > > Then I can remove the dma_sync_single calls from ep_queue() and done()? > > > > Not a good idea. There are two ways that a DMA address gets > > provided to the lower level code: (a) coherent buffer allocation, > > as above, and (b) mapping done by driver, and re-used. The former > > doesn't need dma_sync_single(). The latter does. > > Do you mean that the buf of a usb_request could be allocated other than > calling usb_ep_alloc_buffer()?
Yes, see case (b) above ... > I mean if usb_ep_alloc_buffer() is required and only used in allocating > buffer to be processed by ep_queue() and done(). We can choose to use > one of the ways you mentioned above, not both. In this case, I preferred > to choose the second way for better performance. But it's not **CORRRECT** except in the case I noted ... which is not gauranteed, or assumed, elsewhere in the driver. ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
