Hi Dave,
On 17 May 2012 16:01, Dave Airlie airlied@gmail.com wrote:
From: Dave Airlie airlied@redhat.com
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.
Signed-off-by: Dave Airlie airlied@redhat.com
drivers/base/dma-buf.c | 34 ++++++++++++++++++++++++++++++++++ include/linux/dma-buf.h | 14 ++++++++++++++ 2 files changed, 48 insertions(+), 0 deletions(-)
diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c index 07cbbc6..750f92c 100644 --- a/drivers/base/dma-buf.c +++ b/drivers/base/dma-buf.c @@ -406,3 +406,37 @@ void dma_buf_kunmap(struct dma_buf *dmabuf, unsigned long page_num, dmabuf->ops->kunmap(dmabuf, page_num, vaddr); } EXPORT_SYMBOL_GPL(dma_buf_kunmap);
+/**
- dma_buf_vmap - Create virtual mapping for the buffer object into kernel address space. The same restrictions as for vmap and friends apply.
- @dma_buf: [in] buffer to vmap
- This call may fail due to lack of virtual mapping address space.
- These calls are optional in drivers. The intended use for them
- is for mapping objects linear in kernel space for high use objects.
- Please attempt to use kmap/kunmap before thinking about these interfaces.
- */
+void *dma_buf_vmap(struct dma_buf *dmabuf) +{
- if (WARN_ON(!dmabuf))
- return NULL;
- if (dmabuf->ops->vmap)
- return dmabuf->ops->vmap(dmabuf);
- return NULL;
+} +EXPORT_SYMBOL(dma_buf_vmap);
I am afraid we don't yet have a clear consensus on the usage of EXPORT_SYMBOL - till it is done, I would prefer that we use EXPORT_SYMBOL_GPL for consistency. Once we reach agreement, we can change them all in one go if required.
<snip>