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
Hello,
This is another update on my works DMA-mapping framework redesign for
ARM architecture. It includes a few minor cleanup and fixes since the
last version posted by the end of December 2011. This patch series is
now based on the generic, cross-arch dma-mapping redesign patches posted
in the "[PATCH 00/14] DMA-mapping framework redesign preparation"
thread: http://www.spinics.net/lists/linux-sh/msg09777.html
All patches have been now rebased onto v3.3-rc2 kernel.
All the code has been tested on Samsung Exynos4 'UniversalC210' board
with IOMMU driver posted by KyongHo Cho.
History of the development:
v1: (initial version of the DMA-mapping redesign patches):
http://www.spinics.net/lists/linux-mm/msg21241.html
v2:
http://lists.linaro.org/pipermail/linaro-mm-sig/2011-September/000571.htmlhttp://lists.linaro.org/pipermail/linaro-mm-sig/2011-September/000577.html
v3:
http://www.spinics.net/lists/linux-mm/msg25490.html
v4 and v5:
http://www.spinics.net/lists/arm-kernel/msg151147.htmlhttp://www.spinics.net/lists/arm-kernel/msg154889.html
Best regards
--
Marek Szyprowski
Samsung Poland R&D Center
Patch summary:
Marek Szyprowski (7):
ARM: dma-mapping: remove offset parameter to prepare for generic
dma_ops
ARM: dma-mapping: use asm-generic/dma-mapping-common.h
ARM: dma-mapping: implement dma sg methods on top of any generic dma
ops
ARM: dma-mapping: move all dma bounce code to separate dma ops
structure
ARM: dma-mapping: remove redundant code and cleanup
ARM: dma-mapping: use alloc, mmap, free from dma_ops
ARM: dma-mapping: add support for IOMMU mapper
arch/arm/Kconfig | 9 +
arch/arm/common/dmabounce.c | 78 +++-
arch/arm/include/asm/device.h | 4 +
arch/arm/include/asm/dma-iommu.h | 34 ++
arch/arm/include/asm/dma-mapping.h | 404 +++++------------
arch/arm/mm/dma-mapping.c | 897 ++++++++++++++++++++++++++++++------
arch/arm/mm/vmregion.h | 2 +-
7 files changed, 980 insertions(+), 448 deletions(-)
create mode 100644 arch/arm/include/asm/dma-iommu.h
--
1.7.1.569.g6f426