search for: is_coherent

...nv_device_is_cpu_coherent(device) || nvbo->force_coherent) > + return; Is the is_cpu_coherent check really required? On coherent platforms the sync_for_foo should be a noop. It's the dma api's job to encapsulate this knowledge so that drivers can be blissfully ignorant. The explicit is_coherent check makes this a bit leaky. And same comment that underlying the bus-specifics dma-mapping functions are identical. -Daniel > + > + if (nv_device_is_pci(device)) { > + for (i = 0; i < ttm_dma->ttm.num_pages; i++) > + pci_dma_sync_single_for_device(device->pdev, > +...

...dma_common_free_remap(cpu_addr, size, VM_ARM_DMA_CONSISTENT | VM_USERMAP); } @@ -1653,8 +1653,7 @@ static int __map_sg_chunk(struct device *dev, struct scatterlist *sg, phys_addr_t phys = page_to_phys(sg_page(s)); unsigned int len = PAGE_ALIGN(s->offset + s->length); - if (!is_coherent && - !dma_get_attr(DMA_ATTR_SKIP_CPU_SYNC, attrs)) + if (!is_coherent && (attrs & DMA_ATTR_SKIP_CPU_SYNC) == 0) __dma_page_cpu_to_dev(sg_page(s), s->offset, s->length, dir); prot = __dma_direction_to_prot(dir); @@ -1767,8 +1766,7 @@ static void __iommu_unmap_sg...

...oherent) > >>+ return; > > > >Is the is_cpu_coherent check really required? On coherent platforms the > >sync_for_foo should be a noop. It's the dma api's job to encapsulate this > >knowledge so that drivers can be blissfully ignorant. The explicit > >is_coherent check makes this a bit leaky. And same comment that underlying > >the bus-specifics dma-mapping functions are identical. > > I think you are right, the is_cpu_coherent check should not be needed here. > I still think we should have separate paths for the PCI/DMA cases though, > u...

...vice) || nvbo->force_coherent) >> + return; > > Is the is_cpu_coherent check really required? On coherent platforms the > sync_for_foo should be a noop. It's the dma api's job to encapsulate this > knowledge so that drivers can be blissfully ignorant. The explicit > is_coherent check makes this a bit leaky. And same comment that underlying > the bus-specifics dma-mapping functions are identical. I think you are right, the is_cpu_coherent check should not be needed here. I still think we should have separate paths for the PCI/DMA cases though, unless you can point me...

Hi, This is third approach (complete this time) for replacing struct dma_attrs with unsigned long. The main patch (2/45) doing the change is split into many subpatches for easier review (3-43). They should be squashed together when applying. *Important:* Patchset is *only* build tested on allyesconfigs: ARM, ARM64, i386, x86_64 and powerpc. Please provide reviewes and tests for other

Another revision of this patchset critical for GK20A to operate. Previous attempts were exclusively using either TTM's regular page allocator or the DMA API one. Both have their advantages and drawbacks: the page allocator is fast but requires explicit synchronization on non-coherent architectures, whereas the DMA allocator always returns coherent memory, but is also slower, creates a

Hi all, this series replaced the DMA_ATTR_NON_CONSISTENT flag to dma_alloc_attrs with a separate new dma_alloc_pages API, which is available on all platforms. In addition to cleaning up the convoluted code path, this ensures that other drivers that have asked for better support for non-coherent DMA to pages with incurring bounce buffering over can finally be properly supported. I'm still a