Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

7 participants
3604 discussions

[PATCH] dma-buf: Do a fast lockless check for poll with timeout=0

by Chris Wilson

Currently we install a callback for performing poll on a dma-buf, irrespective of the timeout. This involves taking a spinlock, as well as unnecessary work, and greatly reduces scaling of poll(.timeout=0) across multiple threads. We can query whether the poll will block prior to installing the callback to make the busy-query fast. Single thread: 60% faster 8 threads on 4 (+4 HT) cores: 600% faster Still not quite the perfect scaling we get with a native busy ioctl, but poll(dmabuf) is faster due to the quicker lookup of the object and avoiding drm_ioctl(). Signed-off-by: Chris Wilson <chris(a)chris-wilson.co.uk> Cc: Sumit Semwal <sumit.semwal(a)linaro.org> Cc: linux-media(a)vger.kernel.org Cc: dri-devel(a)lists.freedesktop.org Cc: linaro-mm-sig(a)lists.linaro.org --- drivers/dma-buf/dma-buf.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index cf04d249a6a4..c7a7bc579941 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -156,6 +156,18 @@ static unsigned int dma_buf_poll(struct file *file, poll_table *poll) if (!events) return 0; + if (poll_does_not_wait(poll)) { + if (events & POLLOUT && + !reservation_object_test_signaled_rcu(resv, true)) + events &= ~(POLLOUT | POLLIN); + + if (events & POLLIN && + !reservation_object_test_signaled_rcu(resv, false)) + events &= ~POLLIN; + + return events; + } + retry: seq = read_seqcount_begin(&resv->seq); rcu_read_lock(); -- 2.9.3

10 years, 1 month

[PATCH v2 0/2] doc: dma-buf: sphinx conversion

by Sumit Semwal

Convert dma-buf documentation over to sphinx. While at that, convert dma-buf-sharing.txt as well, and make it the dma-buf API guide. There is no content change yet; only format conversion and creation of some hyperlinks. v2: Address review comments from Jonathan Corbet and Markus Heiser. Sumit Semwal (2): Documentation: move dma-buf documentation to rst Documentation/sphinx: link dma-buf rsts Documentation/DocBook/device-drivers.tmpl | 41 --- Documentation/dma-buf-sharing.txt | 482 ---------------------------- Documentation/dma-buf/guide.rst | 507 ++++++++++++++++++++++++++++++ Documentation/dma-buf/intro.rst | 82 +++++ Documentation/index.rst | 2 + MAINTAINERS | 2 +- 6 files changed, 592 insertions(+), 524 deletions(-) delete mode 100644 Documentation/dma-buf-sharing.txt create mode 100644 Documentation/dma-buf/guide.rst create mode 100644 Documentation/dma-buf/intro.rst -- 2.7.4

10 years, 1 month

[PATCH] dma-buf: fix kernel-doc warning and typos

by Randy Dunlap

From: Randy Dunlap <rdunlap(a)infradead.org> Fix dma-buf kernel-doc warning and 2 minor typos in fence_array_create(). Fixes this warning: ..//drivers/dma-buf/fence-array.c:124: warning: No description found for parameter 'signal_on_any' Signed-off-by: Randy Dunlap <rdunlap(a)infradead.org> Cc: Sumit Semwal <sumit.semwal(a)linaro.org> Cc: linux-media(a)vger.kernel.org Cc: dri-devel(a)lists.freedesktop.org Cc: linaro-mm-sig(a)lists.linaro.org --- drivers/dma-buf/fence-array.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) --- lnx-48-rc2.orig/drivers/dma-buf/fence-array.c +++ lnx-48-rc2/drivers/dma-buf/fence-array.c @@ -106,14 +106,14 @@ const struct fence_ops fence_array_ops = * @fences: [in] array containing the fences * @context: [in] fence context to use * @seqno: [in] sequence number to use - * @signal_on_any [in] signal on any fence in the array + * @signal_on_any: [in] signal on any fence in the array * * Allocate a fence_array object and initialize the base fence with fence_init(). * In case of error it returns NULL. * - * The caller should allocte the fences array with num_fences size + * The caller should allocate the fences array with num_fences size * and fill it with the fences it wants to add to the object. Ownership of this - * array is take and fence_put() is used on each fence on release. + * array is taken and fence_put() is used on each fence on release. * * If @signal_on_any is true the fence array signals if any fence in the array * signals, otherwise it signals when all fences in the array signal.

10 years, 1 month

[RFCv2][PATCH 0/5] Cleanup Ion mapping/caching

by Laura Abbott

Hi, This is v2 on the attempt to remove misuse of the cache APIs from Ion. The previous version[1] attempted to pull the cache APIs into Ion. This was indicated as the wrong approach and real APIs should be created instead. The APIs created are kernel_force_cache_clean and kernel_force_cache_invalidate. They force a clean and invalidate of the cache, respectively. The aim was to take the semantics of dma_sync and turn them into something that isn't dma_sync. This series includes a nominal implementation for arm/arm64, mostly for demonstration purposes. I did review before writing this of whether Ion could just use the DMA mapping APIs to acheive the necessary coherency. The conclusion I came to was that trying to force the Ion code into the DMA model would create more problem than it solved since there wasn't anything like DMA going on. Similarly, none of the existing cache APIs did exactly what was needed either. The closest matches were designed for file cache pages and not drivers. The series includes conversion of Ion to the new APIs. There are a few other drivers which are calling either arch specific APIs or flush_dcache_page that could be converted as well. The i915 driver could potentially be converted with the addition of an x86 implementation. Feedback appreciated as always. Thanks, Laura [1] https://lkml.kernel.org/g/<1464205684-5587-1-git-send-email-labbott(a)redhat.com> Laura Abbott (5): Documentation: Introduce kernel_force_cache_* APIs arm: Implement ARCH_HAS_FORCE_CACHE arm64: Implement ARCH_HAS_FORCE_CACHE staging: android: ion: Convert to the kernel_force_cache APIs staging: ion: Add support for syncing with DMA_BUF_IOCTL_SYNC Documentation/cachetlb.txt | 18 +++- arch/arm/include/asm/cacheflush.h | 4 + arch/arm/mm/dma-mapping.c | 119 ------------------------ arch/arm/mm/flush.c | 115 +++++++++++++++++++++++ arch/arm/mm/mm.h | 8 ++ arch/arm64/include/asm/cacheflush.h | 5 + arch/arm64/mm/flush.c | 11 +++ drivers/staging/android/ion/ion.c | 53 +++++++---- drivers/staging/android/ion/ion_carveout_heap.c | 8 +- drivers/staging/android/ion/ion_chunk_heap.c | 12 ++- drivers/staging/android/ion/ion_page_pool.c | 6 +- drivers/staging/android/ion/ion_priv.h | 11 --- drivers/staging/android/ion/ion_system_heap.c | 6 +- include/linux/cacheflush.h | 11 +++ 14 files changed, 225 insertions(+), 162 deletions(-) create mode 100644 include/linux/cacheflush.h -- 2.7.4

10 years, 1 month

[RESEND][PATCH 0/5] Ion cleanup

by Laura Abbott

I never saw any feedback or action on these patches so this is a resend. Probably hit the window when everyone was busy/traveling. --- Hi, This is some clean up of old Ion interfaces and APIs. These are interfaces that mostly existed before dma_buf was well integrated into the kernel along with reservations for board files. If there are objections to deletion I expect it to turn into a discussion about what other APIs need to be extended. Thanks, Laura Laura Abbott (5): staging: android: ion: Get rid of ion_sg_table staging: android: ion: Drop ion_phys interface staging: android: ion: Get rid of map_dma/unmap_dma staging: android: ion: Drop ion_carveout_allocate definitions staging: android: ion: Get rid of ion_reserve drivers/staging/android/ion/ion.c | 103 ++---------------------- drivers/staging/android/ion/ion.h | 41 ---------- drivers/staging/android/ion/ion_carveout_heap.c | 33 +------- drivers/staging/android/ion/ion_chunk_heap.c | 17 +--- drivers/staging/android/ion/ion_cma_heap.c | 34 +------- drivers/staging/android/ion/ion_priv.h | 30 +------ drivers/staging/android/ion/ion_system_heap.c | 44 +--------- 7 files changed, 19 insertions(+), 283 deletions(-) -- 2.5.5

