dma-buf: A collection of typo and documentation fixes
I've been collecting these typo fixes for a while and it feels like time to send them in. Signed-off-by: T.J. Mercier <tjmercier@google.com> Reviewed-by: Randy Dunlap <rdunlap@infradead.org> Acked-by: Christian König <christian.koenig@amd.com> Reviewed-by: Tommaso Merciai <tommaso.merciai@amarulasolutions.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221123193519.3948105-1-tjmercier@google.com Signed-off-by: Christian König <christian.koenig@amd.com>
This commit is contained in:
parent
1e5b3968a5
commit
b56ffa5833
@ -1252,7 +1252,7 @@ EXPORT_SYMBOL_NS_GPL(dma_buf_unmap_attachment_unlocked, DMA_BUF);
|
||||
*
|
||||
* @dmabuf: [in] buffer which is moving
|
||||
*
|
||||
* Informs all attachmenst that they need to destroy and recreated all their
|
||||
* Informs all attachments that they need to destroy and recreate all their
|
||||
* mappings.
|
||||
*/
|
||||
void dma_buf_move_notify(struct dma_buf *dmabuf)
|
||||
@ -1270,11 +1270,11 @@ EXPORT_SYMBOL_NS_GPL(dma_buf_move_notify, DMA_BUF);
|
||||
/**
|
||||
* DOC: cpu access
|
||||
*
|
||||
* There are mutliple reasons for supporting CPU access to a dma buffer object:
|
||||
* There are multiple reasons for supporting CPU access to a dma buffer object:
|
||||
*
|
||||
* - 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
|
||||
* sending it away. Cache coherency is handled by braketing any transactions
|
||||
* sending it away. Cache coherency is handled by bracketing any transactions
|
||||
* with calls to dma_buf_begin_cpu_access() and dma_buf_end_cpu_access()
|
||||
* access.
|
||||
*
|
||||
@ -1301,7 +1301,7 @@ EXPORT_SYMBOL_NS_GPL(dma_buf_move_notify, DMA_BUF);
|
||||
* replace ION buffers mmap support was needed.
|
||||
*
|
||||
* There is no special interfaces, userspace simply calls mmap on the dma-buf
|
||||
* fd. But like for CPU access there's a need to braket the actual access,
|
||||
* fd. But like for CPU access there's a need to bracket the actual access,
|
||||
* 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.
|
||||
@ -1375,10 +1375,10 @@ static int __dma_buf_begin_cpu_access(struct dma_buf *dmabuf,
|
||||
* preparations. Coherency is only guaranteed in the specified range for the
|
||||
* specified access direction.
|
||||
* @dmabuf: [in] buffer to prepare cpu access for.
|
||||
* @direction: [in] length of range for cpu access.
|
||||
* @direction: [in] direction of access.
|
||||
*
|
||||
* After the cpu access is complete the caller should call
|
||||
* dma_buf_end_cpu_access(). Only when cpu access is braketed by both calls is
|
||||
* dma_buf_end_cpu_access(). Only when cpu access is bracketed by both calls is
|
||||
* it guaranteed to be coherent with other DMA access.
|
||||
*
|
||||
* This function will also wait for any DMA transactions tracked through
|
||||
@ -1418,7 +1418,7 @@ EXPORT_SYMBOL_NS_GPL(dma_buf_begin_cpu_access, DMA_BUF);
|
||||
* actions. Coherency is only guaranteed in the specified range for the
|
||||
* specified access direction.
|
||||
* @dmabuf: [in] buffer to complete cpu access for.
|
||||
* @direction: [in] length of range for cpu access.
|
||||
* @direction: [in] direction of access.
|
||||
*
|
||||
* This terminates CPU access started with dma_buf_begin_cpu_access().
|
||||
*
|
||||
|
@ -356,7 +356,7 @@ struct dma_buf {
|
||||
*/
|
||||
const char *name;
|
||||
|
||||
/** @name_lock: Spinlock to protect name acces for read access. */
|
||||
/** @name_lock: Spinlock to protect name access for read access. */
|
||||
spinlock_t name_lock;
|
||||
|
||||
/**
|
||||
@ -393,7 +393,7 @@ struct dma_buf {
|
||||
* anything the userspace API considers write access.
|
||||
*
|
||||
* - Drivers may just always add a write fence, since that only
|
||||
* causes unecessarily synchronization, but no correctness issues.
|
||||
* causes unnecessary synchronization, but no correctness issues.
|
||||
*
|
||||
* - Some drivers only expose a synchronous userspace API with no
|
||||
* pipelining across drivers. These do not set any fences for their
|
||||
|
Loading…
Reference in New Issue
Block a user