search for: dma_sync_

...rent.c b/arch/mips/mm/dma-noncoherent.c index 563c2c0d0c8193..97a14adbafc99c 100644 --- a/arch/mips/mm/dma-noncoherent.c +++ b/arch/mips/mm/dma-noncoherent.c @@ -55,22 +55,34 @@ void *arch_dma_set_uncached(void *addr, size_t size) return (void *)(__pa(addr) + UNCAC_BASE); } -static inline void dma_sync_virt(void *addr, size_t size, +static inline void dma_sync_virt_for_device(void *addr, size_t size, enum dma_data_direction dir) { switch (dir) { case DMA_TO_DEVICE: dma_cache_wback((unsigned long)addr, size); break; - case DMA_FROM_DEVICE: dma_cache_inv((unsigned long)addr, size)...

...k+0x48/0x69 > [<c0461fc7>] warn_slowpath_common+0x87/0xc0 > [<c07b9029>] ? check_sync+0x169/0x6e0 > [<c07b9029>] ? check_sync+0x169/0x6e0 > [<c046203e>] warn_slowpath_fmt+0x3e/0x60 > [<c07b9029>] check_sync+0x169/0x6e0 > [<c07b96ad>] debug_dma_sync_single_for_device+0x7d/0x90 > [<f7ece298>] ? ttm_bo_del_sub_from_lru+0x18/0x50 [ttm] > [<c040bef0>] ? text_poke_bp+0xd0/0xd0 > [<f85d96db>] nouveau_bo_sync_for_device+0x8b/0xa0 [nouveau] > [<f85d97c4>] nouveau_bo_validate+0x34/0x40 [nouveau] > [<f85d995...

...memory." > >> > >> $ git grep dma_cache_sync drivers/media > >> $ > > > > AFAIK dma_cache_sync() isn't the only way to perform the cache > > synchronization. The earlier patch series that I reviewed relied on > > dma_get_sgtable() and then dma_sync_sg_*() (which existed in the > > vb2-dc since forever [1]). However, it looks like with the final code > > the sgtable isn't acquired and the synchronization isn't happening, so > > you have a point. > > Using the streaming sync calls on coherent allocations has also...

On Wed, Aug 19, 2020 at 03:07:04PM +0100, Robin Murphy wrote: >> FWIW, I asked back in time what the plan is for non-coherent >> allocations and it seemed like DMA_ATTR_NON_CONSISTENT and >> dma_sync_*() was supposed to be the right thing to go with. [2] The >> same thread also explains why dma_alloc_pages() isn't suitable for the >> users of dma_alloc_attrs() and DMA_ATTR_NON_CONSISTENT. > > AFAICS even back then Christoph was implying getting rid of NON_CONSISTENT > a...

...mory > in the driver should it choose to return non-consistent memory." > > $ git grep dma_cache_sync drivers/media > $ AFAIK dma_cache_sync() isn't the only way to perform the cache synchronization. The earlier patch series that I reviewed relied on dma_get_sgtable() and then dma_sync_sg_*() (which existed in the vb2-dc since forever [1]). However, it looks like with the final code the sgtable isn't acquired and the synchronization isn't happening, so you have a point. FWIW, I asked back in time what the plan is for non-coherent allocations and it seemed like DMA_ATTR_NO...

DMA_ATTR_SKIP_CPU_SYNC should only be used when the driver manually performs dma cache maintainance operations using the dma_sync_* calls. Nouveau doesn't do that, and generally just assumes DMA is coherent. Use plain dma_map_page which doesn't make this code correct but at least a little less wrong and simpler. Signed-off-by: Christoph Hellwig <hch at lst.de> --- drivers/gpu/drm/nouveau/nouveau_dmem.c | 10 +...

...ith cache coherent DMA. I really wonder what is the difference between this new API and alloc_pages(GFP_DMA, n). Is this API really needed? I thought that this is legacy thing to be removed one day... Maybe it would make more sense to convert the few remaining drivers to regular dma_map_page()/dma_sync_*()/dma_unmap_page() or have I missed something? Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland

...0, 2020 at 7:02 AM Christoph Hellwig <hch at lst.de> wrote: > > On Wed, Aug 19, 2020 at 03:07:04PM +0100, Robin Murphy wrote: > >> FWIW, I asked back in time what the plan is for non-coherent > >> allocations and it seemed like DMA_ATTR_NON_CONSISTENT and > >> dma_sync_*() was supposed to be the right thing to go with. [2] The > >> same thread also explains why dma_alloc_pages() isn't suitable for the > >> users of dma_alloc_attrs() and DMA_ATTR_NON_CONSISTENT. > > > > AFAICS even back then Christoph was implying getting rid of NO...

...t choose to return non-consistent memory." >> >> $ git grep dma_cache_sync drivers/media >> $ > > AFAIK dma_cache_sync() isn't the only way to perform the cache > synchronization. The earlier patch series that I reviewed relied on > dma_get_sgtable() and then dma_sync_sg_*() (which existed in the > vb2-dc since forever [1]). However, it looks like with the final code > the sgtable isn't acquired and the synchronization isn't happening, so > you have a point. Using the streaming sync calls on coherent allocations has also always been wrong per t...

On 11/10/2015 05:00 PM, Thierry Reding wrote: > On Tue, Nov 10, 2015 at 03:54:52PM +0100, Mario Kleiner wrote: >> From: Daniel Vetter <daniel.vetter at ffwll.ch> >> >> Apparently pre-nv50 pageflip events happen before the actual vblank >> period. Therefore that functionality got semi-disabled in >> >> commit af4870e406126b7ac0ae7c7ce5751f25ebe60f28

...) devices often are not coherent with the cache. So you need to writeback the cpu cache before transferring data to the device, and invalidate the cpu cache before transferring data from the device. Plus additional workarounds for speculation. Looks at the implementations and comments around the dma_sync_* calls. > > > Even worse I think this > > is actually broken at least for VIVT event for virtualized > > implementations. E.g. a KVM guest is going to access memory > > using different virtual addresses than qemu, vhost might throw > > in another different a...

It seems the problems running mthca in a Xen domU have uncovered a bug in mthca: mthca uses dma_sync_single in mthca_arbel_write_mtt_seg() and mthca_arbel_map_phys_fmr() to sync the MTTs that get written. However, Documentation/DMA-API.txt says: void dma_sync_single(struct device *dev, dma_addr_t dma_handle, size_t size, enum dma_data_direction direction) synchronise a single co...

On Wed, Jun 06, 2018 at 10:23:06PM -0700, Christoph Hellwig wrote: > On Thu, May 31, 2018 at 08:43:58PM +0300, Michael S. Tsirkin wrote: > > Pls work on a long term solution. Short term needs can be served by > > enabling the iommu platform in qemu. > > So, I spent some time looking at converting virtio to dma ops overrides, > and the current virtio spec, and the sad

On Wed, Jun 06, 2018 at 10:23:06PM -0700, Christoph Hellwig wrote: > On Thu, May 31, 2018 at 08:43:58PM +0300, Michael S. Tsirkin wrote: > > Pls work on a long term solution. Short term needs can be served by > > enabling the iommu platform in qemu. > > So, I spent some time looking at converting virtio to dma ops overrides, > and the current virtio spec, and the sad

...enum dma_data_direction direction) > { > - struct vb2_dc_buf *buf = dbuf->priv; > - struct sg_table *sgt = buf->dma_sgt; > - > - if (vb2_dc_buffer_consistent(buf->attrs)) > - return 0; > - > - dma_sync_sg_for_cpu(buf->dev, sgt->sgl, sgt->nents, buf->dma_dir); > return 0; > } > > @@ -355,13 +343,6 @@ static int > vb2_dc_dmabuf_ops_end_cpu_access(struct dma_buf *dbuf, > enum dma_data_direction direction) > { > - st...

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