10 years, 1 month

[RFC 0/4] doc: dma-buf: sphinx conversion and cleanup

by Sumit Semwal

Convert dma-buf documentation over to sphinx; also cleanup to address sphinx warnings. While at that, convert dma-buf-sharing.txt as well, and make it the dma-buf API guide. There is no content change yet; only format conversion and creation of some hyperlinks. Sumit Semwal (4): dma-buf/fence: kerneldoc: remove unused struct members dma-buf/fence: kerneldoc: remove spurious section header Documentation: move dma-buf documentation to rst Documentation/sphinx: link dma-buf rsts Documentation/DocBook/device-drivers.tmpl | 37 --- Documentation/dma-buf/guide.rst | 503 ++++++++++++++++++++++++++++++ Documentation/dma-buf/intro.rst | 76 +++++ Documentation/index.rst | 2 + MAINTAINERS | 2 +- include/linux/fence.h | 4 +- 6 files changed, 583 insertions(+), 41 deletions(-) create mode 100644 Documentation/dma-buf/guide.rst create mode 100644 Documentation/dma-buf/intro.rst -- 2.7.4

10 years, 1 month

[RFC 0/4] doc: dma-buf: sphinx conversion and cleanup

by Sumit Semwal

10 years, 1 month

Re: [Linaro-mm-sig] [RFCv2][PATCH 2/5] arm: Implement ARCH_HAS_FORCE_CACHE

by Laura Abbott

On 08/09/2016 02:56 PM, Florian Fainelli wrote: > On 08/08/2016 10:49 AM, Laura Abbott wrote: >> arm may need the kernel_force_cache APIs to guarantee data consistency. >> Implement versions of these APIs based on the DMA APIs. >> >> Signed-off-by: Laura Abbott <labbott(a)redhat.com> >> --- >> arch/arm/include/asm/cacheflush.h | 4 ++ >> arch/arm/mm/dma-mapping.c | 119 -------------------------------------- >> arch/arm/mm/flush.c | 115 ++++++++++++++++++++++++++++++++++++ > > Why is the code moved between dma-mapping.c and flush.c? It was not > obvious while looking at these patches why this is needed. > I wanted to use the cache flushing routines from dma-mapping.c and it seemed better to pull them out vs. trying to put more generic cache flushing code in dma-mapping.c. flush.c seemed like an appropriate place although I forgot about the dependency on CONFIG_MMU. It can certainly remain in dma-mapping.c if deemed appropriate. Thanks, Laura

10 years, 1 month

[PATCH v8 0/4] Generic zpos property

by Benjamin Gaignard

