Linaro-mm-sig October 2012

linaro-mm-sig@lists.linaro.org

27 participants
14 discussions

[RFC 0/5] ARM: dma-mapping: New dma_map_ops to control IOVA more precisely

by Hiroshi Doyu

Hi, The following APIs are needed for us to support the legacy Tegra memory manager for devices("NvMap") with *DMA mapping API*. New API: ->iova_alloc(): To allocate IOVA area. ->iova_alloc_at(): To allocate IOVA area at specific address. ->iova_free(): To free IOVA area. ->map_page_at(): To map page at specific IOVA. misc: ->iova_get_free_total(): To return how much IOVA is available totally. ->iova_get_free_max(): To return the size of biggest IOVA area. Although NvMap itself will be replaced soon, there are cases for the above API where we need to specify IOVA explicitly. (1) HWAs may require the address for special purpose, like reset vector. (2) IOVA linear mapping: ex: [RFC 5/5] ARM: dma-mapping: Introduce dma_map_linear_attrs() for IOVA linear map (3) To support different heaps. To have allocation and mapping independently. Some of them could be supported with creating different mappings, but currently a device can have a single contiguous mapping, and we cannot specifiy any address inside of a map since all IOVA alloction is done implicitly now. This is the revised version of: http://lists.linaro.org/pipermail/linaro-mm-sig/2012-May/001947.html http://lists.linaro.org/pipermail/linaro-mm-sig/2012-May/001948.html http://lists.linaro.org/pipermail/linaro-mm-sig/2012-May/001949.html Any comment would be really appreciated. Hiroshi Doyu (5): ARM: dma-mapping: New dma_map_ops->iova_get_free_{total,max} functions ARM: dma-mapping: New dma_map_ops->iova_{alloc,free}() functions ARM: dma-mapping: New dma_map_ops->iova_alloc*_at* function ARM: dma-mapping: New dma_map_ops->map_page*_at* function ARM: dma-mapping: Introduce dma_map_linear_attrs() for IOVA linear map arch/arm/include/asm/dma-mapping.h | 55 +++++++++++++ arch/arm/mm/dma-mapping.c | 124 ++++++++++++++++++++++++++++++ include/asm-generic/dma-mapping-common.h | 20 +++++ include/linux/dma-mapping.h | 14 ++++ 4 files changed, 213 insertions(+), 0 deletions(-) -- 1.7.5.4

12 years

[PATCHv10 00/26] Integration of videobuf2 with DMABUF

by Tomasz Stanislawski

