On Sunday 27 November 2005 10:52 am, Chris Humbert wrote: > The problem lies with a broken API, where dma_map_sg() can't > report errors. usb_buffer_map_sg() notes this problem: > > // FIXME generic api broken like pci, can't report errors > return dma_map_sg (controller, sg, nents, > usb_pipein (pipe) ? DMA_FROM_DEVICE : DMA_TO_DEVICE);
Hmm, I forgot about that issue. > This is very problematic for my memory constrained HC, where > -ENOMEM is common. Pretending to be a PIO controller and > handling DMA in-house is looking like a better solution. Especially since by the usual Linux definitions, it's not actually doing DMA ... the CPU is copying data. (Though it wouldn't need to do so for dma_alloc_coherent memory...) > The problem is I'm not writing a HCD, but a bus glue for OHCI, > and the OHCI core doesn't let the bus glue know about URB > completions. You're right, though, I should handle this with the > HCD's completion routine. I just need a hook to use. Your original patch had TD-level hooks: > > +struct td_ops { > > + void (*fill)(struct ohci_hcd *ohci, u32 info, dma_addr_t data, > > + int len, struct urb *urb, int index); > > + void (*done)(struct ohci_hcd *ohci, struct urb *urb, struct td *td); > > +}; If fill() could return fault codes, and you added some solution for allocating TDs without using the DMA pools, those hooks might almost suffice: return ENOMEM if TD+buffer alloc+fill fails, and then done() would free the TD and its buffer. One issue would be resource reservation for periodic transfers. Right now the bus bandwidth is reserved, no buffer memory. It'd be possible for the resubmit to fail because its buffer was reused. - Dave ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel