Re: [PATCH]dma rules violation in the option driver

Alan Stern <[email protected]>
Newsgroups gmane.linux.usb.devel
Message-ID <[email protected]>
On Tue, 27 Mar 2007, David Brownell wrote:

> > Hmm... A CPU has to access all that data, and reading a cache line
> > at a time surely as better. Although on the other hand, it's something
> > streaming and thus just using the cache space for no good reason.
> 
> Right.  "Potentially".  Displacing hot cachelines for use-once data
> will in various cases be a lose.

It would be nice to see somewhere a more explicit and detailed discussion 
of the tradeoffs.  Under what conditions is it better to allocate DMA 
memory rather than just using kmalloc() and calling dma_map_single()?


> > OK... I admit I must do something for usbmon working better when
> > DMA is pre-allocated, especially on PPC (where it simply gives
> > up immediately and returns 'D' tag). But it's somewhat difficult.
> > There's no portable API which I could use.
> 
> That is, when the application manages DMA adressing?  The driver "should"
> provide both the DMA and regular address, since not every underlying
> controller wil use the DMA address for all transfers.

That's not quite true.  The driver is obliged to provide a regular address 
if the controller doesn't use DMA, but it isn't obliged if the controller 
does use DMA.  And in fact it frequently happens with usb-storage; the 
underlying SCSI drivers provide a scatter-gather list with page addresses 
that are suitable for DMA but may not lie in kernel-accessible memory.

Alan Stern


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.