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
|
|
|
/*
|
|
|
|
* Header file for dma buffer sharing framework.
|
|
|
|
*
|
|
|
|
* 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.
|
|
|
|
*
|
|
|
|
* This program is free software; you can redistribute it and/or modify it
|
|
|
|
* under the terms of the GNU General Public License version 2 as published by
|
|
|
|
* the Free Software Foundation.
|
|
|
|
*
|
|
|
|
* This program is distributed in the hope that it will be useful, but WITHOUT
|
|
|
|
* ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
|
|
|
|
* FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
|
|
|
|
* more details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU General Public License along with
|
|
|
|
* this program. If not, see <http://www.gnu.org/licenses/>.
|
|
|
|
*/
|
|
|
|
#ifndef __DMA_BUF_H__
|
|
|
|
#define __DMA_BUF_H__
|
|
|
|
|
|
|
|
#include <linux/file.h>
|
|
|
|
#include <linux/err.h>
|
|
|
|
#include <linux/scatterlist.h>
|
|
|
|
#include <linux/list.h>
|
|
|
|
#include <linux/dma-mapping.h>
|
2012-03-17 00:04:41 +08:00
|
|
|
#include <linux/fs.h>
|
2016-10-25 20:00:45 +08:00
|
|
|
#include <linux/dma-fence.h>
|
2014-07-01 18:57:43 +08:00
|
|
|
#include <linux/wait.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
|
|
|
|
2012-01-31 00:46:54 +08:00
|
|
|
struct device;
|
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;
|
|
|
|
struct dma_buf_attachment;
|
|
|
|
|
|
|
|
/**
|
|
|
|
* struct dma_buf_ops - operations possible on struct dma_buf
|
2018-05-29 21:59:18 +08:00
|
|
|
* @map_atomic: [optional] maps a page from the buffer into kernel address
|
2017-04-20 03:36:10 +08:00
|
|
|
* space, users may not block until the subsequent unmap call.
|
|
|
|
* This callback must not sleep.
|
|
|
|
* @unmap_atomic: [optional] unmaps a atomically mapped page from the buffer.
|
|
|
|
* This Callback must not sleep.
|
2018-05-29 21:59:18 +08:00
|
|
|
* @map: [optional] maps a page from the buffer into kernel address space.
|
2017-04-20 03:36:10 +08:00
|
|
|
* @unmap: [optional] unmaps a page from the buffer.
|
2012-05-23 17:57:40 +08:00
|
|
|
* @vmap: [optional] creates a virtual mapping for the buffer into kernel
|
|
|
|
* address space. Same restrictions as for vmap and friends apply.
|
|
|
|
* @vunmap: [optional] unmaps a vmap from the buffer
|
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_ops {
|
2016-12-10 02:53:07 +08:00
|
|
|
/**
|
|
|
|
* @attach:
|
|
|
|
*
|
|
|
|
* This is called from dma_buf_attach() to make sure that a given
|
2018-05-28 17:47:52 +08:00
|
|
|
* &dma_buf_attachment.dev can access the provided &dma_buf. Exporters
|
|
|
|
* which support buffer objects in special locations like VRAM or
|
|
|
|
* device-specific carveout areas should check whether the buffer could
|
|
|
|
* be move to system memory (or directly accessed by the provided
|
|
|
|
* device), and otherwise need to fail the attach operation.
|
2016-12-10 02:53:07 +08:00
|
|
|
*
|
|
|
|
* The exporter should also in general check whether the current
|
|
|
|
* allocation fullfills the DMA constraints of the new device. If this
|
|
|
|
* is not the case, and the allocation cannot be moved, it should also
|
|
|
|
* fail the attach operation.
|
|
|
|
*
|
2016-12-30 04:48:25 +08:00
|
|
|
* Any exporter-private housekeeping data can be stored in the
|
|
|
|
* &dma_buf_attachment.priv pointer.
|
2016-12-10 02:53:07 +08:00
|
|
|
*
|
|
|
|
* This callback is optional.
|
|
|
|
*
|
|
|
|
* Returns:
|
|
|
|
*
|
|
|
|
* 0 on success, negative error code on failure. It might return -EBUSY
|
|
|
|
* to signal that backing storage is already allocated and incompatible
|
|
|
|
* with the requirements of requesting device.
|
|
|
|
*/
|
2018-05-28 17:47:52 +08:00
|
|
|
int (*attach)(struct dma_buf *, struct dma_buf_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
|
|
|
/**
|
|
|
|
* @detach:
|
|
|
|
*
|
|
|
|
* This is called by dma_buf_detach() to release a &dma_buf_attachment.
|
|
|
|
* Provided so that exporters can clean up any housekeeping for an
|
|
|
|
* &dma_buf_attachment.
|
|
|
|
*
|
|
|
|
* This callback is optional.
|
|
|
|
*/
|
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 (*detach)(struct dma_buf *, struct dma_buf_attachment *);
|
|
|
|
|
2016-12-10 02:53:07 +08:00
|
|
|
/**
|
|
|
|
* @map_dma_buf:
|
|
|
|
*
|
|
|
|
* This is called by dma_buf_map_attachment() and is used to map a
|
|
|
|
* shared &dma_buf into device address space, and it is mandatory. It
|
|
|
|
* can only be called if @attach has been called successfully. This
|
|
|
|
* essentially pins the DMA buffer into place, and it cannot be moved
|
|
|
|
* any more
|
|
|
|
*
|
|
|
|
* This call may sleep, e.g. when the backing storage first needs to be
|
|
|
|
* allocated, or moved to a location suitable for all currently attached
|
|
|
|
* devices.
|
|
|
|
*
|
|
|
|
* Note that any specific buffer attributes required for this function
|
|
|
|
* should get added to device_dma_parameters accessible via
|
2016-12-30 04:48:25 +08:00
|
|
|
* &device.dma_params from the &dma_buf_attachment. The @attach callback
|
2016-12-10 02:53:07 +08:00
|
|
|
* should also check these constraints.
|
|
|
|
*
|
|
|
|
* If this is being called for the first time, the exporter can now
|
|
|
|
* choose to scan through the list of attachments for this buffer,
|
|
|
|
* collate the requirements of the attached devices, and choose an
|
|
|
|
* appropriate backing storage for the buffer.
|
|
|
|
*
|
|
|
|
* Based on enum dma_data_direction, it might be possible to have
|
|
|
|
* multiple users accessing at the same time (for reading, maybe), or
|
|
|
|
* any other kind of sharing that the exporter might wish to make
|
|
|
|
* available to buffer-users.
|
|
|
|
*
|
|
|
|
* Returns:
|
|
|
|
*
|
|
|
|
* A &sg_table scatter list of or the backing storage of the DMA buffer,
|
|
|
|
* already mapped into the device address space of the &device attached
|
|
|
|
* with the provided &dma_buf_attachment.
|
|
|
|
*
|
|
|
|
* On failure, returns a negative error value wrapped into a pointer.
|
|
|
|
* May also return -EINTR when a signal was received while being
|
|
|
|
* blocked.
|
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 * (*map_dma_buf)(struct dma_buf_attachment *,
|
2016-12-10 02:53:07 +08:00
|
|
|
enum dma_data_direction);
|
|
|
|
/**
|
|
|
|
* @unmap_dma_buf:
|
|
|
|
*
|
|
|
|
* This is called by dma_buf_unmap_attachment() and should unmap and
|
|
|
|
* release the &sg_table allocated in @map_dma_buf, and it is mandatory.
|
|
|
|
* It should also unpin the backing storage if this is the last mapping
|
|
|
|
* of the DMA buffer, it the exporter supports backing storage
|
|
|
|
* migration.
|
|
|
|
*/
|
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 (*unmap_dma_buf)(struct dma_buf_attachment *,
|
2016-12-10 02:53:07 +08:00
|
|
|
struct sg_table *,
|
|
|
|
enum dma_data_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
|
|
|
/* TODO: Add try_map_dma_buf version, to return immed with -EBUSY
|
|
|
|
* if the call would block.
|
|
|
|
*/
|
|
|
|
|
2016-12-10 02:53:07 +08:00
|
|
|
/**
|
|
|
|
* @release:
|
|
|
|
*
|
|
|
|
* Called after the last dma_buf_put to release the &dma_buf, and
|
|
|
|
* mandatory.
|
|
|
|
*/
|
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 (*release)(struct dma_buf *);
|
|
|
|
|
2016-12-10 02:53:08 +08:00
|
|
|
/**
|
|
|
|
* @begin_cpu_access:
|
|
|
|
*
|
|
|
|
* This is called from dma_buf_begin_cpu_access() and allows the
|
|
|
|
* exporter to ensure that the memory is actually available for cpu
|
|
|
|
* access - the exporter might need to allocate or swap-in and pin the
|
|
|
|
* backing storage. The exporter also needs to ensure that cpu access is
|
|
|
|
* coherent for the access direction. The direction can be used by the
|
|
|
|
* exporter to optimize the cache flushing, i.e. access with a different
|
|
|
|
* direction (read instead of write) might return stale or even bogus
|
|
|
|
* data (e.g. when the exporter needs to copy the data to temporary
|
|
|
|
* storage).
|
|
|
|
*
|
|
|
|
* This callback is optional.
|
|
|
|
*
|
|
|
|
* FIXME: This is both called through the DMA_BUF_IOCTL_SYNC command
|
|
|
|
* from userspace (where storage shouldn't be pinned to avoid handing
|
|
|
|
* de-factor mlock rights to userspace) and for the kernel-internal
|
|
|
|
* users of the various kmap interfaces, where the backing storage must
|
|
|
|
* be pinned to guarantee that the atomic kmap calls can succeed. Since
|
|
|
|
* there's no in-kernel users of the kmap interfaces yet this isn't a
|
|
|
|
* real problem.
|
|
|
|
*
|
|
|
|
* Returns:
|
|
|
|
*
|
|
|
|
* 0 on success or a negative error code on failure. This can for
|
|
|
|
* example fail when the backing storage can't be allocated. Can also
|
|
|
|
* return -ERESTARTSYS or -EINTR when the call has been interrupted and
|
|
|
|
* needs to be restarted.
|
|
|
|
*/
|
2015-12-23 05:36:45 +08:00
|
|
|
int (*begin_cpu_access)(struct dma_buf *, enum dma_data_direction);
|
2016-12-10 02:53:08 +08:00
|
|
|
|
|
|
|
/**
|
|
|
|
* @end_cpu_access:
|
|
|
|
*
|
|
|
|
* This is called from dma_buf_end_cpu_access() when the importer is
|
|
|
|
* done accessing the CPU. The exporter can use this to flush caches and
|
|
|
|
* unpin any resources pinned in @begin_cpu_access.
|
|
|
|
* The result of any dma_buf kmap calls after end_cpu_access is
|
|
|
|
* undefined.
|
|
|
|
*
|
|
|
|
* This callback is optional.
|
|
|
|
*
|
|
|
|
* Returns:
|
|
|
|
*
|
|
|
|
* 0 on success or a negative error code on failure. Can return
|
|
|
|
* -ERESTARTSYS or -EINTR when the call has been interrupted and needs
|
|
|
|
* to be restarted.
|
|
|
|
*/
|
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 (*end_cpu_access)(struct dma_buf *, enum dma_data_direction);
|
2017-04-20 03:36:10 +08:00
|
|
|
void *(*map)(struct dma_buf *, unsigned long);
|
|
|
|
void (*unmap)(struct dma_buf *, unsigned long, void *);
|
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
|
|
|
|
2016-12-10 02:53:08 +08:00
|
|
|
/**
|
|
|
|
* @mmap:
|
|
|
|
*
|
|
|
|
* This callback is used by the dma_buf_mmap() function
|
|
|
|
*
|
|
|
|
* Note that the mapping needs to be incoherent, userspace is expected
|
|
|
|
* to braket CPU access using the DMA_BUF_IOCTL_SYNC interface.
|
|
|
|
*
|
|
|
|
* Because dma-buf buffers have invariant size over their lifetime, the
|
|
|
|
* dma-buf core checks whether a vma is too large and rejects such
|
|
|
|
* mappings. The exporter hence does not need to duplicate this check.
|
|
|
|
* Drivers do not need to check this themselves.
|
|
|
|
*
|
|
|
|
* If an exporter needs to manually flush caches and hence needs to fake
|
|
|
|
* coherency for mmap support, it needs to be able to zap all the ptes
|
|
|
|
* pointing at the backing storage. Now linux mm needs a struct
|
|
|
|
* address_space associated with the struct file stored in vma->vm_file
|
|
|
|
* to do that with the function unmap_mapping_range. But the dma_buf
|
|
|
|
* framework only backs every dma_buf fd with the anon_file struct file,
|
|
|
|
* i.e. all dma_bufs share the same file.
|
|
|
|
*
|
|
|
|
* Hence exporters need to setup their own file (and address_space)
|
|
|
|
* association by setting vma->vm_file and adjusting vma->vm_pgoff in
|
|
|
|
* the dma_buf mmap callback. In the specific case of a gem driver the
|
|
|
|
* exporter could use the shmem file already provided by gem (and set
|
|
|
|
* vm_pgoff = 0). Exporters can then zap ptes by unmapping the
|
|
|
|
* corresponding range of the struct address_space associated with their
|
|
|
|
* own file.
|
|
|
|
*
|
|
|
|
* This callback is optional.
|
|
|
|
*
|
|
|
|
* Returns:
|
|
|
|
*
|
|
|
|
* 0 on success or a negative error code on failure.
|
|
|
|
*/
|
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
|
|
|
int (*mmap)(struct dma_buf *, struct vm_area_struct *vma);
|
2012-05-20 15:03:56 +08:00
|
|
|
|
|
|
|
void *(*vmap)(struct dma_buf *);
|
|
|
|
void (*vunmap)(struct dma_buf *, void *vaddr);
|
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 - shared buffer object
|
|
|
|
* @size: size of the buffer
|
|
|
|
* @file: file pointer used for sharing buffers across, and for refcounting.
|
|
|
|
* @attachments: list of dma_buf_attachment that denotes all devices attached.
|
|
|
|
* @ops: dma_buf_ops associated with this buffer object.
|
2016-04-01 04:26:50 +08:00
|
|
|
* @lock: used internally to serialize list manipulation, attach/detach and vmap/unmap
|
|
|
|
* @vmapping_counter: used internally to refcnt the vmaps
|
|
|
|
* @vmap_ptr: the current vmap ptr if vmapping_counter > 0
|
2013-03-22 20:52:16 +08:00
|
|
|
* @exp_name: name of the exporter; useful for debugging.
|
2015-05-05 17:26:15 +08:00
|
|
|
* @owner: pointer to exporter module; used for refcounting when exporter is a
|
|
|
|
* kernel module.
|
2013-04-04 14:14:37 +08:00
|
|
|
* @list_node: node for dma_buf accounting and 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
|
|
|
* @priv: exporter specific private data for this buffer object.
|
2014-07-01 18:57:26 +08:00
|
|
|
* @resv: reservation object linked to this dma-buf
|
2016-04-01 04:26:50 +08:00
|
|
|
* @poll: for userspace poll support
|
|
|
|
* @cb_excl: for userspace poll support
|
|
|
|
* @cb_shared: for userspace poll support
|
2016-12-10 02:53:07 +08:00
|
|
|
*
|
|
|
|
* This represents a shared buffer, created by calling dma_buf_export(). The
|
|
|
|
* userspace representation is a normal file descriptor, which can be created by
|
|
|
|
* calling dma_buf_fd().
|
|
|
|
*
|
|
|
|
* Shared dma buffers are reference counted using dma_buf_put() and
|
|
|
|
* get_dma_buf().
|
|
|
|
*
|
2016-12-30 04:48:24 +08:00
|
|
|
* Device DMA access is handled by the separate &struct dma_buf_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
|
|
|
*/
|
|
|
|
struct dma_buf {
|
|
|
|
size_t size;
|
|
|
|
struct file *file;
|
|
|
|
struct list_head attachments;
|
|
|
|
const struct dma_buf_ops *ops;
|
|
|
|
struct mutex lock;
|
2012-12-20 21:14:23 +08:00
|
|
|
unsigned vmapping_counter;
|
|
|
|
void *vmap_ptr;
|
2013-03-22 20:52:16 +08:00
|
|
|
const char *exp_name;
|
2015-05-05 17:26:15 +08:00
|
|
|
struct module *owner;
|
2013-04-04 14:14:37 +08:00
|
|
|
struct list_head list_node;
|
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 *priv;
|
2014-07-01 18:57:26 +08:00
|
|
|
struct reservation_object *resv;
|
2014-07-01 18:57:43 +08:00
|
|
|
|
|
|
|
/* poll support */
|
|
|
|
wait_queue_head_t poll;
|
|
|
|
|
|
|
|
struct dma_buf_poll_cb_t {
|
2016-10-25 20:00:45 +08:00
|
|
|
struct dma_fence_cb cb;
|
2014-07-01 18:57:43 +08:00
|
|
|
wait_queue_head_t *poll;
|
|
|
|
|
2017-07-04 11:53:17 +08:00
|
|
|
__poll_t active;
|
2014-07-01 18:57:43 +08:00
|
|
|
} cb_excl, cb_shared;
|
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 - holds device-buffer attachment data
|
|
|
|
* @dmabuf: buffer for this attachment.
|
|
|
|
* @dev: device attached to the buffer.
|
|
|
|
* @node: list of dma_buf_attachment.
|
|
|
|
* @priv: exporter specific attachment data.
|
|
|
|
*
|
|
|
|
* This structure holds the attachment information between the dma_buf buffer
|
|
|
|
* and its user device(s). The list contains one attachment struct per device
|
|
|
|
* attached to the buffer.
|
2016-12-10 02:53:07 +08:00
|
|
|
*
|
|
|
|
* An attachment is created by calling dma_buf_attach(), and released again by
|
|
|
|
* calling dma_buf_detach(). The DMA mapping itself needed to initiate a
|
|
|
|
* transfer is created by dma_buf_map_attachment() and freed again by calling
|
|
|
|
* dma_buf_unmap_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
|
|
|
*/
|
|
|
|
struct dma_buf_attachment {
|
|
|
|
struct dma_buf *dmabuf;
|
|
|
|
struct device *dev;
|
|
|
|
struct list_head node;
|
|
|
|
void *priv;
|
|
|
|
};
|
|
|
|
|
2015-01-23 15:23:43 +08:00
|
|
|
/**
|
|
|
|
* struct dma_buf_export_info - holds information needed to export a dma_buf
|
2015-05-05 17:26:15 +08:00
|
|
|
* @exp_name: name of the exporter - useful for debugging.
|
|
|
|
* @owner: pointer to exporter module - used for refcounting kernel module
|
2015-01-23 15:23:43 +08:00
|
|
|
* @ops: Attach allocator-defined dma buf ops to the new buffer
|
|
|
|
* @size: Size of the buffer
|
|
|
|
* @flags: mode flags for the file
|
|
|
|
* @resv: reservation-object, NULL to allocate default one
|
|
|
|
* @priv: Attach private data of allocator to this buffer
|
|
|
|
*
|
|
|
|
* This structure holds the information required to export the buffer. Used
|
|
|
|
* with dma_buf_export() only.
|
|
|
|
*/
|
|
|
|
struct dma_buf_export_info {
|
|
|
|
const char *exp_name;
|
2015-05-05 17:26:15 +08:00
|
|
|
struct module *owner;
|
2015-01-23 15:23:43 +08:00
|
|
|
const struct dma_buf_ops *ops;
|
|
|
|
size_t size;
|
|
|
|
int flags;
|
|
|
|
struct reservation_object *resv;
|
|
|
|
void *priv;
|
|
|
|
};
|
|
|
|
|
|
|
|
/**
|
2016-12-10 02:53:07 +08:00
|
|
|
* DEFINE_DMA_BUF_EXPORT_INFO - helper macro for exporters
|
2016-04-01 04:26:50 +08:00
|
|
|
* @name: export-info name
|
2016-12-10 02:53:07 +08:00
|
|
|
*
|
2016-12-30 04:48:24 +08:00
|
|
|
* DEFINE_DMA_BUF_EXPORT_INFO macro defines the &struct dma_buf_export_info,
|
2016-12-10 02:53:07 +08:00
|
|
|
* zeroes it out and pre-populates exp_name in it.
|
2015-01-23 15:23:43 +08:00
|
|
|
*/
|
2016-04-01 04:26:50 +08:00
|
|
|
#define DEFINE_DMA_BUF_EXPORT_INFO(name) \
|
|
|
|
struct dma_buf_export_info name = { .exp_name = KBUILD_MODNAME, \
|
2015-05-05 17:26:15 +08:00
|
|
|
.owner = THIS_MODULE }
|
2015-01-23 15:23:43 +08:00
|
|
|
|
2012-03-17 00:04:41 +08:00
|
|
|
/**
|
|
|
|
* get_dma_buf - convenience wrapper for get_file.
|
|
|
|
* @dmabuf: [in] pointer to dma_buf
|
|
|
|
*
|
|
|
|
* Increments the reference count on the dma-buf, needed in case of drivers
|
|
|
|
* that either need to create additional references to the dmabuf on the
|
|
|
|
* kernel side. For example, an exporter that needs to keep a dmabuf ptr
|
|
|
|
* so that subsequent exports don't create a new dmabuf.
|
|
|
|
*/
|
|
|
|
static inline void get_dma_buf(struct dma_buf *dmabuf)
|
|
|
|
{
|
|
|
|
get_file(dmabuf->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
|
|
|
struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
|
|
|
|
struct device *dev);
|
|
|
|
void dma_buf_detach(struct dma_buf *dmabuf,
|
|
|
|
struct dma_buf_attachment *dmabuf_attach);
|
2013-03-22 20:52:16 +08:00
|
|
|
|
2015-01-23 15:23:43 +08:00
|
|
|
struct dma_buf *dma_buf_export(const struct dma_buf_export_info *exp_info);
|
2013-03-22 20:52:16 +08:00
|
|
|
|
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
|
|
|
struct dma_buf *dma_buf_get(int fd);
|
|
|
|
void dma_buf_put(struct dma_buf *dmabuf);
|
|
|
|
|
|
|
|
struct sg_table *dma_buf_map_attachment(struct dma_buf_attachment *,
|
|
|
|
enum dma_data_direction);
|
2012-01-27 17:39:27 +08:00
|
|
|
void dma_buf_unmap_attachment(struct dma_buf_attachment *, struct sg_table *,
|
|
|
|
enum dma_data_direction);
|
2015-12-23 05:36:45 +08:00
|
|
|
int dma_buf_begin_cpu_access(struct dma_buf *dma_buf,
|
2012-03-20 07:02:37 +08:00
|
|
|
enum dma_data_direction dir);
|
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 *dma_buf,
|
|
|
|
enum dma_data_direction dir);
|
2012-03-20 07:02:37 +08:00
|
|
|
void *dma_buf_kmap(struct dma_buf *, unsigned long);
|
|
|
|
void dma_buf_kunmap(struct dma_buf *, unsigned long, void *);
|
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
|
|
|
|
|
|
|
int dma_buf_mmap(struct dma_buf *, struct vm_area_struct *,
|
|
|
|
unsigned long);
|
2012-05-20 15:03:56 +08:00
|
|
|
void *dma_buf_vmap(struct dma_buf *);
|
|
|
|
void dma_buf_vunmap(struct dma_buf *, void *vaddr);
|
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
|
|
|
#endif /* __DMA_BUF_H__ */
|