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

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

by benjamin.gaignard＠linaro.org

From: Benjamin Gaignard <benjamin.gaignard(a)linaro.org> 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 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/Kconfig | 5 ++ drivers/gpu/ion/Makefile | 1 + drivers/gpu/ion/ion_cma_heap.c | 187 ++++++++++++++++++++++++++++++++++++++++ drivers/gpu/ion/ion_heap.c | 7 ++ drivers/gpu/ion/ion_priv.h | 16 ++++ include/linux/ion.h | 7 +- 6 files changed, 222 insertions(+), 1 deletion(-) create mode 100644 drivers/gpu/ion/ion_cma_heap.c -- 1.7.10

12 years, 6 months

1
0
0 0

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

9
26
0 0

[PATCH] dma-mapping: fix dma_common_get_sgtable() conditional compilation

by Marek Szyprowski

dma_common_get_sgtable() function doesn't depend on ARCH_HAS_DMA_DECLARE_COHERENT_MEMORY, so it must not be compiled conditionally. Reported-by: Stephen Rothwell <sfr(a)canb.auug.org.au> Signed-off-by: Marek Szyprowski <m.szyprowski(a)samsung.com> --- drivers/base/dma-mapping.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/base/dma-mapping.c b/drivers/base/dma-mapping.c index 3fbedc7..0ce39a3 100644 --- a/drivers/base/dma-mapping.c +++ b/drivers/base/dma-mapping.c @@ -218,6 +218,8 @@ void dmam_release_declared_memory(struct device *dev) } EXPORT_SYMBOL(dmam_release_declared_memory); +#endif + /* * Create scatter-list for the already allocated DMA buffer. */ @@ -236,8 +238,6 @@ int dma_common_get_sgtable(struct device *dev, struct sg_table *sgt, } EXPORT_SYMBOL(dma_common_get_sgtable); -#endif - /* * Create userspace mapping for the DMA-coherent memory. */ -- 1.7.9.5

12 years, 6 months

1
0
0 0

DMABUF V4L2 patches got merged

by Mauro Carvalho Chehab

Hi all, Today, I finally merged the DMABUF V4L2 patches from Tomasz. The DMABUF allows replacing the old V4L2 Overlay method by something more robust and safer. It was a long road to get them ready for their upstream inclusion, and to be able to test on both embedded and personal computers. Along this weekend, I was able to test it using 4 different test scenarios: - vivi + s5p-tv; - uvcvideo + fimc (m2m) + s5p-tv; - s5k4ecgx + fimc (m2m) + s5p-tv; - uvcvideo + i915. The first 3 tests ran on a Samsung Origen Rev. A board; the 4th one on a notebook, with a Sandy Bridge i5core processor with GPU, and an embedded UVC camera. While testing the s5k4ecgx sensor driver, I also added support for multiplane at libv4l, via its plugin interface: http://git.linuxtv.org/v4l-utils.git/commit/ced1be346fe4f61c864cba9d81f6608… Such tests wouldn't be possible without the help of Linaro and Samsung, with donated me some hardware for the tests, and Ideas on Board for making uvcvideo + i915 driver to work especially for this test. Thank you all for your support! In particular, Sylwester helped me a lot to fix several non-related issues with the Origen board, that was not running with an upstream Kernel. There are a number of patches required to make the Origen board to work with an Upstream Kernel. Also, its sensor driver (s5k4ecgx) was not submitted upstream yet. In order to help others that may need to do similar tests, I added the needed patches on my experimental tree, at branch origen+dmabuf: http://git.linuxtv.org/mchehab/experimental.git/shortlog/refs/heads/origen%… Still missing there are the wireless/bluetooth support. It seems that there are some patches for it already, but they aren't submitted upstream, nor I didn't test they. I expect that Linaro and Samsung will be able to submit real soon the pending patches needed by Origen in time for its addition on 3.8. Thank you all! Mauro

12 years, 6 months

2
1
0 0

[PATCH] mm: cma: allocate pages from CMA if NR_FREE_PAGES approaches low water mark

by Marek Szyprowski

It has been observed that system tends to keep a lot of CMA free pages even in very high memory pressure use cases. The CMA fallback for movable pages is used very rarely, only when system is completely pruned from MOVABLE pages, what usually means that the out-of-memory even will be triggered very soon. To avoid such situation and make better use of CMA pages, a heuristics is introduced which turns on CMA fallback for movable pages when the real number of free pages (excluding CMA free pages) approaches low water mark. Signed-off-by: Marek Szyprowski <m.szyprowski(a)samsung.com> Reviewed-by: Kyungmin Park <kyungmin.park(a)samsung.com> CC: Michal Nazarewicz <mina86(a)mina86.com> --- mm/page_alloc.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/mm/page_alloc.c b/mm/page_alloc.c index fcb9719..90b51f3 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -1076,6 +1076,15 @@ static struct page *__rmqueue(struct zone *zone, unsigned int order, { struct page *page; +#ifdef CONFIG_CMA + unsigned long nr_free = zone_page_state(zone, NR_FREE_PAGES); + unsigned long nr_cma_free = zone_page_state(zone, NR_FREE_CMA_PAGES); + + if (migratetype == MIGRATE_MOVABLE && nr_cma_free && + nr_free - nr_cma_free < 2 * low_wmark_pages(zone)) + migratetype = MIGRATE_CMA; +#endif /* CONFIG_CMA */ + retry_reserve: page = __rmqueue_smallest(zone, order, migratetype); -- 1.7.9.5

12 years, 6 months

4
11
0 0

[PATCH] mm: skip watermarks check for already isolated blocks in split_free_page()

by Marek Szyprowski

Since commit 2139cbe627b8 ("cma: fix counting of isolated pages") free pages in isolated pageblocks are not accounted to NR_FREE_PAGES counters, so watermarks check is not required if one operates on a free page in isolated pageblock. Signed-off-by: Marek Szyprowski <m.szyprowski(a)samsung.com> --- mm/page_alloc.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/mm/page_alloc.c b/mm/page_alloc.c index fd154fe..43ab09f 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -1394,10 +1394,12 @@ int capture_free_page(struct page *page, int alloc_order, int migratetype) zone = page_zone(page); order = page_order(page); - /* Obey watermarks as if the page was being allocated */ - watermark = low_wmark_pages(zone) + (1 << order); - if (!zone_watermark_ok(zone, 0, watermark, 0, 0)) - return 0; + if (get_pageblock_migratetype(page) != MIGRATE_ISOLATE) { + /* Obey watermarks as if the page was being allocated */ + watermark = low_wmark_pages(zone) + (1 << order); + if (!zone_watermark_ok(zone, 0, watermark, 0, 0)) + return 0; + } /* Remove page from free list */ list_del(&page->lru); -- 1.7.9.5

12 years, 6 months

2
2
0 0

[PATCH] mm: cma: WARN if freed memory is still in use

by Marek Szyprowski

Memory return to free_contig_range() must have no other references. Let kernel to complain loudly if page reference count is not equal to 1. Signed-off-by: Marek Szyprowski <m.szyprowski(a)samsung.com> Reviewed-by: Kyungmin Park <kyungmin.park(a)samsung.com> CC: Michal Nazarewicz <mina86(a)mina86.com> --- mm/page_alloc.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/mm/page_alloc.c b/mm/page_alloc.c index 022e4ed..290c2eb 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -5888,8 +5888,13 @@ done: void free_contig_range(unsigned long pfn, unsigned nr_pages) { - for (; nr_pages--; ++pfn) - __free_page(pfn_to_page(pfn)); + struct page *page = pfn_to_page(pfn); + int refcount = nr_pages; + for (; nr_pages--; page++) { + refcount -= page_count(page) == 1; + __free_page(page); + } + WARN(refcount != 0, "some pages are still in use!\n"); } #endif -- 1.7.9.5

12 years, 6 months

2
3
0 0

[PATCH] mm: use migrate_prep() instead of migrate_prep_local()

by Marek Szyprowski

__alloc_contig_migrate_range() should use all possible ways to get all the pages migrated from the given memory range, so pruning per-cpu lru lists for all CPUs is required, regadless the cost of such operation. Otherwise some pages which got stuck at per-cpu lru list might get missed by migration procedure causing the contiguous allocation to fail. Reported-by: SeongHwan Yoon <sunghwan.yun(a)samsung.com> Signed-off-by: Marek Szyprowski <m.szyprowski(a)samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park(a)samsung.com> --- mm/page_alloc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/page_alloc.c b/mm/page_alloc.c index 1bfe2b0..fcb9719 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -5677,7 +5677,7 @@ static int __alloc_contig_migrate_range(struct compact_control *cc, unsigned int tries = 0; int ret = 0; - migrate_prep_local(); + migrate_prep(); while (pfn < end || !list_empty(&cc->migratepages)) { if (fatal_signal_pending(current)) { -- 1.7.9.5

12 years, 6 months

2
1
0 0

[PATCH] mm: remove watermark hacks for CMA

by Marek Szyprowski

Commits 2139cbe627b89 ("cma: fix counting of isolated pages") and d95ea5d18e69951 ("cma: fix watermark checking") introduced a reliable method of free page accounting when memory is being allocated from CMA regions, so the workaround introduced earlier by commit 49f223a9cd96c72 ("mm: trigger page reclaim in alloc_contig_range() to stabilise watermarks") can be finally removed. Signed-off-by: Marek Szyprowski <m.szyprowski(a)samsung.com> --- include/linux/mmzone.h | 9 -------- mm/page_alloc.c | 57 ------------------------------------------------ 2 files changed, 66 deletions(-) diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h index c9fcd8f..f010b23 100644 --- a/include/linux/mmzone.h +++ b/include/linux/mmzone.h @@ -63,10 +63,8 @@ enum { #ifdef CONFIG_CMA # define is_migrate_cma(migratetype) unlikely((migratetype) == MIGRATE_CMA) -# define cma_wmark_pages(zone) zone->min_cma_pages #else # define is_migrate_cma(migratetype) false -# define cma_wmark_pages(zone) 0 #endif #define for_each_migratetype_order(order, type) \ @@ -372,13 +370,6 @@ struct zone { /* see spanned/present_pages for more description */ seqlock_t span_seqlock; #endif -#ifdef CONFIG_CMA - /* - * CMA needs to increase watermark levels during the allocation - * process to make sure that the system is not starved. - */ - unsigned long min_cma_pages; -#endif struct free_area free_area[MAX_ORDER]; #ifndef CONFIG_SPARSEMEM diff --git a/mm/page_alloc.c b/mm/page_alloc.c index 43ab09f..5028a18 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -5217,10 +5217,6 @@ static void __setup_per_zone_wmarks(void) zone->watermark[WMARK_LOW] = min_wmark_pages(zone) + (tmp >> 2); zone->watermark[WMARK_HIGH] = min_wmark_pages(zone) + (tmp >> 1); - zone->watermark[WMARK_MIN] += cma_wmark_pages(zone); - zone->watermark[WMARK_LOW] += cma_wmark_pages(zone); - zone->watermark[WMARK_HIGH] += cma_wmark_pages(zone); - setup_zone_migrate_reserve(zone); spin_unlock_irqrestore(&zone->lock, flags); } @@ -5765,54 +5761,6 @@ static int __alloc_contig_migrate_range(struct compact_control *cc, return ret > 0 ? 0 : ret; } -/* - * Update zone's cma pages counter used for watermark level calculation. - */ -static inline void __update_cma_watermarks(struct zone *zone, int count) -{ - unsigned long flags; - spin_lock_irqsave(&zone->lock, flags); - zone->min_cma_pages += count; - spin_unlock_irqrestore(&zone->lock, flags); - setup_per_zone_wmarks(); -} - -/* - * Trigger memory pressure bump to reclaim some pages in order to be able to - * allocate 'count' pages in single page units. Does similar work as - *__alloc_pages_slowpath() function. - */ -static int __reclaim_pages(struct zone *zone, gfp_t gfp_mask, int count) -{ - enum zone_type high_zoneidx = gfp_zone(gfp_mask); - struct zonelist *zonelist = node_zonelist(0, gfp_mask); - int did_some_progress = 0; - int order = 1; - - /* - * Increase level of watermarks to force kswapd do his job - * to stabilise at new watermark level. - */ - __update_cma_watermarks(zone, count); - - /* Obey watermarks as if the page was being allocated */ - while (!zone_watermark_ok(zone, 0, low_wmark_pages(zone), 0, 0)) { - wake_all_kswapd(order, zonelist, high_zoneidx, zone_idx(zone)); - - did_some_progress = __perform_reclaim(gfp_mask, order, zonelist, - NULL); - if (!did_some_progress) { - /* Exhausted what can be done so it's blamo time */ - out_of_memory(zonelist, gfp_mask, order, NULL, false); - } - } - - /* Restore original watermark levels. */ - __update_cma_watermarks(zone, -count); - - return count; -} - /** * alloc_contig_range() -- tries to allocate given range of pages * @start: start PFN to allocate @@ -5921,11 +5869,6 @@ int alloc_contig_range(unsigned long start, unsigned long end, goto done; } - /* - * Reclaim enough pages to make sure that contiguous allocation - * will not starve the system. - */ - __reclaim_pages(zone, GFP_HIGHUSER_MOVABLE, end-start); /* Grab isolated pages from freelists. */ outer_end = isolate_freepages_range(&cc, outer_start, end); -- 1.7.9.5

12 years, 7 months

1
0
0 0

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

5
42
0 0

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

2
1
0 0

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

1
0
0 0

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

9
31
0 0

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

1
0
0 0

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

1
0
0 0

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

7
14
0 0

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

1
0
0 0

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

5
46
0 0

[PATCH 1/5] dma-buf: remove fallback for !CONFIG_DMA_SHARED_BUFFER

by Maarten Lankhorst

Documentation says that code requiring dma-buf should add it to select, so inline fallbacks are not going to be used. A link error will make it obvious what went wrong, instead of silently doing nothing at runtime. Signed-off-by: Maarten Lankhorst <maarten.lankhorst(a)canonical.com> --- include/linux/dma-buf.h | 99 ----------------------------------------------- 1 file changed, 99 deletions(-) diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h index eb48f38..bd2e52c 100644 --- a/include/linux/dma-buf.h +++ b/include/linux/dma-buf.h @@ -156,7 +156,6 @@ static inline void get_dma_buf(struct dma_buf *dmabuf) get_file(dmabuf->file); } -#ifdef CONFIG_DMA_SHARED_BUFFER struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf, struct device *dev); void dma_buf_detach(struct dma_buf *dmabuf, @@ -184,103 +183,5 @@ int dma_buf_mmap(struct dma_buf *, struct vm_area_struct *, unsigned long); void *dma_buf_vmap(struct dma_buf *); void dma_buf_vunmap(struct dma_buf *, void *vaddr); -#else - -static inline struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf, - struct device *dev) -{ - return ERR_PTR(-ENODEV); -} - -static inline void dma_buf_detach(struct dma_buf *dmabuf, - struct dma_buf_attachment *dmabuf_attach) -{ - return; -} - -static inline struct dma_buf *dma_buf_export(void *priv, - const struct dma_buf_ops *ops, - size_t size, int flags) -{ - return ERR_PTR(-ENODEV); -} - -static inline int dma_buf_fd(struct dma_buf *dmabuf, int flags) -{ - return -ENODEV; -} - -static inline struct dma_buf *dma_buf_get(int fd) -{ - return ERR_PTR(-ENODEV); -} - -static inline void dma_buf_put(struct dma_buf *dmabuf) -{ - return; -} - -static inline struct sg_table *dma_buf_map_attachment( - struct dma_buf_attachment *attach, enum dma_data_direction write) -{ - return ERR_PTR(-ENODEV); -} - -static inline void dma_buf_unmap_attachment(struct dma_buf_attachment *attach, - struct sg_table *sg, enum dma_data_direction dir) -{ - return; -} - -static inline int dma_buf_begin_cpu_access(struct dma_buf *dmabuf, - size_t start, size_t len, - enum dma_data_direction dir) -{ - return -ENODEV; -} - -static inline void dma_buf_end_cpu_access(struct dma_buf *dmabuf, - size_t start, size_t len, - enum dma_data_direction dir) -{ -} - -static inline void *dma_buf_kmap_atomic(struct dma_buf *dmabuf, - unsigned long pnum) -{ - return NULL; -} - -static inline void dma_buf_kunmap_atomic(struct dma_buf *dmabuf, - unsigned long pnum, void *vaddr) -{ -} - -static inline void *dma_buf_kmap(struct dma_buf *dmabuf, unsigned long pnum) -{ - return NULL; -} - -static inline void dma_buf_kunmap(struct dma_buf *dmabuf, - unsigned long pnum, void *vaddr) -{ -} - -static inline int dma_buf_mmap(struct dma_buf *dmabuf, - struct vm_area_struct *vma, - unsigned long pgoff) -{ - return -ENODEV; -} - -static inline void *dma_buf_vmap(struct dma_buf *dmabuf) -{ - return NULL; -} - -static inline void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr) -{ -} -#endif /* CONFIG_DMA_SHARED_BUFFER */ #endif /* __DMA_BUF_H__ */

12 years, 8 months

4
26
0 0

Re: [Linaro-mm-sig] [RFC] New dma_buf -> EGLImage EGL extension

by Maarten Lankhorst

Hey, Bit late reply, hopefully not too late. Op 30-08-12 16:00, Tom Cooksey schreef: > Hi All, > > Over the last few months I've been working on & off with a few people from > Linaro on a new EGL extension. The extension allows constructing an EGLImage > from a (set of) dma_buf file descriptors, including support for multi-plane > YUV. I envisage the primary use-case of this extension to be importing video > frames from v4l2 into the EGL/GLES graphics driver to texture from. > Originally the intent was to develop this as a Khronos-ratified extension. > However, this is a little too platform-specific to be an officially > sanctioned Khronos extension. It also goes against the general "EGLStream" > direction the EGL working group is going in. As such, the general feeling > was to make this an EXT "multi-vendor" extension with no official stamp of > approval from Khronos. As this is no-longer intended to be a Khronos > extension, I've re-written it to be a lot more Linux & dma_buf specific. It > also allows me to circulate the extension more widely (I.e. To those outside > Khronos membership). > > ARM are implementing this extension for at least our Mali-T6xx driver and > likely earlier drivers too. I am sending this e-mail to solicit feedback, > both from other vendors who might implement this extension (Mesa3D?) and > from potential users of the extension. However, any feedback is welcome. > Please find the extension text as it currently stands below. There several > open issues which I've proposed solutions for, but I'm not really happy with > those proposals and hoped others could chip-in with better ideas. There are > likely other issues I've not thought about which also need to be added and > addressed. > > Once there's a general consensus or if no-one's interested, I'll update the > spec, move it out of Draft status and get it added to the Khronos registry, > which includes assigning values for the new symbols. > > > Cheers, > > Tom > > > ---------8<--------- > > > Name > > EXT_image_dma_buf_import > > Name Strings > > EGL_EXT_image_dma_buf_import > > Contributors > > Jesse Barker > Rob Clark > Tom Cooksey > > Contacts > > Jesse Barker (jesse 'dot' barker 'at' linaro 'dot' org) > Tom Cooksey (tom 'dot' cooksey 'at' arm 'dot' com) > > Status > > DRAFT > > Version > > Version 3, August 16, 2012 > > Number > > EGL Extension ??? > > Dependencies > > EGL 1.2 is required. > > EGL_KHR_image_base is required. > > The EGL implementation must be running on a Linux kernel supporting the > dma_buf buffer sharing mechanism. > > This extension is written against the wording of the EGL 1.2 > Specification. > > Overview > > This extension allows creating an EGLImage from a Linux dma_buf file > descriptor or multiple file descriptors in the case of multi-plane YUV > images. > > New Types > > None > > New Procedures and Functions > > None > > New Tokens > > Accepted by the <target> parameter of eglCreateImageKHR: > > EGL_LINUX_DMA_BUF_EXT > > Accepted as an attribute in the <attrib_list> parameter of > eglCreateImageKHR: > > EGL_LINUX_DRM_FOURCC_EXT > EGL_DMA_BUF_PLANE0_FD_EXT > EGL_DMA_BUF_PLANE0_OFFSET_EXT > EGL_DMA_BUF_PLANE0_PITCH_EXT > EGL_DMA_BUF_PLANE1_FD_EXT > EGL_DMA_BUF_PLANE1_OFFSET_EXT > EGL_DMA_BUF_PLANE1_PITCH_EXT > EGL_DMA_BUF_PLANE2_FD_EXT > EGL_DMA_BUF_PLANE2_OFFSET_EXT > EGL_DMA_BUF_PLANE2_PITCH_EXT You might want to add PLANE3 just in case someone wants to import a AYUV image. > Additions to Chapter 2 of the EGL 1.2 Specification (EGL Operation) > > Add to section 2.5.1 "EGLImage Specification" (as defined by the > EGL_KHR_image_base specification), in the description of > eglCreateImageKHR: > > "Values accepted for <target> are listed in Table aaa, below. > > > +-------------------------+--------------------------------------------+ > | <target> | Notes > | > > +-------------------------+--------------------------------------------+ > | EGL_LINUX_DMA_BUF_EXT | Used for EGLImages imported from Linux > | > | | dma_buf file descriptors > | > > +-------------------------+--------------------------------------------+ > Table aaa. Legal values for eglCreateImageKHR <target> parameter > > ... > > If <target> is EGL_LINUX_DMA_BUF_EXT, <dpy> must be a valid display, > <ctx> > must be EGL_NO_CONTEXT, and <buffer> must be NULL, cast into the type > EGLClientBuffer. The details of the image is specified by the attributes > passed into eglCreateImageKHR. Required attributes and their values are > as > follows: > > * EGL_WIDTH & EGL_HEIGHT: The logical dimensions of the buffer in > pixels > > * EGL_LINUX_DRM_FOURCC_EXT: The pixel format of the buffer, as > specified > by drm_fourcc.h and used as the pixel_format parameter of the > drm_mode_fb_cmd2 ioctl. > > * EGL_DMA_BUF_PLANE0_FD_EXT: The dma_buf file descriptor of plane 0 > of > the image. > > * EGL_DMA_BUF_PLANE0_OFFSET_EXT: The offset from the start of the > dma_buf of the first sample in plane 0, in bytes. > > * EGL_DMA_BUF_PLANE0_PITCH_EXT: The number of bytes between the > start of > subsequent rows of samples in plane 0. May have special meaning > for > non-linear formats. > > For images in an RGB color-space or those using a single-plane YUV > format, > only the first plane's file descriptor, offset & pitch should be > specified. > For semi-planar YUV formats, the chroma samples are stored in plane 1 > and > for fully planar formats, U-samples are stored in plane 1 and V-samples > are > stored in plane 2. Planes 1 & 2 are specified by the following > attributes, > which have the same meanings as defined above for plane 0: > Nitpick, Y'CbCr not YUV. How do you want to deal with the case where Y' and CbCr are different hardware buffers? Could some support for 2d arrays be added in case Y' and CbCr are separated into top/bottom fields? How are semi-planar/planar formats handled that have a different width/height for Y' and CbCr? (YUV420) ~Maarten

12 years, 8 months

4
3
0 0

[RFC] New dma_buf -> EGLImage EGL extension - New draft!

by Tom Cooksey

Hi All, After receiving a fair bit of feedback (thanks!), I've updated the EGL_EXT_image_dma_buf_import spec and expanded it to resolve a number of the issues. Please find the latest draft below and let me know any additional feedback you might have, either on the lists or by private e-mail - I don't mind which. I think the only remaining issue now is if we need a mechanism whereby an application can query which drm_fourcc.h formats EGL supports or if just failing with EGL_BAD_MATCH when the application has use one EGL doesn't support is sufficient. Any thoughts? Cheers, Tom --------------------8<-------------------- Name EXT_image_dma_buf_import Name Strings EGL_EXT_image_dma_buf_import Contributors Jesse Barker Rob Clark Tom Cooksey Contacts Jesse Barker (jesse 'dot' barker 'at' linaro 'dot' org) Tom Cooksey (tom 'dot' cooksey 'at' arm 'dot' com) Status DRAFT Version Version 4, October 04, 2012 Number EGL Extension ??? Dependencies EGL 1.2 is required. EGL_KHR_image_base is required. The EGL implementation must be running on a Linux kernel supporting the dma_buf buffer sharing mechanism. This extension is written against the wording of the EGL 1.2 Specification. Overview This extension allows creating an EGLImage from a Linux dma_buf file descriptor or multiple file descriptors in the case of multi-plane YUV images. New Types None New Procedures and Functions None New Tokens Accepted by the <target> parameter of eglCreateImageKHR: EGL_LINUX_DMA_BUF_EXT Accepted as an attribute in the <attrib_list> parameter of eglCreateImageKHR: EGL_LINUX_DRM_FOURCC_EXT EGL_DMA_BUF_PLANE0_FD_EXT EGL_DMA_BUF_PLANE0_OFFSET_EXT EGL_DMA_BUF_PLANE0_PITCH_EXT EGL_DMA_BUF_PLANE1_FD_EXT EGL_DMA_BUF_PLANE1_OFFSET_EXT EGL_DMA_BUF_PLANE1_PITCH_EXT EGL_DMA_BUF_PLANE2_FD_EXT EGL_DMA_BUF_PLANE2_OFFSET_EXT EGL_DMA_BUF_PLANE2_PITCH_EXT EGL_YUV_COLOR_SPACE_HINT_EXT EGL_SAMPLE_RANGE_HINT_EXT EGL_YUV_CHROMA_HORIZONTAL_SITING_HINT_EXT EGL_YUV_CHROMA_VERTICAL_SITING_HINT_EXT Accepted as the value for the EGL_YUV_COLOR_SPACE_HINT_EXT attribute: EGL_ITU_REC601_EXT EGL_ITU_REC709_EXT EGL_ITU_REC2020_EXT Accepted as the value for the EGL_SAMPLE_RANGE_HINT_EXT attribute: EGL_YUV_FULL_RANGE_EXT EGL_YUV_NARROW_RANGE_EXT Accepted as the value for the EGL_YUV_CHROMA_HORIZONTAL_SITING_HINT_EXT & EGL_YUV_CHROMA_VERTICAL_SITING_HINT_EXT attributes: EGL_YUV_CHROMA_SITING_0_EXT EGL_YUV_CHROMA_SITING_0_5_EXT Additions to Chapter 2 of the EGL 1.2 Specification (EGL Operation) Add to section 2.5.1 "EGLImage Specification" (as defined by the EGL_KHR_image_base specification), in the description of eglCreateImageKHR: "Values accepted for <target> are listed in Table aaa, below. +-------------------------+--------------------------------------------+ | <target> | Notes | +-------------------------+--------------------------------------------+ | EGL_LINUX_DMA_BUF_EXT | Used for EGLImages imported from Linux | | | dma_buf file descriptors | +-------------------------+--------------------------------------------+ Table aaa. Legal values for eglCreateImageKHR <target> parameter ... If <target> is EGL_LINUX_DMA_BUF_EXT, <dpy> must be a valid display, <ctx> must be EGL_NO_CONTEXT, and <buffer> must be NULL, cast into the type EGLClientBuffer. The details of the image is specified by the attributes passed into eglCreateImageKHR. Required attributes and their values are as follows: * EGL_WIDTH & EGL_HEIGHT: The logical dimensions of the buffer in pixels * EGL_LINUX_DRM_FOURCC_EXT: The pixel format of the buffer, as specified by drm_fourcc.h and used as the pixel_format parameter of the drm_mode_fb_cmd2 ioctl. * EGL_DMA_BUF_PLANE0_FD_EXT: The dma_buf file descriptor of plane 0 of the image. * EGL_DMA_BUF_PLANE0_OFFSET_EXT: The offset from the start of the dma_buf of the first sample in plane 0, in bytes. * EGL_DMA_BUF_PLANE0_PITCH_EXT: The number of bytes between the start of subsequent rows of samples in plane 0. May have special meaning for non-linear formats. For images in an RGB color-space or those using a single-plane YUV format, only the first plane's file descriptor, offset & pitch should be specified. For semi-planar YUV formats, the chroma samples are stored in plane 1 and for fully planar formats, U-samples are stored in plane 1 and V-samples are stored in plane 2. Planes 1 & 2 are specified by the following attributes, which have the same meanings as defined above for plane 0: * EGL_DMA_BUF_PLANE1_FD_EXT * EGL_DMA_BUF_PLANE1_OFFSET_EXT * EGL_DMA_BUF_PLANE1_PITCH_EXT * EGL_DMA_BUF_PLANE2_FD_EXT * EGL_DMA_BUF_PLANE2_OFFSET_EXT * EGL_DMA_BUF_PLANE2_PITCH_EXT In addition to the above required attributes, the application may also provide hints as to how the data should be interpreted by the GL. If any of these hints are not specified, the GL will guess based on the pixel format passed as the EGL_LINUX_DRM_FOURCC_EXT attribute or may fall-back to some default value. Not all GLs will be able to support all combinations of these hints and are free to use whatever settings they choose to achieve the closest possible match. * EGL_YUV_COLOR_SPACE_HINT_EXT: The color-space the data is in. Only relevant for images in a YUV format, ignored when specified for an image in an RGB format. Accepted values are: EGL_ITU_REC601_EXT, EGL_ITU_REC709_EXT & EGL_ITU_REC2020_EXT. * EGL_YUV_CHROMA_HORIZONTAL_SITING_HINT_EXT & EGL_YUV_CHROMA_VERTICAL_SITING_HINT_EXT: Where chroma samples are sited relative to luma samples when the image is in a sub-sampled format. When the image is not using chroma sub-sampling, the luma and chroma samples are assumed to be co-sited. Siting is split into the vertical and horizontal and is in a fixed range. A siting of zero means the first luma sample is taken from the same position in that dimension as the chroma sample. This is best illustrated in the diagram below: (0.5, 0.5) (0.0, 0.5) (0.0, 0.0) + + + + + + + + * + * + x x x x + + + + + + + + + + + + + + + + + + + + * + * + x x x x + + + + + + + + + + + + Luma samples (+), Chroma samples (x) Chrome & Luma samples (*) Note this attribute is ignored for RGB images and non sub-sampled YUV images. Accepted values are: EGL_YUV_CHROMA_SITING_0_EXT (0.0) & EGL_YUV_CHROMA_SITING_0_5_EXT (0.5) * EGL_SAMPLE_RANGE_HINT_EXT: The numerical range of samples. Only relevant for images in a YUV format, ignored when specified for images in an RGB format. Accepted values are: EGL_YUV_FULL_RANGE_EXT (0-256) & EGL_YUV_NARROW_RANGE_EXT (16-235). If eglCreateImageKHR is successful for a EGL_LINUX_DMA_BUF_EXT target, the EGL takes ownership of the file descriptor and is responsible for closing it, which it may do at any time while the EGLDisplay is initialized." Add to the list of error conditions for eglCreateImageKHR: "* If <target> is EGL_LINUX_DMA_BUF_EXT and <buffer> is not NULL, the error EGL_BAD_PARAMETER is generated. * If <target> is EGL_LINUX_DMA_BUF_EXT, and the list of attributes is incomplete, EGL_BAD_PARAMETER is generated. * If <target> is EGL_LINUX_DMA_BUF_EXT, and the EGL_LINUX_DRM_FOURCC_EXT attribute is set to a format not supported by the EGL, EGL_BAD_MATCH is generated. * If <target> is EGL_LINUX_DMA_BUF_EXT, and the EGL_LINUX_DRM_FOURCC_EXT attribute indicates a single-plane format, EGL_BAD_ATTRIBUTE is generated if any of the EGL_DMA_BUF_PLANE1_* or EGL_DMA_BUF_PLANE2_* attributes are specified. * If <target> is EGL_LINUX_DMA_BUF_EXT and the value specified for EGL_YUV_COLOR_SPACE_HINT_EXT is not EGL_ITU_REC601_EXT, EGL_ITU_REC709_EXT or EGL_ITU_REC2020_EXT, EGL_BAD_ATTRIBUTE is generated. * If <target> is EGL_LINUX_DMA_BUF_EXT and the value specified for EGL_SAMPLE_RANGE_HINT_EXT is not EGL_YUV_FULL_RANGE_EXT or EGL_YUV_NARROW_RANGE_EXT, EGL_BAD_ATTRIBUTE is generated. * If <target> is EGL_LINUX_DMA_BUF_EXT and the value specified for EGL_YUV_CHROMA_HORIZONTAL_SITING_HINT_EXT or EGL_YUV_CHROMA_VERTICAL_SITING_HINT_EXT is not EGL_YUV_CHROMA_SITING_0_EXT or EGL_YUV_CHROMA_SITING_0_5_EXT, EGL_BAD_ATTRIBUTE is generated. * If <target> is EGL_LINUX_DMA_BUF_EXT and one or more of the values specified for a plane's pitch or offset isn't supported by EGL, EGL_BAD_ACCESS is generated. * If <target> is EGL_LINUX_DMA_BUF_EXT and eglCreateImageKHR fails, EGL does not retain ownership of the file descriptor and it is the responsibility of the application to close it." Issues 1. Should this be a KHR or EXT extension? ANSWER: EXT. Khronos EGL working group not keen on this extension as it is seen as contradicting the EGLStream direction the specification is going in. The working group recommends creating additional specs to allow an EGLStream producer/consumer connected to v4l2/DRM or any other Linux interface. 2. Should this be a generic any platform extension, or a Linux-only extension which explicitly states the handles are dma_buf fds? ANSWER: There's currently no intention to port this extension to any OS not based on the Linux kernel. Consequently, this spec can be explicitly written against Linux and the dma_buf API. 3. Does ownership of the file descriptor pass to the EGL library? ANSWER: If eglCreateImageKHR is successful, EGL assumes ownership of the file descriptors and is responsible for closing them. 4. How are the different YUV color spaces handled (BT.709/BT.601)? ANSWER: The pixel formats defined in drm_fourcc.h only specify how the data is laid out in memory. It does not define how that data should be interpreted. Added a new EGL_YUV_COLOR_SPACE_HINT_EXT attribute to allow the application to specify which color space the data is in to allow the GL to choose an appropriate set of co-efficients if it needs to convert that data to RGB for example. 5. What chroma-siting is used for sub-sampled YUV formats? ANSWER: The chroma siting is not specified by either the v4l2 or DRM APIs. This is similar to the color-space issue (4) in that the chroma siting doesn't affect how the data is stored in memory. However, the GL will need to know the siting in order to filter the image correctly. While the visual impact of getting the siting wrong is minor, provision should be made to allow an application to specify the siting if desired. Added additional EGL_YUV_CHROMA_HORIZONTAL_SITING_HINT_EXT & EGL_YUV_CHROMA_VERTICAL_SITING_HINT_EXT attributes to allow the siting to be specified using a set of pre-defined values (0 or 0.5). 6. How can an application query which formats the EGL implementation supports? PROPOSAL: Don't provide a query mechanism but instead add an error condition that EGL_BAD_MATCH is raised if the EGL implementation doesn't support that particular format. 7. Which image formats should be supported and how is format specified? Seem to be two options 1) specify a new enum in this specification and enumerate all possible formats. 2) Use an existing enum already in Linux, either v4l2_mbus_pixelcode and/or those formats listed in drm_fourcc.h? ANSWER: Go for option 2) and just use values defined in drm_fourcc.h. 8. How can AYUV images be handled? ANSWER: At least on fourcc.org and in drm_fourcc.h, there only seems to be a single AYUV format and that is a packed format, so everything, including the alpha component would be in the first plane. 9. How can you import interlaced images? ANSWER: Interlaced frames are usually stored with the top & bottom fields interleaved in a single buffer. As the fields would need to be displayed as at different times, the application would create two EGLImages from the same buffer, one for the top field and another for the bottom. Both EGLImages would set the pitch to 2x the buffer width and the second EGLImage would use a suitable offset to indicate it started on the second line of the buffer. This should work regardless of whether the data is packed in a single plane, semi-planar or multi-planar. If each interlaced field is stored in a separate buffer then it should be trivial to create two EGLImages, one for each field's buffer. 10. How are semi-planar/planar formats handled that have a different width/height for Y' and CbCr such as YUV420? ANSWER: The spec says EGL_WIDTH & EGL_HEIGHT specify the *logical* width and height of the buffer in pixels. For pixel formats with sub-sampled Chroma values, it should be trivial for the EGL implementation to calculate the width/height of the Chroma sample buffers using the logical width & height and by inspecting the pixel format passed as the EGL_LINUX_DRM_FOURCC_EXT attribute. I.e. If the pixel format says it's YUV420, the Chroma buffer's width = EGL_WIDTH/2 & height =EGL_HEIGHT/2. 11. How are Bayer formats handled? ANSWER: As of Linux 2.6.34, drm_fourcc.h does not include any Bayer formats. However, future kernel versions may add such formats in which case they would be handled in the same way as any other format. 12. Should the spec support buffers which have samples in a "narrow range"? Content sampled from older analogue sources typically don't use the full (0-256) range of the data type storing the sample and instead use a narrow (16-235) range to allow some headroom & toeroom in the signals to avoid clipping signals which overshoot slightly during processing. This is sometimes known as signals using "studio swing". ANSWER: Add a new attribute to define if the samples use a narrow 16-235 range or the full 0-256 range. 13. Specifying the color space and range seems cumbersome, why not just allow the application to specify the full YUV->RGB color conversion matrix? ANSWER: Some hardware may not be able to use an arbitrary conversion matrix and needs to select an appropriate pre-defined matrix based on the color space and the sample range. 14. How do you handle EGL implementations which have restrictions on pitch and/or offset? ANSWER: Buffers being imported using dma_buf pretty much have to be allocated by a kernel-space driver. As such, it is expected that a system integrator would make sure all devices which allocate buffers suitable for exporting make sure they use a pitch supported by all possible importers. However, it is still possible eglCreateImageKHR can fail due to an unsupported pitch. Added a new error to the list indicating this. 15. Should this specification also describe how to export an existing EGLImage as a dma_buf file descriptor? ANSWER: No. Importing and exporting buffers are two separate operations and importing an existing dma_buf fd into an EGLImage is useful functionality in itself. Agree that exporting an EGLImage as a dma_buf fd is useful, E.g. it could be used by an OpenMAX IL implementation's OMX_UseEGLImage function to give access to the buffer backing an EGLImage to video hardware. However, exporting can be split into a separate extension specification. Revision History #4 (Tom Cooksey, October 04, 2012) - Fixed issue numbering! - Added issues 8 - 15. - Promoted proposal for Issue 3 to be the answer. - Added an additional attribute to allow an application to specify the color space as a hint which should address issue 4. - Added an additional attribute to allow an application to specify the chroma siting as a hint which should address issue 5. - Added an additional attribute to allow an application to specify the sample range as a hint which should address the new issue 12. - Added language to end of error section clarifying who owns the fd passed to eglCreateImageKHR if an error is generated. #3 (Tom Cooksey, August 16, 2012) - Changed name from EGL_EXT_image_external and re-written language to explicitly state this for use with Linux & dma_buf. - Added a list of issues, including some still open ones. #2 (Jesse Barker, May 30, 2012) - Revision to split eglCreateImageKHR functionality from export Functionality. - Update definition of EGLNativeBufferType to be a struct containing a list of handles to support multi-buffer/multi-planar formats. #1 (Jesse Barker, March 20, 2012) - Initial draft.

12 years, 8 months

1
0
0 0

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

by Marek Szyprowski

Hi Linus, I would like to ask for pulling another set of CMA and DMA-mapping framework updates for v3.7. The following changes since commit a0d271cbfed1dd50278c6b06bead3d00ba0a88f9: Linux 3.6 (2012-09-30 16:47:46 -0700) are available in the git repository at: git://git.linaro.org/people/mszyprowski/linux-dma-mapping.git for-v3.7 for you to fetch changes up to 461b6f0d3d7d4e556035463b531136b034b7433e: Merge branch 'next-cleanup' into for-v3.7 (2012-10-02 09:24:24 +0200) ---------------------------------------------------------------- This time the pull request is rather small, because the further redesign patches were not ready on time. This pull request consists of the patches which extend ARM DMA-mapping subsystem with support for CPU coherent (ACP) DMA busses. The first client of the new version is HighBank SATA driver. The second part of the pull request includes various cleanup for both CMA common code and ARM DMA-mapping subsystem. Thanks! Best regards Marek Szyprowski Samsung Poland R&D Center Patch summary: Hiroshi Doyu (3): ARM: dma-mapping: Small logical clean up ARM: dma-mapping: Refrain noisy console message ARM: dma-mapping: Remove unsed var at arm_coherent_iommu_unmap_page Marek Szyprowski (1): Merge branch 'next-cleanup' into for-v3.7 Michal Nazarewicz (1): drivers: dma-contiguous: refactor dma_alloc_from_contiguous() Rob Herring (4): ARM: add coherent dma ops ARM: add coherent iommu dma ops ARM: kill off arch_is_coherent ARM: highbank: add coherent DMA setup .../devicetree/bindings/ata/ahci-platform.txt | 3 + .../devicetree/bindings/dma/arm-pl330.txt | 3 + .../devicetree/bindings/net/calxeda-xgmac.txt | 3 + arch/arm/boot/dts/highbank.dts | 1 + arch/arm/include/asm/barrier.h | 7 +- arch/arm/include/asm/dma-mapping.h | 1 + arch/arm/include/asm/memory.h | 8 - arch/arm/mach-highbank/highbank.c | 52 ++++ arch/arm/mm/dma-mapping.c | 264 +++++++++++++++----- arch/arm/mm/mmu.c | 17 +- drivers/base/dma-contiguous.c | 18 +- 11 files changed, 283 insertions(+), 94 deletions(-)

12 years, 8 months

1
0
0 0

[PATCH] dma-buf: might_sleep() in dma_buf_unmap_attachment()

by Rob Clark

From: Rob Clark <rob(a)ti.com> We never really clarified if unmap could be done in atomic context. But since mapping might require sleeping, this implies mutex in use to synchronize mapping/unmapping, so unmap could sleep as well. Add a might_sleep() to clarify this. Signed-off-by: Rob Clark <rob(a)ti.com> Acked-by: Daniel Vetter <daniel.vetter(a)ffwll.ch> --- drivers/base/dma-buf.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c index c30f3e1..877eacb 100644 --- a/drivers/base/dma-buf.c +++ b/drivers/base/dma-buf.c @@ -298,6 +298,8 @@ void dma_buf_unmap_attachment(struct dma_buf_attachment *attach, struct sg_table *sg_table, enum dma_data_direction direction) { + might_sleep(); + if (WARN_ON(!attach || !attach->dmabuf || !sg_table)) return; -- 1.7.9.5

12 years, 8 months

3
2
0 0

[PATCHv8 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. The importer and exporter part were merged because DMA mapping redesign [3] was scheduled for merge to mainline. 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 (5): 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 media: vb2: fail if user ptr buffer is not correctly aligned v4l: vb2: add support for DMA_ATTR_NO_KERNEL_MAPPING 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 | 3 +- Documentation/DocBook/media/v4l/vidioc-expbuf.xml | 223 ++++++ Documentation/DocBook/media/v4l/vidioc-qbuf.xml | 15 + Documentation/DocBook/media/v4l/vidioc-reqbufs.xml | 47 +- drivers/media/video/Kconfig | 1 + drivers/media/video/atmel-isi.c | 2 +- drivers/media/video/blackfin/bfin_capture.c | 2 +- drivers/media/video/marvell-ccic/mcam-core.c | 3 +- drivers/media/video/mx2_camera.c | 2 +- drivers/media/video/mx2_emmaprp.c | 2 +- drivers/media/video/mx3_camera.c | 2 +- drivers/media/video/s5p-fimc/Kconfig | 1 + drivers/media/video/s5p-fimc/fimc-capture.c | 11 +- drivers/media/video/s5p-fimc/fimc-core.c | 2 +- drivers/media/video/s5p-fimc/fimc-lite.c | 2 +- drivers/media/video/s5p-g2d/g2d.c | 2 +- drivers/media/video/s5p-jpeg/jpeg-core.c | 2 +- drivers/media/video/s5p-mfc/s5p_mfc.c | 5 +- drivers/media/video/s5p-mfc/s5p_mfc_dec.c | 18 + drivers/media/video/s5p-mfc/s5p_mfc_enc.c | 18 + drivers/media/video/s5p-tv/Kconfig | 1 + drivers/media/video/s5p-tv/mixer_video.c | 14 +- drivers/media/video/sh_mobile_ceu_camera.c | 2 +- drivers/media/video/v4l2-compat-ioctl32.c | 19 + drivers/media/video/v4l2-dev.c | 1 + drivers/media/video/v4l2-ioctl.c | 16 + drivers/media/video/videobuf-core.c | 4 + drivers/media/video/videobuf2-core.c | 275 +++++++- drivers/media/video/videobuf2-dma-contig.c | 719 ++++++++++++++++++-- drivers/media/video/videobuf2-memops.c | 40 -- drivers/media/video/videobuf2-vmalloc.c | 56 ++ drivers/media/video/vivi.c | 2 +- drivers/staging/media/dt3155v4l/dt3155v4l.c | 2 +- include/linux/videodev2.h | 33 + include/media/v4l2-ioctl.h | 2 + include/media/videobuf2-core.h | 36 + include/media/videobuf2-dma-contig.h | 4 +- include/media/videobuf2-memops.h | 5 - 41 files changed, 1639 insertions(+), 146 deletions(-) create mode 100644 Documentation/DocBook/media/v4l/vidioc-expbuf.xml -- 1.7.9.5

12 years, 8 months

3
57
0 0

[GIT PULL] DMA-mapping fix for v3.6

by Marek Szyprowski

Hi Linus, I would like to ask for pulling yet another patch for ARM dma-mapping subsystem to Linux v3.6 kernel tree. This patch fixes potential memory leak ARM dma-mapping code. The following changes since commit 979570e02981d4a8fc20b3cc8fd651856c98ee9d: Linux 3.6-rc7 (2012-09-23 18:10:57 -0700) are available in the git repository at: git://git.linaro.org/people/mszyprowski/linux-dma-mapping.git fixes-for-3.6 for you to fetch changes up to ec10665cbf271fb1f60daeb194ad4f2cdcdc59d9: ARM: dma-mapping: Fix potential memory leak in atomic_pool_init() (2012-09-24 08:35:03 +0200) ---------------------------------------------------------------- Sachin Kamat (1): ARM: dma-mapping: Fix potential memory leak in atomic_pool_init() arch/arm/mm/dma-mapping.c | 2 ++ 1 file changed, 2 insertions(+)

12 years, 8 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig