Hi,
I noticed there is currently no CMA support for AArch64. Is this already
on someone's TODO list or is this still open?
Thanks,
Laura
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
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
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