Hello everyone, This patchset adds support for DMABUF [2] importing and exporting to V4L2 stack. v10: - rebase on media-next 3.7 - typos and style fixes in Documentation (from Hans Verkuil) - fix compilation error with __fill_vb2_buffer - fix uninitialized data_offset for single-planar queue - support for DMABUF importing in S5P-FIMC mem-to-mem interface - update layout of v4l2_exportbuffer structure - update ioctl flags in v4l2_ioctls for VIDIOC_EXPBUF - support for DMABUF exporting in m2m framework - allow exporting for file handles that calle REQBUBS/CREATE_BUF - simplify handling of get_device in vb2_dc_alloc - reduce pr_err to pr_debug while checking alignment of userptr - check size of userptr buffer against zero - align size to PAGE_SIZE at allocation of dma-contig buffer v9: - rebase on 3.6 - change type for fs to __s32 - add support for vb2_ioctl_expbuf - remove patch 'v4l: vb2: add support for DMA_ATTR_NO_KERNEL_MAPPING', it will be posted as a separate patch - fix typos and style in Documentation (from Hans Verkuil) - only vb2-core and vb2-dma-contig selects DMA_SHARED_BUFFER in Kconfig - use data_offset and length while queueing DMABUF - return the most recently used fd at VIDIOC_DQBUF - use (buffer-type, index, plane) tuple instead of mem_offset to identify a for exporting (from Hans Verkuil) - support for DMABUF mmap in vb2-dma-contig (from Laurent Pinchart) - add testing alignment of vaddr and size while verifying userptr against DMA capabilities (from Laurent Pinchart) - substitute VM_DONTDUMP with VM_RESERVED - simplify error handling in vb2_dc_get_dmabuf (from Laurent Pinchart) v8: - rebased on 3.6-rc1 - merged importer and exporter patchsets - fixed missing fields in v4l2_plane32 and v4l2_buffer32 structs - fixed typos/style in documentation - significant reduction of warnings from checkpatch.pl - fixed STREAMOFF issues reported by Dima Zavin [4] by adding __vb2_dqbuf helper to vb2-core - DC fails if userptr is not correctly aligned - add support for DMA attributes in DC - add support for buffers with no kernel mapping - add reference counting on device from allocator context - dummy support for mmap - use dma_get_sgtable, drop vb2_dc_kaddr_to_pages hack and vb2_dc_get_base_sgt helper v7: - support for V4L2_MEMORY_DMABUF in v4l2-compact-ioctl32.c - cosmetic fixes to the documentation - added importing for vmalloc because vmap support in dmabuf for 3.5 was pull-requested - support for dmabuf importing for VIVI - resurrect allocation of dma-contig context - remove reference of alloc_ctx in dma-contig buffer - use sg_alloc_table_from_pages - fix DMA scatterlist calls to use orig_nents instead of nents - fix memleak in vb2_dc_sgt_foreach_page (use orig_nents instead of nents) v6: - fixed missing entry in v4l2_memory_names - fixed a bug occuring after get_user_pages failure - fixed a bug caused by using invalid vma for get_user_pages - prepare/finish no longer call dma_sync for dmabuf buffers v5: - removed change of importer/exporter behaviour - fixes vb2_dc_pages_to_sgt basing on Laurent's hints - changed pin/unpin words to lock/unlock in Doc v4: - rebased on mainline 3.4-rc2 - included missing importing support for s5p-fimc and s5p-tv - added patch for changing map/unmap for importers - fixes to Documentation part - coding style fixes - pairing {map/unmap}_dmabuf in vb2-core - fixing variable types and semantic of arguments in videobufb2-dma-contig.c v3: - rebased on mainline 3.4-rc1 - split 'code refactor' patch to multiple smaller patches - squashed fixes to Sumit's patches - patchset is no longer dependant on 'DMA mapping redesign' - separated path for handling IO and non-IO mappings - add documentation for DMABUF importing to V4L - removed all DMABUF exporter related code - removed usage of dma_get_pages extension v2: - extended VIDIOC_EXPBUF argument from integer memoffset to struct v4l2_exportbuffer - added patch that breaks DMABUF spec on (un)map_atachment callcacks but allows to work with existing implementation of DMABUF prime in DRM - all dma-contig code refactoring patches were squashed - bugfixes v1: List of changes since [1]. - support for DMA api extension dma_get_pages, the function is used to retrieve pages used to create DMA mapping. - small fixes/code cleanup to videobuf2 - added prepare and finish callbacks to vb2 allocators, it is used keep consistency between dma-cpu acess to the memory (by Marek Szyprowski) - support for exporting of DMABUF buffer in V4L2 and Videobuf2, originated from [3]. - support for dma-buf exporting in vb2-dma-contig allocator - support for DMABUF for s5p-tv and s5p-fimc (capture interface) drivers, originated from [3] - changed handling for userptr buffers (by Marek Szyprowski, Andrzej Pietrasiewicz) - let mmap method to use dma_mmap_writecombine call (by Marek Szyprowski) [1] http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/4296… [2] https://lkml.org/lkml/2011/12/26/29 [3] http://thread.gmane.org/gmane.linux.kernel.cross-arch/12819 [4] http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/497… Laurent Pinchart (2): v4l: vb2-dma-contig: shorten vb2_dma_contig prefix to vb2_dc v4l: vb2-dma-contig: reorder functions Marek Szyprowski (4): v4l: vb2: add prepare/finish callbacks to allocators v4l: vb2-dma-contig: add prepare/finish to dma-contig allocator v4l: vb2-dma-contig: let mmap method to use dma_mmap_coherent call v4l: vb2-dma-contig: fail if user ptr buffer is not correctly aligned Sumit Semwal (4): v4l: Add DMABUF as a memory type v4l: vb2: add support for shared buffer (dma_buf) v4l: vb: remove warnings about MEMORY_DMABUF v4l: vb2-dma-contig: add support for dma_buf importing Tomasz Stanislawski (16): Documentation: media: description of DMABUF importing in V4L2 v4l: vb2-dma-contig: remove reference of alloc_ctx from a buffer v4l: vb2-dma-contig: add support for scatterlist in userptr mode v4l: vb2-vmalloc: add support for dmabuf importing v4l: vivi: support for dmabuf importing v4l: s5p-tv: mixer: support for dmabuf importing v4l: s5p-fimc: support for dmabuf importing Documentation: media: description of DMABUF exporting in V4L2 v4l: add buffer exporting via dmabuf v4l: vb2: add buffer exporting via dmabuf v4l: vb2-dma-contig: add support for DMABUF exporting v4l: vb2-dma-contig: add reference counting for a device from allocator context v4l: vb2-dma-contig: align buffer size to PAGE_SIZE v4l: s5p-fimc: support for dmabuf exporting v4l: s5p-tv: mixer: support for dmabuf exporting v4l: s5p-mfc: support for dmabuf exporting Documentation/DocBook/media/v4l/compat.xml | 7 + Documentation/DocBook/media/v4l/io.xml | 184 ++++- Documentation/DocBook/media/v4l/v4l2.xml | 1 + .../DocBook/media/v4l/vidioc-create-bufs.xml | 16 +- Documentation/DocBook/media/v4l/vidioc-expbuf.xml | 212 ++++++ Documentation/DocBook/media/v4l/vidioc-qbuf.xml | 17 + Documentation/DocBook/media/v4l/vidioc-reqbufs.xml | 47 +- drivers/media/platform/s5p-fimc/fimc-capture.c | 11 +- drivers/media/platform/s5p-fimc/fimc-m2m.c | 14 +- drivers/media/platform/s5p-mfc/s5p_mfc_dec.c | 14 + drivers/media/platform/s5p-mfc/s5p_mfc_enc.c | 14 + drivers/media/platform/s5p-tv/mixer_video.c | 12 +- drivers/media/platform/vivi.c | 2 +- drivers/media/v4l2-core/Kconfig | 3 + drivers/media/v4l2-core/v4l2-compat-ioctl32.c | 19 + drivers/media/v4l2-core/v4l2-dev.c | 1 + drivers/media/v4l2-core/v4l2-ioctl.c | 11 + drivers/media/v4l2-core/v4l2-mem2mem.c | 13 + drivers/media/v4l2-core/videobuf-core.c | 4 + drivers/media/v4l2-core/videobuf2-core.c | 300 ++++++++- drivers/media/v4l2-core/videobuf2-dma-contig.c | 702 ++++++++++++++++++-- drivers/media/v4l2-core/videobuf2-memops.c | 40 -- drivers/media/v4l2-core/videobuf2-vmalloc.c | 56 ++ include/linux/videodev2.h | 35 + include/media/v4l2-ioctl.h | 2 + include/media/v4l2-mem2mem.h | 3 + include/media/videobuf2-core.h | 38 ++ include/media/videobuf2-memops.h | 5 - 28 files changed, 1645 insertions(+), 138 deletions(-) create mode 100644 Documentation/DocBook/media/v4l/vidioc-expbuf.xml -- 1.7.9.5

