Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

1 participants
2905 discussions

[PATCH v2 0/5] reserved-memory regions/CMA in devicetree, again

by Marek Szyprowski

Hi all! This is an updated version of the second attempt to add basic support for dynamic allocation of memory reserved regions defined in device tree. The initial code for this feature were posted here [1], merged as commit 9d8eab7af79cb4ce2de5de39f82c455b1f796963 ("drivers: of: add initialization code for dma reserved memory") and later reverted by commit 1931ee143b0ab72924944bc06e363d837ba05063. For more information, see [2]. Finally a new bindings has been proposed [3] and Josh Cartwright a few days ago prepared some code which implements those bindings [4]. This finally pushed me again to find some time to finish this task and review the code. Josh agreed to give me the ownership of this series to continue preparing them for mainline inclusion. For more information please refer to the changlelog below. [1]: http://lkml.kernel.org/g/1377527959-5080-1-git-send-email-m.szyprowski@sams… [2]: http://lkml.kernel.org/g/1381476448-14548-1-git-send-email-m.szyprowski@sam… [3]: http://lkml.kernel.org/g/20131030134702.19B57C402A0@trevor.secretlab.ca [4]: http://thread.gmane.org/gmane.linux.documentation/19579 Changelog: v2: - removed copying of the node name - split shared-dma-pool handling into separate files (one for CMA and one for dma_declare_coherent based implementations) for making the code easier to understand - added support for AMBA devices, changed prototypes to use struct decice instead of struct platform_device - renamed some functions to better match other names used in drivers/of/ - restructured the rest of the code a bit for better readability - added 'reusable' property to exmaple linux,cma node in documentation - exclusive dma (dma_coherent) is used for only handling 'shared-dma-pool' regions without 'reusable' property and CMA is used only for handling 'shared-dma-pool' regions with 'reusable' property. v1: http://thread.gmane.org/gmane.linux.documentation/19579 - initial version prepared by Josh Cartwright Summary: Grant Likely (1): of: document bindings for reserved-memory nodes Josh Cartwright (2): drivers: of: implement reserved-memory handling for dma drivers: of: implement reserved-memory handling for cma Marek Szyprowski (2): drivers: of: add initialization code for reserved memory ARM: init: add support for reserved memory defined by device tree .../bindings/reserved-memory/reserved-memory.txt | 138 ++++++++++++ arch/arm/mm/init.c | 3 + drivers/of/Kconfig | 20 ++ drivers/of/Makefile | 3 + drivers/of/of_reserved_mem.c | 219 ++++++++++++++++++++ drivers/of/of_reserved_mem_cma.c | 75 +++++++ drivers/of/of_reserved_mem_dma.c | 78 +++++++ drivers/of/platform.c | 7 + include/asm-generic/vmlinux.lds.h | 11 + include/linux/of_reserved_mem.h | 62 ++++++ 10 files changed, 616 insertions(+) create mode 100644 Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt create mode 100644 drivers/of/of_reserved_mem.c create mode 100644 drivers/of/of_reserved_mem_cma.c create mode 100644 drivers/of/of_reserved_mem_dma.c create mode 100644 include/linux/of_reserved_mem.h -- 1.7.9.5

11 years, 4 months

[GIT PULL]: dma-buf updates for 3.14

by Sumit Semwal

Hi Linus, Here's another tiny pull request for dma-buf framework updates; just some debugfs output updates. (There's another patch related to dma-buf, but it'll get upstreamed via Greg-kh's pull request). Could you please pull? The following changes since commit 45f7fdc2ffb9d5af4dab593843e89da70d1259e3: Merge branch 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc (2014-02-11 22:28:47 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/sumits/dma-buf.git tags/dma-buf-for-3.14 for you to fetch changes up to c0b00a525c127d0055c1df6283300e17f601a1a1: dma-buf: update debugfs output (2014-02-13 10:08:52 +0530) ---------------------------------------------------------------- Small dma-buf pull request for 3.14 ---------------------------------------------------------------- Sumit Semwal (1): dma-buf: update debugfs output drivers/base/dma-buf.c | 25 ++++++++++++------------- include/linux/dma-buf.h | 2 +- 2 files changed, 13 insertions(+), 14 deletions(-)

11 years, 4 months

KSM and Android

by Pradeep Sawlani

Hello, In pursuit of saving memory on Android, I started experimenting with Kernel Same Page Merging(KSM). Number of pages shared because of KSM is reported by /sys/kernel/mm/pages_sharing. Documentation/vm/ksm.txt explains this as: "pages_sharing - how many more sites are sharing them i.e. how much saved" After enabling KSM on Android device, this number was reported as 19666 pages. Obvious optimization is to find out source of sharing and see if we can avoid duplicate pages at first place. In order to collect the data needed, It needed few modifications(trace_printk) statement in mm/ksm.c. Data should be collected from second cycle because that's when ksm starts merging pages. First KSM cycle is only used to calculate the checksum, pages are added to unstable tree and eventually moved to stable tree after this. After analyzing data from second KSM cycle, few things which stood out: 1. In the same cycle, KSM can scan same page multiple times. Scanning a page involves comparing page with pages in stable tree, if no match is found checksum is calculated. From the look of it, it seems to be cpu intensive operation and impacts dcache as well. 2. Same page which is already shared by multiple process can be replaced by KSM page. In this case, let say a particular page is mapped 24 times and is replaced by KSM page then eventually all 24 entries will point to KSM page. pages_sharing will account for all 24 pages. so pages _sharing does not actually report amount of memory saved.From the above example actual savings is one page. Both cases happen very often with Android because of its architecture - Zygote spawning(fork) multipleapplications. To calculate actual savings, we should account for same page(pfn)replaced by same KSM page only once. In the case 2 example, page_sharing should account only one page.After recalculating memory saving comes out to be 8602 pages (~34MB). I am trying to find out right solution to fix pages_sharing and eventually optimize KSM to scan pageonce even if it is mapped multiple times. Comments? Has anyone tried this before? Thanks, Pradeep

11 years, 4 months

[PATCH] dma-buf: avoid using IS_ERR_OR_NULL

by Colin Cross

dma_buf_map_attachment and dma_buf_vmap can return NULL or ERR_PTR on a error. This encourages a common buggy pattern in callers: sgt = dma_buf_map_attachment(attach, DMA_BIDIRECTIONAL); if (IS_ERR_OR_NULL(sgt)) return PTR_ERR(sgt); This causes the caller to return 0 on an error. IS_ERR_OR_NULL is almost always a sign of poorly-defined error handling. This patch converts dma_buf_map_attachment to always return ERR_PTR, and fixes the callers that incorrectly handled NULL. There are a few more callers that were not checking for NULL at all, which would have dereferenced a NULL pointer later. There are also a few more callers that correctly handled NULL and ERR_PTR differently, I left those alone but they could also be modified to delete the NULL check. This patch also converts dma_buf_vmap to always return NULL. All the callers to dma_buf_vmap only check for NULL, and would have dereferenced an ERR_PTR and panic'd if one was ever returned. This is not consistent with the rest of the dma buf APIs, but matches the expectations of all of the callers. Signed-off-by: Colin Cross <ccross(a)android.com> --- drivers/base/dma-buf.c | 18 +++++++++++------- drivers/gpu/drm/drm_prime.c | 2 +- drivers/gpu/drm/exynos/exynos_drm_dmabuf.c | 2 +- drivers/media/v4l2-core/videobuf2-dma-contig.c | 2 +- 4 files changed, 14 insertions(+), 10 deletions(-) diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c index 1e16cbd61da2..cfe1d8bc7bb8 100644 --- a/drivers/base/dma-buf.c +++ b/drivers/base/dma-buf.c @@ -251,9 +251,8 @@ EXPORT_SYMBOL_GPL(dma_buf_put); * @dmabuf: [in] buffer to attach device to. * @dev: [in] device to be attached. * - * Returns struct dma_buf_attachment * for this attachment; may return negative - * error codes. - * + * Returns struct dma_buf_attachment * for this attachment; returns ERR_PTR on + * error. */ struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf, struct device *dev) @@ -319,9 +318,8 @@ EXPORT_SYMBOL_GPL(dma_buf_detach); * @attach: [in] attachment whose scatterlist is to be returned * @direction: [in] direction of DMA transfer * - * Returns sg_table containing the scatterlist to be returned; may return NULL - * or ERR_PTR. - * + * Returns sg_table containing the scatterlist to be returned; returns ERR_PTR + * on error. */ struct sg_table *dma_buf_map_attachment(struct dma_buf_attachment *attach, enum dma_data_direction direction) @@ -334,6 +332,8 @@ struct sg_table *dma_buf_map_attachment(struct dma_buf_attachment *attach, return ERR_PTR(-EINVAL); sg_table = attach->dmabuf->ops->map_dma_buf(attach, direction); + if (!sg_table) + sg_table = ERR_PTR(-ENOMEM); return sg_table; } @@ -544,6 +544,8 @@ EXPORT_SYMBOL_GPL(dma_buf_mmap); * These calls are optional in drivers. The intended use for them * is for mapping objects linear in kernel space for high use objects. * Please attempt to use kmap/kunmap before thinking about these interfaces. + * + * Returns NULL on error. */ void *dma_buf_vmap(struct dma_buf *dmabuf) { @@ -566,7 +568,9 @@ void *dma_buf_vmap(struct dma_buf *dmabuf) BUG_ON(dmabuf->vmap_ptr); ptr = dmabuf->ops->vmap(dmabuf); - if (IS_ERR_OR_NULL(ptr)) + if (WARN_ON_ONCE(IS_ERR(ptr))) + ptr = NULL; + if (!ptr) goto out_unlock; dmabuf->vmap_ptr = ptr; diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c index 56805c39c906..bb516fdd195d 100644 --- a/drivers/gpu/drm/drm_prime.c +++ b/drivers/gpu/drm/drm_prime.c @@ -471,7 +471,7 @@ struct drm_gem_object *drm_gem_prime_import(struct drm_device *dev, get_dma_buf(dma_buf); sgt = dma_buf_map_attachment(attach, DMA_BIDIRECTIONAL); - if (IS_ERR_OR_NULL(sgt)) { + if (IS_ERR(sgt)) { ret = PTR_ERR(sgt); goto fail_detach; } diff --git a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c index 59827cc5e770..c786cd4f457b 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c +++ b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c @@ -224,7 +224,7 @@ struct drm_gem_object *exynos_dmabuf_prime_import(struct drm_device *drm_dev, get_dma_buf(dma_buf); sgt = dma_buf_map_attachment(attach, DMA_BIDIRECTIONAL); - if (IS_ERR_OR_NULL(sgt)) { + if (IS_ERR(sgt)) { ret = PTR_ERR(sgt); goto err_buf_detach; } diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c b/drivers/media/v4l2-core/videobuf2-dma-contig.c index 33d3871d1e13..880be0782dd9 100644 --- a/drivers/media/v4l2-core/videobuf2-dma-contig.c +++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c @@ -719,7 +719,7 @@ static int vb2_dc_map_dmabuf(void *mem_priv) /* get the associated scatterlist for this buffer */ sgt = dma_buf_map_attachment(buf->db_attach, buf->dma_dir); - if (IS_ERR_OR_NULL(sgt)) { + if (IS_ERR(sgt)) { pr_err("Error getting dmabuf scatterlist\n"); return -EINVAL; } -- 1.8.5.1

11 years, 4 months

IOMMU DMA-mapping API for arm64 ?

by Ritesh Harjani

Hi everyone, I tried looking for IOMMU support in ARM64 but what I was able to see is only swiotlb is currently supported. Based on my understanding for IOMMU support, we need DMA-MAPPING API to have IOMMU ops field, similar to what is present in arm32. I could see the iommu field added in dev_archdata in below mentioned patch (arch/arm64/include/asm/device.h), but there is no ops field in arch/arm64/mm/dma-mapping.c ? I also saw one mail discussion between you guys on what is the best place for adding iommu support in ARM64, but couldn't see any followed up patches for the same. Please tell us the current status/updates on the same. Your feedback will be greatly appreciated. commit 73150c983ac1f9b7653cfd3823b1ad4a44aad3bf Author: Will Deacon <will.deacon(a)arm.com> Date: Mon Jun 10 19:34:42 2013 +0100 arm64: device: add iommu pointer to device archdata When using an IOMMU for device mappings, it is necessary to keep a pointer between the device and the IOMMU to which it is attached in order to obtain the correct IOMMU when attaching the device to a domain. This patch adds an iommu pointer to the dev_archdata structure, in a similar manner to other architectures (ARM, PowerPC, x86, ...). Signed-off-by: Will Deacon <will.deacon(a)arm.com> Signed-off-by: Catalin Marinas <catalin.marinas(a)arm.com> Thanks Ritesh

11 years, 4 months

[PATCH] dma-buf: update debugfs output

by Sumit Semwal

Russell King observed 'wierd' looking output from debugfs, and also suggested better ways of getting device names (use KBUILD_MODNAME, dev_name()) This patch addresses these issues to make the debugfs output correct and better looking. Signed-off-by: Sumit Semwal <sumit.semwal(a)linaro.org> --- drivers/base/dma-buf.c | 18 ++++++++---------- include/linux/dma-buf.h | 2 +- 2 files changed, 9 insertions(+), 11 deletions(-) diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c index cfe1d8b..bf89fe3 100644 --- a/drivers/base/dma-buf.c +++ b/drivers/base/dma-buf.c @@ -621,7 +621,7 @@ static int dma_buf_describe(struct seq_file *s) return ret; seq_printf(s, "\nDma-buf Objects:\n"); - seq_printf(s, "\texp_name\tsize\tflags\tmode\tcount\n"); + seq_printf(s, "size\tflags\tmode\tcount\texp_name\n"); list_for_each_entry(buf_obj, &db_list.head, list_node) { ret = mutex_lock_interruptible(&buf_obj->lock); @@ -632,24 +632,22 @@ static int dma_buf_describe(struct seq_file *s) continue; } - seq_printf(s, "\t"); - - seq_printf(s, "\t%s\t%08zu\t%08x\t%08x\t%08ld\n", - buf_obj->exp_name, buf_obj->size, + seq_printf(s, "%08zu\t%08x\t%08x\t%08ld\t%s\n", + buf_obj->size, buf_obj->file->f_flags, buf_obj->file->f_mode, - (long)(buf_obj->file->f_count.counter)); + (long)(buf_obj->file->f_count.counter), buf_obj->exp_name); - seq_printf(s, "\t\tAttached Devices:\n"); + seq_printf(s, "\tAttached Devices:\n"); attach_count = 0; list_for_each_entry(attach_obj, &buf_obj->attachments, node) { - seq_printf(s, "\t\t"); + seq_printf(s, "\t"); - seq_printf(s, "%s\n", attach_obj->dev->init_name); + seq_printf(s, "%s\n", dev_name(attach_obj->dev)); attach_count++; } - seq_printf(s, "\n\t\tTotal %d devices attached\n", + seq_printf(s, "\nTotal %d devices attached\n", attach_count); count++; diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h index dfac5ed..f886985 100644 --- a/include/linux/dma-buf.h +++ b/include/linux/dma-buf.h @@ -171,7 +171,7 @@ struct dma_buf *dma_buf_export_named(void *priv, const struct dma_buf_ops *ops, size_t size, int flags, const char *); #define dma_buf_export(priv, ops, size, flags) \ - dma_buf_export_named(priv, ops, size, flags, __FILE__) + dma_buf_export_named(priv, ops, size, flags, KBUILD_MODNAME) int dma_buf_fd(struct dma_buf *dmabuf, int flags); struct dma_buf *dma_buf_get(int fd); -- 1.8.3.2

11 years, 4 months

[PATCH 0/7] dma-buf synchronization patches

by Maarten Lankhorst

The following series implements fence and converts dma-buf and android sync to use it. Patch 6 and 7 add support for polling to dma-buf, blocking until all fences are signaled. --- Maarten Lankhorst (7): sched: allow try_to_wake_up to be used internally outside of core.c fence: dma-buf cross-device synchronization (v16) seqno-fence: Hardware dma-buf implementation of fencing (v4) dma-buf: use reservation objects android: convert sync to fence api, v3 reservation: add support for fences to enable cross-device synchronisation dma-buf: add poll support Documentation/DocBook/device-drivers.tmpl | 3 drivers/base/Kconfig | 9 drivers/base/Makefile | 2 drivers/base/dma-buf.c | 124 +++ drivers/base/fence.c | 465 ++++++++++++ drivers/gpu/drm/drm_prime.c | 8 drivers/gpu/drm/exynos/exynos_drm_dmabuf.c | 2 drivers/gpu/drm/i915/i915_gem_dmabuf.c | 2 drivers/gpu/drm/nouveau/nouveau_drm.c | 1 drivers/gpu/drm/nouveau/nouveau_gem.h | 1 drivers/gpu/drm/nouveau/nouveau_prime.c | 7 drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 2 drivers/gpu/drm/radeon/radeon_drv.c | 2 drivers/gpu/drm/radeon/radeon_prime.c | 8 drivers/gpu/drm/ttm/ttm_object.c | 2 drivers/media/v4l2-core/videobuf2-dma-contig.c | 2 drivers/staging/android/Kconfig | 1 drivers/staging/android/Makefile | 2 drivers/staging/android/sw_sync.c | 4 drivers/staging/android/sync.c | 895 ++++++++---------------- drivers/staging/android/sync.h | 85 +- drivers/staging/android/sync_debug.c | 245 +++++++ drivers/staging/android/trace/sync.h | 12 include/drm/drmP.h | 2 include/linux/dma-buf.h | 21 - include/linux/fence.h | 329 +++++++++ include/linux/reservation.h | 18 include/linux/seqno-fence.h | 109 +++ include/linux/wait.h | 1 include/trace/events/fence.h | 125 +++ kernel/sched/core.c | 2 31 files changed, 1825 insertions(+), 666 deletions(-) create mode 100644 drivers/base/fence.c create mode 100644 drivers/staging/android/sync_debug.c create mode 100644 include/linux/fence.h create mode 100644 include/linux/seqno-fence.h create mode 100644 include/trace/events/fence.h -- Signature

11 years, 5 months

[RFC] dma-mapping: Provide write-combine allocations

by Thierry Reding

Provide an implementation for dma_{alloc,free}_writecombine() when the architecture supports DMA attributes. Signed-off-by: Thierry Reding <treding(a)nvidia.com> --- arch/arm/include/asm/dma-mapping.h | 16 ---------------- include/linux/dma-mapping.h | 16 ++++++++++++++++ 2 files changed, 16 insertions(+), 16 deletions(-) diff --git a/arch/arm/include/asm/dma-mapping.h b/arch/arm/include/asm/dma-mapping.h index e701a4d9aa59..96b7634a7edc 100644 --- a/arch/arm/include/asm/dma-mapping.h +++ b/arch/arm/include/asm/dma-mapping.h @@ -242,22 +242,6 @@ extern int arm_dma_mmap(struct device *dev, struct vm_area_struct *vma, void *cpu_addr, dma_addr_t dma_addr, size_t size, struct dma_attrs *attrs); -static inline void *dma_alloc_writecombine(struct device *dev, size_t size, - dma_addr_t *dma_handle, gfp_t flag) -{ - DEFINE_DMA_ATTRS(attrs); - dma_set_attr(DMA_ATTR_WRITE_COMBINE, &attrs); - return dma_alloc_attrs(dev, size, dma_handle, flag, &attrs); -} - -static inline void dma_free_writecombine(struct device *dev, size_t size, - void *cpu_addr, dma_addr_t dma_handle) -{ - DEFINE_DMA_ATTRS(attrs); - dma_set_attr(DMA_ATTR_WRITE_COMBINE, &attrs); - return dma_free_attrs(dev, size, cpu_addr, dma_handle, &attrs); -} - /* * This can be called during early boot to increase the size of the atomic * coherent DMA pool above the default value of 256KiB. It must be called diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h index fd4aee29ad10..8475e02b4bd1 100644 --- a/include/linux/dma-mapping.h +++ b/include/linux/dma-mapping.h @@ -249,6 +249,22 @@ struct dma_attrs; #define dma_unmap_sg_attrs(dev, sgl, nents, dir, attrs) \ dma_unmap_sg(dev, sgl, nents, dir) +#else +static inline void *dma_alloc_writecombine(struct device *dev, size_t size, + dma_addr_t *dma_addr, gfp_t gfp) +{ + DEFINE_DMA_ATTRS(attrs); + dma_set_attr(DMA_ATTR_WRITE_COMBINE, &attrs); + return dma_alloc_attrs(dev, size, dma_addr, gfp, &attrs); +} + +static inline void dma_free_writecombine(struct device *dev, size_t size, + void *cpu_addr, dma_addr_t dma_addr) +{ + DEFINE_DMA_ATTRS(attrs); + dma_set_attr(DMA_ATTR_WRITE_COMBINE, &attrs); + return dma_free_attrs(dev, size, cpu_addr, dma_addr, &attrs); +} #endif /* CONFIG_HAVE_DMA_ATTRS */ #ifdef CONFIG_NEED_DMA_MAP_STATE -- 1.8.4.2

11 years, 5 months

[PATCH v4 0/3] Add support of dmabuf in wayland/weston

by benjamin.gaignard＠linaro.org

From: Benjamin Gaignard <benjamin.gaignard(a)linaro.org> The goal of this serie of patches is to add a way to use dmabuf file descriptor inside wayland and weston. In a context where there is no Mesa EGL (and so no wl_drm protocol) wl_dmabuf could be used as an alternative to shm to share buffers between hardware devices. If your hardware device (video decoder, renderer, etc...) need physical contiguous memory (obviously don't have MMU) wl_dmabuf may save the cost of one copy compare to shm. shm case: videodecoder --(copy into shm_buffer)--> weston(+pixman) --> HW renderer dmabuf case: videodecoder --(directly write in dmabuf buffer)--> weston(+pixman) --> HW renderer The server is responsible to send its supported pixel formats and the device name to be used by the client to allocate buffers. While mmap() call on dmabuf file descriptor result isn't guaranty on all architectures both server and client should take care of it before accessing to buffer data to avoid segfault. This series of patches include wayland and weston modifications. An example of how use wl_dmabuf is provided in weston/clients/simple-dmabuf.c === Wayland === Benjamin Gaignard (1): Add wl_dmabuf protocol protocol/Makefile.am | 6 +- protocol/wayland-dmabuf.xml | 128 ++++++++++++++++++++++++ src/Makefile.am | 12 ++- src/wayland-dmabuf.c | 231 +++++++++++++++++++++++++++++++++++++++++++ src/wayland-dmabuf.h | 123 +++++++++++++++++++++++ 5 files changed, 496 insertions(+), 4 deletions(-) create mode 100644 protocol/wayland-dmabuf.xml create mode 100644 src/wayland-dmabuf.c create mode 100644 src/wayland-dmabuf.h === Weston === Benjamin Gaignard (2): compositor-drm: allow to be a wl_dmabuf server add simple-dmabuf client clients/Makefile.am | 11 ++ clients/simple-dmabuf.c | 469 +++++++++++++++++++++++++++++++++++++++++++++++ configure.ac | 5 + src/compositor-drm.c | 83 ++++++++- src/compositor.c | 4 +- src/compositor.h | 2 + src/pixman-renderer.c | 93 +++++++--- 7 files changed, 637 insertions(+), 30 deletions(-) create mode 100644 clients/simple-dmabuf.c -- 1.7.9.5

11 years, 5 months

Specifying subrect properties in dma-buf

by Sundareson, Prabindh

Hello all, I have an use-case, where a buffer "B" needs to be further operated upon by an additional operator (ex, CPU or 2D HW). The further operation is typically in smaller subrects of "B". While looking through the dma-buf API, I do not see a way by which I can specify properties of subrects in a buffer which can be specified as "read-only" to one user of the buffer, while the other user can go ahead and update it. If we have this mechanism, we can do below steps to reduce latency of locking/waiting for one full buffer update, and then making it available to the next consumer. (1) Create dma-buf using usual methods (2) Exported to 2 users - ex GPU, and 2D HW (3) GPU updates specific subrects (4) 2D HW updates specific subrects (5) When both (3) and (4) are complete, the buffer is available to next consumer. Since (3) and (4) can run in parallel, latency can be reduced. If there is a way by which this can already be done, I would appreciate if someone can point me to it. regards Prabindh

11 years, 5 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig