[Xen-devel] Re: mthca use of dma_sync_single is bogus

["Michael S. Tsirkin" <mst@xxxxxxxxxxxxxxxxxx>]

> Quoting Roland Dreier <rdreier@xxxxxxxxx>:
> Subject: Re: mthca use of dma_sync_single is bogus
> 
>  > >     void
>  > >     dma_sync_single_range(struct device *dev, dma_addr_t dma_handle,
>  > >                        unsigned long offset, size_t size,
>  > >                        enum dma_data_direction direction)
> 
>  > This is under Part II - Advanced dma_ usage - I don't think it's dealing 
> with
>  > non-consistent memory only (e.g. dma_declare_coherent_memory is there), 
> and this
>  > looks like a good fit.  Most functions here work for both consistent and
>  > non-consistent memory...  What makes you suspicious?
> 
> I was suspicious because it is described between the main noncoherent
> API stuff and dma_cache_sync().  But I think it is probably OK.
> 
> Unfortunately it is not that good a fit for our current code, since we
> use pci_map_sg() to do the DMA mapping on the MTT memory instead of
> dma_map_single().
> 
>  > I'm concerned that MTTs need a fair amount of memory,
>  > while the amount of coherent memory might be limited.
>  > Not that non-coherent memory systems are widespread ...
> 
> Yes, for example on ppc 4xx the amount of coherent memory is quite
> small by default (address space for non-cached mappings is actually
> what is limited, but it amounts to the same thing).
> 
> Maybe the least bad solution is to change to using dma_map_single()
> instead of pci_map_sg() in mthca_memfree.c.

Hmm.
What makes you think dma_sync_single_range can't be used on memory mapped
by pci_map_sg/dma_map_sg?

-- 
MST

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel