diff options
author | Christian König <christian.koenig@amd.com> | 2018-07-03 16:42:26 +0200 |
---|---|---|
committer | Christian König <christian.koenig@amd.com> | 2019-10-24 09:18:09 +0200 |
commit | 15fd552d186cb0df34b9d36a07dd6677c4da56bc (patch) | |
tree | fbe76ba4a2cf559647313f0ae96caeb43da3027e /include/linux/dma-buf.h | |
parent | 9a42c7c647a9ad0f7ebb147a52eda3dcb7c84292 (diff) |
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/
Diffstat (limited to 'include/linux/dma-buf.h')
-rw-r--r-- | include/linux/dma-buf.h | 63 |
1 files changed, 57 insertions, 6 deletions
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h index ec212cb27fdc..af73f835c51c 100644 --- a/include/linux/dma-buf.h +++ b/include/linux/dma-buf.h @@ -43,6 +43,18 @@ struct dma_buf_ops { bool cache_sgt_mapping; /** + * @dynamic_mapping: + * + * If true the framework makes sure that the map/unmap_dma_buf + * callbacks are always called with the dma_resv object locked. + * + * If false the framework makes sure that the map/unmap_dma_buf + * callbacks are always called without the dma_resv object locked. + * Mutual exclusive with @cache_sgt_mapping. + */ + bool dynamic_mapping; + + /** * @attach: * * This is called from dma_buf_attach() to make sure that a given @@ -109,6 +121,9 @@ struct dma_buf_ops { * any other kind of sharing that the exporter might wish to make * available to buffer-users. * + * This is always called with the dmabuf->resv object locked when + * the dynamic_mapping flag is true. + * * Returns: * * A &sg_table scatter list of or the backing storage of the DMA buffer, @@ -267,14 +282,16 @@ struct dma_buf_ops { * 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. + * @attachments: list of dma_buf_attachment that denotes all devices attached, + * protected by dma_resv lock. * @ops: dma_buf_ops associated with this buffer object. * @lock: used internally to serialize list manipulation, attach/detach and - * vmap/unmap, and accesses to name + * vmap/unmap * @vmapping_counter: used internally to refcnt the vmaps * @vmap_ptr: the current vmap ptr if vmapping_counter > 0 * @exp_name: name of the exporter; useful for debugging. - * @name: userspace-provided name; useful for accounting and debugging. + * @name: userspace-provided name; useful for accounting and debugging, + * protected by @resv. * @owner: pointer to exporter module; used for refcounting when exporter is a * kernel module. * @list_node: node for dma_buf accounting and debugging. @@ -323,10 +340,12 @@ struct dma_buf { * 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. + * @node: list of dma_buf_attachment, protected by dma_resv lock of the dmabuf. * @sgt: cached mapping. * @dir: direction of cached mapping. * @priv: exporter specific attachment data. + * @dynamic_mapping: true if dma_buf_map/unmap_attachment() is called with the + * dma_resv lock held. * * This structure holds the attachment information between the dma_buf buffer * and its user device(s). The list contains one attachment struct per device @@ -343,6 +362,7 @@ struct dma_buf_attachment { struct list_head node; struct sg_table *sgt; enum dma_data_direction dir; + bool dynamic_mapping; void *priv; }; @@ -394,10 +414,40 @@ static inline void get_dma_buf(struct dma_buf *dmabuf) get_file(dmabuf->file); } +/** + * dma_buf_is_dynamic - check if a DMA-buf uses dynamic mappings. + * @dmabuf: the DMA-buf to check + * + * Returns true if a DMA-buf exporter wants to be called with the dma_resv + * locked for the map/unmap callbacks, false if it doesn't wants to be called + * with the lock held. + */ +static inline bool dma_buf_is_dynamic(struct dma_buf *dmabuf) +{ + return dmabuf->ops->dynamic_mapping; +} + +/** + * dma_buf_attachment_is_dynamic - check if a DMA-buf attachment uses dynamic + * mappinsg + * @attach: the DMA-buf attachment to check + * + * Returns true if a DMA-buf importer wants to call the map/unmap functions with + * the dma_resv lock held. + */ +static inline bool +dma_buf_attachment_is_dynamic(struct dma_buf_attachment *attach) +{ + return attach->dynamic_mapping; +} + struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf, - struct device *dev); + struct device *dev); +struct dma_buf_attachment * +dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct device *dev, + bool dynamic_mapping); void dma_buf_detach(struct dma_buf *dmabuf, - struct dma_buf_attachment *dmabuf_attach); + struct dma_buf_attachment *attach); struct dma_buf *dma_buf_export(const struct dma_buf_export_info *exp_info); @@ -409,6 +459,7 @@ struct sg_table *dma_buf_map_attachment(struct dma_buf_attachment *, enum dma_data_direction); void dma_buf_unmap_attachment(struct dma_buf_attachment *, struct sg_table *, enum dma_data_direction); +void dma_buf_move_notify(struct dma_buf *dma_buf); int dma_buf_begin_cpu_access(struct dma_buf *dma_buf, enum dma_data_direction dir); int dma_buf_end_cpu_access(struct dma_buf *dma_buf, |