On Thu, 5 Jun 2003, Oliver Neukum wrote:

> > > extern inline dma_addr_t pci_map_single(struct pci_dev *hwdev, void *ptr,
> > >                                   size_t size, int direction)
> > > {
> > >   if (direction == PCI_DMA_NONE)
> > >           BUG();
> > >
> > > #ifndef CONFIG_COHERENT_IO
> > >   dma_cache_wback_inv((unsigned long)ptr, size);
> > > #endif
> > >
> > >   return virt_to_bus(ptr);
> > > }
> > >
> > > It is probably best to allocate all buffers seperately.
> >
> > I don't follow you.  What's inefficient about this?  It looks like the
> > decision of whether or not to call dma_cache_wback_inv() has nothing to do
> > with what other data is stored in the same memory block with the output
> > buffer.  And there's nothing that indicates dma_cache_wback_inv() is less
> > efficient when ptr isn't aligned on a cacheline.
> 
> No, I meant sharing it. You'd get a full hard cache miss.

I get it.  The writeback-and-invalidate means that the next time the CPU 
tries to access any data in that region of memory it must wait for the 
cache to fill up.  And apparently the MIPS doesn't support writeback 
without invalidating, which would make more sense for DMA_OUT operations.  
So your point that output buffers shouldn't share memory regions is well 
taken.

On the other hand, for DMA_IN it is most likely that the next piece of
data the CPU will access in that memory region is the input buffer itself.  
Especially if the memory region is devoted only to input buffers and the
input operations occur sequentially.  So nothing is lost by incurring a
cache miss there, because the CPU would have to refill its cache anyway.

Alan Stern



-------------------------------------------------------
This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Reply via email to