user/sven/linux.git/include/linux/dma-buf.h, branch v3.14.68

dma-buf: update debugfs output

2014-02-13T04:38:52Z

Russell King observed 'wierd' looking output from debugfs, and also suggested better ways of getting device names (use KBUILD_MODNAME, dev_name()) This patch addresses these issues to make the debugfs output correct and better looking. While at it, replace seq_printf with seq_puts to remove the checkpatch.pl warnings. Reported-by: Russell King - ARM Linux Signed-off-by: Sumit Semwal

dma-buf: Add debugfs support

2013-05-01T11:06:22Z

Add debugfs support to make it easier to print debug information about the dma-buf buffers. Cc: Dave Airlie [minor fixes on init and warning fix] Cc: Dan Carpenter [remove double unlock in fail case] Signed-off-by: Sumit Semwal

dma-buf: replace dma_buf_export() with dma_buf_export_named()

2013-05-01T11:05:36Z

For debugging purposes, it is useful to have a name-string added while exporting buffers. Hence, dma_buf_export() is replaced with dma_buf_export_named(), which additionally takes 'exp_name' as a parameter. For backward compatibility, and for lazy exporters who don't wish to name themselves, a #define dma_buf_export() is also made available, which adds a __FILE__ instead of 'exp_name'. Cc: Daniel Vetter [Thanks for the idea!] Reviewed-by: Daniel Vetter Signed-off-by: Sumit Semwal

dma-buf: implement vmap refcounting in the interface logic

2013-02-27T09:43:36Z

All drivers which implement this need to have some sort of refcount to allow concurrent vmap usage. Hence implement this in the dma-buf core. To protect against concurrent calls we need a lock, which potentially causes new funny locking inversions. But this shouldn't be a problem for exporters with statically allocated backing storage, and more dynamic drivers have decent issues already anyway. Inspired by some refactoring patches from Aaron Plattner, who implemented the same idea, but only for drm/prime drivers. v2: Check in dma_buf_release that no dangling vmaps are left. Suggested by Aaron Plattner. We might want to do similar checks for attachments, but that's for another patch. Also fix up ERR_PTR return for vmap. v3: Check whether the passed-in vmap address matches with the cached one for vunmap. Eventually we might want to remove that parameter - compared to the kmap functions there's no need for the vaddr for unmapping. Suggested by Chris Wilson. v4: Fix a brown-paper-bag bug spotted by Aaron Plattner. Cc: Aaron Plattner Reviewed-by: Aaron Plattner Tested-by: Aaron Plattner Reviewed-by: Rob Clark Signed-off-by: Daniel Vetter Signed-off-by: Sumit Semwal

Merge branch 'master' into for-next

2013-01-29T09:48:30Z

Conflicts: drivers/devfreq/exynos4_bus.c Sync with Linus' tree to be able to apply patches that are against newer code (mvneta).

treewide: Fix typo in various drivers

2013-01-09T10:43:32Z

Correct spelling typo in printk within various drivers. Signed-off-by: Masanari Iida Signed-off-by: Jiri Kosina

dma-buf: remove fallback for !CONFIG_DMA_SHARED_BUFFER

2012-12-20T06:35:06Z

Documentation says that code requiring dma-buf should add it to select, so inline fallbacks are not going to be used. A link error will make it obvious what went wrong, instead of silently doing nothing at runtime. Signed-off-by: Maarten Lankhorst Reviewed-by: Daniel Vetter Reviewed-by: Rob Clark Signed-off-by: Sumit Semwal

dma-buf: minor documentation fixes.

2012-05-25T07:16:23Z

Some minor inline documentation fixes for gaps resulting from new patches. Signed-off-by: Sumit Semwal Signed-off-by: Sumit Semwal

dma-buf: add vmap interface

2012-05-25T07:05:24Z

The main requirement I have for this interface is for scanning out using the USB gpu devices. Since these devices have to read the framebuffer on updates and linearly compress it, using kmaps is a major overhead for every update. v2: fix warn issues pointed out by Sylwester Nawrocki. v3: fix compile !CONFIG_DMA_SHARED_BUFFER and add _GPL for now Signed-off-by: Dave Airlie Reviewed-by: Rob Clark Signed-off-by: Sumit Semwal

dma-buf: mmap support

2012-05-25T07:05:24Z

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 Cc: Rebecca Schultz Zavin Acked-by: Rob Clark Signed-Off-by: Daniel Vetter Signed-off-by: Sumit Semwal