Just wondering how we expect userspace to use dma-buf/prime interfaces.
Currently I see one driver in sharing the buffer with handle->fd, then
passing the fd to the other driver and it using fd->handle, do we then
expect the importing driver to close the fd?
Dave.
From: benjamin gaignard <benjamin.gaignard(a)linaro.org>
The goal of those patches is to allow ION clients (drivers or userland applications)
to use Contiguous Memory Allocator (CMA).
To get more info about CMA:
http://lists.linaro.org/pipermail/linaro-mm-sig/2012-February/001328.html
patches version 3:
- add a private field in ion_heap structure instead of expose ion_device
structure to all heaps
- ion_cma_heap is no more a platform driver
- ion_cma_heap use ion_heap private field to store the device pointer and
make the link with reserved CMA regions
- provide ux500-ion driver and configuration file for snowball board to give
an example of how use CMA heaps
patches version 2:
- fix comments done by Andy Green
Benjamin Gaignard (1):
fix ion_platform_data definition
add private field in ion_heap structure
add CMA heap
add test/example driver for ux500 platform
arch/arm/mach-ux500/board-mop500.c | 80 +++++++++++++++++++
drivers/gpu/ion/Kconfig | 6 ++
drivers/gpu/ion/Makefile | 2 +
drivers/gpu/ion/cma/Makefile | 1 +
drivers/gpu/ion/cma/ion_cma_heap.c | 126 ++++++++++++++++++++++++++++++
drivers/gpu/ion/cma/ion_cma_heap.h | 11 +++
drivers/gpu/ion/ion_priv.h | 2 +
drivers/gpu/ion/ux500/Makefile | 1 +
drivers/gpu/ion/ux500/ux500_ion.c | 147 ++++++++++++++++++++++++++++++++++++
include/linux/ion.h | 2 +-
10 files changed, 377 insertions(+), 1 deletions(-)
create mode 100644 drivers/gpu/ion/cma/Makefile
create mode 100644 drivers/gpu/ion/cma/ion_cma_heap.c
create mode 100644 drivers/gpu/ion/cma/ion_cma_heap.h
create mode 100644 drivers/gpu/ion/ux500/Makefile
create mode 100644 drivers/gpu/ion/ux500/ux500_ion.c
From: benjamin gaignard <benjamin.gaignard(a)linaro.org>
The goal of those patches is to allow ION clients (drivers or userland applications)
to use Contiguous Memory Allocator (CMA).
To get more info about CMA:
http://lists.linaro.org/pipermail/linaro-mm-sig/2012-February/001328.html
patches version 2:
fix comments done by Andy Green
Benjamin Gaignard (3):
make struct ion_device available for other heap
fix ion_platform_data definition
add CMA heap
drivers/gpu/ion/Kconfig | 5 +
drivers/gpu/ion/Makefile | 1 +
drivers/gpu/ion/cma/Makefile | 1 +
drivers/gpu/ion/cma/ion_cma_heap.c | 217 ++++++++++++++++++++++++++++++++++++
drivers/gpu/ion/ion.c | 20 ----
drivers/gpu/ion/ion_priv.h | 22 ++++
include/linux/ion.h | 2 +-
7 files changed, 247 insertions(+), 21 deletions(-)
create mode 100644 drivers/gpu/ion/cma/Makefile
create mode 100644 drivers/gpu/ion/cma/ion_cma_heap.c
Hi Stephen,
May I request you to please add the dma-buf buffer sharing framework
tree to linux-next?
It is hosted here
git://git.linaro.org/people/sumitsemwal/linux-dma-buf.git
branch: for-next
--
Thanks and nest regards,
Sumit Semwal.
Hi all,
This series here implements an interface to enable cpu access from the kernel
context to dma_buf objects. The main design goal of this interface proposal is
to enable buffer objects that reside in highmem.
Comments, flames, ideas and questions highly welcome. Althouhg I might be a bit
slow in responding - I'm on conferences and vacation the next 2 weeks.
Cheers, Daniel
Daniel Vetter (3):
dma-buf: don't hold the mutex around map/unmap calls
dma-buf: add support for kernel cpu access
dma_buf: Add documentation for the new cpu access support
Documentation/dma-buf-sharing.txt | 102 +++++++++++++++++++++++++++++-
drivers/base/dma-buf.c | 124 +++++++++++++++++++++++++++++++++++-
include/linux/dma-buf.h | 62 ++++++++++++++++++-
3 files changed, 280 insertions(+), 8 deletions(-)
--
1.7.7.5
Hi all,
Since the inclusion of dma-buf buffer sharing framework in 3.3 (thanks
to Dave Airlie primarily), I have been volunteered to be its
maintainer.
Obviously there is a need for some simple rules about the dma-buf
feature tree, so here we are:
- there will be a 'for-next' branch for (N+1), which will open around
-Nrc1, and close about 1-2 weeks before the (N+1)merge opens.
- there will be a 'fixes' branch, which will take fixes after the
for-next pull request is sent upstream.
- after -rc2, regression fixes only.
- after -rc4/5, only revert and disable patches. The real fix should
then be targeted at for-next.
- to stop me from pushing useless stuff, I will merge my own patches
only after sufficient review on our mailing lists. If you see me
breaking this rule, please shout out at me _publicly_ at the top of
your voice.
Being a 'first-time-maintainer', I am very willing to learn
on-the-job, though I might still take cover under the
'first-time-maintainer' umbrella [for sometime :)] for any stupid acts
I might commit.
The tree resides at: git://git.linaro.org/people/sumitsemwal/linux-dma-buf.git
At present, the mailing lists are: linux-media(a)vger.kernel.org,
dri-devel(a)lists.freedesktop.org, linaro-mm-sig(a)lists.linaro.org, in
addition to lkml.
Comments, flames and suggestions highly welcome.
(I have been 'influenced' quite a bit from Daniel Vetter's model for
the drm/i915 -next tree [thank you, DanVet!], but any errors/omissions
are entirely mine.)
Thanks and regards,
~Sumit.
I'm going to be off doing other things for the next couple of weeks, so
I'm dropping these now to give it a nice soak while I'm gone.
Dave/Daniel: if you could look these over and tell me if the general
direction seems good.
Ajax: anything you missing in the basic vgem stuff?
Since the last time:
Squashed down the original vgem patches
Use dumb_bo functions/ditched VGEM ioctls
Hooked up prime import and export support
On the prime side, the major difference from what Dave has done before
is a per driver hash of the previously used dma bufs/gem objects.
The prime stuff is of particularly low quality at this point, like I
said, trying to get something out before I disappear for a while. So
please don't yell at me about obvious bugs :). After getting feedback on
what I have now, I will incorporate Dave's earlier work on i915 prime,
and get some better test cases going.
On my todos:
Ascii chart of dmabuf/drm object life cycle
hashsify the per file list
i915 per driver hash
vgem-i915 and vice versa test cases
As before, the very basic tools are here:
git://people.freedesktop.org/~bwidawsk/vgem-gpu-tools
Once we get cpu maps that I think Daniel wants to work on, I can even do
better tests with just VGEM.
Adam Jackson (1):
drm/vgem: virtual GEM provider
Ben Widawsky (5):
drm: DRM_DEBUG_PRIME
drm: per device prime dma buf hash
drm/vgem: prime export support
drm/vgem: import support
drm: actually enable PRIME
Dave Airlie (1):
drm: base prime support
drivers/gpu/drm/Kconfig | 9 +
drivers/gpu/drm/Makefile | 3 +-
drivers/gpu/drm/drm_drv.c | 3 +
drivers/gpu/drm/drm_gem.c | 4 +
drivers/gpu/drm/drm_prime.c | 172 +++++++++++++++
drivers/gpu/drm/drm_stub.c | 8 +
drivers/gpu/drm/vgem/Makefile | 4 +
drivers/gpu/drm/vgem/vgem_dma_buf.c | 248 ++++++++++++++++++++++
drivers/gpu/drm/vgem/vgem_drv.c | 389 +++++++++++++++++++++++++++++++++++
drivers/gpu/drm/vgem/vgem_drv.h | 61 ++++++
include/drm/drm.h | 10 +-
include/drm/drmP.h | 55 +++++
12 files changed, 964 insertions(+), 2 deletions(-)
create mode 100644 drivers/gpu/drm/drm_prime.c
create mode 100644 drivers/gpu/drm/vgem/Makefile
create mode 100644 drivers/gpu/drm/vgem/vgem_dma_buf.c
create mode 100644 drivers/gpu/drm/vgem/vgem_drv.c
create mode 100644 drivers/gpu/drm/vgem/vgem_drv.h
--
1.7.9.1