12 years, 1 month

[RFC] Using CMA with devicetree generated devices

by Laura Abbott

Is it possible to use the devices generated from device tree for use with CMA? The API for reserving a CMA region (dma_declare_contiguous) requires a device pointer to properly associate a region with a device. By the time the devices from devicetree are actually available (generally during machine_init), dma_contiguous_remap has already been called so it's too late to have a properly setup region. I currently see several options: 1) All CMA devices must be statically declared in the board file 2) Scan the FDT to set up 'dummy' devices early which can later be used to set up CMA with the 'proper' devices 3) My assumption is completely wrong and the check that I was using is invalid: diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c index 8404601..6d37516 100644 --- a/arch/arm/mm/dma-mapping.c +++ b/arch/arm/mm/dma-mapping.c @@ -368,9 +368,11 @@ struct dma_contig_early_reserve { static struct dma_contig_early_reserve dma_mmu_remap[MAX_CMA_AREAS] __initdata; static int dma_mmu_remap_num __initdata; +static int is_remapped; void __init dma_contiguous_early_fixup(phys_addr_t base, unsigned long size) { + BUG_ON(is_remapped); dma_mmu_remap[dma_mmu_remap_num].base = base; dma_mmu_remap[dma_mmu_remap_num].size = size; dma_mmu_remap_num++; @@ -404,6 +406,7 @@ void __init dma_contiguous_remap(void) iotable_init(&map, 1); } + is_remapped = 1; } static void * I'm currently leaning towards setting up #2 unless I'm missing something obvious here. Thanks. Laura -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

12 years, 1 month

[GIT PULL] Urgent DMA-mapping fix for v3.7-rc3

by Marek Szyprowski

