> > 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. - R. _______________________________________________ general mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