version 8: move drm_blend.o from drm-y to drm_kms_helper-y to avoid EXPORT_SYMBOL(drm_atomic_helper_normalize_zpos) remove dead function declarations in drm_crtc.h rebased code on drm-next + merge of git://linuxtv.org/media_tree.git vsp1 branch. version 7: remove useless EXPORT_SYMBOL() better z-order wording in Documentation rebased code on drm-next + merge of git://linuxtv.org/media_tree.git vsp1 branch. vsp1 branch might be merged into 4.8-rc1 so conflits between rcar-du and zpos patches should be avoid in this version 7. version 6: add zpos in Documentation/gpu/kms-properties.csv merge Ville's patch (splitted between all the commits) it simplify the API and fix bug. Thanks version 5: rebased on drm-next where Documentation/DocBook/gpu.tmpl doesn't exist anymore. rework sti patch because some plane functions have changed since v4 version 4: make sure that normalized zpos value is stay in the defined property range and warn user if not. Fix NULL pointer bug in rcar-du while setting zpos value. No changes in the other drivers. version 3: use kmalloc_array instead of kmalloc. Correct normalize_zpos computation (comeback to Mareck original code) version 2: add a zpos property into drm_plane structure to simplify code. This allow to get/set zpos value in core and not in drivers code. Fix various remarks. version 1: refactor Marek's patches to have per plane zpos property instead of only one in core. Benjamin Gaignard (2): drm: sti: use generic zpos for plane drm: rcar: use generic code for managing zpos plane property Marek Szyprowski (2): drm: add generic zpos property drm/exynos: use generic code for managing zpos plane property Documentation/gpu/kms-properties.csv | 1 + drivers/gpu/drm/Makefile | 2 +- drivers/gpu/drm/drm_atomic.c | 4 + drivers/gpu/drm/drm_atomic_helper.c | 7 + drivers/gpu/drm/drm_blend.c | 238 ++++++++++++++++++++++++++++++ drivers/gpu/drm/drm_crtc_internal.h | 4 + drivers/gpu/drm/exynos/exynos_drm_drv.h | 2 - drivers/gpu/drm/exynos/exynos_drm_plane.c | 67 ++------- drivers/gpu/drm/exynos/exynos_mixer.c | 6 +- drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 2 +- drivers/gpu/drm/rcar-du/rcar_du_drv.h | 1 - drivers/gpu/drm/rcar-du/rcar_du_kms.c | 5 - drivers/gpu/drm/rcar-du/rcar_du_plane.c | 9 +- drivers/gpu/drm/rcar-du/rcar_du_plane.h | 2 - drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 14 +- drivers/gpu/drm/sti/sti_cursor.c | 4 +- drivers/gpu/drm/sti/sti_gdp.c | 4 +- drivers/gpu/drm/sti/sti_hqvdp.c | 4 +- drivers/gpu/drm/sti/sti_mixer.c | 9 +- drivers/gpu/drm/sti/sti_plane.c | 78 ++++------ drivers/gpu/drm/sti/sti_plane.h | 7 +- include/drm/drm_crtc.h | 20 +++ 22 files changed, 334 insertions(+), 156 deletions(-) create mode 100644 drivers/gpu/drm/drm_blend.c -- 1.9.1

10 years, 2 months

Re: [Linaro-mm-sig] [PATCH v7 1/4] drm: add generic zpos property

by Benjamin Gaignard

2016-07-28 14:55 GMT+02:00 Emil Velikov <emil.l.velikov(a)gmail.com>: > Hi Benjamin, > > Just spotted a couple of small bits which, imho, should be fine with > squashing with follow up patch(es). > > On 28 July 2016 at 09:07, Benjamin Gaignard > <benjamin.gaignard(a)linaro.org> wrote: > >> +EXPORT_SYMBOL(drm_atomic_helper_normalize_zpos); > The symbols is internal only thus the EXPORT_SYMBOL notation isn't needed. > Rule of thumb - interfaces used by other modules are declared in > include/drm and the symbol(s) should be annotated with EXPORT_SYMBOL* > drm_blend.c is linked into drm.o while drm_atomic_helper_normalize_zpos is used in drm_atomic_helper.c linked within drm_kms_helper.o so EXPORT_SYMBOL is need either I got linked error while compiling drm as a module >> + >> +int drm_plane_atomic_set_zpos_property(struct drm_plane *plane, >> + struct drm_plane_state *state, >> + struct drm_property *property, >> + uint64_t val); >> + >> +int drm_plane_atomic_get_zpos_property(struct drm_plane *plane, >> + const struct drm_plane_state *state, >> + struct drm_property *property, >> + uint64_t *val); >> + > Dead code/declarations ? > yes dead code, I will remove it. > Cheers, > Emil Thanks, Benjamin -- Benjamin Gaignard Graphic Study Group Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog

10 years, 2 months

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig