Hi Christian,
A few comments. See below:
Em 22-03-2012 11:54, Christian Robottom Reis escreveu:
Hey there,
We ran a call today on the topics of V4L2/dmabuf integration and theDMA 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;h=refs/heads/umm-3.3-wipLaurent, 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
It should be, instead:
Also wants to see tested with V4L virtual driver (vivi) also supporting dma-buf
wants both importer and exporter?
I want to simulate what's currently done with the Xorg v4l driver/xawtv and a board with overlay support, as the dma-buf is, on my understanding, a replacement for it.
ACTION: Sumit to look into VV driver used for v4l2 testing needs importer and exporter
s/VV/vivi/
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
Tried to take a few pictures on it, but they weren't clear enough.
What happens is that there's a connector to be soldered, in order to allow me to plug the camera daughter board. The connector Sumit sent me is higher on one of the sides. There is a small "peek" on it (probably, at the side that should match pin 1), as if it were expecting a hole at the board. Without either adding a hole at the motherboard or cutting the "peek", the pins can't be soldered.
Should I cut try to cut it? How do I know what's the right position of the connector?
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
A small addition to it: the applications should be either sent to the linux-media or, better, a link should be provided there, to allow to download the test environment.
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 addedTake care,