2019-06-03 13:44:50 +08:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-only
|
dma-buf: Introduce dma buffer sharing mechanism
This is the first step in defining a dma buffer sharing mechanism.
A new buffer object dma_buf is added, with operations and API to allow easy
sharing of this buffer object across devices.
The framework allows:
- creation of a buffer object, its association with a file pointer, and
associated allocator-defined operations on that buffer. This operation is
called the 'export' operation.
- different devices to 'attach' themselves to this exported buffer object, to
facilitate backing storage negotiation, using dma_buf_attach() API.
- the exported buffer object to be shared with the other entity by asking for
its 'file-descriptor (fd)', and sharing the fd across.
- a received fd to get the buffer object back, where it can be accessed using
the associated exporter-defined operations.
- the exporter and user to share the scatterlist associated with this buffer
object using map_dma_buf and unmap_dma_buf operations.
Atleast one 'attach()' call is required to be made prior to calling the
map_dma_buf() operation.
Couple of building blocks in map_dma_buf() are added to ease introduction
of sync'ing across exporter and users, and late allocation by the exporter.
For this first version, this framework will work with certain conditions:
- *ONLY* exporter will be allowed to mmap to userspace (outside of this
framework - mmap is not a buffer object operation),
- currently, *ONLY* users that do not need CPU access to the buffer are
allowed.
More details are there in the documentation patch.
This is based on design suggestions from many people at the mini-summits[1],
most notably from Arnd Bergmann <arnd@arndb.de>, Rob Clark <rob@ti.com> and
Daniel Vetter <daniel@ffwll.ch>.
The implementation is inspired from proof-of-concept patch-set from
Tomasz Stanislawski <t.stanislaws@samsung.com>, who demonstrated buffer sharing
between two v4l2 devices. [2]
[1]: https://wiki.linaro.org/OfficeofCTO/MemoryManagement
[2]: http://lwn.net/Articles/454389
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
Signed-off-by: Sumit Semwal <sumit.semwal@ti.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-and-Tested-by: Rob Clark <rob.clark@linaro.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-12-26 17:23:15 +08:00
|
|
|
/*
|
|
|
|
* Framework for buffer objects that can be shared across devices/subsystems.
|
|
|
|
*
|
|
|
|
* Copyright(C) 2011 Linaro Limited. All rights reserved.
|
|
|
|
* Author: Sumit Semwal <sumit.semwal@ti.com>
|
|
|
|
*
|
|
|
|
* Many thanks to linaro-mm-sig list, and specially
|
|
|
|
* Arnd Bergmann <arnd@arndb.de>, Rob Clark <rob@ti.com> and
|
|
|
|
* Daniel Vetter <daniel@ffwll.ch> for their support in creation and
|
|
|
|
* refining of this idea.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <linux/fs.h>
|
|
|
|
#include <linux/slab.h>
|
|
|
|
#include <linux/dma-buf.h>
|
2016-10-25 20:00:45 +08:00
|
|
|
#include <linux/dma-fence.h>
|
2022-08-03 05:01:58 +08:00
|
|
|
#include <linux/dma-fence-unwrap.h>
|
dma-buf: Introduce dma buffer sharing mechanism
This is the first step in defining a dma buffer sharing mechanism.
A new buffer object dma_buf is added, with operations and API to allow easy
sharing of this buffer object across devices.
The framework allows:
- creation of a buffer object, its association with a file pointer, and
associated allocator-defined operations on that buffer. This operation is
called the 'export' operation.
- different devices to 'attach' themselves to this exported buffer object, to
facilitate backing storage negotiation, using dma_buf_attach() API.
- the exported buffer object to be shared with the other entity by asking for
its 'file-descriptor (fd)', and sharing the fd across.
- a received fd to get the buffer object back, where it can be accessed using
the associated exporter-defined operations.
- the exporter and user to share the scatterlist associated with this buffer
object using map_dma_buf and unmap_dma_buf operations.
Atleast one 'attach()' call is required to be made prior to calling the
map_dma_buf() operation.
Couple of building blocks in map_dma_buf() are added to ease introduction
of sync'ing across exporter and users, and late allocation by the exporter.
For this first version, this framework will work with certain conditions:
- *ONLY* exporter will be allowed to mmap to userspace (outside of this
framework - mmap is not a buffer object operation),
- currently, *ONLY* users that do not need CPU access to the buffer are
allowed.
More details are there in the documentation patch.
This is based on design suggestions from many people at the mini-summits[1],
most notably from Arnd Bergmann <arnd@arndb.de>, Rob Clark <rob@ti.com> and
Daniel Vetter <daniel@ffwll.ch>.
The implementation is inspired from proof-of-concept patch-set from
Tomasz Stanislawski <t.stanislaws@samsung.com>, who demonstrated buffer sharing
between two v4l2 devices. [2]
[1]: https://wiki.linaro.org/OfficeofCTO/MemoryManagement
[2]: http://lwn.net/Articles/454389
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
Signed-off-by: Sumit Semwal <sumit.semwal@ti.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-and-Tested-by: Rob Clark <rob.clark@linaro.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-12-26 17:23:15 +08:00
|
|
|
#include <linux/anon_inodes.h>
|
|
|
|
#include <linux/export.h>
|
2013-04-04 14:14:37 +08:00
|
|
|
#include <linux/debugfs.h>
|
2015-05-05 17:26:15 +08:00
|
|
|
#include <linux/module.h>
|
2013-04-04 14:14:37 +08:00
|
|
|
#include <linux/seq_file.h>
|
dma-buf: Add an API for exporting sync files (v14)
Modern userspace APIs like Vulkan are built on an explicit
synchronization model. This doesn't always play nicely with the
implicit synchronization used in the kernel and assumed by X11 and
Wayland. The client -> compositor half of the synchronization isn't too
bad, at least on intel, because we can control whether or not i915
synchronizes on the buffer and whether or not it's considered written.
The harder part is the compositor -> client synchronization when we get
the buffer back from the compositor. We're required to be able to
provide the client with a VkSemaphore and VkFence representing the point
in time where the window system (compositor and/or display) finished
using the buffer. With current APIs, it's very hard to do this in such
a way that we don't get confused by the Vulkan driver's access of the
buffer. In particular, once we tell the kernel that we're rendering to
the buffer again, any CPU waits on the buffer or GPU dependencies will
wait on some of the client rendering and not just the compositor.
This new IOCTL solves this problem by allowing us to get a snapshot of
the implicit synchronization state of a given dma-buf in the form of a
sync file. It's effectively the same as a poll() or I915_GEM_WAIT only,
instead of CPU waiting directly, it encapsulates the wait operation, at
the current moment in time, in a sync_file so we can check/wait on it
later. As long as the Vulkan driver does the sync_file export from the
dma-buf before we re-introduce it for rendering, it will only contain
fences from the compositor or display. This allows to accurately turn
it into a VkFence or VkSemaphore without any over-synchronization.
By making this an ioctl on the dma-buf itself, it allows this new
functionality to be used in an entirely driver-agnostic way without
having access to a DRM fd. This makes it ideal for use in driver-generic
code in Mesa or in a client such as a compositor where the DRM fd may be
hard to reach.
v2 (Jason Ekstrand):
- Use a wrapper dma_fence_array of all fences including the new one
when importing an exclusive fence.
v3 (Jason Ekstrand):
- Lock around setting shared fences as well as exclusive
- Mark SIGNAL_SYNC_FILE as a read-write ioctl.
- Initialize ret to 0 in dma_buf_wait_sync_file
v4 (Jason Ekstrand):
- Use the new dma_resv_get_singleton helper
v5 (Jason Ekstrand):
- Rename the IOCTLs to import/export rather than wait/signal
- Drop the WRITE flag and always get/set the exclusive fence
v6 (Jason Ekstrand):
- Drop the sync_file import as it was all-around sketchy and not nearly
as useful as import.
- Re-introduce READ/WRITE flag support for export
- Rework the commit message
v7 (Jason Ekstrand):
- Require at least one sync flag
- Fix a refcounting bug: dma_resv_get_excl() doesn't take a reference
- Use _rcu helpers since we're accessing the dma_resv read-only
v8 (Jason Ekstrand):
- Return -ENOMEM if the sync_file_create fails
- Predicate support on IS_ENABLED(CONFIG_SYNC_FILE)
v9 (Jason Ekstrand):
- Add documentation for the new ioctl
v10 (Jason Ekstrand):
- Go back to dma_buf_sync_file as the ioctl struct name
v11 (Daniel Vetter):
- Go back to dma_buf_export_sync_file as the ioctl struct name
- Better kerneldoc describing what the read/write flags do
v12 (Christian König):
- Document why we chose to make it an ioctl on dma-buf
v13 (Jason Ekstrand):
- Rebase on Christian König's fence rework
v14 (Daniel Vetter & Christian König):
- Use dma_rev_usage_rw to get the properly inverted usage to pass to
dma_resv_get_singleton()
- Clean up the sync_file and fd if copy_to_user() fails
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Signed-off-by: Jason Ekstrand <jason.ekstrand@intel.com>
Signed-off-by: Jason Ekstrand <jason.ekstrand@collabora.com>
Acked-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Simon Ser <contact@emersion.fr>
Link: https://patchwork.freedesktop.org/patch/msgid/20220608152142.14495-2-jason@jlekstrand.net
2022-06-08 23:21:41 +08:00
|
|
|
#include <linux/sync_file.h>
|
2014-07-01 18:57:43 +08:00
|
|
|
#include <linux/poll.h>
|
2019-08-11 16:06:32 +08:00
|
|
|
#include <linux/dma-resv.h>
|
2016-05-23 19:38:42 +08:00
|
|
|
#include <linux/mm.h>
|
2019-06-14 06:34:06 +08:00
|
|
|
#include <linux/mount.h>
|
2019-07-20 01:42:02 +08:00
|
|
|
#include <linux/pseudo_fs.h>
|
dma-buf: Introduce dma buffer sharing mechanism
This is the first step in defining a dma buffer sharing mechanism.
A new buffer object dma_buf is added, with operations and API to allow easy
sharing of this buffer object across devices.
The framework allows:
- creation of a buffer object, its association with a file pointer, and
associated allocator-defined operations on that buffer. This operation is
called the 'export' operation.
- different devices to 'attach' themselves to this exported buffer object, to
facilitate backing storage negotiation, using dma_buf_attach() API.
- the exported buffer object to be shared with the other entity by asking for
its 'file-descriptor (fd)', and sharing the fd across.
- a received fd to get the buffer object back, where it can be accessed using
the associated exporter-defined operations.
- the exporter and user to share the scatterlist associated with this buffer
object using map_dma_buf and unmap_dma_buf operations.
Atleast one 'attach()' call is required to be made prior to calling the
map_dma_buf() operation.
Couple of building blocks in map_dma_buf() are added to ease introduction
of sync'ing across exporter and users, and late allocation by the exporter.
For this first version, this framework will work with certain conditions:
- *ONLY* exporter will be allowed to mmap to userspace (outside of this
framework - mmap is not a buffer object operation),
- currently, *ONLY* users that do not need CPU access to the buffer are
allowed.
More details are there in the documentation patch.
This is based on design suggestions from many people at the mini-summits[1],
most notably from Arnd Bergmann <arnd@arndb.de>, Rob Clark <rob@ti.com> and
Daniel Vetter <daniel@ffwll.ch>.
The implementation is inspired from proof-of-concept patch-set from
Tomasz Stanislawski <t.stanislaws@samsung.com>, who demonstrated buffer sharing
between two v4l2 devices. [2]
[1]: https://wiki.linaro.org/OfficeofCTO/MemoryManagement
[2]: http://lwn.net/Articles/454389
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
Signed-off-by: Sumit Semwal <sumit.semwal@ti.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-and-Tested-by: Rob Clark <rob.clark@linaro.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-12-26 17:23:15 +08:00
|
|
|
|
2016-02-12 06:04:51 +08:00
|
|
|
#include <uapi/linux/dma-buf.h>
|
2019-06-14 06:34:06 +08:00
|
|
|
#include <uapi/linux/magic.h>
|
2016-02-12 06:04:51 +08:00
|
|
|
|
2021-06-04 05:47:51 +08:00
|
|
|
#include "dma-buf-sysfs-stats.h"
|
|
|
|
|
dma-buf: Introduce dma buffer sharing mechanism
This is the first step in defining a dma buffer sharing mechanism.
A new buffer object dma_buf is added, with operations and API to allow easy
sharing of this buffer object across devices.
The framework allows:
- creation of a buffer object, its association with a file pointer, and
associated allocator-defined operations on that buffer. This operation is
called the 'export' operation.
- different devices to 'attach' themselves to this exported buffer object, to
facilitate backing storage negotiation, using dma_buf_attach() API.
- the exported buffer object to be shared with the other entity by asking for
its 'file-descriptor (fd)', and sharing the fd across.
- a received fd to get the buffer object back, where it can be accessed using
the associated exporter-defined operations.
- the exporter and user to share the scatterlist associated with this buffer
object using map_dma_buf and unmap_dma_buf operations.
Atleast one 'attach()' call is required to be made prior to calling the
map_dma_buf() operation.
Couple of building blocks in map_dma_buf() are added to ease introduction
of sync'ing across exporter and users, and late allocation by the exporter.
For this first version, this framework will work with certain conditions:
- *ONLY* exporter will be allowed to mmap to userspace (outside of this
framework - mmap is not a buffer object operation),
- currently, *ONLY* users that do not need CPU access to the buffer are
allowed.
More details are there in the documentation patch.
This is based on design suggestions from many people at the mini-summits[1],
most notably from Arnd Bergmann <arnd@arndb.de>, Rob Clark <rob@ti.com> and
Daniel Vetter <daniel@ffwll.ch>.
The implementation is inspired from proof-of-concept patch-set from
Tomasz Stanislawski <t.stanislaws@samsung.com>, who demonstrated buffer sharing
between two v4l2 devices. [2]
[1]: https://wiki.linaro.org/OfficeofCTO/MemoryManagement
[2]: http://lwn.net/Articles/454389
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
Signed-off-by: Sumit Semwal <sumit.semwal@ti.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-and-Tested-by: Rob Clark <rob.clark@linaro.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-12-26 17:23:15 +08:00
|
|
|
static inline int is_dma_buf_file(struct file *);
|
|
|
|
|
2024-03-28 22:53:23 +08:00
|
|
|
#if IS_ENABLED(CONFIG_DEBUG_FS)
|
|
|
|
static DEFINE_MUTEX(debugfs_list_mutex);
|
|
|
|
static LIST_HEAD(debugfs_list);
|
2013-04-04 14:14:37 +08:00
|
|
|
|
2024-03-28 22:53:23 +08:00
|
|
|
static void __dma_buf_debugfs_list_add(struct dma_buf *dmabuf)
|
|
|
|
{
|
|
|
|
mutex_lock(&debugfs_list_mutex);
|
|
|
|
list_add(&dmabuf->list_node, &debugfs_list);
|
|
|
|
mutex_unlock(&debugfs_list_mutex);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void __dma_buf_debugfs_list_del(struct dma_buf *dmabuf)
|
|
|
|
{
|
|
|
|
if (!dmabuf)
|
|
|
|
return;
|
|
|
|
|
|
|
|
mutex_lock(&debugfs_list_mutex);
|
|
|
|
list_del(&dmabuf->list_node);
|
|
|
|
mutex_unlock(&debugfs_list_mutex);
|
|
|
|
}
|
|
|
|
#else
|
|
|
|
static void __dma_buf_debugfs_list_add(struct dma_buf *dmabuf)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
|
|
|
static void __dma_buf_debugfs_list_del(struct file *file)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
#endif
|
2013-04-04 14:14:37 +08:00
|
|
|
|
2019-06-14 06:34:07 +08:00
|
|
|
static char *dmabuffs_dname(struct dentry *dentry, char *buffer, int buflen)
|
|
|
|
{
|
|
|
|
struct dma_buf *dmabuf;
|
|
|
|
char name[DMA_BUF_NAME_LEN];
|
2023-11-17 03:14:10 +08:00
|
|
|
ssize_t ret = 0;
|
2019-06-14 06:34:07 +08:00
|
|
|
|
|
|
|
dmabuf = dentry->d_fsdata;
|
2020-06-19 19:57:19 +08:00
|
|
|
spin_lock(&dmabuf->name_lock);
|
2019-06-14 06:34:07 +08:00
|
|
|
if (dmabuf->name)
|
2023-11-17 03:14:10 +08:00
|
|
|
ret = strscpy(name, dmabuf->name, sizeof(name));
|
2020-06-19 19:57:19 +08:00
|
|
|
spin_unlock(&dmabuf->name_lock);
|
2019-06-14 06:34:07 +08:00
|
|
|
|
2022-01-31 04:03:49 +08:00
|
|
|
return dynamic_dname(buffer, buflen, "/%s:%s",
|
2019-06-14 06:34:07 +08:00
|
|
|
dentry->d_name.name, ret > 0 ? name : "");
|
|
|
|
}
|
|
|
|
|
dma-buf: Move dma_buf_release() from fops to dentry_ops
Charan Teja reported a 'use-after-free' in dmabuffs_dname [1], which
happens if the dma_buf_release() is called while the userspace is
accessing the dma_buf pseudo fs's dmabuffs_dname() in another process,
and dma_buf_release() releases the dmabuf object when the last reference
to the struct file goes away.
I discussed with Arnd Bergmann, and he suggested that rather than tying
the dma_buf_release() to the file_operations' release(), we can tie it to
the dentry_operations' d_release(), which will be called when the last ref
to the dentry is removed.
The path exercised by __fput() calls f_op->release() first, and then calls
dput, which eventually calls d_op->d_release().
In the 'normal' case, when no userspace access is happening via dma_buf
pseudo fs, there should be exactly one fd, file, dentry and inode, so
closing the fd will kill of everything right away.
In the presented case, the dentry's d_release() will be called only when
the dentry's last ref is released.
Therefore, lets move dma_buf_release() from fops->release() to
d_ops->d_release()
Many thanks to Arnd for his FS insights :)
[1]: https://lore.kernel.org/patchwork/patch/1238278/
Fixes: bb2bb9030425 ("dma-buf: add DMA_BUF_SET_NAME ioctls")
Reported-by: syzbot+3643a18836bce555bff6@syzkaller.appspotmail.com
Cc: <stable@vger.kernel.org> [5.3+]
Cc: Arnd Bergmann <arnd@arndb.de>
Reported-by: Charan Teja Reddy <charante@codeaurora.org>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
Tested-by: Charan Teja Reddy <charante@codeaurora.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20200611114418.19852-1-sumit.semwal@linaro.org
2020-06-11 19:44:18 +08:00
|
|
|
static void dma_buf_release(struct dentry *dentry)
|
dma-buf: Introduce dma buffer sharing mechanism
This is the first step in defining a dma buffer sharing mechanism.
A new buffer object dma_buf is added, with operations and API to allow easy
sharing of this buffer object across devices.
The framework allows:
- creation of a buffer object, its association with a file pointer, and
associated allocator-defined operations on that buffer. This operation is
called the 'export' operation.
- different devices to 'attach' themselves to this exported buffer object, to
facilitate backing storage negotiation, using dma_buf_attach() API.
- the exported buffer object to be shared with the other entity by asking for
its 'file-descriptor (fd)', and sharing the fd across.
- a received fd to get the buffer object back, where it can be accessed using
the associated exporter-defined operations.
- the exporter and user to share the scatterlist associated with this buffer
object using map_dma_buf and unmap_dma_buf operations.
Atleast one 'attach()' call is required to be made prior to calling the
map_dma_buf() operation.
Couple of building blocks in map_dma_buf() are added to ease introduction
of sync'ing across exporter and users, and late allocation by the exporter.
For this first version, this framework will work with certain conditions:
- *ONLY* exporter will be allowed to mmap to userspace (outside of this
framework - mmap is not a buffer object operation),
- currently, *ONLY* users that do not need CPU access to the buffer are
allowed.
More details are there in the documentation patch.
This is based on design suggestions from many people at the mini-summits[1],
most notably from Arnd Bergmann <arnd@arndb.de>, Rob Clark <rob@ti.com> and
Daniel Vetter <daniel@ffwll.ch>.
The implementation is inspired from proof-of-concept patch-set from
Tomasz Stanislawski <t.stanislaws@samsung.com>, who demonstrated buffer sharing
between two v4l2 devices. [2]
[1]: https://wiki.linaro.org/OfficeofCTO/MemoryManagement
[2]: http://lwn.net/Articles/454389
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
Signed-off-by: Sumit Semwal <sumit.semwal@ti.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-and-Tested-by: Rob Clark <rob.clark@linaro.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-12-26 17:23:15 +08:00
|
|
|
{
|
|
|
|
struct dma_buf *dmabuf;
|
|
|
|
|
dma-buf: Move dma_buf_release() from fops to dentry_ops
Charan Teja reported a 'use-after-free' in dmabuffs_dname [1], which
happens if the dma_buf_release() is called while the userspace is
accessing the dma_buf pseudo fs's dmabuffs_dname() in another process,
and dma_buf_release() releases the dmabuf object when the last reference
to the struct file goes away.
I discussed with Arnd Bergmann, and he suggested that rather than tying
the dma_buf_release() to the file_operations' release(), we can tie it to
the dentry_operations' d_release(), which will be called when the last ref
to the dentry is removed.
The path exercised by __fput() calls f_op->release() first, and then calls
dput, which eventually calls d_op->d_release().
In the 'normal' case, when no userspace access is happening via dma_buf
pseudo fs, there should be exactly one fd, file, dentry and inode, so
closing the fd will kill of everything right away.
In the presented case, the dentry's d_release() will be called only when
the dentry's last ref is released.
Therefore, lets move dma_buf_release() from fops->release() to
d_ops->d_release()
Many thanks to Arnd for his FS insights :)
[1]: https://lore.kernel.org/patchwork/patch/1238278/
Fixes: bb2bb9030425 ("dma-buf: add DMA_BUF_SET_NAME ioctls")
Reported-by: syzbot+3643a18836bce555bff6@syzkaller.appspotmail.com
Cc: <stable@vger.kernel.org> [5.3+]
Cc: Arnd Bergmann <arnd@arndb.de>
Reported-by: Charan Teja Reddy <charante@codeaurora.org>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
Tested-by: Charan Teja Reddy <charante@codeaurora.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20200611114418.19852-1-sumit.semwal@linaro.org
2020-06-11 19:44:18 +08:00
|
|
|
dmabuf = dentry->d_fsdata;
|
2020-09-18 18:32:31 +08:00
|
|
|
if (unlikely(!dmabuf))
|
|
|
|
return;
|
dma-buf: Introduce dma buffer sharing mechanism
This is the first step in defining a dma buffer sharing mechanism.
A new buffer object dma_buf is added, with operations and API to allow easy
sharing of this buffer object across devices.
The framework allows:
- creation of a buffer object, its association with a file pointer, and
associated allocator-defined operations on that buffer. This operation is
called the 'export' operation.
- different devices to 'attach' themselves to this exported buffer object, to
facilitate backing storage negotiation, using dma_buf_attach() API.
- the exported buffer object to be shared with the other entity by asking for
its 'file-descriptor (fd)', and sharing the fd across.
- a received fd to get the buffer object back, where it can be accessed using
the associated exporter-defined operations.
- the exporter and user to share the scatterlist associated with this buffer
object using map_dma_buf and unmap_dma_buf operations.
Atleast one 'attach()' call is required to be made prior to calling the
map_dma_buf() operation.
Couple of building blocks in map_dma_buf() are added to ease introduction
of sync'ing across exporter and users, and late allocation by the exporter.
For this first version, this framework will work with certain conditions:
- *ONLY* exporter will be allowed to mmap to userspace (outside of this
framework - mmap is not a buffer object operation),
- currently, *ONLY* users that do not need CPU access to the buffer are
allowed.
More details are there in the documentation patch.
This is based on design suggestions from many people at the mini-summits[1],
most notably from Arnd Bergmann <arnd@arndb.de>, Rob Clark <rob@ti.com> and
Daniel Vetter <daniel@ffwll.ch>.
The implementation is inspired from proof-of-concept patch-set from
Tomasz Stanislawski <t.stanislaws@samsung.com>, who demonstrated buffer sharing
between two v4l2 devices. [2]
[1]: https://wiki.linaro.org/OfficeofCTO/MemoryManagement
[2]: http://lwn.net/Articles/454389
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
Signed-off-by: Sumit Semwal <sumit.semwal@ti.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-and-Tested-by: Rob Clark <rob.clark@linaro.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-12-26 17:23:15 +08:00
|
|
|
|
2012-12-20 21:14:23 +08:00
|
|
|
BUG_ON(dmabuf->vmapping_counter);
|
|
|
|
|
2014-07-01 18:57:43 +08:00
|
|
|
/*
|
2021-07-23 15:58:57 +08:00
|
|
|
* If you hit this BUG() it could mean:
|
|
|
|
* * There's a file reference imbalance in dma_buf_poll / dma_buf_poll_cb or somewhere else
|
|
|
|
* * dmabuf->cb_in/out.active are non-0 despite no pending fence callback
|
2014-07-01 18:57:43 +08:00
|
|
|
*/
|
2021-06-15 19:12:33 +08:00
|
|
|
BUG_ON(dmabuf->cb_in.active || dmabuf->cb_out.active);
|
2014-07-01 18:57:43 +08:00
|
|
|
|
2021-07-20 18:31:58 +08:00
|
|
|
dma_buf_stats_teardown(dmabuf);
|
dma-buf: Introduce dma buffer sharing mechanism
This is the first step in defining a dma buffer sharing mechanism.
A new buffer object dma_buf is added, with operations and API to allow easy
sharing of this buffer object across devices.
The framework allows:
- creation of a buffer object, its association with a file pointer, and
associated allocator-defined operations on that buffer. This operation is
called the 'export' operation.
- different devices to 'attach' themselves to this exported buffer object, to
facilitate backing storage negotiation, using dma_buf_attach() API.
- the exported buffer object to be shared with the other entity by asking for
its 'file-descriptor (fd)', and sharing the fd across.
- a received fd to get the buffer object back, where it can be accessed using
the associated exporter-defined operations.
- the exporter and user to share the scatterlist associated with this buffer
object using map_dma_buf and unmap_dma_buf operations.
Atleast one 'attach()' call is required to be made prior to calling the
map_dma_buf() operation.
Couple of building blocks in map_dma_buf() are added to ease introduction
of sync'ing across exporter and users, and late allocation by the exporter.
For this first version, this framework will work with certain conditions:
- *ONLY* exporter will be allowed to mmap to userspace (outside of this
framework - mmap is not a buffer object operation),
- currently, *ONLY* users that do not need CPU access to the buffer are
allowed.
More details are there in the documentation patch.
This is based on design suggestions from many people at the mini-summits[1],
most notably from Arnd Bergmann <arnd@arndb.de>, Rob Clark <rob@ti.com> and
Daniel Vetter <daniel@ffwll.ch>.
The implementation is inspired from proof-of-concept patch-set from
Tomasz Stanislawski <t.stanislaws@samsung.com>, who demonstrated buffer sharing
between two v4l2 devices. [2]
[1]: https://wiki.linaro.org/OfficeofCTO/MemoryManagement
[2]: http://lwn.net/Articles/454389
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
Signed-off-by: Sumit Semwal <sumit.semwal@ti.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-and-Tested-by: Rob Clark <rob.clark@linaro.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-12-26 17:23:15 +08:00
|
|
|
dmabuf->ops->release(dmabuf);
|
2013-04-04 14:14:37 +08:00
|
|
|
|
2019-08-11 16:06:32 +08:00
|
|
|
if (dmabuf->resv == (struct dma_resv *)&dmabuf[1])
|
|
|
|
dma_resv_fini(dmabuf->resv);
|
2014-07-01 18:57:26 +08:00
|
|
|
|
2021-07-23 20:31:08 +08:00
|
|
|
WARN_ON(!list_empty(&dmabuf->attachments));
|
2015-05-05 17:26:15 +08:00
|
|
|
module_put(dmabuf->owner);
|
2019-12-27 14:32:04 +08:00
|
|
|
kfree(dmabuf->name);
|
dma-buf: Introduce dma buffer sharing mechanism
This is the first step in defining a dma buffer sharing mechanism.
A new buffer object dma_buf is added, with operations and API to allow easy
sharing of this buffer object across devices.
The framework allows:
- creation of a buffer object, its association with a file pointer, and
associated allocator-defined operations on that buffer. This operation is
called the 'export' operation.
- different devices to 'attach' themselves to this exported buffer object, to
facilitate backing storage negotiation, using dma_buf_attach() API.
- the exported buffer object to be shared with the other entity by asking for
its 'file-descriptor (fd)', and sharing the fd across.
- a received fd to get the buffer object back, where it can be accessed using
the associated exporter-defined operations.
- the exporter and user to share the scatterlist associated with this buffer
object using map_dma_buf and unmap_dma_buf operations.
Atleast one 'attach()' call is required to be made prior to calling the
map_dma_buf() operation.
Couple of building blocks in map_dma_buf() are added to ease introduction
of sync'ing across exporter and users, and late allocation by the exporter.
For this first version, this framework will work with certain conditions:
- *ONLY* exporter will be allowed to mmap to userspace (outside of this
framework - mmap is not a buffer object operation),
- currently, *ONLY* users that do not need CPU access to the buffer are
allowed.
More details are there in the documentation patch.
This is based on design suggestions from many people at the mini-summits[1],
most notably from Arnd Bergmann <arnd@arndb.de>, Rob Clark <rob@ti.com> and
Daniel Vetter <daniel@ffwll.ch>.
The implementation is inspired from proof-of-concept patch-set from
Tomasz Stanislawski <t.stanislaws@samsung.com>, who demonstrated buffer sharing
between two v4l2 devices. [2]
[1]: https://wiki.linaro.org/OfficeofCTO/MemoryManagement
[2]: http://lwn.net/Articles/454389
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
Signed-off-by: Sumit Semwal <sumit.semwal@ti.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-and-Tested-by: Rob Clark <rob.clark@linaro.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-12-26 17:23:15 +08:00
|
|
|
kfree(dmabuf);
|
dma-buf: Move dma_buf_release() from fops to dentry_ops
Charan Teja reported a 'use-after-free' in dmabuffs_dname [1], which
happens if the dma_buf_release() is called while the userspace is
accessing the dma_buf pseudo fs's dmabuffs_dname() in another process,
and dma_buf_release() releases the dmabuf object when the last reference
to the struct file goes away.
I discussed with Arnd Bergmann, and he suggested that rather than tying
the dma_buf_release() to the file_operations' release(), we can tie it to
the dentry_operations' d_release(), which will be called when the last ref
to the dentry is removed.
The path exercised by __fput() calls f_op->release() first, and then calls
dput, which eventually calls d_op->d_release().
In the 'normal' case, when no userspace access is happening via dma_buf
pseudo fs, there should be exactly one fd, file, dentry and inode, so
closing the fd will kill of everything right away.
In the presented case, the dentry's d_release() will be called only when
the dentry's last ref is released.
Therefore, lets move dma_buf_release() from fops->release() to
d_ops->d_release()
Many thanks to Arnd for his FS insights :)
[1]: https://lore.kernel.org/patchwork/patch/1238278/
Fixes: bb2bb9030425 ("dma-buf: add DMA_BUF_SET_NAME ioctls")
Reported-by: syzbot+3643a18836bce555bff6@syzkaller.appspotmail.com
Cc: <stable@vger.kernel.org> [5.3+]
Cc: Arnd Bergmann <arnd@arndb.de>
Reported-by: Charan Teja Reddy <charante@codeaurora.org>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
Tested-by: Charan Teja Reddy <charante@codeaurora.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20200611114418.19852-1-sumit.semwal@linaro.org
2020-06-11 19:44:18 +08:00
|
|
|
}
|
|
|
|
|
2021-01-05 22:36:39 +08:00
|
|
|
static int dma_buf_file_release(struct inode *inode, struct file *file)
|
|
|
|
{
|
|
|
|
if (!is_dma_buf_file(file))
|
|
|
|
return -EINVAL;
|
|
|
|
|
2024-03-28 22:53:23 +08:00
|
|
|
__dma_buf_debugfs_list_del(file->private_data);
|
2021-01-05 22:36:39 +08:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
dma-buf: Move dma_buf_release() from fops to dentry_ops
Charan Teja reported a 'use-after-free' in dmabuffs_dname [1], which
happens if the dma_buf_release() is called while the userspace is
accessing the dma_buf pseudo fs's dmabuffs_dname() in another process,
and dma_buf_release() releases the dmabuf object when the last reference
to the struct file goes away.
I discussed with Arnd Bergmann, and he suggested that rather than tying
the dma_buf_release() to the file_operations' release(), we can tie it to
the dentry_operations' d_release(), which will be called when the last ref
to the dentry is removed.
The path exercised by __fput() calls f_op->release() first, and then calls
dput, which eventually calls d_op->d_release().
In the 'normal' case, when no userspace access is happening via dma_buf
pseudo fs, there should be exactly one fd, file, dentry and inode, so
closing the fd will kill of everything right away.
In the presented case, the dentry's d_release() will be called only when
the dentry's last ref is released.
Therefore, lets move dma_buf_release() from fops->release() to
d_ops->d_release()
Many thanks to Arnd for his FS insights :)
[1]: https://lore.kernel.org/patchwork/patch/1238278/
Fixes: bb2bb9030425 ("dma-buf: add DMA_BUF_SET_NAME ioctls")
Reported-by: syzbot+3643a18836bce555bff6@syzkaller.appspotmail.com
Cc: <stable@vger.kernel.org> [5.3+]
Cc: Arnd Bergmann <arnd@arndb.de>
Reported-by: Charan Teja Reddy <charante@codeaurora.org>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
Tested-by: Charan Teja Reddy <charante@codeaurora.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20200611114418.19852-1-sumit.semwal@linaro.org
2020-06-11 19:44:18 +08:00
|
|
|
static const struct dentry_operations dma_buf_dentry_ops = {
|
|
|
|
.d_dname = dmabuffs_dname,
|
|
|
|
.d_release = dma_buf_release,
|
|
|
|
};
|
|
|
|
|
|
|
|
static struct vfsmount *dma_buf_mnt;
|
|
|
|
|
|
|
|
static int dma_buf_fs_init_context(struct fs_context *fc)
|
|
|
|
{
|
|
|
|
struct pseudo_fs_context *ctx;
|
|
|
|
|
|
|
|
ctx = init_pseudo(fc, DMA_BUF_MAGIC);
|
|
|
|
if (!ctx)
|
|
|
|
return -ENOMEM;
|
|
|
|
ctx->dops = &dma_buf_dentry_ops;
|
dma-buf: Introduce dma buffer sharing mechanism
This is the first step in defining a dma buffer sharing mechanism.
A new buffer object dma_buf is added, with operations and API to allow easy
sharing of this buffer object across devices.
The framework allows:
- creation of a buffer object, its association with a file pointer, and
associated allocator-defined operations on that buffer. This operation is
called the 'export' operation.
- different devices to 'attach' themselves to this exported buffer object, to
facilitate backing storage negotiation, using dma_buf_attach() API.
- the exported buffer object to be shared with the other entity by asking for
its 'file-descriptor (fd)', and sharing the fd across.
- a received fd to get the buffer object back, where it can be accessed using
the associated exporter-defined operations.
- the exporter and user to share the scatterlist associated with this buffer
object using map_dma_buf and unmap_dma_buf operations.
Atleast one 'attach()' call is required to be made prior to calling the
map_dma_buf() operation.
Couple of building blocks in map_dma_buf() are added to ease introduction
of sync'ing across exporter and users, and late allocation by the exporter.
For this first version, this framework will work with certain conditions:
- *ONLY* exporter will be allowed to mmap to userspace (outside of this
framework - mmap is not a buffer object operation),
- currently, *ONLY* users that do not need CPU access to the buffer are
allowed.
More details are there in the documentation patch.
This is based on design suggestions from many people at the mini-summits[1],
most notably from Arnd Bergmann <arnd@arndb.de>, Rob Clark <rob@ti.com> and
Daniel Vetter <daniel@ffwll.ch>.
The implementation is inspired from proof-of-concept patch-set from
Tomasz Stanislawski <t.stanislaws@samsung.com>, who demonstrated buffer sharing
between two v4l2 devices. [2]
[1]: https://wiki.linaro.org/OfficeofCTO/MemoryManagement
[2]: http://lwn.net/Articles/454389
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
Signed-off-by: Sumit Semwal <sumit.semwal@ti.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-and-Tested-by: Rob Clark <rob.clark@linaro.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-12-26 17:23:15 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
dma-buf: Move dma_buf_release() from fops to dentry_ops
Charan Teja reported a 'use-after-free' in dmabuffs_dname [1], which
happens if the dma_buf_release() is called while the userspace is
accessing the dma_buf pseudo fs's dmabuffs_dname() in another process,
and dma_buf_release() releases the dmabuf object when the last reference
to the struct file goes away.
I discussed with Arnd Bergmann, and he suggested that rather than tying
the dma_buf_release() to the file_operations' release(), we can tie it to
the dentry_operations' d_release(), which will be called when the last ref
to the dentry is removed.
The path exercised by __fput() calls f_op->release() first, and then calls
dput, which eventually calls d_op->d_release().
In the 'normal' case, when no userspace access is happening via dma_buf
pseudo fs, there should be exactly one fd, file, dentry and inode, so
closing the fd will kill of everything right away.
In the presented case, the dentry's d_release() will be called only when
the dentry's last ref is released.
Therefore, lets move dma_buf_release() from fops->release() to
d_ops->d_release()
Many thanks to Arnd for his FS insights :)
[1]: https://lore.kernel.org/patchwork/patch/1238278/
Fixes: bb2bb9030425 ("dma-buf: add DMA_BUF_SET_NAME ioctls")
Reported-by: syzbot+3643a18836bce555bff6@syzkaller.appspotmail.com
Cc: <stable@vger.kernel.org> [5.3+]
Cc: Arnd Bergmann <arnd@arndb.de>
Reported-by: Charan Teja Reddy <charante@codeaurora.org>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
Tested-by: Charan Teja Reddy <charante@codeaurora.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20200611114418.19852-1-sumit.semwal@linaro.org
2020-06-11 19:44:18 +08:00
|
|
|
static struct file_system_type dma_buf_fs_type = {
|
|
|
|
.name = "dmabuf",
|
|
|
|
.init_fs_context = dma_buf_fs_init_context,
|
|
|
|
.kill_sb = kill_anon_super,
|
|
|
|
};
|
|
|
|
|
dma-buf: mmap support
Compared to Rob Clark's RFC I've ditched the prepare/finish hooks
and corresponding ioctls on the dma_buf file. The major reason for
that is that many people seem to be under the impression that this is
also for synchronization with outstanding asynchronous processsing.
I'm pretty massively opposed to this because:
- It boils down reinventing a new rather general-purpose userspace
synchronization interface. If we look at things like futexes, this
is hard to get right.
- Furthermore a lot of kernel code has to interact with this
synchronization primitive. This smells a look like the dri1 hw_lock,
a horror show I prefer not to reinvent.
- Even more fun is that multiple different subsystems would interact
here, so we have plenty of opportunities to create funny deadlock
scenarios.
I think synchronization is a wholesale different problem from data
sharing and should be tackled as an orthogonal problem.
Now we could demand that prepare/finish may only ensure cache
coherency (as Rob intended), but that runs up into the next problem:
We not only need mmap support to facilitate sw-only processing nodes
in a pipeline (without jumping through hoops by importing the dma_buf
into some sw-access only importer), which allows for a nicer
ION->dma-buf upgrade path for existing Android userspace. We also need
mmap support for existing importing subsystems to support existing
userspace libraries. And a loot of these subsystems are expected to
export coherent userspace mappings.
So prepare/finish can only ever be optional and the exporter /needs/
to support coherent mappings. Given that mmap access is always
somewhat fallback-y in nature I've decided to drop this optimization,
instead of just making it optional. If we demonstrate a clear need for
this, supported by benchmark results, we can always add it in again
later as an optional extension.
Other differences compared to Rob's RFC is the above mentioned support
for mapping a dma-buf through facilities provided by the importer.
Which results in mmap support no longer being optional.
Note that this dma-buf mmap patch does _not_ support every possible
insanity an existing subsystem could pull of with mmap: Because it
does not allow to intercept pagefaults and shoot down ptes importing
subsystems can't add some magic of their own at these points (e.g. to
automatically synchronize with outstanding rendering or set up some
special resources). I've done a cursory read through a few mmap
implementions of various subsytems and I'm hopeful that we can avoid
this (and the complexity it'd bring with it).
Additonally I've extended the documentation a bit to explain the hows
and whys of this mmap extension.
In case we ever want to add support for explicitly cache maneged
userspace mmap with a prepare/finish ioctl pair, we could specify that
userspace needs to mmap a different part of the dma_buf, e.g. the
range starting at dma_buf->size up to dma_buf->size*2. This works
because the size of a dma_buf is invariant over it's lifetime. The
exporter would obviously need to fall back to coherent mappings for
both ranges if a legacy clients maps the coherent range and the
architecture cannot suppor conflicting caching policies. Also, this
would obviously be optional and userspace needs to be able to fall
back to coherent mappings.
v2:
- Spelling fixes from Rob Clark.
- Compile fix for !DMA_BUF from Rob Clark.
- Extend commit message to explain how explicitly cache managed mmap
support could be added later.
- Extend the documentation with implementations notes for exporters
that need to manually fake coherency.
v3:
- dma_buf pointer initialization goof-up noticed by Rebecca Schultz
Zavin.
Cc: Rob Clark <rob.clark@linaro.org>
Cc: Rebecca Schultz Zavin <rebecca@android.com>
Acked-by: Rob Clark <rob.clark@linaro.org>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
2012-04-24 17:08:52 +08:00
|
|
|
static int dma_buf_mmap_internal(struct file *file, struct vm_area_struct *vma)
|
|
|
|
{
|
|
|
|
struct dma_buf *dmabuf;
|
|
|
|
|
|
|
|
if (!is_dma_buf_file(file))
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
dmabuf = file->private_data;
|
|
|
|
|
2019-03-30 00:52:01 +08:00
|
|
|
/* check if buffer supports mmap */
|
|
|
|
if (!dmabuf->ops->mmap)
|
|
|
|
return -EINVAL;
|
|
|
|
|
dma-buf: mmap support
Compared to Rob Clark's RFC I've ditched the prepare/finish hooks
and corresponding ioctls on the dma_buf file. The major reason for
that is that many people seem to be under the impression that this is
also for synchronization with outstanding asynchronous processsing.
I'm pretty massively opposed to this because:
- It boils down reinventing a new rather general-purpose userspace
synchronization interface. If we look at things like futexes, this
is hard to get right.
- Furthermore a lot of kernel code has to interact with this
synchronization primitive. This smells a look like the dri1 hw_lock,
a horror show I prefer not to reinvent.
- Even more fun is that multiple different subsystems would interact
here, so we have plenty of opportunities to create funny deadlock
scenarios.
I think synchronization is a wholesale different problem from data
sharing and should be tackled as an orthogonal problem.
Now we could demand that prepare/finish may only ensure cache
coherency (as Rob intended), but that runs up into the next problem:
We not only need mmap support to facilitate sw-only processing nodes
in a pipeline (without jumping through hoops by importing the dma_buf
into some sw-access only importer), which allows for a nicer
ION->dma-buf upgrade path for existing Android userspace. We also need
mmap support for existing importing subsystems to support existing
userspace libraries. And a loot of these subsystems are expected to
export coherent userspace mappings.
So prepare/finish can only ever be optional and the exporter /needs/
to support coherent mappings. Given that mmap access is always
somewhat fallback-y in nature I've decided to drop this optimization,
instead of just making it optional. If we demonstrate a clear need for
this, supported by benchmark results, we can always add it in again
later as an optional extension.
Other differences compared to Rob's RFC is the above mentioned support
for mapping a dma-buf through facilities provided by the importer.
Which results in mmap support no longer being optional.
Note that this dma-buf mmap patch does _not_ support every possible
insanity an existing subsystem could pull of with mmap: Because it
does not allow to intercept pagefaults and shoot down ptes importing
subsystems can't add some magic of their own at these points (e.g. to
automatically synchronize with outstanding rendering or set up some
special resources). I've done a cursory read through a few mmap
implementions of various subsytems and I'm hopeful that we can avoid
this (and the complexity it'd bring with it).
Additonally I've extended the documentation a bit to explain the hows
and whys of this mmap extension.
In case we ever want to add support for explicitly cache maneged
userspace mmap with a prepare/finish ioctl pair, we could specify that
userspace needs to mmap a different part of the dma_buf, e.g. the
range starting at dma_buf->size up to dma_buf->size*2. This works
because the size of a dma_buf is invariant over it's lifetime. The
exporter would obviously need to fall back to coherent mappings for
both ranges if a legacy clients maps the coherent range and the
architecture cannot suppor conflicting caching policies. Also, this
would obviously be optional and userspace needs to be able to fall
back to coherent mappings.
v2:
- Spelling fixes from Rob Clark.
- Compile fix for !DMA_BUF from Rob Clark.
- Extend commit message to explain how explicitly cache managed mmap
support could be added later.
- Extend the documentation with implementations notes for exporters
that need to manually fake coherency.
v3:
- dma_buf pointer initialization goof-up noticed by Rebecca Schultz
Zavin.
Cc: Rob Clark <rob.clark@linaro.org>
Cc: Rebecca Schultz Zavin <rebecca@android.com>
Acked-by: Rob Clark <rob.clark@linaro.org>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
2012-04-24 17:08:52 +08:00
|
|
|
/* check for overflowing the buffer's size */
|
2016-05-23 19:38:42 +08:00
|
|
|
if (vma->vm_pgoff + vma_pages(vma) >
|
dma-buf: mmap support
Compared to Rob Clark's RFC I've ditched the prepare/finish hooks
and corresponding ioctls on the dma_buf file. The major reason for
that is that many people seem to be under the impression that this is
also for synchronization with outstanding asynchronous processsing.
I'm pretty massively opposed to this because:
- It boils down reinventing a new rather general-purpose userspace
synchronization interface. If we look at things like futexes, this
is hard to get right.
- Furthermore a lot of kernel code has to interact with this
synchronization primitive. This smells a look like the dri1 hw_lock,
a horror show I prefer not to reinvent.
- Even more fun is that multiple different subsystems would interact
here, so we have plenty of opportunities to create funny deadlock
scenarios.
I think synchronization is a wholesale different problem from data
sharing and should be tackled as an orthogonal problem.
Now we could demand that prepare/finish may only ensure cache
coherency (as Rob intended), but that runs up into the next problem:
We not only need mmap support to facilitate sw-only processing nodes
in a pipeline (without jumping through hoops by importing the dma_buf
into some sw-access only importer), which allows for a nicer
ION->dma-buf upgrade path for existing Android userspace. We also need
mmap support for existing importing subsystems to support existing
userspace libraries. And a loot of these subsystems are expected to
export coherent userspace mappings.
So prepare/finish can only ever be optional and the exporter /needs/
to support coherent mappings. Given that mmap access is always
somewhat fallback-y in nature I've decided to drop this optimization,
instead of just making it optional. If we demonstrate a clear need for
this, supported by benchmark results, we can always add it in again
later as an optional extension.
Other differences compared to Rob's RFC is the above mentioned support
for mapping a dma-buf through facilities provided by the importer.
Which results in mmap support no longer being optional.
Note that this dma-buf mmap patch does _not_ support every possible
insanity an existing subsystem could pull of with mmap: Because it
does not allow to intercept pagefaults and shoot down ptes importing
subsystems can't add some magic of their own at these points (e.g. to
automatically synchronize with outstanding rendering or set up some
special resources). I've done a cursory read through a few mmap
implementions of various subsytems and I'm hopeful that we can avoid
this (and the complexity it'd bring with it).
Additonally I've extended the documentation a bit to explain the hows
and whys of this mmap extension.
In case we ever want to add support for explicitly cache maneged
userspace mmap with a prepare/finish ioctl pair, we could specify that
userspace needs to mmap a different part of the dma_buf, e.g. the
range starting at dma_buf->size up to dma_buf->size*2. This works
because the size of a dma_buf is invariant over it's lifetime. The
exporter would obviously need to fall back to coherent mappings for
both ranges if a legacy clients maps the coherent range and the
architecture cannot suppor conflicting caching policies. Also, this
would obviously be optional and userspace needs to be able to fall
back to coherent mappings.
v2:
- Spelling fixes from Rob Clark.
- Compile fix for !DMA_BUF from Rob Clark.
- Extend commit message to explain how explicitly cache managed mmap
support could be added later.
- Extend the documentation with implementations notes for exporters
that need to manually fake coherency.
v3:
- dma_buf pointer initialization goof-up noticed by Rebecca Schultz
Zavin.
Cc: Rob Clark <rob.clark@linaro.org>
Cc: Rebecca Schultz Zavin <rebecca@android.com>
Acked-by: Rob Clark <rob.clark@linaro.org>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
2012-04-24 17:08:52 +08:00
|
|
|
dmabuf->size >> PAGE_SHIFT)
|
|
|
|
return -EINVAL;
|
|
|
|
|
2023-05-30 06:39:34 +08:00
|
|
|
return dmabuf->ops->mmap(dmabuf, vma);
|
dma-buf: mmap support
Compared to Rob Clark's RFC I've ditched the prepare/finish hooks
and corresponding ioctls on the dma_buf file. The major reason for
that is that many people seem to be under the impression that this is
also for synchronization with outstanding asynchronous processsing.
I'm pretty massively opposed to this because:
- It boils down reinventing a new rather general-purpose userspace
synchronization interface. If we look at things like futexes, this
is hard to get right.
- Furthermore a lot of kernel code has to interact with this
synchronization primitive. This smells a look like the dri1 hw_lock,
a horror show I prefer not to reinvent.
- Even more fun is that multiple different subsystems would interact
here, so we have plenty of opportunities to create funny deadlock
scenarios.
I think synchronization is a wholesale different problem from data
sharing and should be tackled as an orthogonal problem.
Now we could demand that prepare/finish may only ensure cache
coherency (as Rob intended), but that runs up into the next problem:
We not only need mmap support to facilitate sw-only processing nodes
in a pipeline (without jumping through hoops by importing the dma_buf
into some sw-access only importer), which allows for a nicer
ION->dma-buf upgrade path for existing Android userspace. We also need
mmap support for existing importing subsystems to support existing
userspace libraries. And a loot of these subsystems are expected to
export coherent userspace mappings.
So prepare/finish can only ever be optional and the exporter /needs/
to support coherent mappings. Given that mmap access is always
somewhat fallback-y in nature I've decided to drop this optimization,
instead of just making it optional. If we demonstrate a clear need for
this, supported by benchmark results, we can always add it in again
later as an optional extension.
Other differences compared to Rob's RFC is the above mentioned support
for mapping a dma-buf through facilities provided by the importer.
Which results in mmap support no longer being optional.
Note that this dma-buf mmap patch does _not_ support every possible
insanity an existing subsystem could pull of with mmap: Because it
does not allow to intercept pagefaults and shoot down ptes importing
subsystems can't add some magic of their own at these points (e.g. to
automatically synchronize with outstanding rendering or set up some
special resources). I've done a cursory read through a few mmap
implementions of various subsytems and I'm hopeful that we can avoid
this (and the complexity it'd bring with it).
Additonally I've extended the documentation a bit to explain the hows
and whys of this mmap extension.
In case we ever want to add support for explicitly cache maneged
userspace mmap with a prepare/finish ioctl pair, we could specify that
userspace needs to mmap a different part of the dma_buf, e.g. the
range starting at dma_buf->size up to dma_buf->size*2. This works
because the size of a dma_buf is invariant over it's lifetime. The
exporter would obviously need to fall back to coherent mappings for
both ranges if a legacy clients maps the coherent range and the
architecture cannot suppor conflicting caching policies. Also, this
would obviously be optional and userspace needs to be able to fall
back to coherent mappings.
v2:
- Spelling fixes from Rob Clark.
- Compile fix for !DMA_BUF from Rob Clark.
- Extend commit message to explain how explicitly cache managed mmap
support could be added later.
- Extend the documentation with implementations notes for exporters
that need to manually fake coherency.
v3:
- dma_buf pointer initialization goof-up noticed by Rebecca Schultz
Zavin.
Cc: Rob Clark <rob.clark@linaro.org>
Cc: Rebecca Schultz Zavin <rebecca@android.com>
Acked-by: Rob Clark <rob.clark@linaro.org>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
2012-04-24 17:08:52 +08:00
|
|
|
}
|
|
|
|
|
2013-09-10 14:06:45 +08:00
|
|
|
static loff_t dma_buf_llseek(struct file *file, loff_t offset, int whence)
|
|
|
|
{
|
|
|
|
struct dma_buf *dmabuf;
|
|
|
|
loff_t base;
|
|
|
|
|
|
|
|
if (!is_dma_buf_file(file))
|
|
|
|
return -EBADF;
|
|
|
|
|
|
|
|
dmabuf = file->private_data;
|
|
|
|
|
|
|
|
/* only support discovering the end of the buffer,
|
|
|
|
but also allow SEEK_SET to maintain the idiomatic
|
|
|
|
SEEK_END(0), SEEK_CUR(0) pattern */
|
|
|
|
if (whence == SEEK_END)
|
|
|
|
base = dmabuf->size;
|
|
|
|
else if (whence == SEEK_SET)
|
|
|
|
base = 0;
|
|
|
|
else
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
if (offset != 0)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
return base + offset;
|
|
|
|
}
|
|
|
|
|
2016-12-10 05:50:55 +08:00
|
|
|
/**
|
2020-06-12 15:05:35 +08:00
|
|
|
* DOC: implicit fence polling
|
2016-12-10 05:50:55 +08:00
|
|
|
*
|
|
|
|
* To support cross-device and cross-driver synchronization of buffer access
|
2020-06-12 15:05:35 +08:00
|
|
|
* implicit fences (represented internally in the kernel with &struct dma_fence)
|
|
|
|
* can be attached to a &dma_buf. The glue for that and a few related things are
|
2019-08-11 16:06:32 +08:00
|
|
|
* provided in the &dma_resv structure.
|
2016-12-10 05:50:55 +08:00
|
|
|
*
|
|
|
|
* Userspace can query the state of these implicitly tracked fences using poll()
|
|
|
|
* and related system calls:
|
|
|
|
*
|
2018-02-12 06:34:03 +08:00
|
|
|
* - Checking for EPOLLIN, i.e. read access, can be use to query the state of the
|
2016-12-10 05:50:55 +08:00
|
|
|
* most recent write or exclusive fence.
|
|
|
|
*
|
2018-02-12 06:34:03 +08:00
|
|
|
* - Checking for EPOLLOUT, i.e. write access, can be used to query the state of
|
2016-12-10 05:50:55 +08:00
|
|
|
* all attached fences, shared and exclusive ones.
|
|
|
|
*
|
|
|
|
* Note that this only signals the completion of the respective fences, i.e. the
|
|
|
|
* DMA transfers are complete. Cache flushing and any other necessary
|
|
|
|
* preparations before CPU access can begin still need to happen.
|
dma-buf: Add an API for exporting sync files (v14)
Modern userspace APIs like Vulkan are built on an explicit
synchronization model. This doesn't always play nicely with the
implicit synchronization used in the kernel and assumed by X11 and
Wayland. The client -> compositor half of the synchronization isn't too
bad, at least on intel, because we can control whether or not i915
synchronizes on the buffer and whether or not it's considered written.
The harder part is the compositor -> client synchronization when we get
the buffer back from the compositor. We're required to be able to
provide the client with a VkSemaphore and VkFence representing the point
in time where the window system (compositor and/or display) finished
using the buffer. With current APIs, it's very hard to do this in such
a way that we don't get confused by the Vulkan driver's access of the
buffer. In particular, once we tell the kernel that we're rendering to
the buffer again, any CPU waits on the buffer or GPU dependencies will
wait on some of the client rendering and not just the compositor.
This new IOCTL solves this problem by allowing us to get a snapshot of
the implicit synchronization state of a given dma-buf in the form of a
sync file. It's effectively the same as a poll() or I915_GEM_WAIT only,
instead of CPU waiting directly, it encapsulates the wait operation, at
the current moment in time, in a sync_file so we can check/wait on it
later. As long as the Vulkan driver does the sync_file export from the
dma-buf before we re-introduce it for rendering, it will only contain
fences from the compositor or display. This allows to accurately turn
it into a VkFence or VkSemaphore without any over-synchronization.
By making this an ioctl on the dma-buf itself, it allows this new
functionality to be used in an entirely driver-agnostic way without
having access to a DRM fd. This makes it ideal for use in driver-generic
code in Mesa or in a client such as a compositor where the DRM fd may be
hard to reach.
v2 (Jason Ekstrand):
- Use a wrapper dma_fence_array of all fences including the new one
when importing an exclusive fence.
v3 (Jason Ekstrand):
- Lock around setting shared fences as well as exclusive
- Mark SIGNAL_SYNC_FILE as a read-write ioctl.
- Initialize ret to 0 in dma_buf_wait_sync_file
v4 (Jason Ekstrand):
- Use the new dma_resv_get_singleton helper
v5 (Jason Ekstrand):
- Rename the IOCTLs to import/export rather than wait/signal
- Drop the WRITE flag and always get/set the exclusive fence
v6 (Jason Ekstrand):
- Drop the sync_file import as it was all-around sketchy and not nearly
as useful as import.
- Re-introduce READ/WRITE flag support for export
- Rework the commit message
v7 (Jason Ekstrand):
- Require at least one sync flag
- Fix a refcounting bug: dma_resv_get_excl() doesn't take a reference
- Use _rcu helpers since we're accessing the dma_resv read-only
v8 (Jason Ekstrand):
- Return -ENOMEM if the sync_file_create fails
- Predicate support on IS_ENABLED(CONFIG_SYNC_FILE)
v9 (Jason Ekstrand):
- Add documentation for the new ioctl
v10 (Jason Ekstrand):
- Go back to dma_buf_sync_file as the ioctl struct name
v11 (Daniel Vetter):
- Go back to dma_buf_export_sync_file as the ioctl struct name
- Better kerneldoc describing what the read/write flags do
v12 (Christian König):
- Document why we chose to make it an ioctl on dma-buf
v13 (Jason Ekstrand):
- Rebase on Christian König's fence rework
v14 (Daniel Vetter & Christian König):
- Use dma_rev_usage_rw to get the properly inverted usage to pass to
dma_resv_get_singleton()
- Clean up the sync_file and fd if copy_to_user() fails
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Signed-off-by: Jason Ekstrand <jason.ekstrand@intel.com>
Signed-off-by: Jason Ekstrand <jason.ekstrand@collabora.com>
Acked-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Simon Ser <contact@emersion.fr>
Link: https://patchwork.freedesktop.org/patch/msgid/20220608152142.14495-2-jason@jlekstrand.net
2022-06-08 23:21:41 +08:00
|
|
|
*
|
|
|
|
* As an alternative to poll(), the set of fences on DMA buffer can be
|
|
|
|
* exported as a &sync_file using &dma_buf_sync_file_export.
|
2016-12-10 05:50:55 +08:00
|
|
|
*/
|
|
|
|
|
2016-10-25 20:00:45 +08:00
|
|
|
static void dma_buf_poll_cb(struct dma_fence *fence, struct dma_fence_cb *cb)
|
2014-07-01 18:57:43 +08:00
|
|
|
{
|
|
|
|
struct dma_buf_poll_cb_t *dcb = (struct dma_buf_poll_cb_t *)cb;
|
2021-07-23 15:58:57 +08:00
|
|
|
struct dma_buf *dmabuf = container_of(dcb->poll, struct dma_buf, poll);
|
2014-07-01 18:57:43 +08:00
|
|
|
unsigned long flags;
|
|
|
|
|
|
|
|
spin_lock_irqsave(&dcb->poll->lock, flags);
|
|
|
|
wake_up_locked_poll(dcb->poll, dcb->active);
|
|
|
|
dcb->active = 0;
|
|
|
|
spin_unlock_irqrestore(&dcb->poll->lock, flags);
|
2021-06-15 19:12:33 +08:00
|
|
|
dma_fence_put(fence);
|
2021-07-23 15:58:57 +08:00
|
|
|
/* Paired with get_file in dma_buf_poll */
|
|
|
|
fput(dmabuf->file);
|
2021-06-15 19:12:33 +08:00
|
|
|
}
|
|
|
|
|
2021-09-24 17:31:22 +08:00
|
|
|
static bool dma_buf_poll_add_cb(struct dma_resv *resv, bool write,
|
2021-06-15 19:12:33 +08:00
|
|
|
struct dma_buf_poll_cb_t *dcb)
|
|
|
|
{
|
2021-09-24 17:31:22 +08:00
|
|
|
struct dma_resv_iter cursor;
|
2021-06-15 19:12:33 +08:00
|
|
|
struct dma_fence *fence;
|
2021-09-24 17:31:22 +08:00
|
|
|
int r;
|
2021-06-15 19:12:33 +08:00
|
|
|
|
2021-11-09 18:08:18 +08:00
|
|
|
dma_resv_for_each_fence(&cursor, resv, dma_resv_usage_rw(write),
|
|
|
|
fence) {
|
2021-06-15 19:12:33 +08:00
|
|
|
dma_fence_get(fence);
|
|
|
|
r = dma_fence_add_callback(fence, &dcb->cb, dma_buf_poll_cb);
|
|
|
|
if (!r)
|
|
|
|
return true;
|
|
|
|
dma_fence_put(fence);
|
|
|
|
}
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2017-07-03 18:39:46 +08:00
|
|
|
static __poll_t dma_buf_poll(struct file *file, poll_table *poll)
|
2014-07-01 18:57:43 +08:00
|
|
|
{
|
|
|
|
struct dma_buf *dmabuf;
|
2019-08-11 16:06:32 +08:00
|
|
|
struct dma_resv *resv;
|
2017-07-03 15:14:15 +08:00
|
|
|
__poll_t events;
|
2014-07-01 18:57:43 +08:00
|
|
|
|
|
|
|
dmabuf = file->private_data;
|
|
|
|
if (!dmabuf || !dmabuf->resv)
|
2018-02-12 06:34:03 +08:00
|
|
|
return EPOLLERR;
|
2014-07-01 18:57:43 +08:00
|
|
|
|
|
|
|
resv = dmabuf->resv;
|
|
|
|
|
|
|
|
poll_wait(file, &dmabuf->poll, poll);
|
|
|
|
|
2018-02-12 06:34:03 +08:00
|
|
|
events = poll_requested_events(poll) & (EPOLLIN | EPOLLOUT);
|
2014-07-01 18:57:43 +08:00
|
|
|
if (!events)
|
|
|
|
return 0;
|
|
|
|
|
2021-06-15 19:12:33 +08:00
|
|
|
dma_resv_lock(resv, NULL);
|
2014-07-01 18:57:43 +08:00
|
|
|
|
2021-06-15 19:12:33 +08:00
|
|
|
if (events & EPOLLOUT) {
|
|
|
|
struct dma_buf_poll_cb_t *dcb = &dmabuf->cb_out;
|
2014-07-01 18:57:43 +08:00
|
|
|
|
2021-06-15 19:12:33 +08:00
|
|
|
/* Check that callback isn't busy */
|
2014-07-01 18:57:43 +08:00
|
|
|
spin_lock_irq(&dmabuf->poll.lock);
|
2021-06-15 19:12:33 +08:00
|
|
|
if (dcb->active)
|
|
|
|
events &= ~EPOLLOUT;
|
|
|
|
else
|
|
|
|
dcb->active = EPOLLOUT;
|
2014-07-01 18:57:43 +08:00
|
|
|
spin_unlock_irq(&dmabuf->poll.lock);
|
|
|
|
|
2021-06-15 19:12:33 +08:00
|
|
|
if (events & EPOLLOUT) {
|
2021-07-23 15:58:57 +08:00
|
|
|
/* Paired with fput in dma_buf_poll_cb */
|
|
|
|
get_file(dmabuf->file);
|
|
|
|
|
2021-09-24 17:31:22 +08:00
|
|
|
if (!dma_buf_poll_add_cb(resv, true, dcb))
|
2021-06-15 19:12:33 +08:00
|
|
|
/* No callback queued, wake up any other waiters */
|
2014-07-01 18:57:43 +08:00
|
|
|
dma_buf_poll_cb(NULL, &dcb->cb);
|
2021-06-15 19:12:33 +08:00
|
|
|
else
|
|
|
|
events &= ~EPOLLOUT;
|
2014-07-01 18:57:43 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2021-06-15 19:12:33 +08:00
|
|
|
if (events & EPOLLIN) {
|
|
|
|
struct dma_buf_poll_cb_t *dcb = &dmabuf->cb_in;
|
2014-07-01 18:57:43 +08:00
|
|
|
|
2021-06-15 19:12:33 +08:00
|
|
|
/* Check that callback isn't busy */
|
2014-07-01 18:57:43 +08:00
|
|
|
spin_lock_irq(&dmabuf->poll.lock);
|
|
|
|
if (dcb->active)
|
2021-06-15 19:12:33 +08:00
|
|
|
events &= ~EPOLLIN;
|
2014-07-01 18:57:43 +08:00
|
|
|
else
|
2021-06-15 19:12:33 +08:00
|
|
|
dcb->active = EPOLLIN;
|
2014-07-01 18:57:43 +08:00
|
|
|
spin_unlock_irq(&dmabuf->poll.lock);
|
|
|
|
|
2021-06-15 19:12:33 +08:00
|
|
|
if (events & EPOLLIN) {
|
2021-07-23 15:58:57 +08:00
|
|
|
/* Paired with fput in dma_buf_poll_cb */
|
|
|
|
get_file(dmabuf->file);
|
|
|
|
|
2021-09-24 17:31:22 +08:00
|
|
|
if (!dma_buf_poll_add_cb(resv, false, dcb))
|
2021-06-15 19:12:33 +08:00
|
|
|
/* No callback queued, wake up any other waiters */
|
2014-07-01 18:58:00 +08:00
|
|
|
dma_buf_poll_cb(NULL, &dcb->cb);
|
2021-06-15 19:12:33 +08:00
|
|
|
else
|
|
|
|
events &= ~EPOLLIN;
|
2014-07-01 18:57:54 +08:00
|
|
|
}
|
2014-07-01 18:57:43 +08:00
|
|
|
}
|
|
|
|
|
2021-06-15 19:12:33 +08:00
|
|
|
dma_resv_unlock(resv);
|
2014-07-01 18:57:43 +08:00
|
|
|
return events;
|
|
|
|
}
|
|
|
|
|
2019-06-14 06:34:07 +08:00
|
|
|
/**
|
|
|
|
* dma_buf_set_name - Set a name to a specific dma_buf to track the usage.
|
2021-10-14 18:25:51 +08:00
|
|
|
* It could support changing the name of the dma-buf if the same
|
|
|
|
* piece of memory is used for multiple purpose between different devices.
|
2019-06-14 06:34:07 +08:00
|
|
|
*
|
2020-08-20 01:51:33 +08:00
|
|
|
* @dmabuf: [in] dmabuf buffer that will be renamed.
|
|
|
|
* @buf: [in] A piece of userspace memory that contains the name of
|
|
|
|
* the dma-buf.
|
2019-06-14 06:34:07 +08:00
|
|
|
*
|
|
|
|
* Returns 0 on success. If the dma-buf buffer is already attached to
|
|
|
|
* devices, return -EBUSY.
|
|
|
|
*
|
|
|
|
*/
|
|
|
|
static long dma_buf_set_name(struct dma_buf *dmabuf, const char __user *buf)
|
|
|
|
{
|
|
|
|
char *name = strndup_user(buf, DMA_BUF_NAME_LEN);
|
|
|
|
|
|
|
|
if (IS_ERR(name))
|
|
|
|
return PTR_ERR(name);
|
|
|
|
|
2020-06-19 19:57:19 +08:00
|
|
|
spin_lock(&dmabuf->name_lock);
|
2019-06-14 06:34:07 +08:00
|
|
|
kfree(dmabuf->name);
|
|
|
|
dmabuf->name = name;
|
2020-06-19 19:57:19 +08:00
|
|
|
spin_unlock(&dmabuf->name_lock);
|
2019-06-14 06:34:07 +08:00
|
|
|
|
2021-10-14 18:25:51 +08:00
|
|
|
return 0;
|
2019-06-14 06:34:07 +08:00
|
|
|
}
|
|
|
|
|
dma-buf: Add an API for exporting sync files (v14)
Modern userspace APIs like Vulkan are built on an explicit
synchronization model. This doesn't always play nicely with the
implicit synchronization used in the kernel and assumed by X11 and
Wayland. The client -> compositor half of the synchronization isn't too
bad, at least on intel, because we can control whether or not i915
synchronizes on the buffer and whether or not it's considered written.
The harder part is the compositor -> client synchronization when we get
the buffer back from the compositor. We're required to be able to
provide the client with a VkSemaphore and VkFence representing the point
in time where the window system (compositor and/or display) finished
using the buffer. With current APIs, it's very hard to do this in such
a way that we don't get confused by the Vulkan driver's access of the
buffer. In particular, once we tell the kernel that we're rendering to
the buffer again, any CPU waits on the buffer or GPU dependencies will
wait on some of the client rendering and not just the compositor.
This new IOCTL solves this problem by allowing us to get a snapshot of
the implicit synchronization state of a given dma-buf in the form of a
sync file. It's effectively the same as a poll() or I915_GEM_WAIT only,
instead of CPU waiting directly, it encapsulates the wait operation, at
the current moment in time, in a sync_file so we can check/wait on it
later. As long as the Vulkan driver does the sync_file export from the
dma-buf before we re-introduce it for rendering, it will only contain
fences from the compositor or display. This allows to accurately turn
it into a VkFence or VkSemaphore without any over-synchronization.
By making this an ioctl on the dma-buf itself, it allows this new
functionality to be used in an entirely driver-agnostic way without
having access to a DRM fd. This makes it ideal for use in driver-generic
code in Mesa or in a client such as a compositor where the DRM fd may be
hard to reach.
v2 (Jason Ekstrand):
- Use a wrapper dma_fence_array of all fences including the new one
when importing an exclusive fence.
v3 (Jason Ekstrand):
- Lock around setting shared fences as well as exclusive
- Mark SIGNAL_SYNC_FILE as a read-write ioctl.
- Initialize ret to 0 in dma_buf_wait_sync_file
v4 (Jason Ekstrand):
- Use the new dma_resv_get_singleton helper
v5 (Jason Ekstrand):
- Rename the IOCTLs to import/export rather than wait/signal
- Drop the WRITE flag and always get/set the exclusive fence
v6 (Jason Ekstrand):
- Drop the sync_file import as it was all-around sketchy and not nearly
as useful as import.
- Re-introduce READ/WRITE flag support for export
- Rework the commit message
v7 (Jason Ekstrand):
- Require at least one sync flag
- Fix a refcounting bug: dma_resv_get_excl() doesn't take a reference
- Use _rcu helpers since we're accessing the dma_resv read-only
v8 (Jason Ekstrand):
- Return -ENOMEM if the sync_file_create fails
- Predicate support on IS_ENABLED(CONFIG_SYNC_FILE)
v9 (Jason Ekstrand):
- Add documentation for the new ioctl
v10 (Jason Ekstrand):
- Go back to dma_buf_sync_file as the ioctl struct name
v11 (Daniel Vetter):
- Go back to dma_buf_export_sync_file as the ioctl struct name
- Better kerneldoc describing what the read/write flags do
v12 (Christian König):
- Document why we chose to make it an ioctl on dma-buf
v13 (Jason Ekstrand):
- Rebase on Christian König's fence rework
v14 (Daniel Vetter & Christian König):
- Use dma_rev_usage_rw to get the properly inverted usage to pass to
dma_resv_get_singleton()
- Clean up the sync_file and fd if copy_to_user() fails
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Signed-off-by: Jason Ekstrand <jason.ekstrand@intel.com>
Signed-off-by: Jason Ekstrand <jason.ekstrand@collabora.com>
Acked-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Simon Ser <contact@emersion.fr>
Link: https://patchwork.freedesktop.org/patch/msgid/20220608152142.14495-2-jason@jlekstrand.net
2022-06-08 23:21:41 +08:00
|
|
|
#if IS_ENABLED(CONFIG_SYNC_FILE)
|
|
|
|
static long dma_buf_export_sync_file(struct dma_buf *dmabuf,
|
|
|
|
void __user *user_data)
|
|
|
|
{
|
|
|
|
struct dma_buf_export_sync_file arg;
|
|
|
|
enum dma_resv_usage usage;
|
|
|
|
struct dma_fence *fence = NULL;
|
|
|
|
struct sync_file *sync_file;
|
|
|
|
int fd, ret;
|
|
|
|
|
|
|
|
if (copy_from_user(&arg, user_data, sizeof(arg)))
|
|
|
|
return -EFAULT;
|
|
|
|
|
|
|
|
if (arg.flags & ~DMA_BUF_SYNC_RW)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
if ((arg.flags & DMA_BUF_SYNC_RW) == 0)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
fd = get_unused_fd_flags(O_CLOEXEC);
|
|
|
|
if (fd < 0)
|
|
|
|
return fd;
|
|
|
|
|
|
|
|
usage = dma_resv_usage_rw(arg.flags & DMA_BUF_SYNC_WRITE);
|
|
|
|
ret = dma_resv_get_singleton(dmabuf->resv, usage, &fence);
|
|
|
|
if (ret)
|
|
|
|
goto err_put_fd;
|
|
|
|
|
|
|
|
if (!fence)
|
|
|
|
fence = dma_fence_get_stub();
|
|
|
|
|
|
|
|
sync_file = sync_file_create(fence);
|
|
|
|
|
|
|
|
dma_fence_put(fence);
|
|
|
|
|
|
|
|
if (!sync_file) {
|
|
|
|
ret = -ENOMEM;
|
|
|
|
goto err_put_fd;
|
|
|
|
}
|
|
|
|
|
|
|
|
arg.fd = fd;
|
|
|
|
if (copy_to_user(user_data, &arg, sizeof(arg))) {
|
|
|
|
ret = -EFAULT;
|
|
|
|
goto err_put_file;
|
|
|
|
}
|
|
|
|
|
|
|
|
fd_install(fd, sync_file->file);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
err_put_file:
|
|
|
|
fput(sync_file->file);
|
|
|
|
err_put_fd:
|
|
|
|
put_unused_fd(fd);
|
|
|
|
return ret;
|
|
|
|
}
|
dma-buf: Add an API for importing sync files (v10)
This patch is analogous to the previous sync file export patch in that
it allows you to import a sync_file into a dma-buf. Unlike the previous
patch, however, this does add genuinely new functionality to dma-buf.
Without this, the only way to attach a sync_file to a dma-buf is to
submit a batch to your driver of choice which waits on the sync_file and
claims to write to the dma-buf. Even if said batch is a no-op, a submit
is typically way more overhead than just attaching a fence. A submit
may also imply extra synchronization with other work because it happens
on a hardware queue.
In the Vulkan world, this is useful for dealing with the out-fence from
vkQueuePresent. Current Linux window-systems (X11, Wayland, etc.) all
rely on dma-buf implicit sync. Since Vulkan is an explicit sync API, we
get a set of fences (VkSemaphores) in vkQueuePresent and have to stash
those as an exclusive (write) fence on the dma-buf. We handle it in
Mesa today with the above mentioned dummy submit trick. This ioctl
would allow us to set it directly without the dummy submit.
This may also open up possibilities for GPU drivers to move away from
implicit sync for their kernel driver uAPI and instead provide sync
files and rely on dma-buf import/export for communicating with other
implicit sync clients.
We make the explicit choice here to only allow setting RW fences which
translates to an exclusive fence on the dma_resv. There's no use for
read-only fences for communicating with other implicit sync userspace
and any such attempts are likely to be racy at best. When we got to
insert the RW fence, the actual fence we set as the new exclusive fence
is a combination of the sync_file provided by the user and all the other
fences on the dma_resv. This ensures that the newly added exclusive
fence will never signal before the old one would have and ensures that
we don't break any dma_resv contracts. We require userspace to specify
RW in the flags for symmetry with the export ioctl and in case we ever
want to support read fences in the future.
There is one downside here that's worth documenting: If two clients
writing to the same dma-buf using this API race with each other, their
actions on the dma-buf may happen in parallel or in an undefined order.
Both with and without this API, the pattern is the same: Collect all
the fences on dma-buf, submit work which depends on said fences, and
then set a new exclusive (write) fence on the dma-buf which depends on
said work. The difference is that, when it's all handled by the GPU
driver's submit ioctl, the three operations happen atomically under the
dma_resv lock. If two userspace submits race, one will happen before
the other. You aren't guaranteed which but you are guaranteed that
they're strictly ordered. If userspace manages the fences itself, then
these three operations happen separately and the two render operations
may happen genuinely in parallel or get interleaved. However, this is a
case of userspace racing with itself. As long as we ensure userspace
can't back the kernel into a corner, it should be fine.
v2 (Jason Ekstrand):
- Use a wrapper dma_fence_array of all fences including the new one
when importing an exclusive fence.
v3 (Jason Ekstrand):
- Lock around setting shared fences as well as exclusive
- Mark SIGNAL_SYNC_FILE as a read-write ioctl.
- Initialize ret to 0 in dma_buf_wait_sync_file
v4 (Jason Ekstrand):
- Use the new dma_resv_get_singleton helper
v5 (Jason Ekstrand):
- Rename the IOCTLs to import/export rather than wait/signal
- Drop the WRITE flag and always get/set the exclusive fence
v6 (Jason Ekstrand):
- Split import and export into separate patches
- New commit message
v7 (Daniel Vetter):
- Fix the uapi header to use the right struct in the ioctl
- Use a separate dma_buf_import_sync_file struct
- Add kerneldoc for dma_buf_import_sync_file
v8 (Jason Ekstrand):
- Rebase on Christian König's fence rework
v9 (Daniel Vetter):
- Fix -EINVAL checks for the flags parameter
- Add documentation about read/write fences
- Add documentation about the expected usage of import/export and
specifically call out the possible userspace race.
v10 (Simon Ser):
- Fix a typo in the docs
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Signed-off-by: Jason Ekstrand <jason.ekstrand@intel.com>
Signed-off-by: Jason Ekstrand <jason.ekstrand@collabora.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Simon Ser <contact@emersion.fr>
Link: https://patchwork.freedesktop.org/patch/msgid/20220608152142.14495-3-jason@jlekstrand.net
2022-06-08 23:21:42 +08:00
|
|
|
|
|
|
|
static long dma_buf_import_sync_file(struct dma_buf *dmabuf,
|
|
|
|
const void __user *user_data)
|
|
|
|
{
|
|
|
|
struct dma_buf_import_sync_file arg;
|
2022-08-03 05:01:58 +08:00
|
|
|
struct dma_fence *fence, *f;
|
dma-buf: Add an API for importing sync files (v10)
This patch is analogous to the previous sync file export patch in that
it allows you to import a sync_file into a dma-buf. Unlike the previous
patch, however, this does add genuinely new functionality to dma-buf.
Without this, the only way to attach a sync_file to a dma-buf is to
submit a batch to your driver of choice which waits on the sync_file and
claims to write to the dma-buf. Even if said batch is a no-op, a submit
is typically way more overhead than just attaching a fence. A submit
may also imply extra synchronization with other work because it happens
on a hardware queue.
In the Vulkan world, this is useful for dealing with the out-fence from
vkQueuePresent. Current Linux window-systems (X11, Wayland, etc.) all
rely on dma-buf implicit sync. Since Vulkan is an explicit sync API, we
get a set of fences (VkSemaphores) in vkQueuePresent and have to stash
those as an exclusive (write) fence on the dma-buf. We handle it in
Mesa today with the above mentioned dummy submit trick. This ioctl
would allow us to set it directly without the dummy submit.
This may also open up possibilities for GPU drivers to move away from
implicit sync for their kernel driver uAPI and instead provide sync
files and rely on dma-buf import/export for communicating with other
implicit sync clients.
We make the explicit choice here to only allow setting RW fences which
translates to an exclusive fence on the dma_resv. There's no use for
read-only fences for communicating with other implicit sync userspace
and any such attempts are likely to be racy at best. When we got to
insert the RW fence, the actual fence we set as the new exclusive fence
is a combination of the sync_file provided by the user and all the other
fences on the dma_resv. This ensures that the newly added exclusive
fence will never signal before the old one would have and ensures that
we don't break any dma_resv contracts. We require userspace to specify
RW in the flags for symmetry with the export ioctl and in case we ever
want to support read fences in the future.
There is one downside here that's worth documenting: If two clients
writing to the same dma-buf using this API race with each other, their
actions on the dma-buf may happen in parallel or in an undefined order.
Both with and without this API, the pattern is the same: Collect all
the fences on dma-buf, submit work which depends on said fences, and
then set a new exclusive (write) fence on the dma-buf which depends on
said work. The difference is that, when it's all handled by the GPU
driver's submit ioctl, the three operations happen atomically under the
dma_resv lock. If two userspace submits race, one will happen before
the other. You aren't guaranteed which but you are guaranteed that
they're strictly ordered. If userspace manages the fences itself, then
these three operations happen separately and the two render operations
may happen genuinely in parallel or get interleaved. However, this is a
case of userspace racing with itself. As long as we ensure userspace
can't back the kernel into a corner, it should be fine.
v2 (Jason Ekstrand):
- Use a wrapper dma_fence_array of all fences including the new one
when importing an exclusive fence.
v3 (Jason Ekstrand):
- Lock around setting shared fences as well as exclusive
- Mark SIGNAL_SYNC_FILE as a read-write ioctl.
- Initialize ret to 0 in dma_buf_wait_sync_file
v4 (Jason Ekstrand):
- Use the new dma_resv_get_singleton helper
v5 (Jason Ekstrand):
- Rename the IOCTLs to import/export rather than wait/signal
- Drop the WRITE flag and always get/set the exclusive fence
v6 (Jason Ekstrand):
- Split import and export into separate patches
- New commit message
v7 (Daniel Vetter):
- Fix the uapi header to use the right struct in the ioctl
- Use a separate dma_buf_import_sync_file struct
- Add kerneldoc for dma_buf_import_sync_file
v8 (Jason Ekstrand):
- Rebase on Christian König's fence rework
v9 (Daniel Vetter):
- Fix -EINVAL checks for the flags parameter
- Add documentation about read/write fences
- Add documentation about the expected usage of import/export and
specifically call out the possible userspace race.
v10 (Simon Ser):
- Fix a typo in the docs
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Signed-off-by: Jason Ekstrand <jason.ekstrand@intel.com>
Signed-off-by: Jason Ekstrand <jason.ekstrand@collabora.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Simon Ser <contact@emersion.fr>
Link: https://patchwork.freedesktop.org/patch/msgid/20220608152142.14495-3-jason@jlekstrand.net
2022-06-08 23:21:42 +08:00
|
|
|
enum dma_resv_usage usage;
|
2022-08-03 05:01:58 +08:00
|
|
|
struct dma_fence_unwrap iter;
|
|
|
|
unsigned int num_fences;
|
dma-buf: Add an API for importing sync files (v10)
This patch is analogous to the previous sync file export patch in that
it allows you to import a sync_file into a dma-buf. Unlike the previous
patch, however, this does add genuinely new functionality to dma-buf.
Without this, the only way to attach a sync_file to a dma-buf is to
submit a batch to your driver of choice which waits on the sync_file and
claims to write to the dma-buf. Even if said batch is a no-op, a submit
is typically way more overhead than just attaching a fence. A submit
may also imply extra synchronization with other work because it happens
on a hardware queue.
In the Vulkan world, this is useful for dealing with the out-fence from
vkQueuePresent. Current Linux window-systems (X11, Wayland, etc.) all
rely on dma-buf implicit sync. Since Vulkan is an explicit sync API, we
get a set of fences (VkSemaphores) in vkQueuePresent and have to stash
those as an exclusive (write) fence on the dma-buf. We handle it in
Mesa today with the above mentioned dummy submit trick. This ioctl
would allow us to set it directly without the dummy submit.
This may also open up possibilities for GPU drivers to move away from
implicit sync for their kernel driver uAPI and instead provide sync
files and rely on dma-buf import/export for communicating with other
implicit sync clients.
We make the explicit choice here to only allow setting RW fences which
translates to an exclusive fence on the dma_resv. There's no use for
read-only fences for communicating with other implicit sync userspace
and any such attempts are likely to be racy at best. When we got to
insert the RW fence, the actual fence we set as the new exclusive fence
is a combination of the sync_file provided by the user and all the other
fences on the dma_resv. This ensures that the newly added exclusive
fence will never signal before the old one would have and ensures that
we don't break any dma_resv contracts. We require userspace to specify
RW in the flags for symmetry with the export ioctl and in case we ever
want to support read fences in the future.
There is one downside here that's worth documenting: If two clients
writing to the same dma-buf using this API race with each other, their
actions on the dma-buf may happen in parallel or in an undefined order.
Both with and without this API, the pattern is the same: Collect all
the fences on dma-buf, submit work which depends on said fences, and
then set a new exclusive (write) fence on the dma-buf which depends on
said work. The difference is that, when it's all handled by the GPU
driver's submit ioctl, the three operations happen atomically under the
dma_resv lock. If two userspace submits race, one will happen before
the other. You aren't guaranteed which but you are guaranteed that
they're strictly ordered. If userspace manages the fences itself, then
these three operations happen separately and the two render operations
may happen genuinely in parallel or get interleaved. However, this is a
case of userspace racing with itself. As long as we ensure userspace
can't back the kernel into a corner, it should be fine.
v2 (Jason Ekstrand):
- Use a wrapper dma_fence_array of all fences including the new one
when importing an exclusive fence.
v3 (Jason Ekstrand):
- Lock around setting shared fences as well as exclusive
- Mark SIGNAL_SYNC_FILE as a read-write ioctl.
- Initialize ret to 0 in dma_buf_wait_sync_file
v4 (Jason Ekstrand):
- Use the new dma_resv_get_singleton helper
v5 (Jason Ekstrand):
- Rename the IOCTLs to import/export rather than wait/signal
- Drop the WRITE flag and always get/set the exclusive fence
v6 (Jason Ekstrand):
- Split import and export into separate patches
- New commit message
v7 (Daniel Vetter):
- Fix the uapi header to use the right struct in the ioctl
- Use a separate dma_buf_import_sync_file struct
- Add kerneldoc for dma_buf_import_sync_file
v8 (Jason Ekstrand):
- Rebase on Christian König's fence rework
v9 (Daniel Vetter):
- Fix -EINVAL checks for the flags parameter
- Add documentation about read/write fences
- Add documentation about the expected usage of import/export and
specifically call out the possible userspace race.
v10 (Simon Ser):
- Fix a typo in the docs
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Signed-off-by: Jason Ekstrand <jason.ekstrand@intel.com>
Signed-off-by: Jason Ekstrand <jason.ekstrand@collabora.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Simon Ser <contact@emersion.fr>
Link: https://patchwork.freedesktop.org/patch/msgid/20220608152142.14495-3-jason@jlekstrand.net
2022-06-08 23:21:42 +08:00
|
|
|
int ret = 0;
|
|
|
|
|
|
|
|
if (copy_from_user(&arg, user_data, sizeof(arg)))
|
|
|
|
return -EFAULT;
|
|
|
|
|
|
|
|
if (arg.flags & ~DMA_BUF_SYNC_RW)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
if ((arg.flags & DMA_BUF_SYNC_RW) == 0)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
fence = sync_file_get_fence(arg.fd);
|
|
|
|
if (!fence)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
usage = (arg.flags & DMA_BUF_SYNC_WRITE) ? DMA_RESV_USAGE_WRITE :
|
|
|
|
DMA_RESV_USAGE_READ;
|
|
|
|
|
2022-08-03 05:01:58 +08:00
|
|
|
num_fences = 0;
|
|
|
|
dma_fence_unwrap_for_each(f, &iter, fence)
|
|
|
|
++num_fences;
|
|
|
|
|
|
|
|
if (num_fences > 0) {
|
|
|
|
dma_resv_lock(dmabuf->resv, NULL);
|
dma-buf: Add an API for importing sync files (v10)
This patch is analogous to the previous sync file export patch in that
it allows you to import a sync_file into a dma-buf. Unlike the previous
patch, however, this does add genuinely new functionality to dma-buf.
Without this, the only way to attach a sync_file to a dma-buf is to
submit a batch to your driver of choice which waits on the sync_file and
claims to write to the dma-buf. Even if said batch is a no-op, a submit
is typically way more overhead than just attaching a fence. A submit
may also imply extra synchronization with other work because it happens
on a hardware queue.
In the Vulkan world, this is useful for dealing with the out-fence from
vkQueuePresent. Current Linux window-systems (X11, Wayland, etc.) all
rely on dma-buf implicit sync. Since Vulkan is an explicit sync API, we
get a set of fences (VkSemaphores) in vkQueuePresent and have to stash
those as an exclusive (write) fence on the dma-buf. We handle it in
Mesa today with the above mentioned dummy submit trick. This ioctl
would allow us to set it directly without the dummy submit.
This may also open up possibilities for GPU drivers to move away from
implicit sync for their kernel driver uAPI and instead provide sync
files and rely on dma-buf import/export for communicating with other
implicit sync clients.
We make the explicit choice here to only allow setting RW fences which
translates to an exclusive fence on the dma_resv. There's no use for
read-only fences for communicating with other implicit sync userspace
and any such attempts are likely to be racy at best. When we got to
insert the RW fence, the actual fence we set as the new exclusive fence
is a combination of the sync_file provided by the user and all the other
fences on the dma_resv. This ensures that the newly added exclusive
fence will never signal before the old one would have and ensures that
we don't break any dma_resv contracts. We require userspace to specify
RW in the flags for symmetry with the export ioctl and in case we ever
want to support read fences in the future.
There is one downside here that's worth documenting: If two clients
writing to the same dma-buf using this API race with each other, their
actions on the dma-buf may happen in parallel or in an undefined order.
Both with and without this API, the pattern is the same: Collect all
the fences on dma-buf, submit work which depends on said fences, and
then set a new exclusive (write) fence on the dma-buf which depends on
said work. The difference is that, when it's all handled by the GPU
driver's submit ioctl, the three operations happen atomically under the
dma_resv lock. If two userspace submits race, one will happen before
the other. You aren't guaranteed which but you are guaranteed that
they're strictly ordered. If userspace manages the fences itself, then
these three operations happen separately and the two render operations
may happen genuinely in parallel or get interleaved. However, this is a
case of userspace racing with itself. As long as we ensure userspace
can't back the kernel into a corner, it should be fine.
v2 (Jason Ekstrand):
- Use a wrapper dma_fence_array of all fences including the new one
when importing an exclusive fence.
v3 (Jason Ekstrand):
- Lock around setting shared fences as well as exclusive
- Mark SIGNAL_SYNC_FILE as a read-write ioctl.
- Initialize ret to 0 in dma_buf_wait_sync_file
v4 (Jason Ekstrand):
- Use the new dma_resv_get_singleton helper
v5 (Jason Ekstrand):
- Rename the IOCTLs to import/export rather than wait/signal
- Drop the WRITE flag and always get/set the exclusive fence
v6 (Jason Ekstrand):
- Split import and export into separate patches
- New commit message
v7 (Daniel Vetter):
- Fix the uapi header to use the right struct in the ioctl
- Use a separate dma_buf_import_sync_file struct
- Add kerneldoc for dma_buf_import_sync_file
v8 (Jason Ekstrand):
- Rebase on Christian König's fence rework
v9 (Daniel Vetter):
- Fix -EINVAL checks for the flags parameter
- Add documentation about read/write fences
- Add documentation about the expected usage of import/export and
specifically call out the possible userspace race.
v10 (Simon Ser):
- Fix a typo in the docs
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Signed-off-by: Jason Ekstrand <jason.ekstrand@intel.com>
Signed-off-by: Jason Ekstrand <jason.ekstrand@collabora.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Simon Ser <contact@emersion.fr>
Link: https://patchwork.freedesktop.org/patch/msgid/20220608152142.14495-3-jason@jlekstrand.net
2022-06-08 23:21:42 +08:00
|
|
|
|
2022-08-03 05:01:58 +08:00
|
|
|
ret = dma_resv_reserve_fences(dmabuf->resv, num_fences);
|
|
|
|
if (!ret) {
|
|
|
|
dma_fence_unwrap_for_each(f, &iter, fence)
|
|
|
|
dma_resv_add_fence(dmabuf->resv, f, usage);
|
|
|
|
}
|
dma-buf: Add an API for importing sync files (v10)
This patch is analogous to the previous sync file export patch in that
it allows you to import a sync_file into a dma-buf. Unlike the previous
patch, however, this does add genuinely new functionality to dma-buf.
Without this, the only way to attach a sync_file to a dma-buf is to
submit a batch to your driver of choice which waits on the sync_file and
claims to write to the dma-buf. Even if said batch is a no-op, a submit
is typically way more overhead than just attaching a fence. A submit
may also imply extra synchronization with other work because it happens
on a hardware queue.
In the Vulkan world, this is useful for dealing with the out-fence from
vkQueuePresent. Current Linux window-systems (X11, Wayland, etc.) all
rely on dma-buf implicit sync. Since Vulkan is an explicit sync API, we
get a set of fences (VkSemaphores) in vkQueuePresent and have to stash
those as an exclusive (write) fence on the dma-buf. We handle it in
Mesa today with the above mentioned dummy submit trick. This ioctl
would allow us to set it directly without the dummy submit.
This may also open up possibilities for GPU drivers to move away from
implicit sync for their kernel driver uAPI and instead provide sync
files and rely on dma-buf import/export for communicating with other
implicit sync clients.
We make the explicit choice here to only allow setting RW fences which
translates to an exclusive fence on the dma_resv. There's no use for
read-only fences for communicating with other implicit sync userspace
and any such attempts are likely to be racy at best. When we got to
insert the RW fence, the actual fence we set as the new exclusive fence
is a combination of the sync_file provided by the user and all the other
fences on the dma_resv. This ensures that the newly added exclusive
fence will never signal before the old one would have and ensures that
we don't break any dma_resv contracts. We require userspace to specify
RW in the flags for symmetry with the export ioctl and in case we ever
want to support read fences in the future.
There is one downside here that's worth documenting: If two clients
writing to the same dma-buf using this API race with each other, their
actions on the dma-buf may happen in parallel or in an undefined order.
Both with and without this API, the pattern is the same: Collect all
the fences on dma-buf, submit work which depends on said fences, and
then set a new exclusive (write) fence on the dma-buf which depends on
said work. The difference is that, when it's all handled by the GPU
driver's submit ioctl, the three operations happen atomically under the
dma_resv lock. If two userspace submits race, one will happen before
the other. You aren't guaranteed which but you are guaranteed that
they're strictly ordered. If userspace manages the fences itself, then
these three operations happen separately and the two render operations
may happen genuinely in parallel or get interleaved. However, this is a
case of userspace racing with itself. As long as we ensure userspace
can't back the kernel into a corner, it should be fine.
v2 (Jason Ekstrand):
- Use a wrapper dma_fence_array of all fences including the new one
when importing an exclusive fence.
v3 (Jason Ekstrand):
- Lock around setting shared fences as well as exclusive
- Mark SIGNAL_SYNC_FILE as a read-write ioctl.
- Initialize ret to 0 in dma_buf_wait_sync_file
v4 (Jason Ekstrand):
- Use the new dma_resv_get_singleton helper
v5 (Jason Ekstrand):
- Rename the IOCTLs to import/export rather than wait/signal
- Drop the WRITE flag and always get/set the exclusive fence
v6 (Jason Ekstrand):
- Split import and export into separate patches
- New commit message
v7 (Daniel Vetter):
- Fix the uapi header to use the right struct in the ioctl
- Use a separate dma_buf_import_sync_file struct
- Add kerneldoc for dma_buf_import_sync_file
v8 (Jason Ekstrand):
- Rebase on Christian König's fence rework
v9 (Daniel Vetter):
- Fix -EINVAL checks for the flags parameter
- Add documentation about read/write fences
- Add documentation about the expected usage of import/export and
specifically call out the possible userspace race.
v10 (Simon Ser):
- Fix a typo in the docs
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Signed-off-by: Jason Ekstrand <jason.ekstrand@intel.com>
Signed-off-by: Jason Ekstrand <jason.ekstrand@collabora.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Simon Ser <contact@emersion.fr>
Link: https://patchwork.freedesktop.org/patch/msgid/20220608152142.14495-3-jason@jlekstrand.net
2022-06-08 23:21:42 +08:00
|
|
|
|
2022-08-03 05:01:58 +08:00
|
|
|
dma_resv_unlock(dmabuf->resv);
|
|
|
|
}
|
dma-buf: Add an API for importing sync files (v10)
This patch is analogous to the previous sync file export patch in that
it allows you to import a sync_file into a dma-buf. Unlike the previous
patch, however, this does add genuinely new functionality to dma-buf.
Without this, the only way to attach a sync_file to a dma-buf is to
submit a batch to your driver of choice which waits on the sync_file and
claims to write to the dma-buf. Even if said batch is a no-op, a submit
is typically way more overhead than just attaching a fence. A submit
may also imply extra synchronization with other work because it happens
on a hardware queue.
In the Vulkan world, this is useful for dealing with the out-fence from
vkQueuePresent. Current Linux window-systems (X11, Wayland, etc.) all
rely on dma-buf implicit sync. Since Vulkan is an explicit sync API, we
get a set of fences (VkSemaphores) in vkQueuePresent and have to stash
those as an exclusive (write) fence on the dma-buf. We handle it in
Mesa today with the above mentioned dummy submit trick. This ioctl
would allow us to set it directly without the dummy submit.
This may also open up possibilities for GPU drivers to move away from
implicit sync for their kernel driver uAPI and instead provide sync
files and rely on dma-buf import/export for communicating with other
implicit sync clients.
We make the explicit choice here to only allow setting RW fences which
translates to an exclusive fence on the dma_resv. There's no use for
read-only fences for communicating with other implicit sync userspace
and any such attempts are likely to be racy at best. When we got to
insert the RW fence, the actual fence we set as the new exclusive fence
is a combination of the sync_file provided by the user and all the other
fences on the dma_resv. This ensures that the newly added exclusive
fence will never signal before the old one would have and ensures that
we don't break any dma_resv contracts. We require userspace to specify
RW in the flags for symmetry with the export ioctl and in case we ever
want to support read fences in the future.
There is one downside here that's worth documenting: If two clients
writing to the same dma-buf using this API race with each other, their
actions on the dma-buf may happen in parallel or in an undefined order.
Both with and without this API, the pattern is the same: Collect all
the fences on dma-buf, submit work which depends on said fences, and
then set a new exclusive (write) fence on the dma-buf which depends on
said work. The difference is that, when it's all handled by the GPU
driver's submit ioctl, the three operations happen atomically under the
dma_resv lock. If two userspace submits race, one will happen before
the other. You aren't guaranteed which but you are guaranteed that
they're strictly ordered. If userspace manages the fences itself, then
these three operations happen separately and the two render operations
may happen genuinely in parallel or get interleaved. However, this is a
case of userspace racing with itself. As long as we ensure userspace
can't back the kernel into a corner, it should be fine.
v2 (Jason Ekstrand):
- Use a wrapper dma_fence_array of all fences including the new one
when importing an exclusive fence.
v3 (Jason Ekstrand):
- Lock around setting shared fences as well as exclusive
- Mark SIGNAL_SYNC_FILE as a read-write ioctl.
- Initialize ret to 0 in dma_buf_wait_sync_file
v4 (Jason Ekstrand):
- Use the new dma_resv_get_singleton helper
v5 (Jason Ekstrand):
- Rename the IOCTLs to import/export rather than wait/signal
- Drop the WRITE flag and always get/set the exclusive fence
v6 (Jason Ekstrand):
- Split import and export into separate patches
- New commit message
v7 (Daniel Vetter):
- Fix the uapi header to use the right struct in the ioctl
- Use a separate dma_buf_import_sync_file struct
- Add kerneldoc for dma_buf_import_sync_file
v8 (Jason Ekstrand):
- Rebase on Christian König's fence rework
v9 (Daniel Vetter):
- Fix -EINVAL checks for the flags parameter
- Add documentation about read/write fences
- Add documentation about the expected usage of import/export and
specifically call out the possible userspace race.
v10 (Simon Ser):
- Fix a typo in the docs
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Signed-off-by: Jason Ekstrand <jason.ekstrand@intel.com>
Signed-off-by: Jason Ekstrand <jason.ekstrand@collabora.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Simon Ser <contact@emersion.fr>
Link: https://patchwork.freedesktop.org/patch/msgid/20220608152142.14495-3-jason@jlekstrand.net
2022-06-08 23:21:42 +08:00
|
|
|
|
|
|
|
dma_fence_put(fence);
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
dma-buf: Add an API for exporting sync files (v14)
Modern userspace APIs like Vulkan are built on an explicit
synchronization model. This doesn't always play nicely with the
implicit synchronization used in the kernel and assumed by X11 and
Wayland. The client -> compositor half of the synchronization isn't too
bad, at least on intel, because we can control whether or not i915
synchronizes on the buffer and whether or not it's considered written.
The harder part is the compositor -> client synchronization when we get
the buffer back from the compositor. We're required to be able to
provide the client with a VkSemaphore and VkFence representing the point
in time where the window system (compositor and/or display) finished
using the buffer. With current APIs, it's very hard to do this in such
a way that we don't get confused by the Vulkan driver's access of the
buffer. In particular, once we tell the kernel that we're rendering to
the buffer again, any CPU waits on the buffer or GPU dependencies will
wait on some of the client rendering and not just the compositor.
This new IOCTL solves this problem by allowing us to get a snapshot of
the implicit synchronization state of a given dma-buf in the form of a
sync file. It's effectively the same as a poll() or I915_GEM_WAIT only,
instead of CPU waiting directly, it encapsulates the wait operation, at
the current moment in time, in a sync_file so we can check/wait on it
later. As long as the Vulkan driver does the sync_file export from the
dma-buf before we re-introduce it for rendering, it will only contain
fences from the compositor or display. This allows to accurately turn
it into a VkFence or VkSemaphore without any over-synchronization.
By making this an ioctl on the dma-buf itself, it allows this new
functionality to be used in an entirely driver-agnostic way without
having access to a DRM fd. This makes it ideal for use in driver-generic
code in Mesa or in a client such as a compositor where the DRM fd may be
hard to reach.
v2 (Jason Ekstrand):
- Use a wrapper dma_fence_array of all fences including the new one
when importing an exclusive fence.
v3 (Jason Ekstrand):
- Lock around setting shared fences as well as exclusive
- Mark SIGNAL_SYNC_FILE as a read-write ioctl.
- Initialize ret to 0 in dma_buf_wait_sync_file
v4 (Jason Ekstrand):
- Use the new dma_resv_get_singleton helper
v5 (Jason Ekstrand):
- Rename the IOCTLs to import/export rather than wait/signal
- Drop the WRITE flag and always get/set the exclusive fence
v6 (Jason Ekstrand):
- Drop the sync_file import as it was all-around sketchy and not nearly
as useful as import.
- Re-introduce READ/WRITE flag support for export
- Rework the commit message
v7 (Jason Ekstrand):
- Require at least one sync flag
- Fix a refcounting bug: dma_resv_get_excl() doesn't take a reference
- Use _rcu helpers since we're accessing the dma_resv read-only
v8 (Jason Ekstrand):
- Return -ENOMEM if the sync_file_create fails
- Predicate support on IS_ENABLED(CONFIG_SYNC_FILE)
v9 (Jason Ekstrand):
- Add documentation for the new ioctl
v10 (Jason Ekstrand):
- Go back to dma_buf_sync_file as the ioctl struct name
v11 (Daniel Vetter):
- Go back to dma_buf_export_sync_file as the ioctl struct name
- Better kerneldoc describing what the read/write flags do
v12 (Christian König):
- Document why we chose to make it an ioctl on dma-buf
v13 (Jason Ekstrand):
- Rebase on Christian König's fence rework
v14 (Daniel Vetter & Christian König):
- Use dma_rev_usage_rw to get the properly inverted usage to pass to
dma_resv_get_singleton()
- Clean up the sync_file and fd if copy_to_user() fails
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Signed-off-by: Jason Ekstrand <jason.ekstrand@intel.com>
Signed-off-by: Jason Ekstrand <jason.ekstrand@collabora.com>
Acked-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Simon Ser <contact@emersion.fr>
Link: https://patchwork.freedesktop.org/patch/msgid/20220608152142.14495-2-jason@jlekstrand.net
2022-06-08 23:21:41 +08:00
|
|
|
#endif
|
|
|
|
|
2016-02-12 06:04:51 +08:00
|
|
|
static long dma_buf_ioctl(struct file *file,
|
|
|
|
unsigned int cmd, unsigned long arg)
|
|
|
|
{
|
|
|
|
struct dma_buf *dmabuf;
|
|
|
|
struct dma_buf_sync sync;
|
|
|
|
enum dma_data_direction direction;
|
dma-buf, drm, ion: Propagate error code from dma_buf_start_cpu_access()
Drivers, especially i915.ko, can fail during the initial migration of a
dma-buf for CPU access. However, the error code from the driver was not
being propagated back to ioctl and so userspace was blissfully ignorant
of the failure. Rendering corruption ensues.
Whilst fixing the ioctl to return the error code from
dma_buf_start_cpu_access(), also do the same for
dma_buf_end_cpu_access(). For most drivers, dma_buf_end_cpu_access()
cannot fail. i915.ko however, as most drivers would, wants to avoid being
uninterruptible (as would be required to guarrantee no failure when
flushing the buffer to the device). As userspace already has to handle
errors from the SYNC_IOCTL, take advantage of this to be able to restart
the syscall across signals.
This fixes a coherency issue for i915.ko as well as reducing the
uninterruptible hold upon its BKL, the struct_mutex.
Fixes commit c11e391da2a8fe973c3c2398452000bed505851e
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Thu Feb 11 20:04:51 2016 -0200
dma-buf: Add ioctls to allow userspace to flush
Testcase: igt/gem_concurrent_blit/*dmabuf*interruptible
Testcase: igt/prime_mmap_coherency/ioctl-errors
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tiago Vignatti <tiago.vignatti@intel.com>
Cc: Stéphane Marchesin <marcheu@chromium.org>
Cc: David Herrmann <dh.herrmann@gmail.com>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Cc: Daniel Vetter <daniel.vetter@intel.com>
CC: linux-media@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linaro-mm-sig@lists.linaro.org
Cc: intel-gfx@lists.freedesktop.org
Cc: devel@driverdev.osuosl.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1458331359-2634-1-git-send-email-chris@chris-wilson.co.uk
2016-03-19 04:02:39 +08:00
|
|
|
int ret;
|
2016-02-12 06:04:51 +08:00
|
|
|
|
|
|
|
dmabuf = file->private_data;
|
|
|
|
|
|
|
|
switch (cmd) {
|
|
|
|
case DMA_BUF_IOCTL_SYNC:
|
|
|
|
if (copy_from_user(&sync, (void __user *) arg, sizeof(sync)))
|
|
|
|
return -EFAULT;
|
|
|
|
|
|
|
|
if (sync.flags & ~DMA_BUF_SYNC_VALID_FLAGS_MASK)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
switch (sync.flags & DMA_BUF_SYNC_RW) {
|
|
|
|
case DMA_BUF_SYNC_READ:
|
|
|
|
direction = DMA_FROM_DEVICE;
|
|
|
|
break;
|
|
|
|
case DMA_BUF_SYNC_WRITE:
|
|
|
|
direction = DMA_TO_DEVICE;
|
|
|
|
break;
|
|
|
|
case DMA_BUF_SYNC_RW:
|
|
|
|
direction = DMA_BIDIRECTIONAL;
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (sync.flags & DMA_BUF_SYNC_END)
|
dma-buf, drm, ion: Propagate error code from dma_buf_start_cpu_access()
Drivers, especially i915.ko, can fail during the initial migration of a
dma-buf for CPU access. However, the error code from the driver was not
being propagated back to ioctl and so userspace was blissfully ignorant
of the failure. Rendering corruption ensues.
Whilst fixing the ioctl to return the error code from
dma_buf_start_cpu_access(), also do the same for
dma_buf_end_cpu_access(). For most drivers, dma_buf_end_cpu_access()
cannot fail. i915.ko however, as most drivers would, wants to avoid being
uninterruptible (as would be required to guarrantee no failure when
flushing the buffer to the device). As userspace already has to handle
errors from the SYNC_IOCTL, take advantage of this to be able to restart
the syscall across signals.
This fixes a coherency issue for i915.ko as well as reducing the
uninterruptible hold upon its BKL, the struct_mutex.
Fixes commit c11e391da2a8fe973c3c2398452000bed505851e
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Thu Feb 11 20:04:51 2016 -0200
dma-buf: Add ioctls to allow userspace to flush
Testcase: igt/gem_concurrent_blit/*dmabuf*interruptible
Testcase: igt/prime_mmap_coherency/ioctl-errors
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tiago Vignatti <tiago.vignatti@intel.com>
Cc: Stéphane Marchesin <marcheu@chromium.org>
Cc: David Herrmann <dh.herrmann@gmail.com>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Cc: Daniel Vetter <daniel.vetter@intel.com>
CC: linux-media@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linaro-mm-sig@lists.linaro.org
Cc: intel-gfx@lists.freedesktop.org
Cc: devel@driverdev.osuosl.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1458331359-2634-1-git-send-email-chris@chris-wilson.co.uk
2016-03-19 04:02:39 +08:00
|
|
|
ret = dma_buf_end_cpu_access(dmabuf, direction);
|
2016-02-12 06:04:51 +08:00
|
|
|
else
|
dma-buf, drm, ion: Propagate error code from dma_buf_start_cpu_access()
Drivers, especially i915.ko, can fail during the initial migration of a
dma-buf for CPU access. However, the error code from the driver was not
being propagated back to ioctl and so userspace was blissfully ignorant
of the failure. Rendering corruption ensues.
Whilst fixing the ioctl to return the error code from
dma_buf_start_cpu_access(), also do the same for
dma_buf_end_cpu_access(). For most drivers, dma_buf_end_cpu_access()
cannot fail. i915.ko however, as most drivers would, wants to avoid being
uninterruptible (as would be required to guarrantee no failure when
flushing the buffer to the device). As userspace already has to handle
errors from the SYNC_IOCTL, take advantage of this to be able to restart
the syscall across signals.
This fixes a coherency issue for i915.ko as well as reducing the
uninterruptible hold upon its BKL, the struct_mutex.
Fixes commit c11e391da2a8fe973c3c2398452000bed505851e
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Thu Feb 11 20:04:51 2016 -0200
dma-buf: Add ioctls to allow userspace to flush
Testcase: igt/gem_concurrent_blit/*dmabuf*interruptible
Testcase: igt/prime_mmap_coherency/ioctl-errors
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tiago Vignatti <tiago.vignatti@intel.com>
Cc: Stéphane Marchesin <marcheu@chromium.org>
Cc: David Herrmann <dh.herrmann@gmail.com>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Cc: Daniel Vetter <daniel.vetter@intel.com>
CC: linux-media@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linaro-mm-sig@lists.linaro.org
Cc: intel-gfx@lists.freedesktop.org
Cc: devel@driverdev.osuosl.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1458331359-2634-1-git-send-email-chris@chris-wilson.co.uk
2016-03-19 04:02:39 +08:00
|
|
|
ret = dma_buf_begin_cpu_access(dmabuf, direction);
|
2016-02-12 06:04:51 +08:00
|
|
|
|
dma-buf, drm, ion: Propagate error code from dma_buf_start_cpu_access()
Drivers, especially i915.ko, can fail during the initial migration of a
dma-buf for CPU access. However, the error code from the driver was not
being propagated back to ioctl and so userspace was blissfully ignorant
of the failure. Rendering corruption ensues.
Whilst fixing the ioctl to return the error code from
dma_buf_start_cpu_access(), also do the same for
dma_buf_end_cpu_access(). For most drivers, dma_buf_end_cpu_access()
cannot fail. i915.ko however, as most drivers would, wants to avoid being
uninterruptible (as would be required to guarrantee no failure when
flushing the buffer to the device). As userspace already has to handle
errors from the SYNC_IOCTL, take advantage of this to be able to restart
the syscall across signals.
This fixes a coherency issue for i915.ko as well as reducing the
uninterruptible hold upon its BKL, the struct_mutex.
Fixes commit c11e391da2a8fe973c3c2398452000bed505851e
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Thu Feb 11 20:04:51 2016 -0200
dma-buf: Add ioctls to allow userspace to flush
Testcase: igt/gem_concurrent_blit/*dmabuf*interruptible
Testcase: igt/prime_mmap_coherency/ioctl-errors
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tiago Vignatti <tiago.vignatti@intel.com>
Cc: Stéphane Marchesin <marcheu@chromium.org>
Cc: David Herrmann <dh.herrmann@gmail.com>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Cc: Daniel Vetter <daniel.vetter@intel.com>
CC: linux-media@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linaro-mm-sig@lists.linaro.org
Cc: intel-gfx@lists.freedesktop.org
Cc: devel@driverdev.osuosl.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1458331359-2634-1-git-send-email-chris@chris-wilson.co.uk
2016-03-19 04:02:39 +08:00
|
|
|
return ret;
|
2019-06-14 06:34:07 +08:00
|
|
|
|
2020-04-07 21:30:02 +08:00
|
|
|
case DMA_BUF_SET_NAME_A:
|
|
|
|
case DMA_BUF_SET_NAME_B:
|
2019-06-14 06:34:07 +08:00
|
|
|
return dma_buf_set_name(dmabuf, (const char __user *)arg);
|
|
|
|
|
dma-buf: Add an API for exporting sync files (v14)
Modern userspace APIs like Vulkan are built on an explicit
synchronization model. This doesn't always play nicely with the
implicit synchronization used in the kernel and assumed by X11 and
Wayland. The client -> compositor half of the synchronization isn't too
bad, at least on intel, because we can control whether or not i915
synchronizes on the buffer and whether or not it's considered written.
The harder part is the compositor -> client synchronization when we get
the buffer back from the compositor. We're required to be able to
provide the client with a VkSemaphore and VkFence representing the point
in time where the window system (compositor and/or display) finished
using the buffer. With current APIs, it's very hard to do this in such
a way that we don't get confused by the Vulkan driver's access of the
buffer. In particular, once we tell the kernel that we're rendering to
the buffer again, any CPU waits on the buffer or GPU dependencies will
wait on some of the client rendering and not just the compositor.
This new IOCTL solves this problem by allowing us to get a snapshot of
the implicit synchronization state of a given dma-buf in the form of a
sync file. It's effectively the same as a poll() or I915_GEM_WAIT only,
instead of CPU waiting directly, it encapsulates the wait operation, at
the current moment in time, in a sync_file so we can check/wait on it
later. As long as the Vulkan driver does the sync_file export from the
dma-buf before we re-introduce it for rendering, it will only contain
fences from the compositor or display. This allows to accurately turn
it into a VkFence or VkSemaphore without any over-synchronization.
By making this an ioctl on the dma-buf itself, it allows this new
functionality to be used in an entirely driver-agnostic way without
having access to a DRM fd. This makes it ideal for use in driver-generic
code in Mesa or in a client such as a compositor where the DRM fd may be
hard to reach.
v2 (Jason Ekstrand):
- Use a wrapper dma_fence_array of all fences including the new one
when importing an exclusive fence.
v3 (Jason Ekstrand):
- Lock around setting shared fences as well as exclusive
- Mark SIGNAL_SYNC_FILE as a read-write ioctl.
- Initialize ret to 0 in dma_buf_wait_sync_file
v4 (Jason Ekstrand):
- Use the new dma_resv_get_singleton helper
v5 (Jason Ekstrand):
- Rename the IOCTLs to import/export rather than wait/signal
- Drop the WRITE flag and always get/set the exclusive fence
v6 (Jason Ekstrand):
- Drop the sync_file import as it was all-around sketchy and not nearly
as useful as import.
- Re-introduce READ/WRITE flag support for export
- Rework the commit message
v7 (Jason Ekstrand):
- Require at least one sync flag
- Fix a refcounting bug: dma_resv_get_excl() doesn't take a reference
- Use _rcu helpers since we're accessing the dma_resv read-only
v8 (Jason Ekstrand):
- Return -ENOMEM if the sync_file_create fails
- Predicate support on IS_ENABLED(CONFIG_SYNC_FILE)
v9 (Jason Ekstrand):
- Add documentation for the new ioctl
v10 (Jason Ekstrand):
- Go back to dma_buf_sync_file as the ioctl struct name
v11 (Daniel Vetter):
- Go back to dma_buf_export_sync_file as the ioctl struct name
- Better kerneldoc describing what the read/write flags do
v12 (Christian König):
- Document why we chose to make it an ioctl on dma-buf
v13 (Jason Ekstrand):
- Rebase on Christian König's fence rework
v14 (Daniel Vetter & Christian König):
- Use dma_rev_usage_rw to get the properly inverted usage to pass to
dma_resv_get_singleton()
- Clean up the sync_file and fd if copy_to_user() fails
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Signed-off-by: Jason Ekstrand <jason.ekstrand@intel.com>
Signed-off-by: Jason Ekstrand <jason.ekstrand@collabora.com>
Acked-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Simon Ser <contact@emersion.fr>
Link: https://patchwork.freedesktop.org/patch/msgid/20220608152142.14495-2-jason@jlekstrand.net
2022-06-08 23:21:41 +08:00
|
|
|
#if IS_ENABLED(CONFIG_SYNC_FILE)
|
|
|
|
case DMA_BUF_IOCTL_EXPORT_SYNC_FILE:
|
|
|
|
return dma_buf_export_sync_file(dmabuf, (void __user *)arg);
|
dma-buf: Add an API for importing sync files (v10)
This patch is analogous to the previous sync file export patch in that
it allows you to import a sync_file into a dma-buf. Unlike the previous
patch, however, this does add genuinely new functionality to dma-buf.
Without this, the only way to attach a sync_file to a dma-buf is to
submit a batch to your driver of choice which waits on the sync_file and
claims to write to the dma-buf. Even if said batch is a no-op, a submit
is typically way more overhead than just attaching a fence. A submit
may also imply extra synchronization with other work because it happens
on a hardware queue.
In the Vulkan world, this is useful for dealing with the out-fence from
vkQueuePresent. Current Linux window-systems (X11, Wayland, etc.) all
rely on dma-buf implicit sync. Since Vulkan is an explicit sync API, we
get a set of fences (VkSemaphores) in vkQueuePresent and have to stash
those as an exclusive (write) fence on the dma-buf. We handle it in
Mesa today with the above mentioned dummy submit trick. This ioctl
would allow us to set it directly without the dummy submit.
This may also open up possibilities for GPU drivers to move away from
implicit sync for their kernel driver uAPI and instead provide sync
files and rely on dma-buf import/export for communicating with other
implicit sync clients.
We make the explicit choice here to only allow setting RW fences which
translates to an exclusive fence on the dma_resv. There's no use for
read-only fences for communicating with other implicit sync userspace
and any such attempts are likely to be racy at best. When we got to
insert the RW fence, the actual fence we set as the new exclusive fence
is a combination of the sync_file provided by the user and all the other
fences on the dma_resv. This ensures that the newly added exclusive
fence will never signal before the old one would have and ensures that
we don't break any dma_resv contracts. We require userspace to specify
RW in the flags for symmetry with the export ioctl and in case we ever
want to support read fences in the future.
There is one downside here that's worth documenting: If two clients
writing to the same dma-buf using this API race with each other, their
actions on the dma-buf may happen in parallel or in an undefined order.
Both with and without this API, the pattern is the same: Collect all
the fences on dma-buf, submit work which depends on said fences, and
then set a new exclusive (write) fence on the dma-buf which depends on
said work. The difference is that, when it's all handled by the GPU
driver's submit ioctl, the three operations happen atomically under the
dma_resv lock. If two userspace submits race, one will happen before
the other. You aren't guaranteed which but you are guaranteed that
they're strictly ordered. If userspace manages the fences itself, then
these three operations happen separately and the two render operations
may happen genuinely in parallel or get interleaved. However, this is a
case of userspace racing with itself. As long as we ensure userspace
can't back the kernel into a corner, it should be fine.
v2 (Jason Ekstrand):
- Use a wrapper dma_fence_array of all fences including the new one
when importing an exclusive fence.
v3 (Jason Ekstrand):
- Lock around setting shared fences as well as exclusive
- Mark SIGNAL_SYNC_FILE as a read-write ioctl.
- Initialize ret to 0 in dma_buf_wait_sync_file
v4 (Jason Ekstrand):
- Use the new dma_resv_get_singleton helper
v5 (Jason Ekstrand):
- Rename the IOCTLs to import/export rather than wait/signal
- Drop the WRITE flag and always get/set the exclusive fence
v6 (Jason Ekstrand):
- Split import and export into separate patches
- New commit message
v7 (Daniel Vetter):
- Fix the uapi header to use the right struct in the ioctl
- Use a separate dma_buf_import_sync_file struct
- Add kerneldoc for dma_buf_import_sync_file
v8 (Jason Ekstrand):
- Rebase on Christian König's fence rework
v9 (Daniel Vetter):
- Fix -EINVAL checks for the flags parameter
- Add documentation about read/write fences
- Add documentation about the expected usage of import/export and
specifically call out the possible userspace race.
v10 (Simon Ser):
- Fix a typo in the docs
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Signed-off-by: Jason Ekstrand <jason.ekstrand@intel.com>
Signed-off-by: Jason Ekstrand <jason.ekstrand@collabora.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Simon Ser <contact@emersion.fr>
Link: https://patchwork.freedesktop.org/patch/msgid/20220608152142.14495-3-jason@jlekstrand.net
2022-06-08 23:21:42 +08:00
|
|
|
case DMA_BUF_IOCTL_IMPORT_SYNC_FILE:
|
|
|
|
return dma_buf_import_sync_file(dmabuf, (const void __user *)arg);
|
dma-buf: Add an API for exporting sync files (v14)
Modern userspace APIs like Vulkan are built on an explicit
synchronization model. This doesn't always play nicely with the
implicit synchronization used in the kernel and assumed by X11 and
Wayland. The client -> compositor half of the synchronization isn't too
bad, at least on intel, because we can control whether or not i915
synchronizes on the buffer and whether or not it's considered written.
The harder part is the compositor -> client synchronization when we get
the buffer back from the compositor. We're required to be able to
provide the client with a VkSemaphore and VkFence representing the point
in time where the window system (compositor and/or display) finished
using the buffer. With current APIs, it's very hard to do this in such
a way that we don't get confused by the Vulkan driver's access of the
buffer. In particular, once we tell the kernel that we're rendering to
the buffer again, any CPU waits on the buffer or GPU dependencies will
wait on some of the client rendering and not just the compositor.
This new IOCTL solves this problem by allowing us to get a snapshot of
the implicit synchronization state of a given dma-buf in the form of a
sync file. It's effectively the same as a poll() or I915_GEM_WAIT only,
instead of CPU waiting directly, it encapsulates the wait operation, at
the current moment in time, in a sync_file so we can check/wait on it
later. As long as the Vulkan driver does the sync_file export from the
dma-buf before we re-introduce it for rendering, it will only contain
fences from the compositor or display. This allows to accurately turn
it into a VkFence or VkSemaphore without any over-synchronization.
By making this an ioctl on the dma-buf itself, it allows this new
functionality to be used in an entirely driver-agnostic way without
having access to a DRM fd. This makes it ideal for use in driver-generic
code in Mesa or in a client such as a compositor where the DRM fd may be
hard to reach.
v2 (Jason Ekstrand):
- Use a wrapper dma_fence_array of all fences including the new one
when importing an exclusive fence.
v3 (Jason Ekstrand):
- Lock around setting shared fences as well as exclusive
- Mark SIGNAL_SYNC_FILE as a read-write ioctl.
- Initialize ret to 0 in dma_buf_wait_sync_file
v4 (Jason Ekstrand):
- Use the new dma_resv_get_singleton helper
v5 (Jason Ekstrand):
- Rename the IOCTLs to import/export rather than wait/signal
- Drop the WRITE flag and always get/set the exclusive fence
v6 (Jason Ekstrand):
- Drop the sync_file import as it was all-around sketchy and not nearly
as useful as import.
- Re-introduce READ/WRITE flag support for export
- Rework the commit message
v7 (Jason Ekstrand):
- Require at least one sync flag
- Fix a refcounting bug: dma_resv_get_excl() doesn't take a reference
- Use _rcu helpers since we're accessing the dma_resv read-only
v8 (Jason Ekstrand):
- Return -ENOMEM if the sync_file_create fails
- Predicate support on IS_ENABLED(CONFIG_SYNC_FILE)
v9 (Jason Ekstrand):
- Add documentation for the new ioctl
v10 (Jason Ekstrand):
- Go back to dma_buf_sync_file as the ioctl struct name
v11 (Daniel Vetter):
- Go back to dma_buf_export_sync_file as the ioctl struct name
- Better kerneldoc describing what the read/write flags do
v12 (Christian König):
- Document why we chose to make it an ioctl on dma-buf
v13 (Jason Ekstrand):
- Rebase on Christian König's fence rework
v14 (Daniel Vetter & Christian König):
- Use dma_rev_usage_rw to get the properly inverted usage to pass to
dma_resv_get_singleton()
- Clean up the sync_file and fd if copy_to_user() fails
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Signed-off-by: Jason Ekstrand <jason.ekstrand@intel.com>
Signed-off-by: Jason Ekstrand <jason.ekstrand@collabora.com>
Acked-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Simon Ser <contact@emersion.fr>
Link: https://patchwork.freedesktop.org/patch/msgid/20220608152142.14495-2-jason@jlekstrand.net
2022-06-08 23:21:41 +08:00
|
|
|
#endif
|
|
|
|
|
2016-02-12 06:04:51 +08:00
|
|
|
default:
|
|
|
|
return -ENOTTY;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-06-14 06:34:08 +08:00
|
|
|
static void dma_buf_show_fdinfo(struct seq_file *m, struct file *file)
|
|
|
|
{
|
|
|
|
struct dma_buf *dmabuf = file->private_data;
|
|
|
|
|
|
|
|
seq_printf(m, "size:\t%zu\n", dmabuf->size);
|
|
|
|
/* Don't count the temporary reference taken inside procfs seq_show */
|
|
|
|
seq_printf(m, "count:\t%ld\n", file_count(dmabuf->file) - 1);
|
|
|
|
seq_printf(m, "exp_name:\t%s\n", dmabuf->exp_name);
|
2020-06-19 19:57:19 +08:00
|
|
|
spin_lock(&dmabuf->name_lock);
|
2019-06-14 06:34:08 +08:00
|
|
|
if (dmabuf->name)
|
|
|
|
seq_printf(m, "name:\t%s\n", dmabuf->name);
|
2020-06-19 19:57:19 +08:00
|
|
|
spin_unlock(&dmabuf->name_lock);
|
2019-06-14 06:34:08 +08:00
|
|
|
}
|
|
|
|
|
dma-buf: Introduce dma buffer sharing mechanism
This is the first step in defining a dma buffer sharing mechanism.
A new buffer object dma_buf is added, with operations and API to allow easy
sharing of this buffer object across devices.
The framework allows:
- creation of a buffer object, its association with a file pointer, and
associated allocator-defined operations on that buffer. This operation is
called the 'export' operation.
- different devices to 'attach' themselves to this exported buffer object, to
facilitate backing storage negotiation, using dma_buf_attach() API.
- the exported buffer object to be shared with the other entity by asking for
its 'file-descriptor (fd)', and sharing the fd across.
- a received fd to get the buffer object back, where it can be accessed using
the associated exporter-defined operations.
- the exporter and user to share the scatterlist associated with this buffer
object using map_dma_buf and unmap_dma_buf operations.
Atleast one 'attach()' call is required to be made prior to calling the
map_dma_buf() operation.
Couple of building blocks in map_dma_buf() are added to ease introduction
of sync'ing across exporter and users, and late allocation by the exporter.
For this first version, this framework will work with certain conditions:
- *ONLY* exporter will be allowed to mmap to userspace (outside of this
framework - mmap is not a buffer object operation),
- currently, *ONLY* users that do not need CPU access to the buffer are
allowed.
More details are there in the documentation patch.
This is based on design suggestions from many people at the mini-summits[1],
most notably from Arnd Bergmann <arnd@arndb.de>, Rob Clark <rob@ti.com> and
Daniel Vetter <daniel@ffwll.ch>.
The implementation is inspired from proof-of-concept patch-set from
Tomasz Stanislawski <t.stanislaws@samsung.com>, who demonstrated buffer sharing
between two v4l2 devices. [2]
[1]: https://wiki.linaro.org/OfficeofCTO/MemoryManagement
[2]: http://lwn.net/Articles/454389
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
Signed-off-by: Sumit Semwal <sumit.semwal@ti.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-and-Tested-by: Rob Clark <rob.clark@linaro.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-12-26 17:23:15 +08:00
|
|
|
static const struct file_operations dma_buf_fops = {
|
2021-01-05 22:36:39 +08:00
|
|
|
.release = dma_buf_file_release,
|
dma-buf: mmap support
Compared to Rob Clark's RFC I've ditched the prepare/finish hooks
and corresponding ioctls on the dma_buf file. The major reason for
that is that many people seem to be under the impression that this is
also for synchronization with outstanding asynchronous processsing.
I'm pretty massively opposed to this because:
- It boils down reinventing a new rather general-purpose userspace
synchronization interface. If we look at things like futexes, this
is hard to get right.
- Furthermore a lot of kernel code has to interact with this
synchronization primitive. This smells a look like the dri1 hw_lock,
a horror show I prefer not to reinvent.
- Even more fun is that multiple different subsystems would interact
here, so we have plenty of opportunities to create funny deadlock
scenarios.
I think synchronization is a wholesale different problem from data
sharing and should be tackled as an orthogonal problem.
Now we could demand that prepare/finish may only ensure cache
coherency (as Rob intended), but that runs up into the next problem:
We not only need mmap support to facilitate sw-only processing nodes
in a pipeline (without jumping through hoops by importing the dma_buf
into some sw-access only importer), which allows for a nicer
ION->dma-buf upgrade path for existing Android userspace. We also need
mmap support for existing importing subsystems to support existing
userspace libraries. And a loot of these subsystems are expected to
export coherent userspace mappings.
So prepare/finish can only ever be optional and the exporter /needs/
to support coherent mappings. Given that mmap access is always
somewhat fallback-y in nature I've decided to drop this optimization,
instead of just making it optional. If we demonstrate a clear need for
this, supported by benchmark results, we can always add it in again
later as an optional extension.
Other differences compared to Rob's RFC is the above mentioned support
for mapping a dma-buf through facilities provided by the importer.
Which results in mmap support no longer being optional.
Note that this dma-buf mmap patch does _not_ support every possible
insanity an existing subsystem could pull of with mmap: Because it
does not allow to intercept pagefaults and shoot down ptes importing
subsystems can't add some magic of their own at these points (e.g. to
automatically synchronize with outstanding rendering or set up some
special resources). I've done a cursory read through a few mmap
implementions of various subsytems and I'm hopeful that we can avoid
this (and the complexity it'd bring with it).
Additonally I've extended the documentation a bit to explain the hows
and whys of this mmap extension.
In case we ever want to add support for explicitly cache maneged
userspace mmap with a prepare/finish ioctl pair, we could specify that
userspace needs to mmap a different part of the dma_buf, e.g. the
range starting at dma_buf->size up to dma_buf->size*2. This works
because the size of a dma_buf is invariant over it's lifetime. The
exporter would obviously need to fall back to coherent mappings for
both ranges if a legacy clients maps the coherent range and the
architecture cannot suppor conflicting caching policies. Also, this
would obviously be optional and userspace needs to be able to fall
back to coherent mappings.
v2:
- Spelling fixes from Rob Clark.
- Compile fix for !DMA_BUF from Rob Clark.
- Extend commit message to explain how explicitly cache managed mmap
support could be added later.
- Extend the documentation with implementations notes for exporters
that need to manually fake coherency.
v3:
- dma_buf pointer initialization goof-up noticed by Rebecca Schultz
Zavin.
Cc: Rob Clark <rob.clark@linaro.org>
Cc: Rebecca Schultz Zavin <rebecca@android.com>
Acked-by: Rob Clark <rob.clark@linaro.org>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
2012-04-24 17:08:52 +08:00
|
|
|
.mmap = dma_buf_mmap_internal,
|
2013-09-10 14:06:45 +08:00
|
|
|
.llseek = dma_buf_llseek,
|
2014-07-01 18:57:43 +08:00
|
|
|
.poll = dma_buf_poll,
|
2016-02-12 06:04:51 +08:00
|
|
|
.unlocked_ioctl = dma_buf_ioctl,
|
2018-09-12 03:59:08 +08:00
|
|
|
.compat_ioctl = compat_ptr_ioctl,
|
2019-06-14 06:34:08 +08:00
|
|
|
.show_fdinfo = dma_buf_show_fdinfo,
|
dma-buf: Introduce dma buffer sharing mechanism
This is the first step in defining a dma buffer sharing mechanism.
A new buffer object dma_buf is added, with operations and API to allow easy
sharing of this buffer object across devices.
The framework allows:
- creation of a buffer object, its association with a file pointer, and
associated allocator-defined operations on that buffer. This operation is
called the 'export' operation.
- different devices to 'attach' themselves to this exported buffer object, to
facilitate backing storage negotiation, using dma_buf_attach() API.
- the exported buffer object to be shared with the other entity by asking for
its 'file-descriptor (fd)', and sharing the fd across.
- a received fd to get the buffer object back, where it can be accessed using
the associated exporter-defined operations.
- the exporter and user to share the scatterlist associated with this buffer
object using map_dma_buf and unmap_dma_buf operations.
Atleast one 'attach()' call is required to be made prior to calling the
map_dma_buf() operation.
Couple of building blocks in map_dma_buf() are added to ease introduction
of sync'ing across exporter and users, and late allocation by the exporter.
For this first version, this framework will work with certain conditions:
- *ONLY* exporter will be allowed to mmap to userspace (outside of this
framework - mmap is not a buffer object operation),
- currently, *ONLY* users that do not need CPU access to the buffer are
allowed.
More details are there in the documentation patch.
This is based on design suggestions from many people at the mini-summits[1],
most notably from Arnd Bergmann <arnd@arndb.de>, Rob Clark <rob@ti.com> and
Daniel Vetter <daniel@ffwll.ch>.
The implementation is inspired from proof-of-concept patch-set from
Tomasz Stanislawski <t.stanislaws@samsung.com>, who demonstrated buffer sharing
between two v4l2 devices. [2]
[1]: https://wiki.linaro.org/OfficeofCTO/MemoryManagement
[2]: http://lwn.net/Articles/454389
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
Signed-off-by: Sumit Semwal <sumit.semwal@ti.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-and-Tested-by: Rob Clark <rob.clark@linaro.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-12-26 17:23:15 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
/*
|
|
|
|
* is_dma_buf_file - Check if struct file* is associated with dma_buf
|
|
|
|
*/
|
|
|
|
static inline int is_dma_buf_file(struct file *file)
|
|
|
|
{
|
|
|
|
return file->f_op == &dma_buf_fops;
|
|
|
|
}
|
|
|
|
|
2022-12-06 21:07:49 +08:00
|
|
|
static struct file *dma_buf_getfile(size_t size, int flags)
|
2019-06-14 06:34:06 +08:00
|
|
|
{
|
2022-05-13 19:28:16 +08:00
|
|
|
static atomic64_t dmabuf_inode = ATOMIC64_INIT(0);
|
2019-06-14 06:34:06 +08:00
|
|
|
struct inode *inode = alloc_anon_inode(dma_buf_mnt->mnt_sb);
|
2022-12-06 21:07:49 +08:00
|
|
|
struct file *file;
|
2019-06-14 06:34:06 +08:00
|
|
|
|
|
|
|
if (IS_ERR(inode))
|
|
|
|
return ERR_CAST(inode);
|
|
|
|
|
2022-12-06 21:07:49 +08:00
|
|
|
inode->i_size = size;
|
|
|
|
inode_set_bytes(inode, size);
|
2019-06-14 06:34:06 +08:00
|
|
|
|
2022-05-13 19:28:16 +08:00
|
|
|
/*
|
|
|
|
* The ->i_ino acquired from get_next_ino() is not unique thus
|
|
|
|
* not suitable for using it as dentry name by dmabuf stats.
|
|
|
|
* Override ->i_ino with the unique and dmabuffs specific
|
|
|
|
* value.
|
|
|
|
*/
|
|
|
|
inode->i_ino = atomic64_add_return(1, &dmabuf_inode);
|
2021-06-21 01:53:35 +08:00
|
|
|
flags &= O_ACCMODE | O_NONBLOCK;
|
2019-06-14 06:34:06 +08:00
|
|
|
file = alloc_file_pseudo(inode, dma_buf_mnt, "dmabuf",
|
|
|
|
flags, &dma_buf_fops);
|
|
|
|
if (IS_ERR(file))
|
|
|
|
goto err_alloc_file;
|
|
|
|
|
|
|
|
return file;
|
|
|
|
|
|
|
|
err_alloc_file:
|
|
|
|
iput(inode);
|
|
|
|
return file;
|
|
|
|
}
|
|
|
|
|
2016-12-10 02:53:07 +08:00
|
|
|
/**
|
|
|
|
* DOC: dma buf device access
|
|
|
|
*
|
|
|
|
* For device DMA access to a shared DMA buffer the usual sequence of operations
|
|
|
|
* is fairly simple:
|
|
|
|
*
|
|
|
|
* 1. The exporter defines his exporter instance using
|
|
|
|
* DEFINE_DMA_BUF_EXPORT_INFO() and calls dma_buf_export() to wrap a private
|
|
|
|
* buffer object into a &dma_buf. It then exports that &dma_buf to userspace
|
|
|
|
* as a file descriptor by calling dma_buf_fd().
|
|
|
|
*
|
|
|
|
* 2. Userspace passes this file-descriptors to all drivers it wants this buffer
|
2022-04-02 21:44:13 +08:00
|
|
|
* to share with: First the file descriptor is converted to a &dma_buf using
|
2017-11-01 22:06:30 +08:00
|
|
|
* dma_buf_get(). Then the buffer is attached to the device using
|
2016-12-10 02:53:07 +08:00
|
|
|
* dma_buf_attach().
|
|
|
|
*
|
|
|
|
* Up to this stage the exporter is still free to migrate or reallocate the
|
|
|
|
* backing storage.
|
|
|
|
*
|
2017-11-01 22:06:30 +08:00
|
|
|
* 3. Once the buffer is attached to all devices userspace can initiate DMA
|
2016-12-10 02:53:07 +08:00
|
|
|
* access to the shared buffer. In the kernel this is done by calling
|
|
|
|
* dma_buf_map_attachment() and dma_buf_unmap_attachment().
|
|
|
|
*
|
|
|
|
* 4. Once a driver is done with a shared buffer it needs to call
|
|
|
|
* dma_buf_detach() (after cleaning up any mappings) and then release the
|
2020-12-11 23:58:41 +08:00
|
|
|
* reference acquired with dma_buf_get() by calling dma_buf_put().
|
2016-12-10 02:53:07 +08:00
|
|
|
*
|
|
|
|
* For the detailed semantics exporters are expected to implement see
|
|
|
|
* &dma_buf_ops.
|
|
|
|
*/
|
|
|
|
|
dma-buf: Introduce dma buffer sharing mechanism
This is the first step in defining a dma buffer sharing mechanism.
A new buffer object dma_buf is added, with operations and API to allow easy
sharing of this buffer object across devices.
The framework allows:
- creation of a buffer object, its association with a file pointer, and
associated allocator-defined operations on that buffer. This operation is
called the 'export' operation.
- different devices to 'attach' themselves to this exported buffer object, to
facilitate backing storage negotiation, using dma_buf_attach() API.
- the exported buffer object to be shared with the other entity by asking for
its 'file-descriptor (fd)', and sharing the fd across.
- a received fd to get the buffer object back, where it can be accessed using
the associated exporter-defined operations.
- the exporter and user to share the scatterlist associated with this buffer
object using map_dma_buf and unmap_dma_buf operations.
Atleast one 'attach()' call is required to be made prior to calling the
map_dma_buf() operation.
Couple of building blocks in map_dma_buf() are added to ease introduction
of sync'ing across exporter and users, and late allocation by the exporter.
For this first version, this framework will work with certain conditions:
- *ONLY* exporter will be allowed to mmap to userspace (outside of this
framework - mmap is not a buffer object operation),
- currently, *ONLY* users that do not need CPU access to the buffer are
allowed.
More details are there in the documentation patch.
This is based on design suggestions from many people at the mini-summits[1],
most notably from Arnd Bergmann <arnd@arndb.de>, Rob Clark <rob@ti.com> and
Daniel Vetter <daniel@ffwll.ch>.
The implementation is inspired from proof-of-concept patch-set from
Tomasz Stanislawski <t.stanislaws@samsung.com>, who demonstrated buffer sharing
between two v4l2 devices. [2]
[1]: https://wiki.linaro.org/OfficeofCTO/MemoryManagement
[2]: http://lwn.net/Articles/454389
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
Signed-off-by: Sumit Semwal <sumit.semwal@ti.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-and-Tested-by: Rob Clark <rob.clark@linaro.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-12-26 17:23:15 +08:00
|
|
|
/**
|
2015-01-23 15:23:43 +08:00
|
|
|
* dma_buf_export - Creates a new dma_buf, and associates an anon file
|
dma-buf: Introduce dma buffer sharing mechanism
This is the first step in defining a dma buffer sharing mechanism.
A new buffer object dma_buf is added, with operations and API to allow easy
sharing of this buffer object across devices.
The framework allows:
- creation of a buffer object, its association with a file pointer, and
associated allocator-defined operations on that buffer. This operation is
called the 'export' operation.
- different devices to 'attach' themselves to this exported buffer object, to
facilitate backing storage negotiation, using dma_buf_attach() API.
- the exported buffer object to be shared with the other entity by asking for
its 'file-descriptor (fd)', and sharing the fd across.
- a received fd to get the buffer object back, where it can be accessed using
the associated exporter-defined operations.
- the exporter and user to share the scatterlist associated with this buffer
object using map_dma_buf and unmap_dma_buf operations.
Atleast one 'attach()' call is required to be made prior to calling the
map_dma_buf() operation.
Couple of building blocks in map_dma_buf() are added to ease introduction
of sync'ing across exporter and users, and late allocation by the exporter.
For this first version, this framework will work with certain conditions:
- *ONLY* exporter will be allowed to mmap to userspace (outside of this
framework - mmap is not a buffer object operation),
- currently, *ONLY* users that do not need CPU access to the buffer are
allowed.
More details are there in the documentation patch.
This is based on design suggestions from many people at the mini-summits[1],
most notably from Arnd Bergmann <arnd@arndb.de>, Rob Clark <rob@ti.com> and
Daniel Vetter <daniel@ffwll.ch>.
The implementation is inspired from proof-of-concept patch-set from
Tomasz Stanislawski <t.stanislaws@samsung.com>, who demonstrated buffer sharing
between two v4l2 devices. [2]
[1]: https://wiki.linaro.org/OfficeofCTO/MemoryManagement
[2]: http://lwn.net/Articles/454389
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
Signed-off-by: Sumit Semwal <sumit.semwal@ti.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-and-Tested-by: Rob Clark <rob.clark@linaro.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-12-26 17:23:15 +08:00
|
|
|
* with this buffer, so it can be exported.
|
|
|
|
* Also connect the allocator specific data and ops to the buffer.
|
2013-03-22 20:52:16 +08:00
|
|
|
* Additionally, provide a name string for exporter; useful in debugging.
|
dma-buf: Introduce dma buffer sharing mechanism
This is the first step in defining a dma buffer sharing mechanism.
A new buffer object dma_buf is added, with operations and API to allow easy
sharing of this buffer object across devices.
The framework allows:
- creation of a buffer object, its association with a file pointer, and
associated allocator-defined operations on that buffer. This operation is
called the 'export' operation.
- different devices to 'attach' themselves to this exported buffer object, to
facilitate backing storage negotiation, using dma_buf_attach() API.
- the exported buffer object to be shared with the other entity by asking for
its 'file-descriptor (fd)', and sharing the fd across.
- a received fd to get the buffer object back, where it can be accessed using
the associated exporter-defined operations.
- the exporter and user to share the scatterlist associated with this buffer
object using map_dma_buf and unmap_dma_buf operations.
Atleast one 'attach()' call is required to be made prior to calling the
map_dma_buf() operation.
Couple of building blocks in map_dma_buf() are added to ease introduction
of sync'ing across exporter and users, and late allocation by the exporter.
For this first version, this framework will work with certain conditions:
- *ONLY* exporter will be allowed to mmap to userspace (outside of this
framework - mmap is not a buffer object operation),
- currently, *ONLY* users that do not need CPU access to the buffer are
allowed.
More details are there in the documentation patch.
This is based on design suggestions from many people at the mini-summits[1],
most notably from Arnd Bergmann <arnd@arndb.de>, Rob Clark <rob@ti.com> and
Daniel Vetter <daniel@ffwll.ch>.
The implementation is inspired from proof-of-concept patch-set from
Tomasz Stanislawski <t.stanislaws@samsung.com>, who demonstrated buffer sharing
between two v4l2 devices. [2]
[1]: https://wiki.linaro.org/OfficeofCTO/MemoryManagement
[2]: http://lwn.net/Articles/454389
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
Signed-off-by: Sumit Semwal <sumit.semwal@ti.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-and-Tested-by: Rob Clark <rob.clark@linaro.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-12-26 17:23:15 +08:00
|
|
|
*
|
2015-01-23 15:23:43 +08:00
|
|
|
* @exp_info: [in] holds all the export related information provided
|
2016-12-30 04:48:24 +08:00
|
|
|
* by the exporter. see &struct dma_buf_export_info
|
2015-01-23 15:23:43 +08:00
|
|
|
* for further details.
|
dma-buf: Introduce dma buffer sharing mechanism
This is the first step in defining a dma buffer sharing mechanism.
A new buffer object dma_buf is added, with operations and API to allow easy
sharing of this buffer object across devices.
The framework allows:
- creation of a buffer object, its association with a file pointer, and
associated allocator-defined operations on that buffer. This operation is
called the 'export' operation.
- different devices to 'attach' themselves to this exported buffer object, to
facilitate backing storage negotiation, using dma_buf_attach() API.
- the exported buffer object to be shared with the other entity by asking for
its 'file-descriptor (fd)', and sharing the fd across.
- a received fd to get the buffer object back, where it can be accessed using
the associated exporter-defined operations.
- the exporter and user to share the scatterlist associated with this buffer
object using map_dma_buf and unmap_dma_buf operations.
Atleast one 'attach()' call is required to be made prior to calling the
map_dma_buf() operation.
Couple of building blocks in map_dma_buf() are added to ease introduction
of sync'ing across exporter and users, and late allocation by the exporter.
For this first version, this framework will work with certain conditions:
- *ONLY* exporter will be allowed to mmap to userspace (outside of this
framework - mmap is not a buffer object operation),
- currently, *ONLY* users that do not need CPU access to the buffer are
allowed.
More details are there in the documentation patch.
This is based on design suggestions from many people at the mini-summits[1],
most notably from Arnd Bergmann <arnd@arndb.de>, Rob Clark <rob@ti.com> and
Daniel Vetter <daniel@ffwll.ch>.
The implementation is inspired from proof-of-concept patch-set from
Tomasz Stanislawski <t.stanislaws@samsung.com>, who demonstrated buffer sharing
between two v4l2 devices. [2]
[1]: https://wiki.linaro.org/OfficeofCTO/MemoryManagement
[2]: http://lwn.net/Articles/454389
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
Signed-off-by: Sumit Semwal <sumit.semwal@ti.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-and-Tested-by: Rob Clark <rob.clark@linaro.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-12-26 17:23:15 +08:00
|
|
|
*
|
2020-12-11 23:58:41 +08:00
|
|
|
* Returns, on success, a newly created struct dma_buf object, which wraps the
|
|
|
|
* supplied private data and operations for struct dma_buf_ops. On either
|
|
|
|
* missing ops, or error in allocating struct dma_buf, will return negative
|
|
|
|
* error.
|
dma-buf: Introduce dma buffer sharing mechanism
This is the first step in defining a dma buffer sharing mechanism.
A new buffer object dma_buf is added, with operations and API to allow easy
sharing of this buffer object across devices.
The framework allows:
- creation of a buffer object, its association with a file pointer, and
associated allocator-defined operations on that buffer. This operation is
called the 'export' operation.
- different devices to 'attach' themselves to this exported buffer object, to
facilitate backing storage negotiation, using dma_buf_attach() API.
- the exported buffer object to be shared with the other entity by asking for
its 'file-descriptor (fd)', and sharing the fd across.
- a received fd to get the buffer object back, where it can be accessed using
the associated exporter-defined operations.
- the exporter and user to share the scatterlist associated with this buffer
object using map_dma_buf and unmap_dma_buf operations.
Atleast one 'attach()' call is required to be made prior to calling the
map_dma_buf() operation.
Couple of building blocks in map_dma_buf() are added to ease introduction
of sync'ing across exporter and users, and late allocation by the exporter.
For this first version, this framework will work with certain conditions:
- *ONLY* exporter will be allowed to mmap to userspace (outside of this
framework - mmap is not a buffer object operation),
- currently, *ONLY* users that do not need CPU access to the buffer are
allowed.
More details are there in the documentation patch.
This is based on design suggestions from many people at the mini-summits[1],
most notably from Arnd Bergmann <arnd@arndb.de>, Rob Clark <rob@ti.com> and
Daniel Vetter <daniel@ffwll.ch>.
The implementation is inspired from proof-of-concept patch-set from
Tomasz Stanislawski <t.stanislaws@samsung.com>, who demonstrated buffer sharing
between two v4l2 devices. [2]
[1]: https://wiki.linaro.org/OfficeofCTO/MemoryManagement
[2]: http://lwn.net/Articles/454389
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
Signed-off-by: Sumit Semwal <sumit.semwal@ti.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-and-Tested-by: Rob Clark <rob.clark@linaro.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-12-26 17:23:15 +08:00
|
|
|
*
|
2016-12-10 02:53:07 +08:00
|
|
|
* For most cases the easiest way to create @exp_info is through the
|
|
|
|
* %DEFINE_DMA_BUF_EXPORT_INFO macro.
|
dma-buf: Introduce dma buffer sharing mechanism
This is the first step in defining a dma buffer sharing mechanism.
A new buffer object dma_buf is added, with operations and API to allow easy
sharing of this buffer object across devices.
The framework allows:
- creation of a buffer object, its association with a file pointer, and
associated allocator-defined operations on that buffer. This operation is
called the 'export' operation.
- different devices to 'attach' themselves to this exported buffer object, to
facilitate backing storage negotiation, using dma_buf_attach() API.
- the exported buffer object to be shared with the other entity by asking for
its 'file-descriptor (fd)', and sharing the fd across.
- a received fd to get the buffer object back, where it can be accessed using
the associated exporter-defined operations.
- the exporter and user to share the scatterlist associated with this buffer
object using map_dma_buf and unmap_dma_buf operations.
Atleast one 'attach()' call is required to be made prior to calling the
map_dma_buf() operation.
Couple of building blocks in map_dma_buf() are added to ease introduction
of sync'ing across exporter and users, and late allocation by the exporter.
For this first version, this framework will work with certain conditions:
- *ONLY* exporter will be allowed to mmap to userspace (outside of this
framework - mmap is not a buffer object operation),
- currently, *ONLY* users that do not need CPU access to the buffer are
allowed.
More details are there in the documentation patch.
This is based on design suggestions from many people at the mini-summits[1],
most notably from Arnd Bergmann <arnd@arndb.de>, Rob Clark <rob@ti.com> and
Daniel Vetter <daniel@ffwll.ch>.
The implementation is inspired from proof-of-concept patch-set from
Tomasz Stanislawski <t.stanislaws@samsung.com>, who demonstrated buffer sharing
between two v4l2 devices. [2]
[1]: https://wiki.linaro.org/OfficeofCTO/MemoryManagement
[2]: http://lwn.net/Articles/454389
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
Signed-off-by: Sumit Semwal <sumit.semwal@ti.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-and-Tested-by: Rob Clark <rob.clark@linaro.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-12-26 17:23:15 +08:00
|
|
|
*/
|
2015-01-23 15:23:43 +08:00
|
|
|
struct dma_buf *dma_buf_export(const struct dma_buf_export_info *exp_info)
|
dma-buf: Introduce dma buffer sharing mechanism
This is the first step in defining a dma buffer sharing mechanism.
A new buffer object dma_buf is added, with operations and API to allow easy
sharing of this buffer object across devices.
The framework allows:
- creation of a buffer object, its association with a file pointer, and
associated allocator-defined operations on that buffer. This operation is
called the 'export' operation.
- different devices to 'attach' themselves to this exported buffer object, to
facilitate backing storage negotiation, using dma_buf_attach() API.
- the exported buffer object to be shared with the other entity by asking for
its 'file-descriptor (fd)', and sharing the fd across.
- a received fd to get the buffer object back, where it can be accessed using
the associated exporter-defined operations.
- the exporter and user to share the scatterlist associated with this buffer
object using map_dma_buf and unmap_dma_buf operations.
Atleast one 'attach()' call is required to be made prior to calling the
map_dma_buf() operation.
Couple of building blocks in map_dma_buf() are added to ease introduction
of sync'ing across exporter and users, and late allocation by the exporter.
For this first version, this framework will work with certain conditions:
- *ONLY* exporter will be allowed to mmap to userspace (outside of this
framework - mmap is not a buffer object operation),
- currently, *ONLY* users that do not need CPU access to the buffer are
allowed.
More details are there in the documentation patch.
This is based on design suggestions from many people at the mini-summits[1],
most notably from Arnd Bergmann <arnd@arndb.de>, Rob Clark <rob@ti.com> and
Daniel Vetter <daniel@ffwll.ch>.
The implementation is inspired from proof-of-concept patch-set from
Tomasz Stanislawski <t.stanislaws@samsung.com>, who demonstrated buffer sharing
between two v4l2 devices. [2]
[1]: https://wiki.linaro.org/OfficeofCTO/MemoryManagement
[2]: http://lwn.net/Articles/454389
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
Signed-off-by: Sumit Semwal <sumit.semwal@ti.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-and-Tested-by: Rob Clark <rob.clark@linaro.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-12-26 17:23:15 +08:00
|
|
|
{
|
|
|
|
struct dma_buf *dmabuf;
|
2019-08-11 16:06:32 +08:00
|
|
|
struct dma_resv *resv = exp_info->resv;
|
dma-buf: Introduce dma buffer sharing mechanism
This is the first step in defining a dma buffer sharing mechanism.
A new buffer object dma_buf is added, with operations and API to allow easy
sharing of this buffer object across devices.
The framework allows:
- creation of a buffer object, its association with a file pointer, and
associated allocator-defined operations on that buffer. This operation is
called the 'export' operation.
- different devices to 'attach' themselves to this exported buffer object, to
facilitate backing storage negotiation, using dma_buf_attach() API.
- the exported buffer object to be shared with the other entity by asking for
its 'file-descriptor (fd)', and sharing the fd across.
- a received fd to get the buffer object back, where it can be accessed using
the associated exporter-defined operations.
- the exporter and user to share the scatterlist associated with this buffer
object using map_dma_buf and unmap_dma_buf operations.
Atleast one 'attach()' call is required to be made prior to calling the
map_dma_buf() operation.
Couple of building blocks in map_dma_buf() are added to ease introduction
of sync'ing across exporter and users, and late allocation by the exporter.
For this first version, this framework will work with certain conditions:
- *ONLY* exporter will be allowed to mmap to userspace (outside of this
framework - mmap is not a buffer object operation),
- currently, *ONLY* users that do not need CPU access to the buffer are
allowed.
More details are there in the documentation patch.
This is based on design suggestions from many people at the mini-summits[1],
most notably from Arnd Bergmann <arnd@arndb.de>, Rob Clark <rob@ti.com> and
Daniel Vetter <daniel@ffwll.ch>.
The implementation is inspired from proof-of-concept patch-set from
Tomasz Stanislawski <t.stanislaws@samsung.com>, who demonstrated buffer sharing
between two v4l2 devices. [2]
[1]: https://wiki.linaro.org/OfficeofCTO/MemoryManagement
[2]: http://lwn.net/Articles/454389
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
Signed-off-by: Sumit Semwal <sumit.semwal@ti.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-and-Tested-by: Rob Clark <rob.clark@linaro.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-12-26 17:23:15 +08:00
|
|
|
struct file *file;
|
2014-07-01 18:57:26 +08:00
|
|
|
size_t alloc_size = sizeof(struct dma_buf);
|
2016-07-18 19:16:22 +08:00
|
|
|
int ret;
|
2015-05-21 03:39:31 +08:00
|
|
|
|
2022-12-06 21:07:49 +08:00
|
|
|
if (WARN_ON(!exp_info->priv || !exp_info->ops
|
|
|
|
|| !exp_info->ops->map_dma_buf
|
|
|
|
|| !exp_info->ops->unmap_dma_buf
|
|
|
|
|| !exp_info->ops->release))
|
dma-buf: Introduce dma buffer sharing mechanism
This is the first step in defining a dma buffer sharing mechanism.
A new buffer object dma_buf is added, with operations and API to allow easy
sharing of this buffer object across devices.
The framework allows:
- creation of a buffer object, its association with a file pointer, and
associated allocator-defined operations on that buffer. This operation is
called the 'export' operation.
- different devices to 'attach' themselves to this exported buffer object, to
facilitate backing storage negotiation, using dma_buf_attach() API.
- the exported buffer object to be shared with the other entity by asking for
its 'file-descriptor (fd)', and sharing the fd across.
- a received fd to get the buffer object back, where it can be accessed using
the associated exporter-defined operations.
- the exporter and user to share the scatterlist associated with this buffer
object using map_dma_buf and unmap_dma_buf operations.
Atleast one 'attach()' call is required to be made prior to calling the
map_dma_buf() operation.
Couple of building blocks in map_dma_buf() are added to ease introduction
of sync'ing across exporter and users, and late allocation by the exporter.
For this first version, this framework will work with certain conditions:
- *ONLY* exporter will be allowed to mmap to userspace (outside of this
framework - mmap is not a buffer object operation),
- currently, *ONLY* users that do not need CPU access to the buffer are
allowed.
More details are there in the documentation patch.
This is based on design suggestions from many people at the mini-summits[1],
most notably from Arnd Bergmann <arnd@arndb.de>, Rob Clark <rob@ti.com> and
Daniel Vetter <daniel@ffwll.ch>.
The implementation is inspired from proof-of-concept patch-set from
Tomasz Stanislawski <t.stanislaws@samsung.com>, who demonstrated buffer sharing
between two v4l2 devices. [2]
[1]: https://wiki.linaro.org/OfficeofCTO/MemoryManagement
[2]: http://lwn.net/Articles/454389
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
Signed-off-by: Sumit Semwal <sumit.semwal@ti.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-and-Tested-by: Rob Clark <rob.clark@linaro.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-12-26 17:23:15 +08:00
|
|
|
return ERR_PTR(-EINVAL);
|
|
|
|
|
dma-buf: change DMA-buf locking convention v3
This patch is a stripped down version of the locking changes
necessary to support dynamic DMA-buf handling.
It adds a dynamic flag for both importers as well as exporters
so that drivers can choose if they want the reservation object
locked or unlocked during mapping of attachments.
For compatibility between drivers we cache the DMA-buf mapping
during attaching an importer as soon as exporter/importer
disagree on the dynamic handling.
Issues and solutions we considered:
- We can't change all existing drivers, and existing improters have
strong opinions about which locks they're holding while calling
dma_buf_attachment_map/unmap. Exporters also have strong opinions about
which locks they can acquire in their ->map/unmap callbacks, levaing no
room for change. The solution to avoid this was to move the
actual map/unmap out from this call, into the attach/detach callbacks,
and cache the mapping. This works because drivers don't call
attach/detach from deep within their code callchains (like deep in
memory management code called from cs/execbuf ioctl), but directly from
the fd2handle implementation.
- The caching has some troubles on some soc drivers, which set other modes
than DMA_BIDIRECTIONAL. We can't have 2 incompatible mappings, and we
can't re-create the mapping at _map time due to the above locking fun.
We very carefuly step around that by only caching at attach time if the
dynamic mode between importer/expoert mismatches.
- There's been quite some discussion on dma-buf mappings which need active
cache management, which would all break down when caching, plus we don't
have explicit flush operations on the attachment side. The solution to
this was to shrug and keep the current discrepancy between what the
dma-buf docs claim and what implementations do, with the hope that the
begin/end_cpu_access hooks are good enough and that all necessary
flushing to keep device mappings consistent will be done there.
v2: cleanup set_name merge, improve kerneldoc
v3: update commit message, kerneldoc and cleanup _debug_show()
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/336788/
2018-07-03 22:42:26 +08:00
|
|
|
if (WARN_ON(exp_info->ops->cache_sgt_mapping &&
|
2020-02-18 23:57:24 +08:00
|
|
|
(exp_info->ops->pin || exp_info->ops->unpin)))
|
dma-buf: change DMA-buf locking convention v3
This patch is a stripped down version of the locking changes
necessary to support dynamic DMA-buf handling.
It adds a dynamic flag for both importers as well as exporters
so that drivers can choose if they want the reservation object
locked or unlocked during mapping of attachments.
For compatibility between drivers we cache the DMA-buf mapping
during attaching an importer as soon as exporter/importer
disagree on the dynamic handling.
Issues and solutions we considered:
- We can't change all existing drivers, and existing improters have
strong opinions about which locks they're holding while calling
dma_buf_attachment_map/unmap. Exporters also have strong opinions about
which locks they can acquire in their ->map/unmap callbacks, levaing no
room for change. The solution to avoid this was to move the
actual map/unmap out from this call, into the attach/detach callbacks,
and cache the mapping. This works because drivers don't call
attach/detach from deep within their code callchains (like deep in
memory management code called from cs/execbuf ioctl), but directly from
the fd2handle implementation.
- The caching has some troubles on some soc drivers, which set other modes
than DMA_BIDIRECTIONAL. We can't have 2 incompatible mappings, and we
can't re-create the mapping at _map time due to the above locking fun.
We very carefuly step around that by only caching at attach time if the
dynamic mode between importer/expoert mismatches.
- There's been quite some discussion on dma-buf mappings which need active
cache management, which would all break down when caching, plus we don't
have explicit flush operations on the attachment side. The solution to
this was to shrug and keep the current discrepancy between what the
dma-buf docs claim and what implementations do, with the hope that the
begin/end_cpu_access hooks are good enough and that all necessary
flushing to keep device mappings consistent will be done there.
v2: cleanup set_name merge, improve kerneldoc
v3: update commit message, kerneldoc and cleanup _debug_show()
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/336788/
2018-07-03 22:42:26 +08:00
|
|
|
return ERR_PTR(-EINVAL);
|
|
|
|
|
2020-02-18 23:57:24 +08:00
|
|
|
if (WARN_ON(!exp_info->ops->pin != !exp_info->ops->unpin))
|
dma-buf: change DMA-buf locking convention v3
This patch is a stripped down version of the locking changes
necessary to support dynamic DMA-buf handling.
It adds a dynamic flag for both importers as well as exporters
so that drivers can choose if they want the reservation object
locked or unlocked during mapping of attachments.
For compatibility between drivers we cache the DMA-buf mapping
during attaching an importer as soon as exporter/importer
disagree on the dynamic handling.
Issues and solutions we considered:
- We can't change all existing drivers, and existing improters have
strong opinions about which locks they're holding while calling
dma_buf_attachment_map/unmap. Exporters also have strong opinions about
which locks they can acquire in their ->map/unmap callbacks, levaing no
room for change. The solution to avoid this was to move the
actual map/unmap out from this call, into the attach/detach callbacks,
and cache the mapping. This works because drivers don't call
attach/detach from deep within their code callchains (like deep in
memory management code called from cs/execbuf ioctl), but directly from
the fd2handle implementation.
- The caching has some troubles on some soc drivers, which set other modes
than DMA_BIDIRECTIONAL. We can't have 2 incompatible mappings, and we
can't re-create the mapping at _map time due to the above locking fun.
We very carefuly step around that by only caching at attach time if the
dynamic mode between importer/expoert mismatches.
- There's been quite some discussion on dma-buf mappings which need active
cache management, which would all break down when caching, plus we don't
have explicit flush operations on the attachment side. The solution to
this was to shrug and keep the current discrepancy between what the
dma-buf docs claim and what implementations do, with the hope that the
begin/end_cpu_access hooks are good enough and that all necessary
flushing to keep device mappings consistent will be done there.
v2: cleanup set_name merge, improve kerneldoc
v3: update commit message, kerneldoc and cleanup _debug_show()
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/336788/
2018-07-03 22:42:26 +08:00
|
|
|
return ERR_PTR(-EINVAL);
|
|
|
|
|
2015-05-05 17:26:15 +08:00
|
|
|
if (!try_module_get(exp_info->owner))
|
|
|
|
return ERR_PTR(-ENOENT);
|
|
|
|
|
2022-12-06 21:07:49 +08:00
|
|
|
file = dma_buf_getfile(exp_info->size, exp_info->flags);
|
|
|
|
if (IS_ERR(file)) {
|
|
|
|
ret = PTR_ERR(file);
|
|
|
|
goto err_module;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!exp_info->resv)
|
|
|
|
alloc_size += sizeof(struct dma_resv);
|
|
|
|
else
|
|
|
|
/* prevent &dma_buf[1] == dma_buf->resv */
|
|
|
|
alloc_size += 1;
|
2014-07-01 18:57:26 +08:00
|
|
|
dmabuf = kzalloc(alloc_size, GFP_KERNEL);
|
2015-05-05 17:26:15 +08:00
|
|
|
if (!dmabuf) {
|
2016-07-18 19:16:22 +08:00
|
|
|
ret = -ENOMEM;
|
2022-12-06 21:07:49 +08:00
|
|
|
goto err_file;
|
2015-05-05 17:26:15 +08:00
|
|
|
}
|
dma-buf: Introduce dma buffer sharing mechanism
This is the first step in defining a dma buffer sharing mechanism.
A new buffer object dma_buf is added, with operations and API to allow easy
sharing of this buffer object across devices.
The framework allows:
- creation of a buffer object, its association with a file pointer, and
associated allocator-defined operations on that buffer. This operation is
called the 'export' operation.
- different devices to 'attach' themselves to this exported buffer object, to
facilitate backing storage negotiation, using dma_buf_attach() API.
- the exported buffer object to be shared with the other entity by asking for
its 'file-descriptor (fd)', and sharing the fd across.
- a received fd to get the buffer object back, where it can be accessed using
the associated exporter-defined operations.
- the exporter and user to share the scatterlist associated with this buffer
object using map_dma_buf and unmap_dma_buf operations.
Atleast one 'attach()' call is required to be made prior to calling the
map_dma_buf() operation.
Couple of building blocks in map_dma_buf() are added to ease introduction
of sync'ing across exporter and users, and late allocation by the exporter.
For this first version, this framework will work with certain conditions:
- *ONLY* exporter will be allowed to mmap to userspace (outside of this
framework - mmap is not a buffer object operation),
- currently, *ONLY* users that do not need CPU access to the buffer are
allowed.
More details are there in the documentation patch.
This is based on design suggestions from many people at the mini-summits[1],
most notably from Arnd Bergmann <arnd@arndb.de>, Rob Clark <rob@ti.com> and
Daniel Vetter <daniel@ffwll.ch>.
The implementation is inspired from proof-of-concept patch-set from
Tomasz Stanislawski <t.stanislaws@samsung.com>, who demonstrated buffer sharing
between two v4l2 devices. [2]
[1]: https://wiki.linaro.org/OfficeofCTO/MemoryManagement
[2]: http://lwn.net/Articles/454389
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
Signed-off-by: Sumit Semwal <sumit.semwal@ti.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-and-Tested-by: Rob Clark <rob.clark@linaro.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-12-26 17:23:15 +08:00
|
|
|
|
2015-01-23 15:23:43 +08:00
|
|
|
dmabuf->priv = exp_info->priv;
|
|
|
|
dmabuf->ops = exp_info->ops;
|
|
|
|
dmabuf->size = exp_info->size;
|
|
|
|
dmabuf->exp_name = exp_info->exp_name;
|
2015-05-05 17:26:15 +08:00
|
|
|
dmabuf->owner = exp_info->owner;
|
2020-06-19 19:57:19 +08:00
|
|
|
spin_lock_init(&dmabuf->name_lock);
|
2014-07-01 18:57:43 +08:00
|
|
|
init_waitqueue_head(&dmabuf->poll);
|
2021-06-15 19:12:33 +08:00
|
|
|
dmabuf->cb_in.poll = dmabuf->cb_out.poll = &dmabuf->poll;
|
|
|
|
dmabuf->cb_in.active = dmabuf->cb_out.active = 0;
|
2022-12-06 21:07:49 +08:00
|
|
|
INIT_LIST_HEAD(&dmabuf->attachments);
|
2014-07-01 18:57:43 +08:00
|
|
|
|
2014-07-01 18:57:26 +08:00
|
|
|
if (!resv) {
|
2022-12-06 21:07:49 +08:00
|
|
|
dmabuf->resv = (struct dma_resv *)&dmabuf[1];
|
|
|
|
dma_resv_init(dmabuf->resv);
|
|
|
|
} else {
|
|
|
|
dmabuf->resv = resv;
|
2014-07-01 18:57:26 +08:00
|
|
|
}
|
dma-buf: Introduce dma buffer sharing mechanism
This is the first step in defining a dma buffer sharing mechanism.
A new buffer object dma_buf is added, with operations and API to allow easy
sharing of this buffer object across devices.
The framework allows:
- creation of a buffer object, its association with a file pointer, and
associated allocator-defined operations on that buffer. This operation is
called the 'export' operation.
- different devices to 'attach' themselves to this exported buffer object, to
facilitate backing storage negotiation, using dma_buf_attach() API.
- the exported buffer object to be shared with the other entity by asking for
its 'file-descriptor (fd)', and sharing the fd across.
- a received fd to get the buffer object back, where it can be accessed using
the associated exporter-defined operations.
- the exporter and user to share the scatterlist associated with this buffer
object using map_dma_buf and unmap_dma_buf operations.
Atleast one 'attach()' call is required to be made prior to calling the
map_dma_buf() operation.
Couple of building blocks in map_dma_buf() are added to ease introduction
of sync'ing across exporter and users, and late allocation by the exporter.
For this first version, this framework will work with certain conditions:
- *ONLY* exporter will be allowed to mmap to userspace (outside of this
framework - mmap is not a buffer object operation),
- currently, *ONLY* users that do not need CPU access to the buffer are
allowed.
More details are there in the documentation patch.
This is based on design suggestions from many people at the mini-summits[1],
most notably from Arnd Bergmann <arnd@arndb.de>, Rob Clark <rob@ti.com> and
Daniel Vetter <daniel@ffwll.ch>.
The implementation is inspired from proof-of-concept patch-set from
Tomasz Stanislawski <t.stanislaws@samsung.com>, who demonstrated buffer sharing
between two v4l2 devices. [2]
[1]: https://wiki.linaro.org/OfficeofCTO/MemoryManagement
[2]: http://lwn.net/Articles/454389
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
Signed-off-by: Sumit Semwal <sumit.semwal@ti.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-and-Tested-by: Rob Clark <rob.clark@linaro.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-12-26 17:23:15 +08:00
|
|
|
|
2022-12-06 21:07:49 +08:00
|
|
|
ret = dma_buf_stats_setup(dmabuf, file);
|
|
|
|
if (ret)
|
2016-07-18 19:16:22 +08:00
|
|
|
goto err_dmabuf;
|
2013-09-10 14:06:45 +08:00
|
|
|
|
2022-12-06 21:07:49 +08:00
|
|
|
file->private_data = dmabuf;
|
|
|
|
file->f_path.dentry->d_fsdata = dmabuf;
|
dma-buf: Introduce dma buffer sharing mechanism
This is the first step in defining a dma buffer sharing mechanism.
A new buffer object dma_buf is added, with operations and API to allow easy
sharing of this buffer object across devices.
The framework allows:
- creation of a buffer object, its association with a file pointer, and
associated allocator-defined operations on that buffer. This operation is
called the 'export' operation.
- different devices to 'attach' themselves to this exported buffer object, to
facilitate backing storage negotiation, using dma_buf_attach() API.
- the exported buffer object to be shared with the other entity by asking for
its 'file-descriptor (fd)', and sharing the fd across.
- a received fd to get the buffer object back, where it can be accessed using
the associated exporter-defined operations.
- the exporter and user to share the scatterlist associated with this buffer
object using map_dma_buf and unmap_dma_buf operations.
Atleast one 'attach()' call is required to be made prior to calling the
map_dma_buf() operation.
Couple of building blocks in map_dma_buf() are added to ease introduction
of sync'ing across exporter and users, and late allocation by the exporter.
For this first version, this framework will work with certain conditions:
- *ONLY* exporter will be allowed to mmap to userspace (outside of this
framework - mmap is not a buffer object operation),
- currently, *ONLY* users that do not need CPU access to the buffer are
allowed.
More details are there in the documentation patch.
This is based on design suggestions from many people at the mini-summits[1],
most notably from Arnd Bergmann <arnd@arndb.de>, Rob Clark <rob@ti.com> and
Daniel Vetter <daniel@ffwll.ch>.
The implementation is inspired from proof-of-concept patch-set from
Tomasz Stanislawski <t.stanislaws@samsung.com>, who demonstrated buffer sharing
between two v4l2 devices. [2]
[1]: https://wiki.linaro.org/OfficeofCTO/MemoryManagement
[2]: http://lwn.net/Articles/454389
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
Signed-off-by: Sumit Semwal <sumit.semwal@ti.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-and-Tested-by: Rob Clark <rob.clark@linaro.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-12-26 17:23:15 +08:00
|
|
|
dmabuf->file = file;
|
|
|
|
|
2024-03-28 22:53:23 +08:00
|
|
|
__dma_buf_debugfs_list_add(dmabuf);
|
2013-04-04 14:14:37 +08:00
|
|
|
|
dma-buf: Introduce dma buffer sharing mechanism
This is the first step in defining a dma buffer sharing mechanism.
A new buffer object dma_buf is added, with operations and API to allow easy
sharing of this buffer object across devices.
The framework allows:
- creation of a buffer object, its association with a file pointer, and
associated allocator-defined operations on that buffer. This operation is
called the 'export' operation.
- different devices to 'attach' themselves to this exported buffer object, to
facilitate backing storage negotiation, using dma_buf_attach() API.
- the exported buffer object to be shared with the other entity by asking for
its 'file-descriptor (fd)', and sharing the fd across.
- a received fd to get the buffer object back, where it can be accessed using
the associated exporter-defined operations.
- the exporter and user to share the scatterlist associated with this buffer
object using map_dma_buf and unmap_dma_buf operations.
Atleast one 'attach()' call is required to be made prior to calling the
map_dma_buf() operation.
Couple of building blocks in map_dma_buf() are added to ease introduction
of sync'ing across exporter and users, and late allocation by the exporter.
For this first version, this framework will work with certain conditions:
- *ONLY* exporter will be allowed to mmap to userspace (outside of this
framework - mmap is not a buffer object operation),
- currently, *ONLY* users that do not need CPU access to the buffer are
allowed.
More details are there in the documentation patch.
This is based on design suggestions from many people at the mini-summits[1],
most notably from Arnd Bergmann <arnd@arndb.de>, Rob Clark <rob@ti.com> and
Daniel Vetter <daniel@ffwll.ch>.
The implementation is inspired from proof-of-concept patch-set from
Tomasz Stanislawski <t.stanislaws@samsung.com>, who demonstrated buffer sharing
between two v4l2 devices. [2]
[1]: https://wiki.linaro.org/OfficeofCTO/MemoryManagement
[2]: http://lwn.net/Articles/454389
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
Signed-off-by: Sumit Semwal <sumit.semwal@ti.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-and-Tested-by: Rob Clark <rob.clark@linaro.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-12-26 17:23:15 +08:00
|
|
|
return dmabuf;
|
2016-07-18 19:16:22 +08:00
|
|
|
|
|
|
|
err_dmabuf:
|
2022-12-06 21:07:49 +08:00
|
|
|
if (!resv)
|
|
|
|
dma_resv_fini(dmabuf->resv);
|
2016-07-18 19:16:22 +08:00
|
|
|
kfree(dmabuf);
|
2022-12-06 21:07:49 +08:00
|
|
|
err_file:
|
|
|
|
fput(file);
|
2016-07-18 19:16:22 +08:00
|
|
|
err_module:
|
|
|
|
module_put(exp_info->owner);
|
|
|
|
return ERR_PTR(ret);
|
dma-buf: Introduce dma buffer sharing mechanism
This is the first step in defining a dma buffer sharing mechanism.
A new buffer object dma_buf is added, with operations and API to allow easy
sharing of this buffer object across devices.
The framework allows:
- creation of a buffer object, its association with a file pointer, and
associated allocator-defined operations on that buffer. This operation is
called the 'export' operation.
- different devices to 'attach' themselves to this exported buffer object, to
facilitate backing storage negotiation, using dma_buf_attach() API.
- the exported buffer object to be shared with the other entity by asking for
its 'file-descriptor (fd)', and sharing the fd across.
- a received fd to get the buffer object back, where it can be accessed using
the associated exporter-defined operations.
- the exporter and user to share the scatterlist associated with this buffer
object using map_dma_buf and unmap_dma_buf operations.
Atleast one 'attach()' call is required to be made prior to calling the
map_dma_buf() operation.
Couple of building blocks in map_dma_buf() are added to ease introduction
of sync'ing across exporter and users, and late allocation by the exporter.
For this first version, this framework will work with certain conditions:
- *ONLY* exporter will be allowed to mmap to userspace (outside of this
framework - mmap is not a buffer object operation),
- currently, *ONLY* users that do not need CPU access to the buffer are
allowed.
More details are there in the documentation patch.
This is based on design suggestions from many people at the mini-summits[1],
most notably from Arnd Bergmann <arnd@arndb.de>, Rob Clark <rob@ti.com> and
Daniel Vetter <daniel@ffwll.ch>.
The implementation is inspired from proof-of-concept patch-set from
Tomasz Stanislawski <t.stanislaws@samsung.com>, who demonstrated buffer sharing
between two v4l2 devices. [2]
[1]: https://wiki.linaro.org/OfficeofCTO/MemoryManagement
[2]: http://lwn.net/Articles/454389
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
Signed-off-by: Sumit Semwal <sumit.semwal@ti.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-and-Tested-by: Rob Clark <rob.clark@linaro.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-12-26 17:23:15 +08:00
|
|
|
}
|
2021-10-10 20:46:28 +08:00
|
|
|
EXPORT_SYMBOL_NS_GPL(dma_buf_export, DMA_BUF);
|
dma-buf: Introduce dma buffer sharing mechanism
This is the first step in defining a dma buffer sharing mechanism.
A new buffer object dma_buf is added, with operations and API to allow easy
sharing of this buffer object across devices.
The framework allows:
- creation of a buffer object, its association with a file pointer, and
associated allocator-defined operations on that buffer. This operation is
called the 'export' operation.
- different devices to 'attach' themselves to this exported buffer object, to
facilitate backing storage negotiation, using dma_buf_attach() API.
- the exported buffer object to be shared with the other entity by asking for
its 'file-descriptor (fd)', and sharing the fd across.
- a received fd to get the buffer object back, where it can be accessed using
the associated exporter-defined operations.
- the exporter and user to share the scatterlist associated with this buffer
object using map_dma_buf and unmap_dma_buf operations.
Atleast one 'attach()' call is required to be made prior to calling the
map_dma_buf() operation.
Couple of building blocks in map_dma_buf() are added to ease introduction
of sync'ing across exporter and users, and late allocation by the exporter.
For this first version, this framework will work with certain conditions:
- *ONLY* exporter will be allowed to mmap to userspace (outside of this
framework - mmap is not a buffer object operation),
- currently, *ONLY* users that do not need CPU access to the buffer are
allowed.
More details are there in the documentation patch.
This is based on design suggestions from many people at the mini-summits[1],
most notably from Arnd Bergmann <arnd@arndb.de>, Rob Clark <rob@ti.com> and
Daniel Vetter <daniel@ffwll.ch>.
The implementation is inspired from proof-of-concept patch-set from
Tomasz Stanislawski <t.stanislaws@samsung.com>, who demonstrated buffer sharing
between two v4l2 devices. [2]
[1]: https://wiki.linaro.org/OfficeofCTO/MemoryManagement
[2]: http://lwn.net/Articles/454389
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
Signed-off-by: Sumit Semwal <sumit.semwal@ti.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-and-Tested-by: Rob Clark <rob.clark@linaro.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-12-26 17:23:15 +08:00
|
|
|
|
|
|
|
/**
|
2020-12-11 23:58:41 +08:00
|
|
|
* dma_buf_fd - returns a file descriptor for the given struct dma_buf
|
dma-buf: Introduce dma buffer sharing mechanism
This is the first step in defining a dma buffer sharing mechanism.
A new buffer object dma_buf is added, with operations and API to allow easy
sharing of this buffer object across devices.
The framework allows:
- creation of a buffer object, its association with a file pointer, and
associated allocator-defined operations on that buffer. This operation is
called the 'export' operation.
- different devices to 'attach' themselves to this exported buffer object, to
facilitate backing storage negotiation, using dma_buf_attach() API.
- the exported buffer object to be shared with the other entity by asking for
its 'file-descriptor (fd)', and sharing the fd across.
- a received fd to get the buffer object back, where it can be accessed using
the associated exporter-defined operations.
- the exporter and user to share the scatterlist associated with this buffer
object using map_dma_buf and unmap_dma_buf operations.
Atleast one 'attach()' call is required to be made prior to calling the
map_dma_buf() operation.
Couple of building blocks in map_dma_buf() are added to ease introduction
of sync'ing across exporter and users, and late allocation by the exporter.
For this first version, this framework will work with certain conditions:
- *ONLY* exporter will be allowed to mmap to userspace (outside of this
framework - mmap is not a buffer object operation),
- currently, *ONLY* users that do not need CPU access to the buffer are
allowed.
More details are there in the documentation patch.
This is based on design suggestions from many people at the mini-summits[1],
most notably from Arnd Bergmann <arnd@arndb.de>, Rob Clark <rob@ti.com> and
Daniel Vetter <daniel@ffwll.ch>.
The implementation is inspired from proof-of-concept patch-set from
Tomasz Stanislawski <t.stanislaws@samsung.com>, who demonstrated buffer sharing
between two v4l2 devices. [2]
[1]: https://wiki.linaro.org/OfficeofCTO/MemoryManagement
[2]: http://lwn.net/Articles/454389
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
Signed-off-by: Sumit Semwal <sumit.semwal@ti.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-and-Tested-by: Rob Clark <rob.clark@linaro.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-12-26 17:23:15 +08:00
|
|
|
* @dmabuf: [in] pointer to dma_buf for which fd is required.
|
2012-03-16 18:34:02 +08:00
|
|
|
* @flags: [in] flags to give to fd
|
dma-buf: Introduce dma buffer sharing mechanism
This is the first step in defining a dma buffer sharing mechanism.
A new buffer object dma_buf is added, with operations and API to allow easy
sharing of this buffer object across devices.
The framework allows:
- creation of a buffer object, its association with a file pointer, and
associated allocator-defined operations on that buffer. This operation is
called the 'export' operation.
- different devices to 'attach' themselves to this exported buffer object, to
facilitate backing storage negotiation, using dma_buf_attach() API.
- the exported buffer object to be shared with the other entity by asking for
its 'file-descriptor (fd)', and sharing the fd across.
- a received fd to get the buffer object back, where it can be accessed using
the associated exporter-defined operations.
- the exporter and user to share the scatterlist associated with this buffer
object using map_dma_buf and unmap_dma_buf operations.
Atleast one 'attach()' call is required to be made prior to calling the
map_dma_buf() operation.
Couple of building blocks in map_dma_buf() are added to ease introduction
of sync'ing across exporter and users, and late allocation by the exporter.
For this first version, this framework will work with certain conditions:
- *ONLY* exporter will be allowed to mmap to userspace (outside of this
framework - mmap is not a buffer object operation),
- currently, *ONLY* users that do not need CPU access to the buffer are
allowed.
More details are there in the documentation patch.
This is based on design suggestions from many people at the mini-summits[1],
most notably from Arnd Bergmann <arnd@arndb.de>, Rob Clark <rob@ti.com> and
Daniel Vetter <daniel@ffwll.ch>.
The implementation is inspired from proof-of-concept patch-set from
Tomasz Stanislawski <t.stanislaws@samsung.com>, who demonstrated buffer sharing
between two v4l2 devices. [2]
[1]: https://wiki.linaro.org/OfficeofCTO/MemoryManagement
[2]: http://lwn.net/Articles/454389
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
Signed-off-by: Sumit Semwal <sumit.semwal@ti.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-and-Tested-by: Rob Clark <rob.clark@linaro.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-12-26 17:23:15 +08:00
|
|
|
*
|
|
|
|
* On success, returns an associated 'fd'. Else, returns error.
|
|
|
|
*/
|
2012-03-16 18:34:02 +08:00
|
|
|
int dma_buf_fd(struct dma_buf *dmabuf, int flags)
|
dma-buf: Introduce dma buffer sharing mechanism
This is the first step in defining a dma buffer sharing mechanism.
A new buffer object dma_buf is added, with operations and API to allow easy
sharing of this buffer object across devices.
The framework allows:
- creation of a buffer object, its association with a file pointer, and
associated allocator-defined operations on that buffer. This operation is
called the 'export' operation.
- different devices to 'attach' themselves to this exported buffer object, to
facilitate backing storage negotiation, using dma_buf_attach() API.
- the exported buffer object to be shared with the other entity by asking for
its 'file-descriptor (fd)', and sharing the fd across.
- a received fd to get the buffer object back, where it can be accessed using
the associated exporter-defined operations.
- the exporter and user to share the scatterlist associated with this buffer
object using map_dma_buf and unmap_dma_buf operations.
Atleast one 'attach()' call is required to be made prior to calling the
map_dma_buf() operation.
Couple of building blocks in map_dma_buf() are added to ease introduction
of sync'ing across exporter and users, and late allocation by the exporter.
For this first version, this framework will work with certain conditions:
- *ONLY* exporter will be allowed to mmap to userspace (outside of this
framework - mmap is not a buffer object operation),
- currently, *ONLY* users that do not need CPU access to the buffer are
allowed.
More details are there in the documentation patch.
This is based on design suggestions from many people at the mini-summits[1],
most notably from Arnd Bergmann <arnd@arndb.de>, Rob Clark <rob@ti.com> and
Daniel Vetter <daniel@ffwll.ch>.
The implementation is inspired from proof-of-concept patch-set from
Tomasz Stanislawski <t.stanislaws@samsung.com>, who demonstrated buffer sharing
between two v4l2 devices. [2]
[1]: https://wiki.linaro.org/OfficeofCTO/MemoryManagement
[2]: http://lwn.net/Articles/454389
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
Signed-off-by: Sumit Semwal <sumit.semwal@ti.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-and-Tested-by: Rob Clark <rob.clark@linaro.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-12-26 17:23:15 +08:00
|
|
|
{
|
2012-12-11 23:05:26 +08:00
|
|
|
int fd;
|
dma-buf: Introduce dma buffer sharing mechanism
This is the first step in defining a dma buffer sharing mechanism.
A new buffer object dma_buf is added, with operations and API to allow easy
sharing of this buffer object across devices.
The framework allows:
- creation of a buffer object, its association with a file pointer, and
associated allocator-defined operations on that buffer. This operation is
called the 'export' operation.
- different devices to 'attach' themselves to this exported buffer object, to
facilitate backing storage negotiation, using dma_buf_attach() API.
- the exported buffer object to be shared with the other entity by asking for
its 'file-descriptor (fd)', and sharing the fd across.
- a received fd to get the buffer object back, where it can be accessed using
the associated exporter-defined operations.
- the exporter and user to share the scatterlist associated with this buffer
object using map_dma_buf and unmap_dma_buf operations.
Atleast one 'attach()' call is required to be made prior to calling the
map_dma_buf() operation.
Couple of building blocks in map_dma_buf() are added to ease introduction
of sync'ing across exporter and users, and late allocation by the exporter.
For this first version, this framework will work with certain conditions:
- *ONLY* exporter will be allowed to mmap to userspace (outside of this
framework - mmap is not a buffer object operation),
- currently, *ONLY* users that do not need CPU access to the buffer are
allowed.
More details are there in the documentation patch.
This is based on design suggestions from many people at the mini-summits[1],
most notably from Arnd Bergmann <arnd@arndb.de>, Rob Clark <rob@ti.com> and
Daniel Vetter <daniel@ffwll.ch>.
The implementation is inspired from proof-of-concept patch-set from
Tomasz Stanislawski <t.stanislaws@samsung.com>, who demonstrated buffer sharing
between two v4l2 devices. [2]
[1]: https://wiki.linaro.org/OfficeofCTO/MemoryManagement
[2]: http://lwn.net/Articles/454389
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
Signed-off-by: Sumit Semwal <sumit.semwal@ti.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-and-Tested-by: Rob Clark <rob.clark@linaro.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-12-26 17:23:15 +08:00
|
|
|
|
|
|
|
if (!dmabuf || !dmabuf->file)
|
|
|
|
return -EINVAL;
|
|
|
|
|
2012-12-11 23:05:26 +08:00
|
|
|
fd = get_unused_fd_flags(flags);
|
|
|
|
if (fd < 0)
|
|
|
|
return fd;
|
dma-buf: Introduce dma buffer sharing mechanism
This is the first step in defining a dma buffer sharing mechanism.
A new buffer object dma_buf is added, with operations and API to allow easy
sharing of this buffer object across devices.
The framework allows:
- creation of a buffer object, its association with a file pointer, and
associated allocator-defined operations on that buffer. This operation is
called the 'export' operation.
- different devices to 'attach' themselves to this exported buffer object, to
facilitate backing storage negotiation, using dma_buf_attach() API.
- the exported buffer object to be shared with the other entity by asking for
its 'file-descriptor (fd)', and sharing the fd across.
- a received fd to get the buffer object back, where it can be accessed using
the associated exporter-defined operations.
- the exporter and user to share the scatterlist associated with this buffer
object using map_dma_buf and unmap_dma_buf operations.
Atleast one 'attach()' call is required to be made prior to calling the
map_dma_buf() operation.
Couple of building blocks in map_dma_buf() are added to ease introduction
of sync'ing across exporter and users, and late allocation by the exporter.
For this first version, this framework will work with certain conditions:
- *ONLY* exporter will be allowed to mmap to userspace (outside of this
framework - mmap is not a buffer object operation),
- currently, *ONLY* users that do not need CPU access to the buffer are
allowed.
More details are there in the documentation patch.
This is based on design suggestions from many people at the mini-summits[1],
most notably from Arnd Bergmann <arnd@arndb.de>, Rob Clark <rob@ti.com> and
Daniel Vetter <daniel@ffwll.ch>.
The implementation is inspired from proof-of-concept patch-set from
Tomasz Stanislawski <t.stanislaws@samsung.com>, who demonstrated buffer sharing
between two v4l2 devices. [2]
[1]: https://wiki.linaro.org/OfficeofCTO/MemoryManagement
[2]: http://lwn.net/Articles/454389
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
Signed-off-by: Sumit Semwal <sumit.semwal@ti.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-and-Tested-by: Rob Clark <rob.clark@linaro.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-12-26 17:23:15 +08:00
|
|
|
|
|
|
|
fd_install(fd, dmabuf->file);
|
|
|
|
|
|
|
|
return fd;
|
|
|
|
}
|
2021-10-10 20:46:28 +08:00
|
|
|
EXPORT_SYMBOL_NS_GPL(dma_buf_fd, DMA_BUF);
|
dma-buf: Introduce dma buffer sharing mechanism
This is the first step in defining a dma buffer sharing mechanism.
A new buffer object dma_buf is added, with operations and API to allow easy
sharing of this buffer object across devices.
The framework allows:
- creation of a buffer object, its association with a file pointer, and
associated allocator-defined operations on that buffer. This operation is
called the 'export' operation.
- different devices to 'attach' themselves to this exported buffer object, to
facilitate backing storage negotiation, using dma_buf_attach() API.
- the exported buffer object to be shared with the other entity by asking for
its 'file-descriptor (fd)', and sharing the fd across.
- a received fd to get the buffer object back, where it can be accessed using
the associated exporter-defined operations.
- the exporter and user to share the scatterlist associated with this buffer
object using map_dma_buf and unmap_dma_buf operations.
Atleast one 'attach()' call is required to be made prior to calling the
map_dma_buf() operation.
Couple of building blocks in map_dma_buf() are added to ease introduction
of sync'ing across exporter and users, and late allocation by the exporter.
For this first version, this framework will work with certain conditions:
- *ONLY* exporter will be allowed to mmap to userspace (outside of this
framework - mmap is not a buffer object operation),
- currently, *ONLY* users that do not need CPU access to the buffer are
allowed.
More details are there in the documentation patch.
This is based on design suggestions from many people at the mini-summits[1],
most notably from Arnd Bergmann <arnd@arndb.de>, Rob Clark <rob@ti.com> and
Daniel Vetter <daniel@ffwll.ch>.
The implementation is inspired from proof-of-concept patch-set from
Tomasz Stanislawski <t.stanislaws@samsung.com>, who demonstrated buffer sharing
between two v4l2 devices. [2]
[1]: https://wiki.linaro.org/OfficeofCTO/MemoryManagement
[2]: http://lwn.net/Articles/454389
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
Signed-off-by: Sumit Semwal <sumit.semwal@ti.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-and-Tested-by: Rob Clark <rob.clark@linaro.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-12-26 17:23:15 +08:00
|
|
|
|
|
|
|
/**
|
2020-12-11 23:58:41 +08:00
|
|
|
* dma_buf_get - returns the struct dma_buf related to an fd
|
|
|
|
* @fd: [in] fd associated with the struct dma_buf to be returned
|
dma-buf: Introduce dma buffer sharing mechanism
This is the first step in defining a dma buffer sharing mechanism.
A new buffer object dma_buf is added, with operations and API to allow easy
sharing of this buffer object across devices.
The framework allows:
- creation of a buffer object, its association with a file pointer, and
associated allocator-defined operations on that buffer. This operation is
called the 'export' operation.
- different devices to 'attach' themselves to this exported buffer object, to
facilitate backing storage negotiation, using dma_buf_attach() API.
- the exported buffer object to be shared with the other entity by asking for
its 'file-descriptor (fd)', and sharing the fd across.
- a received fd to get the buffer object back, where it can be accessed using
the associated exporter-defined operations.
- the exporter and user to share the scatterlist associated with this buffer
object using map_dma_buf and unmap_dma_buf operations.
Atleast one 'attach()' call is required to be made prior to calling the
map_dma_buf() operation.
Couple of building blocks in map_dma_buf() are added to ease introduction
of sync'ing across exporter and users, and late allocation by the exporter.
For this first version, this framework will work with certain conditions:
- *ONLY* exporter will be allowed to mmap to userspace (outside of this
framework - mmap is not a buffer object operation),
- currently, *ONLY* users that do not need CPU access to the buffer are
allowed.
More details are there in the documentation patch.
This is based on design suggestions from many people at the mini-summits[1],
most notably from Arnd Bergmann <arnd@arndb.de>, Rob Clark <rob@ti.com> and
Daniel Vetter <daniel@ffwll.ch>.
The implementation is inspired from proof-of-concept patch-set from
Tomasz Stanislawski <t.stanislaws@samsung.com>, who demonstrated buffer sharing
between two v4l2 devices. [2]
[1]: https://wiki.linaro.org/OfficeofCTO/MemoryManagement
[2]: http://lwn.net/Articles/454389
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
Signed-off-by: Sumit Semwal <sumit.semwal@ti.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-and-Tested-by: Rob Clark <rob.clark@linaro.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-12-26 17:23:15 +08:00
|
|
|
*
|
2020-12-11 23:58:41 +08:00
|
|
|
* On success, returns the struct dma_buf associated with an fd; uses
|
dma-buf: Introduce dma buffer sharing mechanism
This is the first step in defining a dma buffer sharing mechanism.
A new buffer object dma_buf is added, with operations and API to allow easy
sharing of this buffer object across devices.
The framework allows:
- creation of a buffer object, its association with a file pointer, and
associated allocator-defined operations on that buffer. This operation is
called the 'export' operation.
- different devices to 'attach' themselves to this exported buffer object, to
facilitate backing storage negotiation, using dma_buf_attach() API.
- the exported buffer object to be shared with the other entity by asking for
its 'file-descriptor (fd)', and sharing the fd across.
- a received fd to get the buffer object back, where it can be accessed using
the associated exporter-defined operations.
- the exporter and user to share the scatterlist associated with this buffer
object using map_dma_buf and unmap_dma_buf operations.
Atleast one 'attach()' call is required to be made prior to calling the
map_dma_buf() operation.
Couple of building blocks in map_dma_buf() are added to ease introduction
of sync'ing across exporter and users, and late allocation by the exporter.
For this first version, this framework will work with certain conditions:
- *ONLY* exporter will be allowed to mmap to userspace (outside of this
framework - mmap is not a buffer object operation),
- currently, *ONLY* users that do not need CPU access to the buffer are
allowed.
More details are there in the documentation patch.
This is based on design suggestions from many people at the mini-summits[1],
most notably from Arnd Bergmann <arnd@arndb.de>, Rob Clark <rob@ti.com> and
Daniel Vetter <daniel@ffwll.ch>.
The implementation is inspired from proof-of-concept patch-set from
Tomasz Stanislawski <t.stanislaws@samsung.com>, who demonstrated buffer sharing
between two v4l2 devices. [2]
[1]: https://wiki.linaro.org/OfficeofCTO/MemoryManagement
[2]: http://lwn.net/Articles/454389
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
Signed-off-by: Sumit Semwal <sumit.semwal@ti.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-and-Tested-by: Rob Clark <rob.clark@linaro.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-12-26 17:23:15 +08:00
|
|
|
* file's refcounting done by fget to increase refcount. returns ERR_PTR
|
|
|
|
* otherwise.
|
|
|
|
*/
|
|
|
|
struct dma_buf *dma_buf_get(int fd)
|
|
|
|
{
|
|
|
|
struct file *file;
|
|
|
|
|
|
|
|
file = fget(fd);
|
|
|
|
|
|
|
|
if (!file)
|
|
|
|
return ERR_PTR(-EBADF);
|
|
|
|
|
|
|
|
if (!is_dma_buf_file(file)) {
|
|
|
|
fput(file);
|
|
|
|
return ERR_PTR(-EINVAL);
|
|
|
|
}
|
|
|
|
|
|
|
|
return file->private_data;
|
|
|
|
}
|
2021-10-10 20:46:28 +08:00
|
|
|
EXPORT_SYMBOL_NS_GPL(dma_buf_get, DMA_BUF);
|
dma-buf: Introduce dma buffer sharing mechanism
This is the first step in defining a dma buffer sharing mechanism.
A new buffer object dma_buf is added, with operations and API to allow easy
sharing of this buffer object across devices.
The framework allows:
- creation of a buffer object, its association with a file pointer, and
associated allocator-defined operations on that buffer. This operation is
called the 'export' operation.
- different devices to 'attach' themselves to this exported buffer object, to
facilitate backing storage negotiation, using dma_buf_attach() API.
- the exported buffer object to be shared with the other entity by asking for
its 'file-descriptor (fd)', and sharing the fd across.
- a received fd to get the buffer object back, where it can be accessed using
the associated exporter-defined operations.
- the exporter and user to share the scatterlist associated with this buffer
object using map_dma_buf and unmap_dma_buf operations.
Atleast one 'attach()' call is required to be made prior to calling the
map_dma_buf() operation.
Couple of building blocks in map_dma_buf() are added to ease introduction
of sync'ing across exporter and users, and late allocation by the exporter.
For this first version, this framework will work with certain conditions:
- *ONLY* exporter will be allowed to mmap to userspace (outside of this
framework - mmap is not a buffer object operation),
- currently, *ONLY* users that do not need CPU access to the buffer are
allowed.
More details are there in the documentation patch.
This is based on design suggestions from many people at the mini-summits[1],
most notably from Arnd Bergmann <arnd@arndb.de>, Rob Clark <rob@ti.com> and
Daniel Vetter <daniel@ffwll.ch>.
The implementation is inspired from proof-of-concept patch-set from
Tomasz Stanislawski <t.stanislaws@samsung.com>, who demonstrated buffer sharing
between two v4l2 devices. [2]
[1]: https://wiki.linaro.org/OfficeofCTO/MemoryManagement
[2]: http://lwn.net/Articles/454389
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
Signed-off-by: Sumit Semwal <sumit.semwal@ti.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-and-Tested-by: Rob Clark <rob.clark@linaro.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-12-26 17:23:15 +08:00
|
|
|
|
|
|
|
/**
|
|
|
|
* dma_buf_put - decreases refcount of the buffer
|
|
|
|
* @dmabuf: [in] buffer to reduce refcount of
|
|
|
|
*
|
2016-12-10 02:53:07 +08:00
|
|
|
* Uses file's refcounting done implicitly by fput().
|
|
|
|
*
|
|
|
|
* If, as a result of this call, the refcount becomes 0, the 'release' file
|
2016-12-30 04:48:25 +08:00
|
|
|
* operation related to this fd is called. It calls &dma_buf_ops.release vfunc
|
|
|
|
* in turn, and frees the memory allocated for dmabuf when exported.
|
dma-buf: Introduce dma buffer sharing mechanism
This is the first step in defining a dma buffer sharing mechanism.
A new buffer object dma_buf is added, with operations and API to allow easy
sharing of this buffer object across devices.
The framework allows:
- creation of a buffer object, its association with a file pointer, and
associated allocator-defined operations on that buffer. This operation is
called the 'export' operation.
- different devices to 'attach' themselves to this exported buffer object, to
facilitate backing storage negotiation, using dma_buf_attach() API.
- the exported buffer object to be shared with the other entity by asking for
its 'file-descriptor (fd)', and sharing the fd across.
- a received fd to get the buffer object back, where it can be accessed using
the associated exporter-defined operations.
- the exporter and user to share the scatterlist associated with this buffer
object using map_dma_buf and unmap_dma_buf operations.
Atleast one 'attach()' call is required to be made prior to calling the
map_dma_buf() operation.
Couple of building blocks in map_dma_buf() are added to ease introduction
of sync'ing across exporter and users, and late allocation by the exporter.
For this first version, this framework will work with certain conditions:
- *ONLY* exporter will be allowed to mmap to userspace (outside of this
framework - mmap is not a buffer object operation),
- currently, *ONLY* users that do not need CPU access to the buffer are
allowed.
More details are there in the documentation patch.
This is based on design suggestions from many people at the mini-summits[1],
most notably from Arnd Bergmann <arnd@arndb.de>, Rob Clark <rob@ti.com> and
Daniel Vetter <daniel@ffwll.ch>.
The implementation is inspired from proof-of-concept patch-set from
Tomasz Stanislawski <t.stanislaws@samsung.com>, who demonstrated buffer sharing
between two v4l2 devices. [2]
[1]: https://wiki.linaro.org/OfficeofCTO/MemoryManagement
[2]: http://lwn.net/Articles/454389
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
Signed-off-by: Sumit Semwal <sumit.semwal@ti.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-and-Tested-by: Rob Clark <rob.clark@linaro.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-12-26 17:23:15 +08:00
|
|
|
*/
|
|
|
|
void dma_buf_put(struct dma_buf *dmabuf)
|
|
|
|
{
|
|
|
|
if (WARN_ON(!dmabuf || !dmabuf->file))
|
|
|
|
return;
|
|
|
|
|
|
|
|
fput(dmabuf->file);
|
|
|
|
}
|
2021-10-10 20:46:28 +08:00
|
|
|
EXPORT_SYMBOL_NS_GPL(dma_buf_put, DMA_BUF);
|
dma-buf: Introduce dma buffer sharing mechanism
This is the first step in defining a dma buffer sharing mechanism.
A new buffer object dma_buf is added, with operations and API to allow easy
sharing of this buffer object across devices.
The framework allows:
- creation of a buffer object, its association with a file pointer, and
associated allocator-defined operations on that buffer. This operation is
called the 'export' operation.
- different devices to 'attach' themselves to this exported buffer object, to
facilitate backing storage negotiation, using dma_buf_attach() API.
- the exported buffer object to be shared with the other entity by asking for
its 'file-descriptor (fd)', and sharing the fd across.
- a received fd to get the buffer object back, where it can be accessed using
the associated exporter-defined operations.
- the exporter and user to share the scatterlist associated with this buffer
object using map_dma_buf and unmap_dma_buf operations.
Atleast one 'attach()' call is required to be made prior to calling the
map_dma_buf() operation.
Couple of building blocks in map_dma_buf() are added to ease introduction
of sync'ing across exporter and users, and late allocation by the exporter.
For this first version, this framework will work with certain conditions:
- *ONLY* exporter will be allowed to mmap to userspace (outside of this
framework - mmap is not a buffer object operation),
- currently, *ONLY* users that do not need CPU access to the buffer are
allowed.
More details are there in the documentation patch.
This is based on design suggestions from many people at the mini-summits[1],
most notably from Arnd Bergmann <arnd@arndb.de>, Rob Clark <rob@ti.com> and
Daniel Vetter <daniel@ffwll.ch>.
The implementation is inspired from proof-of-concept patch-set from
Tomasz Stanislawski <t.stanislaws@samsung.com>, who demonstrated buffer sharing
between two v4l2 devices. [2]
[1]: https://wiki.linaro.org/OfficeofCTO/MemoryManagement
[2]: http://lwn.net/Articles/454389
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
Signed-off-by: Sumit Semwal <sumit.semwal@ti.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-and-Tested-by: Rob Clark <rob.clark@linaro.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-12-26 17:23:15 +08:00
|
|
|
|
2021-01-16 00:47:39 +08:00
|
|
|
static void mangle_sg_table(struct sg_table *sg_table)
|
|
|
|
{
|
|
|
|
#ifdef CONFIG_DMABUF_DEBUG
|
|
|
|
int i;
|
|
|
|
struct scatterlist *sg;
|
|
|
|
|
|
|
|
/* To catch abuse of the underlying struct page by importers mix
|
|
|
|
* up the bits, but take care to preserve the low SG_ bits to
|
|
|
|
* not corrupt the sgt. The mixing is undone in __unmap_dma_buf
|
|
|
|
* before passing the sgt back to the exporter. */
|
|
|
|
for_each_sgtable_sg(sg_table, sg, i)
|
|
|
|
sg->page_link ^= ~0xffUL;
|
|
|
|
#endif
|
|
|
|
|
|
|
|
}
|
|
|
|
static struct sg_table * __map_dma_buf(struct dma_buf_attachment *attach,
|
|
|
|
enum dma_data_direction direction)
|
|
|
|
{
|
|
|
|
struct sg_table *sg_table;
|
2021-11-23 16:58:36 +08:00
|
|
|
signed long ret;
|
2021-01-16 00:47:39 +08:00
|
|
|
|
|
|
|
sg_table = attach->dmabuf->ops->map_dma_buf(attach, direction);
|
2021-11-23 16:58:36 +08:00
|
|
|
if (IS_ERR_OR_NULL(sg_table))
|
|
|
|
return sg_table;
|
|
|
|
|
|
|
|
if (!dma_buf_attachment_is_dynamic(attach)) {
|
|
|
|
ret = dma_resv_wait_timeout(attach->dmabuf->resv,
|
|
|
|
DMA_RESV_USAGE_KERNEL, true,
|
|
|
|
MAX_SCHEDULE_TIMEOUT);
|
|
|
|
if (ret < 0) {
|
|
|
|
attach->dmabuf->ops->unmap_dma_buf(attach, sg_table,
|
|
|
|
direction);
|
|
|
|
return ERR_PTR(ret);
|
|
|
|
}
|
|
|
|
}
|
2021-01-16 00:47:39 +08:00
|
|
|
|
2021-11-23 16:58:36 +08:00
|
|
|
mangle_sg_table(sg_table);
|
2021-01-16 00:47:39 +08:00
|
|
|
return sg_table;
|
|
|
|
}
|
|
|
|
|
2022-10-18 01:22:27 +08:00
|
|
|
/**
|
|
|
|
* DOC: locking convention
|
|
|
|
*
|
|
|
|
* In order to avoid deadlock situations between dma-buf exports and importers,
|
|
|
|
* all dma-buf API users must follow the common dma-buf locking convention.
|
|
|
|
*
|
|
|
|
* Convention for importers
|
|
|
|
*
|
|
|
|
* 1. Importers must hold the dma-buf reservation lock when calling these
|
|
|
|
* functions:
|
|
|
|
*
|
|
|
|
* - dma_buf_pin()
|
|
|
|
* - dma_buf_unpin()
|
|
|
|
* - dma_buf_map_attachment()
|
|
|
|
* - dma_buf_unmap_attachment()
|
|
|
|
* - dma_buf_vmap()
|
|
|
|
* - dma_buf_vunmap()
|
|
|
|
*
|
|
|
|
* 2. Importers must not hold the dma-buf reservation lock when calling these
|
|
|
|
* functions:
|
|
|
|
*
|
|
|
|
* - dma_buf_attach()
|
|
|
|
* - dma_buf_dynamic_attach()
|
|
|
|
* - dma_buf_detach()
|
2023-02-23 20:19:09 +08:00
|
|
|
* - dma_buf_export()
|
2022-10-18 01:22:27 +08:00
|
|
|
* - dma_buf_fd()
|
|
|
|
* - dma_buf_get()
|
|
|
|
* - dma_buf_put()
|
|
|
|
* - dma_buf_mmap()
|
|
|
|
* - dma_buf_begin_cpu_access()
|
|
|
|
* - dma_buf_end_cpu_access()
|
|
|
|
* - dma_buf_map_attachment_unlocked()
|
|
|
|
* - dma_buf_unmap_attachment_unlocked()
|
|
|
|
* - dma_buf_vmap_unlocked()
|
|
|
|
* - dma_buf_vunmap_unlocked()
|
|
|
|
*
|
|
|
|
* Convention for exporters
|
|
|
|
*
|
|
|
|
* 1. These &dma_buf_ops callbacks are invoked with unlocked dma-buf
|
|
|
|
* reservation and exporter can take the lock:
|
|
|
|
*
|
|
|
|
* - &dma_buf_ops.attach()
|
|
|
|
* - &dma_buf_ops.detach()
|
|
|
|
* - &dma_buf_ops.release()
|
|
|
|
* - &dma_buf_ops.begin_cpu_access()
|
|
|
|
* - &dma_buf_ops.end_cpu_access()
|
2023-05-30 06:39:34 +08:00
|
|
|
* - &dma_buf_ops.mmap()
|
2022-10-18 01:22:27 +08:00
|
|
|
*
|
|
|
|
* 2. These &dma_buf_ops callbacks are invoked with locked dma-buf
|
|
|
|
* reservation and exporter can't take the lock:
|
|
|
|
*
|
|
|
|
* - &dma_buf_ops.pin()
|
|
|
|
* - &dma_buf_ops.unpin()
|
|
|
|
* - &dma_buf_ops.map_dma_buf()
|
|
|
|
* - &dma_buf_ops.unmap_dma_buf()
|
|
|
|
* - &dma_buf_ops.vmap()
|
|
|
|
* - &dma_buf_ops.vunmap()
|
|
|
|
*
|
|
|
|
* 3. Exporters must hold the dma-buf reservation lock when calling these
|
|
|
|
* functions:
|
|
|
|
*
|
|
|
|
* - dma_buf_move_notify()
|
|
|
|
*/
|
|
|
|
|
dma-buf: Introduce dma buffer sharing mechanism
This is the first step in defining a dma buffer sharing mechanism.
A new buffer object dma_buf is added, with operations and API to allow easy
sharing of this buffer object across devices.
The framework allows:
- creation of a buffer object, its association with a file pointer, and
associated allocator-defined operations on that buffer. This operation is
called the 'export' operation.
- different devices to 'attach' themselves to this exported buffer object, to
facilitate backing storage negotiation, using dma_buf_attach() API.
- the exported buffer object to be shared with the other entity by asking for
its 'file-descriptor (fd)', and sharing the fd across.
- a received fd to get the buffer object back, where it can be accessed using
the associated exporter-defined operations.
- the exporter and user to share the scatterlist associated with this buffer
object using map_dma_buf and unmap_dma_buf operations.
Atleast one 'attach()' call is required to be made prior to calling the
map_dma_buf() operation.
Couple of building blocks in map_dma_buf() are added to ease introduction
of sync'ing across exporter and users, and late allocation by the exporter.
For this first version, this framework will work with certain conditions:
- *ONLY* exporter will be allowed to mmap to userspace (outside of this
framework - mmap is not a buffer object operation),
- currently, *ONLY* users that do not need CPU access to the buffer are
allowed.
More details are there in the documentation patch.
This is based on design suggestions from many people at the mini-summits[1],
most notably from Arnd Bergmann <arnd@arndb.de>, Rob Clark <rob@ti.com> and
Daniel Vetter <daniel@ffwll.ch>.
The implementation is inspired from proof-of-concept patch-set from
Tomasz Stanislawski <t.stanislaws@samsung.com>, who demonstrated buffer sharing
between two v4l2 devices. [2]
[1]: https://wiki.linaro.org/OfficeofCTO/MemoryManagement
[2]: http://lwn.net/Articles/454389
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
Signed-off-by: Sumit Semwal <sumit.semwal@ti.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-and-Tested-by: Rob Clark <rob.clark@linaro.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-12-26 17:23:15 +08:00
|
|
|
/**
|
2020-12-11 23:58:41 +08:00
|
|
|
* dma_buf_dynamic_attach - Add the device to dma_buf's attachments list
|
dma-buf: change DMA-buf locking convention v3
This patch is a stripped down version of the locking changes
necessary to support dynamic DMA-buf handling.
It adds a dynamic flag for both importers as well as exporters
so that drivers can choose if they want the reservation object
locked or unlocked during mapping of attachments.
For compatibility between drivers we cache the DMA-buf mapping
during attaching an importer as soon as exporter/importer
disagree on the dynamic handling.
Issues and solutions we considered:
- We can't change all existing drivers, and existing improters have
strong opinions about which locks they're holding while calling
dma_buf_attachment_map/unmap. Exporters also have strong opinions about
which locks they can acquire in their ->map/unmap callbacks, levaing no
room for change. The solution to avoid this was to move the
actual map/unmap out from this call, into the attach/detach callbacks,
and cache the mapping. This works because drivers don't call
attach/detach from deep within their code callchains (like deep in
memory management code called from cs/execbuf ioctl), but directly from
the fd2handle implementation.
- The caching has some troubles on some soc drivers, which set other modes
than DMA_BIDIRECTIONAL. We can't have 2 incompatible mappings, and we
can't re-create the mapping at _map time due to the above locking fun.
We very carefuly step around that by only caching at attach time if the
dynamic mode between importer/expoert mismatches.
- There's been quite some discussion on dma-buf mappings which need active
cache management, which would all break down when caching, plus we don't
have explicit flush operations on the attachment side. The solution to
this was to shrug and keep the current discrepancy between what the
dma-buf docs claim and what implementations do, with the hope that the
begin/end_cpu_access hooks are good enough and that all necessary
flushing to keep device mappings consistent will be done there.
v2: cleanup set_name merge, improve kerneldoc
v3: update commit message, kerneldoc and cleanup _debug_show()
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/336788/
2018-07-03 22:42:26 +08:00
|
|
|
* @dmabuf: [in] buffer to attach device to.
|
|
|
|
* @dev: [in] device to be attached.
|
2020-04-08 12:20:34 +08:00
|
|
|
* @importer_ops: [in] importer operations for the attachment
|
|
|
|
* @importer_priv: [in] importer private pointer for the attachment
|
dma-buf: Introduce dma buffer sharing mechanism
This is the first step in defining a dma buffer sharing mechanism.
A new buffer object dma_buf is added, with operations and API to allow easy
sharing of this buffer object across devices.
The framework allows:
- creation of a buffer object, its association with a file pointer, and
associated allocator-defined operations on that buffer. This operation is
called the 'export' operation.
- different devices to 'attach' themselves to this exported buffer object, to
facilitate backing storage negotiation, using dma_buf_attach() API.
- the exported buffer object to be shared with the other entity by asking for
its 'file-descriptor (fd)', and sharing the fd across.
- a received fd to get the buffer object back, where it can be accessed using
the associated exporter-defined operations.
- the exporter and user to share the scatterlist associated with this buffer
object using map_dma_buf and unmap_dma_buf operations.
Atleast one 'attach()' call is required to be made prior to calling the
map_dma_buf() operation.
Couple of building blocks in map_dma_buf() are added to ease introduction
of sync'ing across exporter and users, and late allocation by the exporter.
For this first version, this framework will work with certain conditions:
- *ONLY* exporter will be allowed to mmap to userspace (outside of this
framework - mmap is not a buffer object operation),
- currently, *ONLY* users that do not need CPU access to the buffer are
allowed.
More details are there in the documentation patch.
This is based on design suggestions from many people at the mini-summits[1],
most notably from Arnd Bergmann <arnd@arndb.de>, Rob Clark <rob@ti.com> and
Daniel Vetter <daniel@ffwll.ch>.
The implementation is inspired from proof-of-concept patch-set from
Tomasz Stanislawski <t.stanislaws@samsung.com>, who demonstrated buffer sharing
between two v4l2 devices. [2]
[1]: https://wiki.linaro.org/OfficeofCTO/MemoryManagement
[2]: http://lwn.net/Articles/454389
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
Signed-off-by: Sumit Semwal <sumit.semwal@ti.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-and-Tested-by: Rob Clark <rob.clark@linaro.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-12-26 17:23:15 +08:00
|
|
|
*
|
2016-12-10 02:53:07 +08:00
|
|
|
* Returns struct dma_buf_attachment pointer for this attachment. Attachments
|
|
|
|
* must be cleaned up by calling dma_buf_detach().
|
|
|
|
*
|
2020-12-11 23:58:41 +08:00
|
|
|
* Optionally this calls &dma_buf_ops.attach to allow device-specific attach
|
|
|
|
* functionality.
|
|
|
|
*
|
2016-12-10 02:53:07 +08:00
|
|
|
* Returns:
|
|
|
|
*
|
|
|
|
* A pointer to newly created &dma_buf_attachment on success, or a negative
|
|
|
|
* error code wrapped into a pointer on failure.
|
|
|
|
*
|
|
|
|
* Note that this can fail if the backing storage of @dmabuf is in a place not
|
|
|
|
* accessible to @dev, and cannot be moved to a more suitable place. This is
|
|
|
|
* indicated with the error code -EBUSY.
|
dma-buf: Introduce dma buffer sharing mechanism
This is the first step in defining a dma buffer sharing mechanism.
A new buffer object dma_buf is added, with operations and API to allow easy
sharing of this buffer object across devices.
The framework allows:
- creation of a buffer object, its association with a file pointer, and
associated allocator-defined operations on that buffer. This operation is
called the 'export' operation.
- different devices to 'attach' themselves to this exported buffer object, to
facilitate backing storage negotiation, using dma_buf_attach() API.
- the exported buffer object to be shared with the other entity by asking for
its 'file-descriptor (fd)', and sharing the fd across.
- a received fd to get the buffer object back, where it can be accessed using
the associated exporter-defined operations.
- the exporter and user to share the scatterlist associated with this buffer
object using map_dma_buf and unmap_dma_buf operations.
Atleast one 'attach()' call is required to be made prior to calling the
map_dma_buf() operation.
Couple of building blocks in map_dma_buf() are added to ease introduction
of sync'ing across exporter and users, and late allocation by the exporter.
For this first version, this framework will work with certain conditions:
- *ONLY* exporter will be allowed to mmap to userspace (outside of this
framework - mmap is not a buffer object operation),
- currently, *ONLY* users that do not need CPU access to the buffer are
allowed.
More details are there in the documentation patch.
This is based on design suggestions from many people at the mini-summits[1],
most notably from Arnd Bergmann <arnd@arndb.de>, Rob Clark <rob@ti.com> and
Daniel Vetter <daniel@ffwll.ch>.
The implementation is inspired from proof-of-concept patch-set from
Tomasz Stanislawski <t.stanislaws@samsung.com>, who demonstrated buffer sharing
between two v4l2 devices. [2]
[1]: https://wiki.linaro.org/OfficeofCTO/MemoryManagement
[2]: http://lwn.net/Articles/454389
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
Signed-off-by: Sumit Semwal <sumit.semwal@ti.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-and-Tested-by: Rob Clark <rob.clark@linaro.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-12-26 17:23:15 +08:00
|
|
|
*/
|
dma-buf: change DMA-buf locking convention v3
This patch is a stripped down version of the locking changes
necessary to support dynamic DMA-buf handling.
It adds a dynamic flag for both importers as well as exporters
so that drivers can choose if they want the reservation object
locked or unlocked during mapping of attachments.
For compatibility between drivers we cache the DMA-buf mapping
during attaching an importer as soon as exporter/importer
disagree on the dynamic handling.
Issues and solutions we considered:
- We can't change all existing drivers, and existing improters have
strong opinions about which locks they're holding while calling
dma_buf_attachment_map/unmap. Exporters also have strong opinions about
which locks they can acquire in their ->map/unmap callbacks, levaing no
room for change. The solution to avoid this was to move the
actual map/unmap out from this call, into the attach/detach callbacks,
and cache the mapping. This works because drivers don't call
attach/detach from deep within their code callchains (like deep in
memory management code called from cs/execbuf ioctl), but directly from
the fd2handle implementation.
- The caching has some troubles on some soc drivers, which set other modes
than DMA_BIDIRECTIONAL. We can't have 2 incompatible mappings, and we
can't re-create the mapping at _map time due to the above locking fun.
We very carefuly step around that by only caching at attach time if the
dynamic mode between importer/expoert mismatches.
- There's been quite some discussion on dma-buf mappings which need active
cache management, which would all break down when caching, plus we don't
have explicit flush operations on the attachment side. The solution to
this was to shrug and keep the current discrepancy between what the
dma-buf docs claim and what implementations do, with the hope that the
begin/end_cpu_access hooks are good enough and that all necessary
flushing to keep device mappings consistent will be done there.
v2: cleanup set_name merge, improve kerneldoc
v3: update commit message, kerneldoc and cleanup _debug_show()
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/336788/
2018-07-03 22:42:26 +08:00
|
|
|
struct dma_buf_attachment *
|
|
|
|
dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct device *dev,
|
2018-07-03 22:42:26 +08:00
|
|
|
const struct dma_buf_attach_ops *importer_ops,
|
|
|
|
void *importer_priv)
|
dma-buf: Introduce dma buffer sharing mechanism
This is the first step in defining a dma buffer sharing mechanism.
A new buffer object dma_buf is added, with operations and API to allow easy
sharing of this buffer object across devices.
The framework allows:
- creation of a buffer object, its association with a file pointer, and
associated allocator-defined operations on that buffer. This operation is
called the 'export' operation.
- different devices to 'attach' themselves to this exported buffer object, to
facilitate backing storage negotiation, using dma_buf_attach() API.
- the exported buffer object to be shared with the other entity by asking for
its 'file-descriptor (fd)', and sharing the fd across.
- a received fd to get the buffer object back, where it can be accessed using
the associated exporter-defined operations.
- the exporter and user to share the scatterlist associated with this buffer
object using map_dma_buf and unmap_dma_buf operations.
Atleast one 'attach()' call is required to be made prior to calling the
map_dma_buf() operation.
Couple of building blocks in map_dma_buf() are added to ease introduction
of sync'ing across exporter and users, and late allocation by the exporter.
For this first version, this framework will work with certain conditions:
- *ONLY* exporter will be allowed to mmap to userspace (outside of this
framework - mmap is not a buffer object operation),
- currently, *ONLY* users that do not need CPU access to the buffer are
allowed.
More details are there in the documentation patch.
This is based on design suggestions from many people at the mini-summits[1],
most notably from Arnd Bergmann <arnd@arndb.de>, Rob Clark <rob@ti.com> and
Daniel Vetter <daniel@ffwll.ch>.
The implementation is inspired from proof-of-concept patch-set from
Tomasz Stanislawski <t.stanislaws@samsung.com>, who demonstrated buffer sharing
between two v4l2 devices. [2]
[1]: https://wiki.linaro.org/OfficeofCTO/MemoryManagement
[2]: http://lwn.net/Articles/454389
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
Signed-off-by: Sumit Semwal <sumit.semwal@ti.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-and-Tested-by: Rob Clark <rob.clark@linaro.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-12-26 17:23:15 +08:00
|
|
|
{
|
|
|
|
struct dma_buf_attachment *attach;
|
|
|
|
int ret;
|
|
|
|
|
2012-01-26 19:27:23 +08:00
|
|
|
if (WARN_ON(!dmabuf || !dev))
|
dma-buf: Introduce dma buffer sharing mechanism
This is the first step in defining a dma buffer sharing mechanism.
A new buffer object dma_buf is added, with operations and API to allow easy
sharing of this buffer object across devices.
The framework allows:
- creation of a buffer object, its association with a file pointer, and
associated allocator-defined operations on that buffer. This operation is
called the 'export' operation.
- different devices to 'attach' themselves to this exported buffer object, to
facilitate backing storage negotiation, using dma_buf_attach() API.
- the exported buffer object to be shared with the other entity by asking for
its 'file-descriptor (fd)', and sharing the fd across.
- a received fd to get the buffer object back, where it can be accessed using
the associated exporter-defined operations.
- the exporter and user to share the scatterlist associated with this buffer
object using map_dma_buf and unmap_dma_buf operations.
Atleast one 'attach()' call is required to be made prior to calling the
map_dma_buf() operation.
Couple of building blocks in map_dma_buf() are added to ease introduction
of sync'ing across exporter and users, and late allocation by the exporter.
For this first version, this framework will work with certain conditions:
- *ONLY* exporter will be allowed to mmap to userspace (outside of this
framework - mmap is not a buffer object operation),
- currently, *ONLY* users that do not need CPU access to the buffer are
allowed.
More details are there in the documentation patch.
This is based on design suggestions from many people at the mini-summits[1],
most notably from Arnd Bergmann <arnd@arndb.de>, Rob Clark <rob@ti.com> and
Daniel Vetter <daniel@ffwll.ch>.
The implementation is inspired from proof-of-concept patch-set from
Tomasz Stanislawski <t.stanislaws@samsung.com>, who demonstrated buffer sharing
between two v4l2 devices. [2]
[1]: https://wiki.linaro.org/OfficeofCTO/MemoryManagement
[2]: http://lwn.net/Articles/454389
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
Signed-off-by: Sumit Semwal <sumit.semwal@ti.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-and-Tested-by: Rob Clark <rob.clark@linaro.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-12-26 17:23:15 +08:00
|
|
|
return ERR_PTR(-EINVAL);
|
|
|
|
|
2020-02-19 20:32:43 +08:00
|
|
|
if (WARN_ON(importer_ops && !importer_ops->move_notify))
|
|
|
|
return ERR_PTR(-EINVAL);
|
|
|
|
|
2017-05-08 16:50:09 +08:00
|
|
|
attach = kzalloc(sizeof(*attach), GFP_KERNEL);
|
2017-05-08 16:54:17 +08:00
|
|
|
if (!attach)
|
2012-01-26 19:27:24 +08:00
|
|
|
return ERR_PTR(-ENOMEM);
|
dma-buf: Introduce dma buffer sharing mechanism
This is the first step in defining a dma buffer sharing mechanism.
A new buffer object dma_buf is added, with operations and API to allow easy
sharing of this buffer object across devices.
The framework allows:
- creation of a buffer object, its association with a file pointer, and
associated allocator-defined operations on that buffer. This operation is
called the 'export' operation.
- different devices to 'attach' themselves to this exported buffer object, to
facilitate backing storage negotiation, using dma_buf_attach() API.
- the exported buffer object to be shared with the other entity by asking for
its 'file-descriptor (fd)', and sharing the fd across.
- a received fd to get the buffer object back, where it can be accessed using
the associated exporter-defined operations.
- the exporter and user to share the scatterlist associated with this buffer
object using map_dma_buf and unmap_dma_buf operations.
Atleast one 'attach()' call is required to be made prior to calling the
map_dma_buf() operation.
Couple of building blocks in map_dma_buf() are added to ease introduction
of sync'ing across exporter and users, and late allocation by the exporter.
For this first version, this framework will work with certain conditions:
- *ONLY* exporter will be allowed to mmap to userspace (outside of this
framework - mmap is not a buffer object operation),
- currently, *ONLY* users that do not need CPU access to the buffer are
allowed.
More details are there in the documentation patch.
This is based on design suggestions from many people at the mini-summits[1],
most notably from Arnd Bergmann <arnd@arndb.de>, Rob Clark <rob@ti.com> and
Daniel Vetter <daniel@ffwll.ch>.
The implementation is inspired from proof-of-concept patch-set from
Tomasz Stanislawski <t.stanislaws@samsung.com>, who demonstrated buffer sharing
between two v4l2 devices. [2]
[1]: https://wiki.linaro.org/OfficeofCTO/MemoryManagement
[2]: http://lwn.net/Articles/454389
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
Signed-off-by: Sumit Semwal <sumit.semwal@ti.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-and-Tested-by: Rob Clark <rob.clark@linaro.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-12-26 17:23:15 +08:00
|
|
|
|
|
|
|
attach->dev = dev;
|
|
|
|
attach->dmabuf = dmabuf;
|
2018-03-23 00:09:42 +08:00
|
|
|
if (importer_ops)
|
|
|
|
attach->peer2peer = importer_ops->allow_peer2peer;
|
2018-07-03 22:42:26 +08:00
|
|
|
attach->importer_ops = importer_ops;
|
|
|
|
attach->importer_priv = importer_priv;
|
2012-01-26 19:27:25 +08:00
|
|
|
|
dma-buf: Introduce dma buffer sharing mechanism
This is the first step in defining a dma buffer sharing mechanism.
A new buffer object dma_buf is added, with operations and API to allow easy
sharing of this buffer object across devices.
The framework allows:
- creation of a buffer object, its association with a file pointer, and
associated allocator-defined operations on that buffer. This operation is
called the 'export' operation.
- different devices to 'attach' themselves to this exported buffer object, to
facilitate backing storage negotiation, using dma_buf_attach() API.
- the exported buffer object to be shared with the other entity by asking for
its 'file-descriptor (fd)', and sharing the fd across.
- a received fd to get the buffer object back, where it can be accessed using
the associated exporter-defined operations.
- the exporter and user to share the scatterlist associated with this buffer
object using map_dma_buf and unmap_dma_buf operations.
Atleast one 'attach()' call is required to be made prior to calling the
map_dma_buf() operation.
Couple of building blocks in map_dma_buf() are added to ease introduction
of sync'ing across exporter and users, and late allocation by the exporter.
For this first version, this framework will work with certain conditions:
- *ONLY* exporter will be allowed to mmap to userspace (outside of this
framework - mmap is not a buffer object operation),
- currently, *ONLY* users that do not need CPU access to the buffer are
allowed.
More details are there in the documentation patch.
This is based on design suggestions from many people at the mini-summits[1],
most notably from Arnd Bergmann <arnd@arndb.de>, Rob Clark <rob@ti.com> and
Daniel Vetter <daniel@ffwll.ch>.
The implementation is inspired from proof-of-concept patch-set from
Tomasz Stanislawski <t.stanislaws@samsung.com>, who demonstrated buffer sharing
between two v4l2 devices. [2]
[1]: https://wiki.linaro.org/OfficeofCTO/MemoryManagement
[2]: http://lwn.net/Articles/454389
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
Signed-off-by: Sumit Semwal <sumit.semwal@ti.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-and-Tested-by: Rob Clark <rob.clark@linaro.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-12-26 17:23:15 +08:00
|
|
|
if (dmabuf->ops->attach) {
|
2018-05-28 17:47:52 +08:00
|
|
|
ret = dmabuf->ops->attach(dmabuf, attach);
|
dma-buf: Introduce dma buffer sharing mechanism
This is the first step in defining a dma buffer sharing mechanism.
A new buffer object dma_buf is added, with operations and API to allow easy
sharing of this buffer object across devices.
The framework allows:
- creation of a buffer object, its association with a file pointer, and
associated allocator-defined operations on that buffer. This operation is
called the 'export' operation.
- different devices to 'attach' themselves to this exported buffer object, to
facilitate backing storage negotiation, using dma_buf_attach() API.
- the exported buffer object to be shared with the other entity by asking for
its 'file-descriptor (fd)', and sharing the fd across.
- a received fd to get the buffer object back, where it can be accessed using
the associated exporter-defined operations.
- the exporter and user to share the scatterlist associated with this buffer
object using map_dma_buf and unmap_dma_buf operations.
Atleast one 'attach()' call is required to be made prior to calling the
map_dma_buf() operation.
Couple of building blocks in map_dma_buf() are added to ease introduction
of sync'ing across exporter and users, and late allocation by the exporter.
For this first version, this framework will work with certain conditions:
- *ONLY* exporter will be allowed to mmap to userspace (outside of this
framework - mmap is not a buffer object operation),
- currently, *ONLY* users that do not need CPU access to the buffer are
allowed.
More details are there in the documentation patch.
This is based on design suggestions from many people at the mini-summits[1],
most notably from Arnd Bergmann <arnd@arndb.de>, Rob Clark <rob@ti.com> and
Daniel Vetter <daniel@ffwll.ch>.
The implementation is inspired from proof-of-concept patch-set from
Tomasz Stanislawski <t.stanislaws@samsung.com>, who demonstrated buffer sharing
between two v4l2 devices. [2]
[1]: https://wiki.linaro.org/OfficeofCTO/MemoryManagement
[2]: http://lwn.net/Articles/454389
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
Signed-off-by: Sumit Semwal <sumit.semwal@ti.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-and-Tested-by: Rob Clark <rob.clark@linaro.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-12-26 17:23:15 +08:00
|
|
|
if (ret)
|
|
|
|
goto err_attach;
|
|
|
|
}
|
dma-buf: change DMA-buf locking convention v3
This patch is a stripped down version of the locking changes
necessary to support dynamic DMA-buf handling.
It adds a dynamic flag for both importers as well as exporters
so that drivers can choose if they want the reservation object
locked or unlocked during mapping of attachments.
For compatibility between drivers we cache the DMA-buf mapping
during attaching an importer as soon as exporter/importer
disagree on the dynamic handling.
Issues and solutions we considered:
- We can't change all existing drivers, and existing improters have
strong opinions about which locks they're holding while calling
dma_buf_attachment_map/unmap. Exporters also have strong opinions about
which locks they can acquire in their ->map/unmap callbacks, levaing no
room for change. The solution to avoid this was to move the
actual map/unmap out from this call, into the attach/detach callbacks,
and cache the mapping. This works because drivers don't call
attach/detach from deep within their code callchains (like deep in
memory management code called from cs/execbuf ioctl), but directly from
the fd2handle implementation.
- The caching has some troubles on some soc drivers, which set other modes
than DMA_BIDIRECTIONAL. We can't have 2 incompatible mappings, and we
can't re-create the mapping at _map time due to the above locking fun.
We very carefuly step around that by only caching at attach time if the
dynamic mode between importer/expoert mismatches.
- There's been quite some discussion on dma-buf mappings which need active
cache management, which would all break down when caching, plus we don't
have explicit flush operations on the attachment side. The solution to
this was to shrug and keep the current discrepancy between what the
dma-buf docs claim and what implementations do, with the hope that the
begin/end_cpu_access hooks are good enough and that all necessary
flushing to keep device mappings consistent will be done there.
v2: cleanup set_name merge, improve kerneldoc
v3: update commit message, kerneldoc and cleanup _debug_show()
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/336788/
2018-07-03 22:42:26 +08:00
|
|
|
dma_resv_lock(dmabuf->resv, NULL);
|
dma-buf: Introduce dma buffer sharing mechanism
This is the first step in defining a dma buffer sharing mechanism.
A new buffer object dma_buf is added, with operations and API to allow easy
sharing of this buffer object across devices.
The framework allows:
- creation of a buffer object, its association with a file pointer, and
associated allocator-defined operations on that buffer. This operation is
called the 'export' operation.
- different devices to 'attach' themselves to this exported buffer object, to
facilitate backing storage negotiation, using dma_buf_attach() API.
- the exported buffer object to be shared with the other entity by asking for
its 'file-descriptor (fd)', and sharing the fd across.
- a received fd to get the buffer object back, where it can be accessed using
the associated exporter-defined operations.
- the exporter and user to share the scatterlist associated with this buffer
object using map_dma_buf and unmap_dma_buf operations.
Atleast one 'attach()' call is required to be made prior to calling the
map_dma_buf() operation.
Couple of building blocks in map_dma_buf() are added to ease introduction
of sync'ing across exporter and users, and late allocation by the exporter.
For this first version, this framework will work with certain conditions:
- *ONLY* exporter will be allowed to mmap to userspace (outside of this
framework - mmap is not a buffer object operation),
- currently, *ONLY* users that do not need CPU access to the buffer are
allowed.
More details are there in the documentation patch.
This is based on design suggestions from many people at the mini-summits[1],
most notably from Arnd Bergmann <arnd@arndb.de>, Rob Clark <rob@ti.com> and
Daniel Vetter <daniel@ffwll.ch>.
The implementation is inspired from proof-of-concept patch-set from
Tomasz Stanislawski <t.stanislaws@samsung.com>, who demonstrated buffer sharing
between two v4l2 devices. [2]
[1]: https://wiki.linaro.org/OfficeofCTO/MemoryManagement
[2]: http://lwn.net/Articles/454389
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
Signed-off-by: Sumit Semwal <sumit.semwal@ti.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-and-Tested-by: Rob Clark <rob.clark@linaro.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-12-26 17:23:15 +08:00
|
|
|
list_add(&attach->node, &dmabuf->attachments);
|
dma-buf: change DMA-buf locking convention v3
This patch is a stripped down version of the locking changes
necessary to support dynamic DMA-buf handling.
It adds a dynamic flag for both importers as well as exporters
so that drivers can choose if they want the reservation object
locked or unlocked during mapping of attachments.
For compatibility between drivers we cache the DMA-buf mapping
during attaching an importer as soon as exporter/importer
disagree on the dynamic handling.
Issues and solutions we considered:
- We can't change all existing drivers, and existing improters have
strong opinions about which locks they're holding while calling
dma_buf_attachment_map/unmap. Exporters also have strong opinions about
which locks they can acquire in their ->map/unmap callbacks, levaing no
room for change. The solution to avoid this was to move the
actual map/unmap out from this call, into the attach/detach callbacks,
and cache the mapping. This works because drivers don't call
attach/detach from deep within their code callchains (like deep in
memory management code called from cs/execbuf ioctl), but directly from
the fd2handle implementation.
- The caching has some troubles on some soc drivers, which set other modes
than DMA_BIDIRECTIONAL. We can't have 2 incompatible mappings, and we
can't re-create the mapping at _map time due to the above locking fun.
We very carefuly step around that by only caching at attach time if the
dynamic mode between importer/expoert mismatches.
- There's been quite some discussion on dma-buf mappings which need active
cache management, which would all break down when caching, plus we don't
have explicit flush operations on the attachment side. The solution to
this was to shrug and keep the current discrepancy between what the
dma-buf docs claim and what implementations do, with the hope that the
begin/end_cpu_access hooks are good enough and that all necessary
flushing to keep device mappings consistent will be done there.
v2: cleanup set_name merge, improve kerneldoc
v3: update commit message, kerneldoc and cleanup _debug_show()
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/336788/
2018-07-03 22:42:26 +08:00
|
|
|
dma_resv_unlock(dmabuf->resv);
|
dma-buf: Introduce dma buffer sharing mechanism
This is the first step in defining a dma buffer sharing mechanism.
A new buffer object dma_buf is added, with operations and API to allow easy
sharing of this buffer object across devices.
The framework allows:
- creation of a buffer object, its association with a file pointer, and
associated allocator-defined operations on that buffer. This operation is
called the 'export' operation.
- different devices to 'attach' themselves to this exported buffer object, to
facilitate backing storage negotiation, using dma_buf_attach() API.
- the exported buffer object to be shared with the other entity by asking for
its 'file-descriptor (fd)', and sharing the fd across.
- a received fd to get the buffer object back, where it can be accessed using
the associated exporter-defined operations.
- the exporter and user to share the scatterlist associated with this buffer
object using map_dma_buf and unmap_dma_buf operations.
Atleast one 'attach()' call is required to be made prior to calling the
map_dma_buf() operation.
Couple of building blocks in map_dma_buf() are added to ease introduction
of sync'ing across exporter and users, and late allocation by the exporter.
For this first version, this framework will work with certain conditions:
- *ONLY* exporter will be allowed to mmap to userspace (outside of this
framework - mmap is not a buffer object operation),
- currently, *ONLY* users that do not need CPU access to the buffer are
allowed.
More details are there in the documentation patch.
This is based on design suggestions from many people at the mini-summits[1],
most notably from Arnd Bergmann <arnd@arndb.de>, Rob Clark <rob@ti.com> and
Daniel Vetter <daniel@ffwll.ch>.
The implementation is inspired from proof-of-concept patch-set from
Tomasz Stanislawski <t.stanislaws@samsung.com>, who demonstrated buffer sharing
between two v4l2 devices. [2]
[1]: https://wiki.linaro.org/OfficeofCTO/MemoryManagement
[2]: http://lwn.net/Articles/454389
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
Signed-off-by: Sumit Semwal <sumit.semwal@ti.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-and-Tested-by: Rob Clark <rob.clark@linaro.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-12-26 17:23:15 +08:00
|
|
|
|
dma-buf: change DMA-buf locking convention v3
This patch is a stripped down version of the locking changes
necessary to support dynamic DMA-buf handling.
It adds a dynamic flag for both importers as well as exporters
so that drivers can choose if they want the reservation object
locked or unlocked during mapping of attachments.
For compatibility between drivers we cache the DMA-buf mapping
during attaching an importer as soon as exporter/importer
disagree on the dynamic handling.
Issues and solutions we considered:
- We can't change all existing drivers, and existing improters have
strong opinions about which locks they're holding while calling
dma_buf_attachment_map/unmap. Exporters also have strong opinions about
which locks they can acquire in their ->map/unmap callbacks, levaing no
room for change. The solution to avoid this was to move the
actual map/unmap out from this call, into the attach/detach callbacks,
and cache the mapping. This works because drivers don't call
attach/detach from deep within their code callchains (like deep in
memory management code called from cs/execbuf ioctl), but directly from
the fd2handle implementation.
- The caching has some troubles on some soc drivers, which set other modes
than DMA_BIDIRECTIONAL. We can't have 2 incompatible mappings, and we
can't re-create the mapping at _map time due to the above locking fun.
We very carefuly step around that by only caching at attach time if the
dynamic mode between importer/expoert mismatches.
- There's been quite some discussion on dma-buf mappings which need active
cache management, which would all break down when caching, plus we don't
have explicit flush operations on the attachment side. The solution to
this was to shrug and keep the current discrepancy between what the
dma-buf docs claim and what implementations do, with the hope that the
begin/end_cpu_access hooks are good enough and that all necessary
flushing to keep device mappings consistent will be done there.
v2: cleanup set_name merge, improve kerneldoc
v3: update commit message, kerneldoc and cleanup _debug_show()
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/336788/
2018-07-03 22:42:26 +08:00
|
|
|
/* When either the importer or the exporter can't handle dynamic
|
|
|
|
* mappings we cache the mapping here to avoid issues with the
|
|
|
|
* reservation object lock.
|
|
|
|
*/
|
|
|
|
if (dma_buf_attachment_is_dynamic(attach) !=
|
|
|
|
dma_buf_is_dynamic(dmabuf)) {
|
|
|
|
struct sg_table *sgt;
|
|
|
|
|
2022-10-18 01:22:24 +08:00
|
|
|
dma_resv_lock(attach->dmabuf->resv, NULL);
|
2018-07-03 22:42:26 +08:00
|
|
|
if (dma_buf_is_dynamic(attach->dmabuf)) {
|
2021-05-17 19:20:17 +08:00
|
|
|
ret = dmabuf->ops->pin(attach);
|
2018-07-03 22:42:26 +08:00
|
|
|
if (ret)
|
|
|
|
goto err_unlock;
|
|
|
|
}
|
dma-buf: change DMA-buf locking convention v3
This patch is a stripped down version of the locking changes
necessary to support dynamic DMA-buf handling.
It adds a dynamic flag for both importers as well as exporters
so that drivers can choose if they want the reservation object
locked or unlocked during mapping of attachments.
For compatibility between drivers we cache the DMA-buf mapping
during attaching an importer as soon as exporter/importer
disagree on the dynamic handling.
Issues and solutions we considered:
- We can't change all existing drivers, and existing improters have
strong opinions about which locks they're holding while calling
dma_buf_attachment_map/unmap. Exporters also have strong opinions about
which locks they can acquire in their ->map/unmap callbacks, levaing no
room for change. The solution to avoid this was to move the
actual map/unmap out from this call, into the attach/detach callbacks,
and cache the mapping. This works because drivers don't call
attach/detach from deep within their code callchains (like deep in
memory management code called from cs/execbuf ioctl), but directly from
the fd2handle implementation.
- The caching has some troubles on some soc drivers, which set other modes
than DMA_BIDIRECTIONAL. We can't have 2 incompatible mappings, and we
can't re-create the mapping at _map time due to the above locking fun.
We very carefuly step around that by only caching at attach time if the
dynamic mode between importer/expoert mismatches.
- There's been quite some discussion on dma-buf mappings which need active
cache management, which would all break down when caching, plus we don't
have explicit flush operations on the attachment side. The solution to
this was to shrug and keep the current discrepancy between what the
dma-buf docs claim and what implementations do, with the hope that the
begin/end_cpu_access hooks are good enough and that all necessary
flushing to keep device mappings consistent will be done there.
v2: cleanup set_name merge, improve kerneldoc
v3: update commit message, kerneldoc and cleanup _debug_show()
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/336788/
2018-07-03 22:42:26 +08:00
|
|
|
|
2021-01-16 00:47:39 +08:00
|
|
|
sgt = __map_dma_buf(attach, DMA_BIDIRECTIONAL);
|
dma-buf: change DMA-buf locking convention v3
This patch is a stripped down version of the locking changes
necessary to support dynamic DMA-buf handling.
It adds a dynamic flag for both importers as well as exporters
so that drivers can choose if they want the reservation object
locked or unlocked during mapping of attachments.
For compatibility between drivers we cache the DMA-buf mapping
during attaching an importer as soon as exporter/importer
disagree on the dynamic handling.
Issues and solutions we considered:
- We can't change all existing drivers, and existing improters have
strong opinions about which locks they're holding while calling
dma_buf_attachment_map/unmap. Exporters also have strong opinions about
which locks they can acquire in their ->map/unmap callbacks, levaing no
room for change. The solution to avoid this was to move the
actual map/unmap out from this call, into the attach/detach callbacks,
and cache the mapping. This works because drivers don't call
attach/detach from deep within their code callchains (like deep in
memory management code called from cs/execbuf ioctl), but directly from
the fd2handle implementation.
- The caching has some troubles on some soc drivers, which set other modes
than DMA_BIDIRECTIONAL. We can't have 2 incompatible mappings, and we
can't re-create the mapping at _map time due to the above locking fun.
We very carefuly step around that by only caching at attach time if the
dynamic mode between importer/expoert mismatches.
- There's been quite some discussion on dma-buf mappings which need active
cache management, which would all break down when caching, plus we don't
have explicit flush operations on the attachment side. The solution to
this was to shrug and keep the current discrepancy between what the
dma-buf docs claim and what implementations do, with the hope that the
begin/end_cpu_access hooks are good enough and that all necessary
flushing to keep device mappings consistent will be done there.
v2: cleanup set_name merge, improve kerneldoc
v3: update commit message, kerneldoc and cleanup _debug_show()
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/336788/
2018-07-03 22:42:26 +08:00
|
|
|
if (!sgt)
|
|
|
|
sgt = ERR_PTR(-ENOMEM);
|
|
|
|
if (IS_ERR(sgt)) {
|
|
|
|
ret = PTR_ERR(sgt);
|
2018-07-03 22:42:26 +08:00
|
|
|
goto err_unpin;
|
dma-buf: change DMA-buf locking convention v3
This patch is a stripped down version of the locking changes
necessary to support dynamic DMA-buf handling.
It adds a dynamic flag for both importers as well as exporters
so that drivers can choose if they want the reservation object
locked or unlocked during mapping of attachments.
For compatibility between drivers we cache the DMA-buf mapping
during attaching an importer as soon as exporter/importer
disagree on the dynamic handling.
Issues and solutions we considered:
- We can't change all existing drivers, and existing improters have
strong opinions about which locks they're holding while calling
dma_buf_attachment_map/unmap. Exporters also have strong opinions about
which locks they can acquire in their ->map/unmap callbacks, levaing no
room for change. The solution to avoid this was to move the
actual map/unmap out from this call, into the attach/detach callbacks,
and cache the mapping. This works because drivers don't call
attach/detach from deep within their code callchains (like deep in
memory management code called from cs/execbuf ioctl), but directly from
the fd2handle implementation.
- The caching has some troubles on some soc drivers, which set other modes
than DMA_BIDIRECTIONAL. We can't have 2 incompatible mappings, and we
can't re-create the mapping at _map time due to the above locking fun.
We very carefuly step around that by only caching at attach time if the
dynamic mode between importer/expoert mismatches.
- There's been quite some discussion on dma-buf mappings which need active
cache management, which would all break down when caching, plus we don't
have explicit flush operations on the attachment side. The solution to
this was to shrug and keep the current discrepancy between what the
dma-buf docs claim and what implementations do, with the hope that the
begin/end_cpu_access hooks are good enough and that all necessary
flushing to keep device mappings consistent will be done there.
v2: cleanup set_name merge, improve kerneldoc
v3: update commit message, kerneldoc and cleanup _debug_show()
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/336788/
2018-07-03 22:42:26 +08:00
|
|
|
}
|
2022-10-18 01:22:24 +08:00
|
|
|
dma_resv_unlock(attach->dmabuf->resv);
|
dma-buf: change DMA-buf locking convention v3
This patch is a stripped down version of the locking changes
necessary to support dynamic DMA-buf handling.
It adds a dynamic flag for both importers as well as exporters
so that drivers can choose if they want the reservation object
locked or unlocked during mapping of attachments.
For compatibility between drivers we cache the DMA-buf mapping
during attaching an importer as soon as exporter/importer
disagree on the dynamic handling.
Issues and solutions we considered:
- We can't change all existing drivers, and existing improters have
strong opinions about which locks they're holding while calling
dma_buf_attachment_map/unmap. Exporters also have strong opinions about
which locks they can acquire in their ->map/unmap callbacks, levaing no
room for change. The solution to avoid this was to move the
actual map/unmap out from this call, into the attach/detach callbacks,
and cache the mapping. This works because drivers don't call
attach/detach from deep within their code callchains (like deep in
memory management code called from cs/execbuf ioctl), but directly from
the fd2handle implementation.
- The caching has some troubles on some soc drivers, which set other modes
than DMA_BIDIRECTIONAL. We can't have 2 incompatible mappings, and we
can't re-create the mapping at _map time due to the above locking fun.
We very carefuly step around that by only caching at attach time if the
dynamic mode between importer/expoert mismatches.
- There's been quite some discussion on dma-buf mappings which need active
cache management, which would all break down when caching, plus we don't
have explicit flush operations on the attachment side. The solution to
this was to shrug and keep the current discrepancy between what the
dma-buf docs claim and what implementations do, with the hope that the
begin/end_cpu_access hooks are good enough and that all necessary
flushing to keep device mappings consistent will be done there.
v2: cleanup set_name merge, improve kerneldoc
v3: update commit message, kerneldoc and cleanup _debug_show()
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/336788/
2018-07-03 22:42:26 +08:00
|
|
|
attach->sgt = sgt;
|
|
|
|
attach->dir = DMA_BIDIRECTIONAL;
|
|
|
|
}
|
|
|
|
|
dma-buf: Introduce dma buffer sharing mechanism
This is the first step in defining a dma buffer sharing mechanism.
A new buffer object dma_buf is added, with operations and API to allow easy
sharing of this buffer object across devices.
The framework allows:
- creation of a buffer object, its association with a file pointer, and
associated allocator-defined operations on that buffer. This operation is
called the 'export' operation.
- different devices to 'attach' themselves to this exported buffer object, to
facilitate backing storage negotiation, using dma_buf_attach() API.
- the exported buffer object to be shared with the other entity by asking for
its 'file-descriptor (fd)', and sharing the fd across.
- a received fd to get the buffer object back, where it can be accessed using
the associated exporter-defined operations.
- the exporter and user to share the scatterlist associated with this buffer
object using map_dma_buf and unmap_dma_buf operations.
Atleast one 'attach()' call is required to be made prior to calling the
map_dma_buf() operation.
Couple of building blocks in map_dma_buf() are added to ease introduction
of sync'ing across exporter and users, and late allocation by the exporter.
For this first version, this framework will work with certain conditions:
- *ONLY* exporter will be allowed to mmap to userspace (outside of this
framework - mmap is not a buffer object operation),
- currently, *ONLY* users that do not need CPU access to the buffer are
allowed.
More details are there in the documentation patch.
This is based on design suggestions from many people at the mini-summits[1],
most notably from Arnd Bergmann <arnd@arndb.de>, Rob Clark <rob@ti.com> and
Daniel Vetter <daniel@ffwll.ch>.
The implementation is inspired from proof-of-concept patch-set from
Tomasz Stanislawski <t.stanislaws@samsung.com>, who demonstrated buffer sharing
between two v4l2 devices. [2]
[1]: https://wiki.linaro.org/OfficeofCTO/MemoryManagement
[2]: http://lwn.net/Articles/454389
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
Signed-off-by: Sumit Semwal <sumit.semwal@ti.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-and-Tested-by: Rob Clark <rob.clark@linaro.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-12-26 17:23:15 +08:00
|
|
|
return attach;
|
|
|
|
|
|
|
|
err_attach:
|
|
|
|
kfree(attach);
|
|
|
|
return ERR_PTR(ret);
|
dma-buf: change DMA-buf locking convention v3
This patch is a stripped down version of the locking changes
necessary to support dynamic DMA-buf handling.
It adds a dynamic flag for both importers as well as exporters
so that drivers can choose if they want the reservation object
locked or unlocked during mapping of attachments.
For compatibility between drivers we cache the DMA-buf mapping
during attaching an importer as soon as exporter/importer
disagree on the dynamic handling.
Issues and solutions we considered:
- We can't change all existing drivers, and existing improters have
strong opinions about which locks they're holding while calling
dma_buf_attachment_map/unmap. Exporters also have strong opinions about
which locks they can acquire in their ->map/unmap callbacks, levaing no
room for change. The solution to avoid this was to move the
actual map/unmap out from this call, into the attach/detach callbacks,
and cache the mapping. This works because drivers don't call
attach/detach from deep within their code callchains (like deep in
memory management code called from cs/execbuf ioctl), but directly from
the fd2handle implementation.
- The caching has some troubles on some soc drivers, which set other modes
than DMA_BIDIRECTIONAL. We can't have 2 incompatible mappings, and we
can't re-create the mapping at _map time due to the above locking fun.
We very carefuly step around that by only caching at attach time if the
dynamic mode between importer/expoert mismatches.
- There's been quite some discussion on dma-buf mappings which need active
cache management, which would all break down when caching, plus we don't
have explicit flush operations on the attachment side. The solution to
this was to shrug and keep the current discrepancy between what the
dma-buf docs claim and what implementations do, with the hope that the
begin/end_cpu_access hooks are good enough and that all necessary
flushing to keep device mappings consistent will be done there.
v2: cleanup set_name merge, improve kerneldoc
v3: update commit message, kerneldoc and cleanup _debug_show()
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/336788/
2018-07-03 22:42:26 +08:00
|
|
|
|
2018-07-03 22:42:26 +08:00
|
|
|
err_unpin:
|
|
|
|
if (dma_buf_is_dynamic(attach->dmabuf))
|
2021-05-17 19:20:17 +08:00
|
|
|
dmabuf->ops->unpin(attach);
|
2018-07-03 22:42:26 +08:00
|
|
|
|
dma-buf: change DMA-buf locking convention v3
This patch is a stripped down version of the locking changes
necessary to support dynamic DMA-buf handling.
It adds a dynamic flag for both importers as well as exporters
so that drivers can choose if they want the reservation object
locked or unlocked during mapping of attachments.
For compatibility between drivers we cache the DMA-buf mapping
during attaching an importer as soon as exporter/importer
disagree on the dynamic handling.
Issues and solutions we considered:
- We can't change all existing drivers, and existing improters have
strong opinions about which locks they're holding while calling
dma_buf_attachment_map/unmap. Exporters also have strong opinions about
which locks they can acquire in their ->map/unmap callbacks, levaing no
room for change. The solution to avoid this was to move the
actual map/unmap out from this call, into the attach/detach callbacks,
and cache the mapping. This works because drivers don't call
attach/detach from deep within their code callchains (like deep in
memory management code called from cs/execbuf ioctl), but directly from
the fd2handle implementation.
- The caching has some troubles on some soc drivers, which set other modes
than DMA_BIDIRECTIONAL. We can't have 2 incompatible mappings, and we
can't re-create the mapping at _map time due to the above locking fun.
We very carefuly step around that by only caching at attach time if the
dynamic mode between importer/expoert mismatches.
- There's been quite some discussion on dma-buf mappings which need active
cache management, which would all break down when caching, plus we don't
have explicit flush operations on the attachment side. The solution to
this was to shrug and keep the current discrepancy between what the
dma-buf docs claim and what implementations do, with the hope that the
begin/end_cpu_access hooks are good enough and that all necessary
flushing to keep device mappings consistent will be done there.
v2: cleanup set_name merge, improve kerneldoc
v3: update commit message, kerneldoc and cleanup _debug_show()
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/336788/
2018-07-03 22:42:26 +08:00
|
|
|
err_unlock:
|
2022-10-18 01:22:24 +08:00
|
|
|
dma_resv_unlock(attach->dmabuf->resv);
|
dma-buf: change DMA-buf locking convention v3
This patch is a stripped down version of the locking changes
necessary to support dynamic DMA-buf handling.
It adds a dynamic flag for both importers as well as exporters
so that drivers can choose if they want the reservation object
locked or unlocked during mapping of attachments.
For compatibility between drivers we cache the DMA-buf mapping
during attaching an importer as soon as exporter/importer
disagree on the dynamic handling.
Issues and solutions we considered:
- We can't change all existing drivers, and existing improters have
strong opinions about which locks they're holding while calling
dma_buf_attachment_map/unmap. Exporters also have strong opinions about
which locks they can acquire in their ->map/unmap callbacks, levaing no
room for change. The solution to avoid this was to move the
actual map/unmap out from this call, into the attach/detach callbacks,
and cache the mapping. This works because drivers don't call
attach/detach from deep within their code callchains (like deep in
memory management code called from cs/execbuf ioctl), but directly from
the fd2handle implementation.
- The caching has some troubles on some soc drivers, which set other modes
than DMA_BIDIRECTIONAL. We can't have 2 incompatible mappings, and we
can't re-create the mapping at _map time due to the above locking fun.
We very carefuly step around that by only caching at attach time if the
dynamic mode between importer/expoert mismatches.
- There's been quite some discussion on dma-buf mappings which need active
cache management, which would all break down when caching, plus we don't
have explicit flush operations on the attachment side. The solution to
this was to shrug and keep the current discrepancy between what the
dma-buf docs claim and what implementations do, with the hope that the
begin/end_cpu_access hooks are good enough and that all necessary
flushing to keep device mappings consistent will be done there.
v2: cleanup set_name merge, improve kerneldoc
v3: update commit message, kerneldoc and cleanup _debug_show()
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/336788/
2018-07-03 22:42:26 +08:00
|
|
|
|
|
|
|
dma_buf_detach(dmabuf, attach);
|
|
|
|
return ERR_PTR(ret);
|
|
|
|
}
|
2021-10-10 20:46:28 +08:00
|
|
|
EXPORT_SYMBOL_NS_GPL(dma_buf_dynamic_attach, DMA_BUF);
|
dma-buf: change DMA-buf locking convention v3
This patch is a stripped down version of the locking changes
necessary to support dynamic DMA-buf handling.
It adds a dynamic flag for both importers as well as exporters
so that drivers can choose if they want the reservation object
locked or unlocked during mapping of attachments.
For compatibility between drivers we cache the DMA-buf mapping
during attaching an importer as soon as exporter/importer
disagree on the dynamic handling.
Issues and solutions we considered:
- We can't change all existing drivers, and existing improters have
strong opinions about which locks they're holding while calling
dma_buf_attachment_map/unmap. Exporters also have strong opinions about
which locks they can acquire in their ->map/unmap callbacks, levaing no
room for change. The solution to avoid this was to move the
actual map/unmap out from this call, into the attach/detach callbacks,
and cache the mapping. This works because drivers don't call
attach/detach from deep within their code callchains (like deep in
memory management code called from cs/execbuf ioctl), but directly from
the fd2handle implementation.
- The caching has some troubles on some soc drivers, which set other modes
than DMA_BIDIRECTIONAL. We can't have 2 incompatible mappings, and we
can't re-create the mapping at _map time due to the above locking fun.
We very carefuly step around that by only caching at attach time if the
dynamic mode between importer/expoert mismatches.
- There's been quite some discussion on dma-buf mappings which need active
cache management, which would all break down when caching, plus we don't
have explicit flush operations on the attachment side. The solution to
this was to shrug and keep the current discrepancy between what the
dma-buf docs claim and what implementations do, with the hope that the
begin/end_cpu_access hooks are good enough and that all necessary
flushing to keep device mappings consistent will be done there.
v2: cleanup set_name merge, improve kerneldoc
v3: update commit message, kerneldoc and cleanup _debug_show()
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/336788/
2018-07-03 22:42:26 +08:00
|
|
|
|
|
|
|
/**
|
|
|
|
* dma_buf_attach - Wrapper for dma_buf_dynamic_attach
|
|
|
|
* @dmabuf: [in] buffer to attach device to.
|
|
|
|
* @dev: [in] device to be attached.
|
|
|
|
*
|
|
|
|
* Wrapper to call dma_buf_dynamic_attach() for drivers which still use a static
|
|
|
|
* mapping.
|
|
|
|
*/
|
|
|
|
struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
|
|
|
|
struct device *dev)
|
|
|
|
{
|
2018-07-03 22:42:26 +08:00
|
|
|
return dma_buf_dynamic_attach(dmabuf, dev, NULL, NULL);
|
dma-buf: Introduce dma buffer sharing mechanism
This is the first step in defining a dma buffer sharing mechanism.
A new buffer object dma_buf is added, with operations and API to allow easy
sharing of this buffer object across devices.
The framework allows:
- creation of a buffer object, its association with a file pointer, and
associated allocator-defined operations on that buffer. This operation is
called the 'export' operation.
- different devices to 'attach' themselves to this exported buffer object, to
facilitate backing storage negotiation, using dma_buf_attach() API.
- the exported buffer object to be shared with the other entity by asking for
its 'file-descriptor (fd)', and sharing the fd across.
- a received fd to get the buffer object back, where it can be accessed using
the associated exporter-defined operations.
- the exporter and user to share the scatterlist associated with this buffer
object using map_dma_buf and unmap_dma_buf operations.
Atleast one 'attach()' call is required to be made prior to calling the
map_dma_buf() operation.
Couple of building blocks in map_dma_buf() are added to ease introduction
of sync'ing across exporter and users, and late allocation by the exporter.
For this first version, this framework will work with certain conditions:
- *ONLY* exporter will be allowed to mmap to userspace (outside of this
framework - mmap is not a buffer object operation),
- currently, *ONLY* users that do not need CPU access to the buffer are
allowed.
More details are there in the documentation patch.
This is based on design suggestions from many people at the mini-summits[1],
most notably from Arnd Bergmann <arnd@arndb.de>, Rob Clark <rob@ti.com> and
Daniel Vetter <daniel@ffwll.ch>.
The implementation is inspired from proof-of-concept patch-set from
Tomasz Stanislawski <t.stanislaws@samsung.com>, who demonstrated buffer sharing
between two v4l2 devices. [2]
[1]: https://wiki.linaro.org/OfficeofCTO/MemoryManagement
[2]: http://lwn.net/Articles/454389
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
Signed-off-by: Sumit Semwal <sumit.semwal@ti.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-and-Tested-by: Rob Clark <rob.clark@linaro.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-12-26 17:23:15 +08:00
|
|
|
}
|
2021-10-10 20:46:28 +08:00
|
|
|
EXPORT_SYMBOL_NS_GPL(dma_buf_attach, DMA_BUF);
|
dma-buf: Introduce dma buffer sharing mechanism
This is the first step in defining a dma buffer sharing mechanism.
A new buffer object dma_buf is added, with operations and API to allow easy
sharing of this buffer object across devices.
The framework allows:
- creation of a buffer object, its association with a file pointer, and
associated allocator-defined operations on that buffer. This operation is
called the 'export' operation.
- different devices to 'attach' themselves to this exported buffer object, to
facilitate backing storage negotiation, using dma_buf_attach() API.
- the exported buffer object to be shared with the other entity by asking for
its 'file-descriptor (fd)', and sharing the fd across.
- a received fd to get the buffer object back, where it can be accessed using
the associated exporter-defined operations.
- the exporter and user to share the scatterlist associated with this buffer
object using map_dma_buf and unmap_dma_buf operations.
Atleast one 'attach()' call is required to be made prior to calling the
map_dma_buf() operation.
Couple of building blocks in map_dma_buf() are added to ease introduction
of sync'ing across exporter and users, and late allocation by the exporter.
For this first version, this framework will work with certain conditions:
- *ONLY* exporter will be allowed to mmap to userspace (outside of this
framework - mmap is not a buffer object operation),
- currently, *ONLY* users that do not need CPU access to the buffer are
allowed.
More details are there in the documentation patch.
This is based on design suggestions from many people at the mini-summits[1],
most notably from Arnd Bergmann <arnd@arndb.de>, Rob Clark <rob@ti.com> and
Daniel Vetter <daniel@ffwll.ch>.
The implementation is inspired from proof-of-concept patch-set from
Tomasz Stanislawski <t.stanislaws@samsung.com>, who demonstrated buffer sharing
between two v4l2 devices. [2]
[1]: https://wiki.linaro.org/OfficeofCTO/MemoryManagement
[2]: http://lwn.net/Articles/454389
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
Signed-off-by: Sumit Semwal <sumit.semwal@ti.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-and-Tested-by: Rob Clark <rob.clark@linaro.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-12-26 17:23:15 +08:00
|
|
|
|
2021-01-16 00:47:39 +08:00
|
|
|
static void __unmap_dma_buf(struct dma_buf_attachment *attach,
|
|
|
|
struct sg_table *sg_table,
|
|
|
|
enum dma_data_direction direction)
|
|
|
|
{
|
|
|
|
/* uses XOR, hence this unmangles */
|
|
|
|
mangle_sg_table(sg_table);
|
|
|
|
|
|
|
|
attach->dmabuf->ops->unmap_dma_buf(attach, sg_table, direction);
|
|
|
|
}
|
|
|
|
|
dma-buf: Introduce dma buffer sharing mechanism
This is the first step in defining a dma buffer sharing mechanism.
A new buffer object dma_buf is added, with operations and API to allow easy
sharing of this buffer object across devices.
The framework allows:
- creation of a buffer object, its association with a file pointer, and
associated allocator-defined operations on that buffer. This operation is
called the 'export' operation.
- different devices to 'attach' themselves to this exported buffer object, to
facilitate backing storage negotiation, using dma_buf_attach() API.
- the exported buffer object to be shared with the other entity by asking for
its 'file-descriptor (fd)', and sharing the fd across.
- a received fd to get the buffer object back, where it can be accessed using
the associated exporter-defined operations.
- the exporter and user to share the scatterlist associated with this buffer
object using map_dma_buf and unmap_dma_buf operations.
Atleast one 'attach()' call is required to be made prior to calling the
map_dma_buf() operation.
Couple of building blocks in map_dma_buf() are added to ease introduction
of sync'ing across exporter and users, and late allocation by the exporter.
For this first version, this framework will work with certain conditions:
- *ONLY* exporter will be allowed to mmap to userspace (outside of this
framework - mmap is not a buffer object operation),
- currently, *ONLY* users that do not need CPU access to the buffer are
allowed.
More details are there in the documentation patch.
This is based on design suggestions from many people at the mini-summits[1],
most notably from Arnd Bergmann <arnd@arndb.de>, Rob Clark <rob@ti.com> and
Daniel Vetter <daniel@ffwll.ch>.
The implementation is inspired from proof-of-concept patch-set from
Tomasz Stanislawski <t.stanislaws@samsung.com>, who demonstrated buffer sharing
between two v4l2 devices. [2]
[1]: https://wiki.linaro.org/OfficeofCTO/MemoryManagement
[2]: http://lwn.net/Articles/454389
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
Signed-off-by: Sumit Semwal <sumit.semwal@ti.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-and-Tested-by: Rob Clark <rob.clark@linaro.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-12-26 17:23:15 +08:00
|
|
|
/**
|
2020-12-11 23:58:41 +08:00
|
|
|
* dma_buf_detach - Remove the given attachment from dmabuf's attachments list
|
dma-buf: Introduce dma buffer sharing mechanism
This is the first step in defining a dma buffer sharing mechanism.
A new buffer object dma_buf is added, with operations and API to allow easy
sharing of this buffer object across devices.
The framework allows:
- creation of a buffer object, its association with a file pointer, and
associated allocator-defined operations on that buffer. This operation is
called the 'export' operation.
- different devices to 'attach' themselves to this exported buffer object, to
facilitate backing storage negotiation, using dma_buf_attach() API.
- the exported buffer object to be shared with the other entity by asking for
its 'file-descriptor (fd)', and sharing the fd across.
- a received fd to get the buffer object back, where it can be accessed using
the associated exporter-defined operations.
- the exporter and user to share the scatterlist associated with this buffer
object using map_dma_buf and unmap_dma_buf operations.
Atleast one 'attach()' call is required to be made prior to calling the
map_dma_buf() operation.
Couple of building blocks in map_dma_buf() are added to ease introduction
of sync'ing across exporter and users, and late allocation by the exporter.
For this first version, this framework will work with certain conditions:
- *ONLY* exporter will be allowed to mmap to userspace (outside of this
framework - mmap is not a buffer object operation),
- currently, *ONLY* users that do not need CPU access to the buffer are
allowed.
More details are there in the documentation patch.
This is based on design suggestions from many people at the mini-summits[1],
most notably from Arnd Bergmann <arnd@arndb.de>, Rob Clark <rob@ti.com> and
Daniel Vetter <daniel@ffwll.ch>.
The implementation is inspired from proof-of-concept patch-set from
Tomasz Stanislawski <t.stanislaws@samsung.com>, who demonstrated buffer sharing
between two v4l2 devices. [2]
[1]: https://wiki.linaro.org/OfficeofCTO/MemoryManagement
[2]: http://lwn.net/Articles/454389
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
Signed-off-by: Sumit Semwal <sumit.semwal@ti.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-and-Tested-by: Rob Clark <rob.clark@linaro.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-12-26 17:23:15 +08:00
|
|
|
* @dmabuf: [in] buffer to detach from.
|
|
|
|
* @attach: [in] attachment to be detached; is free'd after this call.
|
|
|
|
*
|
2016-12-10 02:53:07 +08:00
|
|
|
* Clean up a device attachment obtained by calling dma_buf_attach().
|
2020-12-11 23:58:41 +08:00
|
|
|
*
|
|
|
|
* Optionally this calls &dma_buf_ops.detach for device-specific detach.
|
dma-buf: Introduce dma buffer sharing mechanism
This is the first step in defining a dma buffer sharing mechanism.
A new buffer object dma_buf is added, with operations and API to allow easy
sharing of this buffer object across devices.
The framework allows:
- creation of a buffer object, its association with a file pointer, and
associated allocator-defined operations on that buffer. This operation is
called the 'export' operation.
- different devices to 'attach' themselves to this exported buffer object, to
facilitate backing storage negotiation, using dma_buf_attach() API.
- the exported buffer object to be shared with the other entity by asking for
its 'file-descriptor (fd)', and sharing the fd across.
- a received fd to get the buffer object back, where it can be accessed using
the associated exporter-defined operations.
- the exporter and user to share the scatterlist associated with this buffer
object using map_dma_buf and unmap_dma_buf operations.
Atleast one 'attach()' call is required to be made prior to calling the
map_dma_buf() operation.
Couple of building blocks in map_dma_buf() are added to ease introduction
of sync'ing across exporter and users, and late allocation by the exporter.
For this first version, this framework will work with certain conditions:
- *ONLY* exporter will be allowed to mmap to userspace (outside of this
framework - mmap is not a buffer object operation),
- currently, *ONLY* users that do not need CPU access to the buffer are
allowed.
More details are there in the documentation patch.
This is based on design suggestions from many people at the mini-summits[1],
most notably from Arnd Bergmann <arnd@arndb.de>, Rob Clark <rob@ti.com> and
Daniel Vetter <daniel@ffwll.ch>.
The implementation is inspired from proof-of-concept patch-set from
Tomasz Stanislawski <t.stanislaws@samsung.com>, who demonstrated buffer sharing
between two v4l2 devices. [2]
[1]: https://wiki.linaro.org/OfficeofCTO/MemoryManagement
[2]: http://lwn.net/Articles/454389
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
Signed-off-by: Sumit Semwal <sumit.semwal@ti.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-and-Tested-by: Rob Clark <rob.clark@linaro.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-12-26 17:23:15 +08:00
|
|
|
*/
|
|
|
|
void dma_buf_detach(struct dma_buf *dmabuf, struct dma_buf_attachment *attach)
|
|
|
|
{
|
2022-10-30 23:44:11 +08:00
|
|
|
if (WARN_ON(!dmabuf || !attach || dmabuf != attach->dmabuf))
|
dma-buf: Introduce dma buffer sharing mechanism
This is the first step in defining a dma buffer sharing mechanism.
A new buffer object dma_buf is added, with operations and API to allow easy
sharing of this buffer object across devices.
The framework allows:
- creation of a buffer object, its association with a file pointer, and
associated allocator-defined operations on that buffer. This operation is
called the 'export' operation.
- different devices to 'attach' themselves to this exported buffer object, to
facilitate backing storage negotiation, using dma_buf_attach() API.
- the exported buffer object to be shared with the other entity by asking for
its 'file-descriptor (fd)', and sharing the fd across.
- a received fd to get the buffer object back, where it can be accessed using
the associated exporter-defined operations.
- the exporter and user to share the scatterlist associated with this buffer
object using map_dma_buf and unmap_dma_buf operations.
Atleast one 'attach()' call is required to be made prior to calling the
map_dma_buf() operation.
Couple of building blocks in map_dma_buf() are added to ease introduction
of sync'ing across exporter and users, and late allocation by the exporter.
For this first version, this framework will work with certain conditions:
- *ONLY* exporter will be allowed to mmap to userspace (outside of this
framework - mmap is not a buffer object operation),
- currently, *ONLY* users that do not need CPU access to the buffer are
allowed.
More details are there in the documentation patch.
This is based on design suggestions from many people at the mini-summits[1],
most notably from Arnd Bergmann <arnd@arndb.de>, Rob Clark <rob@ti.com> and
Daniel Vetter <daniel@ffwll.ch>.
The implementation is inspired from proof-of-concept patch-set from
Tomasz Stanislawski <t.stanislaws@samsung.com>, who demonstrated buffer sharing
between two v4l2 devices. [2]
[1]: https://wiki.linaro.org/OfficeofCTO/MemoryManagement
[2]: http://lwn.net/Articles/454389
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
Signed-off-by: Sumit Semwal <sumit.semwal@ti.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-and-Tested-by: Rob Clark <rob.clark@linaro.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-12-26 17:23:15 +08:00
|
|
|
return;
|
|
|
|
|
2022-10-30 23:44:11 +08:00
|
|
|
dma_resv_lock(dmabuf->resv, NULL);
|
2022-10-18 01:22:24 +08:00
|
|
|
|
dma-buf: change DMA-buf locking convention v3
This patch is a stripped down version of the locking changes
necessary to support dynamic DMA-buf handling.
It adds a dynamic flag for both importers as well as exporters
so that drivers can choose if they want the reservation object
locked or unlocked during mapping of attachments.
For compatibility between drivers we cache the DMA-buf mapping
during attaching an importer as soon as exporter/importer
disagree on the dynamic handling.
Issues and solutions we considered:
- We can't change all existing drivers, and existing improters have
strong opinions about which locks they're holding while calling
dma_buf_attachment_map/unmap. Exporters also have strong opinions about
which locks they can acquire in their ->map/unmap callbacks, levaing no
room for change. The solution to avoid this was to move the
actual map/unmap out from this call, into the attach/detach callbacks,
and cache the mapping. This works because drivers don't call
attach/detach from deep within their code callchains (like deep in
memory management code called from cs/execbuf ioctl), but directly from
the fd2handle implementation.
- The caching has some troubles on some soc drivers, which set other modes
than DMA_BIDIRECTIONAL. We can't have 2 incompatible mappings, and we
can't re-create the mapping at _map time due to the above locking fun.
We very carefuly step around that by only caching at attach time if the
dynamic mode between importer/expoert mismatches.
- There's been quite some discussion on dma-buf mappings which need active
cache management, which would all break down when caching, plus we don't
have explicit flush operations on the attachment side. The solution to
this was to shrug and keep the current discrepancy between what the
dma-buf docs claim and what implementations do, with the hope that the
begin/end_cpu_access hooks are good enough and that all necessary
flushing to keep device mappings consistent will be done there.
v2: cleanup set_name merge, improve kerneldoc
v3: update commit message, kerneldoc and cleanup _debug_show()
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/336788/
2018-07-03 22:42:26 +08:00
|
|
|
if (attach->sgt) {
|
|
|
|
|
2021-01-16 00:47:39 +08:00
|
|
|
__unmap_dma_buf(attach, attach->sgt, attach->dir);
|
2018-07-03 22:42:26 +08:00
|
|
|
|
2022-10-18 01:22:24 +08:00
|
|
|
if (dma_buf_is_dynamic(attach->dmabuf))
|
2021-05-17 19:20:17 +08:00
|
|
|
dmabuf->ops->unpin(attach);
|
dma-buf: change DMA-buf locking convention v3
This patch is a stripped down version of the locking changes
necessary to support dynamic DMA-buf handling.
It adds a dynamic flag for both importers as well as exporters
so that drivers can choose if they want the reservation object
locked or unlocked during mapping of attachments.
For compatibility between drivers we cache the DMA-buf mapping
during attaching an importer as soon as exporter/importer
disagree on the dynamic handling.
Issues and solutions we considered:
- We can't change all existing drivers, and existing improters have
strong opinions about which locks they're holding while calling
dma_buf_attachment_map/unmap. Exporters also have strong opinions about
which locks they can acquire in their ->map/unmap callbacks, levaing no
room for change. The solution to avoid this was to move the
actual map/unmap out from this call, into the attach/detach callbacks,
and cache the mapping. This works because drivers don't call
attach/detach from deep within their code callchains (like deep in
memory management code called from cs/execbuf ioctl), but directly from
the fd2handle implementation.
- The caching has some troubles on some soc drivers, which set other modes
than DMA_BIDIRECTIONAL. We can't have 2 incompatible mappings, and we
can't re-create the mapping at _map time due to the above locking fun.
We very carefuly step around that by only caching at attach time if the
dynamic mode between importer/expoert mismatches.
- There's been quite some discussion on dma-buf mappings which need active
cache management, which would all break down when caching, plus we don't
have explicit flush operations on the attachment side. The solution to
this was to shrug and keep the current discrepancy between what the
dma-buf docs claim and what implementations do, with the hope that the
begin/end_cpu_access hooks are good enough and that all necessary
flushing to keep device mappings consistent will be done there.
v2: cleanup set_name merge, improve kerneldoc
v3: update commit message, kerneldoc and cleanup _debug_show()
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/336788/
2018-07-03 22:42:26 +08:00
|
|
|
}
|
dma-buf: Introduce dma buffer sharing mechanism
This is the first step in defining a dma buffer sharing mechanism.
A new buffer object dma_buf is added, with operations and API to allow easy
sharing of this buffer object across devices.
The framework allows:
- creation of a buffer object, its association with a file pointer, and
associated allocator-defined operations on that buffer. This operation is
called the 'export' operation.
- different devices to 'attach' themselves to this exported buffer object, to
facilitate backing storage negotiation, using dma_buf_attach() API.
- the exported buffer object to be shared with the other entity by asking for
its 'file-descriptor (fd)', and sharing the fd across.
- a received fd to get the buffer object back, where it can be accessed using
the associated exporter-defined operations.
- the exporter and user to share the scatterlist associated with this buffer
object using map_dma_buf and unmap_dma_buf operations.
Atleast one 'attach()' call is required to be made prior to calling the
map_dma_buf() operation.
Couple of building blocks in map_dma_buf() are added to ease introduction
of sync'ing across exporter and users, and late allocation by the exporter.
For this first version, this framework will work with certain conditions:
- *ONLY* exporter will be allowed to mmap to userspace (outside of this
framework - mmap is not a buffer object operation),
- currently, *ONLY* users that do not need CPU access to the buffer are
allowed.
More details are there in the documentation patch.
This is based on design suggestions from many people at the mini-summits[1],
most notably from Arnd Bergmann <arnd@arndb.de>, Rob Clark <rob@ti.com> and
Daniel Vetter <daniel@ffwll.ch>.
The implementation is inspired from proof-of-concept patch-set from
Tomasz Stanislawski <t.stanislaws@samsung.com>, who demonstrated buffer sharing
between two v4l2 devices. [2]
[1]: https://wiki.linaro.org/OfficeofCTO/MemoryManagement
[2]: http://lwn.net/Articles/454389
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
Signed-off-by: Sumit Semwal <sumit.semwal@ti.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-and-Tested-by: Rob Clark <rob.clark@linaro.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-12-26 17:23:15 +08:00
|
|
|
list_del(&attach->node);
|
2022-10-18 01:22:24 +08:00
|
|
|
|
dma-buf: change DMA-buf locking convention v3
This patch is a stripped down version of the locking changes
necessary to support dynamic DMA-buf handling.
It adds a dynamic flag for both importers as well as exporters
so that drivers can choose if they want the reservation object
locked or unlocked during mapping of attachments.
For compatibility between drivers we cache the DMA-buf mapping
during attaching an importer as soon as exporter/importer
disagree on the dynamic handling.
Issues and solutions we considered:
- We can't change all existing drivers, and existing improters have
strong opinions about which locks they're holding while calling
dma_buf_attachment_map/unmap. Exporters also have strong opinions about
which locks they can acquire in their ->map/unmap callbacks, levaing no
room for change. The solution to avoid this was to move the
actual map/unmap out from this call, into the attach/detach callbacks,
and cache the mapping. This works because drivers don't call
attach/detach from deep within their code callchains (like deep in
memory management code called from cs/execbuf ioctl), but directly from
the fd2handle implementation.
- The caching has some troubles on some soc drivers, which set other modes
than DMA_BIDIRECTIONAL. We can't have 2 incompatible mappings, and we
can't re-create the mapping at _map time due to the above locking fun.
We very carefuly step around that by only caching at attach time if the
dynamic mode between importer/expoert mismatches.
- There's been quite some discussion on dma-buf mappings which need active
cache management, which would all break down when caching, plus we don't
have explicit flush operations on the attachment side. The solution to
this was to shrug and keep the current discrepancy between what the
dma-buf docs claim and what implementations do, with the hope that the
begin/end_cpu_access hooks are good enough and that all necessary
flushing to keep device mappings consistent will be done there.
v2: cleanup set_name merge, improve kerneldoc
v3: update commit message, kerneldoc and cleanup _debug_show()
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/336788/
2018-07-03 22:42:26 +08:00
|
|
|
dma_resv_unlock(dmabuf->resv);
|
2022-10-18 01:22:24 +08:00
|
|
|
|
dma-buf: Introduce dma buffer sharing mechanism
This is the first step in defining a dma buffer sharing mechanism.
A new buffer object dma_buf is added, with operations and API to allow easy
sharing of this buffer object across devices.
The framework allows:
- creation of a buffer object, its association with a file pointer, and
associated allocator-defined operations on that buffer. This operation is
called the 'export' operation.
- different devices to 'attach' themselves to this exported buffer object, to
facilitate backing storage negotiation, using dma_buf_attach() API.
- the exported buffer object to be shared with the other entity by asking for
its 'file-descriptor (fd)', and sharing the fd across.
- a received fd to get the buffer object back, where it can be accessed using
the associated exporter-defined operations.
- the exporter and user to share the scatterlist associated with this buffer
object using map_dma_buf and unmap_dma_buf operations.
Atleast one 'attach()' call is required to be made prior to calling the
map_dma_buf() operation.
Couple of building blocks in map_dma_buf() are added to ease introduction
of sync'ing across exporter and users, and late allocation by the exporter.
For this first version, this framework will work with certain conditions:
- *ONLY* exporter will be allowed to mmap to userspace (outside of this
framework - mmap is not a buffer object operation),
- currently, *ONLY* users that do not need CPU access to the buffer are
allowed.
More details are there in the documentation patch.
This is based on design suggestions from many people at the mini-summits[1],
most notably from Arnd Bergmann <arnd@arndb.de>, Rob Clark <rob@ti.com> and
Daniel Vetter <daniel@ffwll.ch>.
The implementation is inspired from proof-of-concept patch-set from
Tomasz Stanislawski <t.stanislaws@samsung.com>, who demonstrated buffer sharing
between two v4l2 devices. [2]
[1]: https://wiki.linaro.org/OfficeofCTO/MemoryManagement
[2]: http://lwn.net/Articles/454389
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
Signed-off-by: Sumit Semwal <sumit.semwal@ti.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-and-Tested-by: Rob Clark <rob.clark@linaro.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-12-26 17:23:15 +08:00
|
|
|
if (dmabuf->ops->detach)
|
|
|
|
dmabuf->ops->detach(dmabuf, attach);
|
|
|
|
|
|
|
|
kfree(attach);
|
|
|
|
}
|
2021-10-10 20:46:28 +08:00
|
|
|
EXPORT_SYMBOL_NS_GPL(dma_buf_detach, DMA_BUF);
|
dma-buf: Introduce dma buffer sharing mechanism
This is the first step in defining a dma buffer sharing mechanism.
A new buffer object dma_buf is added, with operations and API to allow easy
sharing of this buffer object across devices.
The framework allows:
- creation of a buffer object, its association with a file pointer, and
associated allocator-defined operations on that buffer. This operation is
called the 'export' operation.
- different devices to 'attach' themselves to this exported buffer object, to
facilitate backing storage negotiation, using dma_buf_attach() API.
- the exported buffer object to be shared with the other entity by asking for
its 'file-descriptor (fd)', and sharing the fd across.
- a received fd to get the buffer object back, where it can be accessed using
the associated exporter-defined operations.
- the exporter and user to share the scatterlist associated with this buffer
object using map_dma_buf and unmap_dma_buf operations.
Atleast one 'attach()' call is required to be made prior to calling the
map_dma_buf() operation.
Couple of building blocks in map_dma_buf() are added to ease introduction
of sync'ing across exporter and users, and late allocation by the exporter.
For this first version, this framework will work with certain conditions:
- *ONLY* exporter will be allowed to mmap to userspace (outside of this
framework - mmap is not a buffer object operation),
- currently, *ONLY* users that do not need CPU access to the buffer are
allowed.
More details are there in the documentation patch.
This is based on design suggestions from many people at the mini-summits[1],
most notably from Arnd Bergmann <arnd@arndb.de>, Rob Clark <rob@ti.com> and
Daniel Vetter <daniel@ffwll.ch>.
The implementation is inspired from proof-of-concept patch-set from
Tomasz Stanislawski <t.stanislaws@samsung.com>, who demonstrated buffer sharing
between two v4l2 devices. [2]
[1]: https://wiki.linaro.org/OfficeofCTO/MemoryManagement
[2]: http://lwn.net/Articles/454389
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
Signed-off-by: Sumit Semwal <sumit.semwal@ti.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-and-Tested-by: Rob Clark <rob.clark@linaro.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-12-26 17:23:15 +08:00
|
|
|
|
2018-07-03 22:42:26 +08:00
|
|
|
/**
|
|
|
|
* dma_buf_pin - Lock down the DMA-buf
|
|
|
|
* @attach: [in] attachment which should be pinned
|
|
|
|
*
|
2020-12-11 23:58:43 +08:00
|
|
|
* Only dynamic importers (who set up @attach with dma_buf_dynamic_attach()) may
|
|
|
|
* call this, and only for limited use cases like scanout and not for temporary
|
|
|
|
* pin operations. It is not permitted to allow userspace to pin arbitrary
|
|
|
|
* amounts of buffers through this interface.
|
|
|
|
*
|
|
|
|
* Buffers must be unpinned by calling dma_buf_unpin().
|
|
|
|
*
|
2018-07-03 22:42:26 +08:00
|
|
|
* Returns:
|
|
|
|
* 0 on success, negative error code on failure.
|
|
|
|
*/
|
|
|
|
int dma_buf_pin(struct dma_buf_attachment *attach)
|
|
|
|
{
|
|
|
|
struct dma_buf *dmabuf = attach->dmabuf;
|
|
|
|
int ret = 0;
|
|
|
|
|
2020-12-11 23:58:43 +08:00
|
|
|
WARN_ON(!dma_buf_attachment_is_dynamic(attach));
|
|
|
|
|
2018-07-03 22:42:26 +08:00
|
|
|
dma_resv_assert_held(dmabuf->resv);
|
|
|
|
|
|
|
|
if (dmabuf->ops->pin)
|
|
|
|
ret = dmabuf->ops->pin(attach);
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
2021-10-10 20:46:28 +08:00
|
|
|
EXPORT_SYMBOL_NS_GPL(dma_buf_pin, DMA_BUF);
|
2018-07-03 22:42:26 +08:00
|
|
|
|
|
|
|
/**
|
2020-12-11 23:58:43 +08:00
|
|
|
* dma_buf_unpin - Unpin a DMA-buf
|
2018-07-03 22:42:26 +08:00
|
|
|
* @attach: [in] attachment which should be unpinned
|
2020-12-11 23:58:43 +08:00
|
|
|
*
|
|
|
|
* This unpins a buffer pinned by dma_buf_pin() and allows the exporter to move
|
|
|
|
* any mapping of @attach again and inform the importer through
|
|
|
|
* &dma_buf_attach_ops.move_notify.
|
2018-07-03 22:42:26 +08:00
|
|
|
*/
|
|
|
|
void dma_buf_unpin(struct dma_buf_attachment *attach)
|
|
|
|
{
|
|
|
|
struct dma_buf *dmabuf = attach->dmabuf;
|
|
|
|
|
2020-12-11 23:58:43 +08:00
|
|
|
WARN_ON(!dma_buf_attachment_is_dynamic(attach));
|
|
|
|
|
2018-07-03 22:42:26 +08:00
|
|
|
dma_resv_assert_held(dmabuf->resv);
|
|
|
|
|
|
|
|
if (dmabuf->ops->unpin)
|
|
|
|
dmabuf->ops->unpin(attach);
|
|
|
|
}
|
2021-10-10 20:46:28 +08:00
|
|
|
EXPORT_SYMBOL_NS_GPL(dma_buf_unpin, DMA_BUF);
|
2018-07-03 22:42:26 +08:00
|
|
|
|
dma-buf: Introduce dma buffer sharing mechanism
This is the first step in defining a dma buffer sharing mechanism.
A new buffer object dma_buf is added, with operations and API to allow easy
sharing of this buffer object across devices.
The framework allows:
- creation of a buffer object, its association with a file pointer, and
associated allocator-defined operations on that buffer. This operation is
called the 'export' operation.
- different devices to 'attach' themselves to this exported buffer object, to
facilitate backing storage negotiation, using dma_buf_attach() API.
- the exported buffer object to be shared with the other entity by asking for
its 'file-descriptor (fd)', and sharing the fd across.
- a received fd to get the buffer object back, where it can be accessed using
the associated exporter-defined operations.
- the exporter and user to share the scatterlist associated with this buffer
object using map_dma_buf and unmap_dma_buf operations.
Atleast one 'attach()' call is required to be made prior to calling the
map_dma_buf() operation.
Couple of building blocks in map_dma_buf() are added to ease introduction
of sync'ing across exporter and users, and late allocation by the exporter.
For this first version, this framework will work with certain conditions:
- *ONLY* exporter will be allowed to mmap to userspace (outside of this
framework - mmap is not a buffer object operation),
- currently, *ONLY* users that do not need CPU access to the buffer are
allowed.
More details are there in the documentation patch.
This is based on design suggestions from many people at the mini-summits[1],
most notably from Arnd Bergmann <arnd@arndb.de>, Rob Clark <rob@ti.com> and
Daniel Vetter <daniel@ffwll.ch>.
The implementation is inspired from proof-of-concept patch-set from
Tomasz Stanislawski <t.stanislaws@samsung.com>, who demonstrated buffer sharing
between two v4l2 devices. [2]
[1]: https://wiki.linaro.org/OfficeofCTO/MemoryManagement
[2]: http://lwn.net/Articles/454389
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
Signed-off-by: Sumit Semwal <sumit.semwal@ti.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-and-Tested-by: Rob Clark <rob.clark@linaro.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-12-26 17:23:15 +08:00
|
|
|
/**
|
|
|
|
* dma_buf_map_attachment - Returns the scatterlist table of the attachment;
|
|
|
|
* mapped into _device_ address space. Is a wrapper for map_dma_buf() of the
|
|
|
|
* dma_buf_ops.
|
|
|
|
* @attach: [in] attachment whose scatterlist is to be returned
|
|
|
|
* @direction: [in] direction of DMA transfer
|
|
|
|
*
|
2013-12-21 08:43:50 +08:00
|
|
|
* Returns sg_table containing the scatterlist to be returned; returns ERR_PTR
|
2016-12-10 02:53:07 +08:00
|
|
|
* on error. May return -EINTR if it is interrupted by a signal.
|
|
|
|
*
|
2020-10-15 00:16:01 +08:00
|
|
|
* On success, the DMA addresses and lengths in the returned scatterlist are
|
|
|
|
* PAGE_SIZE aligned.
|
|
|
|
*
|
2017-11-01 22:06:30 +08:00
|
|
|
* A mapping must be unmapped by using dma_buf_unmap_attachment(). Note that
|
2016-12-10 02:53:07 +08:00
|
|
|
* the underlying backing storage is pinned for as long as a mapping exists,
|
|
|
|
* therefore users/importers should not hold onto a mapping for undue amounts of
|
|
|
|
* time.
|
2021-06-21 23:17:58 +08:00
|
|
|
*
|
|
|
|
* Important: Dynamic importers must wait for the exclusive fence of the struct
|
|
|
|
* dma_resv attached to the DMA-BUF first.
|
dma-buf: Introduce dma buffer sharing mechanism
This is the first step in defining a dma buffer sharing mechanism.
A new buffer object dma_buf is added, with operations and API to allow easy
sharing of this buffer object across devices.
The framework allows:
- creation of a buffer object, its association with a file pointer, and
associated allocator-defined operations on that buffer. This operation is
called the 'export' operation.
- different devices to 'attach' themselves to this exported buffer object, to
facilitate backing storage negotiation, using dma_buf_attach() API.
- the exported buffer object to be shared with the other entity by asking for
its 'file-descriptor (fd)', and sharing the fd across.
- a received fd to get the buffer object back, where it can be accessed using
the associated exporter-defined operations.
- the exporter and user to share the scatterlist associated with this buffer
object using map_dma_buf and unmap_dma_buf operations.
Atleast one 'attach()' call is required to be made prior to calling the
map_dma_buf() operation.
Couple of building blocks in map_dma_buf() are added to ease introduction
of sync'ing across exporter and users, and late allocation by the exporter.
For this first version, this framework will work with certain conditions:
- *ONLY* exporter will be allowed to mmap to userspace (outside of this
framework - mmap is not a buffer object operation),
- currently, *ONLY* users that do not need CPU access to the buffer are
allowed.
More details are there in the documentation patch.
This is based on design suggestions from many people at the mini-summits[1],
most notably from Arnd Bergmann <arnd@arndb.de>, Rob Clark <rob@ti.com> and
Daniel Vetter <daniel@ffwll.ch>.
The implementation is inspired from proof-of-concept patch-set from
Tomasz Stanislawski <t.stanislaws@samsung.com>, who demonstrated buffer sharing
between two v4l2 devices. [2]
[1]: https://wiki.linaro.org/OfficeofCTO/MemoryManagement
[2]: http://lwn.net/Articles/454389
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
Signed-off-by: Sumit Semwal <sumit.semwal@ti.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-and-Tested-by: Rob Clark <rob.clark@linaro.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-12-26 17:23:15 +08:00
|
|
|
*/
|
|
|
|
struct sg_table *dma_buf_map_attachment(struct dma_buf_attachment *attach,
|
|
|
|
enum dma_data_direction direction)
|
|
|
|
{
|
2017-09-15 07:05:16 +08:00
|
|
|
struct sg_table *sg_table;
|
2018-07-03 22:42:26 +08:00
|
|
|
int r;
|
dma-buf: Introduce dma buffer sharing mechanism
This is the first step in defining a dma buffer sharing mechanism.
A new buffer object dma_buf is added, with operations and API to allow easy
sharing of this buffer object across devices.
The framework allows:
- creation of a buffer object, its association with a file pointer, and
associated allocator-defined operations on that buffer. This operation is
called the 'export' operation.
- different devices to 'attach' themselves to this exported buffer object, to
facilitate backing storage negotiation, using dma_buf_attach() API.
- the exported buffer object to be shared with the other entity by asking for
its 'file-descriptor (fd)', and sharing the fd across.
- a received fd to get the buffer object back, where it can be accessed using
the associated exporter-defined operations.
- the exporter and user to share the scatterlist associated with this buffer
object using map_dma_buf and unmap_dma_buf operations.
Atleast one 'attach()' call is required to be made prior to calling the
map_dma_buf() operation.
Couple of building blocks in map_dma_buf() are added to ease introduction
of sync'ing across exporter and users, and late allocation by the exporter.
For this first version, this framework will work with certain conditions:
- *ONLY* exporter will be allowed to mmap to userspace (outside of this
framework - mmap is not a buffer object operation),
- currently, *ONLY* users that do not need CPU access to the buffer are
allowed.
More details are there in the documentation patch.
This is based on design suggestions from many people at the mini-summits[1],
most notably from Arnd Bergmann <arnd@arndb.de>, Rob Clark <rob@ti.com> and
Daniel Vetter <daniel@ffwll.ch>.
The implementation is inspired from proof-of-concept patch-set from
Tomasz Stanislawski <t.stanislaws@samsung.com>, who demonstrated buffer sharing
between two v4l2 devices. [2]
[1]: https://wiki.linaro.org/OfficeofCTO/MemoryManagement
[2]: http://lwn.net/Articles/454389
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
Signed-off-by: Sumit Semwal <sumit.semwal@ti.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-and-Tested-by: Rob Clark <rob.clark@linaro.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-12-26 17:23:15 +08:00
|
|
|
|
|
|
|
might_sleep();
|
|
|
|
|
2012-01-26 19:27:23 +08:00
|
|
|
if (WARN_ON(!attach || !attach->dmabuf))
|
dma-buf: Introduce dma buffer sharing mechanism
This is the first step in defining a dma buffer sharing mechanism.
A new buffer object dma_buf is added, with operations and API to allow easy
sharing of this buffer object across devices.
The framework allows:
- creation of a buffer object, its association with a file pointer, and
associated allocator-defined operations on that buffer. This operation is
called the 'export' operation.
- different devices to 'attach' themselves to this exported buffer object, to
facilitate backing storage negotiation, using dma_buf_attach() API.
- the exported buffer object to be shared with the other entity by asking for
its 'file-descriptor (fd)', and sharing the fd across.
- a received fd to get the buffer object back, where it can be accessed using
the associated exporter-defined operations.
- the exporter and user to share the scatterlist associated with this buffer
object using map_dma_buf and unmap_dma_buf operations.
Atleast one 'attach()' call is required to be made prior to calling the
map_dma_buf() operation.
Couple of building blocks in map_dma_buf() are added to ease introduction
of sync'ing across exporter and users, and late allocation by the exporter.
For this first version, this framework will work with certain conditions:
- *ONLY* exporter will be allowed to mmap to userspace (outside of this
framework - mmap is not a buffer object operation),
- currently, *ONLY* users that do not need CPU access to the buffer are
allowed.
More details are there in the documentation patch.
This is based on design suggestions from many people at the mini-summits[1],
most notably from Arnd Bergmann <arnd@arndb.de>, Rob Clark <rob@ti.com> and
Daniel Vetter <daniel@ffwll.ch>.
The implementation is inspired from proof-of-concept patch-set from
Tomasz Stanislawski <t.stanislaws@samsung.com>, who demonstrated buffer sharing
between two v4l2 devices. [2]
[1]: https://wiki.linaro.org/OfficeofCTO/MemoryManagement
[2]: http://lwn.net/Articles/454389
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
Signed-off-by: Sumit Semwal <sumit.semwal@ti.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-and-Tested-by: Rob Clark <rob.clark@linaro.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-12-26 17:23:15 +08:00
|
|
|
return ERR_PTR(-EINVAL);
|
|
|
|
|
2022-10-18 01:22:25 +08:00
|
|
|
dma_resv_assert_held(attach->dmabuf->resv);
|
dma-buf: change DMA-buf locking convention v3
This patch is a stripped down version of the locking changes
necessary to support dynamic DMA-buf handling.
It adds a dynamic flag for both importers as well as exporters
so that drivers can choose if they want the reservation object
locked or unlocked during mapping of attachments.
For compatibility between drivers we cache the DMA-buf mapping
during attaching an importer as soon as exporter/importer
disagree on the dynamic handling.
Issues and solutions we considered:
- We can't change all existing drivers, and existing improters have
strong opinions about which locks they're holding while calling
dma_buf_attachment_map/unmap. Exporters also have strong opinions about
which locks they can acquire in their ->map/unmap callbacks, levaing no
room for change. The solution to avoid this was to move the
actual map/unmap out from this call, into the attach/detach callbacks,
and cache the mapping. This works because drivers don't call
attach/detach from deep within their code callchains (like deep in
memory management code called from cs/execbuf ioctl), but directly from
the fd2handle implementation.
- The caching has some troubles on some soc drivers, which set other modes
than DMA_BIDIRECTIONAL. We can't have 2 incompatible mappings, and we
can't re-create the mapping at _map time due to the above locking fun.
We very carefuly step around that by only caching at attach time if the
dynamic mode between importer/expoert mismatches.
- There's been quite some discussion on dma-buf mappings which need active
cache management, which would all break down when caching, plus we don't
have explicit flush operations on the attachment side. The solution to
this was to shrug and keep the current discrepancy between what the
dma-buf docs claim and what implementations do, with the hope that the
begin/end_cpu_access hooks are good enough and that all necessary
flushing to keep device mappings consistent will be done there.
v2: cleanup set_name merge, improve kerneldoc
v3: update commit message, kerneldoc and cleanup _debug_show()
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/336788/
2018-07-03 22:42:26 +08:00
|
|
|
|
2018-07-03 22:42:26 +08:00
|
|
|
if (attach->sgt) {
|
|
|
|
/*
|
|
|
|
* Two mappings with different directions for the same
|
|
|
|
* attachment are not allowed.
|
|
|
|
*/
|
|
|
|
if (attach->dir != direction &&
|
|
|
|
attach->dir != DMA_BIDIRECTIONAL)
|
|
|
|
return ERR_PTR(-EBUSY);
|
|
|
|
|
|
|
|
return attach->sgt;
|
|
|
|
}
|
|
|
|
|
2018-07-03 22:42:26 +08:00
|
|
|
if (dma_buf_is_dynamic(attach->dmabuf)) {
|
2020-02-19 20:32:43 +08:00
|
|
|
if (!IS_ENABLED(CONFIG_DMABUF_MOVE_NOTIFY)) {
|
2021-05-17 19:20:17 +08:00
|
|
|
r = attach->dmabuf->ops->pin(attach);
|
2018-07-03 22:42:26 +08:00
|
|
|
if (r)
|
|
|
|
return ERR_PTR(r);
|
|
|
|
}
|
|
|
|
}
|
dma-buf: change DMA-buf locking convention v3
This patch is a stripped down version of the locking changes
necessary to support dynamic DMA-buf handling.
It adds a dynamic flag for both importers as well as exporters
so that drivers can choose if they want the reservation object
locked or unlocked during mapping of attachments.
For compatibility between drivers we cache the DMA-buf mapping
during attaching an importer as soon as exporter/importer
disagree on the dynamic handling.
Issues and solutions we considered:
- We can't change all existing drivers, and existing improters have
strong opinions about which locks they're holding while calling
dma_buf_attachment_map/unmap. Exporters also have strong opinions about
which locks they can acquire in their ->map/unmap callbacks, levaing no
room for change. The solution to avoid this was to move the
actual map/unmap out from this call, into the attach/detach callbacks,
and cache the mapping. This works because drivers don't call
attach/detach from deep within their code callchains (like deep in
memory management code called from cs/execbuf ioctl), but directly from
the fd2handle implementation.
- The caching has some troubles on some soc drivers, which set other modes
than DMA_BIDIRECTIONAL. We can't have 2 incompatible mappings, and we
can't re-create the mapping at _map time due to the above locking fun.
We very carefuly step around that by only caching at attach time if the
dynamic mode between importer/expoert mismatches.
- There's been quite some discussion on dma-buf mappings which need active
cache management, which would all break down when caching, plus we don't
have explicit flush operations on the attachment side. The solution to
this was to shrug and keep the current discrepancy between what the
dma-buf docs claim and what implementations do, with the hope that the
begin/end_cpu_access hooks are good enough and that all necessary
flushing to keep device mappings consistent will be done there.
v2: cleanup set_name merge, improve kerneldoc
v3: update commit message, kerneldoc and cleanup _debug_show()
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/336788/
2018-07-03 22:42:26 +08:00
|
|
|
|
2021-01-16 00:47:39 +08:00
|
|
|
sg_table = __map_dma_buf(attach, direction);
|
2013-12-21 08:43:50 +08:00
|
|
|
if (!sg_table)
|
|
|
|
sg_table = ERR_PTR(-ENOMEM);
|
dma-buf: Introduce dma buffer sharing mechanism
This is the first step in defining a dma buffer sharing mechanism.
A new buffer object dma_buf is added, with operations and API to allow easy
sharing of this buffer object across devices.
The framework allows:
- creation of a buffer object, its association with a file pointer, and
associated allocator-defined operations on that buffer. This operation is
called the 'export' operation.
- different devices to 'attach' themselves to this exported buffer object, to
facilitate backing storage negotiation, using dma_buf_attach() API.
- the exported buffer object to be shared with the other entity by asking for
its 'file-descriptor (fd)', and sharing the fd across.
- a received fd to get the buffer object back, where it can be accessed using
the associated exporter-defined operations.
- the exporter and user to share the scatterlist associated with this buffer
object using map_dma_buf and unmap_dma_buf operations.
Atleast one 'attach()' call is required to be made prior to calling the
map_dma_buf() operation.
Couple of building blocks in map_dma_buf() are added to ease introduction
of sync'ing across exporter and users, and late allocation by the exporter.
For this first version, this framework will work with certain conditions:
- *ONLY* exporter will be allowed to mmap to userspace (outside of this
framework - mmap is not a buffer object operation),
- currently, *ONLY* users that do not need CPU access to the buffer are
allowed.
More details are there in the documentation patch.
This is based on design suggestions from many people at the mini-summits[1],
most notably from Arnd Bergmann <arnd@arndb.de>, Rob Clark <rob@ti.com> and
Daniel Vetter <daniel@ffwll.ch>.
The implementation is inspired from proof-of-concept patch-set from
Tomasz Stanislawski <t.stanislaws@samsung.com>, who demonstrated buffer sharing
between two v4l2 devices. [2]
[1]: https://wiki.linaro.org/OfficeofCTO/MemoryManagement
[2]: http://lwn.net/Articles/454389
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
Signed-off-by: Sumit Semwal <sumit.semwal@ti.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-and-Tested-by: Rob Clark <rob.clark@linaro.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-12-26 17:23:15 +08:00
|
|
|
|
2018-07-03 22:42:26 +08:00
|
|
|
if (IS_ERR(sg_table) && dma_buf_is_dynamic(attach->dmabuf) &&
|
2020-02-19 20:32:43 +08:00
|
|
|
!IS_ENABLED(CONFIG_DMABUF_MOVE_NOTIFY))
|
2021-05-17 19:20:17 +08:00
|
|
|
attach->dmabuf->ops->unpin(attach);
|
2018-07-03 22:42:26 +08:00
|
|
|
|
2018-07-03 22:42:26 +08:00
|
|
|
if (!IS_ERR(sg_table) && attach->dmabuf->ops->cache_sgt_mapping) {
|
|
|
|
attach->sgt = sg_table;
|
|
|
|
attach->dir = direction;
|
|
|
|
}
|
|
|
|
|
2020-10-15 00:16:01 +08:00
|
|
|
#ifdef CONFIG_DMA_API_DEBUG
|
2020-11-03 11:51:58 +08:00
|
|
|
if (!IS_ERR(sg_table)) {
|
2020-10-15 00:16:01 +08:00
|
|
|
struct scatterlist *sg;
|
|
|
|
u64 addr;
|
|
|
|
int len;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
for_each_sgtable_dma_sg(sg_table, sg, i) {
|
|
|
|
addr = sg_dma_address(sg);
|
|
|
|
len = sg_dma_len(sg);
|
|
|
|
if (!PAGE_ALIGNED(addr) || !PAGE_ALIGNED(len)) {
|
|
|
|
pr_debug("%s: addr %llx or len %x is not page aligned!\n",
|
|
|
|
__func__, addr, len);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
#endif /* CONFIG_DMA_API_DEBUG */
|
dma-buf: Introduce dma buffer sharing mechanism
This is the first step in defining a dma buffer sharing mechanism.
A new buffer object dma_buf is added, with operations and API to allow easy
sharing of this buffer object across devices.
The framework allows:
- creation of a buffer object, its association with a file pointer, and
associated allocator-defined operations on that buffer. This operation is
called the 'export' operation.
- different devices to 'attach' themselves to this exported buffer object, to
facilitate backing storage negotiation, using dma_buf_attach() API.
- the exported buffer object to be shared with the other entity by asking for
its 'file-descriptor (fd)', and sharing the fd across.
- a received fd to get the buffer object back, where it can be accessed using
the associated exporter-defined operations.
- the exporter and user to share the scatterlist associated with this buffer
object using map_dma_buf and unmap_dma_buf operations.
Atleast one 'attach()' call is required to be made prior to calling the
map_dma_buf() operation.
Couple of building blocks in map_dma_buf() are added to ease introduction
of sync'ing across exporter and users, and late allocation by the exporter.
For this first version, this framework will work with certain conditions:
- *ONLY* exporter will be allowed to mmap to userspace (outside of this
framework - mmap is not a buffer object operation),
- currently, *ONLY* users that do not need CPU access to the buffer are
allowed.
More details are there in the documentation patch.
This is based on design suggestions from many people at the mini-summits[1],
most notably from Arnd Bergmann <arnd@arndb.de>, Rob Clark <rob@ti.com> and
Daniel Vetter <daniel@ffwll.ch>.
The implementation is inspired from proof-of-concept patch-set from
Tomasz Stanislawski <t.stanislaws@samsung.com>, who demonstrated buffer sharing
between two v4l2 devices. [2]
[1]: https://wiki.linaro.org/OfficeofCTO/MemoryManagement
[2]: http://lwn.net/Articles/454389
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
Signed-off-by: Sumit Semwal <sumit.semwal@ti.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-and-Tested-by: Rob Clark <rob.clark@linaro.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-12-26 17:23:15 +08:00
|
|
|
return sg_table;
|
|
|
|
}
|
2021-10-10 20:46:28 +08:00
|
|
|
EXPORT_SYMBOL_NS_GPL(dma_buf_map_attachment, DMA_BUF);
|
dma-buf: Introduce dma buffer sharing mechanism
This is the first step in defining a dma buffer sharing mechanism.
A new buffer object dma_buf is added, with operations and API to allow easy
sharing of this buffer object across devices.
The framework allows:
- creation of a buffer object, its association with a file pointer, and
associated allocator-defined operations on that buffer. This operation is
called the 'export' operation.
- different devices to 'attach' themselves to this exported buffer object, to
facilitate backing storage negotiation, using dma_buf_attach() API.
- the exported buffer object to be shared with the other entity by asking for
its 'file-descriptor (fd)', and sharing the fd across.
- a received fd to get the buffer object back, where it can be accessed using
the associated exporter-defined operations.
- the exporter and user to share the scatterlist associated with this buffer
object using map_dma_buf and unmap_dma_buf operations.
Atleast one 'attach()' call is required to be made prior to calling the
map_dma_buf() operation.
Couple of building blocks in map_dma_buf() are added to ease introduction
of sync'ing across exporter and users, and late allocation by the exporter.
For this first version, this framework will work with certain conditions:
- *ONLY* exporter will be allowed to mmap to userspace (outside of this
framework - mmap is not a buffer object operation),
- currently, *ONLY* users that do not need CPU access to the buffer are
allowed.
More details are there in the documentation patch.
This is based on design suggestions from many people at the mini-summits[1],
most notably from Arnd Bergmann <arnd@arndb.de>, Rob Clark <rob@ti.com> and
Daniel Vetter <daniel@ffwll.ch>.
The implementation is inspired from proof-of-concept patch-set from
Tomasz Stanislawski <t.stanislaws@samsung.com>, who demonstrated buffer sharing
between two v4l2 devices. [2]
[1]: https://wiki.linaro.org/OfficeofCTO/MemoryManagement
[2]: http://lwn.net/Articles/454389
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
Signed-off-by: Sumit Semwal <sumit.semwal@ti.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-and-Tested-by: Rob Clark <rob.clark@linaro.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-12-26 17:23:15 +08:00
|
|
|
|
2022-10-18 01:22:10 +08:00
|
|
|
/**
|
|
|
|
* dma_buf_map_attachment_unlocked - Returns the scatterlist table of the attachment;
|
|
|
|
* mapped into _device_ address space. Is a wrapper for map_dma_buf() of the
|
|
|
|
* dma_buf_ops.
|
|
|
|
* @attach: [in] attachment whose scatterlist is to be returned
|
|
|
|
* @direction: [in] direction of DMA transfer
|
|
|
|
*
|
|
|
|
* Unlocked variant of dma_buf_map_attachment().
|
|
|
|
*/
|
|
|
|
struct sg_table *
|
|
|
|
dma_buf_map_attachment_unlocked(struct dma_buf_attachment *attach,
|
|
|
|
enum dma_data_direction direction)
|
|
|
|
{
|
|
|
|
struct sg_table *sg_table;
|
|
|
|
|
|
|
|
might_sleep();
|
|
|
|
|
|
|
|
if (WARN_ON(!attach || !attach->dmabuf))
|
|
|
|
return ERR_PTR(-EINVAL);
|
|
|
|
|
|
|
|
dma_resv_lock(attach->dmabuf->resv, NULL);
|
|
|
|
sg_table = dma_buf_map_attachment(attach, direction);
|
|
|
|
dma_resv_unlock(attach->dmabuf->resv);
|
|
|
|
|
|
|
|
return sg_table;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_NS_GPL(dma_buf_map_attachment_unlocked, DMA_BUF);
|
|
|
|
|
dma-buf: Introduce dma buffer sharing mechanism
This is the first step in defining a dma buffer sharing mechanism.
A new buffer object dma_buf is added, with operations and API to allow easy
sharing of this buffer object across devices.
The framework allows:
- creation of a buffer object, its association with a file pointer, and
associated allocator-defined operations on that buffer. This operation is
called the 'export' operation.
- different devices to 'attach' themselves to this exported buffer object, to
facilitate backing storage negotiation, using dma_buf_attach() API.
- the exported buffer object to be shared with the other entity by asking for
its 'file-descriptor (fd)', and sharing the fd across.
- a received fd to get the buffer object back, where it can be accessed using
the associated exporter-defined operations.
- the exporter and user to share the scatterlist associated with this buffer
object using map_dma_buf and unmap_dma_buf operations.
Atleast one 'attach()' call is required to be made prior to calling the
map_dma_buf() operation.
Couple of building blocks in map_dma_buf() are added to ease introduction
of sync'ing across exporter and users, and late allocation by the exporter.
For this first version, this framework will work with certain conditions:
- *ONLY* exporter will be allowed to mmap to userspace (outside of this
framework - mmap is not a buffer object operation),
- currently, *ONLY* users that do not need CPU access to the buffer are
allowed.
More details are there in the documentation patch.
This is based on design suggestions from many people at the mini-summits[1],
most notably from Arnd Bergmann <arnd@arndb.de>, Rob Clark <rob@ti.com> and
Daniel Vetter <daniel@ffwll.ch>.
The implementation is inspired from proof-of-concept patch-set from
Tomasz Stanislawski <t.stanislaws@samsung.com>, who demonstrated buffer sharing
between two v4l2 devices. [2]
[1]: https://wiki.linaro.org/OfficeofCTO/MemoryManagement
[2]: http://lwn.net/Articles/454389
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
Signed-off-by: Sumit Semwal <sumit.semwal@ti.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-and-Tested-by: Rob Clark <rob.clark@linaro.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-12-26 17:23:15 +08:00
|
|
|
/**
|
|
|
|
* dma_buf_unmap_attachment - unmaps and decreases usecount of the buffer;might
|
|
|
|
* deallocate the scatterlist associated. Is a wrapper for unmap_dma_buf() of
|
|
|
|
* dma_buf_ops.
|
|
|
|
* @attach: [in] attachment to unmap buffer from
|
|
|
|
* @sg_table: [in] scatterlist info of the buffer to unmap
|
2012-01-27 17:39:27 +08:00
|
|
|
* @direction: [in] direction of DMA transfer
|
dma-buf: Introduce dma buffer sharing mechanism
This is the first step in defining a dma buffer sharing mechanism.
A new buffer object dma_buf is added, with operations and API to allow easy
sharing of this buffer object across devices.
The framework allows:
- creation of a buffer object, its association with a file pointer, and
associated allocator-defined operations on that buffer. This operation is
called the 'export' operation.
- different devices to 'attach' themselves to this exported buffer object, to
facilitate backing storage negotiation, using dma_buf_attach() API.
- the exported buffer object to be shared with the other entity by asking for
its 'file-descriptor (fd)', and sharing the fd across.
- a received fd to get the buffer object back, where it can be accessed using
the associated exporter-defined operations.
- the exporter and user to share the scatterlist associated with this buffer
object using map_dma_buf and unmap_dma_buf operations.
Atleast one 'attach()' call is required to be made prior to calling the
map_dma_buf() operation.
Couple of building blocks in map_dma_buf() are added to ease introduction
of sync'ing across exporter and users, and late allocation by the exporter.
For this first version, this framework will work with certain conditions:
- *ONLY* exporter will be allowed to mmap to userspace (outside of this
framework - mmap is not a buffer object operation),
- currently, *ONLY* users that do not need CPU access to the buffer are
allowed.
More details are there in the documentation patch.
This is based on design suggestions from many people at the mini-summits[1],
most notably from Arnd Bergmann <arnd@arndb.de>, Rob Clark <rob@ti.com> and
Daniel Vetter <daniel@ffwll.ch>.
The implementation is inspired from proof-of-concept patch-set from
Tomasz Stanislawski <t.stanislaws@samsung.com>, who demonstrated buffer sharing
between two v4l2 devices. [2]
[1]: https://wiki.linaro.org/OfficeofCTO/MemoryManagement
[2]: http://lwn.net/Articles/454389
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
Signed-off-by: Sumit Semwal <sumit.semwal@ti.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-and-Tested-by: Rob Clark <rob.clark@linaro.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-12-26 17:23:15 +08:00
|
|
|
*
|
2016-12-10 02:53:07 +08:00
|
|
|
* This unmaps a DMA mapping for @attached obtained by dma_buf_map_attachment().
|
dma-buf: Introduce dma buffer sharing mechanism
This is the first step in defining a dma buffer sharing mechanism.
A new buffer object dma_buf is added, with operations and API to allow easy
sharing of this buffer object across devices.
The framework allows:
- creation of a buffer object, its association with a file pointer, and
associated allocator-defined operations on that buffer. This operation is
called the 'export' operation.
- different devices to 'attach' themselves to this exported buffer object, to
facilitate backing storage negotiation, using dma_buf_attach() API.
- the exported buffer object to be shared with the other entity by asking for
its 'file-descriptor (fd)', and sharing the fd across.
- a received fd to get the buffer object back, where it can be accessed using
the associated exporter-defined operations.
- the exporter and user to share the scatterlist associated with this buffer
object using map_dma_buf and unmap_dma_buf operations.
Atleast one 'attach()' call is required to be made prior to calling the
map_dma_buf() operation.
Couple of building blocks in map_dma_buf() are added to ease introduction
of sync'ing across exporter and users, and late allocation by the exporter.
For this first version, this framework will work with certain conditions:
- *ONLY* exporter will be allowed to mmap to userspace (outside of this
framework - mmap is not a buffer object operation),
- currently, *ONLY* users that do not need CPU access to the buffer are
allowed.
More details are there in the documentation patch.
This is based on design suggestions from many people at the mini-summits[1],
most notably from Arnd Bergmann <arnd@arndb.de>, Rob Clark <rob@ti.com> and
Daniel Vetter <daniel@ffwll.ch>.
The implementation is inspired from proof-of-concept patch-set from
Tomasz Stanislawski <t.stanislaws@samsung.com>, who demonstrated buffer sharing
between two v4l2 devices. [2]
[1]: https://wiki.linaro.org/OfficeofCTO/MemoryManagement
[2]: http://lwn.net/Articles/454389
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
Signed-off-by: Sumit Semwal <sumit.semwal@ti.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-and-Tested-by: Rob Clark <rob.clark@linaro.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-12-26 17:23:15 +08:00
|
|
|
*/
|
|
|
|
void dma_buf_unmap_attachment(struct dma_buf_attachment *attach,
|
2012-01-27 17:39:27 +08:00
|
|
|
struct sg_table *sg_table,
|
|
|
|
enum dma_data_direction direction)
|
dma-buf: Introduce dma buffer sharing mechanism
This is the first step in defining a dma buffer sharing mechanism.
A new buffer object dma_buf is added, with operations and API to allow easy
sharing of this buffer object across devices.
The framework allows:
- creation of a buffer object, its association with a file pointer, and
associated allocator-defined operations on that buffer. This operation is
called the 'export' operation.
- different devices to 'attach' themselves to this exported buffer object, to
facilitate backing storage negotiation, using dma_buf_attach() API.
- the exported buffer object to be shared with the other entity by asking for
its 'file-descriptor (fd)', and sharing the fd across.
- a received fd to get the buffer object back, where it can be accessed using
the associated exporter-defined operations.
- the exporter and user to share the scatterlist associated with this buffer
object using map_dma_buf and unmap_dma_buf operations.
Atleast one 'attach()' call is required to be made prior to calling the
map_dma_buf() operation.
Couple of building blocks in map_dma_buf() are added to ease introduction
of sync'ing across exporter and users, and late allocation by the exporter.
For this first version, this framework will work with certain conditions:
- *ONLY* exporter will be allowed to mmap to userspace (outside of this
framework - mmap is not a buffer object operation),
- currently, *ONLY* users that do not need CPU access to the buffer are
allowed.
More details are there in the documentation patch.
This is based on design suggestions from many people at the mini-summits[1],
most notably from Arnd Bergmann <arnd@arndb.de>, Rob Clark <rob@ti.com> and
Daniel Vetter <daniel@ffwll.ch>.
The implementation is inspired from proof-of-concept patch-set from
Tomasz Stanislawski <t.stanislaws@samsung.com>, who demonstrated buffer sharing
between two v4l2 devices. [2]
[1]: https://wiki.linaro.org/OfficeofCTO/MemoryManagement
[2]: http://lwn.net/Articles/454389
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
Signed-off-by: Sumit Semwal <sumit.semwal@ti.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-and-Tested-by: Rob Clark <rob.clark@linaro.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-12-26 17:23:15 +08:00
|
|
|
{
|
2012-09-28 15:29:43 +08:00
|
|
|
might_sleep();
|
|
|
|
|
2012-01-26 19:27:23 +08:00
|
|
|
if (WARN_ON(!attach || !attach->dmabuf || !sg_table))
|
dma-buf: Introduce dma buffer sharing mechanism
This is the first step in defining a dma buffer sharing mechanism.
A new buffer object dma_buf is added, with operations and API to allow easy
sharing of this buffer object across devices.
The framework allows:
- creation of a buffer object, its association with a file pointer, and
associated allocator-defined operations on that buffer. This operation is
called the 'export' operation.
- different devices to 'attach' themselves to this exported buffer object, to
facilitate backing storage negotiation, using dma_buf_attach() API.
- the exported buffer object to be shared with the other entity by asking for
its 'file-descriptor (fd)', and sharing the fd across.
- a received fd to get the buffer object back, where it can be accessed using
the associated exporter-defined operations.
- the exporter and user to share the scatterlist associated with this buffer
object using map_dma_buf and unmap_dma_buf operations.
Atleast one 'attach()' call is required to be made prior to calling the
map_dma_buf() operation.
Couple of building blocks in map_dma_buf() are added to ease introduction
of sync'ing across exporter and users, and late allocation by the exporter.
For this first version, this framework will work with certain conditions:
- *ONLY* exporter will be allowed to mmap to userspace (outside of this
framework - mmap is not a buffer object operation),
- currently, *ONLY* users that do not need CPU access to the buffer are
allowed.
More details are there in the documentation patch.
This is based on design suggestions from many people at the mini-summits[1],
most notably from Arnd Bergmann <arnd@arndb.de>, Rob Clark <rob@ti.com> and
Daniel Vetter <daniel@ffwll.ch>.
The implementation is inspired from proof-of-concept patch-set from
Tomasz Stanislawski <t.stanislaws@samsung.com>, who demonstrated buffer sharing
between two v4l2 devices. [2]
[1]: https://wiki.linaro.org/OfficeofCTO/MemoryManagement
[2]: http://lwn.net/Articles/454389
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
Signed-off-by: Sumit Semwal <sumit.semwal@ti.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-and-Tested-by: Rob Clark <rob.clark@linaro.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-12-26 17:23:15 +08:00
|
|
|
return;
|
|
|
|
|
2022-10-18 01:22:25 +08:00
|
|
|
dma_resv_assert_held(attach->dmabuf->resv);
|
dma-buf: change DMA-buf locking convention v3
This patch is a stripped down version of the locking changes
necessary to support dynamic DMA-buf handling.
It adds a dynamic flag for both importers as well as exporters
so that drivers can choose if they want the reservation object
locked or unlocked during mapping of attachments.
For compatibility between drivers we cache the DMA-buf mapping
during attaching an importer as soon as exporter/importer
disagree on the dynamic handling.
Issues and solutions we considered:
- We can't change all existing drivers, and existing improters have
strong opinions about which locks they're holding while calling
dma_buf_attachment_map/unmap. Exporters also have strong opinions about
which locks they can acquire in their ->map/unmap callbacks, levaing no
room for change. The solution to avoid this was to move the
actual map/unmap out from this call, into the attach/detach callbacks,
and cache the mapping. This works because drivers don't call
attach/detach from deep within their code callchains (like deep in
memory management code called from cs/execbuf ioctl), but directly from
the fd2handle implementation.
- The caching has some troubles on some soc drivers, which set other modes
than DMA_BIDIRECTIONAL. We can't have 2 incompatible mappings, and we
can't re-create the mapping at _map time due to the above locking fun.
We very carefuly step around that by only caching at attach time if the
dynamic mode between importer/expoert mismatches.
- There's been quite some discussion on dma-buf mappings which need active
cache management, which would all break down when caching, plus we don't
have explicit flush operations on the attachment side. The solution to
this was to shrug and keep the current discrepancy between what the
dma-buf docs claim and what implementations do, with the hope that the
begin/end_cpu_access hooks are good enough and that all necessary
flushing to keep device mappings consistent will be done there.
v2: cleanup set_name merge, improve kerneldoc
v3: update commit message, kerneldoc and cleanup _debug_show()
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/336788/
2018-07-03 22:42:26 +08:00
|
|
|
|
2018-07-03 22:42:26 +08:00
|
|
|
if (attach->sgt == sg_table)
|
|
|
|
return;
|
|
|
|
|
2021-01-16 00:47:39 +08:00
|
|
|
__unmap_dma_buf(attach, sg_table, direction);
|
2018-07-03 22:42:26 +08:00
|
|
|
|
|
|
|
if (dma_buf_is_dynamic(attach->dmabuf) &&
|
2020-02-19 20:32:43 +08:00
|
|
|
!IS_ENABLED(CONFIG_DMABUF_MOVE_NOTIFY))
|
2018-07-03 22:42:26 +08:00
|
|
|
dma_buf_unpin(attach);
|
dma-buf: Introduce dma buffer sharing mechanism
This is the first step in defining a dma buffer sharing mechanism.
A new buffer object dma_buf is added, with operations and API to allow easy
sharing of this buffer object across devices.
The framework allows:
- creation of a buffer object, its association with a file pointer, and
associated allocator-defined operations on that buffer. This operation is
called the 'export' operation.
- different devices to 'attach' themselves to this exported buffer object, to
facilitate backing storage negotiation, using dma_buf_attach() API.
- the exported buffer object to be shared with the other entity by asking for
its 'file-descriptor (fd)', and sharing the fd across.
- a received fd to get the buffer object back, where it can be accessed using
the associated exporter-defined operations.
- the exporter and user to share the scatterlist associated with this buffer
object using map_dma_buf and unmap_dma_buf operations.
Atleast one 'attach()' call is required to be made prior to calling the
map_dma_buf() operation.
Couple of building blocks in map_dma_buf() are added to ease introduction
of sync'ing across exporter and users, and late allocation by the exporter.
For this first version, this framework will work with certain conditions:
- *ONLY* exporter will be allowed to mmap to userspace (outside of this
framework - mmap is not a buffer object operation),
- currently, *ONLY* users that do not need CPU access to the buffer are
allowed.
More details are there in the documentation patch.
This is based on design suggestions from many people at the mini-summits[1],
most notably from Arnd Bergmann <arnd@arndb.de>, Rob Clark <rob@ti.com> and
Daniel Vetter <daniel@ffwll.ch>.
The implementation is inspired from proof-of-concept patch-set from
Tomasz Stanislawski <t.stanislaws@samsung.com>, who demonstrated buffer sharing
between two v4l2 devices. [2]
[1]: https://wiki.linaro.org/OfficeofCTO/MemoryManagement
[2]: http://lwn.net/Articles/454389
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
Signed-off-by: Sumit Semwal <sumit.semwal@ti.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-and-Tested-by: Rob Clark <rob.clark@linaro.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-12-26 17:23:15 +08:00
|
|
|
}
|
2021-10-10 20:46:28 +08:00
|
|
|
EXPORT_SYMBOL_NS_GPL(dma_buf_unmap_attachment, DMA_BUF);
|
2012-03-20 07:02:37 +08:00
|
|
|
|
2022-10-18 01:22:10 +08:00
|
|
|
/**
|
|
|
|
* dma_buf_unmap_attachment_unlocked - unmaps and decreases usecount of the buffer;might
|
|
|
|
* deallocate the scatterlist associated. Is a wrapper for unmap_dma_buf() of
|
|
|
|
* dma_buf_ops.
|
|
|
|
* @attach: [in] attachment to unmap buffer from
|
|
|
|
* @sg_table: [in] scatterlist info of the buffer to unmap
|
|
|
|
* @direction: [in] direction of DMA transfer
|
|
|
|
*
|
|
|
|
* Unlocked variant of dma_buf_unmap_attachment().
|
|
|
|
*/
|
|
|
|
void dma_buf_unmap_attachment_unlocked(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;
|
|
|
|
|
|
|
|
dma_resv_lock(attach->dmabuf->resv, NULL);
|
|
|
|
dma_buf_unmap_attachment(attach, sg_table, direction);
|
|
|
|
dma_resv_unlock(attach->dmabuf->resv);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_NS_GPL(dma_buf_unmap_attachment_unlocked, DMA_BUF);
|
|
|
|
|
2018-07-03 22:42:26 +08:00
|
|
|
/**
|
|
|
|
* dma_buf_move_notify - notify attachments that DMA-buf is moving
|
|
|
|
*
|
|
|
|
* @dmabuf: [in] buffer which is moving
|
|
|
|
*
|
2022-11-24 03:35:18 +08:00
|
|
|
* Informs all attachments that they need to destroy and recreate all their
|
2018-07-03 22:42:26 +08:00
|
|
|
* mappings.
|
|
|
|
*/
|
|
|
|
void dma_buf_move_notify(struct dma_buf *dmabuf)
|
|
|
|
{
|
|
|
|
struct dma_buf_attachment *attach;
|
|
|
|
|
|
|
|
dma_resv_assert_held(dmabuf->resv);
|
|
|
|
|
|
|
|
list_for_each_entry(attach, &dmabuf->attachments, node)
|
2020-02-19 20:32:43 +08:00
|
|
|
if (attach->importer_ops)
|
2018-07-03 22:42:26 +08:00
|
|
|
attach->importer_ops->move_notify(attach);
|
|
|
|
}
|
2021-10-10 20:46:28 +08:00
|
|
|
EXPORT_SYMBOL_NS_GPL(dma_buf_move_notify, DMA_BUF);
|
2018-07-03 22:42:26 +08:00
|
|
|
|
2016-12-10 02:53:08 +08:00
|
|
|
/**
|
|
|
|
* DOC: cpu access
|
|
|
|
*
|
2022-11-24 03:35:18 +08:00
|
|
|
* There are multiple reasons for supporting CPU access to a dma buffer object:
|
2016-12-10 02:53:08 +08:00
|
|
|
*
|
|
|
|
* - Fallback operations in the kernel, for example when a device is connected
|
|
|
|
* over USB and the kernel needs to shuffle the data around first before
|
2022-11-24 03:35:18 +08:00
|
|
|
* sending it away. Cache coherency is handled by bracketing any transactions
|
2016-12-10 02:53:08 +08:00
|
|
|
* with calls to dma_buf_begin_cpu_access() and dma_buf_end_cpu_access()
|
|
|
|
* access.
|
|
|
|
*
|
2019-11-18 18:35:30 +08:00
|
|
|
* Since for most kernel internal dma-buf accesses need the entire buffer, a
|
|
|
|
* vmap interface is introduced. Note that on very old 32-bit architectures
|
|
|
|
* vmalloc space might be limited and result in vmap calls failing.
|
2016-12-10 02:53:08 +08:00
|
|
|
*
|
|
|
|
* Interfaces::
|
2020-12-11 23:58:40 +08:00
|
|
|
*
|
2022-02-05 01:05:41 +08:00
|
|
|
* void \*dma_buf_vmap(struct dma_buf \*dmabuf, struct iosys_map \*map)
|
|
|
|
* void dma_buf_vunmap(struct dma_buf \*dmabuf, struct iosys_map \*map)
|
2016-12-10 02:53:08 +08:00
|
|
|
*
|
|
|
|
* The vmap call can fail if there is no vmap support in the exporter, or if
|
2020-12-11 23:58:40 +08:00
|
|
|
* it runs out of vmalloc space. Note that the dma-buf layer keeps a reference
|
|
|
|
* count for all vmap access and calls down into the exporter's vmap function
|
|
|
|
* only when no vmapping exists, and only unmaps it once. Protection against
|
|
|
|
* concurrent vmap/vunmap calls is provided by taking the &dma_buf.lock mutex.
|
2016-12-10 02:53:08 +08:00
|
|
|
*
|
|
|
|
* - For full compatibility on the importer side with existing userspace
|
|
|
|
* interfaces, which might already support mmap'ing buffers. This is needed in
|
|
|
|
* many processing pipelines (e.g. feeding a software rendered image into a
|
|
|
|
* hardware pipeline, thumbnail creation, snapshots, ...). Also, Android's ION
|
|
|
|
* framework already supported this and for DMA buffer file descriptors to
|
|
|
|
* replace ION buffers mmap support was needed.
|
|
|
|
*
|
|
|
|
* There is no special interfaces, userspace simply calls mmap on the dma-buf
|
2022-11-24 03:35:18 +08:00
|
|
|
* fd. But like for CPU access there's a need to bracket the actual access,
|
2016-12-10 02:53:08 +08:00
|
|
|
* which is handled by the ioctl (DMA_BUF_IOCTL_SYNC). Note that
|
|
|
|
* DMA_BUF_IOCTL_SYNC can fail with -EAGAIN or -EINTR, in which case it must
|
|
|
|
* be restarted.
|
|
|
|
*
|
|
|
|
* Some systems might need some sort of cache coherency management e.g. when
|
|
|
|
* CPU and GPU domains are being accessed through dma-buf at the same time.
|
|
|
|
* To circumvent this problem there are begin/end coherency markers, that
|
|
|
|
* forward directly to existing dma-buf device drivers vfunc hooks. Userspace
|
|
|
|
* can make use of those markers through the DMA_BUF_IOCTL_SYNC ioctl. The
|
|
|
|
* sequence would be used like following:
|
|
|
|
*
|
|
|
|
* - mmap dma-buf fd
|
|
|
|
* - for each drawing/upload cycle in CPU 1. SYNC_START ioctl, 2. read/write
|
|
|
|
* to mmap area 3. SYNC_END ioctl. This can be repeated as often as you
|
|
|
|
* want (with the new data being consumed by say the GPU or the scanout
|
|
|
|
* device)
|
|
|
|
* - munmap once you don't need the buffer any more
|
|
|
|
*
|
|
|
|
* For correctness and optimal performance, it is always required to use
|
|
|
|
* SYNC_START and SYNC_END before and after, respectively, when accessing the
|
|
|
|
* mapped address. Userspace cannot rely on coherent access, even when there
|
|
|
|
* are systems where it just works without calling these ioctls.
|
|
|
|
*
|
|
|
|
* - And as a CPU fallback in userspace processing pipelines.
|
|
|
|
*
|
|
|
|
* Similar to the motivation for kernel cpu access it is again important that
|
|
|
|
* the userspace code of a given importing subsystem can use the same
|
|
|
|
* interfaces with a imported dma-buf buffer object as with a native buffer
|
|
|
|
* object. This is especially important for drm where the userspace part of
|
|
|
|
* contemporary OpenGL, X, and other drivers is huge, and reworking them to
|
|
|
|
* use a different way to mmap a buffer rather invasive.
|
|
|
|
*
|
|
|
|
* The assumption in the current dma-buf interfaces is that redirecting the
|
|
|
|
* initial mmap is all that's needed. A survey of some of the existing
|
|
|
|
* subsystems shows that no driver seems to do any nefarious thing like
|
|
|
|
* syncing up with outstanding asynchronous processing on the device or
|
|
|
|
* allocating special resources at fault time. So hopefully this is good
|
|
|
|
* enough, since adding interfaces to intercept pagefaults and allow pte
|
|
|
|
* shootdowns would increase the complexity quite a bit.
|
|
|
|
*
|
|
|
|
* Interface::
|
2020-12-11 23:58:41 +08:00
|
|
|
*
|
2016-12-10 02:53:08 +08:00
|
|
|
* int dma_buf_mmap(struct dma_buf \*, struct vm_area_struct \*,
|
|
|
|
* unsigned long);
|
|
|
|
*
|
|
|
|
* If the importing subsystem simply provides a special-purpose mmap call to
|
2020-12-11 23:58:41 +08:00
|
|
|
* set up a mapping in userspace, calling do_mmap with &dma_buf.file will
|
2016-12-10 02:53:08 +08:00
|
|
|
* equally achieve that for a dma-buf object.
|
|
|
|
*/
|
|
|
|
|
2016-08-15 23:42:18 +08:00
|
|
|
static int __dma_buf_begin_cpu_access(struct dma_buf *dmabuf,
|
|
|
|
enum dma_data_direction direction)
|
|
|
|
{
|
|
|
|
bool write = (direction == DMA_BIDIRECTIONAL ||
|
|
|
|
direction == DMA_TO_DEVICE);
|
2019-08-11 16:06:32 +08:00
|
|
|
struct dma_resv *resv = dmabuf->resv;
|
2016-08-15 23:42:18 +08:00
|
|
|
long ret;
|
|
|
|
|
|
|
|
/* Wait on any implicit rendering fences */
|
2021-11-09 18:08:18 +08:00
|
|
|
ret = dma_resv_wait_timeout(resv, dma_resv_usage_rw(write),
|
|
|
|
true, MAX_SCHEDULE_TIMEOUT);
|
2016-08-15 23:42:18 +08:00
|
|
|
if (ret < 0)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
2012-03-20 07:02:37 +08:00
|
|
|
|
|
|
|
/**
|
|
|
|
* dma_buf_begin_cpu_access - Must be called before accessing a dma_buf from the
|
|
|
|
* cpu in the kernel context. Calls begin_cpu_access to allow exporter-specific
|
|
|
|
* preparations. Coherency is only guaranteed in the specified range for the
|
|
|
|
* specified access direction.
|
2012-04-18 08:03:30 +08:00
|
|
|
* @dmabuf: [in] buffer to prepare cpu access for.
|
2022-11-24 03:35:18 +08:00
|
|
|
* @direction: [in] direction of access.
|
2012-03-20 07:02:37 +08:00
|
|
|
*
|
2016-12-10 02:53:08 +08:00
|
|
|
* After the cpu access is complete the caller should call
|
2022-11-24 03:35:18 +08:00
|
|
|
* dma_buf_end_cpu_access(). Only when cpu access is bracketed by both calls is
|
2016-12-10 02:53:08 +08:00
|
|
|
* it guaranteed to be coherent with other DMA access.
|
|
|
|
*
|
2020-12-11 23:58:40 +08:00
|
|
|
* This function will also wait for any DMA transactions tracked through
|
|
|
|
* implicit synchronization in &dma_buf.resv. For DMA transactions with explicit
|
|
|
|
* synchronization this function will only ensure cache coherency, callers must
|
|
|
|
* ensure synchronization with such DMA transactions on their own.
|
|
|
|
*
|
2012-03-20 07:02:37 +08:00
|
|
|
* Can return negative error values, returns 0 on success.
|
|
|
|
*/
|
2015-12-23 05:36:45 +08:00
|
|
|
int dma_buf_begin_cpu_access(struct dma_buf *dmabuf,
|
2012-03-20 07:02:37 +08:00
|
|
|
enum dma_data_direction direction)
|
|
|
|
{
|
|
|
|
int ret = 0;
|
|
|
|
|
|
|
|
if (WARN_ON(!dmabuf))
|
|
|
|
return -EINVAL;
|
|
|
|
|
2020-12-15 01:16:22 +08:00
|
|
|
might_lock(&dmabuf->resv->lock.base);
|
|
|
|
|
2012-03-20 07:02:37 +08:00
|
|
|
if (dmabuf->ops->begin_cpu_access)
|
2015-12-23 05:36:45 +08:00
|
|
|
ret = dmabuf->ops->begin_cpu_access(dmabuf, direction);
|
2012-03-20 07:02:37 +08:00
|
|
|
|
2016-08-15 23:42:18 +08:00
|
|
|
/* Ensure that all fences are waited upon - but we first allow
|
|
|
|
* the native handler the chance to do so more efficiently if it
|
|
|
|
* chooses. A double invocation here will be reasonably cheap no-op.
|
|
|
|
*/
|
|
|
|
if (ret == 0)
|
|
|
|
ret = __dma_buf_begin_cpu_access(dmabuf, direction);
|
|
|
|
|
2012-03-20 07:02:37 +08:00
|
|
|
return ret;
|
|
|
|
}
|
2021-10-10 20:46:28 +08:00
|
|
|
EXPORT_SYMBOL_NS_GPL(dma_buf_begin_cpu_access, DMA_BUF);
|
2012-03-20 07:02:37 +08:00
|
|
|
|
|
|
|
/**
|
|
|
|
* dma_buf_end_cpu_access - Must be called after accessing a dma_buf from the
|
|
|
|
* cpu in the kernel context. Calls end_cpu_access to allow exporter-specific
|
|
|
|
* actions. Coherency is only guaranteed in the specified range for the
|
|
|
|
* specified access direction.
|
2012-04-18 08:03:30 +08:00
|
|
|
* @dmabuf: [in] buffer to complete cpu access for.
|
2022-11-24 03:35:18 +08:00
|
|
|
* @direction: [in] direction of access.
|
2012-03-20 07:02:37 +08:00
|
|
|
*
|
2016-12-10 02:53:08 +08:00
|
|
|
* This terminates CPU access started with dma_buf_begin_cpu_access().
|
|
|
|
*
|
2016-03-21 15:24:22 +08:00
|
|
|
* Can return negative error values, returns 0 on success.
|
2012-03-20 07:02:37 +08:00
|
|
|
*/
|
dma-buf, drm, ion: Propagate error code from dma_buf_start_cpu_access()
Drivers, especially i915.ko, can fail during the initial migration of a
dma-buf for CPU access. However, the error code from the driver was not
being propagated back to ioctl and so userspace was blissfully ignorant
of the failure. Rendering corruption ensues.
Whilst fixing the ioctl to return the error code from
dma_buf_start_cpu_access(), also do the same for
dma_buf_end_cpu_access(). For most drivers, dma_buf_end_cpu_access()
cannot fail. i915.ko however, as most drivers would, wants to avoid being
uninterruptible (as would be required to guarrantee no failure when
flushing the buffer to the device). As userspace already has to handle
errors from the SYNC_IOCTL, take advantage of this to be able to restart
the syscall across signals.
This fixes a coherency issue for i915.ko as well as reducing the
uninterruptible hold upon its BKL, the struct_mutex.
Fixes commit c11e391da2a8fe973c3c2398452000bed505851e
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Thu Feb 11 20:04:51 2016 -0200
dma-buf: Add ioctls to allow userspace to flush
Testcase: igt/gem_concurrent_blit/*dmabuf*interruptible
Testcase: igt/prime_mmap_coherency/ioctl-errors
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tiago Vignatti <tiago.vignatti@intel.com>
Cc: Stéphane Marchesin <marcheu@chromium.org>
Cc: David Herrmann <dh.herrmann@gmail.com>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Cc: Daniel Vetter <daniel.vetter@intel.com>
CC: linux-media@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linaro-mm-sig@lists.linaro.org
Cc: intel-gfx@lists.freedesktop.org
Cc: devel@driverdev.osuosl.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1458331359-2634-1-git-send-email-chris@chris-wilson.co.uk
2016-03-19 04:02:39 +08:00
|
|
|
int dma_buf_end_cpu_access(struct dma_buf *dmabuf,
|
|
|
|
enum dma_data_direction direction)
|
2012-03-20 07:02:37 +08:00
|
|
|
{
|
dma-buf, drm, ion: Propagate error code from dma_buf_start_cpu_access()
Drivers, especially i915.ko, can fail during the initial migration of a
dma-buf for CPU access. However, the error code from the driver was not
being propagated back to ioctl and so userspace was blissfully ignorant
of the failure. Rendering corruption ensues.
Whilst fixing the ioctl to return the error code from
dma_buf_start_cpu_access(), also do the same for
dma_buf_end_cpu_access(). For most drivers, dma_buf_end_cpu_access()
cannot fail. i915.ko however, as most drivers would, wants to avoid being
uninterruptible (as would be required to guarrantee no failure when
flushing the buffer to the device). As userspace already has to handle
errors from the SYNC_IOCTL, take advantage of this to be able to restart
the syscall across signals.
This fixes a coherency issue for i915.ko as well as reducing the
uninterruptible hold upon its BKL, the struct_mutex.
Fixes commit c11e391da2a8fe973c3c2398452000bed505851e
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Thu Feb 11 20:04:51 2016 -0200
dma-buf: Add ioctls to allow userspace to flush
Testcase: igt/gem_concurrent_blit/*dmabuf*interruptible
Testcase: igt/prime_mmap_coherency/ioctl-errors
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tiago Vignatti <tiago.vignatti@intel.com>
Cc: Stéphane Marchesin <marcheu@chromium.org>
Cc: David Herrmann <dh.herrmann@gmail.com>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Cc: Daniel Vetter <daniel.vetter@intel.com>
CC: linux-media@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linaro-mm-sig@lists.linaro.org
Cc: intel-gfx@lists.freedesktop.org
Cc: devel@driverdev.osuosl.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1458331359-2634-1-git-send-email-chris@chris-wilson.co.uk
2016-03-19 04:02:39 +08:00
|
|
|
int ret = 0;
|
|
|
|
|
2012-03-20 07:02:37 +08:00
|
|
|
WARN_ON(!dmabuf);
|
|
|
|
|
2020-12-15 01:16:22 +08:00
|
|
|
might_lock(&dmabuf->resv->lock.base);
|
|
|
|
|
2012-03-20 07:02:37 +08:00
|
|
|
if (dmabuf->ops->end_cpu_access)
|
dma-buf, drm, ion: Propagate error code from dma_buf_start_cpu_access()
Drivers, especially i915.ko, can fail during the initial migration of a
dma-buf for CPU access. However, the error code from the driver was not
being propagated back to ioctl and so userspace was blissfully ignorant
of the failure. Rendering corruption ensues.
Whilst fixing the ioctl to return the error code from
dma_buf_start_cpu_access(), also do the same for
dma_buf_end_cpu_access(). For most drivers, dma_buf_end_cpu_access()
cannot fail. i915.ko however, as most drivers would, wants to avoid being
uninterruptible (as would be required to guarrantee no failure when
flushing the buffer to the device). As userspace already has to handle
errors from the SYNC_IOCTL, take advantage of this to be able to restart
the syscall across signals.
This fixes a coherency issue for i915.ko as well as reducing the
uninterruptible hold upon its BKL, the struct_mutex.
Fixes commit c11e391da2a8fe973c3c2398452000bed505851e
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Thu Feb 11 20:04:51 2016 -0200
dma-buf: Add ioctls to allow userspace to flush
Testcase: igt/gem_concurrent_blit/*dmabuf*interruptible
Testcase: igt/prime_mmap_coherency/ioctl-errors
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tiago Vignatti <tiago.vignatti@intel.com>
Cc: Stéphane Marchesin <marcheu@chromium.org>
Cc: David Herrmann <dh.herrmann@gmail.com>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Cc: Daniel Vetter <daniel.vetter@intel.com>
CC: linux-media@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linaro-mm-sig@lists.linaro.org
Cc: intel-gfx@lists.freedesktop.org
Cc: devel@driverdev.osuosl.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1458331359-2634-1-git-send-email-chris@chris-wilson.co.uk
2016-03-19 04:02:39 +08:00
|
|
|
ret = dmabuf->ops->end_cpu_access(dmabuf, direction);
|
|
|
|
|
|
|
|
return ret;
|
2012-03-20 07:02:37 +08:00
|
|
|
}
|
2021-10-10 20:46:28 +08:00
|
|
|
EXPORT_SYMBOL_NS_GPL(dma_buf_end_cpu_access, DMA_BUF);
|
2012-03-20 07:02:37 +08:00
|
|
|
|
dma-buf: mmap support
Compared to Rob Clark's RFC I've ditched the prepare/finish hooks
and corresponding ioctls on the dma_buf file. The major reason for
that is that many people seem to be under the impression that this is
also for synchronization with outstanding asynchronous processsing.
I'm pretty massively opposed to this because:
- It boils down reinventing a new rather general-purpose userspace
synchronization interface. If we look at things like futexes, this
is hard to get right.
- Furthermore a lot of kernel code has to interact with this
synchronization primitive. This smells a look like the dri1 hw_lock,
a horror show I prefer not to reinvent.
- Even more fun is that multiple different subsystems would interact
here, so we have plenty of opportunities to create funny deadlock
scenarios.
I think synchronization is a wholesale different problem from data
sharing and should be tackled as an orthogonal problem.
Now we could demand that prepare/finish may only ensure cache
coherency (as Rob intended), but that runs up into the next problem:
We not only need mmap support to facilitate sw-only processing nodes
in a pipeline (without jumping through hoops by importing the dma_buf
into some sw-access only importer), which allows for a nicer
ION->dma-buf upgrade path for existing Android userspace. We also need
mmap support for existing importing subsystems to support existing
userspace libraries. And a loot of these subsystems are expected to
export coherent userspace mappings.
So prepare/finish can only ever be optional and the exporter /needs/
to support coherent mappings. Given that mmap access is always
somewhat fallback-y in nature I've decided to drop this optimization,
instead of just making it optional. If we demonstrate a clear need for
this, supported by benchmark results, we can always add it in again
later as an optional extension.
Other differences compared to Rob's RFC is the above mentioned support
for mapping a dma-buf through facilities provided by the importer.
Which results in mmap support no longer being optional.
Note that this dma-buf mmap patch does _not_ support every possible
insanity an existing subsystem could pull of with mmap: Because it
does not allow to intercept pagefaults and shoot down ptes importing
subsystems can't add some magic of their own at these points (e.g. to
automatically synchronize with outstanding rendering or set up some
special resources). I've done a cursory read through a few mmap
implementions of various subsytems and I'm hopeful that we can avoid
this (and the complexity it'd bring with it).
Additonally I've extended the documentation a bit to explain the hows
and whys of this mmap extension.
In case we ever want to add support for explicitly cache maneged
userspace mmap with a prepare/finish ioctl pair, we could specify that
userspace needs to mmap a different part of the dma_buf, e.g. the
range starting at dma_buf->size up to dma_buf->size*2. This works
because the size of a dma_buf is invariant over it's lifetime. The
exporter would obviously need to fall back to coherent mappings for
both ranges if a legacy clients maps the coherent range and the
architecture cannot suppor conflicting caching policies. Also, this
would obviously be optional and userspace needs to be able to fall
back to coherent mappings.
v2:
- Spelling fixes from Rob Clark.
- Compile fix for !DMA_BUF from Rob Clark.
- Extend commit message to explain how explicitly cache managed mmap
support could be added later.
- Extend the documentation with implementations notes for exporters
that need to manually fake coherency.
v3:
- dma_buf pointer initialization goof-up noticed by Rebecca Schultz
Zavin.
Cc: Rob Clark <rob.clark@linaro.org>
Cc: Rebecca Schultz Zavin <rebecca@android.com>
Acked-by: Rob Clark <rob.clark@linaro.org>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
2012-04-24 17:08:52 +08:00
|
|
|
|
|
|
|
/**
|
|
|
|
* dma_buf_mmap - Setup up a userspace mmap with the given vma
|
2012-05-23 17:57:40 +08:00
|
|
|
* @dmabuf: [in] buffer that should back the vma
|
dma-buf: mmap support
Compared to Rob Clark's RFC I've ditched the prepare/finish hooks
and corresponding ioctls on the dma_buf file. The major reason for
that is that many people seem to be under the impression that this is
also for synchronization with outstanding asynchronous processsing.
I'm pretty massively opposed to this because:
- It boils down reinventing a new rather general-purpose userspace
synchronization interface. If we look at things like futexes, this
is hard to get right.
- Furthermore a lot of kernel code has to interact with this
synchronization primitive. This smells a look like the dri1 hw_lock,
a horror show I prefer not to reinvent.
- Even more fun is that multiple different subsystems would interact
here, so we have plenty of opportunities to create funny deadlock
scenarios.
I think synchronization is a wholesale different problem from data
sharing and should be tackled as an orthogonal problem.
Now we could demand that prepare/finish may only ensure cache
coherency (as Rob intended), but that runs up into the next problem:
We not only need mmap support to facilitate sw-only processing nodes
in a pipeline (without jumping through hoops by importing the dma_buf
into some sw-access only importer), which allows for a nicer
ION->dma-buf upgrade path for existing Android userspace. We also need
mmap support for existing importing subsystems to support existing
userspace libraries. And a loot of these subsystems are expected to
export coherent userspace mappings.
So prepare/finish can only ever be optional and the exporter /needs/
to support coherent mappings. Given that mmap access is always
somewhat fallback-y in nature I've decided to drop this optimization,
instead of just making it optional. If we demonstrate a clear need for
this, supported by benchmark results, we can always add it in again
later as an optional extension.
Other differences compared to Rob's RFC is the above mentioned support
for mapping a dma-buf through facilities provided by the importer.
Which results in mmap support no longer being optional.
Note that this dma-buf mmap patch does _not_ support every possible
insanity an existing subsystem could pull of with mmap: Because it
does not allow to intercept pagefaults and shoot down ptes importing
subsystems can't add some magic of their own at these points (e.g. to
automatically synchronize with outstanding rendering or set up some
special resources). I've done a cursory read through a few mmap
implementions of various subsytems and I'm hopeful that we can avoid
this (and the complexity it'd bring with it).
Additonally I've extended the documentation a bit to explain the hows
and whys of this mmap extension.
In case we ever want to add support for explicitly cache maneged
userspace mmap with a prepare/finish ioctl pair, we could specify that
userspace needs to mmap a different part of the dma_buf, e.g. the
range starting at dma_buf->size up to dma_buf->size*2. This works
because the size of a dma_buf is invariant over it's lifetime. The
exporter would obviously need to fall back to coherent mappings for
both ranges if a legacy clients maps the coherent range and the
architecture cannot suppor conflicting caching policies. Also, this
would obviously be optional and userspace needs to be able to fall
back to coherent mappings.
v2:
- Spelling fixes from Rob Clark.
- Compile fix for !DMA_BUF from Rob Clark.
- Extend commit message to explain how explicitly cache managed mmap
support could be added later.
- Extend the documentation with implementations notes for exporters
that need to manually fake coherency.
v3:
- dma_buf pointer initialization goof-up noticed by Rebecca Schultz
Zavin.
Cc: Rob Clark <rob.clark@linaro.org>
Cc: Rebecca Schultz Zavin <rebecca@android.com>
Acked-by: Rob Clark <rob.clark@linaro.org>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
2012-04-24 17:08:52 +08:00
|
|
|
* @vma: [in] vma for the mmap
|
|
|
|
* @pgoff: [in] offset in pages where this mmap should start within the
|
2015-05-21 03:39:31 +08:00
|
|
|
* dma-buf buffer.
|
dma-buf: mmap support
Compared to Rob Clark's RFC I've ditched the prepare/finish hooks
and corresponding ioctls on the dma_buf file. The major reason for
that is that many people seem to be under the impression that this is
also for synchronization with outstanding asynchronous processsing.
I'm pretty massively opposed to this because:
- It boils down reinventing a new rather general-purpose userspace
synchronization interface. If we look at things like futexes, this
is hard to get right.
- Furthermore a lot of kernel code has to interact with this
synchronization primitive. This smells a look like the dri1 hw_lock,
a horror show I prefer not to reinvent.
- Even more fun is that multiple different subsystems would interact
here, so we have plenty of opportunities to create funny deadlock
scenarios.
I think synchronization is a wholesale different problem from data
sharing and should be tackled as an orthogonal problem.
Now we could demand that prepare/finish may only ensure cache
coherency (as Rob intended), but that runs up into the next problem:
We not only need mmap support to facilitate sw-only processing nodes
in a pipeline (without jumping through hoops by importing the dma_buf
into some sw-access only importer), which allows for a nicer
ION->dma-buf upgrade path for existing Android userspace. We also need
mmap support for existing importing subsystems to support existing
userspace libraries. And a loot of these subsystems are expected to
export coherent userspace mappings.
So prepare/finish can only ever be optional and the exporter /needs/
to support coherent mappings. Given that mmap access is always
somewhat fallback-y in nature I've decided to drop this optimization,
instead of just making it optional. If we demonstrate a clear need for
this, supported by benchmark results, we can always add it in again
later as an optional extension.
Other differences compared to Rob's RFC is the above mentioned support
for mapping a dma-buf through facilities provided by the importer.
Which results in mmap support no longer being optional.
Note that this dma-buf mmap patch does _not_ support every possible
insanity an existing subsystem could pull of with mmap: Because it
does not allow to intercept pagefaults and shoot down ptes importing
subsystems can't add some magic of their own at these points (e.g. to
automatically synchronize with outstanding rendering or set up some
special resources). I've done a cursory read through a few mmap
implementions of various subsytems and I'm hopeful that we can avoid
this (and the complexity it'd bring with it).
Additonally I've extended the documentation a bit to explain the hows
and whys of this mmap extension.
In case we ever want to add support for explicitly cache maneged
userspace mmap with a prepare/finish ioctl pair, we could specify that
userspace needs to mmap a different part of the dma_buf, e.g. the
range starting at dma_buf->size up to dma_buf->size*2. This works
because the size of a dma_buf is invariant over it's lifetime. The
exporter would obviously need to fall back to coherent mappings for
both ranges if a legacy clients maps the coherent range and the
architecture cannot suppor conflicting caching policies. Also, this
would obviously be optional and userspace needs to be able to fall
back to coherent mappings.
v2:
- Spelling fixes from Rob Clark.
- Compile fix for !DMA_BUF from Rob Clark.
- Extend commit message to explain how explicitly cache managed mmap
support could be added later.
- Extend the documentation with implementations notes for exporters
that need to manually fake coherency.
v3:
- dma_buf pointer initialization goof-up noticed by Rebecca Schultz
Zavin.
Cc: Rob Clark <rob.clark@linaro.org>
Cc: Rebecca Schultz Zavin <rebecca@android.com>
Acked-by: Rob Clark <rob.clark@linaro.org>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
2012-04-24 17:08:52 +08:00
|
|
|
*
|
|
|
|
* This function adjusts the passed in vma so that it points at the file of the
|
2014-04-10 07:30:05 +08:00
|
|
|
* dma_buf operation. It also adjusts the starting pgoff and does bounds
|
dma-buf: mmap support
Compared to Rob Clark's RFC I've ditched the prepare/finish hooks
and corresponding ioctls on the dma_buf file. The major reason for
that is that many people seem to be under the impression that this is
also for synchronization with outstanding asynchronous processsing.
I'm pretty massively opposed to this because:
- It boils down reinventing a new rather general-purpose userspace
synchronization interface. If we look at things like futexes, this
is hard to get right.
- Furthermore a lot of kernel code has to interact with this
synchronization primitive. This smells a look like the dri1 hw_lock,
a horror show I prefer not to reinvent.
- Even more fun is that multiple different subsystems would interact
here, so we have plenty of opportunities to create funny deadlock
scenarios.
I think synchronization is a wholesale different problem from data
sharing and should be tackled as an orthogonal problem.
Now we could demand that prepare/finish may only ensure cache
coherency (as Rob intended), but that runs up into the next problem:
We not only need mmap support to facilitate sw-only processing nodes
in a pipeline (without jumping through hoops by importing the dma_buf
into some sw-access only importer), which allows for a nicer
ION->dma-buf upgrade path for existing Android userspace. We also need
mmap support for existing importing subsystems to support existing
userspace libraries. And a loot of these subsystems are expected to
export coherent userspace mappings.
So prepare/finish can only ever be optional and the exporter /needs/
to support coherent mappings. Given that mmap access is always
somewhat fallback-y in nature I've decided to drop this optimization,
instead of just making it optional. If we demonstrate a clear need for
this, supported by benchmark results, we can always add it in again
later as an optional extension.
Other differences compared to Rob's RFC is the above mentioned support
for mapping a dma-buf through facilities provided by the importer.
Which results in mmap support no longer being optional.
Note that this dma-buf mmap patch does _not_ support every possible
insanity an existing subsystem could pull of with mmap: Because it
does not allow to intercept pagefaults and shoot down ptes importing
subsystems can't add some magic of their own at these points (e.g. to
automatically synchronize with outstanding rendering or set up some
special resources). I've done a cursory read through a few mmap
implementions of various subsytems and I'm hopeful that we can avoid
this (and the complexity it'd bring with it).
Additonally I've extended the documentation a bit to explain the hows
and whys of this mmap extension.
In case we ever want to add support for explicitly cache maneged
userspace mmap with a prepare/finish ioctl pair, we could specify that
userspace needs to mmap a different part of the dma_buf, e.g. the
range starting at dma_buf->size up to dma_buf->size*2. This works
because the size of a dma_buf is invariant over it's lifetime. The
exporter would obviously need to fall back to coherent mappings for
both ranges if a legacy clients maps the coherent range and the
architecture cannot suppor conflicting caching policies. Also, this
would obviously be optional and userspace needs to be able to fall
back to coherent mappings.
v2:
- Spelling fixes from Rob Clark.
- Compile fix for !DMA_BUF from Rob Clark.
- Extend commit message to explain how explicitly cache managed mmap
support could be added later.
- Extend the documentation with implementations notes for exporters
that need to manually fake coherency.
v3:
- dma_buf pointer initialization goof-up noticed by Rebecca Schultz
Zavin.
Cc: Rob Clark <rob.clark@linaro.org>
Cc: Rebecca Schultz Zavin <rebecca@android.com>
Acked-by: Rob Clark <rob.clark@linaro.org>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
2012-04-24 17:08:52 +08:00
|
|
|
* checking on the size of the vma. Then it calls the exporters mmap function to
|
|
|
|
* set up the mapping.
|
|
|
|
*
|
|
|
|
* Can return negative error values, returns 0 on success.
|
|
|
|
*/
|
|
|
|
int dma_buf_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma,
|
|
|
|
unsigned long pgoff)
|
|
|
|
{
|
|
|
|
if (WARN_ON(!dmabuf || !vma))
|
|
|
|
return -EINVAL;
|
|
|
|
|
2019-03-30 00:52:01 +08:00
|
|
|
/* check if buffer supports mmap */
|
|
|
|
if (!dmabuf->ops->mmap)
|
|
|
|
return -EINVAL;
|
|
|
|
|
dma-buf: mmap support
Compared to Rob Clark's RFC I've ditched the prepare/finish hooks
and corresponding ioctls on the dma_buf file. The major reason for
that is that many people seem to be under the impression that this is
also for synchronization with outstanding asynchronous processsing.
I'm pretty massively opposed to this because:
- It boils down reinventing a new rather general-purpose userspace
synchronization interface. If we look at things like futexes, this
is hard to get right.
- Furthermore a lot of kernel code has to interact with this
synchronization primitive. This smells a look like the dri1 hw_lock,
a horror show I prefer not to reinvent.
- Even more fun is that multiple different subsystems would interact
here, so we have plenty of opportunities to create funny deadlock
scenarios.
I think synchronization is a wholesale different problem from data
sharing and should be tackled as an orthogonal problem.
Now we could demand that prepare/finish may only ensure cache
coherency (as Rob intended), but that runs up into the next problem:
We not only need mmap support to facilitate sw-only processing nodes
in a pipeline (without jumping through hoops by importing the dma_buf
into some sw-access only importer), which allows for a nicer
ION->dma-buf upgrade path for existing Android userspace. We also need
mmap support for existing importing subsystems to support existing
userspace libraries. And a loot of these subsystems are expected to
export coherent userspace mappings.
So prepare/finish can only ever be optional and the exporter /needs/
to support coherent mappings. Given that mmap access is always
somewhat fallback-y in nature I've decided to drop this optimization,
instead of just making it optional. If we demonstrate a clear need for
this, supported by benchmark results, we can always add it in again
later as an optional extension.
Other differences compared to Rob's RFC is the above mentioned support
for mapping a dma-buf through facilities provided by the importer.
Which results in mmap support no longer being optional.
Note that this dma-buf mmap patch does _not_ support every possible
insanity an existing subsystem could pull of with mmap: Because it
does not allow to intercept pagefaults and shoot down ptes importing
subsystems can't add some magic of their own at these points (e.g. to
automatically synchronize with outstanding rendering or set up some
special resources). I've done a cursory read through a few mmap
implementions of various subsytems and I'm hopeful that we can avoid
this (and the complexity it'd bring with it).
Additonally I've extended the documentation a bit to explain the hows
and whys of this mmap extension.
In case we ever want to add support for explicitly cache maneged
userspace mmap with a prepare/finish ioctl pair, we could specify that
userspace needs to mmap a different part of the dma_buf, e.g. the
range starting at dma_buf->size up to dma_buf->size*2. This works
because the size of a dma_buf is invariant over it's lifetime. The
exporter would obviously need to fall back to coherent mappings for
both ranges if a legacy clients maps the coherent range and the
architecture cannot suppor conflicting caching policies. Also, this
would obviously be optional and userspace needs to be able to fall
back to coherent mappings.
v2:
- Spelling fixes from Rob Clark.
- Compile fix for !DMA_BUF from Rob Clark.
- Extend commit message to explain how explicitly cache managed mmap
support could be added later.
- Extend the documentation with implementations notes for exporters
that need to manually fake coherency.
v3:
- dma_buf pointer initialization goof-up noticed by Rebecca Schultz
Zavin.
Cc: Rob Clark <rob.clark@linaro.org>
Cc: Rebecca Schultz Zavin <rebecca@android.com>
Acked-by: Rob Clark <rob.clark@linaro.org>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
2012-04-24 17:08:52 +08:00
|
|
|
/* check for offset overflow */
|
2016-05-23 19:38:42 +08:00
|
|
|
if (pgoff + vma_pages(vma) < pgoff)
|
dma-buf: mmap support
Compared to Rob Clark's RFC I've ditched the prepare/finish hooks
and corresponding ioctls on the dma_buf file. The major reason for
that is that many people seem to be under the impression that this is
also for synchronization with outstanding asynchronous processsing.
I'm pretty massively opposed to this because:
- It boils down reinventing a new rather general-purpose userspace
synchronization interface. If we look at things like futexes, this
is hard to get right.
- Furthermore a lot of kernel code has to interact with this
synchronization primitive. This smells a look like the dri1 hw_lock,
a horror show I prefer not to reinvent.
- Even more fun is that multiple different subsystems would interact
here, so we have plenty of opportunities to create funny deadlock
scenarios.
I think synchronization is a wholesale different problem from data
sharing and should be tackled as an orthogonal problem.
Now we could demand that prepare/finish may only ensure cache
coherency (as Rob intended), but that runs up into the next problem:
We not only need mmap support to facilitate sw-only processing nodes
in a pipeline (without jumping through hoops by importing the dma_buf
into some sw-access only importer), which allows for a nicer
ION->dma-buf upgrade path for existing Android userspace. We also need
mmap support for existing importing subsystems to support existing
userspace libraries. And a loot of these subsystems are expected to
export coherent userspace mappings.
So prepare/finish can only ever be optional and the exporter /needs/
to support coherent mappings. Given that mmap access is always
somewhat fallback-y in nature I've decided to drop this optimization,
instead of just making it optional. If we demonstrate a clear need for
this, supported by benchmark results, we can always add it in again
later as an optional extension.
Other differences compared to Rob's RFC is the above mentioned support
for mapping a dma-buf through facilities provided by the importer.
Which results in mmap support no longer being optional.
Note that this dma-buf mmap patch does _not_ support every possible
insanity an existing subsystem could pull of with mmap: Because it
does not allow to intercept pagefaults and shoot down ptes importing
subsystems can't add some magic of their own at these points (e.g. to
automatically synchronize with outstanding rendering or set up some
special resources). I've done a cursory read through a few mmap
implementions of various subsytems and I'm hopeful that we can avoid
this (and the complexity it'd bring with it).
Additonally I've extended the documentation a bit to explain the hows
and whys of this mmap extension.
In case we ever want to add support for explicitly cache maneged
userspace mmap with a prepare/finish ioctl pair, we could specify that
userspace needs to mmap a different part of the dma_buf, e.g. the
range starting at dma_buf->size up to dma_buf->size*2. This works
because the size of a dma_buf is invariant over it's lifetime. The
exporter would obviously need to fall back to coherent mappings for
both ranges if a legacy clients maps the coherent range and the
architecture cannot suppor conflicting caching policies. Also, this
would obviously be optional and userspace needs to be able to fall
back to coherent mappings.
v2:
- Spelling fixes from Rob Clark.
- Compile fix for !DMA_BUF from Rob Clark.
- Extend commit message to explain how explicitly cache managed mmap
support could be added later.
- Extend the documentation with implementations notes for exporters
that need to manually fake coherency.
v3:
- dma_buf pointer initialization goof-up noticed by Rebecca Schultz
Zavin.
Cc: Rob Clark <rob.clark@linaro.org>
Cc: Rebecca Schultz Zavin <rebecca@android.com>
Acked-by: Rob Clark <rob.clark@linaro.org>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
2012-04-24 17:08:52 +08:00
|
|
|
return -EOVERFLOW;
|
|
|
|
|
|
|
|
/* check for overflowing the buffer's size */
|
2016-05-23 19:38:42 +08:00
|
|
|
if (pgoff + vma_pages(vma) >
|
dma-buf: mmap support
Compared to Rob Clark's RFC I've ditched the prepare/finish hooks
and corresponding ioctls on the dma_buf file. The major reason for
that is that many people seem to be under the impression that this is
also for synchronization with outstanding asynchronous processsing.
I'm pretty massively opposed to this because:
- It boils down reinventing a new rather general-purpose userspace
synchronization interface. If we look at things like futexes, this
is hard to get right.
- Furthermore a lot of kernel code has to interact with this
synchronization primitive. This smells a look like the dri1 hw_lock,
a horror show I prefer not to reinvent.
- Even more fun is that multiple different subsystems would interact
here, so we have plenty of opportunities to create funny deadlock
scenarios.
I think synchronization is a wholesale different problem from data
sharing and should be tackled as an orthogonal problem.
Now we could demand that prepare/finish may only ensure cache
coherency (as Rob intended), but that runs up into the next problem:
We not only need mmap support to facilitate sw-only processing nodes
in a pipeline (without jumping through hoops by importing the dma_buf
into some sw-access only importer), which allows for a nicer
ION->dma-buf upgrade path for existing Android userspace. We also need
mmap support for existing importing subsystems to support existing
userspace libraries. And a loot of these subsystems are expected to
export coherent userspace mappings.
So prepare/finish can only ever be optional and the exporter /needs/
to support coherent mappings. Given that mmap access is always
somewhat fallback-y in nature I've decided to drop this optimization,
instead of just making it optional. If we demonstrate a clear need for
this, supported by benchmark results, we can always add it in again
later as an optional extension.
Other differences compared to Rob's RFC is the above mentioned support
for mapping a dma-buf through facilities provided by the importer.
Which results in mmap support no longer being optional.
Note that this dma-buf mmap patch does _not_ support every possible
insanity an existing subsystem could pull of with mmap: Because it
does not allow to intercept pagefaults and shoot down ptes importing
subsystems can't add some magic of their own at these points (e.g. to
automatically synchronize with outstanding rendering or set up some
special resources). I've done a cursory read through a few mmap
implementions of various subsytems and I'm hopeful that we can avoid
this (and the complexity it'd bring with it).
Additonally I've extended the documentation a bit to explain the hows
and whys of this mmap extension.
In case we ever want to add support for explicitly cache maneged
userspace mmap with a prepare/finish ioctl pair, we could specify that
userspace needs to mmap a different part of the dma_buf, e.g. the
range starting at dma_buf->size up to dma_buf->size*2. This works
because the size of a dma_buf is invariant over it's lifetime. The
exporter would obviously need to fall back to coherent mappings for
both ranges if a legacy clients maps the coherent range and the
architecture cannot suppor conflicting caching policies. Also, this
would obviously be optional and userspace needs to be able to fall
back to coherent mappings.
v2:
- Spelling fixes from Rob Clark.
- Compile fix for !DMA_BUF from Rob Clark.
- Extend commit message to explain how explicitly cache managed mmap
support could be added later.
- Extend the documentation with implementations notes for exporters
that need to manually fake coherency.
v3:
- dma_buf pointer initialization goof-up noticed by Rebecca Schultz
Zavin.
Cc: Rob Clark <rob.clark@linaro.org>
Cc: Rebecca Schultz Zavin <rebecca@android.com>
Acked-by: Rob Clark <rob.clark@linaro.org>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
2012-04-24 17:08:52 +08:00
|
|
|
dmabuf->size >> PAGE_SHIFT)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
/* readjust the vma */
|
2020-09-14 21:09:33 +08:00
|
|
|
vma_set_file(vma, dmabuf->file);
|
dma-buf: mmap support
Compared to Rob Clark's RFC I've ditched the prepare/finish hooks
and corresponding ioctls on the dma_buf file. The major reason for
that is that many people seem to be under the impression that this is
also for synchronization with outstanding asynchronous processsing.
I'm pretty massively opposed to this because:
- It boils down reinventing a new rather general-purpose userspace
synchronization interface. If we look at things like futexes, this
is hard to get right.
- Furthermore a lot of kernel code has to interact with this
synchronization primitive. This smells a look like the dri1 hw_lock,
a horror show I prefer not to reinvent.
- Even more fun is that multiple different subsystems would interact
here, so we have plenty of opportunities to create funny deadlock
scenarios.
I think synchronization is a wholesale different problem from data
sharing and should be tackled as an orthogonal problem.
Now we could demand that prepare/finish may only ensure cache
coherency (as Rob intended), but that runs up into the next problem:
We not only need mmap support to facilitate sw-only processing nodes
in a pipeline (without jumping through hoops by importing the dma_buf
into some sw-access only importer), which allows for a nicer
ION->dma-buf upgrade path for existing Android userspace. We also need
mmap support for existing importing subsystems to support existing
userspace libraries. And a loot of these subsystems are expected to
export coherent userspace mappings.
So prepare/finish can only ever be optional and the exporter /needs/
to support coherent mappings. Given that mmap access is always
somewhat fallback-y in nature I've decided to drop this optimization,
instead of just making it optional. If we demonstrate a clear need for
this, supported by benchmark results, we can always add it in again
later as an optional extension.
Other differences compared to Rob's RFC is the above mentioned support
for mapping a dma-buf through facilities provided by the importer.
Which results in mmap support no longer being optional.
Note that this dma-buf mmap patch does _not_ support every possible
insanity an existing subsystem could pull of with mmap: Because it
does not allow to intercept pagefaults and shoot down ptes importing
subsystems can't add some magic of their own at these points (e.g. to
automatically synchronize with outstanding rendering or set up some
special resources). I've done a cursory read through a few mmap
implementions of various subsytems and I'm hopeful that we can avoid
this (and the complexity it'd bring with it).
Additonally I've extended the documentation a bit to explain the hows
and whys of this mmap extension.
In case we ever want to add support for explicitly cache maneged
userspace mmap with a prepare/finish ioctl pair, we could specify that
userspace needs to mmap a different part of the dma_buf, e.g. the
range starting at dma_buf->size up to dma_buf->size*2. This works
because the size of a dma_buf is invariant over it's lifetime. The
exporter would obviously need to fall back to coherent mappings for
both ranges if a legacy clients maps the coherent range and the
architecture cannot suppor conflicting caching policies. Also, this
would obviously be optional and userspace needs to be able to fall
back to coherent mappings.
v2:
- Spelling fixes from Rob Clark.
- Compile fix for !DMA_BUF from Rob Clark.
- Extend commit message to explain how explicitly cache managed mmap
support could be added later.
- Extend the documentation with implementations notes for exporters
that need to manually fake coherency.
v3:
- dma_buf pointer initialization goof-up noticed by Rebecca Schultz
Zavin.
Cc: Rob Clark <rob.clark@linaro.org>
Cc: Rebecca Schultz Zavin <rebecca@android.com>
Acked-by: Rob Clark <rob.clark@linaro.org>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
2012-04-24 17:08:52 +08:00
|
|
|
vma->vm_pgoff = pgoff;
|
|
|
|
|
2023-05-30 06:39:34 +08:00
|
|
|
return dmabuf->ops->mmap(dmabuf, vma);
|
dma-buf: mmap support
Compared to Rob Clark's RFC I've ditched the prepare/finish hooks
and corresponding ioctls on the dma_buf file. The major reason for
that is that many people seem to be under the impression that this is
also for synchronization with outstanding asynchronous processsing.
I'm pretty massively opposed to this because:
- It boils down reinventing a new rather general-purpose userspace
synchronization interface. If we look at things like futexes, this
is hard to get right.
- Furthermore a lot of kernel code has to interact with this
synchronization primitive. This smells a look like the dri1 hw_lock,
a horror show I prefer not to reinvent.
- Even more fun is that multiple different subsystems would interact
here, so we have plenty of opportunities to create funny deadlock
scenarios.
I think synchronization is a wholesale different problem from data
sharing and should be tackled as an orthogonal problem.
Now we could demand that prepare/finish may only ensure cache
coherency (as Rob intended), but that runs up into the next problem:
We not only need mmap support to facilitate sw-only processing nodes
in a pipeline (without jumping through hoops by importing the dma_buf
into some sw-access only importer), which allows for a nicer
ION->dma-buf upgrade path for existing Android userspace. We also need
mmap support for existing importing subsystems to support existing
userspace libraries. And a loot of these subsystems are expected to
export coherent userspace mappings.
So prepare/finish can only ever be optional and the exporter /needs/
to support coherent mappings. Given that mmap access is always
somewhat fallback-y in nature I've decided to drop this optimization,
instead of just making it optional. If we demonstrate a clear need for
this, supported by benchmark results, we can always add it in again
later as an optional extension.
Other differences compared to Rob's RFC is the above mentioned support
for mapping a dma-buf through facilities provided by the importer.
Which results in mmap support no longer being optional.
Note that this dma-buf mmap patch does _not_ support every possible
insanity an existing subsystem could pull of with mmap: Because it
does not allow to intercept pagefaults and shoot down ptes importing
subsystems can't add some magic of their own at these points (e.g. to
automatically synchronize with outstanding rendering or set up some
special resources). I've done a cursory read through a few mmap
implementions of various subsytems and I'm hopeful that we can avoid
this (and the complexity it'd bring with it).
Additonally I've extended the documentation a bit to explain the hows
and whys of this mmap extension.
In case we ever want to add support for explicitly cache maneged
userspace mmap with a prepare/finish ioctl pair, we could specify that
userspace needs to mmap a different part of the dma_buf, e.g. the
range starting at dma_buf->size up to dma_buf->size*2. This works
because the size of a dma_buf is invariant over it's lifetime. The
exporter would obviously need to fall back to coherent mappings for
both ranges if a legacy clients maps the coherent range and the
architecture cannot suppor conflicting caching policies. Also, this
would obviously be optional and userspace needs to be able to fall
back to coherent mappings.
v2:
- Spelling fixes from Rob Clark.
- Compile fix for !DMA_BUF from Rob Clark.
- Extend commit message to explain how explicitly cache managed mmap
support could be added later.
- Extend the documentation with implementations notes for exporters
that need to manually fake coherency.
v3:
- dma_buf pointer initialization goof-up noticed by Rebecca Schultz
Zavin.
Cc: Rob Clark <rob.clark@linaro.org>
Cc: Rebecca Schultz Zavin <rebecca@android.com>
Acked-by: Rob Clark <rob.clark@linaro.org>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
2012-04-24 17:08:52 +08:00
|
|
|
}
|
2021-10-10 20:46:28 +08:00
|
|
|
EXPORT_SYMBOL_NS_GPL(dma_buf_mmap, DMA_BUF);
|
2012-05-20 15:03:56 +08:00
|
|
|
|
|
|
|
/**
|
2012-05-23 17:57:40 +08:00
|
|
|
* dma_buf_vmap - Create virtual mapping for the buffer object into kernel
|
|
|
|
* address space. Same restrictions as for vmap and friends apply.
|
|
|
|
* @dmabuf: [in] buffer to vmap
|
2020-09-25 19:55:59 +08:00
|
|
|
* @map: [out] returns the vmap pointer
|
2012-05-20 15:03:56 +08:00
|
|
|
*
|
|
|
|
* This call may fail due to lack of virtual mapping address space.
|
|
|
|
* These calls are optional in drivers. The intended use for them
|
|
|
|
* is for mapping objects linear in kernel space for high use objects.
|
2020-12-11 23:58:40 +08:00
|
|
|
*
|
|
|
|
* To ensure coherency users must call dma_buf_begin_cpu_access() and
|
|
|
|
* dma_buf_end_cpu_access() around any cpu access performed through this
|
|
|
|
* mapping.
|
2013-12-21 08:43:50 +08:00
|
|
|
*
|
2020-09-25 19:55:59 +08:00
|
|
|
* Returns 0 on success, or a negative errno code otherwise.
|
2012-05-20 15:03:56 +08:00
|
|
|
*/
|
2022-02-05 01:05:41 +08:00
|
|
|
int dma_buf_vmap(struct dma_buf *dmabuf, struct iosys_map *map)
|
2012-05-20 15:03:56 +08:00
|
|
|
{
|
2022-02-05 01:05:41 +08:00
|
|
|
struct iosys_map ptr;
|
2022-10-18 01:22:29 +08:00
|
|
|
int ret;
|
2020-09-25 19:55:59 +08:00
|
|
|
|
2022-02-05 01:05:41 +08:00
|
|
|
iosys_map_clear(map);
|
2012-12-20 21:14:23 +08:00
|
|
|
|
2012-05-20 15:03:56 +08:00
|
|
|
if (WARN_ON(!dmabuf))
|
2020-09-25 19:55:59 +08:00
|
|
|
return -EINVAL;
|
2012-05-20 15:03:56 +08:00
|
|
|
|
2022-10-18 01:22:23 +08:00
|
|
|
dma_resv_assert_held(dmabuf->resv);
|
|
|
|
|
2012-12-20 21:14:23 +08:00
|
|
|
if (!dmabuf->ops->vmap)
|
2020-09-25 19:55:59 +08:00
|
|
|
return -EINVAL;
|
2012-12-20 21:14:23 +08:00
|
|
|
|
|
|
|
if (dmabuf->vmapping_counter) {
|
|
|
|
dmabuf->vmapping_counter++;
|
2022-02-05 01:05:41 +08:00
|
|
|
BUG_ON(iosys_map_is_null(&dmabuf->vmap_ptr));
|
2020-09-25 19:55:59 +08:00
|
|
|
*map = dmabuf->vmap_ptr;
|
2022-10-18 01:22:29 +08:00
|
|
|
return 0;
|
2012-12-20 21:14:23 +08:00
|
|
|
}
|
|
|
|
|
2022-02-05 01:05:41 +08:00
|
|
|
BUG_ON(iosys_map_is_set(&dmabuf->vmap_ptr));
|
2012-12-20 21:14:23 +08:00
|
|
|
|
2020-09-25 19:55:59 +08:00
|
|
|
ret = dmabuf->ops->vmap(dmabuf, &ptr);
|
|
|
|
if (WARN_ON_ONCE(ret))
|
2022-10-18 01:22:29 +08:00
|
|
|
return ret;
|
2012-12-20 21:14:23 +08:00
|
|
|
|
2020-09-25 19:55:59 +08:00
|
|
|
dmabuf->vmap_ptr = ptr;
|
2012-12-20 21:14:23 +08:00
|
|
|
dmabuf->vmapping_counter = 1;
|
|
|
|
|
2020-09-25 19:55:59 +08:00
|
|
|
*map = dmabuf->vmap_ptr;
|
|
|
|
|
2022-10-18 01:22:29 +08:00
|
|
|
return 0;
|
2012-05-20 15:03:56 +08:00
|
|
|
}
|
2021-10-10 20:46:28 +08:00
|
|
|
EXPORT_SYMBOL_NS_GPL(dma_buf_vmap, DMA_BUF);
|
2012-05-20 15:03:56 +08:00
|
|
|
|
2022-10-18 01:22:09 +08:00
|
|
|
/**
|
|
|
|
* dma_buf_vmap_unlocked - Create virtual mapping for the buffer object into kernel
|
|
|
|
* address space. Same restrictions as for vmap and friends apply.
|
|
|
|
* @dmabuf: [in] buffer to vmap
|
|
|
|
* @map: [out] returns the vmap pointer
|
|
|
|
*
|
|
|
|
* Unlocked version of dma_buf_vmap()
|
|
|
|
*
|
|
|
|
* Returns 0 on success, or a negative errno code otherwise.
|
|
|
|
*/
|
|
|
|
int dma_buf_vmap_unlocked(struct dma_buf *dmabuf, struct iosys_map *map)
|
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
iosys_map_clear(map);
|
|
|
|
|
|
|
|
if (WARN_ON(!dmabuf))
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
dma_resv_lock(dmabuf->resv, NULL);
|
|
|
|
ret = dma_buf_vmap(dmabuf, map);
|
|
|
|
dma_resv_unlock(dmabuf->resv);
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_NS_GPL(dma_buf_vmap_unlocked, DMA_BUF);
|
|
|
|
|
2012-05-20 15:03:56 +08:00
|
|
|
/**
|
|
|
|
* dma_buf_vunmap - Unmap a vmap obtained by dma_buf_vmap.
|
2012-05-23 17:57:40 +08:00
|
|
|
* @dmabuf: [in] buffer to vunmap
|
2020-09-25 19:56:00 +08:00
|
|
|
* @map: [in] vmap pointer to vunmap
|
2012-05-20 15:03:56 +08:00
|
|
|
*/
|
2022-02-05 01:05:41 +08:00
|
|
|
void dma_buf_vunmap(struct dma_buf *dmabuf, struct iosys_map *map)
|
2012-05-20 15:03:56 +08:00
|
|
|
{
|
|
|
|
if (WARN_ON(!dmabuf))
|
|
|
|
return;
|
|
|
|
|
2022-10-18 01:22:23 +08:00
|
|
|
dma_resv_assert_held(dmabuf->resv);
|
|
|
|
|
2022-02-05 01:05:41 +08:00
|
|
|
BUG_ON(iosys_map_is_null(&dmabuf->vmap_ptr));
|
2012-12-20 21:14:23 +08:00
|
|
|
BUG_ON(dmabuf->vmapping_counter == 0);
|
2022-02-05 01:05:41 +08:00
|
|
|
BUG_ON(!iosys_map_is_equal(&dmabuf->vmap_ptr, map));
|
2012-12-20 21:14:23 +08:00
|
|
|
|
|
|
|
if (--dmabuf->vmapping_counter == 0) {
|
|
|
|
if (dmabuf->ops->vunmap)
|
2020-09-25 19:56:00 +08:00
|
|
|
dmabuf->ops->vunmap(dmabuf, map);
|
2022-02-05 01:05:41 +08:00
|
|
|
iosys_map_clear(&dmabuf->vmap_ptr);
|
2012-12-20 21:14:23 +08:00
|
|
|
}
|
2012-05-20 15:03:56 +08:00
|
|
|
}
|
2021-10-10 20:46:28 +08:00
|
|
|
EXPORT_SYMBOL_NS_GPL(dma_buf_vunmap, DMA_BUF);
|
2013-04-04 14:14:37 +08:00
|
|
|
|
2022-10-18 01:22:09 +08:00
|
|
|
/**
|
|
|
|
* dma_buf_vunmap_unlocked - Unmap a vmap obtained by dma_buf_vmap.
|
|
|
|
* @dmabuf: [in] buffer to vunmap
|
|
|
|
* @map: [in] vmap pointer to vunmap
|
|
|
|
*/
|
|
|
|
void dma_buf_vunmap_unlocked(struct dma_buf *dmabuf, struct iosys_map *map)
|
|
|
|
{
|
|
|
|
if (WARN_ON(!dmabuf))
|
|
|
|
return;
|
|
|
|
|
|
|
|
dma_resv_lock(dmabuf->resv, NULL);
|
|
|
|
dma_buf_vunmap(dmabuf, map);
|
|
|
|
dma_resv_unlock(dmabuf->resv);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_NS_GPL(dma_buf_vunmap_unlocked, DMA_BUF);
|
|
|
|
|
2013-04-04 14:14:37 +08:00
|
|
|
#ifdef CONFIG_DEBUG_FS
|
2016-06-19 20:31:29 +08:00
|
|
|
static int dma_buf_debug_show(struct seq_file *s, void *unused)
|
2013-04-04 14:14:37 +08:00
|
|
|
{
|
|
|
|
struct dma_buf *buf_obj;
|
|
|
|
struct dma_buf_attachment *attach_obj;
|
2021-09-23 16:28:42 +08:00
|
|
|
int count = 0, attach_count;
|
2013-04-04 14:14:37 +08:00
|
|
|
size_t size = 0;
|
2021-05-06 21:00:31 +08:00
|
|
|
int ret;
|
2013-04-04 14:14:37 +08:00
|
|
|
|
2024-03-28 22:53:23 +08:00
|
|
|
ret = mutex_lock_interruptible(&debugfs_list_mutex);
|
2013-04-04 14:14:37 +08:00
|
|
|
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
2014-02-03 17:39:12 +08:00
|
|
|
seq_puts(s, "\nDma-buf Objects:\n");
|
2022-04-28 14:39:24 +08:00
|
|
|
seq_printf(s, "%-8s\t%-8s\t%-8s\t%-8s\texp_name\t%-8s\tname\n",
|
2019-06-14 06:34:06 +08:00
|
|
|
"size", "flags", "mode", "count", "ino");
|
2013-04-04 14:14:37 +08:00
|
|
|
|
2024-03-28 22:53:23 +08:00
|
|
|
list_for_each_entry(buf_obj, &debugfs_list, list_node) {
|
dma-buf: change DMA-buf locking convention v3
This patch is a stripped down version of the locking changes
necessary to support dynamic DMA-buf handling.
It adds a dynamic flag for both importers as well as exporters
so that drivers can choose if they want the reservation object
locked or unlocked during mapping of attachments.
For compatibility between drivers we cache the DMA-buf mapping
during attaching an importer as soon as exporter/importer
disagree on the dynamic handling.
Issues and solutions we considered:
- We can't change all existing drivers, and existing improters have
strong opinions about which locks they're holding while calling
dma_buf_attachment_map/unmap. Exporters also have strong opinions about
which locks they can acquire in their ->map/unmap callbacks, levaing no
room for change. The solution to avoid this was to move the
actual map/unmap out from this call, into the attach/detach callbacks,
and cache the mapping. This works because drivers don't call
attach/detach from deep within their code callchains (like deep in
memory management code called from cs/execbuf ioctl), but directly from
the fd2handle implementation.
- The caching has some troubles on some soc drivers, which set other modes
than DMA_BIDIRECTIONAL. We can't have 2 incompatible mappings, and we
can't re-create the mapping at _map time due to the above locking fun.
We very carefuly step around that by only caching at attach time if the
dynamic mode between importer/expoert mismatches.
- There's been quite some discussion on dma-buf mappings which need active
cache management, which would all break down when caching, plus we don't
have explicit flush operations on the attachment side. The solution to
this was to shrug and keep the current discrepancy between what the
dma-buf docs claim and what implementations do, with the hope that the
begin/end_cpu_access hooks are good enough and that all necessary
flushing to keep device mappings consistent will be done there.
v2: cleanup set_name merge, improve kerneldoc
v3: update commit message, kerneldoc and cleanup _debug_show()
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/336788/
2018-07-03 22:42:26 +08:00
|
|
|
|
|
|
|
ret = dma_resv_lock_interruptible(buf_obj->resv, NULL);
|
|
|
|
if (ret)
|
2019-10-18 22:30:19 +08:00
|
|
|
goto error_unlock;
|
2013-04-04 14:14:37 +08:00
|
|
|
|
2021-10-08 15:54:20 +08:00
|
|
|
|
|
|
|
spin_lock(&buf_obj->name_lock);
|
2019-06-14 06:34:07 +08:00
|
|
|
seq_printf(s, "%08zu\t%08x\t%08x\t%08ld\t%s\t%08lu\t%s\n",
|
2014-02-03 17:39:12 +08:00
|
|
|
buf_obj->size,
|
2013-04-04 14:14:37 +08:00
|
|
|
buf_obj->file->f_flags, buf_obj->file->f_mode,
|
2014-08-20 23:05:50 +08:00
|
|
|
file_count(buf_obj->file),
|
2019-06-14 06:34:06 +08:00
|
|
|
buf_obj->exp_name,
|
2019-06-14 06:34:07 +08:00
|
|
|
file_inode(buf_obj->file)->i_ino,
|
2022-04-28 14:39:24 +08:00
|
|
|
buf_obj->name ?: "<none>");
|
2021-10-08 15:54:20 +08:00
|
|
|
spin_unlock(&buf_obj->name_lock);
|
2013-04-04 14:14:37 +08:00
|
|
|
|
2021-09-23 19:57:42 +08:00
|
|
|
dma_resv_describe(buf_obj->resv, s);
|
2017-03-31 18:00:42 +08:00
|
|
|
|
2014-02-03 17:39:12 +08:00
|
|
|
seq_puts(s, "\tAttached Devices:\n");
|
2013-04-04 14:14:37 +08:00
|
|
|
attach_count = 0;
|
|
|
|
|
|
|
|
list_for_each_entry(attach_obj, &buf_obj->attachments, node) {
|
2017-05-08 16:32:44 +08:00
|
|
|
seq_printf(s, "\t%s\n", dev_name(attach_obj->dev));
|
2013-04-04 14:14:37 +08:00
|
|
|
attach_count++;
|
|
|
|
}
|
dma-buf: change DMA-buf locking convention v3
This patch is a stripped down version of the locking changes
necessary to support dynamic DMA-buf handling.
It adds a dynamic flag for both importers as well as exporters
so that drivers can choose if they want the reservation object
locked or unlocked during mapping of attachments.
For compatibility between drivers we cache the DMA-buf mapping
during attaching an importer as soon as exporter/importer
disagree on the dynamic handling.
Issues and solutions we considered:
- We can't change all existing drivers, and existing improters have
strong opinions about which locks they're holding while calling
dma_buf_attachment_map/unmap. Exporters also have strong opinions about
which locks they can acquire in their ->map/unmap callbacks, levaing no
room for change. The solution to avoid this was to move the
actual map/unmap out from this call, into the attach/detach callbacks,
and cache the mapping. This works because drivers don't call
attach/detach from deep within their code callchains (like deep in
memory management code called from cs/execbuf ioctl), but directly from
the fd2handle implementation.
- The caching has some troubles on some soc drivers, which set other modes
than DMA_BIDIRECTIONAL. We can't have 2 incompatible mappings, and we
can't re-create the mapping at _map time due to the above locking fun.
We very carefuly step around that by only caching at attach time if the
dynamic mode between importer/expoert mismatches.
- There's been quite some discussion on dma-buf mappings which need active
cache management, which would all break down when caching, plus we don't
have explicit flush operations on the attachment side. The solution to
this was to shrug and keep the current discrepancy between what the
dma-buf docs claim and what implementations do, with the hope that the
begin/end_cpu_access hooks are good enough and that all necessary
flushing to keep device mappings consistent will be done there.
v2: cleanup set_name merge, improve kerneldoc
v3: update commit message, kerneldoc and cleanup _debug_show()
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/336788/
2018-07-03 22:42:26 +08:00
|
|
|
dma_resv_unlock(buf_obj->resv);
|
2013-04-04 14:14:37 +08:00
|
|
|
|
2014-02-03 17:39:12 +08:00
|
|
|
seq_printf(s, "Total %d devices attached\n\n",
|
2013-04-04 14:14:37 +08:00
|
|
|
attach_count);
|
|
|
|
|
|
|
|
count++;
|
|
|
|
size += buf_obj->size;
|
|
|
|
}
|
|
|
|
|
|
|
|
seq_printf(s, "\nTotal %d objects, %zu bytes\n", count, size);
|
|
|
|
|
2024-03-28 22:53:23 +08:00
|
|
|
mutex_unlock(&debugfs_list_mutex);
|
2013-04-04 14:14:37 +08:00
|
|
|
return 0;
|
dma-buf: change DMA-buf locking convention v3
This patch is a stripped down version of the locking changes
necessary to support dynamic DMA-buf handling.
It adds a dynamic flag for both importers as well as exporters
so that drivers can choose if they want the reservation object
locked or unlocked during mapping of attachments.
For compatibility between drivers we cache the DMA-buf mapping
during attaching an importer as soon as exporter/importer
disagree on the dynamic handling.
Issues and solutions we considered:
- We can't change all existing drivers, and existing improters have
strong opinions about which locks they're holding while calling
dma_buf_attachment_map/unmap. Exporters also have strong opinions about
which locks they can acquire in their ->map/unmap callbacks, levaing no
room for change. The solution to avoid this was to move the
actual map/unmap out from this call, into the attach/detach callbacks,
and cache the mapping. This works because drivers don't call
attach/detach from deep within their code callchains (like deep in
memory management code called from cs/execbuf ioctl), but directly from
the fd2handle implementation.
- The caching has some troubles on some soc drivers, which set other modes
than DMA_BIDIRECTIONAL. We can't have 2 incompatible mappings, and we
can't re-create the mapping at _map time due to the above locking fun.
We very carefuly step around that by only caching at attach time if the
dynamic mode between importer/expoert mismatches.
- There's been quite some discussion on dma-buf mappings which need active
cache management, which would all break down when caching, plus we don't
have explicit flush operations on the attachment side. The solution to
this was to shrug and keep the current discrepancy between what the
dma-buf docs claim and what implementations do, with the hope that the
begin/end_cpu_access hooks are good enough and that all necessary
flushing to keep device mappings consistent will be done there.
v2: cleanup set_name merge, improve kerneldoc
v3: update commit message, kerneldoc and cleanup _debug_show()
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/336788/
2018-07-03 22:42:26 +08:00
|
|
|
|
2019-10-18 22:30:19 +08:00
|
|
|
error_unlock:
|
2024-03-28 22:53:23 +08:00
|
|
|
mutex_unlock(&debugfs_list_mutex);
|
dma-buf: change DMA-buf locking convention v3
This patch is a stripped down version of the locking changes
necessary to support dynamic DMA-buf handling.
It adds a dynamic flag for both importers as well as exporters
so that drivers can choose if they want the reservation object
locked or unlocked during mapping of attachments.
For compatibility between drivers we cache the DMA-buf mapping
during attaching an importer as soon as exporter/importer
disagree on the dynamic handling.
Issues and solutions we considered:
- We can't change all existing drivers, and existing improters have
strong opinions about which locks they're holding while calling
dma_buf_attachment_map/unmap. Exporters also have strong opinions about
which locks they can acquire in their ->map/unmap callbacks, levaing no
room for change. The solution to avoid this was to move the
actual map/unmap out from this call, into the attach/detach callbacks,
and cache the mapping. This works because drivers don't call
attach/detach from deep within their code callchains (like deep in
memory management code called from cs/execbuf ioctl), but directly from
the fd2handle implementation.
- The caching has some troubles on some soc drivers, which set other modes
than DMA_BIDIRECTIONAL. We can't have 2 incompatible mappings, and we
can't re-create the mapping at _map time due to the above locking fun.
We very carefuly step around that by only caching at attach time if the
dynamic mode between importer/expoert mismatches.
- There's been quite some discussion on dma-buf mappings which need active
cache management, which would all break down when caching, plus we don't
have explicit flush operations on the attachment side. The solution to
this was to shrug and keep the current discrepancy between what the
dma-buf docs claim and what implementations do, with the hope that the
begin/end_cpu_access hooks are good enough and that all necessary
flushing to keep device mappings consistent will be done there.
v2: cleanup set_name merge, improve kerneldoc
v3: update commit message, kerneldoc and cleanup _debug_show()
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/336788/
2018-07-03 22:42:26 +08:00
|
|
|
return ret;
|
2013-04-04 14:14:37 +08:00
|
|
|
}
|
|
|
|
|
2018-12-01 00:11:01 +08:00
|
|
|
DEFINE_SHOW_ATTRIBUTE(dma_buf_debug);
|
2013-04-04 14:14:37 +08:00
|
|
|
|
|
|
|
static struct dentry *dma_buf_debugfs_dir;
|
|
|
|
|
|
|
|
static int dma_buf_init_debugfs(void)
|
|
|
|
{
|
2016-06-19 20:31:31 +08:00
|
|
|
struct dentry *d;
|
2013-04-04 14:14:37 +08:00
|
|
|
int err = 0;
|
2015-05-21 03:39:31 +08:00
|
|
|
|
2016-06-19 20:31:31 +08:00
|
|
|
d = debugfs_create_dir("dma_buf", NULL);
|
|
|
|
if (IS_ERR(d))
|
|
|
|
return PTR_ERR(d);
|
2015-05-21 03:39:31 +08:00
|
|
|
|
2016-06-19 20:31:31 +08:00
|
|
|
dma_buf_debugfs_dir = d;
|
2013-04-04 14:14:37 +08:00
|
|
|
|
2016-06-19 20:31:31 +08:00
|
|
|
d = debugfs_create_file("bufinfo", S_IRUGO, dma_buf_debugfs_dir,
|
|
|
|
NULL, &dma_buf_debug_fops);
|
|
|
|
if (IS_ERR(d)) {
|
2013-04-04 14:14:37 +08:00
|
|
|
pr_debug("dma_buf: debugfs: failed to create node bufinfo\n");
|
2016-06-19 20:31:30 +08:00
|
|
|
debugfs_remove_recursive(dma_buf_debugfs_dir);
|
|
|
|
dma_buf_debugfs_dir = NULL;
|
2016-06-19 20:31:31 +08:00
|
|
|
err = PTR_ERR(d);
|
2016-06-19 20:31:30 +08:00
|
|
|
}
|
2013-04-04 14:14:37 +08:00
|
|
|
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void dma_buf_uninit_debugfs(void)
|
|
|
|
{
|
2017-11-22 23:22:41 +08:00
|
|
|
debugfs_remove_recursive(dma_buf_debugfs_dir);
|
2013-04-04 14:14:37 +08:00
|
|
|
}
|
|
|
|
#else
|
|
|
|
static inline int dma_buf_init_debugfs(void)
|
|
|
|
{
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
static inline void dma_buf_uninit_debugfs(void)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
|
|
|
static int __init dma_buf_init(void)
|
|
|
|
{
|
2021-06-04 05:47:51 +08:00
|
|
|
int ret;
|
|
|
|
|
|
|
|
ret = dma_buf_init_sysfs_statistics();
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
2019-06-14 06:34:06 +08:00
|
|
|
dma_buf_mnt = kern_mount(&dma_buf_fs_type);
|
|
|
|
if (IS_ERR(dma_buf_mnt))
|
|
|
|
return PTR_ERR(dma_buf_mnt);
|
|
|
|
|
2013-04-04 14:14:37 +08:00
|
|
|
dma_buf_init_debugfs();
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
subsys_initcall(dma_buf_init);
|
|
|
|
|
|
|
|
static void __exit dma_buf_deinit(void)
|
|
|
|
{
|
|
|
|
dma_buf_uninit_debugfs();
|
2019-06-14 06:34:06 +08:00
|
|
|
kern_unmount(dma_buf_mnt);
|
2021-06-04 05:47:51 +08:00
|
|
|
dma_buf_uninit_sysfs_statistics();
|
2013-04-04 14:14:37 +08:00
|
|
|
}
|
|
|
|
__exitcall(dma_buf_deinit);
|