Hi Linus, I would like to ask for pulling an urgent fix for ARM DMA-mapping framework for v3.7-rc3. Due to my mistake, my previous pull request (merged as cff7b8ba60e332377568c3d55c8036e9b1de32e6) contained a patch which is aimed for v3.8 and lacks its dependences. This pull request reverts it and fixes build break of ARM architecture. Thanks! Best regards Marek Szyprowski Samsung Poland R&D Center ---------------------------------------------------------------- The following changes since commit 2ab3f29dddfb444c9fcc0a2f3a56ed4bdba41969: Merge branch 'akpm' (Andrew's fixes) (2012-10-25 16:05:57 -0700) are available in the git repository at: git://git.linaro.org/people/mszyprowski/linux-dma-mapping.git fixes_for_linus for you to fetch changes up to 697575896670ba9e76760ce8bbc1f5a3001967d6: Revert "ARM: dma-mapping: support debug_dma_mapping_error" (2012-10-26 07:39:13 +0200) ---------------------------------------------------------------- Marek Szyprowski (1): Revert "ARM: dma-mapping: support debug_dma_mapping_error" arch/arm/include/asm/dma-mapping.h | 1 - 1 file changed, 1 deletion(-)

12 years, 1 month

[PATCH] dma-buf: Use EXPORT_SYMBOL

by Robert Morell

EXPORT_SYMBOL_GPL is intended to be used for "an internal implementation issue, and not really an interface". The dma-buf infrastructure is explicitly intended as an interface between modules/drivers, so it should use EXPORT_SYMBOL instead. Signed-off-by: Robert Morell <rmorell(a)nvidia.com> --- This patch is based on Linus's master branch. We held a discussion at ELC, and agreed that EXPORT_SYMBOL is more appropriate for this interface than EXPORT_SYMBOL_GPL. drivers/base/dma-buf.c | 34 +++++++++++++++++----------------- 1 files changed, 17 insertions(+), 17 deletions(-) diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c index 460e22d..24c28be 100644 --- a/drivers/base/dma-buf.c +++ b/drivers/base/dma-buf.c @@ -122,7 +122,7 @@ struct dma_buf *dma_buf_export(void *priv, const struct dma_buf_ops *ops, return dmabuf; } -EXPORT_SYMBOL_GPL(dma_buf_export); +EXPORT_SYMBOL(dma_buf_export); /** @@ -148,7 +148,7 @@ int dma_buf_fd(struct dma_buf *dmabuf, int flags) return fd; } -EXPORT_SYMBOL_GPL(dma_buf_fd); +EXPORT_SYMBOL(dma_buf_fd); /** * dma_buf_get - returns the dma_buf structure related to an fd @@ -174,7 +174,7 @@ struct dma_buf *dma_buf_get(int fd) return file->private_data; } -EXPORT_SYMBOL_GPL(dma_buf_get); +EXPORT_SYMBOL(dma_buf_get); /** * dma_buf_put - decreases refcount of the buffer @@ -189,7 +189,7 @@ void dma_buf_put(struct dma_buf *dmabuf) fput(dmabuf->file); } -EXPORT_SYMBOL_GPL(dma_buf_put); +EXPORT_SYMBOL(dma_buf_put); /** * dma_buf_attach - Add the device to dma_buf's attachments list; optionally, @@ -234,7 +234,7 @@ err_attach: mutex_unlock(&dmabuf->lock); return ERR_PTR(ret); } -EXPORT_SYMBOL_GPL(dma_buf_attach); +EXPORT_SYMBOL(dma_buf_attach); /** * dma_buf_detach - Remove the given attachment from dmabuf's attachments list; @@ -256,7 +256,7 @@ void dma_buf_detach(struct dma_buf *dmabuf, struct dma_buf_attachment *attach) mutex_unlock(&dmabuf->lock); kfree(attach); } -EXPORT_SYMBOL_GPL(dma_buf_detach); +EXPORT_SYMBOL(dma_buf_detach); /** * dma_buf_map_attachment - Returns the scatterlist table of the attachment; @@ -283,7 +283,7 @@ struct sg_table *dma_buf_map_attachment(struct dma_buf_attachment *attach, return sg_table; } -EXPORT_SYMBOL_GPL(dma_buf_map_attachment); +EXPORT_SYMBOL(dma_buf_map_attachment); /** * dma_buf_unmap_attachment - unmaps and decreases usecount of the buffer;might @@ -304,7 +304,7 @@ void dma_buf_unmap_attachment(struct dma_buf_attachment *attach, attach->dmabuf->ops->unmap_dma_buf(attach, sg_table, direction); } -EXPORT_SYMBOL_GPL(dma_buf_unmap_attachment); +EXPORT_SYMBOL(dma_buf_unmap_attachment); /** @@ -332,7 +332,7 @@ int dma_buf_begin_cpu_access(struct dma_buf *dmabuf, size_t start, size_t len, return ret; } -EXPORT_SYMBOL_GPL(dma_buf_begin_cpu_access); +EXPORT_SYMBOL(dma_buf_begin_cpu_access); /** * dma_buf_end_cpu_access - Must be called after accessing a dma_buf from the @@ -354,7 +354,7 @@ void dma_buf_end_cpu_access(struct dma_buf *dmabuf, size_t start, size_t len, if (dmabuf->ops->end_cpu_access) dmabuf->ops->end_cpu_access(dmabuf, start, len, direction); } -EXPORT_SYMBOL_GPL(dma_buf_end_cpu_access); +EXPORT_SYMBOL(dma_buf_end_cpu_access); /** * dma_buf_kmap_atomic - Map a page of the buffer object into kernel address @@ -371,7 +371,7 @@ void *dma_buf_kmap_atomic(struct dma_buf *dmabuf, unsigned long page_num) return dmabuf->ops->kmap_atomic(dmabuf, page_num); } -EXPORT_SYMBOL_GPL(dma_buf_kmap_atomic); +EXPORT_SYMBOL(dma_buf_kmap_atomic); /** * dma_buf_kunmap_atomic - Unmap a page obtained by dma_buf_kmap_atomic. @@ -389,7 +389,7 @@ void dma_buf_kunmap_atomic(struct dma_buf *dmabuf, unsigned long page_num, if (dmabuf->ops->kunmap_atomic) dmabuf->ops->kunmap_atomic(dmabuf, page_num, vaddr); } -EXPORT_SYMBOL_GPL(dma_buf_kunmap_atomic); +EXPORT_SYMBOL(dma_buf_kunmap_atomic); /** * dma_buf_kmap - Map a page of the buffer object into kernel address space. The @@ -406,7 +406,7 @@ void *dma_buf_kmap(struct dma_buf *dmabuf, unsigned long page_num) return dmabuf->ops->kmap(dmabuf, page_num); } -EXPORT_SYMBOL_GPL(dma_buf_kmap); +EXPORT_SYMBOL(dma_buf_kmap); /** * dma_buf_kunmap - Unmap a page obtained by dma_buf_kmap. @@ -424,7 +424,7 @@ void dma_buf_kunmap(struct dma_buf *dmabuf, unsigned long page_num, if (dmabuf->ops->kunmap) dmabuf->ops->kunmap(dmabuf, page_num, vaddr); } -EXPORT_SYMBOL_GPL(dma_buf_kunmap); +EXPORT_SYMBOL(dma_buf_kunmap); /** @@ -466,7 +466,7 @@ int dma_buf_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma, return dmabuf->ops->mmap(dmabuf, vma); } -EXPORT_SYMBOL_GPL(dma_buf_mmap); +EXPORT_SYMBOL(dma_buf_mmap); /** * dma_buf_vmap - Create virtual mapping for the buffer object into kernel @@ -487,7 +487,7 @@ void *dma_buf_vmap(struct dma_buf *dmabuf) return dmabuf->ops->vmap(dmabuf); return NULL; } -EXPORT_SYMBOL_GPL(dma_buf_vmap); +EXPORT_SYMBOL(dma_buf_vmap); /** * dma_buf_vunmap - Unmap a vmap obtained by dma_buf_vmap. @@ -502,4 +502,4 @@ void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr) if (dmabuf->ops->vunmap) dmabuf->ops->vunmap(dmabuf, vaddr); } -EXPORT_SYMBOL_GPL(dma_buf_vunmap); +EXPORT_SYMBOL(dma_buf_vunmap); -- 1.7.8.6

12 years, 1 month

[GIT PULL] CMA and DMA-mapping fixes for v3.7-rc3

by Marek Szyprowski

Hi Linus, I would like to ask for pulling some minor fixes for both CMA (Contiguous Memory Allocator) and DMA-mapping framework for v3.7-rc3. ---------------------------------------------------------------- The following changes since commit 6f0c0580b70c89094b3422ba81118c7b959c7556: Linux 3.7-rc2 (2012-10-20 12:11:32 -0700) are available in the git repository at: git://git.linaro.org/people/mszyprowski/linux-dma-mapping.git fixes_for_linus for you to fetch changes up to 4e85fb831aa210fd1c5e2cb7909ac203c1f5b67f: ARM: mm: Remove unused arm_vmregion priv field (2012-10-24 07:38:15 +0200) ---------------------------------------------------------------- This pull request consists mainly of a set of one-liner fixes and cleanups for a few minor issues identified in both Contiguous Memory Allocator code and ARM DMA-mapping subsystem. Thanks! Best regards Marek Szyprowski Samsung Poland R&D Center ---------------------------------------------------------------- Patch summary: Bob Liu (1): mm: cma: alloc_contig_range: return early for err path Jingoo Han (1): ARM: dma-mapping: fix build warning in __dma_alloc() Laurent Pinchart (4): drivers: dma-contiguous: Don't redefine SZ_1M drivers: dma-coherent: Fix typo in dma_mmap_from_coherent documentation drivers: cma: Fix wrong CMA selected region size default value ARM: mm: Remove unused arm_vmregion priv field Ming Lei (1): ARM: dma-mapping: support debug_dma_mapping_error arch/arm/include/asm/dma-mapping.h | 1 + arch/arm/mm/dma-mapping.c | 2 +- arch/arm/mm/vmregion.h | 1 - drivers/base/Kconfig | 2 +- drivers/base/dma-coherent.c | 5 ++--- drivers/base/dma-contiguous.c | 5 +---- mm/page_alloc.c | 2 +- 7 files changed, 7 insertions(+), 11 deletions(-)

12 years, 1 month

Re: [Linaro-mm-sig] [PATCH] dma-buf: Use EXPORT_SYMBOL

by Ken Phillis Jr

I agree with the logic Airlied made about Robert's patch. This is an important interface where it's not something you want to force closed source vendors to recreate and have things be an incompatible mess. This would cause a disaster for end users in the long rung... As for Airlied's mentioning of finding out the author's intention. This requires a chain of events to find out what exactly is going on... With this said, I will go ahead and post a quick chain of events to figure out what is going on with this section of code so that this can get resolved as quickly as possible... So far, The only two that even suggested that this API be made EXPORT_SYMBOL_GPL is Konrad Wilk and Arnd Bergmann. That said, Of course Semwil will agree since the whole discussion of this occurred over a 5 day span, and then a delay of about 12 days before the final RFC submission was made. The initial Framework and build up of the dma-buf interface: ( August 10th 2011) * [Linaro-mm-sig] [RFC] dma-shared-buf: Add buffer sharing framework http://lists.linaro.org/pipermail/linaro-mm-sig/2011-August/000509.html * [Linaro-mm-sig] [RFC v2] dma-buf: Add buffer sharing framework http://lists.linaro.org/pipermail/linaro-mm-sig/2011-September/000616.html * [Linaro-mm-sig] [RFC v3] dma-buf: Add buffer sharing framework http://lists.linaro.org/pipermail/linaro-mm-sig/2011-September/000661.html * [Linaro-mm-sig] [RFC 1/2] dma-buf: Introduce dma buffer sharing mechanism http://lists.linaro.org/pipermail/linaro-mm-sig/2011-October/000692.html * [Linaro-mm-sig] [RFC v2 1/2] dma-buf: Introduce dma buffer sharing mechanism http://lists.linaro.org/pipermail/linaro-mm-sig/2011-December/000810.html At this point it's December 2nd, and clearly it's been about 113 days since the initial interface suggestion. At this point is where the changes where suggested... Konrad - Makes initial suggestion ( was first response to this thread ) http://lists.linaro.org/pipermail/linaro-mm-sig/2011-December/000812.html Arnd - Agrees with Konrad (same thread ) http://lists.linaro.org/pipermail/linaro-mm-sig/2011-December/000815.html Semwil - Agrees with the other two ( same thread on December 7th) http://lists.linaro.org/pipermail/linaro-mm-sig/2011-December/000830.html Then the final seal on this transaction appears on the RFC V3 for this version of the path that appeared December 19th... * [Linaro-mm-sig] [RFC v3 1/2] dma-buf: Introduce dma buffer sharing mechanism http://lists.linaro.org/pipermail/linaro-mm-sig/2011-December/000880.html There's a closing statement that mentions this change ( However, there is no challenges made) * [Linaro-mm-sig] [ACTIVITY] Status of memory management closing 11.12 http://lists.linaro.org/pipermail/linaro-mm-sig/2011-December/000896.html Now the patch submission itself... * [Linaro-mm-sig] [PATCH 1/3] dma-buf: Introduce dma buffer sharing mechanism http://lists.linaro.org/pipermail/linaro-mm-sig/2011-December/000922.html Finally, this as a whole is sent to another mailing list... * [DRI-devel] [git pull] dma-buf tree ( January 6th, 2012) http://lists.freedesktop.org/archives/dri-devel/2012-January/017984.html The first challenge of the change appears.... * [DRI-devel] [PATCH] dma-buf: Use EXPORT_SYMBOL ( January 17th, 2012) http://lists.freedesktop.org/archives/dri-devel/2012-January/018250.html

12 years, 2 months

[RFC 0/2] DMA-mapping & IOMMU - physically contiguous allocations

by Marek Szyprowski

Hello, Some devices, which have IOMMU, for some use cases might require to allocate a buffers for DMA which is contiguous in physical memory. Such use cases appears for example in DRM subsystem when one wants to improve performance or use secure buffer protection. I would like to ask if adding a new attribute, as proposed in this RFC is a good idea? I feel that it might be an attribute just for a single driver, but I would like to know your opinion. Should we look for other solution? Best regards -- Marek Szyprowski Samsung Poland R&D Center Marek Szyprowski (2): common: DMA-mapping: add DMA_ATTR_FORCE_CONTIGUOUS attribute ARM: dma-mapping: add support for DMA_ATTR_FORCE_CONTIGUOUS attribute Documentation/DMA-attributes.txt | 9 +++++++++ arch/arm/mm/dma-mapping.c | 41 ++++++++++++++++++++++++++++++-------- include/linux/dma-attrs.h | 1 + 3 files changed, 43 insertions(+), 8 deletions(-) -- 1.7.9.5

12 years, 2 months

Test application for DMABUF support in V4L2

by Tomasz Stanislawski

Hello everyone, This mail contains an application to test DMABUF support in V4L2 for VIVI and S5P-FIMC drivers. The application was tested on linux-media for 3.7 with applied patchset "[PATCHv10 */26] Integration of videobuf2 with DMABUF" on Universal C210 board. Compilation: 1. Fetch media-next, apply patchset [PATCHv10 */26] Integration of videobuf2 with DMABUF 2. Execute 'make headers_install' in kernel source 3. arm-linux-gnueabi-gcc v4l-dbuf.c -o v4l-dbuf -O2 -std=gnu99 -I kernel/usr/include/ This app creates a simple pipeline between VIVI and two FIMC instances. The scenario goes as follows: 1. FIMC0 creates an MMAP buffer at its OUTPUT queue. (testing vb2_dc_alloc) 2. The buffer from 1. is exported using VIDIOC_EXPBUF. (testing exporting in vb2-dma-config) 3. The DMABUF from 2. is imported to VIVI at CAPTURE queue. (testing importing in vb2-vmalloc) 4. Single frame is grabbed from VIVI into the DMABUF. (testing vb2_dc_dmabuf_ops_vmap) 5. FIMC1 creates an MMAP buffer at its OUTPUT queue. (testing vb2_dc_alloc) 6. he buffer from 5. is exported using VIDIOC_EXPBUF. (testing exporting in vb2-dma-config) 7. The DMABUF from 6. is imported by FIMC0 at CAPTURE queue. (testing importing in vb2-dma-contig) 8. FIMC0 is used to process a frame (format conversion/scaling/rotation). 9. USERPTR is created from an anonymous or file mapping. 10. The USERPTR from 9. is passed to FIMC1 at CAPTURE queue. (testing vb2_dc_get_userptr) 11. FIMC1 is used to process a frame (format conversion/scaling/rotation). In the result, the USERPTR contains a frame from VIVI processed by two FIMCs. The app should produce 'Test passed' text on finish. The command line options allow to control the stages of the process -v path path to vivi [default /dev/video0] -f path path to fimc0 [default /dev/video1] -F path path to fimc1 [default /dev/video3] -0 4cc@WxH format between VIVI and FIMC0 -1 4cc@WxH format between FIMC0 and FIMC1 -2 4cc@WxH format between FIMC1 and destination -V vertical flip on FIMC0 -H horizontal flip on FIMC0 -R angle rotation by angle [default 0] on FIMC0 -m size[@file[+offset]] destination mapping, size 0 is adjusted automatically, no file indicate anonymous mapping -h print this help For example: v4l-dbuf -0 RGBP@320x200 -H -R 90 -1 RGB4@96x96 -2 YUYV@32x32 -m 0@/dev/fb0 does: - grab frame from VIVI 320x200 in RGBP (RGB565) format - convert this frame to 96x96 RGB4 (RGB32) format using FIMC0, apply horizontal flip and 90 degree rotation - convert result frame to 32x32 YUYV format using FIMC1 - store result in a framebuffer at /dev/fb0 Please, notice if destination file is missing, then anonymous mapping is used. On platforms that support no SYSMMU for FIMC it is very likely that VIDIOC_QBUF will fail if the size of the result image is larger than a single page. Please use -v, -f, -F options to setup proper paths to VIVI, FIMC0-M2M, and FIMC1-M2M nodes. At each stage the result frames are dumped in PPM format (Netpbm format). Currently, dumping is supported only for RGB565, RGB32 and YUYV formats. The app is not aborted if a format is not supported. Please let us know if you have any further questions. Regards, Tomasz Stanislawski

