On Tue, 20 Oct 2009, Greg Crocker wrote: > I am using the PLX Technologies OXU210HP USB Host Controller and would > like guidance on the best approach for working with memory constrained > devices. The OXU210 is a slave DMA device with 72K of SRAM and I have > modified an existing EHCI-OXU210HP driver to 'work' using > HCD_LOCAL_MEM. > > One issue I have not resolved is how to deal with the case where Linux > USB core system expects memory to available when usb_hcd_submit_urb is > called. I cannot provide a new implementation of ehci_urb_enqueue > because the call to map_urb_for_dma in usb_hcd_submit_urb fails before > ehci_enqueue_urb is called. To get through the initial board debug, I > have implemented an URB queue that allows the memory allocation to > fail and retry without depending on the higher level device drivers to > handle the failure. Most of them do not handle this situation > gracefully. As a result of breaking the USB state machine, I have > (not surprisingly) run into race conditions in how URBs are unlinked > and when devices are removed unexpectedly. > > At this point I am looking for recommendations on the best path going > forward. One option is to move the changes I made in usb/core to > usb/ehci-oxu210hp.c and add new functions to the hc_driver, similar to > ehci_urb_enqueue/dequeue, but this does not resolve the root cause of > needing the queue in the first place. You shouldn't need another queue at all; we've already got a queue of URBs for each endpoint. Instead you need to figure out how to deal with failures of map_urb_for_dma during submission. Here's a possible approach: Add a flag to the HCD structure indicating that the driver will handle its own DMA mapping, and avoid calling map_urb_for_dma and unmap_urb_for_dma when the flag is set. Then your driver can do whatever it wants. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
