On Tue, Mar 25, 2014 at 07:01:10PM +0100, Sam Ravnborg wrote:
> >
> > There are two things that don't work too well with this. First this
> > causes the build to break if the build machine doesn't have the new
> > public header (include/uapi/linux/dma-buf.h) installed yet. So the only
> > way to make this work would be by building the kernel once with SAMPLES
> > disabled, install the headers and then build again with SAMPLES enabled.
> > Which really isn't very nice.
> >
> > One other option that I've tried is to modify the include path so that
> > the test program would get the in-tree copy of the public header file,
> > but that didn't build properly either because the header files aren't
> > properly sanitized and therefore the compiler complains about it
> > (include/uapi/linux/types.h).
> >
> > One other disadvantage of carrying the sample program in the tree is
> > that there's only infrastructure to build programs natively on the build
> > machine. That's somewhat unfortunate because if you want to run the test
> > program on a different architecture you have to either compile the
> > kernel natively on that architecture (which isn't very practical on many
> > embedded devices) or cross-compile manually.
> >
> > I think a much nicer solution would be to add infrastructure to cross-
> > compile these test programs, so that they end up being built for the
> > same architecture as the kernel image (i.e. using CROSS_COMPILE).
> >
> > Adding Michal and the linux-kbuild mailing list, perhaps this has been
> > discussed before, or maybe somebody has a better idea on how to solve
> > this.
> I actually looked into this some time ago.
> May try to dust off the patch.
> IIRC the kernel provided headers were used for building - not the one installed on the machine.
> And crosscompile were supported.
That sounds exactly like what I'd want for this. If you need any help,
please let me know.
Thanks,
Thierry
So after some more hacking I've moved dma-buf to its own subdirectory,
drivers/dma-buf and applied the fence patches to its new place. I believe that the
first patch should be applied regardless, and the rest should be ready now.
:-)
Changes to the fence api:
- release_fence -> fence_release etc.
- __fence_init -> fence_init
- __fence_signal -> fence_signal_locked
- __fence_is_signaled -> fence_is_signaled_locked
- Changing BUG_ON to WARN_ON in fence_later, and return NULL if it triggers.
Android can expose fences to userspace. It's possible to make the new fence
mechanism expose the same fences to userspace by changing sync_fence_create
to take a struct fence instead of a struct sync_pt. No other change is needed,
because only the fence parts of struct sync_pt are used. But because the
userspace fences are a separate problem and I haven't really looked at it yet
I feel it should stay in staging, for now.
---
Maarten Lankhorst (9):
dma-buf: move to drivers/dma-buf
fence: dma-buf cross-device synchronization (v18)
seqno-fence: Hardware dma-buf implementation of fencing (v6)
dma-buf: use reservation objects
android: convert sync to fence api, v6
reservation: add support for fences to enable cross-device synchronisation
dma-buf: add poll support, v3
reservation: update api and add some helpers
reservation: add suppport for read-only access using rcu
Documentation/DocBook/device-drivers.tmpl | 8
MAINTAINERS | 4
drivers/Makefile | 1
drivers/base/Kconfig | 9
drivers/base/Makefile | 1
drivers/base/dma-buf.c | 743 --------------------
drivers/base/reservation.c | 39 -
drivers/dma-buf/Makefile | 1
drivers/dma-buf/dma-buf.c | 907 ++++++++++++++++++++++++
drivers/dma-buf/fence.c | 431 +++++++++++
drivers/dma-buf/reservation.c | 477 +++++++++++++
drivers/dma-buf/seqno-fence.c | 73 ++
drivers/gpu/drm/armada/armada_gem.c | 2
drivers/gpu/drm/drm_prime.c | 8
drivers/gpu/drm/exynos/exynos_drm_dmabuf.c | 2
drivers/gpu/drm/i915/i915_gem_dmabuf.c | 3
drivers/gpu/drm/nouveau/nouveau_drm.c | 1
drivers/gpu/drm/nouveau/nouveau_gem.h | 1
drivers/gpu/drm/nouveau/nouveau_prime.c | 7
drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 2
drivers/gpu/drm/radeon/radeon_drv.c | 2
drivers/gpu/drm/radeon/radeon_prime.c | 8
drivers/gpu/drm/tegra/gem.c | 2
drivers/gpu/drm/ttm/ttm_object.c | 2
drivers/media/v4l2-core/videobuf2-dma-contig.c | 2
drivers/staging/android/Kconfig | 1
drivers/staging/android/Makefile | 2
drivers/staging/android/ion/ion.c | 3
drivers/staging/android/sw_sync.c | 6
drivers/staging/android/sync.c | 913 ++++++++----------------
drivers/staging/android/sync.h | 79 +-
drivers/staging/android/sync_debug.c | 247 ++++++
drivers/staging/android/trace/sync.h | 12
include/drm/drmP.h | 3
include/linux/dma-buf.h | 21 -
include/linux/fence.h | 360 +++++++++
include/linux/reservation.h | 82 ++
include/linux/seqno-fence.h | 116 +++
include/trace/events/fence.h | 128 +++
39 files changed, 3258 insertions(+), 1451 deletions(-)
delete mode 100644 drivers/base/dma-buf.c
delete mode 100644 drivers/base/reservation.c
create mode 100644 drivers/dma-buf/Makefile
create mode 100644 drivers/dma-buf/dma-buf.c
create mode 100644 drivers/dma-buf/fence.c
create mode 100644 drivers/dma-buf/reservation.c
create mode 100644 drivers/dma-buf/seqno-fence.c
create mode 100644 drivers/staging/android/sync_debug.c
create mode 100644 include/linux/fence.h
create mode 100644 include/linux/seqno-fence.h
create mode 100644 include/trace/events/fence.h
--
Signature
Hello,
This is one more respin of the patches which add support for creating
reserved memory regions defined in device tree. The last attempt
(http://lists.linaro.org/pipermail/linaro-mm-sig/2014-February/003738.html)
ended in merging only half of the code, so right now we have complete
documentation merged and only basic code, which implements a half of it
is written in the documentation. Although the merged patches allow to
reserve memory, there is no way of using it for devices and drivers.
This situation makes CMA rather useless, as the main architecture (ARM),
which used it, has been converted from board-file based system
initialization to device tree. Thus there is no place to use direct
calls to dma_declare_contiguous() and some new solution, which bases on
device tree, is urgently needed.
This patch series fixes this issue. It provides two, already widely
discussed and already present in the kernel, drivers for reserved
memory: first based on DMA-coherent allocator, second using Contiguous
Memory Allocator. The first one nicely implements typical 'carved out'
reserved memory way of allocating contiguous buffers in a kernel-style
way. The memory is used exclusively by devices assigned to the given
memory region. The second one allows to reuse reserved memory for
movable kernel pages (like disk buffers, anonymous memory) and migrates
it out when device to allocates contiguous memory buffer. Both driver
provides memory buffers via standard dma-mapping API.
The patches have been rebased on top of latest CMA and mm changes merged
to akmp kernel tree.
To define a 64MiB CMA region following node is needed:
multimedia_reserved: multimedia_mem_region {
compatible = "shared-dma-pool";
reusable;
size = <0x4000000>;
alignment = <0x400000>;
};
Similarly, one can define 64MiB region with DMA coherent memory:
multimedia_reserved: multimedia_mem_region {
compatible = "shared-dma-pool";
no-map;
size = <0x4000000>;
alignment = <0x400000>;
};
Then the defined region can be assigned to devices:
scaler: scaler@12500000 {
memory-region = <&multimedia_reserved>;
/* ... */
};
codec: codec@12600000 {
memory-region = <&multimedia_reserved>;
/* ... */
};
Best regards
Marek Szyprowski
Samsung R&D Institute Poland
Changes since the version posted in '[PATCH v6 00/11] reserved-memory
regions/CMA in devicetree, again' thread
http://lists.linaro.org/pipermail/linaro-mm-sig/2014-February/003738.html:
- rebased on top of '[PATCH v3 -next 0/9] CMA: generalize CMA reserved
area management code' patch series on v3.16-rc3
- improved dma-coherent driver, now it correctly handles assigning more
than one device to the given memory region
Patch summary:
Marek Szyprowski (4):
drivers: of: add automated assignment of reserved regions to client
devices
drivers: of: initialize and assign reserved memory to newly created
devices
drivers: dma-coherent: add initialization from device tree
drivers: dma-contiguous: add initialization from device tree
drivers/base/dma-coherent.c | 137 ++++++++++++++++++++++++++++++++++------
drivers/base/dma-contiguous.c | 67 ++++++++++++++++++++
drivers/of/of_reserved_mem.c | 70 ++++++++++++++++++++
drivers/of/platform.c | 7 ++
include/linux/cma.h | 3 +
include/linux/of_reserved_mem.h | 7 ++
mm/cma.c | 69 +++++++++++++++-----
7 files changed, 324 insertions(+), 36 deletions(-)
--
1.9.2
Hello,
I am trying to read a DMA buff ,allocated and manged by driver "A".
reader is a different driver "B" (which simply make DMA buffer accessible
by /proc to user space).
Can dmabuf APIs can be used for all reader and writer synchronization
issues ?
I want to use dmabuf between two drivers , do i need to go to user space
and use "fd" to get struct dma_buf * from dma_buf_get(int fd).
there is any way to use dmabuf APIs in kernel space only (between two
drivers ) without going to user space ?
example code will certainly help.
--
Regards
Rahul Dargainya
