search for: dma_attr_no_kernel_map

...trs & DMA_ATTR_WRITE_COMBINE) ? + pgprot_writecombine(prot) : + pgprot_dmacoherent(prot); return prot; } @@ -744,7 +744,7 @@ static void *__dma_alloc(struct device *dev, size_t size, dma_addr_t *handle, .gfp = gfp, .prot = prot, .caller = caller, - .want_vaddr = !dma_get_attr(DMA_ATTR_NO_KERNEL_MAPPING, attrs), + .want_vaddr = ((attrs & DMA_ATTR_NO_KERNEL_MAPPING) == 0), }; #ifdef CONFIG_DMA_API_DEBUG @@ -887,7 +887,7 @@ static void __arm_dma_free(struct device *dev, size_t size, void *cpu_addr, .size = PAGE_ALIGN(size), .cpu_addr = cpu_addr, .page = page, - .want_vaddr =...

...imize the allocations for devices which don't care about how contiguous the backing memory is. Do you think we could add an attrs argument to this function and pass it there? As ARM is being moved to the common iommu-dma layer as well, we'll probably make use of the argument to support the DMA_ATTR_NO_KERNEL_MAPPING attribute to conserve the vmalloc area. Best regards, Tomasz

...> + * consistent CPU pointer > + */ > + dma_set_attr(DMA_ATTR_NON_CONSISTENT, &node->attrs); > + dma_set_attr(DMA_ATTR_WEAK_ORDERING, &node->attrs); > + dma_set_attr(DMA_ATTR_WRITE_COMBINE, &node->attrs); > + dma_set_attr(DMA_ATTR_NO_KERNEL_MAPPING, &node->attrs); I wonder, is it possible to have a per-priv version of this instead of per-object? The kernel's function prototypes aren't marked const or anything, which gives me some doubts, but it's worth checking. > + > + node->cpuaddr = dma_alloc_attrs(d...

...* We will access this memory through PRAMIN and thus do not need a + * consistent CPU pointer + */ + dma_set_attr(DMA_ATTR_NON_CONSISTENT, &node->attrs); + dma_set_attr(DMA_ATTR_WEAK_ORDERING, &node->attrs); + dma_set_attr(DMA_ATTR_WRITE_COMBINE, &node->attrs); + dma_set_attr(DMA_ATTR_NO_KERNEL_MAPPING, &node->attrs); + + node->cpuaddr = dma_alloc_attrs(dev, npages << PAGE_SHIFT, + &node->handle, GFP_KERNEL, + &node->attrs); if (!node->cpuaddr) { nv_error(priv, "cannot allocate DMA memory\n"); return -ENOMEM; diff --git a/lib/include/...

...* We will access this memory through PRAMIN and thus do not need a + * consistent CPU pointer + */ + dma_set_attr(DMA_ATTR_NON_CONSISTENT, &node->attrs); + dma_set_attr(DMA_ATTR_WEAK_ORDERING, &node->attrs); + dma_set_attr(DMA_ATTR_WRITE_COMBINE, &node->attrs); + dma_set_attr(DMA_ATTR_NO_KERNEL_MAPPING, &node->attrs); + + node->cpuaddr = dma_alloc_attrs(dev, npages << PAGE_SHIFT, + &node->handle, GFP_KERNEL, + &node->attrs); if (!node->cpuaddr) { nv_error(priv, "cannot allocate DMA memory\n"); return -ENOMEM; diff --git a/lib/include/...

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

...ev, size, &buf->dma_addr, - GFP_KERNEL | gfp_flags, &buf->attrs); + GFP_KERNEL | gfp_flags, buf->attrs); if (!buf->cookie) { dev_err(dev, "dma_alloc_coherent of size %ld failed\n", size); kfree(buf); return ERR_PTR(-ENOMEM); } - if (!dma_get_attr(DMA_ATTR_NO_KERNEL_MAPPING, &buf->attrs)) + if (!dma_get_attr(DMA_ATTR_NO_KERNEL_MAPPING, buf->attrs)) buf->vaddr = buf->cookie; /* Prevent the device from being released while the buffer is used */ @@ -194,7 +194,7 @@ static int vb2_dc_mmap(void *buf_priv, struct vm_area_struct *vma) vma->vm_...

