From: Rob Clark <rob(a)ti.com>
Works in a similar way to get_file(), and is needed in cases such as
when the exporter needs to also keep a reference to the dmabuf (that
is later released with a dma_buf_put()), and possibly other similar
cases.
Signed-off-by: Rob Clark <rob(a)ti.com>
---
include/linux/dma-buf.h | 14 ++++++++++++++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index cbdff81..25eb287 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -132,6 +132,20 @@ struct dma_buf_attachment {
void *priv;
};
+/**
+ * get_dma_buf - convenience wrapper for get_file.
+ * @dmabuf: [in] pointer to dma_buf
+ *
+ * Increments the reference count on the dma-buf, needed in case of drivers
+ * that either need to create additional references to the dmabuf on the
+ * kernel side. For example, an exporter that needs to keep a dmabuf ptr
+ * so that subsequent exports don't create a new dmabuf.
+ */
+static inline void get_dma_buf(struct dma_buf *dmabuf)
+{
+ get_file(dmabuf->file);
+}
+
#ifdef CONFIG_DMA_SHARED_BUFFER
struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
struct device *dev);
--
1.7.5.4
Hey there,
We ran a call today on the topics of V4L2/dmabuf integration and the
DMA mapping changes; I've included minutes and actions below.
In summary:
- We're not going to see the V4L2 patches in 3.4; they haven't had
enough review or testing and Mauro is very busy this merge window.
- We're going to put in effort to validate the work on Exynos4 and
OMAP4 using test applications that Rob and Tomasz are maintaining.
- Sumit's maintaining an up-to-date branch containing all the
in-flight DRM/V4L2/dmabuf-dependent work that we can carry
meanwhile:
http://git.linaro.org/gitweb?p=people/sumitsemwal/linux-3.x.git;a=shortlog;…
Laurent, I missed one thing that you mentioned in the call and it's
included in an XXX: below; if you could note what it was it would be
great.
Please feel free to correct my possibly wild misunderstandings in the
minutes and summary above. Thanks!
Attendees are all on the To: line.
Tomasz: At the moment, have PoC support for import/export dma-buf
for V4L2
Modified patches by Sumit
Supporting importer of dma-buf
Exynos DRM and drm-prime
Test application worked fine for V4L capture and DRM output
Test application between two V4L devices
Laurent has sent in review comments
Tomasz: proposed extension to DMA Mapping -- dma_get_pages
Currently difficult to change the camera address into list of pages
DMA framework has the knowledge of this list and could do this
Depends on dma_get_pages
Needs to be merged first
Test application posted to dri-devel with dependencies to run demo
Many dependencies
Topic: dmabuf importer from V4L2
For sharing with DRM do not need exporter
Need some patches added to DRM
prime
prime for Exynos
drm-prime
ACTION: Tomasz to check with Inki Dae and David A. on
status
Will send request to Mauro?
Doesn't think so, won't have enough time for testing
RC is already open -- not enough time for that
API details needs consideration
Depends on how much time current project
2-3 weeks after the merge window closes
1 month to actually review
Would like to see Exynos working
Mauro has a Samsung V310/Exynos4 dev board
Also wants to see tested with V4L driver
virtual drivers also supporting dma-buf
wants both importer and exporter?
ACTION: Sumit to look into VV driver used for v4l2 testing
needs importer and exporter
Laurent has work that he can push forward in parallel
API change ioctl addition that could be reviewed
Rob: the demo had V4L importer and DRM exporter (?)
There are some changes for prime changes
Laurent: needs to implement importer/exporter camera piece
With drm-prime-dmabuf patches drivers can be simplified
Sumit: we have a new 3.3-WIP branch
Rob could use that as a base and put DRM updates on it
ACTION: Rob to pull in changes and update demonstration
Rob: what camera does Mauro have?
On the Samsung SDK, M5MOLS
Mauro does have a Pandaboard with ov5650 camera but
needs setting up and potential hardware mod
ACTION: Mauro to take picture of setup for Sumit
As a backup Rob could add a Tested-By for the changes
Mauro essentially wants a test on
With CPU access in dmabuf can use vmalloc
Without dependency on dma mapping at all
Without Russell's acceptance can't go forward with ARM-related
pieces
ACTION: Kiko to check with Nicolas on this piece, see if he
can review or help Marek with the ARM-related pieces
Tomasz could use the 3.3-WIP branch
Sumit: rebasing not a good idea, but could pull in for-next
Suggests Tomasz bases work on Linus' mainline
Had problems with Tomasz' branch that is based on -next
His branch includes Tomasz RFCv2 patches as well
Laurent: agree with Sumit
ACTION: Sumit to email Tomasz and CC: Inki Dae
ACTION: send around latest drm-prime branch
Tomasz: so no XXX: exporter support for V4L?
Laurent: doesn't have time to update XXX at the moment
Needs porting to videobuf2
Rob: Looks like Daniel V. has also replied to the V4L patches so
it's going to be hard for 3.4
Mauro's lack of time makes 3.4 not possible anyway
mmap support also likely to miss 3.4
EGLImage extension needs sorting out
Can be carried in our WIP branch meanwhile
Mauro: what are the test applications being used for dmabuf?
Rob: using Panda with camera adapter board (omap-drm)
Would like others to have similar setups
Requires YUV sensor, but there are patches that support the
RAW YUV conversion which allows other sensors to be used
Mauro: but what software app are you using?
Rob: has test code in github:
https://github.com/robclark/omapdrmtest
Tomasz:
Have posted one test application on dri-devel (March 6th)
http://www.spinics.net/lists/dri-devel/msg19634.html
Second application posted to linux-media
As a reply to RFCv1 dma-buf V4L2 patches (Jan 26th)
http://www.mail-archive.com/linux-media@vger.kernel.org/msg42522.html
Mauro: include both applications together with patches when
posting
Sumit: could ask Inki to provide similar exynos-drm test application
in parallel to Rob's omap-drm; same interface will simplify
testing
Marek:
device-to-device coordinate will be needed
Will start next week ideally
For a device-to-device operation, need this to avoid touching
CPU cache
Not sure about ARM stuff for 3.4; need review
If they don't go in, will keep on dma-mapping-next
Konrad's comments are addressed and Reviewed-bys added
Take care,
--
Christian Robottom Reis, Engineering VP
Brazil (GMT-3) | [+55] 16 9112 6430 | [+1] 612 216 4935
Linaro.org: Open Source Software for ARM SoCs
Hello,
This is yet another update on my works DMA-mapping framework redesign
for ARM architecture. It includes a few minor cleanup and fixes reported
by Konrad Rzeszutek Wilk and Krishna Reddy.
This version uses vmalloc for allocating page pointers array if it is
larger than PAGE_SIZE. The chained allocation which fits inside a set of
PAGE_SIZE units will be added later, once the base patches are merged.
Like the previous version, this patchset is also 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-rc5 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
v6:
http://www.spinics.net/lists/linux-mm/msg29903.html
Best regards
--
Marek Szyprowski
Samsung Poland R&D Center
Patch summary:
Marek Szyprowski (9):
ARM: dma-mapping: introduce ARM_DMA_ERROR constant
ARM: dma-mapping: use pr_* instread of printk
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 | 84 +++-
arch/arm/include/asm/device.h | 4 +
arch/arm/include/asm/dma-iommu.h | 34 ++
arch/arm/include/asm/dma-mapping.h | 407 ++++-----------
arch/arm/mm/dma-mapping.c | 1013 ++++++++++++++++++++++++++++++------
arch/arm/mm/vmregion.h | 2 +-
7 files changed, 1088 insertions(+), 465 deletions(-)
create mode 100644 arch/arm/include/asm/dma-iommu.h
--
1.7.1.569.g6f426
Hi Linus,
I would like to ask again for pulling the dma-mapping framework updates for v3.4.
The following changes since commit c16fa4f2ad19908a47c63d8fa436a1178438c7e7:
Linux 3.3 (2012-03-18 16:15:34 -0700)
with the top-most commit 64d70fe5d3640e1a89790ed21120921278f8cb86
common: DMA-mapping: add NON-CONSISTENT attribute
from the git repository at:
git://git.linaro.org/people/mszyprowski/linux-dma-mapping.git for-linus
This is an updated version of the patches which have been earlier rejected,
see the following thread:
https://lkml.org/lkml/2012/3/20/29
I hope I've fixed the issues pointed there:
- collected a few more acks from arch maintainers,
- resolved signed-off-by weirdness,
- removed dependences between the patches.
Short summary for the whole series:
A few limitations have been identified in the current dma-mapping design and
its implementations for various architectures. There exist more than one function
for allocating and freeing the buffers: currently these 3 are used dma_{alloc,
free}_coherent, dma_{alloc,free}_writecombine, dma_{alloc,free}_noncoherent.
For most of the systems these calls are almost equivalent and can be interchanged.
For others, especially the truly non-coherent ones (like ARM), the difference can
be easily noticed in overall driver performance. Sadly not all architectures
provide implementations for all of them, so the drivers might need to be adapted
and cannot be easily shared between different architectures. The provided patches
unify all these functions and hide the differences under the already existing
dma attributes concept. The thread with more references is available here:
http://www.spinics.net/lists/linux-sh/msg09777.html
These patches are also a prerequisite for unifying DMA-mapping implementation
on ARM architecture with the common one provided by dma_map_ops structure and
extending it with IOMMU support. More information is available in the following
thread: http://thread.gmane.org/gmane.linux.kernel.cross-arch/12819
More works on dma-mapping framework are planned, especially in the area of buffer
sharing and managing the shared mappings (together with the recently introduced
dma_buf interface: commit d15bd7ee445d0702ad801fdaece348fdb79e6581 "dma-buf:
Introduce dma buffer sharing mechanism").
The patches in the current set introduce a new alloc/free methods (with
support for memory attributes) in dma_map_ops structure, which will
later replace dma_alloc_coherent and dma_alloc_writecombine functions.
Thanks!
Best regards
Marek Szyprowski
Samsung Poland R&D Center
Patch summary:
Andrzej Pietrasiewicz (8):
X86 & IA64: adapt for dma_map_ops changes
MIPS: adapt for dma_map_ops changes
PowerPC: adapt for dma_map_ops changes
SPARC: adapt for dma_map_ops changes
Alpha: adapt for dma_map_ops changes
SH: adapt for dma_map_ops changes
Microblaze: adapt for dma_map_ops changes
Unicore32: adapt for dma_map_ops changes
Marek Szyprowski (6):
common: dma-mapping: introduce generic alloc() and free() methods
Hexagon: adapt for dma_map_ops changes
common: dma-mapping: remove old alloc_coherent and free_coherent methods
common: dma-mapping: introduce mmap method
common: DMA-mapping: add WRITE_COMBINE attribute
common: DMA-mapping: add NON-CONSISTENT attribute
Documentation/DMA-attributes.txt | 18 ++++++++++++++++++
arch/alpha/include/asm/dma-mapping.h | 18 ++++++++++++------
arch/alpha/kernel/pci-noop.c | 10 ++++++----
arch/alpha/kernel/pci_iommu.c | 10 ++++++----
arch/hexagon/include/asm/dma-mapping.h | 18 ++++++++++++------
arch/hexagon/kernel/dma.c | 9 +++++----
arch/ia64/hp/common/sba_iommu.c | 11 ++++++-----
arch/ia64/include/asm/dma-mapping.h | 18 ++++++++++++------
arch/ia64/kernel/pci-swiotlb.c | 14 +++++++++++---
arch/ia64/sn/pci/pci_dma.c | 9 +++++----
arch/microblaze/include/asm/dma-mapping.h | 18 ++++++++++++------
arch/microblaze/kernel/dma.c | 10 ++++++----
arch/mips/cavium-octeon/dma-octeon.c | 12 ++++++------
arch/mips/include/asm/dma-mapping.h | 18 ++++++++++++------
arch/mips/mm/dma-default.c | 8 ++++----
arch/powerpc/include/asm/dma-mapping.h | 24 ++++++++++++++++--------
arch/powerpc/kernel/dma-iommu.c | 10 ++++++----
arch/powerpc/kernel/dma-swiotlb.c | 4 ++--
arch/powerpc/kernel/dma.c | 10 ++++++----
arch/powerpc/kernel/ibmebus.c | 10 ++++++----
arch/powerpc/kernel/vio.c | 14 ++++++++------
arch/powerpc/platforms/cell/iommu.c | 16 +++++++++-------
arch/powerpc/platforms/ps3/system-bus.c | 13 +++++++------
arch/sh/include/asm/dma-mapping.h | 28 ++++++++++++++++++----------
arch/sh/kernel/dma-nommu.c | 4 ++--
arch/sh/mm/consistent.c | 6 ++++--
arch/sparc/include/asm/dma-mapping.h | 18 ++++++++++++------
arch/sparc/kernel/iommu.c | 10 ++++++----
arch/sparc/kernel/ioport.c | 18 ++++++++++--------
arch/sparc/kernel/pci_sun4v.c | 9 +++++----
arch/unicore32/include/asm/dma-mapping.h | 18 ++++++++++++------
arch/unicore32/mm/dma-swiotlb.c | 18 ++++++++++++++++--
arch/x86/include/asm/dma-mapping.h | 26 ++++++++++++++++----------
arch/x86/kernel/amd_gart_64.c | 11 ++++++-----
arch/x86/kernel/pci-calgary_64.c | 9 +++++----
arch/x86/kernel/pci-dma.c | 3 ++-
arch/x86/kernel/pci-nommu.c | 6 +++---
arch/x86/kernel/pci-swiotlb.c | 17 +++++++++++++----
arch/x86/xen/pci-swiotlb-xen.c | 4 ++--
drivers/iommu/amd_iommu.c | 10 ++++++----
drivers/iommu/intel-iommu.c | 9 +++++----
drivers/xen/swiotlb-xen.c | 5 +++--
include/linux/dma-attrs.h | 2 ++
include/linux/dma-mapping.h | 13 +++++++++----
include/xen/swiotlb-xen.h | 6 ++++--
45 files changed, 354 insertions(+), 198 deletions(-)
