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
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
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
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.
=== Wayland ===
Benjamin Gaignard (1):
Add wl_dmabuf protocol
protocol/Makefile.am | 6 +-
protocol/wayland-dmabuf.xml | 133 +++++++++++++++++++++
src/Makefile.am | 12 +-
src/wayland-dmabuf.c | 279 +++++++++++++++++++++++++++++++++++++++++++
src/wayland-dmabuf.h | 136 +++++++++++++++++++++
5 files changed, 562 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 (1):
compositor-drm: allow to be a wl_dmabuf server
src/compositor-drm.c | 168 +++++++++++++++++++++++++++++++++++++++++++++++--
src/compositor.c | 4 +-
src/compositor.h | 2 +
src/pixman-renderer.c | 86 ++++++++++++++++++-------
4 files changed, 230 insertions(+), 30 deletions(-)
--
1.7.9.5
Hi all,
I'm working for Linaro on enabling a zero copy path in GStreamer by
using dmabuf.
To make this possible I have patched gst wayland sink to use wayland
drm protocol: https://bugzilla.gnome.org/show_bug.cgi?id=711155
Today wayland drm protocol is limited to Mesa so I have decided to
move it into wayland-core.
My hardware doesn't have gpu support yet so I have patched weston
(pixman) to allow usage of wl_drm buffers.
With this I able to share/use a buffer allocated by DRM in gstreamer
pipeline even if I don't have gpu and EGL.
What do you think about make wayland drm protocol available like this ?
Please note those patches are for wayland/weston 1.1.0
Regards,
Benjamin
--
Benjamin Gaignard
Graphic Working Group
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog