diff options
Diffstat (limited to 'Documentation/dma-buf-sharing.txt')
| -rw-r--r-- | Documentation/dma-buf-sharing.txt | 31 |
1 files changed, 26 insertions, 5 deletions
diff --git a/Documentation/dma-buf-sharing.txt b/Documentation/dma-buf-sharing.txt index 4966b1be42a..67a4087d53f 100644 --- a/Documentation/dma-buf-sharing.txt +++ b/Documentation/dma-buf-sharing.txt @@ -52,14 +52,23 @@ The dma_buf buffer sharing API usage contains the following steps: associated with this buffer. Interface: - struct dma_buf *dma_buf_export(void *priv, struct dma_buf_ops *ops, - size_t size, int flags) + struct dma_buf *dma_buf_export_named(void *priv, struct dma_buf_ops *ops, + size_t size, int flags, + const char *exp_name) If this succeeds, dma_buf_export allocates a dma_buf structure, and returns a pointer to the same. It also associates an anonymous file with this buffer, so it can be exported. On failure to allocate the dma_buf object, it returns NULL. + 'exp_name' is the name of exporter - to facilitate information while + debugging. + + Exporting modules which do not wish to provide any specific name may use the + helper define 'dma_buf_export()', with the same arguments as above, but + without the last argument; a KBUILD_MODNAME pre-processor directive will be + inserted in place of 'exp_name' instead. + 2. Userspace gets a handle to pass around to potential buffer-users Userspace entity requests for a file-descriptor (fd) which is a handle to the @@ -208,7 +217,7 @@ NOTES: and then allow further {map,unmap}_dma_buf operations from any buffer-user from the migrated backing-storage. - If the exporter cannot fulfil the backing-storage constraints of the new + If the exporter cannot fulfill the backing-storage constraints of the new buffer-user device as requested, dma_buf_attach() would return an error to denote non-compatibility of the new buffer-sharing request with the current buffer. @@ -312,7 +321,7 @@ Access to a dma_buf from the kernel context involves three steps: When the importer is done accessing the range specified in begin_cpu_access, it needs to announce this to the exporter (to facilitate cache flushing and - unpinning of any pinned resources). The result of of any dma_buf kmap calls + unpinning of any pinned resources). The result of any dma_buf kmap calls after end_cpu_access is undefined. Interface: @@ -343,7 +352,7 @@ Being able to mmap an export dma-buf buffer object has 2 main use-cases: No special interfaces, userspace simply calls mmap on the dma-buf fd. -2. Supporting existing mmap interfaces in exporters +2. Supporting existing mmap interfaces in importers 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 @@ -398,6 +407,18 @@ Being able to mmap an export dma-buf buffer object has 2 main use-cases: interesting ways depending upong the exporter (if userspace starts depending upon this implicit synchronization). +Other Interfaces Exposed to Userspace on the dma-buf FD +------------------------------------------------------ + +- Since kernel 3.12 the dma-buf FD supports the llseek system call, but only + with offset=0 and whence=SEEK_END|SEEK_SET. SEEK_SET is supported to allow + the usual size discover pattern size = SEEK_END(0); SEEK_SET(0). Every other + llseek operation will report -EINVAL. + + If llseek on dma-buf FDs isn't support the kernel will report -ESPIPE for all + cases. Userspace can use this to detect support for discovering the dma-buf + size using llseek. + Miscellaneous notes ------------------- |