12 years, 2 months

[PATCHv9 00/25] Integration of videobuf2 with DMABUF

by Tomasz Stanislawski

Hello everyone, This patchset adds support for DMABUF [2] importing and exporting to V4L2 stack. v9: - rebase on 3.6 - change type for fs to __s32 - add support for vb2_ioctl_expbuf - remove patch 'v4l: vb2: add support for DMA_ATTR_NO_KERNEL_MAPPING', it will be posted as a separate patch - fix typos and style in Documentation (from Hans Verkuil) - only vb2-core and vb2-dma-contig selects DMA_SHARED_BUFFER in Kconfig - use data_offset and length while queueing DMABUF - return the most recently used fd at VIDIOC_DQBUF - use (buffer-type, index, plane) tuple instead of mem_offset to identify a for exporting (from Hans Verkuil) - support for DMABUF mmap in vb2-dma-contig (from Laurent Pinchart) - add testing alignment of vaddr and size while verifying userptr against DMA capabilities (from Laurent Pinchart) - substitute VM_DONTDUMP with VM_RESERVED - simplify error handling in vb2_dc_get_dmabuf (from Laurent Pinchart) v8: - rebased on 3.6-rc1 - merged importer and exporter patchsets - fixed missing fields in v4l2_plane32 and v4l2_buffer32 structs - fixed typos/style in documentation - significant reduction of warnings from checkpatch.pl - fixed STREAMOFF issues reported by Dima Zavin [4] by adding __vb2_dqbuf helper to vb2-core - DC fails if userptr is not correctly aligned - add support for DMA attributes in DC - add support for buffers with no kernel mapping - add reference counting on device from allocator context - dummy support for mmap - use dma_get_sgtable, drop vb2_dc_kaddr_to_pages hack and vb2_dc_get_base_sgt helper v7: - support for V4L2_MEMORY_DMABUF in v4l2-compact-ioctl32.c - cosmetic fixes to the documentation - added importing for vmalloc because vmap support in dmabuf for 3.5 was pull-requested - support for dmabuf importing for VIVI - resurrect allocation of dma-contig context - remove reference of alloc_ctx in dma-contig buffer - use sg_alloc_table_from_pages - fix DMA scatterlist calls to use orig_nents instead of nents - fix memleak in vb2_dc_sgt_foreach_page (use orig_nents instead of nents) v6: - fixed missing entry in v4l2_memory_names - fixed a bug occuring after get_user_pages failure - fixed a bug caused by using invalid vma for get_user_pages - prepare/finish no longer call dma_sync for dmabuf buffers v5: - removed change of importer/exporter behaviour - fixes vb2_dc_pages_to_sgt basing on Laurent's hints - changed pin/unpin words to lock/unlock in Doc v4: - rebased on mainline 3.4-rc2 - included missing importing support for s5p-fimc and s5p-tv - added patch for changing map/unmap for importers - fixes to Documentation part - coding style fixes - pairing {map/unmap}_dmabuf in vb2-core - fixing variable types and semantic of arguments in videobufb2-dma-contig.c v3: - rebased on mainline 3.4-rc1 - split 'code refactor' patch to multiple smaller patches - squashed fixes to Sumit's patches - patchset is no longer dependant on 'DMA mapping redesign' - separated path for handling IO and non-IO mappings - add documentation for DMABUF importing to V4L - removed all DMABUF exporter related code - removed usage of dma_get_pages extension v2: - extended VIDIOC_EXPBUF argument from integer memoffset to struct v4l2_exportbuffer - added patch that breaks DMABUF spec on (un)map_atachment callcacks but allows to work with existing implementation of DMABUF prime in DRM - all dma-contig code refactoring patches were squashed - bugfixes v1: List of changes since [1]. - support for DMA api extension dma_get_pages, the function is used to retrieve pages used to create DMA mapping. - small fixes/code cleanup to videobuf2 - added prepare and finish callbacks to vb2 allocators, it is used keep consistency between dma-cpu acess to the memory (by Marek Szyprowski) - support for exporting of DMABUF buffer in V4L2 and Videobuf2, originated from [3]. - support for dma-buf exporting in vb2-dma-contig allocator - support for DMABUF for s5p-tv and s5p-fimc (capture interface) drivers, originated from [3] - changed handling for userptr buffers (by Marek Szyprowski, Andrzej Pietrasiewicz) - let mmap method to use dma_mmap_writecombine call (by Marek Szyprowski) [1] http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/4296… [2] https://lkml.org/lkml/2011/12/26/29 [3] http://thread.gmane.org/gmane.linux.kernel.cross-arch/12819 [4] http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/497… Laurent Pinchart (2): v4l: vb2-dma-contig: shorten vb2_dma_contig prefix to vb2_dc v4l: vb2-dma-contig: reorder functions Marek Szyprowski (4): v4l: vb2: add prepare/finish callbacks to allocators v4l: vb2-dma-contig: add prepare/finish to dma-contig allocator v4l: vb2-dma-contig: let mmap method to use dma_mmap_coherent call v4l: vb2-dma-contig: fail if user ptr buffer is not correctly aligned Sumit Semwal (4): v4l: Add DMABUF as a memory type v4l: vb2: add support for shared buffer (dma_buf) v4l: vb: remove warnings about MEMORY_DMABUF v4l: vb2-dma-contig: add support for dma_buf importing Tomasz Stanislawski (15): Documentation: media: description of DMABUF importing in V4L2 v4l: vb2-dma-contig: remove reference of alloc_ctx from a buffer v4l: vb2-dma-contig: add support for scatterlist in userptr mode v4l: vb2-vmalloc: add support for dmabuf importing v4l: vivi: support for dmabuf importing v4l: s5p-tv: mixer: support for dmabuf importing v4l: s5p-fimc: support for dmabuf importing Documentation: media: description of DMABUF exporting in V4L2 v4l: add buffer exporting via dmabuf v4l: vb2: add buffer exporting via dmabuf v4l: vb2-dma-contig: add support for DMABUF exporting v4l: vb2-dma-contig: add reference counting for a device from allocator context v4l: s5p-fimc: support for dmabuf exporting v4l: s5p-tv: mixer: support for dmabuf exporting v4l: s5p-mfc: support for dmabuf exporting Documentation/DocBook/media/v4l/compat.xml | 7 + Documentation/DocBook/media/v4l/io.xml | 183 +++++- Documentation/DocBook/media/v4l/v4l2.xml | 1 + .../DocBook/media/v4l/vidioc-create-bufs.xml | 16 +- Documentation/DocBook/media/v4l/vidioc-expbuf.xml | 212 ++++++ Documentation/DocBook/media/v4l/vidioc-qbuf.xml | 17 + Documentation/DocBook/media/v4l/vidioc-reqbufs.xml | 47 +- drivers/media/video/Kconfig | 2 + drivers/media/video/s5p-fimc/fimc-capture.c | 11 +- drivers/media/video/s5p-mfc/s5p_mfc_dec.c | 14 + drivers/media/video/s5p-mfc/s5p_mfc_enc.c | 14 + drivers/media/video/s5p-tv/mixer_video.c | 12 +- drivers/media/video/v4l2-compat-ioctl32.c | 19 + drivers/media/video/v4l2-dev.c | 1 + drivers/media/video/v4l2-ioctl.c | 11 + drivers/media/video/videobuf-core.c | 4 + drivers/media/video/videobuf2-core.c | 300 ++++++++- drivers/media/video/videobuf2-dma-contig.c | 695 ++++++++++++++++++-- drivers/media/video/videobuf2-memops.c | 40 -- drivers/media/video/videobuf2-vmalloc.c | 56 ++ drivers/media/video/vivi.c | 2 +- include/linux/videodev2.h | 35 + include/media/v4l2-ioctl.h | 2 + include/media/videobuf2-core.h | 38 ++ include/media/videobuf2-memops.h | 5 - 25 files changed, 1608 insertions(+), 136 deletions(-) create mode 100644 Documentation/DocBook/media/v4l/vidioc-expbuf.xml -- 1.7.9.5

12 years, 2 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig October 2012