Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

18 participants
2944 discussions

[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

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

[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, 1 month

[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, 1 month

[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, 1 month

[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, 1 month

[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, 1 month

[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, 2 months

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, 2 months

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, 2 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig