With this add a new attribute that can be passsed to dma-mapping IOMMU apis
to differentiate between kernel and user allcoations.
diff --git a/include/linux/dma-attrs.h b/include/linux/dma-attrs.h
index 547ab56..861df09 100644
--- a/include/linux/dma-attrs.h
+++ b/include/linux/dma-attrs.h
@@ -15,6 +15,7 @@ enum dma_attr {
DMA_ATTR_WEAK_ORDERING,
DMA_ATTR_WRITE_COMBINE,
DMA_ATTR_NON_CONSISTENT,
+ DMA_ATTR_USER_SPACE,
DMA_ATTR_MAX,
};
Hello,
This is a request for comments on dma-mapping patches for ARM. I
did some additions for issue related to kernel virtual memory allocations
in the iommu ops defined in dma-mapping framework.
The patches are based on:
git://git.linaro.org/people/mszyprowski/linux-dma-mapping.git3.4-rc3-arm-dm…
The code has been tested on Samsung Exynos5 SMDK5250.
These patches do the following:
1. Define a new dma attribute to identify user space allocation.
2. Add new wrapper functions to pass the dma attribute defined in (1)
above, as in the current framework there is no way to pass the new
attribute which can be used to differentiate between kernel and user
allocations.
3. Extend the existing arm_dma_ops for iommu enabled devices to
differentiate between kernel and user space allocations.
Patch summary:
[PATCH 1/3]:
Common: add DMA_ATTR_USER_SPACE to dma-attr. This can be passed to
arm_dma_ops to identify the type of allocation which can be either from
kernel or from user.
[PATCH 2/3]:
ARM: add "struct page_infodma" to hold information for allocated pages.
This can be attached to any of the devices which is making use of
dma-mapping APIs. Any interested device should allocate this structure and
store all the relevant information about the allocated pages to be able to
do a look up for all future references.
ARM: add dma_alloc_writecombine_user() function to pass DMA_ATTR_USER_SPACE
attribute
ARM: add dma_free_writecombine_user() function to pass DMA_ATTR_USER_SPACE
attribute
ARM: add dma_mmap_writecombine_user() function to pass DMA_ATTR_USER_SPACE
attribute
[PATCH 3/3]:
ARM: add check for allocation type in __dma_alloc_remap() function
ARM: add check for allocation type in arm_iommu_alloc_attrs() function
ARM: add check for allocation type in arm_iommu_mmap_attrs() function
ARM: re-used dma_addr as a flag to check for memory allocation type. It was
an unused argument and the prototype does not pass dma-attrs, so used this
as a means to pass the flag.
ARM: add check for allocation type in arm_iommu_free_attrs() function
arch/arm/include/asm/dma-mapping.h | 31 +++++++
arch/arm/mm/dma-mapping.c | 168
++++++++++++++++++++++++++----------
include/linux/dma-attrs.h | 1 +
3 files changed, 155 insertions(+), 45 deletions(-)
Hello everyone,
This patchset adds support for DMABUF [2] importing to V4L2 stack.
The support for DMABUF exporting was moved to separate patchset
due to dependency on patches for DMA mapping redesign by
Marek Szyprowski [4].
v5:
- removed change of importer/exporter behaviour
- fixes vb2_dc_pages_to_sgt basing on Laurent's hints
- changed pin/unpin words to lock/unlock in Doc
v4:
- rebased on mainline 3.4-rc2
- included missing importing support for s5p-fimc and s5p-tv
- added patch for changing map/unmap for importers
- fixes to Documentation part
- coding style fixes
- pairing {map/unmap}_dmabuf in vb2-core
- fixing variable types and semantic of arguments in videobufb2-dma-contig.c
v3:
- rebased on mainline 3.4-rc1
- split 'code refactor' patch to multiple smaller patches
- squashed fixes to Sumit's patches
- patchset is no longer dependant on 'DMA mapping redesign'
- separated path for handling IO and non-IO mappings
- add documentation for DMABUF importing to V4L
- removed all DMABUF exporter related code
- removed usage of dma_get_pages extension
v2:
- extended VIDIOC_EXPBUF argument from integer memoffset to struct
v4l2_exportbuffer
- added patch that breaks DMABUF spec on (un)map_atachment callcacks but allows
to work with existing implementation of DMABUF prime in DRM
- all dma-contig code refactoring patches were squashed
- bugfixes
v1: List of changes since [1].
- support for DMA api extension dma_get_pages, the function is used to retrieve
pages used to create DMA mapping.
- small fixes/code cleanup to videobuf2
- added prepare and finish callbacks to vb2 allocators, it is used keep
consistency between dma-cpu acess to the memory (by Marek Szyprowski)
- support for exporting of DMABUF buffer in V4L2 and Videobuf2, originated from
[3].
- support for dma-buf exporting in vb2-dma-contig allocator
- support for DMABUF for s5p-tv and s5p-fimc (capture interface) drivers,
originated from [3]
- changed handling for userptr buffers (by Marek Szyprowski, Andrzej
Pietrasiewicz)
- let mmap method to use dma_mmap_writecombine call (by Marek Szyprowski)
[1] http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/4296…
[2] https://lkml.org/lkml/2011/12/26/29
[3] http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/3635…
[4] http://thread.gmane.org/gmane.linux.kernel.cross-arch/12819
Andrzej Pietrasiewicz (1):
v4l: vb2-dma-contig: add support for scatterlist in userptr mode
Laurent Pinchart (2):
v4l: vb2-dma-contig: Shorten vb2_dma_contig prefix to vb2_dc
v4l: vb2-dma-contig: Reorder functions
Marek Szyprowski (2):
v4l: vb2: add prepare/finish callbacks to allocators
v4l: vb2-dma-contig: add prepare/finish to dma-contig allocator
Sumit Semwal (4):
v4l: Add DMABUF as a memory type
v4l: vb2: add support for shared buffer (dma_buf)
v4l: vb: remove warnings about MEMORY_DMABUF
v4l: vb2-dma-contig: add support for dma_buf importing
Tomasz Stanislawski (4):
Documentation: media: description of DMABUF importing in V4L2
v4l: vb2-dma-contig: Remove unneeded allocation context structure
v4l: s5p-tv: mixer: support for dmabuf importing
v4l: s5p-fimc: support for dmabuf importing
Documentation/DocBook/media/v4l/compat.xml | 4 +
Documentation/DocBook/media/v4l/io.xml | 179 +++++++
.../DocBook/media/v4l/vidioc-create-bufs.xml | 1 +
Documentation/DocBook/media/v4l/vidioc-qbuf.xml | 15 +
Documentation/DocBook/media/v4l/vidioc-reqbufs.xml | 47 +-
drivers/media/video/Kconfig | 1 +
drivers/media/video/s5p-fimc/fimc-capture.c | 2 +-
drivers/media/video/s5p-tv/Kconfig | 1 +
drivers/media/video/s5p-tv/mixer_video.c | 2 +-
drivers/media/video/videobuf-core.c | 4 +
drivers/media/video/videobuf2-core.c | 207 ++++++++-
drivers/media/video/videobuf2-dma-contig.c | 529 +++++++++++++++++---
include/linux/videodev2.h | 7 +
include/media/videobuf2-core.h | 34 ++
14 files changed, 932 insertions(+), 101 deletions(-)
--
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