...------------------------ - -DMA_ATTR_NON_CONSISTENT lets the platform to choose to return either -consistent or non-consistent memory as it sees fit. By using this API, -you are guaranteeing to the platform that you have all the correct and -necessary sync points for this memory in the driver. - DMA_ATTR_NO_KERNEL_MAPPING -------------------------- diff --git a/arch/alpha/kernel/pci_iommu.c b/arch/alpha/kernel/pci_iommu.c index 6f7de4f4e191e7..447e0fd0ed3895 100644 --- a/arch/alpha/kernel/pci_iommu.c +++ b/arch/alpha/kernel/pci_iommu.c @@ -952,5 +952,7 @@ const struct dma_map_ops alpha_pci_ops = { .dma_supp...

...ATTR_WRITE_BARRIER (1UL << 1) Any particular reason they start at 2, not 1? > +#define DMA_ATTR_WEAK_ORDERING (1UL << 2) > +#define DMA_ATTR_WRITE_COMBINE (1UL << 3) > +#define DMA_ATTR_NON_CONSISTENT (1UL << 4) > +#define DMA_ATTR_NO_KERNEL_MAPPING (1UL << 5) > +#define DMA_ATTR_SKIP_CPU_SYNC (1UL << 6) > +#define DMA_ATTR_FORCE_CONTIGUOUS (1UL << 7) > +#define DMA_ATTR_ALLOC_SINGLE_PAGES (1UL << 8) Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's...

...ges sort of > implies a struct page return value, but we return a kernel virtual > address. The other alternative would be to name the API > dma_alloc_noncoherent, but the whole non-coherent naming seems to put > people off. As a follow up I plan to move the implementation of the > DMA_ATTR_NO_KERNEL_MAPPING flag over to this framework as well, given > that is also is a fundamentally non coherent allocation. The replacement > for that flag would then return a struct page, as it is allowed to > actually return pages without a kernel mapping as the name suggested > (although most of the...

...> people off. You say that like it's a bad thing. I think the problem is more that people don't understand what non-coherent means and think they're supporting it when they're not. dma_alloc_manual_flushing()? > As a follow up I plan to move the implementation of the > DMA_ATTR_NO_KERNEL_MAPPING flag over to this framework as well, given > that is also is a fundamentally non coherent allocation. The replacement > for that flag would then return a struct page, as it is allowed to > actually return pages without a kernel mapping as the name suggested > (although most of the...

...devices which don't care about how contiguous > the backing memory is. Do you think we could add an attrs argument to this > function and pass it there? > > As ARM is being moved to the common iommu-dma layer as well, we'll probably > make use of the argument to support the DMA_ATTR_NO_KERNEL_MAPPING attribute to > conserve the vmalloc area. We could probably at it. However I wonder why this is something the drivers should care about. Isn't this really something that should be a kernel-wide policy for a given system?

...- * an enum dma_attr represents an attribute associated with a DMA - * mapping. The semantics of each attribute should be defined in - * Documentation/DMA-attributes.txt. - */ -enum dma_attr { - DMA_ATTR_WRITE_BARRIER, - DMA_ATTR_WEAK_ORDERING, - DMA_ATTR_WRITE_COMBINE, - DMA_ATTR_NON_CONSISTENT, - DMA_ATTR_NO_KERNEL_MAPPING, - DMA_ATTR_SKIP_CPU_SYNC, - DMA_ATTR_FORCE_CONTIGUOUS, - DMA_ATTR_ALLOC_SINGLE_PAGES, - DMA_ATTR_MAX, -}; - -#define __DMA_ATTRS_LONGS BITS_TO_LONGS(DMA_ATTR_MAX) - -/** - * struct dma_attrs - an opaque container for DMA attributes - * @flags - bitmask representing a collection of enum dma_att...

...------------------------ - -DMA_ATTR_NON_CONSISTENT lets the platform to choose to return either -consistent or non-consistent memory as it sees fit. By using this API, -you are guaranteeing to the platform that you have all the correct and -necessary sync points for this memory in the driver. - DMA_ATTR_NO_KERNEL_MAPPING -------------------------- diff --git a/arch/alpha/kernel/pci_iommu.c b/arch/alpha/kernel/pci_iommu.c index 81037907268d5c..291121e3b5a583 100644 --- a/arch/alpha/kernel/pci_iommu.c +++ b/arch/alpha/kernel/pci_iommu.c @@ -957,5 +957,7 @@ const struct dma_map_ops alpha_pci_ops = { .dma_supp...

Changes since v3: - Use a single dma_attr for all DMA-API allocations in instmem instead of one per allocation - Use device.info.ram_size instead of pfb->ram to check whether VRAM is present outside of nvkm Changes since v2: - Cleaner changes for ltc - Fixed typos in gk20a instmem IOMMU comments Changes since v1: - Add missing else condition in ltc - Remove extra flags that slipped into

...init_dma_attrs(&imem->attrs); - /* We will access the memory through our own mapping */ dma_set_attr(DMA_ATTR_NON_CONSISTENT, &imem->attrs); dma_set_attr(DMA_ATTR_WEAK_ORDERING, &imem->attrs); dma_set_attr(DMA_ATTR_WRITE_COMBINE, &imem->attrs); - dma_set_attr(DMA_ATTR_NO_KERNEL_MAPPING, &imem->attrs); - imem->cpu_map = gk20a_instobj_cpu_map_dma; nvkm_info(&imem->base.subdev, "using DMA API\n"); } diff --git a/lib/include/nvif/os.h b/lib/include/nvif/os.h index 2df30489179a..e8c06cb254dc 100644 --- a/lib/include/nvif/os.h +++ b/lib/include/nv...

Thanks Ilia for the v2 review! Here is the v3 of this IOMMU support for GK20A series. Changes since v2: - Cleaner changes for ltc - Fixed typos in gk20a instmem IOMMU comments Changes since v1: - Add missing else condition in ltc - Remove extra flags that slipped into nouveau_display.c and nv84_fence.c. Original cover letter: Patches 1-3 make the presence of a RAM device optional, and remove

...->attrs); > - /* We will access the memory through our own mapping */ > dma_set_attr(DMA_ATTR_NON_CONSISTENT, &imem->attrs); > dma_set_attr(DMA_ATTR_WEAK_ORDERING, &imem->attrs); > dma_set_attr(DMA_ATTR_WRITE_COMBINE, &imem->attrs); > - dma_set_attr(DMA_ATTR_NO_KERNEL_MAPPING, &imem->attrs); > - imem->cpu_map = gk20a_instobj_cpu_map_dma; > > nvkm_info(&imem->base.subdev, "using DMA API\n"); > } > diff --git a/lib/include/nvif/os.h b/lib/include/nvif/os.h > index 2df30489179a..e8c06cb254dc 100644 > --- a/lib/inc...

...e API naming, as alloc_pages sort of implies a struct page return value, but we return a kernel virtual address. The other alternative would be to name the API dma_alloc_noncoherent, but the whole non-coherent naming seems to put people off. As a follow up I plan to move the implementation of the DMA_ATTR_NO_KERNEL_MAPPING flag over to this framework as well, given that is also is a fundamentally non coherent allocation. The replacement for that flag would then return a struct page, as it is allowed to actually return pages without a kernel mapping as the name suggested (although most of the time they will actua...

...e 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. As a follow up I plan to move the implementation of the DMA_ATTR_NO_KERNEL_MAPPING flag over to this framework as well, given that is also is a fundamentally non coherent allocation. The replacement for that flag would then return a struct page, as it is allowed to actually return pages without a kernel mapping as the name suggested (although most of the time they will actua...