- Linaro-mm-sig - lists.linaro.org

[PATCH 3/3] iommu/tegra: smmu: Support read-only mapping

by Hiroshi Doyu

Support read-only mapping via struct dma_attrs. Signed-off-by: Hiroshi Doyu <hdoyu(a)nvidia.com> --- drivers/iommu/tegra-smmu.c | 41 +++++++++++++++++++++++++++++------------ 1 file changed, 29 insertions(+), 12 deletions(-) diff --git a/drivers/iommu/tegra-smmu.c b/drivers/iommu/tegra-smmu.c index fab1f19..3aff4cd 100644 --- a/drivers/iommu/tegra-smmu.c +++ b/drivers/iommu/tegra-smmu.c @@ -862,12 +862,13 @@ static size_t __smmu_iommu_unmap_largepage(struct smmu_as *as, dma_addr_t iova) } static int __smmu_iommu_map_pfn(struct smmu_as *as, dma_addr_t iova, - unsigned long pfn) + unsigned long pfn, int prot) { struct smmu_device *smmu = as->smmu; unsigned long *pte; unsigned int *count; struct page *page; + int attrs = as->pte_attr; pte = locate_pte(as, iova, true, &page, &count); if (WARN_ON(!pte)) @@ -875,7 +876,11 @@ static int __smmu_iommu_map_pfn(struct smmu_as *as, dma_addr_t iova, if (*pte == _PTE_VACANT(iova)) (*count)++; - *pte = SMMU_PFN_TO_PTE(pfn, as->pte_attr); + + if (dma_get_attr(DMA_ATTR_READ_ONLY, (struct dma_attrs *)prot)) + attrs &= ~_WRITABLE; + + *pte = SMMU_PFN_TO_PTE(pfn, attrs); FLUSH_CPU_DCACHE(pte, page, sizeof(*pte)); flush_ptc_and_tlb(smmu, as, iova, pte, page, 0); put_signature(as, iova, pfn); @@ -883,23 +888,27 @@ static int __smmu_iommu_map_pfn(struct smmu_as *as, dma_addr_t iova, } static int __smmu_iommu_map_page(struct smmu_as *as, dma_addr_t iova, - phys_addr_t pa) + phys_addr_t pa, int prot) { unsigned long pfn = __phys_to_pfn(pa); - return __smmu_iommu_map_pfn(as, iova, pfn); + return __smmu_iommu_map_pfn(as, iova, pfn, prot); } static int __smmu_iommu_map_largepage(struct smmu_as *as, dma_addr_t iova, - phys_addr_t pa) + phys_addr_t pa, int prot) { unsigned long pdn = SMMU_ADDR_TO_PDN(iova); unsigned long *pdir = (unsigned long *)page_address(as->pdir_page); + int attrs = _PDE_ATTR; if (pdir[pdn] != _PDE_VACANT(pdn)) return -EINVAL; - pdir[pdn] = SMMU_ADDR_TO_PDN(pa) << 10 | _PDE_ATTR; + if (dma_get_attr(DMA_ATTR_READ_ONLY, (struct dma_attrs *)prot)) + attrs &= ~_WRITABLE; + + pdir[pdn] = SMMU_ADDR_TO_PDN(pa) << 10 | attrs; FLUSH_CPU_DCACHE(&pdir[pdn], as->pdir_page, sizeof pdir[pdn]); flush_ptc_and_tlb(as->smmu, as, iova, &pdir[pdn], as->pdir_page, 1); @@ -912,7 +921,8 @@ static int smmu_iommu_map(struct iommu_domain *domain, unsigned long iova, struct smmu_as *as = domain->priv; unsigned long flags; int err; - int (*fn)(struct smmu_as *as, dma_addr_t iova, phys_addr_t pa); + int (*fn)(struct smmu_as *as, dma_addr_t iova, phys_addr_t pa, + int prot); dev_dbg(as->smmu->dev, "[%d] %08lx:%08x\n", as->asid, iova, pa); @@ -929,7 +939,7 @@ static int smmu_iommu_map(struct iommu_domain *domain, unsigned long iova, } spin_lock_irqsave(&as->lock, flags); - err = fn(as, iova, pa); + err = fn(as, iova, pa, prot); spin_unlock_irqrestore(&as->lock, flags); return err; } @@ -943,6 +953,10 @@ static int smmu_iommu_map_pages(struct iommu_domain *domain, unsigned long iova, unsigned long *pdir = page_address(as->pdir_page); int err = 0; bool flush_all = (total > SZ_512) ? true : false; + int attrs = as->pte_attr; + + if (dma_get_attr(DMA_ATTR_READ_ONLY, (struct dma_attrs *)prot)) + attrs &= ~_WRITABLE; spin_lock_irqsave(&as->lock, flags); @@ -977,8 +991,7 @@ static int smmu_iommu_map_pages(struct iommu_domain *domain, unsigned long iova, if (*pte == _PTE_VACANT(iova + i * PAGE_SIZE)) (*rest)++; - *pte = SMMU_PFN_TO_PTE(page_to_pfn(pages[i]), - as->pte_attr); + *pte = SMMU_PFN_TO_PTE(page_to_pfn(pages[i]), attrs); } pte = &ptbl[ptn]; @@ -1010,6 +1023,10 @@ static int smmu_iommu_map_sg(struct iommu_domain *domain, unsigned long iova, bool flush_all = (nents * PAGE_SIZE > SZ_512) ? true : false; struct smmu_as *as = domain->priv; struct smmu_device *smmu = as->smmu; + int attrs = as->pte_attr; + + if (dma_get_attr(DMA_ATTR_READ_ONLY, (struct dma_attrs *)prot)) + attrs &= ~_WRITABLE; for (count = 0, s = sgl; count < nents; s = sg_next(s)) { phys_addr_t phys = page_to_phys(sg_page(s)); @@ -1053,7 +1070,7 @@ static int smmu_iommu_map_sg(struct iommu_domain *domain, unsigned long iova, (*rest)++; } - *pte = SMMU_PFN_TO_PTE(pfn + i, as->pte_attr); + *pte = SMMU_PFN_TO_PTE(pfn + i, attrs); } pte = &ptbl[ptn]; @@ -1191,7 +1208,7 @@ static int smmu_iommu_attach_dev(struct iommu_domain *domain, struct page *page; page = as->smmu->avp_vector_page; - __smmu_iommu_map_pfn(as, 0, page_to_pfn(page)); + __smmu_iommu_map_pfn(as, 0, page_to_pfn(page), 0); pr_debug("Reserve \"page zero\" \ for AVP vectors using a common dummy\n"); -- 1.8.1.5

12 years, 5 months

1
0
0 0

[PATCH 2/3] ARM: dma-mapping: Pass DMA attrs as IOMMU prot

by Hiroshi Doyu

Pass DMA attribute as IOMMU property, which can be proccessed in the backend implementation of IOMMU. For example, DMA_ATTR_READ_ONLY can be translated into each IOMMU H/W implementaion. Signed-off-by: Hiroshi Doyu <hdoyu(a)nvidia.com> --- arch/arm/mm/dma-mapping.c | 34 +++++++++++++++++++++------------- 1 file changed, 21 insertions(+), 13 deletions(-) diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c index 4152ed6..cbc6768 100644 --- a/arch/arm/mm/dma-mapping.c +++ b/arch/arm/mm/dma-mapping.c @@ -1254,7 +1254,8 @@ err: */ static dma_addr_t ____iommu_create_mapping(struct device *dev, dma_addr_t *req, - struct page **pages, size_t size) + struct page **pages, size_t size, + struct dma_attrs *attrs) { struct dma_iommu_mapping *mapping = dev->archdata.mapping; unsigned int count = PAGE_ALIGN(size) >> PAGE_SHIFT; @@ -1280,7 +1281,7 @@ ____iommu_create_mapping(struct device *dev, dma_addr_t *req, break; len = (j - i) << PAGE_SHIFT; - ret = iommu_map(mapping->domain, iova, phys, len, 0); + ret = iommu_map(mapping->domain, iova, phys, len, (int)attrs); if (ret < 0) goto fail; iova += len; @@ -1294,9 +1295,10 @@ fail: } static dma_addr_t -__iommu_create_mapping(struct device *dev, struct page **pages, size_t size) +__iommu_create_mapping(struct device *dev, struct page **pages, size_t size, + struct dma_attrs *attrs) { - return ____iommu_create_mapping(dev, NULL, pages, size); + return ____iommu_create_mapping(dev, NULL, pages, size, attrs); } static int __iommu_remove_mapping(struct device *dev, dma_addr_t iova, size_t size) @@ -1332,7 +1334,7 @@ static struct page **__iommu_get_pages(void *cpu_addr, struct dma_attrs *attrs) } static void *__iommu_alloc_atomic(struct device *dev, size_t size, - dma_addr_t *handle) + dma_addr_t *handle, struct dma_attrs *attrs) { struct page *page; void *addr; @@ -1341,7 +1343,7 @@ static void *__iommu_alloc_atomic(struct device *dev, size_t size, if (!addr) return NULL; - *handle = __iommu_create_mapping(dev, &page, size); + *handle = __iommu_create_mapping(dev, &page, size, attrs); if (*handle == DMA_ERROR_CODE) goto err_mapping; @@ -1378,17 +1380,20 @@ static void *arm_iommu_alloc_attrs(struct device *dev, size_t size, size = PAGE_ALIGN(size); if (gfp & GFP_ATOMIC) - return __iommu_alloc_atomic(dev, size, handle); + + return __iommu_alloc_atomic(dev, size, handle, attrs); pages = __iommu_alloc_buffer(dev, size, gfp); if (!pages) return NULL; if (*handle == DMA_ERROR_CODE) - *handle = __iommu_create_mapping(dev, pages, size); + *handle = __iommu_create_mapping(dev, pages, size, attrs); else - *handle = ____iommu_create_mapping(dev, handle, pages, size); + *handle = ____iommu_create_mapping(dev, handle, pages, size, + attrs); + *handle = __iommu_create_mapping(dev, pages, size, attrs); if (*handle == DMA_ERROR_CODE) goto err_buffer; @@ -1513,7 +1518,7 @@ static int __map_sg_chunk(struct device *dev, struct scatterlist *sg, skip_cmaint: count = size >> PAGE_SHIFT; - ret = iommu_map_sg(mapping->domain, iova_base, sg, count, 0); + ret = iommu_map_sg(mapping->domain, iova_base, sg, count, (int)attrs); if (WARN_ON(ret < 0)) goto fail; @@ -1716,7 +1721,8 @@ static dma_addr_t arm_coherent_iommu_map_page(struct device *dev, struct page *p if (dma_addr == DMA_ERROR_CODE) return dma_addr; - ret = iommu_map(mapping->domain, dma_addr, page_to_phys(page), len, 0); + ret = iommu_map(mapping->domain, dma_addr, page_to_phys(page), len, + (int)attrs); if (ret < 0) goto fail; @@ -1756,7 +1762,8 @@ static dma_addr_t arm_iommu_map_page_at(struct device *dev, struct page *page, if (!dma_get_attr(DMA_ATTR_SKIP_CPU_SYNC, attrs)) __dma_page_cpu_to_dev(page, offset, size, dir); - ret = iommu_map(mapping->domain, dma_addr, page_to_phys(page), len, 0); + ret = iommu_map(mapping->domain, dma_addr, page_to_phys(page), len, + (int)attrs); if (ret < 0) return DMA_ERROR_CODE; @@ -1778,7 +1785,8 @@ static dma_addr_t arm_iommu_map_pages(struct device *dev, struct page **pages, __dma_page_cpu_to_dev(pages[i], 0, PAGE_SIZE, dir); } - ret = iommu_map_pages(mapping->domain, dma_handle, pages, count, 0); + ret = iommu_map_pages(mapping->domain, dma_handle, pages, count, + (int)attrs); if (ret < 0) return DMA_ERROR_CODE; -- 1.8.1.5

12 years, 5 months

1
0
0 0

[PATCH 1/3] common: DMA-mapping: add DMA_ATTR_READ_ONLY attribute

by Hiroshi Doyu

This patch adds DMA_ATTR_READ_ONLY attribute to the DMA-mapping subsystem. This sets mapping attribute read-only. Signed-off-by: Hiroshi Doyu <hdoyu(a)nvidia.com> --- include/linux/dma-attrs.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/linux/dma-attrs.h b/include/linux/dma-attrs.h index f272809..5d7371c 100644 --- a/include/linux/dma-attrs.h +++ b/include/linux/dma-attrs.h @@ -18,6 +18,7 @@ enum dma_attr { DMA_ATTR_NO_KERNEL_MAPPING, DMA_ATTR_SKIP_CPU_SYNC, DMA_ATTR_SKIP_FREE_IOVA, + DMA_ATTR_READ_ONLY, DMA_ATTR_MAX, }; -- 1.8.1.5

12 years, 5 months

1
0
0 0

[PATCH 0/3][RESEND] How to pass IOMMU map attr via DMA API?

by Hiroshi Doyu

In Tegra SoC, IOMMU can set some mapping attribute for each page, for exmaple, READable, and WRITEable. We'd like to use this feature *newly* for robustness, where read-only pages can be protected from being overwritten by wrong operation. We have been using IOMMU via DMA mapping API(ARM). DMA mapping API currently doesn't use "prot" parameter when calling IOMMU API. So this series tries to pass "struct dma_attrs *attrs" via "int prot" in IOMMU API. I'm not so sure if this implementation is right or not because: - Casting (struct dma_attrs *) to (int) in DMA API doesn't look nice. - IOMMU layer needs to cast (int) back to (struct dma_attrs *) again, which can be considered as violation of layers. If you have any implementations/suggestions, it would be really helpful. This series isn't applied cleanly but this is posted to request for comments. Hiroshi Doyu (3): common: DMA-mapping: add DMA_ATTR_READ_ONLY attribute ARM: dma-mapping: Pass DMA attrs as IOMMU prot iommu/tegra: smmu: Support read-only mapping arch/arm/mm/dma-mapping.c | 34 +++++++++++++++++++++------------- drivers/iommu/tegra-smmu.c | 41 +++++++++++++++++++++++++++++------------ include/linux/dma-attrs.h | 1 + 3 files changed, 51 insertions(+), 25 deletions(-) -- 1.8.1.5

12 years, 5 months

1
0
0 0

[PATCH] v4l2: videobuf2-dc: fix support for mappings without struct page in userptr mode

by Marek Szyprowski

Earlier version of dma-contig allocator in user ptr mode assumed that in all cases DMA address equals physical address. This was just a special case. Commit e15dab752d4c588544ccabdbe020a7cc092e23c8 introduced correct support for converting userpage to dma address, but unfortunately it broke the support for simple dma address = physical address for the case, when given physical frame has no struct page associated with it (this happens if one use for example dma_declare_coherent api or other reserved memory approach). This commit restores support for such cases. Signed-off-by: Marek Szyprowski <m.szyprowski(a)samsung.com> --- drivers/media/v4l2-core/videobuf2-dma-contig.c | 87 ++++++++++++++++++++++-- 1 file changed, 82 insertions(+), 5 deletions(-) diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c b/drivers/media/v4l2-core/videobuf2-dma-contig.c index fd56f25..1382749 100644 --- a/drivers/media/v4l2-core/videobuf2-dma-contig.c +++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c @@ -423,6 +423,39 @@ static inline int vma_is_io(struct vm_area_struct *vma) return !!(vma->vm_flags & (VM_IO | VM_PFNMAP)); } +static int vb2_dc_get_user_pfn(unsigned long start, int n_pages, + struct vm_area_struct *vma, unsigned long *res) +{ + unsigned long pfn, start_pfn, prev_pfn; + unsigned int i; + int ret; + + if (!vma_is_io(vma)) + return -EFAULT; + + ret = follow_pfn(vma, start, &pfn); + if (ret) + return ret; + + start_pfn = pfn; + start += PAGE_SIZE; + + for (i = 1; i < n_pages; ++i, start += PAGE_SIZE) { + prev_pfn = pfn; + ret = follow_pfn(vma, start, &pfn); + + if (ret) { + pr_err("no page for address %lu\n", start); + return ret; + } + if (pfn != prev_pfn + 1) + return -EINVAL; + } + + *res = start_pfn; + return 0; +} + static int vb2_dc_get_user_pages(unsigned long start, struct page **pages, int n_pages, struct vm_area_struct *vma, int write) { @@ -433,6 +466,9 @@ static int vb2_dc_get_user_pages(unsigned long start, struct page **pages, unsigned long pfn; int ret = follow_pfn(vma, start, &pfn); + if (!pfn_valid(pfn)) + return -EINVAL; + if (ret) { pr_err("no page for address %lu\n", start); return ret; @@ -468,16 +504,49 @@ static void vb2_dc_put_userptr(void *buf_priv) struct vb2_dc_buf *buf = buf_priv; struct sg_table *sgt = buf->dma_sgt; - dma_unmap_sg(buf->dev, sgt->sgl, sgt->orig_nents, buf->dma_dir); - if (!vma_is_io(buf->vma)) - vb2_dc_sgt_foreach_page(sgt, vb2_dc_put_dirty_page); + if (sgt) { + dma_unmap_sg(buf->dev, sgt->sgl, sgt->orig_nents, buf->dma_dir); + if (!vma_is_io(buf->vma)) + vb2_dc_sgt_foreach_page(sgt, vb2_dc_put_dirty_page); - sg_free_table(sgt); - kfree(sgt); + sg_free_table(sgt); + kfree(sgt); + } vb2_put_vma(buf->vma); kfree(buf); } +/* + * For some kind of reserved memory there might be no struct page available, + * so all that can be done to support such 'pages' is to try to convert + * pfn to dma address or at the last resort just assume that + * dma address == physical address (like it has been assumed in earlier version + * of videobuf2-dma-contig + */ + +#ifdef __arch_pfn_to_dma +static inline dma_addr_t vb2_dc_pfn_to_dma(struct device *dev, unsigned long pfn) +{ + return (dma_addr_t)__arch_pfn_to_dma(dev, pfn); +} +#elsif defined(__pfn_to_bus) +static inline dma_addr_t vb2_dc_pfn_to_dma(struct device *dev, unsigned long pfn) +{ + return (dma_addr_t)__pfn_to_bus(pfn); +} +#elsif defined(__pfn_to_phys) +static inline dma_addr_t vb2_dc_pfn_to_dma(struct device *dev, unsigned long pfn) +{ + return (dma_addr_t)__pfn_to_phys(pfn); +} +#else +static inline dma_addr_t vb2_dc_pfn_to_dma(struct device *dev, unsigned long pfn) +{ + /* really, we cannot do anything better at this point */ + return (dma_addr_t)(pfn) << PAGE_SHIFT; +} +#endif + static void *vb2_dc_get_userptr(void *alloc_ctx, unsigned long vaddr, unsigned long size, int write) { @@ -548,6 +617,14 @@ static void *vb2_dc_get_userptr(void *alloc_ctx, unsigned long vaddr, /* extract page list from userspace mapping */ ret = vb2_dc_get_user_pages(start, pages, n_pages, vma, write); if (ret) { + unsigned long pfn; + if (vb2_dc_get_user_pfn(start, n_pages, vma, &pfn) == 0) { + buf->dma_addr = vb2_dc_pfn_to_dma(buf->dev, pfn); + buf->size = size; + kfree(pages); + return buf; + } + pr_err("failed to get user pages\n"); goto fail_vma; } -- 1.7.9.5

12 years, 6 months

1
0
0 0

DMA mapping API(IOMMU) for ARM64?

by Hiroshi Doyu

Hi, Currently ARM64 supports swiotlb only as below[1]. AFAIU, swiotlb provides some kind of bounce buffer for some restricted H/Ws, and it cannot replace IOMMU H/W completely. So I'm wondering that we would need the IOMMU versions of dma_map_ops as Marek did for ARM32. If my understanding is correct, do you guys have any idea how it's going to be implemented? Can we reuse the current version of "iommu_ops" in "arch/arm/mm/dma-mapping.c" for ARM64 as well? Or do we need to rewrite 64bit version of iommu_ops completely in the same file as one with swiotlb, "arch/arm64/mm/dma-mapping.c"? Any feedback would be really appreciated. [1]: commit 09b55412469dfe6797244dc5836c17ed0c2f191b Author: Catalin Marinas <catalin.marinas(a)arm.com> Date: Mon Mar 5 11:49:30 2012 +0000 arm64: DMA mapping API This patch adds support for the DMA mapping API. It uses dma_map_ops for flexibility and it currently supports swiotlb. This patch could be simplified further if the DMA accesses are coherent (not mandated by the architecture) or if corresponding hooks are placed in the generic swiotlb code to deal with cache maintenance.

12 years, 6 months

6
11
0 0

[PATCH v4 0/4] add mutex wait/wound/style style locks

by Maarten Lankhorst

Version 4 already? Small api changes since v3: - Remove ww_mutex_unlock_single and ww_mutex_lock_single. - Rename ww_mutex_trylock_single to ww_mutex_trylock. - Remove separate implementations of ww_mutex_lock_slow*, normal functions can be used. Inline versions still exist for extra debugging, and to annotate. - Cleanup unneeded memory barriers, add comment to the remaining smp_mb(). Thanks to Daniel Vetter, Rob Clark and Peter Zijlstra for their feedback. --- Daniel Vetter (1): mutex: w/w mutex slowpath debugging Maarten Lankhorst (3): arch: make __mutex_fastpath_lock_retval return whether fastpath succeeded or not. mutex: add support for wound/wait style locks, v5 mutex: Add ww tests to lib/locking-selftest.c. v4 Documentation/ww-mutex-design.txt | 344 +++++++++++++++++++++++++++++++ arch/ia64/include/asm/mutex.h | 10 - arch/powerpc/include/asm/mutex.h | 10 - arch/sh/include/asm/mutex-llsc.h | 4 arch/x86/include/asm/mutex_32.h | 11 - arch/x86/include/asm/mutex_64.h | 11 - include/asm-generic/mutex-dec.h | 10 - include/asm-generic/mutex-null.h | 2 include/asm-generic/mutex-xchg.h | 10 - include/linux/mutex-debug.h | 1 include/linux/mutex.h | 363 +++++++++++++++++++++++++++++++++ kernel/mutex.c | 384 ++++++++++++++++++++++++++++++++--- lib/Kconfig.debug | 13 + lib/debug_locks.c | 2 lib/locking-selftest.c | 410 +++++++++++++++++++++++++++++++++++-- 15 files changed, 1492 insertions(+), 93 deletions(-) create mode 100644 Documentation/ww-mutex-design.txt -- ~Maarten

12 years, 6 months

4
10
0 0

[RFC][PATCH 0/2] dma-buf: add importer private data for reimporting

by Seung-Woo Kim

importer private data in dma-buf attachment can be used by importer to reimport same dma-buf. Seung-Woo Kim (2): dma-buf: add importer private data to attachment drm/prime: find gem object from the reimported dma-buf drivers/base/dma-buf.c | 31 ++++++++++++++++++++++++++++ drivers/gpu/drm/drm_prime.c | 19 ++++++++++++---- drivers/gpu/drm/exynos/exynos_drm_dmabuf.c | 1 + drivers/gpu/drm/i915/i915_gem_dmabuf.c | 1 + drivers/gpu/drm/udl/udl_gem.c | 1 + include/linux/dma-buf.h | 4 +++ 6 files changed, 52 insertions(+), 5 deletions(-) -- 1.7.4.1

12 years, 6 months

6
15
0 0

[PATCH] dma-buf: Cocci spatch "ptr_ret.spatch"

by Thomas Meyer

Signed-off-by: Thomas Meyer <thomas(a)m3y3r.de> --- diff -u -p a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c --- a/drivers/base/dma-buf.c +++ b/drivers/base/dma-buf.c @@ -680,10 +680,7 @@ int dma_buf_debugfs_create_file(const ch d = debugfs_create_file(name, S_IRUGO, dma_buf_debugfs_dir, write, &dma_buf_debug_fops); - if (IS_ERR(d)) - return PTR_ERR(d); - - return 0; + return PTR_RET(d); } #else static inline int dma_buf_init_debugfs(void)

12 years, 6 months

1
0
0 0

[PATCH v3 0/3] Wait/wound mutex implementation, v3

by Maarten Lankhorst

The following series implements the updated api for wait/wound mutex locks. The documentation and api should be complete, the implementation may not be final. There is no support for -rt yet, and TASK_DEADLOCK handling is missing too. However I believe that this is an implementation detail, and that the interface for users of the api will not behave differently. ww_acquire_ctx has been added, and a whole lot of api abuses are now correctly detected because of the extra state carried in ww_acquire_ctx if debugging is enabled. --- Maarten Lankhorst (3): arch: make __mutex_fastpath_lock_retval return whether fastpath succeeded or not. mutex: add support for wound/wait style locks, v3 mutex: Add ww tests to lib/locking-selftest.c. v3 Documentation/ww-mutex-design.txt | 322 +++++++++++++++++++++++++ arch/ia64/include/asm/mutex.h | 10 - arch/powerpc/include/asm/mutex.h | 10 - arch/sh/include/asm/mutex-llsc.h | 4 arch/x86/include/asm/mutex_32.h | 11 - arch/x86/include/asm/mutex_64.h | 11 - include/asm-generic/mutex-dec.h | 10 - include/asm-generic/mutex-null.h | 2 include/asm-generic/mutex-xchg.h | 10 - include/linux/mutex-debug.h | 1 include/linux/mutex.h | 257 ++++++++++++++++++++ kernel/mutex.c | 473 ++++++++++++++++++++++++++++++++++--- lib/debug_locks.c | 2 lib/locking-selftest.c | 439 +++++++++++++++++++++++++++++++++- 14 files changed, 1469 insertions(+), 93 deletions(-) create mode 100644 Documentation/ww-mutex-design.txt -- Signature

12 years, 6 months

5
29
0 0

[PATCH] mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls

by Marek Szyprowski

dmapool always calls dma_alloc_coherent() with GFP_ATOMIC flag, regardless the flags provided by the caller. This causes excessive pruning of emergency memory pools without any good reason. This patch changes the code to correctly use gfp flags provided by the dmapool caller. This should solve the dmapool usage on ARM architecture, where GFP_ATOMIC DMA allocations can be served only from the special, very limited memory pool. Reported-by: Soren Moch <smoch(a)web.de> Reported-by: Thomas Petazzoni <thomas.petazzoni(a)free-electrons.com> Signed-off-by: Marek Szyprowski <m.szyprowski(a)samsung.com> --- mm/dmapool.c | 27 +++++++-------------------- 1 file changed, 7 insertions(+), 20 deletions(-) diff --git a/mm/dmapool.c b/mm/dmapool.c index c5ab33b..86de9b2 100644 --- a/mm/dmapool.c +++ b/mm/dmapool.c @@ -62,8 +62,6 @@ struct dma_page { /* cacheable header for 'allocation' bytes */ unsigned int offset; }; -#define POOL_TIMEOUT_JIFFIES ((100 /* msec */ * HZ) / 1000) - static DEFINE_MUTEX(pools_lock); static ssize_t @@ -227,7 +225,6 @@ static struct dma_page *pool_alloc_page(struct dma_pool *pool, gfp_t mem_flags) memset(page->vaddr, POOL_POISON_FREED, pool->allocation); #endif pool_initialise_page(pool, page); - list_add(&page->page_list, &pool->page_list); page->in_use = 0; page->offset = 0; } else { @@ -315,30 +312,21 @@ void *dma_pool_alloc(struct dma_pool *pool, gfp_t mem_flags, might_sleep_if(mem_flags & __GFP_WAIT); spin_lock_irqsave(&pool->lock, flags); - restart: list_for_each_entry(page, &pool->page_list, page_list) { if (page->offset < pool->allocation) goto ready; } - page = pool_alloc_page(pool, GFP_ATOMIC); - if (!page) { - if (mem_flags & __GFP_WAIT) { - DECLARE_WAITQUEUE(wait, current); - __set_current_state(TASK_UNINTERRUPTIBLE); - __add_wait_queue(&pool->waitq, &wait); - spin_unlock_irqrestore(&pool->lock, flags); + /* pool_alloc_page() might sleep, so temporarily drop &pool->lock */ + spin_unlock_irqrestore(&pool->lock, flags); - schedule_timeout(POOL_TIMEOUT_JIFFIES); + page = pool_alloc_page(pool, mem_flags); + if (!page) + return NULL; - spin_lock_irqsave(&pool->lock, flags); - __remove_wait_queue(&pool->waitq, &wait); - goto restart; - } - retval = NULL; - goto done; - } + spin_lock_irqsave(&pool->lock, flags); + list_add(&page->page_list, &pool->page_list); ready: page->in_use++; offset = page->offset; @@ -348,7 +336,6 @@ void *dma_pool_alloc(struct dma_pool *pool, gfp_t mem_flags, #ifdef DMAPOOL_DEBUG memset(retval, POOL_POISON_ALLOCATED, pool->size); #endif - done: spin_unlock_irqrestore(&pool->lock, flags); return retval; } -- 1.7.9.5

12 years, 7 months

9
63
0 0

[RFC/PATCH 0/5] Contiguous Memory Allocator and get_user_pages()

by Marek Szyprowski

Hello, Contiguous Memory Allocator is very sensitive about migration failures of the individual pages. A single page, which causes permanent migration failure can break large conitguous allocations and cause the failure of a multimedia device driver. One of the known issues with migration of CMA pages are the problems of migrating the anonymous user pages, for which the others called get_user_pages(). This takes a reference to the given user pages to let kernel to operate directly on the page content. This is usually used for preventing swaping out the page contents and doing direct DMA to/from userspace. To solving this issue requires preventing locking of the pages, which are placed in CMA regions, for a long time. Our idea is to migrate anonymous page content before locking the page in get_user_pages(). This cannot be done automatically, as get_user_pages() interface is used very often for various operations, which usually last for a short period of time (like for example exec syscall). We have added a new flag indicating that the given get_user_space() call will grab pages for a long time, thus it is suitable to use the migration workaround in such cases. The proposed extensions is used by V4L2/VideoBuf2 (drivers/media/v4l2-core/videobuf2-dma-contig.c), but that is not the only place which might benefit from it, like any driver which use DMA to userspace with get_user_pages(). This one is provided to demonstrate the use case. I would like to hear some comments on the presented approach. What do you think about it? Is there a chance to get such workaround merged at some point to mainline? Best regards Marek Szyprowski Samsung Poland R&D Center Patch summary: Marek Szyprowski (5): mm: introduce migrate_replace_page() for migrating page to the given target mm: get_user_pages: use static inline mm: get_user_pages: use NON-MOVABLE pages when FOLL_DURABLE flag is set mm: get_user_pages: migrate out CMA pages when FOLL_DURABLE flag is set media: vb2: use FOLL_DURABLE and __get_user_pages() to avoid CMA migration issues drivers/media/v4l2-core/videobuf2-dma-contig.c | 8 +- include/linux/highmem.h | 12 ++- include/linux/migrate.h | 5 + include/linux/mm.h | 76 ++++++++++++- mm/internal.h | 12 +++ mm/memory.c | 136 +++++++++++------------- mm/migrate.c | 59 ++++++++++ 7 files changed, 225 insertions(+), 83 deletions(-) -- 1.7.9.5

12 years, 7 months

8
20
0 0

Re: [Linaro-mm-sig] [PATCH] drm/udl: avoid swiotlb for imported vmap buffers.

by Daniel Vetter

On Wed, May 1, 2013 at 6:30 AM, Dave Airlie <airlied(a)gmail.com> wrote: > Since we ask the dmabuf owner to map the dma-buf into our device > address space, but for udl at present that is the CPU address space, > since we don't DMA directly from the mapped buffer. > > However if we don't set a dma mask on the usb device, the mapping > ends up using swiotlb on machines that have it enabled, which > is less than desireable. > > Signed-off-by: Dave Airlie <airlied(a)redhat.com> Fyi for everyone else who was not on irc when Dave&I discussed this: This really shouldn't be required and I think the real issue is that udl creates a dma_buf attachement (which is needed for device dma only), but only really wants to do cpu access through vmap/kmap. So not attached the device should be good enough. Cc'ing a few more lists for better fyi ;-) -Daniel > --- > drivers/gpu/drm/udl/udl_main.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/gpu/drm/udl/udl_main.c b/drivers/gpu/drm/udl/udl_main.c > index 0ce2d71..6770e1b 100644 > --- a/drivers/gpu/drm/udl/udl_main.c > +++ b/drivers/gpu/drm/udl/udl_main.c > @@ -293,6 +293,7 @@ int udl_driver_load(struct drm_device *dev, unsigned long flags) > udl->ddev = dev; > dev->dev_private = udl; > > + dma_set_mask(dev->dev, DMA_BIT_MASK(64)); > if (!udl_parse_vendor_descriptor(dev, dev->usbdev)) { > DRM_ERROR("firmware not recognized. Assume incompatible device\n"); > goto err; > -- > 1.8.2 > > _______________________________________________ > dri-devel mailing list > dri-devel(a)lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch

12 years, 7 months

3
6
0 0

RFC: Unified DMA allocation algorithms

by Laura Abbott

Hi all, I've been looking at a better way to do custom dma allocation algorithms in a similar style to Ion heaps. Most drivers/clients have come up with a series of semi-standard ways to get memory (CMA, memblock_reserve, discontiguous pages etc.) . As these allocation schemes get more and more complex, there needs to be a since place where all clients (Ion based driver vs. DRM driver vs. ???) can independently take advantage of any optimizations and call a single API for the backing allocations. The dma_map_ops take care of almost everything needed for abstraction but the question is where should new allocation algorithms be located? Most of the work has been added to either arm/mm/dma-mapping.c or dma-contiguous.c . My current thought: 1) split out the dma_map_ops currently in dma-mapping.c into separate files (dma-mapping-common.c, dma-mapping-iommu.c) 2) Extend dma-contiguous.c to support memblock_reserve memory 3) Place additional algorithms in either arch/arm/mm or drivers/base/dma-alloc/ as appropriate to the code. This is the part where I'm most unsure about the direction. I don't have anything written yet but I plan to draft some patches assuming the proposed approach sounds reasonable and no one else has started on something similar already. Thoughts? Opinions? Thanks, Laura -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

12 years, 7 months

3
2
0 0

[GIT PULL]: dma-buf updates for 3.10

by Sumit Semwal

Hi Linus, The 3.10 pull request for dma-buf framework updates: small one, could you please pull? Thanks and best regards, ~Sumit. The following changes since commit 5f56886521d6ddd3648777fae44d82382dd8c87f: Merge branch 'akpm' (incoming from Andrew) (2013-04-30 17:37:43 -0700) are available in the git repository at: git://git.linaro.org/people/sumitsemwal/linux-dma-buf.git tags/tag-for-linus-3.10 for you to fetch changes up to b89e35636bc75b72d15a1af6d49798802aff77d5: dma-buf: Add debugfs support (2013-05-01 16:36:22 +0530) ---------------------------------------------------------------- 3.10 dma-buf updates Added debugfs support to dma-buf. ---------------------------------------------------------------- Sumit Semwal (2): dma-buf: replace dma_buf_export() with dma_buf_export_named() dma-buf: Add debugfs support Documentation/dma-buf-sharing.txt | 13 ++- drivers/base/dma-buf.c | 169 +++++++++++++++++++++++++++++++++++++- include/linux/dma-buf.h | 16 +++- 3 files changed, 189 insertions(+), 9 deletions(-)

12 years, 7 months

1
0
0 0

[RFC/PATCH v2 0/2] Device Tree support for CMA (Contiguous Memory Allocator)

by Marek Szyprowski

Hello, This is an update for my proposal for device tree integration for Contiguous Memory Allocator. The code is quite straightforward, but expect again that the device tree bindings will trigger some discussion. Just a few words for those who see this code for the first time: The proposed bindings allows to define contiguous memory regions of specified base address and size. Then, the defined regions can be assigned to the given device(s) by adding a property with a phanle to the defined contiguous memory region. From the device tree perspective that's all. Once the bindings are added, all the memory allocations from dma-mapping subsystem will be served from the defined contiguous memory regions. Contiguous Memory Allocator is a framework, which lets to provide a large contiguous memory buffers for (usually a multimedia) devices. The contiguous memory is reserved during early boot and then shared with kernel, which is allowed to allocate it for movable pages. Then, when device driver requests a contigouous buffer, the framework migrates movable pages out of contiguous region and gives it to the driver. When device driver frees the buffer, it is added to kernel memory pool again. For more information, please refer to commit c64be2bb1c6eb43c838b2c6d57 ("drivers: add Contiguous Memory Allocator") and d484864dd96e1830e76895 (CMA merge commit). Why we need device tree bindings for CMA at all? Older ARM kernels used so called board-based initialization. Those board files contained a definition of all hardware blocks available on the target system and particular kernel and driver software configuration selected by the board maintainer. In the new approach the board files will be removed completely and Device Tree approach is used to describe all hardware blocks available on the target system. By definition, the bindings should be software independent, so at least in theory it should be possible to use those bindings with other operating systems than Linux kernel. However we also need to pass somehow the information about kernel and device driver software-only configuration data, which were earlier encoded in the board file. For such data I propose to use /chosen node, where kernel command line has been already stored. Future bootloaders will allow to modify or replace particular nodes and one will be able to use custom /chosen node to configure his system. The proposed patches introduce /chosen/contiguous-memory node and related bindings, to avoid complicated encoding of CMA related configuration to kernel command line. Best regards Marek Szyprowski Samsung Poland R&D Center Changelog: v2: - moved contiguous-memory bindings from /memory to /chosen/contiguous-memory/ node to avoid spreading Linux specific parameters over the whole device tree definitions - added support for autoconfigured regions (use zero base) - fixes minor bugs v1: http://thread.gmane.org/gmane.linux.drivers.devicetree/30111/ - initial proposal Patch summary: Marek Szyprowski (2): drivers: dma-contiguous: clean source code and prepare for device tree drivers: dma-contiguous: add initialization from device tree Documentation/devicetree/bindings/memory.txt | 101 ++++++++++ arch/arm/boot/dts/skeleton.dtsi | 7 +- drivers/base/dma-contiguous.c | 278 +++++++++++++++++++------- include/asm-generic/dma-contiguous.h | 4 +- include/linux/dma-contiguous.h | 32 ++- 5 files changed, 338 insertions(+), 84 deletions(-) create mode 100644 Documentation/devicetree/bindings/memory.txt -- 1.7.9.5

12 years, 7 months

4
7
0 0

[PATCH v2 1/3] arch: make __mutex_fastpath_lock_retval return whether fastpath succeeded or not.

by Maarten Lankhorst

This will allow me to call functions that have multiple arguments if fastpath fails. This is required to support ticket mutexes, because they need to be able to pass an extra argument to the fail function. Originally I duplicated the functions, by adding __mutex_fastpath_lock_retval_arg. This ended up being just a duplication of the existing function, so a way to test if fastpath was called ended up being better. This also cleaned up the reservation mutex patch some by being able to call an atomic_set instead of atomic_xchg, and making it easier to detect if the wrong unlock function was previously used. Signed-off-by: Maarten Lankhorst <maarten.lankhorst(a)canonical.com> --- arch/ia64/include/asm/mutex.h | 10 ++++------ arch/powerpc/include/asm/mutex.h | 10 ++++------ arch/sh/include/asm/mutex-llsc.h | 4 ++-- arch/x86/include/asm/mutex_32.h | 11 ++++------- arch/x86/include/asm/mutex_64.h | 11 ++++------- include/asm-generic/mutex-dec.h | 10 ++++------ include/asm-generic/mutex-null.h | 2 +- include/asm-generic/mutex-xchg.h | 10 ++++------ kernel/mutex.c | 32 ++++++++++++++------------------ 9 files changed, 41 insertions(+), 59 deletions(-) diff --git a/arch/ia64/include/asm/mutex.h b/arch/ia64/include/asm/mutex.h index bed73a6..f41e66d 100644 --- a/arch/ia64/include/asm/mutex.h +++ b/arch/ia64/include/asm/mutex.h @@ -29,17 +29,15 @@ __mutex_fastpath_lock(atomic_t *count, void (*fail_fn)(atomic_t *)) * __mutex_fastpath_lock_retval - try to take the lock by moving the count * from 1 to a 0 value * @count: pointer of type atomic_t - * @fail_fn: function to call if the original value was not 1 * - * Change the count from 1 to a value lower than 1, and call <fail_fn> if - * it wasn't 1 originally. This function returns 0 if the fastpath succeeds, - * or anything the slow path function returns. + * Change the count from 1 to a value lower than 1. This function returns 0 + * if the fastpath succeeds, or -1 otherwise. */ static inline int -__mutex_fastpath_lock_retval(atomic_t *count, int (*fail_fn)(atomic_t *)) +__mutex_fastpath_lock_retval(atomic_t *count) { if (unlikely(ia64_fetchadd4_acq(count, -1) != 1)) - return fail_fn(count); + return -1; return 0; } diff --git a/arch/powerpc/include/asm/mutex.h b/arch/powerpc/include/asm/mutex.h index 5399f7e..127ab23 100644 --- a/arch/powerpc/include/asm/mutex.h +++ b/arch/powerpc/include/asm/mutex.h @@ -82,17 +82,15 @@ __mutex_fastpath_lock(atomic_t *count, void (*fail_fn)(atomic_t *)) * __mutex_fastpath_lock_retval - try to take the lock by moving the count * from 1 to a 0 value * @count: pointer of type atomic_t - * @fail_fn: function to call if the original value was not 1 * - * Change the count from 1 to a value lower than 1, and call <fail_fn> if - * it wasn't 1 originally. This function returns 0 if the fastpath succeeds, - * or anything the slow path function returns. + * Change the count from 1 to a value lower than 1. This function returns 0 + * if the fastpath succeeds, or -1 otherwise. */ static inline int -__mutex_fastpath_lock_retval(atomic_t *count, int (*fail_fn)(atomic_t *)) +__mutex_fastpath_lock_retval(atomic_t *count) { if (unlikely(__mutex_dec_return_lock(count) < 0)) - return fail_fn(count); + return -1; return 0; } diff --git a/arch/sh/include/asm/mutex-llsc.h b/arch/sh/include/asm/mutex-llsc.h index 090358a..dad29b6 100644 --- a/arch/sh/include/asm/mutex-llsc.h +++ b/arch/sh/include/asm/mutex-llsc.h @@ -37,7 +37,7 @@ __mutex_fastpath_lock(atomic_t *count, void (*fail_fn)(atomic_t *)) } static inline int -__mutex_fastpath_lock_retval(atomic_t *count, int (*fail_fn)(atomic_t *)) +__mutex_fastpath_lock_retval(atomic_t *count) { int __done, __res; @@ -51,7 +51,7 @@ __mutex_fastpath_lock_retval(atomic_t *count, int (*fail_fn)(atomic_t *)) : "t"); if (unlikely(!__done || __res != 0)) - __res = fail_fn(count); + __res = -1; return __res; } diff --git a/arch/x86/include/asm/mutex_32.h b/arch/x86/include/asm/mutex_32.h index 03f90c8..b7f6b34 100644 --- a/arch/x86/include/asm/mutex_32.h +++ b/arch/x86/include/asm/mutex_32.h @@ -42,17 +42,14 @@ do { \ * __mutex_fastpath_lock_retval - try to take the lock by moving the count * from 1 to a 0 value * @count: pointer of type atomic_t - * @fail_fn: function to call if the original value was not 1 * - * Change the count from 1 to a value lower than 1, and call <fail_fn> if it - * wasn't 1 originally. This function returns 0 if the fastpath succeeds, - * or anything the slow path function returns + * Change the count from 1 to a value lower than 1. This function returns 0 + * if the fastpath succeeds, or 1 otherwise. */ -static inline int __mutex_fastpath_lock_retval(atomic_t *count, - int (*fail_fn)(atomic_t *)) +static inline int __mutex_fastpath_lock_retval(atomic_t *count) { if (unlikely(atomic_dec_return(count) < 0)) - return fail_fn(count); + return -1; else return 0; } diff --git a/arch/x86/include/asm/mutex_64.h b/arch/x86/include/asm/mutex_64.h index 68a87b0..2c543ff 100644 --- a/arch/x86/include/asm/mutex_64.h +++ b/arch/x86/include/asm/mutex_64.h @@ -37,17 +37,14 @@ do { \ * __mutex_fastpath_lock_retval - try to take the lock by moving the count * from 1 to a 0 value * @count: pointer of type atomic_t - * @fail_fn: function to call if the original value was not 1 * - * Change the count from 1 to a value lower than 1, and call <fail_fn> if - * it wasn't 1 originally. This function returns 0 if the fastpath succeeds, - * or anything the slow path function returns + * Change the count from 1 to a value lower than 1. This function returns 0 + * if the fastpath succeeds, or -1 otherwise. */ -static inline int __mutex_fastpath_lock_retval(atomic_t *count, - int (*fail_fn)(atomic_t *)) +static inline int __mutex_fastpath_lock_retval(atomic_t *count) { if (unlikely(atomic_dec_return(count) < 0)) - return fail_fn(count); + return -1; else return 0; } diff --git a/include/asm-generic/mutex-dec.h b/include/asm-generic/mutex-dec.h index f104af7..d4f9fb4 100644 --- a/include/asm-generic/mutex-dec.h +++ b/include/asm-generic/mutex-dec.h @@ -28,17 +28,15 @@ __mutex_fastpath_lock(atomic_t *count, void (*fail_fn)(atomic_t *)) * __mutex_fastpath_lock_retval - try to take the lock by moving the count * from 1 to a 0 value * @count: pointer of type atomic_t - * @fail_fn: function to call if the original value was not 1 * - * Change the count from 1 to a value lower than 1, and call <fail_fn> if - * it wasn't 1 originally. This function returns 0 if the fastpath succeeds, - * or anything the slow path function returns. + * Change the count from 1 to a value lower than 1. This function returns 0 + * if the fastpath succeeds, or -1 otherwise. */ static inline int -__mutex_fastpath_lock_retval(atomic_t *count, int (*fail_fn)(atomic_t *)) +__mutex_fastpath_lock_retval(atomic_t *count) { if (unlikely(atomic_dec_return(count) < 0)) - return fail_fn(count); + return -1; return 0; } diff --git a/include/asm-generic/mutex-null.h b/include/asm-generic/mutex-null.h index e1bbbc7..efd6206 100644 --- a/include/asm-generic/mutex-null.h +++ b/include/asm-generic/mutex-null.h @@ -11,7 +11,7 @@ #define _ASM_GENERIC_MUTEX_NULL_H #define __mutex_fastpath_lock(count, fail_fn) fail_fn(count) -#define __mutex_fastpath_lock_retval(count, fail_fn) fail_fn(count) +#define __mutex_fastpath_lock_retval(count, fail_fn) (-1) #define __mutex_fastpath_unlock(count, fail_fn) fail_fn(count) #define __mutex_fastpath_trylock(count, fail_fn) fail_fn(count) #define __mutex_slowpath_needs_to_unlock() 1 diff --git a/include/asm-generic/mutex-xchg.h b/include/asm-generic/mutex-xchg.h index c04e0db..f169ec0 100644 --- a/include/asm-generic/mutex-xchg.h +++ b/include/asm-generic/mutex-xchg.h @@ -39,18 +39,16 @@ __mutex_fastpath_lock(atomic_t *count, void (*fail_fn)(atomic_t *)) * __mutex_fastpath_lock_retval - try to take the lock by moving the count * from 1 to a 0 value * @count: pointer of type atomic_t - * @fail_fn: function to call if the original value was not 1 * - * Change the count from 1 to a value lower than 1, and call <fail_fn> if it - * wasn't 1 originally. This function returns 0 if the fastpath succeeds, - * or anything the slow path function returns + * Change the count from 1 to a value lower than 1. This function returns 0 + * if the fastpath succeeds, or -1 otherwise. */ static inline int -__mutex_fastpath_lock_retval(atomic_t *count, int (*fail_fn)(atomic_t *)) +__mutex_fastpath_lock_retval(atomic_t *count) { if (unlikely(atomic_xchg(count, 0) != 1)) if (likely(atomic_xchg(count, -1) != 1)) - return fail_fn(count); + return -1; return 0; } diff --git a/kernel/mutex.c b/kernel/mutex.c index 52f2301..84a5f07 100644 --- a/kernel/mutex.c +++ b/kernel/mutex.c @@ -351,10 +351,10 @@ __mutex_unlock_slowpath(atomic_t *lock_count) * mutex_lock_interruptible() and mutex_trylock(). */ static noinline int __sched -__mutex_lock_killable_slowpath(atomic_t *lock_count); +__mutex_lock_killable_slowpath(struct mutex *lock); static noinline int __sched -__mutex_lock_interruptible_slowpath(atomic_t *lock_count); +__mutex_lock_interruptible_slowpath(struct mutex *lock); /** * mutex_lock_interruptible - acquire the mutex, interruptible @@ -372,12 +372,12 @@ int __sched mutex_lock_interruptible(struct mutex *lock) int ret; might_sleep(); - ret = __mutex_fastpath_lock_retval - (&lock->count, __mutex_lock_interruptible_slowpath); - if (!ret) + ret = __mutex_fastpath_lock_retval(&lock->count); + if (likely(!ret)) { mutex_set_owner(lock); - - return ret; + return 0; + } else + return __mutex_lock_interruptible_slowpath(lock); } EXPORT_SYMBOL(mutex_lock_interruptible); @@ -387,12 +387,12 @@ int __sched mutex_lock_killable(struct mutex *lock) int ret; might_sleep(); - ret = __mutex_fastpath_lock_retval - (&lock->count, __mutex_lock_killable_slowpath); - if (!ret) + ret = __mutex_fastpath_lock_retval(&lock->count); + if (likely(!ret)) { mutex_set_owner(lock); - - return ret; + return 0; + } else + return __mutex_lock_killable_slowpath(lock); } EXPORT_SYMBOL(mutex_lock_killable); @@ -405,18 +405,14 @@ __mutex_lock_slowpath(atomic_t *lock_count) } static noinline int __sched -__mutex_lock_killable_slowpath(atomic_t *lock_count) +__mutex_lock_killable_slowpath(struct mutex *lock) { - struct mutex *lock = container_of(lock_count, struct mutex, count); - return __mutex_lock_common(lock, TASK_KILLABLE, 0, NULL, _RET_IP_); } static noinline int __sched -__mutex_lock_interruptible_slowpath(atomic_t *lock_count) +__mutex_lock_interruptible_slowpath(struct mutex *lock) { - struct mutex *lock = container_of(lock_count, struct mutex, count); - return __mutex_lock_common(lock, TASK_INTERRUPTIBLE, 0, NULL, _RET_IP_); } #endif

12 years, 8 months

8
37
0 0

[patch 1/2 -next] dma-buf: double unlock in debugfs code

by Dan Carpenter

We unlock here when we failed to take the lock. Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com> --- This is in linux-next, and I think the debugfs code is only in Sumit's tree. diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c index 466476f..174cd2c 100644 --- a/drivers/base/dma-buf.c +++ b/drivers/base/dma-buf.c @@ -593,7 +593,7 @@ static int dma_buf_describe(struct seq_file *s) if (ret) { seq_printf(s, "\tERROR locking buffer object: skipping\n"); - goto skip_buffer; + continue; } seq_printf(s, "\t"); @@ -618,7 +618,6 @@ static int dma_buf_describe(struct seq_file *s) count++; size += buf_obj->size; -skip_buffer: mutex_unlock(&buf_obj->lock); }

12 years, 8 months

3
4
0 0

Re: [Linaro-mm-sig] Status of exporting an fbdev framebuffer with dma_buf?

by Laurent Pinchart

Hi Tom, On Tuesday 09 April 2013 12:21:08 Tom Cooksey wrote: > Hi All, > > Last year Laurent posted an RFC patch[i] to add support for exporting an > fbdev framebuffer through dma_buf. Looking through the mailing list > archives, it doesn't appear to have progressed beyond an RFC? What would be > needed to get this merged? It would be useful for our Mali T6xx driver > (which supports importing dma_buf buffers) to allow the GPU to draw > directly into the framebuffer on platforms which lack a DRM/KMS driver. The patch was pretty simple, I don't think it would take lots of efforts to get it to mainline. On the other hand, fbdev is a dying API, so I'm not sure how much energy we want to spend on upgrading it. I suppose all that would be needed is a developer with enough interest in the topic to fix the patch according to the comments. > [i] Subject: "[RFC/PATCH] fb: Add dma-buf support", sent 20/06/2012. -- Regards, Laurent Pinchart

12 years, 8 months

1
0
0 0

Status of exporting an fbdev framebuffer with dma_buf?

by Tom Cooksey

Hi All, Last year Laurent posted an RFC patch[i] to add support for exporting an fbdev framebuffer through dma_buf. Looking through the mailing list archives, it doesn't appear to have progressed beyond an RFC? What would be needed to get this merged? It would be useful for our Mali T6xx driver (which supports importing dma_buf buffers) to allow the GPU to draw directly into the framebuffer on platforms which lack a DRM/KMS driver. [i] Subject: "[RFC/PATCH] fb: Add dma-buf support", sent 20/06/2012. Cheers, Tom

12 years, 8 months

1
0
0 0

[PATCH v3 0/2] dma-buf: Add support for debugfs

by Sumit Semwal

The patch series adds a much-missed support for debugfs to dma-buf framework. Based on the feedback received on v1 of this patch series, support is also added to allow exporters to provide name-strings that will prove useful while debugging. Some more magic can be added for more advanced debugging, but we'll leave that for the time being. Best regards, ~Sumit. --- changes since v2: (based on review comments from Laurent Pinchart) - reordered functions to avoid forward declaration - added __exitcall for dma_buf_deinit() changes since v1: - added patch to replace dma_buf_export() with dma_buf_export_named(), per suggestion from Daniel Vetter. - fixes on init and warnings as reported and corrected by Dave Airlie. - added locking while walking attachment list - reported by Daniel Vetter. Sumit Semwal (2): dma-buf: replace dma_buf_export() with dma_buf_export_named() dma-buf: Add debugfs support Documentation/dma-buf-sharing.txt | 13 ++- drivers/base/dma-buf.c | 170 ++++++++++++++++++++++++++++++++++++- include/linux/dma-buf.h | 16 +++- 3 files changed, 190 insertions(+), 9 deletions(-) -- 1.7.10.4

12 years, 8 months

1
3
0 0

[PATCH v2 0/2] dma-buf: Add support for debugfs

by Sumit Semwal

The patch series adds a much-missed support for debugfs to dma-buf framework. Based on the feedback received on v1 of this patch series, support is also added to allow exporters to provide name-strings that will prove useful while debugging. Some more magic can be added for more advanced debugging, but we'll leave that for the time being. Best regards, ~Sumit. Sumit Semwal (2): dma-buf: replace dma_buf_export() with dma_buf_export_named() dma-buf: Add debugfs support Documentation/dma-buf-sharing.txt | 13 ++- drivers/base/dma-buf.c | 173 ++++++++++++++++++++++++++++++++++++- include/linux/dma-buf.h | 16 +++- 3 files changed, 193 insertions(+), 9 deletions(-) -- 1.7.10.4

12 years, 8 months

3
5
0 0

[PATCH v10 0/2] Add CMA heap for ION memory manager

by Benjamin Gaignard

The goal of those patches is to allow ION clients (drivers or userland applications) to use Contiguous Memory Allocator (CMA). To get more info about CMA: http://lists.linaro.org/pipermail/linaro-mm-sig/2012-February/001328.html patches version 10: - stop adding private field in ion_heap structure - put ion_heap into struct ion_cma_heap patches version 9: - rebased on Android kernel - make cma heap able to support ION_FLAG_CACHED flag patches version 8: - fix memory leak when release sg_table - remove virt_to_phys from ion_cma_phys patches version 7: - rebased on Android kernel - fix ion Makefile - add ion_cma_map_kernel function - remove CONFIG_CMA compilation flags from ion_heap.c patches version 6: - add private field in ion_platform_heap to pass the device linked with CMA. - rework CMA heap to use private field. - prepare CMA heap for incoming dma_common_get_sgtable function http://lists.linaro.org/pipermail/linaro-mm-sig/2012-June/002109.html - simplify ion-ux500 driver. patches version 5: - port patches on android kernel 3.4 where ION use dmabuf - add ion_cma_heap_map_dma and ion_cma_heap_unmap_dma functions patches version 4: - add ION_HEAP_TYPE_DMA heap type in ion_heap_type enum. - CMA heap is now a "native" ION heap. - add ion_heap_create_full function to keep backward compatibilty. - clean up included files in CMA heap - ux500-ion is using ion_heap_create_full instead of ion_heap_create patches version 3: - add a private field in ion_heap structure instead of expose ion_device structure to all heaps - ion_cma_heap is no more a platform driver - ion_cma_heap use ion_heap private field to store the device pointer and make the link with reserved CMA regions - provide ux500-ion driver and configuration file for snowball board to give an example of how use CMA heaps patches version 2: - fix comments done by Andy Green Benjamin Gaignard (2): gpu: ion: fix ion_platform_data definition gpu: ion: add CMA heap drivers/gpu/ion/Makefile | 1 + drivers/gpu/ion/ion_cma_heap.c | 234 ++++++++++++++++++++++++++++++++++++++++ drivers/gpu/ion/ion_heap.c | 6 ++ drivers/gpu/ion/ion_priv.h | 14 +++ include/linux/ion.h | 5 +- 5 files changed, 259 insertions(+), 1 deletion(-) create mode 100644 drivers/gpu/ion/ion_cma_heap.c -- 1.7.10

12 years, 8 months

1
2
0 0

[PATCH v9 0/3] Add CMA heap for ION memory manager

by Benjamin Gaignard

The goal of those patches is to allow ION clients (drivers or userland applications) to use Contiguous Memory Allocator (CMA). To get more info about CMA: http://lists.linaro.org/pipermail/linaro-mm-sig/2012-February/001328.html patches version 9: - rebased on Android kernel - make cma heap able to support ION_FLAG_CACHED flag patches version 8: - fix memory leak when release sg_table - remove virt_to_phys from ion_cma_phys patches version 7: - rebased on Android kernel - fix ion Makefile - add ion_cma_map_kernel function - remove CONFIG_CMA compilation flags from ion_heap.c patches version 6: - add private field in ion_platform_heap to pass the device linked with CMA. - rework CMA heap to use private field. - prepare CMA heap for incoming dma_common_get_sgtable function http://lists.linaro.org/pipermail/linaro-mm-sig/2012-June/002109.html - simplify ion-ux500 driver. patches version 5: - port patches on android kernel 3.4 where ION use dmabuf - add ion_cma_heap_map_dma and ion_cma_heap_unmap_dma functions patches version 4: - add ION_HEAP_TYPE_DMA heap type in ion_heap_type enum. - CMA heap is now a "native" ION heap. - add ion_heap_create_full function to keep backward compatibilty. - clean up included files in CMA heap - ux500-ion is using ion_heap_create_full instead of ion_heap_create patches version 3: - add a private field in ion_heap structure instead of expose ion_device structure to all heaps - ion_cma_heap is no more a platform driver - ion_cma_heap use ion_heap private field to store the device pointer and make the link with reserved CMA regions - provide ux500-ion driver and configuration file for snowball board to give an example of how use CMA heaps patches version 2: - fix comments done by Andy Green Benjamin Gaignard (3): gpu: ion: fix ion_platform_data definition gpu: ion: add private field in ion_heap and ion_platform_heap structure gpu: ion: add CMA heap drivers/gpu/ion/Makefile | 1 + drivers/gpu/ion/ion_cma_heap.c | 221 ++++++++++++++++++++++++++++++++++++++++ drivers/gpu/ion/ion_heap.c | 7 ++ drivers/gpu/ion/ion_priv.h | 16 +++ include/linux/ion.h | 5 +- 5 files changed, 249 insertions(+), 1 deletion(-) create mode 100644 drivers/gpu/ion/ion_cma_heap.c -- 1.7.10

12 years, 8 months

3
5
0 0

[PATCH 0/2] Device Tree support for CMA (Contiguous Memory Allocator)

by Marek Szyprowski

Hello, Here is my initial proposal for device tree integration for Contiguous Memory Allocator. The code is quite straightforward, however I expect that the memory bindings require some discussion. The proposed bindings allows to define contiguous memory regions of specified base address and size. Then, the defined regions can be assigned to the given device(s) by adding a property with a phanle to the defined contiguous memory region. From the device tree perspective that's all. Once the bindings are added, all the memory allocations from dma-mapping subsystem will be served from the defined contiguous memory regions. Contiguous Memory Allocator is a framework, which lets to provide a large contiguous memory buffers for (usually a multimedia) devices. The contiguous memory is reserved during early boot and then shared with kernel, which is allowed to allocate it for movable pages. Then, when device driver requests a contigouous buffer, the framework migrates movable pages out of contiguous region and gives it to the driver. When device driver frees the buffer, it is added to kernel memory pool again. For more information, please refer to commit c64be2bb1c6eb43c838b2c6d57 ("drivers: add Contiguous Memory Allocator") and d484864dd96e1830e76895 (CMA merge commit). Best regards Marek Szyprowski Samsung Poland R&D Center Patch summary: Marek Szyprowski (2): drivers: dma-contiguous: clean source code and prepare for device tree drivers: dma-contiguous: add initialization from device tree Documentation/devicetree/bindings/memory.txt | 101 ++++++++++ arch/arm/boot/dts/skeleton.dtsi | 7 +- drivers/base/dma-contiguous.c | 278 +++++++++++++++++++------- include/asm-generic/dma-contiguous.h | 4 +- include/linux/dma-contiguous.h | 32 ++- 5 files changed, 338 insertions(+), 84 deletions(-) create mode 100644 Documentation/devicetree/bindings/memory.txt -- 1.7.9.5

12 years, 9 months

7
17
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig