On Tue, 22 Jan 2008, David Brownell wrote: > > +static int map_urb_for_dma(struct usb_hcd *hcd, struct urb *urb, > > + gfp_t mem_flags) > > +{ ... > Right about here, I think, is where a comment is needed to explain > what's really going on here. Key points: > > - We need "local" memory, canonical example being > a small SRAM on a discrete controller being the > only memory that the controller can read ... > (a) "normal" kernel memory is no good, and > (b) there's not enough to share > > - The only *portable* hook for such stuff in the > DMA framework is dma_declare_coherent_memory() > > - So we use that, even though the primary requirement > is that the memory be "local" (hence addressible > by that device), not "coherent". > > Someday DMA memory management may be smart enough to handle this > stuff without such workarounds. Having a clear description of > this particular sub-problem should help. Having that knowledge > living outside the source tree ... won't. > > > > + else if (hcd->driver->flags & HCD_LOCAL_MEM) > > + ret = hcd_alloc_coherent( > > + urb->dev->bus, mem_flags, > > + &urb->setup_dma, > > + (void **)&urb->setup_packet, > > + sizeof (struct usb_ctrlrequest), > > + DMA_TO_DEVICE); > > + } Isn't the logical location for these comments at the beginning of hcd_alloc_coherent()'s definition, rather than the place where it is called? Alan Stern ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ linux-usb-devel@xxxxxxxxxxxxxxxxxxxxx To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel