Re: [PATCH v2] media i.MX27 camera: properly detect frame loss.
Hi Guennadi, thank you for your attention. I've recently sent a new patch series on top of this patch: [PATCH 0/4] media i.MX27 camera: fix buffer handling and videobuf2 support. (http://www.mail-archive.com/linux-media@vger.kernel.org/msg42255.html) Among other things, it adds videobuf2 support and adds stream_stop and stream_start callbacks which allow to enable/disable capturing of buffers at the right moment. This also makes the sequence number trick disappear and a much cleaner approach is used instead. I suggest you hold on this patch until the new series is accepted and then merge both at the same time. What do you think? -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] convert drivers/media/* to use module_i2c_driver()
Hi, For module s5p-tv/hdmiphy Acked-by: Tomasz Stanislawski t.stanisl...@samsung.com -- Regards, Tomasz Stanislawski -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFCv1 2/4] v4l:vb2: add support for shared buffer (dma_buf)
Hello, On Friday, January 20, 2012 5:29 PM Laurent Pinchart wrote: On Friday 20 January 2012 17:20:22 Tomasz Stanislawski wrote: IMO, One way to do this is adding field 'struct device *dev' to struct vb2_queue. This field should be filled by a driver prior to calling vb2_queue_init. I haven't looked into the details, but that sounds good to me. Do we have use cases where a queue is allocated before knowing which physical device it will be used for ? I don't think so. In case of S5P drivers, vb2_queue_init is called while opening /dev/videoX. BTW. This struct device may help vb2 to produce logs with more descriptive client annotation. What happens if such a device is NULL. It would happen for vmalloc allocator used by VIVI? Good question. Should dma-buf accept NULL devices ? Or should vivi pass its V4L2 device to vb2 ? I assume you suggested using struct video_device-dev entry in such case. It will not work. DMA-mapping API requires some parameters to be set for the client device, like for example dma mask. struct video_device contains only an artificial struct device entry, which has no relation to any physical device and cannot be used for calling DMA-mapping functions. Performing dma_map_* operations with such artificial struct device doesn't make any sense. It also slows down things significantly due to cache flushing (forced by dma-mapping) which should be avoided if the buffer is accessed only with CPU (like it is done by vb2-vmalloc style drivers). IMHO this case perfectly shows the design mistake that have been made. The current version simply tries to do too much. Each client of dma_buf should 'map' the provided sgtable/scatterlist on its own. Only the client device driver has all knowledge to make a proper 'mapping'. Real physical devices usually will use dma_map_sg() for such operation, while some virtual ones will only create a kernel mapping for the provided scatterlist (like vivi with vmalloc memory module). Best regards -- Marek Szyprowski Samsung Poland RD Center -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: problems with building newest media_build.git commit 17f42a807d5d6e7e783f0498916411a5e595edb6
On Monday 23 January 2012 01:18:05 Daniel Schroll wrote: Hi all, I am trying to build the last driver-set in order to get my dvbc USB-Stick Terratec Cinergy HTC Stick HD running. output of lsusb Bus 001 Device 009: ID 0ccd:00b2 TerraTec Electronic GmbH I followed the instructions on http://linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_ Device_Drivers#Building.2FCompiling_the_Modules the build-process of the commit 17f42a807d5d6e7e783f0498916411a5e595edb6 ended in errors: CC [M] /home/user/Downloads/git/media_build/v4l/saa7134-dvb.o LD [M] /home/user/Downloads/git/media_build/v4l/cx88xx.o LD [M] /home/user/Downloads/git/media_build/v4l/cx8800.o LD [M] /home/user/Downloads/git/media_build/v4l/cx8802.o CC [M] /home/user/Downloads/git/media_build/v4l/cx88-alsa.o CC [M] /home/user/Downloads/git/media_build/v4l/cx88-blackbird.o CC [M] /home/user/Downloads/git/media_build/v4l/cx88-dvb.o CC [M] /home/user/Downloads/git/media_build/v4l/cx88-vp3054-i2c.o LD [M] /home/user/Downloads/git/media_build/v4l/em28xx.o LD [M] /home/user/Downloads/git/media_build/v4l/em28xx-alsa.o CC [M] /home/user/Downloads/git/media_build/v4l/em28xx-dvb.o LD [M] /home/user/Downloads/git/media_build/v4l/poseidon.o LD [M] /home/user/Downloads/git/media_build/v4l/cx231xx.o LD [M] /home/user/Downloads/git/media_build/v4l/cx231xx-alsa.o CC [M] /home/user/Downloads/git/media_build/v4l/cx231xx-dvb.o LD [M] /home/user/Downloads/git/media_build/v4l/cx25821.o CC [M] /home/user/Downloads/git/media_build/v4l/cx25821-alsa.o /home/user/Downloads/git/media_build/v4l/cx25821-alsa.c:23:0: warning: pr_fmt redefined [enabled by default] include/linux/printk.h:152:0: note: this is the location of the previous definition LD [M] /home/user/Downloads/git/media_build/v4l/usbvision.o LD [M] /home/user/Downloads/git/media_build/v4l/pvrusb2.o LD [M] /home/user/Downloads/git/media_build/v4l/cpia2.o LD [M] /home/user/Downloads/git/media_build/v4l/tm6000.o CC [M] /home/user/Downloads/git/media_build/v4l/tm6000-alsa.o CC [M] /home/user/Downloads/git/media_build/v4l/tm6000-dvb.o CC [M] /home/user/Downloads/git/media_build/v4l/mxb.o /home/user/Downloads/git/media_build/v4l/mxb.c:24:0: warning: pr_fmt redefined [enabled by default] include/linux/printk.h:152:0: note: this is the location of the previous definition CC [M] /home/user/Downloads/git/media_build/v4l/hexium_orion.o /home/user/Downloads/git/media_build/v4l/hexium_orion.c:24:0: warning: pr_fmt redefined [enabled by default] include/linux/printk.h:152:0: note: this is the location of the previous definition CC [M] /home/user/Downloads/git/media_build/v4l/hexium_gemini.o /home/user/Downloads/git/media_build/v4l/hexium_gemini.c:24:0: warning: pr_fmt redefined [enabled by default] include/linux/printk.h:152:0: note: this is the location of the previous definition CC [M] /home/user/Downloads/git/media_build/v4l/timblogiw.o /home/user/Downloads/git/media_build/v4l/timblogiw.c: In function 'buffer_queue': /home/user/Downloads/git/media_build/v4l/timblogiw.c:568:22: error: 'DMA_DEV_TO_MEM' undeclared (first use in this function) /home/user/Downloads/git/media_build/v4l/timblogiw.c:568:22: note: each undeclared identifier is reported only once for each function it appears in make[3]: *** [/home/user/Downloads/git/media_build/v4l/timblogiw.o] Error 1 make[2]: *** [_module_/home/user/Downloads/git/media_build/v4l] Error 2 make[2]: Leaving directory `/usr/src/linux-headers-3.0.0-15-generic' make[1]: *** [default] Error 2 make[1]: Leaving directory `/home/user/Downloads/git/media_build/v4l' make: *** [all] Error 2 build failed at ./build line 383. I tried to build the previous commit (25c307ca24b03caff9e289daf179a1a5629c798d), too, but it resulted in the same errors. My System: Intel Atom D525 CPU (ASUS S1-AT5NM10E) Ubuntu 11.10 with 3.0.0-15-generic x86_64 Kernel Hope, that no important informations are missing. Fixed in the latest media_build. Thanks for the report. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] media i.MX27 camera: properly detect frame loss.
Hi Javier On Mon, 23 Jan 2012, javier Martin wrote: Hi Guennadi, thank you for your attention. I've recently sent a new patch series on top of this patch: [PATCH 0/4] media i.MX27 camera: fix buffer handling and videobuf2 support. (http://www.mail-archive.com/linux-media@vger.kernel.org/msg42255.html) Among other things, it adds videobuf2 support and adds stream_stop and stream_start callbacks which allow to enable/disable capturing of buffers at the right moment. This also makes the sequence number trick disappear and a much cleaner approach is used instead. I suggest you hold on this patch until the new series is accepted and then merge both at the same time. What do you think? Ok, I'll be reviewing that patch series hopefully soon, and in principle it is good, that the buffer counting will really be fixed in it, but in an ideal world it would be better to have this your patch merged into patch 2/4 of the series, agree? Would I be asking too much of you if I suggest that? Feel free to explain why this wouldn't work or just reject if you're just too tight on schedule. I'll see ifI can swallow it that way or maybe merge myself :-) Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] media i.MX27 camera: properly detect frame loss.
Hi Guennadi, I suggest you hold on this patch until the new series is accepted and then merge both at the same time. What do you think? Ok, I'll be reviewing that patch series hopefully soon, and in principle it is good, that the buffer counting will really be fixed in it, but in an ideal world it would be better to have this your patch merged into patch 2/4 of the series, agree? Would I be asking too much of you if I suggest that? Feel free to explain why this wouldn't work or just reject if you're just too tight on schedule. I'll see ifI can swallow it that way or maybe merge myself :-) If you, Sascha, or someone else comes up with some requests or fixes to the new series I don't mind to rebase it so you can just ignore this patch, since I would have to sent a v2 version of the series anyway. Regards. -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL] a fix for 3.3
Hi Mauro The following change since commit 9e5e3097a3febbf317abc6d1b07bc6c33b20c279: [media] az6007: CodingStyle fixes (2012-01-21 13:52:39 -0200) is available in the git repository at: git://linuxtv.org/gliakhovetski/v4l-dvb.git 3.3-rc1-fixes Josh Wu (1): V4L: atmel-isi: add clk_prepare()/clk_unprepare() functions drivers/media/video/atmel-isi.c | 14 ++ 1 files changed, 14 insertions(+), 0 deletions(-) Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] convert drivers/media/* to use module_i2c_driver()
For modules: adv7170 adv7175 bt819 bt856 bt866 cs5345 cx53l32a cx25840-core indycam ks0127 m52790 msp3400-driver saa6588 saa6752hs saa7110 saa7115 saa7127 saa717x saa7191 tda7432 tda9840 tea6415c tea6420 tlv320aic23b tuner-core tvaudio upd64031a upd64083 vp27smpx wm8739 wm8775 Acked-by: Hans Verkuil hans.verk...@cisco.com Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv1 2/4] v4l:vb2: add support for shared buffer (dma_buf)
On Mon, Jan 23, 2012 at 10:06:57AM +0100, Marek Szyprowski wrote: Hello, On Friday, January 20, 2012 5:29 PM Laurent Pinchart wrote: On Friday 20 January 2012 17:20:22 Tomasz Stanislawski wrote: IMO, One way to do this is adding field 'struct device *dev' to struct vb2_queue. This field should be filled by a driver prior to calling vb2_queue_init. I haven't looked into the details, but that sounds good to me. Do we have use cases where a queue is allocated before knowing which physical device it will be used for ? I don't think so. In case of S5P drivers, vb2_queue_init is called while opening /dev/videoX. BTW. This struct device may help vb2 to produce logs with more descriptive client annotation. What happens if such a device is NULL. It would happen for vmalloc allocator used by VIVI? Good question. Should dma-buf accept NULL devices ? Or should vivi pass its V4L2 device to vb2 ? I assume you suggested using struct video_device-dev entry in such case. It will not work. DMA-mapping API requires some parameters to be set for the client device, like for example dma mask. struct video_device contains only an artificial struct device entry, which has no relation to any physical device and cannot be used for calling DMA-mapping functions. Performing dma_map_* operations with such artificial struct device doesn't make any sense. It also slows down things significantly due to cache flushing (forced by dma-mapping) which should be avoided if the buffer is accessed only with CPU (like it is done by vb2-vmalloc style drivers). IMHO this case perfectly shows the design mistake that have been made. The current version simply tries to do too much. Nope, the current dma_buf does too little. Atm it's simple not useable for drivers that need cpu access, at least not if you're willing to resort to ugly an non-portable tricks like prime. We've discussed this quite a bit and decided that solving cpu access and coherency with n other devices involved is too much v1. It looks like we need to add that extension rather sooner than later. -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv1 2/4] v4l:vb2: add support for shared buffer (dma_buf)
On Mon, Jan 23, 2012 at 10:40:07AM +0100, Daniel Vetter wrote: On Mon, Jan 23, 2012 at 10:06:57AM +0100, Marek Szyprowski wrote: Hello, On Friday, January 20, 2012 5:29 PM Laurent Pinchart wrote: On Friday 20 January 2012 17:20:22 Tomasz Stanislawski wrote: IMO, One way to do this is adding field 'struct device *dev' to struct vb2_queue. This field should be filled by a driver prior to calling vb2_queue_init. I haven't looked into the details, but that sounds good to me. Do we have use cases where a queue is allocated before knowing which physical device it will be used for ? I don't think so. In case of S5P drivers, vb2_queue_init is called while opening /dev/videoX. BTW. This struct device may help vb2 to produce logs with more descriptive client annotation. What happens if such a device is NULL. It would happen for vmalloc allocator used by VIVI? Good question. Should dma-buf accept NULL devices ? Or should vivi pass its V4L2 device to vb2 ? I assume you suggested using struct video_device-dev entry in such case. It will not work. DMA-mapping API requires some parameters to be set for the client device, like for example dma mask. struct video_device contains only an artificial struct device entry, which has no relation to any physical device and cannot be used for calling DMA-mapping functions. Performing dma_map_* operations with such artificial struct device doesn't make any sense. It also slows down things significantly due to cache flushing (forced by dma-mapping) which should be avoided if the buffer is accessed only with CPU (like it is done by vb2-vmalloc style drivers). IMHO this case perfectly shows the design mistake that have been made. The current version simply tries to do too much. Nope, the current dma_buf does too little. Atm it's simple not useable for drivers that need cpu access, at least not if you're willing to resort to ugly an non-portable tricks like prime. Argh, there's a 'not' missing in the above sentence: CPU access is not possible, at elast not if you're *not* willing to resert to ugly ... We've discussed this quite a bit and decided that solving cpu access and coherency with n other devices involved is too much v1. It looks like we need to add that extension rather sooner than later. -Daneil -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv1 2/4] v4l:vb2: add support for shared buffer (dma_buf)
Hi Marek, On Monday 23 January 2012 10:06:57 Marek Szyprowski wrote: On Friday, January 20, 2012 5:29 PM Laurent Pinchart wrote: On Friday 20 January 2012 17:20:22 Tomasz Stanislawski wrote: IMO, One way to do this is adding field 'struct device *dev' to struct vb2_queue. This field should be filled by a driver prior to calling vb2_queue_init. I haven't looked into the details, but that sounds good to me. Do we have use cases where a queue is allocated before knowing which physical device it will be used for ? I don't think so. In case of S5P drivers, vb2_queue_init is called while opening /dev/videoX. BTW. This struct device may help vb2 to produce logs with more descriptive client annotation. What happens if such a device is NULL. It would happen for vmalloc allocator used by VIVI? Good question. Should dma-buf accept NULL devices ? Or should vivi pass its V4L2 device to vb2 ? I assume you suggested using struct video_device-dev entry in such case. It will not work. DMA-mapping API requires some parameters to be set for the client device, like for example dma mask. struct video_device contains only an artificial struct device entry, which has no relation to any physical device and cannot be used for calling DMA-mapping functions. Performing dma_map_* operations with such artificial struct device doesn't make any sense. It also slows down things significantly due to cache flushing (forced by dma-mapping) which should be avoided if the buffer is accessed only with CPU (like it is done by vb2-vmalloc style drivers). I agree that mapping the buffer to the physical device doesn't make any sense, as there's simple no physical device to map the buffer to. In that case we could simply skip the dma_map/dma_unmap calls. Note, however, that dma-buf v1 explicitly does not support CPU access by the importer. IMHO this case perfectly shows the design mistake that have been made. The current version simply tries to do too much. Each client of dma_buf should 'map' the provided sgtable/scatterlist on its own. Only the client device driver has all knowledge to make a proper 'mapping'. Real physical devices usually will use dma_map_sg() for such operation, while some virtual ones will only create a kernel mapping for the provided scatterlist (like vivi with vmalloc memory module). I tend to agree with that. Depending on the importer device, drivers could then map/unmap the buffer around each DMA access, or keep a mapping and sync the buffer. What about splitting the map_dma_buf operation into an operation that backs the buffer with pages and returns an sg_list, and an operation that performs DMA synchronization with the exporter ? unmap_dma_buf would similarly be split in two operations. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] convert drivers/media/* to use module_i2c_driver()
On Sat, 21 Jan 2012, Axel Lin wrote: This patch converts the drivers in drivers/media/* to use the module_i2_driver() macro which makes the code smaller and a bit simpler. Signed-off-by: Axel Lin axel@gmail.com Cc: Mauro Carvalho Chehab mche...@infradead.org Cc: Kyungmin Park kyungmin.p...@samsung.com Cc: Heungjun Kim riverful@samsung.com Cc: Jonathan Corbet cor...@lwn.net Cc: Tomasz Stanislawski t.stanisl...@samsung.com Cc: Hans Verkuil hans.verk...@cisco.com Cc: Joonyoung Shim jy0922.s...@samsung.com Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com Cc: Guennadi Liakhovetski g.liakhovet...@gmx.de Cc: Andrew Chew ac...@nvidia.com Cc: Paul Mundt let...@linux-sh.org Cc: Michael Grzeschik m.grzesc...@pengutronix.de Cc: Johannes Obermaier johannes.oberma...@gmail.com Cc: Sylwester Nawrocki s.nawro...@samsung.com Cc: Steven Toth st...@kernellabs.com --- drivers/media/video/ak881x.c | 13 +-- drivers/media/video/imx074.c | 13 +-- drivers/media/video/mt9m001.c | 13 +-- drivers/media/video/mt9m111.c | 13 +-- drivers/media/video/mt9t031.c | 13 +-- drivers/media/video/mt9t112.c | 16 +- drivers/media/video/mt9v022.c | 13 +-- drivers/media/video/ov2640.c | 16 +- drivers/media/video/ov5642.c | 13 +-- drivers/media/video/ov6650.c | 13 +-- drivers/media/video/ov772x.c | 17 +-- drivers/media/video/ov9640.c | 13 +-- drivers/media/video/ov9740.c | 13 +-- drivers/media/video/rj54n1cb0c.c | 13 +-- drivers/media/video/tw9910.c | 16 +- Acked-by: Guennadi Liakhovetski g.liakhovet...@gmx.de Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cron job: media_tree daily build: ERRORS
On Sunday 22 January 2012 19:53:04 Hans Verkuil wrote: This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. I've updated the daily build to the for_v3.4 branch and fixed media_build so that all targets pass again without errors. The 3.3-rc1 kernel is now also included in the build. Regards, Hans Results of the daily build of media_tree: date:Sun Jan 22 19:00:18 CET 2012 git hash:9e5e3097a3febbf317abc6d1b07bc6c33b20c279 gcc version: i686-linux-gcc (GCC) 4.6.2 host hardware:x86_64 host os: 3.1-2.slh.1-amd64 linux-git-arm-eabi-enoxys: WARNINGS linux-git-arm-eabi-omap: ERRORS linux-git-armv5-ixp: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: OK linux-git-x86_64: WARNINGS linux-2.6.31.12-i686: WARNINGS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-3.0-i686: WARNINGS linux-3.1-i686: WARNINGS linux-3.2.1-i686: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS linux-3.0-x86_64: WARNINGS linux-3.1-x86_64: WARNINGS linux-3.2.1-x86_64: WARNINGS apps: WARNINGS spec-git: WARNINGS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv1 2/4] v4l:vb2: add support for shared buffer (dma_buf)
On Mon, Jan 23, 2012 at 10:48, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Hi Marek, On Monday 23 January 2012 10:06:57 Marek Szyprowski wrote: On Friday, January 20, 2012 5:29 PM Laurent Pinchart wrote: On Friday 20 January 2012 17:20:22 Tomasz Stanislawski wrote: IMO, One way to do this is adding field 'struct device *dev' to struct vb2_queue. This field should be filled by a driver prior to calling vb2_queue_init. I haven't looked into the details, but that sounds good to me. Do we have use cases where a queue is allocated before knowing which physical device it will be used for ? I don't think so. In case of S5P drivers, vb2_queue_init is called while opening /dev/videoX. BTW. This struct device may help vb2 to produce logs with more descriptive client annotation. What happens if such a device is NULL. It would happen for vmalloc allocator used by VIVI? Good question. Should dma-buf accept NULL devices ? Or should vivi pass its V4L2 device to vb2 ? I assume you suggested using struct video_device-dev entry in such case. It will not work. DMA-mapping API requires some parameters to be set for the client device, like for example dma mask. struct video_device contains only an artificial struct device entry, which has no relation to any physical device and cannot be used for calling DMA-mapping functions. Performing dma_map_* operations with such artificial struct device doesn't make any sense. It also slows down things significantly due to cache flushing (forced by dma-mapping) which should be avoided if the buffer is accessed only with CPU (like it is done by vb2-vmalloc style drivers). I agree that mapping the buffer to the physical device doesn't make any sense, as there's simple no physical device to map the buffer to. In that case we could simply skip the dma_map/dma_unmap calls. See my other mail, dma_buf v1 does not support cpu access. So if you don't have a device around, you can't use it in it's current form. Note, however, that dma-buf v1 explicitly does not support CPU access by the importer. IMHO this case perfectly shows the design mistake that have been made. The current version simply tries to do too much. Each client of dma_buf should 'map' the provided sgtable/scatterlist on its own. Only the client device driver has all knowledge to make a proper 'mapping'. Real physical devices usually will use dma_map_sg() for such operation, while some virtual ones will only create a kernel mapping for the provided scatterlist (like vivi with vmalloc memory module). I tend to agree with that. Depending on the importer device, drivers could then map/unmap the buffer around each DMA access, or keep a mapping and sync the buffer. Again we've discussed adding a syncing op to the interface that would allow keeping around mappings. The thing is that this also requires an unmap callback or something similar, so that the exporter can inform the importer that the memory just moved around. And the exporter _needs_ to be able to do that, hence also the language in the doc that importers need to braked all uses with a map/unmap and can't sit forever on a dma_buf mapping. What about splitting the map_dma_buf operation into an operation that backs the buffer with pages and returns an sg_list, and an operation that performs DMA synchronization with the exporter ? unmap_dma_buf would similarly be split in two operations. Again for v1 that doesn't make sense because you can't do cpu access anyway and you should not hang onto mappings forever. Furthermore we have cases where an unmapped sg_list for cpu access simple makes no sense. Yours, Daniel [Aside: You can do a dirty trick like prime that grabs the underlying page of an already mapped sg list. Obviously highly non-portable.] -- Daniel Vetter daniel.vet...@ffwll.ch - +41 (0) 79 364 57 48 - http://blog.ffwll.ch -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv1 2/4] v4l:vb2: add support for shared buffer (dma_buf)
Hi Daniel, On Monday 23 January 2012 11:35:01 Daniel Vetter wrote: On Mon, Jan 23, 2012 at 10:48, Laurent Pinchart wrote: On Monday 23 January 2012 10:06:57 Marek Szyprowski wrote: On Friday, January 20, 2012 5:29 PM Laurent Pinchart wrote: On Friday 20 January 2012 17:20:22 Tomasz Stanislawski wrote: IMO, One way to do this is adding field 'struct device *dev' to struct vb2_queue. This field should be filled by a driver prior to calling vb2_queue_init. I haven't looked into the details, but that sounds good to me. Do we have use cases where a queue is allocated before knowing which physical device it will be used for ? I don't think so. In case of S5P drivers, vb2_queue_init is called while opening /dev/videoX. BTW. This struct device may help vb2 to produce logs with more descriptive client annotation. What happens if such a device is NULL. It would happen for vmalloc allocator used by VIVI? Good question. Should dma-buf accept NULL devices ? Or should vivi pass its V4L2 device to vb2 ? I assume you suggested using struct video_device-dev entry in such case. It will not work. DMA-mapping API requires some parameters to be set for the client device, like for example dma mask. struct video_device contains only an artificial struct device entry, which has no relation to any physical device and cannot be used for calling DMA-mapping functions. Performing dma_map_* operations with such artificial struct device doesn't make any sense. It also slows down things significantly due to cache flushing (forced by dma-mapping) which should be avoided if the buffer is accessed only with CPU (like it is done by vb2-vmalloc style drivers). I agree that mapping the buffer to the physical device doesn't make any sense, as there's simple no physical device to map the buffer to. In that case we could simply skip the dma_map/dma_unmap calls. See my other mail, dma_buf v1 does not support cpu access. v1 is in the kernel now, let's start discussing v2 ;-) So if you don't have a device around, you can't use it in it's current form. Note, however, that dma-buf v1 explicitly does not support CPU access by the importer. IMHO this case perfectly shows the design mistake that have been made. The current version simply tries to do too much. Each client of dma_buf should 'map' the provided sgtable/scatterlist on its own. Only the client device driver has all knowledge to make a proper 'mapping'. Real physical devices usually will use dma_map_sg() for such operation, while some virtual ones will only create a kernel mapping for the provided scatterlist (like vivi with vmalloc memory module). I tend to agree with that. Depending on the importer device, drivers could then map/unmap the buffer around each DMA access, or keep a mapping and sync the buffer. Again we've discussed adding a syncing op to the interface that would allow keeping around mappings. The thing is that this also requires an unmap callback or something similar, so that the exporter can inform the importer that the memory just moved around. And the exporter _needs_ to be able to do that, hence also the language in the doc that importers need to braked all uses with a map/unmap and can't sit forever on a dma_buf mapping. Not all exporters need to be able to move buffers around. If I'm not mistaken, only DRM exporters need such a feature (which obviously makes it an important feature). Does the exporter need to be able to do so at any time ? Buffers can't obviously be moved around when they're used by an activa DMA, so I expect the exporter to be able to wait. How long can it wait ? I'm not sure I would like a callback approach. If we add a sync operation, the exporter could signal to the importer that it must unmap the buffer by returning an appropriate value from the sync operation. Would that be usable for DRM ? Another option would be to keep the mapping around, and check in the importer if the buffer has moved. If so, the importer would tear the mapping down and create a new one. This is a bit hackish though, as we would tear a mapping down for a buffer that doesn't exist anymore. Nothing should be accessing the mapping at that time, but it could be a security risk if we consider rogue hardware (that's pretty far-fetched though, as rogue hardware can probably already kill the system easily in many cases). What about splitting the map_dma_buf operation into an operation that backs the buffer with pages and returns an sg_list, and an operation that performs DMA synchronization with the exporter ? unmap_dma_buf would similarly be split in two operations. Again for v1 that doesn't make sense because you can't do cpu access anyway and you should not hang onto mappings forever. For performance reasons I'd like to hang onto the mapping as long as possible. Creating
Re: [v3.3-rc1] media:dvb-t regression bisected
Em 22-01-2012 13:29, Jörg Otte escreveu:
with v3.3-rc1 I can not watch dvb-t. I get the following
errors from the media player (Kaffeine,vlc):
kaffeine(1801): DvbDevice::frontendEvent: tuning failed
vlc: [0xa278d78] main stream error: cannot pre fill buffer
I have a CinergyT2 usb-stick.
I was able to bisect the problem to:
commit 7830bbaff9f5f9cefcdc9acfb1783b230cc69fac
Author: Mauro Carvalho Chehab mche...@redhat.com
Date: Mon Dec 26 15:41:01 2011 -0300
[media] cinergyT2-fe: convert set_fontend to use DVBv5 parameters
Could you please try this patch?
[PATCH] cinergyT2-fe: Fix bandwdith settings
Changeset 7830bbaff9f mangled the bandwidth field for CinergyT2.
Properly fill it.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
diff --git a/drivers/media/dvb/dvb-usb/cinergyT2-fe.c
b/drivers/media/dvb/dvb-usb/cinergyT2-fe.c
index 8a57ed8..1efc028 100644
--- a/drivers/media/dvb/dvb-usb/cinergyT2-fe.c
+++ b/drivers/media/dvb/dvb-usb/cinergyT2-fe.c
@@ -276,14 +276,15 @@ static int cinergyt2_fe_set_frontend(struct dvb_frontend
*fe)
param.flags = 0;
switch (fep-bandwidth_hz) {
+ default:
case 800:
- param.bandwidth = 0;
+ param.bandwidth = 8;
break;
case 700:
- param.bandwidth = 1;
+ param.bandwidth = 7;
break;
case 600:
- param.bandwidth = 2;
+ param.bandwidth = 6;
break;
}
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] convert drivers/media/* to use module_i2c_driver()
Em 21-01-2012 08:10, Axel Lin escreveu: This patch converts the drivers in drivers/media/* to use the module_i2_driver() macro which makes the code smaller and a bit simpler. Signed-off-by: Axel Lin axel@gmail.com Cc: Mauro Carvalho Chehab mche...@infradead.org Acked-by: Mauro Carvalho Chehab mche...@redhat.com Cc: Kyungmin Park kyungmin.p...@samsung.com Cc: Heungjun Kim riverful@samsung.com Cc: Jonathan Corbet cor...@lwn.net Cc: Tomasz Stanislawski t.stanisl...@samsung.com Cc: Hans Verkuil hans.verk...@cisco.com Cc: Joonyoung Shim jy0922.s...@samsung.com Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com Cc: Guennadi Liakhovetski g.liakhovet...@gmx.de Cc: Andrew Chew ac...@nvidia.com Cc: Paul Mundt let...@linux-sh.org Cc: Michael Grzeschik m.grzesc...@pengutronix.de Cc: Johannes Obermaier johannes.oberma...@gmail.com Cc: Sylwester Nawrocki s.nawro...@samsung.com Cc: Steven Toth st...@kernellabs.com --- drivers/media/dvb/frontends/au8522_decoder.c | 13 +-- drivers/media/radio/radio-tea5764.c | 19 + drivers/media/radio/saa7706h.c| 13 +-- drivers/media/radio/si470x/radio-si470x-i2c.c | 28 + drivers/media/radio/si4713-i2c.c | 15 + drivers/media/radio/tef6862.c | 14 +--- drivers/media/video/adp1653.c | 19 + drivers/media/video/adv7170.c | 13 +-- drivers/media/video/adv7175.c | 13 +-- drivers/media/video/adv7180.c | 14 +--- drivers/media/video/adv7343.c | 13 +-- drivers/media/video/ak881x.c | 13 +-- drivers/media/video/as3645a.c | 19 + drivers/media/video/bt819.c | 13 +-- drivers/media/video/bt856.c | 13 +-- drivers/media/video/bt866.c | 13 +-- drivers/media/video/cs5345.c | 13 +-- drivers/media/video/cs53l32a.c| 13 +-- drivers/media/video/cx25840/cx25840-core.c| 13 +-- drivers/media/video/imx074.c | 13 +-- drivers/media/video/indycam.c | 13 +-- drivers/media/video/ir-kbd-i2c.c | 17 ++ drivers/media/video/ks0127.c | 13 +-- drivers/media/video/m52790.c | 13 +-- drivers/media/video/m5mols/m5mols_core.c | 13 +-- drivers/media/video/msp3400-driver.c | 13 +-- drivers/media/video/mt9m001.c | 13 +-- drivers/media/video/mt9m111.c | 13 +-- drivers/media/video/mt9p031.c | 13 +-- drivers/media/video/mt9t001.c | 13 +-- drivers/media/video/mt9t031.c | 13 +-- drivers/media/video/mt9t112.c | 16 +- drivers/media/video/mt9v011.c | 13 +-- drivers/media/video/mt9v022.c | 13 +-- drivers/media/video/mt9v032.c | 13 +-- drivers/media/video/noon010pc30.c | 13 +-- drivers/media/video/ov2640.c | 16 +- drivers/media/video/ov5642.c | 13 +-- drivers/media/video/ov6650.c | 13 +-- drivers/media/video/ov7670.c | 13 +-- drivers/media/video/ov772x.c | 17 +-- drivers/media/video/ov9640.c | 13 +-- drivers/media/video/ov9740.c | 13 +-- drivers/media/video/rj54n1cb0c.c | 13 +-- drivers/media/video/s5k6aa.c | 13 +-- drivers/media/video/s5p-tv/hdmiphy_drv.c | 12 +- drivers/media/video/saa6588.c | 13 +-- drivers/media/video/saa7110.c | 13 +-- drivers/media/video/saa7115.c | 13 +-- drivers/media/video/saa7127.c | 13 +-- drivers/media/video/saa7134/saa6752hs.c | 13 +-- drivers/media/video/saa717x.c | 13 +-- drivers/media/video/saa7185.c | 13 +-- drivers/media/video/saa7191.c | 13 +-- drivers/media/video/sr030pc30.c | 13 +-- drivers/media/video/tda7432.c | 13 +-- drivers/media/video/tda9840.c | 13 +-- drivers/media/video/tea6415c.c| 13 +-- drivers/media/video/tea6420.c | 13 +-- drivers/media/video/ths7303.c
[PATCH 00/10] Integration of videobuf2 with dmabuf
Hello everyone, This patchset is an incremental patch to patchset created by Sumit Semwal [1]. The patches are dedicated to help find a better solution for support of buffer sharing by V4L2 API. It is expected to start discussion on final installment for dma-buf in vb2-dma-contig allocator. Current version of the patches contain little documentation. It is going to be fixed after achieving consensus about design for buffer exporting. Moreover the API between vb2-core and the allocator should be revised. The amount of changes to vb2-dma-contig.c was significant making the difference patch very difficult to read. Therefore the patch was split into two parts. One removes old file, the next patch creates the version of the file. The patchset contains extension for DMA API and its implementation for ARM architecture. Therefore the patchset should be applied on the top of: http://git.infradead.org/users/kmpark/linux-2.6-samsung/shortlog/refs/heads/3.2-dma-v5 After applying patches from [2] and [1]. 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/42966/focus=42968 [2] https://lkml.org/lkml/2011/12/26/29 [3] http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/36354/focus=36355 Marek Szyprowski (2): [media] media: vb2: remove plane argument from call_memop and cleanup mempriv usage media: vb2: add prepare/finish callbacks to allocators Tomasz Stanislawski (8): arm: dma: support for dma_get_pages v4l: vb2: fixes for DMABUF support v4l: add buffer exporting via dmabuf v4l: vb2: add buffer exporting via dmabuf v4l: vb2: remove dma-contig allocator v4l: vb2-dma-contig: code refactoring, support for DMABUF exporting v4l: fimc: integrate capture i-face with dmabuf v4l: s5p-tv: mixer: integrate with dmabuf arch/arm/include/asm/dma-mapping.h |8 + arch/arm/mm/dma-mapping.c | 44 ++ drivers/media/video/s5p-fimc/fimc-capture.c | 11 +- drivers/media/video/s5p-tv/mixer_video.c| 11 +- drivers/media/video/v4l2-compat-ioctl32.c |1 + drivers/media/video/v4l2-ioctl.c| 11 + drivers/media/video/videobuf2-core.c| 114 - drivers/media/video/videobuf2-dma-contig.c | 754 +-- include/linux/dma-mapping.h |2 + include/linux/videodev2.h |1 + include/media/v4l2-ioctl.h |1 + include/media/videobuf2-core.h | 10 +- 12 files changed, 789 insertions(+), 179 deletions(-) -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 06/10] v4l: vb2: add buffer exporting via dmabuf
This patch adds extension to videobuf2-core. It allow to export a mmap buffer
as a file descriptor.
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/videobuf2-core.c | 60 ++
include/media/videobuf2-core.h |2 +
2 files changed, 62 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/videobuf2-core.c
b/drivers/media/video/videobuf2-core.c
index 59bb1bc..29cf6ed 100644
--- a/drivers/media/video/videobuf2-core.c
+++ b/drivers/media/video/videobuf2-core.c
@@ -1522,6 +1522,66 @@ int vb2_dqbuf(struct vb2_queue *q, struct v4l2_buffer
*b, bool nonblocking)
}
EXPORT_SYMBOL_GPL(vb2_dqbuf);
+static int __find_plane_by_offset(struct vb2_queue *q, unsigned long off,
+ unsigned int *_buffer, unsigned int *_plane);
+
+/**
+ * vb2_expbuf() - Export a buffer as a file descriptor
+ * @q: videobuf2 queue
+ * @b: buffer structure passed from userspace to vidioc_expbuf handler
+ * in driver
+ *
+ * The return values from this function are intended to be directly returned
+ * from vidioc_expbuf handler in driver.
+ */
+int vb2_expbuf(struct vb2_queue *q, unsigned int offset)
+{
+ struct vb2_buffer *vb = NULL;
+ struct vb2_plane *vb_plane;
+ unsigned int buffer, plane;
+ int ret;
+ struct dma_buf *dbuf;
+
+ if (q-memory != V4L2_MEMORY_MMAP) {
+ dprintk(1, Queue is not currently set up for mmap\n);
+ return -EINVAL;
+ }
+
+ if (!q-mem_ops-get_dmabuf) {
+ dprintk(1, Queue does not support DMA buffer exporting\n);
+ return -EINVAL;
+ }
+
+ /*
+* Find the plane corresponding to the offset passed by userspace.
+*/
+ ret = __find_plane_by_offset(q, offset, buffer, plane);
+ if (ret) {
+ dprintk(1, invalid offset %d\n, offset);
+ return ret;
+ }
+
+ vb = q-bufs[buffer];
+ vb_plane = vb-planes[plane];
+
+ dbuf = call_memop(q, get_dmabuf, vb_plane-mem_priv);
+ if (IS_ERR_OR_NULL(dbuf)) {
+ dprintk(1, Failed to export buffer %d, plane %d\n,
+ buffer, plane);
+ return -EINVAL;
+ }
+
+ ret = dma_buf_fd(dbuf);
+ if (ret 0)
+ dprintk(3, buffer %d, plane %d failed to export (%d)\n,
+ buffer, plane, ret);
+ else
+ dprintk(3, buffer %d, plane %d exported as %d descriptor\n,
+ buffer, plane, ret);
+ return ret;
+}
+EXPORT_SYMBOL_GPL(vb2_expbuf);
+
/**
* __vb2_queue_cancel() - cancel and stop (pause) streaming
*
diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
index 412c6a4..3d43954 100644
--- a/include/media/videobuf2-core.h
+++ b/include/media/videobuf2-core.h
@@ -79,6 +79,7 @@ struct vb2_mem_ops {
void(*prepare)(void *buf_priv);
void(*finish)(void *buf_priv);
void(*put)(void *buf_priv);
+ struct dma_buf *(*get_dmabuf)(void *buf_priv);
void*(*get_userptr)(void *alloc_ctx, unsigned long vaddr,
unsigned long size, int write);
@@ -348,6 +349,7 @@ int vb2_queue_init(struct vb2_queue *q);
void vb2_queue_release(struct vb2_queue *q);
int vb2_qbuf(struct vb2_queue *q, struct v4l2_buffer *b);
+int vb2_expbuf(struct vb2_queue *q, unsigned int offset);
int vb2_dqbuf(struct vb2_queue *q, struct v4l2_buffer *b, bool nonblocking);
int vb2_streamon(struct vb2_queue *q, enum v4l2_buf_type type);
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 03/10] media: vb2: add prepare/finish callbacks to allocators
From: Marek Szyprowski m.szyprow...@samsung.com
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
---
drivers/media/video/videobuf2-core.c | 11 +++
include/media/videobuf2-core.h |2 ++
2 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/videobuf2-core.c
b/drivers/media/video/videobuf2-core.c
index 4c3a82e..cb85874 100644
--- a/drivers/media/video/videobuf2-core.c
+++ b/drivers/media/video/videobuf2-core.c
@@ -836,6 +836,7 @@ void vb2_buffer_done(struct vb2_buffer *vb, enum
vb2_buffer_state state)
{
struct vb2_queue *q = vb-vb2_queue;
unsigned long flags;
+ int plane;
if (vb-state != VB2_BUF_STATE_ACTIVE)
return;
@@ -846,6 +847,10 @@ void vb2_buffer_done(struct vb2_buffer *vb, enum
vb2_buffer_state state)
dprintk(4, Done processing on buffer %d, state: %d\n,
vb-v4l2_buf.index, vb-state);
+ /* sync buffers */
+ for (plane = 0; plane vb-num_planes; ++plane)
+ call_memop(q, finish, vb-planes[plane].mem_priv);
+
/* Add the buffer to the done buffers list */
spin_lock_irqsave(q-done_lock, flags);
vb-state = state;
@@ -1136,9 +1141,15 @@ err:
static void __enqueue_in_driver(struct vb2_buffer *vb)
{
struct vb2_queue *q = vb-vb2_queue;
+ int plane;
vb-state = VB2_BUF_STATE_ACTIVE;
atomic_inc(q-queued_count);
+
+ /* sync buffers */
+ for (plane = 0; plane vb-num_planes; ++plane)
+ call_memop(q, prepare, vb-planes[plane].mem_priv);
+
q-ops-buf_queue(vb);
}
diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
index 35607f7..d8b8171 100644
--- a/include/media/videobuf2-core.h
+++ b/include/media/videobuf2-core.h
@@ -76,6 +76,8 @@ struct vb2_fileio_data;
*/
struct vb2_mem_ops {
void*(*alloc)(void *alloc_ctx, unsigned long size);
+ void(*prepare)(void *buf_priv);
+ void(*finish)(void *buf_priv);
void(*put)(void *buf_priv);
void*(*get_userptr)(void *alloc_ctx, unsigned long vaddr,
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 07/10] v4l: vb2: remove dma-contig allocator
This is temporary patch. The dma-contig changes were significant
and the difference patch would be very difficult to read.
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/videobuf2-dma-contig.c | 308
1 files changed, 0 insertions(+), 308 deletions(-)
delete mode 100644 drivers/media/video/videobuf2-dma-contig.c
diff --git a/drivers/media/video/videobuf2-dma-contig.c
b/drivers/media/video/videobuf2-dma-contig.c
deleted file mode 100644
index ea2699f..000
--- a/drivers/media/video/videobuf2-dma-contig.c
+++ /dev/null
@@ -1,308 +0,0 @@
-/*
- * videobuf2-dma-contig.c - DMA contig memory allocator for videobuf2
- *
- * Copyright (C) 2010 Samsung Electronics
- *
- * Author: Pawel Osciak pa...@osciak.com
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation.
- */
-
-#include linux/module.h
-#include linux/slab.h
-#include linux/dma-mapping.h
-#include linux/scatterlist.h
-#include linux/dma-buf.h
-
-#include media/videobuf2-core.h
-#include media/videobuf2-memops.h
-
-struct vb2_dc_conf {
- struct device *dev;
-};
-
-struct vb2_dc_buf {
- struct vb2_dc_conf *conf;
- void*vaddr;
- dma_addr_t dma_addr;
- unsigned long size;
- struct vm_area_struct *vma;
- struct dma_buf_attachment *db_attach;
- atomic_trefcount;
- struct vb2_vmarea_handler handler;
-};
-
-static void vb2_dma_contig_put(void *buf_priv);
-
-static void *vb2_dma_contig_alloc(void *alloc_ctx, unsigned long size)
-{
- struct vb2_dc_conf *conf = alloc_ctx;
- struct vb2_dc_buf *buf;
- /* TODO: add db_attach processing while adding DMABUF as exporter */
-
- buf = kzalloc(sizeof *buf, GFP_KERNEL);
- if (!buf)
- return ERR_PTR(-ENOMEM);
-
- buf-vaddr = dma_alloc_coherent(conf-dev, size, buf-dma_addr,
- GFP_KERNEL);
- if (!buf-vaddr) {
- dev_err(conf-dev, dma_alloc_coherent of size %ld failed\n,
- size);
- kfree(buf);
- return ERR_PTR(-ENOMEM);
- }
-
- buf-conf = conf;
- buf-size = size;
-
- buf-handler.refcount = buf-refcount;
- buf-handler.put = vb2_dma_contig_put;
- buf-handler.arg = buf;
-
- atomic_inc(buf-refcount);
-
- return buf;
-}
-
-static void vb2_dma_contig_put(void *buf_priv)
-{
- struct vb2_dc_buf *buf = buf_priv;
-
- if (atomic_dec_and_test(buf-refcount)) {
- dma_free_coherent(buf-conf-dev, buf-size, buf-vaddr,
- buf-dma_addr);
- kfree(buf);
- }
-}
-
-static void *vb2_dma_contig_cookie(void *buf_priv)
-{
- struct vb2_dc_buf *buf = buf_priv;
-
- return buf-dma_addr;
-}
-
-static void *vb2_dma_contig_vaddr(void *buf_priv)
-{
- struct vb2_dc_buf *buf = buf_priv;
- if (!buf)
- return 0;
-
- return buf-vaddr;
-}
-
-static unsigned int vb2_dma_contig_num_users(void *buf_priv)
-{
- struct vb2_dc_buf *buf = buf_priv;
-
- return atomic_read(buf-refcount);
-}
-
-static int vb2_dma_contig_mmap(void *buf_priv, struct vm_area_struct *vma)
-{
- struct vb2_dc_buf *buf = buf_priv;
-
- if (!buf) {
- printk(KERN_ERR No buffer to map\n);
- return -EINVAL;
- }
-
- return vb2_mmap_pfn_range(vma, buf-dma_addr, buf-size,
- vb2_common_vm_ops, buf-handler);
-}
-
-static void *vb2_dma_contig_get_userptr(void *alloc_ctx, unsigned long vaddr,
- unsigned long size, int write)
-{
- struct vb2_dc_buf *buf;
- struct vm_area_struct *vma;
- dma_addr_t dma_addr = 0;
- int ret;
-
- buf = kzalloc(sizeof *buf, GFP_KERNEL);
- if (!buf)
- return ERR_PTR(-ENOMEM);
-
- ret = vb2_get_contig_userptr(vaddr, size, vma, dma_addr);
- if (ret) {
- printk(KERN_ERR Failed acquiring VMA for vaddr 0x%08lx\n,
- vaddr);
- kfree(buf);
- return ERR_PTR(ret);
- }
-
- buf-size = size;
- buf-dma_addr = dma_addr;
- buf-vma = vma;
-
- return buf;
-}
-
-static void vb2_dma_contig_put_userptr(void *mem_priv)
-{
- struct vb2_dc_buf *buf = mem_priv;
-
- if (!buf)
- return;
-
- vb2_put_vma(buf-vma);
- kfree(buf);
-}
-
-static int vb2_dma_contig_map_dmabuf(void *mem_priv,
- enum dma_data_direction direction)
-{
- struct vb2_dc_buf *buf = mem_priv;
- struct dma_buf
[PATCH 09/10] v4l: fimc: integrate capture i-face with dmabuf
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/s5p-fimc/fimc-capture.c | 11 ++-
1 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/s5p-fimc/fimc-capture.c
b/drivers/media/video/s5p-fimc/fimc-capture.c
index 2cc3b91..ba11c4a 100644
--- a/drivers/media/video/s5p-fimc/fimc-capture.c
+++ b/drivers/media/video/s5p-fimc/fimc-capture.c
@@ -1002,6 +1002,14 @@ static int fimc_cap_qbuf(struct file *file, void *priv,
return vb2_qbuf(fimc-vid_cap.vbq, buf);
}
+static int fimc_cap_expbuf(struct file *file, void *priv,
+ unsigned int offset)
+{
+ struct fimc_dev *fimc = video_drvdata(file);
+
+ return vb2_expbuf(fimc-vid_cap.vbq, offset);
+}
+
static int fimc_cap_dqbuf(struct file *file, void *priv,
struct v4l2_buffer *buf)
{
@@ -1072,6 +1080,7 @@ static const struct v4l2_ioctl_ops fimc_capture_ioctl_ops
= {
.vidioc_qbuf= fimc_cap_qbuf,
.vidioc_dqbuf = fimc_cap_dqbuf,
+ .vidioc_expbuf = fimc_cap_expbuf,
.vidioc_streamon= fimc_cap_streamon,
.vidioc_streamoff = fimc_cap_streamoff,
@@ -1451,7 +1460,7 @@ int fimc_register_capture_device(struct fimc_dev *fimc,
q = fimc-vid_cap.vbq;
memset(q, 0, sizeof(*q));
q-type = V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE;
- q-io_modes = VB2_MMAP | VB2_USERPTR;
+ q-io_modes = VB2_MMAP | VB2_USERPTR | VB2_DMABUF;
q-drv_priv = fimc-vid_cap.ctx;
q-ops = fimc_capture_qops;
q-mem_ops = vb2_dma_contig_memops;
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 08/10] v4l: vb2-dma-contig: code refactoring, support for DMABUF exporting
Signed-off-by: Pawel Osciak pa...@osciak.com
[author of the original file]
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
[implemetation of mmap, finish/prepare]
Signed-off-by: Andrzej Pietrasiewicz andrze...@samsung.com
[implementation of userprt handling]
Signed-off-by: Sumit Semwal sumit.sem...@ti.com
Signed-off-by: Sumit Semwal sumit.sem...@linaro.org
[PoC for importing dmabuf buffer]
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
[buffer exporting using dmabuf, code refactoring]
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/videobuf2-dma-contig.c | 762
1 files changed, 762 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/videobuf2-dma-contig.c
diff --git a/drivers/media/video/videobuf2-dma-contig.c
b/drivers/media/video/videobuf2-dma-contig.c
new file mode 100644
index 000..d95b23a
--- /dev/null
+++ b/drivers/media/video/videobuf2-dma-contig.c
@@ -0,0 +1,762 @@
+/*
+ * videobuf2-dma-contig.c - DMA contig memory allocator for videobuf2
+ *
+ * Copyright (C) 2010 Samsung Electronics
+ *
+ * Author: Pawel Osciak pa...@osciak.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation.
+ */
+
+#include linux/dma-buf.h
+#include linux/dma-mapping.h
+#include linux/module.h
+#include linux/scatterlist.h
+#include linux/sched.h
+#include linux/slab.h
+
+#include media/videobuf2-core.h
+#include media/videobuf2-memops.h
+
+struct vb2_dc_buf {
+ struct device *dev;
+ void*vaddr;
+ unsigned long size;
+ dma_addr_t dma_addr;
+ struct sg_table *dma_sgt;
+ enum dma_data_direction dma_dir;
+
+ /* MMAP related */
+ struct vb2_vmarea_handler handler;
+ atomic_trefcount;
+ struct dma_buf *dma_buf;
+ struct sg_table *sgt_base;
+
+ /* USERPTR related */
+ struct vm_area_struct *vma;
+
+ /* DMABUF related */
+ struct dma_buf_attachment *db_attach;
+};
+
+/*/
+/*scatterlist table functions*/
+/*/
+
+static struct sg_table *vb2_dc_pages_to_sgt(struct page **pages,
+ unsigned long n_pages, size_t offset, size_t offset2)
+{
+ struct sg_table *sgt;
+ int i, j; /* loop counters */
+ int cur_page, chunks;
+ int ret;
+ struct scatterlist *s;
+
+ sgt = kzalloc(sizeof *sgt, GFP_KERNEL);
+ if (!sgt)
+ return ERR_PTR(-ENOMEM);
+
+ /* compute number of chunks */
+ chunks = 1;
+ for (i = 1; i n_pages; ++i)
+ if (pages[i] != pages[i - 1] + 1)
+ ++chunks;
+
+ ret = sg_alloc_table(sgt, chunks, GFP_KERNEL);
+ if (ret) {
+ kfree(sgt);
+ return ERR_PTR(-ENOMEM);
+ }
+
+ /* merging chunks and putting them into the scatterlist */
+ cur_page = 0;
+ for_each_sg(sgt-sgl, s, sgt-orig_nents, i) {
+ size_t size = PAGE_SIZE;
+
+ for (j = cur_page + 1; j n_pages; ++j) {
+ if (pages[j] != pages[j - 1] + 1)
+ break;
+ size += PAGE_SIZE;
+ }
+
+ /* cut offset if chunk starts at the first page */
+ if (cur_page == 0)
+ size -= offset;
+ /* cut offset2 if chunk ends at the last page */
+ if (j == n_pages)
+ size -= offset2;
+
+ sg_set_page(s, pages[cur_page], size, offset);
+ offset = 0;
+ cur_page = j;
+ }
+
+ return sgt;
+}
+
+static void vb2_dc_release_sgtable(struct sg_table *sgt)
+{
+ sg_free_table(sgt);
+ kfree(sgt);
+}
+
+static void vb2_dc_put_sgtable(struct sg_table *sgt, int dirty)
+{
+ struct scatterlist *s;
+ int i, j;
+
+ for_each_sg(sgt-sgl, s, sgt-nents, i) {
+ struct page *page = sg_page(s);
+ int n_pages = PAGE_ALIGN(s-offset + s-length) PAGE_SHIFT;
+
+ for (j = 0; j n_pages; ++j, ++page) {
+ if (dirty)
+ set_page_dirty_lock(page);
+ put_page(page);
+ }
+ }
+
+ vb2_dc_release_sgtable(sgt);
+}
+
+static unsigned long vb2_dc_get_contiguous_size(struct sg_table *sgt)
+{
+ struct scatterlist *s;
+ dma_addr_t expected = sg_dma_address(sgt-sgl);
+ int i;
+ unsigned long size = 0;
+
+ for_each_sg(sgt-sgl, s, sgt-nents, i) {
+ if
[PATCH 10/10] v4l: s5p-tv: mixer: integrate with dmabuf
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/s5p-tv/mixer_video.c | 11 ++-
1 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/s5p-tv/mixer_video.c
b/drivers/media/video/s5p-tv/mixer_video.c
index b47d0c0..65e0722 100644
--- a/drivers/media/video/s5p-tv/mixer_video.c
+++ b/drivers/media/video/s5p-tv/mixer_video.c
@@ -592,6 +592,14 @@ static int mxr_dqbuf(struct file *file, void *priv, struct
v4l2_buffer *p)
return vb2_dqbuf(layer-vb_queue, p, file-f_flags O_NONBLOCK);
}
+static int mxr_expbuf(struct file *file, void *priv, unsigned int offset)
+{
+ struct mxr_layer *layer = video_drvdata(file);
+
+ mxr_dbg(layer-mdev, %s:%d\n, __func__, __LINE__);
+ return vb2_expbuf(layer-vb_queue, offset);
+}
+
static int mxr_streamon(struct file *file, void *priv, enum v4l2_buf_type i)
{
struct mxr_layer *layer = video_drvdata(file);
@@ -619,6 +627,7 @@ static const struct v4l2_ioctl_ops mxr_ioctl_ops = {
.vidioc_querybuf = mxr_querybuf,
.vidioc_qbuf = mxr_qbuf,
.vidioc_dqbuf = mxr_dqbuf,
+ .vidioc_expbuf = mxr_expbuf,
/* Streaming control */
.vidioc_streamon = mxr_streamon,
.vidioc_streamoff = mxr_streamoff,
@@ -973,7 +982,7 @@ struct mxr_layer *mxr_base_layer_create(struct mxr_device
*mdev,
layer-vb_queue = (struct vb2_queue) {
.type = V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE,
- .io_modes = VB2_MMAP | VB2_USERPTR,
+ .io_modes = VB2_MMAP | VB2_USERPTR | VB2_DMABUF,
.drv_priv = layer,
.buf_struct_size = sizeof(struct mxr_buffer),
.ops = mxr_video_qops,
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 02/10] [media] media: vb2: remove plane argument from call_memop and cleanup mempriv usage
From: Marek Szyprowski m.szyprow...@samsung.com
This patch removes unused 'plane' argument from call_memop macro.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
CC: Pawel Osciak pa...@osciak.com
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/video/videobuf2-core.c | 22 ++
1 files changed, 10 insertions(+), 12 deletions(-)
diff --git a/drivers/media/video/videobuf2-core.c
b/drivers/media/video/videobuf2-core.c
index 6cd2f97..4c3a82e 100644
--- a/drivers/media/video/videobuf2-core.c
+++ b/drivers/media/video/videobuf2-core.c
@@ -30,7 +30,7 @@ module_param(debug, int, 0644);
printk(KERN_DEBUG vb2: fmt, ## arg); \
} while (0)
-#define call_memop(q, plane, op, args...) \
+#define call_memop(q, op, args...) \
(((q)-mem_ops-op) ? \
((q)-mem_ops-op(args)) : 0)
@@ -52,7 +52,7 @@ static int __vb2_buf_mem_alloc(struct vb2_buffer *vb)
/* Allocate memory for all planes in this buffer */
for (plane = 0; plane vb-num_planes; ++plane) {
- mem_priv = call_memop(q, plane, alloc, q-alloc_ctx[plane],
+ mem_priv = call_memop(q, alloc, q-alloc_ctx[plane],
q-plane_sizes[plane]);
if (IS_ERR_OR_NULL(mem_priv))
goto free;
@@ -66,7 +66,7 @@ static int __vb2_buf_mem_alloc(struct vb2_buffer *vb)
free:
/* Free already allocated memory if one of the allocations failed */
for (; plane 0; --plane)
- call_memop(q, plane, put, vb-planes[plane - 1].mem_priv);
+ call_memop(q, put, vb-planes[plane - 1].mem_priv);
return -ENOMEM;
}
@@ -80,7 +80,7 @@ static void __vb2_buf_mem_free(struct vb2_buffer *vb)
unsigned int plane;
for (plane = 0; plane vb-num_planes; ++plane) {
- call_memop(q, plane, put, vb-planes[plane].mem_priv);
+ call_memop(q, put, vb-planes[plane].mem_priv);
vb-planes[plane].mem_priv = NULL;
dprintk(3, Freed plane %d of buffer %d\n,
plane, vb-v4l2_buf.index);
@@ -100,7 +100,7 @@ static void __vb2_buf_userptr_put(struct vb2_buffer *vb)
void *mem_priv = vb-planes[plane].mem_priv;
if (mem_priv) {
- call_memop(q, plane, put_userptr, mem_priv);
+ call_memop(q, put_userptr, mem_priv);
vb-planes[plane].mem_priv = NULL;
}
}
@@ -328,7 +328,7 @@ static bool __buffer_in_use(struct vb2_queue *q, struct
vb2_buffer *vb)
* case anyway. If num_users() returns more than 1,
* we are not the only user of the plane's memory.
*/
- if (mem_priv call_memop(q, plane, num_users, mem_priv) 1)
+ if (mem_priv call_memop(q, num_users, mem_priv) 1)
return true;
}
return false;
@@ -793,7 +793,7 @@ void *vb2_plane_vaddr(struct vb2_buffer *vb, unsigned int
plane_no)
if (plane_no vb-num_planes)
return NULL;
- return call_memop(q, plane_no, vaddr, vb-planes[plane_no].mem_priv);
+ return call_memop(q, vaddr, vb-planes[plane_no].mem_priv);
}
EXPORT_SYMBOL_GPL(vb2_plane_vaddr);
@@ -816,7 +816,7 @@ void *vb2_plane_cookie(struct vb2_buffer *vb, unsigned int
plane_no)
if (plane_no vb-num_planes)
return NULL;
- return call_memop(q, plane_no, cookie, vb-planes[plane_no].mem_priv);
+ return call_memop(q, cookie, vb-planes[plane_no].mem_priv);
}
EXPORT_SYMBOL_GPL(vb2_plane_cookie);
@@ -966,8 +966,7 @@ static int __qbuf_userptr(struct vb2_buffer *vb, const
struct v4l2_buffer *b)
/* Release previously acquired memory if present */
if (vb-planes[plane].mem_priv)
- call_memop(q, plane, put_userptr,
- vb-planes[plane].mem_priv);
+ call_memop(q, put_userptr, vb-planes[plane].mem_priv);
vb-planes[plane].mem_priv = NULL;
vb-v4l2_planes[plane].m.userptr = 0;
@@ -1011,8 +1010,7 @@ err:
/* In case of errors, release planes that were already acquired */
for (plane = 0; plane vb-num_planes; ++plane) {
if (vb-planes[plane].mem_priv)
- call_memop(q, plane, put_userptr,
- vb-planes[plane].mem_priv);
+ call_memop(q, put_userptr, vb-planes[plane].mem_priv);
vb-planes[plane].mem_priv = NULL;
vb-v4l2_planes[plane].m.userptr = 0;
vb-v4l2_planes[plane].length = 0;
--
1.7.5.4
--
To
[PATCH 05/10] v4l: add buffer exporting via dmabuf
This patch adds extension to V4L2 api. It allow to export a mmap buffer as file
descriptor. New ioctl VIDIOC_EXPBUF is added. It takes a buffer offset used by
mmap and return a file descriptor on success.
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/v4l2-compat-ioctl32.c |1 +
drivers/media/video/v4l2-ioctl.c | 11 +++
include/linux/videodev2.h |1 +
include/media/v4l2-ioctl.h|1 +
4 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/v4l2-compat-ioctl32.c
b/drivers/media/video/v4l2-compat-ioctl32.c
index c68531b..0f18b5e 100644
--- a/drivers/media/video/v4l2-compat-ioctl32.c
+++ b/drivers/media/video/v4l2-compat-ioctl32.c
@@ -954,6 +954,7 @@ long v4l2_compat_ioctl32(struct file *file, unsigned int
cmd, unsigned long arg)
case VIDIOC_S_FBUF32:
case VIDIOC_OVERLAY32:
case VIDIOC_QBUF32:
+ case VIDIOC_EXPBUF:
case VIDIOC_DQBUF32:
case VIDIOC_STREAMON32:
case VIDIOC_STREAMOFF32:
diff --git a/drivers/media/video/v4l2-ioctl.c b/drivers/media/video/v4l2-ioctl.c
index e1da8fc..cb29e00 100644
--- a/drivers/media/video/v4l2-ioctl.c
+++ b/drivers/media/video/v4l2-ioctl.c
@@ -207,6 +207,7 @@ static const char *v4l2_ioctls[] = {
[_IOC_NR(VIDIOC_S_FBUF)] = VIDIOC_S_FBUF,
[_IOC_NR(VIDIOC_OVERLAY)] = VIDIOC_OVERLAY,
[_IOC_NR(VIDIOC_QBUF)] = VIDIOC_QBUF,
+ [_IOC_NR(VIDIOC_EXPBUF)] = VIDIOC_EXPBUF,
[_IOC_NR(VIDIOC_DQBUF)]= VIDIOC_DQBUF,
[_IOC_NR(VIDIOC_STREAMON)] = VIDIOC_STREAMON,
[_IOC_NR(VIDIOC_STREAMOFF)]= VIDIOC_STREAMOFF,
@@ -932,6 +933,16 @@ static long __video_do_ioctl(struct file *file,
dbgbuf(cmd, vfd, p);
break;
}
+ case VIDIOC_EXPBUF:
+ {
+ unsigned int *p = arg;
+
+ if (!ops-vidioc_expbuf)
+ break;
+
+ ret = ops-vidioc_expbuf(file, fh, *p);
+ break;
+ }
case VIDIOC_DQBUF:
{
struct v4l2_buffer *p = arg;
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 3c0ade1..448fbed 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -2183,6 +2183,7 @@ struct v4l2_create_buffers {
#define VIDIOC_S_FBUF _IOW('V', 11, struct v4l2_framebuffer)
#define VIDIOC_OVERLAY _IOW('V', 14, int)
#define VIDIOC_QBUF_IOWR('V', 15, struct v4l2_buffer)
+#define VIDIOC_EXPBUF _IOWR('V', 16, __u32)
#define VIDIOC_DQBUF _IOWR('V', 17, struct v4l2_buffer)
#define VIDIOC_STREAMON _IOW('V', 18, int)
#define VIDIOC_STREAMOFF_IOW('V', 19, int)
diff --git a/include/media/v4l2-ioctl.h b/include/media/v4l2-ioctl.h
index 4d1c74a..8201546 100644
--- a/include/media/v4l2-ioctl.h
+++ b/include/media/v4l2-ioctl.h
@@ -120,6 +120,7 @@ struct v4l2_ioctl_ops {
int (*vidioc_reqbufs) (struct file *file, void *fh, struct
v4l2_requestbuffers *b);
int (*vidioc_querybuf)(struct file *file, void *fh, struct v4l2_buffer
*b);
int (*vidioc_qbuf)(struct file *file, void *fh, struct v4l2_buffer
*b);
+ int (*vidioc_expbuf) (struct file *file, void *fh, __u32 offset);
int (*vidioc_dqbuf) (struct file *file, void *fh, struct v4l2_buffer
*b);
int (*vidioc_create_bufs)(struct file *file, void *fh, struct
v4l2_create_buffers *b);
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 01/10] arm: dma: support for dma_get_pages
This patch provides reliable mechanism for obtaining pages associated with a
given dma_mapping. This is a proof-of-concept patch.
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
arch/arm/include/asm/dma-mapping.h |8 ++
arch/arm/mm/dma-mapping.c | 44
include/linux/dma-mapping.h|2 +
3 files changed, 54 insertions(+), 0 deletions(-)
diff --git a/arch/arm/include/asm/dma-mapping.h
b/arch/arm/include/asm/dma-mapping.h
index ca7a378..79b6c3d 100644
--- a/arch/arm/include/asm/dma-mapping.h
+++ b/arch/arm/include/asm/dma-mapping.h
@@ -196,6 +196,14 @@ static inline int dma_mmap_attrs(struct device *dev,
struct vm_area_struct *vma,
return ops-mmap(dev, vma, cpu_addr, dma_addr, size, attrs);
}
+static inline int dma_get_pages(struct device *dev, void *cpu_addr,
+ dma_addr_t dma_addr, struct page **pages, size_t n_pages)
+{
+ const struct dma_map_ops *ops = get_dma_ops(dev);
+ BUG_ON(!ops);
+ return ops-get_pages(dev, cpu_addr, dma_addr, pages, n_pages);
+}
+
static inline void *dma_alloc_writecombine(struct device *dev, size_t size,
dma_addr_t *dma_handle, gfp_t flag)
{
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index 2287b01..93a3508 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -116,10 +116,14 @@ static void arm_dma_sync_single_for_device(struct device
*dev,
static int arm_dma_set_mask(struct device *dev, u64 dma_mask);
+static int arm_dma_get_pages(struct device *dev, void *cpu_addr,
+ dma_addr_t dma_addr, struct page **pages, size_t n_pages);
+
struct dma_map_ops arm_dma_ops = {
.alloc = arm_dma_alloc,
.free = arm_dma_free,
.mmap = arm_dma_mmap,
+ .get_pages = arm_dma_get_pages,
.map_page = arm_dma_map_page,
.unmap_page = arm_dma_unmap_page,
.map_sg = arm_dma_map_sg,
@@ -531,6 +535,25 @@ int arm_dma_mmap(struct device *dev, struct vm_area_struct
*vma,
}
/*
+ * Get pages for the DMA-coherent memory.
+ */
+static int arm_dma_get_pages(struct device *dev, void *cpu_addr,
+ dma_addr_t dma_addr, struct page **pages, size_t n_pages)
+{
+#ifdef CONFIG_MMU
+ int i;
+ unsigned long pfn = dma_to_pfn(dev, dma_addr);
+
+ for (i = 0; i n_pages; ++i)
+ pages[i] = pfn_to_page(pfn + i);
+
+ return n_pages;
+#else
+ return -ENXIO;
+#endif /* CONFIG_MMU */
+}
+
+/*
* free a page as defined by the above mapping.
* Must not be called with IRQs disabled.
*/
@@ -1033,6 +1056,26 @@ static int arm_iommu_mmap_attrs(struct device *dev,
struct vm_area_struct *vma,
return 0;
}
+static int arm_iommu_get_pages(struct device *dev, void *cpu_addr,
+ dma_addr_t dma_addr, struct page **pages, size_t n_pages)
+{
+ struct arm_vmregion *c;
+ int n_valid_pages;
+
+ c = arm_vmregion_find(consistent_head, (unsigned long)cpu_addr);
+
+ if (!c)
+ return -ENXIO;
+
+ n_valid_pages = (c-vm_end - c-vm_start) PAGE_SHIFT;
+ if (n_valid_pages n_pages)
+ n_pages = n_valid_pages;
+
+ memcpy(pages, c-priv, n_pages * sizeof pages[0]);
+
+ return n_pages;
+}
+
/*
* free a page as defined by the above mapping.
* Must not be called with IRQs disabled.
@@ -1271,6 +1314,7 @@ struct dma_map_ops iommu_ops = {
.alloc = arm_iommu_alloc_attrs,
.free = arm_iommu_free_attrs,
.mmap = arm_iommu_mmap_attrs,
+ .get_pages = arm_iommu_get_pages,
.map_page = arm_iommu_map_page,
.unmap_page = arm_iommu_unmap_page,
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index b903a20..409d3a9 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -17,6 +17,8 @@ struct dma_map_ops {
struct dma_attrs *attrs);
int (*mmap)(struct device *, struct vm_area_struct *,
void *, dma_addr_t, size_t, struct dma_attrs *attrs);
+ int (*get_pages)(struct device *dev, void *vaddr, dma_addr_t dma_addr,
+ struct page **pages, size_t n_pages);
dma_addr_t (*map_page)(struct device *dev, struct page *page,
unsigned long offset, size_t size,
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 04/10] v4l: vb2: fixes for DMABUF support
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/videobuf2-core.c | 21 +
include/media/videobuf2-core.h |6 +++---
2 files changed, 12 insertions(+), 15 deletions(-)
diff --git a/drivers/media/video/videobuf2-core.c
b/drivers/media/video/videobuf2-core.c
index cb85874..59bb1bc 100644
--- a/drivers/media/video/videobuf2-core.c
+++ b/drivers/media/video/videobuf2-core.c
@@ -119,7 +119,7 @@ static void __vb2_buf_dmabuf_put(struct vb2_buffer *vb)
void *mem_priv = vb-planes[plane].mem_priv;
if (mem_priv) {
- call_memop(q, plane, detach_dmabuf, mem_priv);
+ call_memop(q, detach_dmabuf, mem_priv);
dma_buf_put(vb-planes[plane].dbuf);
vb-planes[plane].dbuf = NULL;
vb-planes[plane].mem_priv = NULL;
@@ -907,6 +907,8 @@ static int __fill_vb2_buffer(struct vb2_buffer *vb, const
struct v4l2_buffer *b,
if (b-memory == V4L2_MEMORY_DMABUF) {
for (plane = 0; plane vb-num_planes; ++plane) {
v4l2_planes[plane].m.fd =
b-m.planes[plane].m.fd;
+ v4l2_planes[plane].length =
+ b-m.planes[plane].length;
}
}
} else {
@@ -1055,15 +1057,10 @@ static int __qbuf_dmabuf(struct vb2_buffer *vb, const
struct v4l2_buffer *b)
if (IS_ERR_OR_NULL(dbuf)) {
dprintk(1, qbuf: invalid dmabuf fd for
plane %d\n, plane);
- ret = PTR_ERR(dbuf);
+ ret = -EINVAL;
goto err;
}
- /* this doesn't get filled in until __fill_vb2_buffer(),
-* since it isn't known until after dma_buf_get()..
-*/
- planes[plane].length = dbuf-size;
-
/* Skip the plane if already verified */
if (dbuf == vb-planes[plane].dbuf) {
dma_buf_put(dbuf);
@@ -1075,7 +1072,7 @@ static int __qbuf_dmabuf(struct vb2_buffer *vb, const
struct v4l2_buffer *b)
/* Release previously acquired memory if present */
if (vb-planes[plane].mem_priv) {
- call_memop(q, plane, detach_dmabuf,
+ call_memop(q, detach_dmabuf,
vb-planes[plane].mem_priv);
dma_buf_put(vb-planes[plane].dbuf);
}
@@ -1083,8 +1080,8 @@ static int __qbuf_dmabuf(struct vb2_buffer *vb, const
struct v4l2_buffer *b)
vb-planes[plane].mem_priv = NULL;
/* Acquire each plane's memory */
- mem_priv = q-mem_ops-attach_dmabuf(
- q-alloc_ctx[plane], dbuf);
+ mem_priv = q-mem_ops-attach_dmabuf(q-alloc_ctx[plane],
+ dbuf, planes[plane].length, write);
if (IS_ERR(mem_priv)) {
dprintk(1, qbuf: failed acquiring dmabuf
memory for plane %d\n, plane);
@@ -1102,7 +1099,7 @@ static int __qbuf_dmabuf(struct vb2_buffer *vb, const
struct v4l2_buffer *b)
*/
for (plane = 0; plane vb-num_planes; ++plane) {
ret = q-mem_ops-map_dmabuf(
- vb-planes[plane].mem_priv, write);
+ vb-planes[plane].mem_priv);
if (ret) {
dprintk(1, qbuf: failed mapping dmabuf
memory for plane %d\n, plane);
@@ -1497,7 +1494,7 @@ int vb2_dqbuf(struct vb2_queue *q, struct v4l2_buffer *b,
bool nonblocking)
*/
if (q-memory == V4L2_MEMORY_DMABUF)
for (plane = 0; plane vb-num_planes; ++plane)
- call_memop(q, plane, unmap_dmabuf,
+ call_memop(q, unmap_dmabuf,
vb-planes[plane].mem_priv);
switch (vb-state) {
diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
index d8b8171..412c6a4 100644
--- a/include/media/videobuf2-core.h
+++ b/include/media/videobuf2-core.h
@@ -88,10 +88,10 @@ struct vb2_mem_ops {
* in the vb2 core, and vb2_mem_ops really just need to get/put the
* sglist (and make sure that the sglist fits it's needs..)
*/
- void*(*attach_dmabuf)(void *alloc_ctx,
- struct dma_buf *dbuf);
+ void*(*attach_dmabuf)(void *alloc_ctx, struct dma_buf *dbuf,
+ unsigned long size, int write);
void(*detach_dmabuf)(void *buf_priv);
- int (*map_dmabuf)(void *buf_priv, int write);
Re: DVB-S2 multistream support
Hello Christian Konstantin, we look forward for your patch. Here are some hints, what we want to do. Now we read TS packets from standard userspace API (/dev/dvb/adapter0/dvr0, for video data processing) or use libdvbapi/dvbnet.h (for IP over DVB data, MPE decapsulation). In future we want to receive ACM/GSE data. So we plan to read whole BBFrame data and decapsulate it. But if there will be GSE decapsulation in linuxtv.org kernel layer, then we don't need whole BBFrame. It would be nice to have acces to some usefull data from BBF headers particularly: TS/GS field, SIS/MIS flag, CCM/ACM flag, it should be statical value throught several BBF. Other usefull data which is diffrent from more BBF is Imput stream ID (ISI). Can it be accesible as list of received values ? This values could be accessible throught standard S2API sytem call ioctl(FE_GET_PROPERTY, struct dtv_property) or if whole BBFrame/BBFheader will be accessible, we can read it ourself from BBF header. BTW: We have GPL source code for GSE decapsulation from Karsten Siebert. If you don't have implement yet, this one can be used, it is in kernel space compatible format. -- Marek Ochaba -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 04/10] v4l: vb2: fixes for DMABUF support
Em 23-01-2012 11:51, Tomasz Stanislawski escreveu:
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Please better describe this patch. What is it supposing to fix?
---
drivers/media/video/videobuf2-core.c | 21 +
include/media/videobuf2-core.h |6 +++---
2 files changed, 12 insertions(+), 15 deletions(-)
diff --git a/drivers/media/video/videobuf2-core.c
b/drivers/media/video/videobuf2-core.c
index cb85874..59bb1bc 100644
--- a/drivers/media/video/videobuf2-core.c
+++ b/drivers/media/video/videobuf2-core.c
@@ -119,7 +119,7 @@ static void __vb2_buf_dmabuf_put(struct vb2_buffer *vb)
void *mem_priv = vb-planes[plane].mem_priv;
if (mem_priv) {
- call_memop(q, plane, detach_dmabuf, mem_priv);
+ call_memop(q, detach_dmabuf, mem_priv);
Huh? You're not removing the plane parameter on this patch, but, instead,
on a previous patch.
No patch is allowed to break compilation, as it breaks git bisect.
dma_buf_put(vb-planes[plane].dbuf);
vb-planes[plane].dbuf = NULL;
vb-planes[plane].mem_priv = NULL;
@@ -907,6 +907,8 @@ static int __fill_vb2_buffer(struct vb2_buffer *vb, const
struct v4l2_buffer *b,
if (b-memory == V4L2_MEMORY_DMABUF) {
for (plane = 0; plane vb-num_planes; ++plane) {
v4l2_planes[plane].m.fd =
b-m.planes[plane].m.fd;
+ v4l2_planes[plane].length =
+ b-m.planes[plane].length;
}
}
} else {
@@ -1055,15 +1057,10 @@ static int __qbuf_dmabuf(struct vb2_buffer *vb, const
struct v4l2_buffer *b)
if (IS_ERR_OR_NULL(dbuf)) {
dprintk(1, qbuf: invalid dmabuf fd for
plane %d\n, plane);
- ret = PTR_ERR(dbuf);
+ ret = -EINVAL;
goto err;
}
- /* this doesn't get filled in until __fill_vb2_buffer(),
- * since it isn't known until after dma_buf_get()..
- */
- planes[plane].length = dbuf-size;
-
/* Skip the plane if already verified */
if (dbuf == vb-planes[plane].dbuf) {
dma_buf_put(dbuf);
@@ -1075,7 +1072,7 @@ static int __qbuf_dmabuf(struct vb2_buffer *vb, const
struct v4l2_buffer *b)
/* Release previously acquired memory if present */
if (vb-planes[plane].mem_priv) {
- call_memop(q, plane, detach_dmabuf,
+ call_memop(q, detach_dmabuf,
vb-planes[plane].mem_priv);
dma_buf_put(vb-planes[plane].dbuf);
}
@@ -1083,8 +1080,8 @@ static int __qbuf_dmabuf(struct vb2_buffer *vb, const
struct v4l2_buffer *b)
vb-planes[plane].mem_priv = NULL;
/* Acquire each plane's memory */
- mem_priv = q-mem_ops-attach_dmabuf(
- q-alloc_ctx[plane], dbuf);
+ mem_priv = q-mem_ops-attach_dmabuf(q-alloc_ctx[plane],
+ dbuf, planes[plane].length, write);
if (IS_ERR(mem_priv)) {
dprintk(1, qbuf: failed acquiring dmabuf
memory for plane %d\n, plane);
@@ -1102,7 +1099,7 @@ static int __qbuf_dmabuf(struct vb2_buffer *vb, const
struct v4l2_buffer *b)
*/
for (plane = 0; plane vb-num_planes; ++plane) {
ret = q-mem_ops-map_dmabuf(
- vb-planes[plane].mem_priv, write);
+ vb-planes[plane].mem_priv);
if (ret) {
dprintk(1, qbuf: failed mapping dmabuf
memory for plane %d\n, plane);
@@ -1497,7 +1494,7 @@ int vb2_dqbuf(struct vb2_queue *q, struct v4l2_buffer
*b, bool nonblocking)
*/
if (q-memory == V4L2_MEMORY_DMABUF)
for (plane = 0; plane vb-num_planes; ++plane)
- call_memop(q, plane, unmap_dmabuf,
+ call_memop(q, unmap_dmabuf,
vb-planes[plane].mem_priv);
switch (vb-state) {
diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
index d8b8171..412c6a4 100644
--- a/include/media/videobuf2-core.h
+++ b/include/media/videobuf2-core.h
@@ -88,10 +88,10 @@ struct vb2_mem_ops {
* in the vb2 core, and vb2_mem_ops really just need to get/put the
* sglist (and make sure that the sglist fits it's needs..)
*/
- void*(*attach_dmabuf)(void *alloc_ctx,
- struct dma_buf *dbuf);
+ void
Re: [PATCH 07/10] v4l: vb2: remove dma-contig allocator
Em 23-01-2012 11:51, Tomasz Stanislawski escreveu:
This is temporary patch. The dma-contig changes were significant
and the difference patch would be very difficult to read.
NACK.
This breaks git bisect.
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/videobuf2-dma-contig.c | 308
1 files changed, 0 insertions(+), 308 deletions(-)
delete mode 100644 drivers/media/video/videobuf2-dma-contig.c
diff --git a/drivers/media/video/videobuf2-dma-contig.c
b/drivers/media/video/videobuf2-dma-contig.c
deleted file mode 100644
index ea2699f..000
--- a/drivers/media/video/videobuf2-dma-contig.c
+++ /dev/null
@@ -1,308 +0,0 @@
-/*
- * videobuf2-dma-contig.c - DMA contig memory allocator for videobuf2
- *
- * Copyright (C) 2010 Samsung Electronics
- *
- * Author: Pawel Osciak pa...@osciak.com
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation.
- */
-
-#include linux/module.h
-#include linux/slab.h
-#include linux/dma-mapping.h
-#include linux/scatterlist.h
-#include linux/dma-buf.h
-
-#include media/videobuf2-core.h
-#include media/videobuf2-memops.h
-
-struct vb2_dc_conf {
- struct device *dev;
-};
-
-struct vb2_dc_buf {
- struct vb2_dc_conf *conf;
- void*vaddr;
- dma_addr_t dma_addr;
- unsigned long size;
- struct vm_area_struct *vma;
- struct dma_buf_attachment *db_attach;
- atomic_trefcount;
- struct vb2_vmarea_handler handler;
-};
-
-static void vb2_dma_contig_put(void *buf_priv);
-
-static void *vb2_dma_contig_alloc(void *alloc_ctx, unsigned long size)
-{
- struct vb2_dc_conf *conf = alloc_ctx;
- struct vb2_dc_buf *buf;
- /* TODO: add db_attach processing while adding DMABUF as exporter */
-
- buf = kzalloc(sizeof *buf, GFP_KERNEL);
- if (!buf)
- return ERR_PTR(-ENOMEM);
-
- buf-vaddr = dma_alloc_coherent(conf-dev, size, buf-dma_addr,
- GFP_KERNEL);
- if (!buf-vaddr) {
- dev_err(conf-dev, dma_alloc_coherent of size %ld failed\n,
- size);
- kfree(buf);
- return ERR_PTR(-ENOMEM);
- }
-
- buf-conf = conf;
- buf-size = size;
-
- buf-handler.refcount = buf-refcount;
- buf-handler.put = vb2_dma_contig_put;
- buf-handler.arg = buf;
-
- atomic_inc(buf-refcount);
-
- return buf;
-}
-
-static void vb2_dma_contig_put(void *buf_priv)
-{
- struct vb2_dc_buf *buf = buf_priv;
-
- if (atomic_dec_and_test(buf-refcount)) {
- dma_free_coherent(buf-conf-dev, buf-size, buf-vaddr,
- buf-dma_addr);
- kfree(buf);
- }
-}
-
-static void *vb2_dma_contig_cookie(void *buf_priv)
-{
- struct vb2_dc_buf *buf = buf_priv;
-
- return buf-dma_addr;
-}
-
-static void *vb2_dma_contig_vaddr(void *buf_priv)
-{
- struct vb2_dc_buf *buf = buf_priv;
- if (!buf)
- return 0;
-
- return buf-vaddr;
-}
-
-static unsigned int vb2_dma_contig_num_users(void *buf_priv)
-{
- struct vb2_dc_buf *buf = buf_priv;
-
- return atomic_read(buf-refcount);
-}
-
-static int vb2_dma_contig_mmap(void *buf_priv, struct vm_area_struct *vma)
-{
- struct vb2_dc_buf *buf = buf_priv;
-
- if (!buf) {
- printk(KERN_ERR No buffer to map\n);
- return -EINVAL;
- }
-
- return vb2_mmap_pfn_range(vma, buf-dma_addr, buf-size,
- vb2_common_vm_ops, buf-handler);
-}
-
-static void *vb2_dma_contig_get_userptr(void *alloc_ctx, unsigned long vaddr,
- unsigned long size, int write)
-{
- struct vb2_dc_buf *buf;
- struct vm_area_struct *vma;
- dma_addr_t dma_addr = 0;
- int ret;
-
- buf = kzalloc(sizeof *buf, GFP_KERNEL);
- if (!buf)
- return ERR_PTR(-ENOMEM);
-
- ret = vb2_get_contig_userptr(vaddr, size, vma, dma_addr);
- if (ret) {
- printk(KERN_ERR Failed acquiring VMA for vaddr 0x%08lx\n,
- vaddr);
- kfree(buf);
- return ERR_PTR(ret);
- }
-
- buf-size = size;
- buf-dma_addr = dma_addr;
- buf-vma = vma;
-
- return buf;
-}
-
-static void vb2_dma_contig_put_userptr(void *mem_priv)
-{
- struct vb2_dc_buf *buf = mem_priv;
-
- if (!buf)
- return;
-
- vb2_put_vma(buf-vma);
- kfree(buf);
-}
-
-static int vb2_dma_contig_map_dmabuf(void *mem_priv,
-
Re: [PATCH 08/10] v4l: vb2-dma-contig: code refactoring, support for DMABUF exporting
Em 23-01-2012 11:51, Tomasz Stanislawski escreveu:
Signed-off-by: Pawel Osciak pa...@osciak.com
[author of the original file]
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
[implemetation of mmap, finish/prepare]
Signed-off-by: Andrzej Pietrasiewicz andrze...@samsung.com
[implementation of userprt handling]
Signed-off-by: Sumit Semwal sumit.sem...@ti.com
Signed-off-by: Sumit Semwal sumit.sem...@linaro.org
[PoC for importing dmabuf buffer]
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
[buffer exporting using dmabuf, code refactoring]
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Please provide a diff against the existing driver, in order to allow reviewing
what has changed.
---
drivers/media/video/videobuf2-dma-contig.c | 762
1 files changed, 762 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/videobuf2-dma-contig.c
diff --git a/drivers/media/video/videobuf2-dma-contig.c
b/drivers/media/video/videobuf2-dma-contig.c
new file mode 100644
index 000..d95b23a
--- /dev/null
+++ b/drivers/media/video/videobuf2-dma-contig.c
@@ -0,0 +1,762 @@
+/*
+ * videobuf2-dma-contig.c - DMA contig memory allocator for videobuf2
+ *
+ * Copyright (C) 2010 Samsung Electronics
+ *
+ * Author: Pawel Osciak pa...@osciak.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation.
+ */
+
+#include linux/dma-buf.h
+#include linux/dma-mapping.h
+#include linux/module.h
+#include linux/scatterlist.h
+#include linux/sched.h
+#include linux/slab.h
+
+#include media/videobuf2-core.h
+#include media/videobuf2-memops.h
+
+struct vb2_dc_buf {
+ struct device *dev;
+ void*vaddr;
+ unsigned long size;
+ dma_addr_t dma_addr;
+ struct sg_table *dma_sgt;
+ enum dma_data_direction dma_dir;
+
+ /* MMAP related */
+ struct vb2_vmarea_handler handler;
+ atomic_trefcount;
+ struct dma_buf *dma_buf;
+ struct sg_table *sgt_base;
+
+ /* USERPTR related */
+ struct vm_area_struct *vma;
+
+ /* DMABUF related */
+ struct dma_buf_attachment *db_attach;
+};
+
+/*/
+/*scatterlist table functions*/
+/*/
+
+static struct sg_table *vb2_dc_pages_to_sgt(struct page **pages,
+ unsigned long n_pages, size_t offset, size_t offset2)
+{
+ struct sg_table *sgt;
+ int i, j; /* loop counters */
+ int cur_page, chunks;
+ int ret;
+ struct scatterlist *s;
+
+ sgt = kzalloc(sizeof *sgt, GFP_KERNEL);
+ if (!sgt)
+ return ERR_PTR(-ENOMEM);
+
+ /* compute number of chunks */
+ chunks = 1;
+ for (i = 1; i n_pages; ++i)
+ if (pages[i] != pages[i - 1] + 1)
+ ++chunks;
+
+ ret = sg_alloc_table(sgt, chunks, GFP_KERNEL);
+ if (ret) {
+ kfree(sgt);
+ return ERR_PTR(-ENOMEM);
+ }
+
+ /* merging chunks and putting them into the scatterlist */
+ cur_page = 0;
+ for_each_sg(sgt-sgl, s, sgt-orig_nents, i) {
+ size_t size = PAGE_SIZE;
+
+ for (j = cur_page + 1; j n_pages; ++j) {
+ if (pages[j] != pages[j - 1] + 1)
+ break;
+ size += PAGE_SIZE;
+ }
+
+ /* cut offset if chunk starts at the first page */
+ if (cur_page == 0)
+ size -= offset;
+ /* cut offset2 if chunk ends at the last page */
+ if (j == n_pages)
+ size -= offset2;
+
+ sg_set_page(s, pages[cur_page], size, offset);
+ offset = 0;
+ cur_page = j;
+ }
+
+ return sgt;
+}
+
+static void vb2_dc_release_sgtable(struct sg_table *sgt)
+{
+ sg_free_table(sgt);
+ kfree(sgt);
+}
+
+static void vb2_dc_put_sgtable(struct sg_table *sgt, int dirty)
+{
+ struct scatterlist *s;
+ int i, j;
+
+ for_each_sg(sgt-sgl, s, sgt-nents, i) {
+ struct page *page = sg_page(s);
+ int n_pages = PAGE_ALIGN(s-offset + s-length) PAGE_SHIFT;
+
+ for (j = 0; j n_pages; ++j, ++page) {
+ if (dirty)
+ set_page_dirty_lock(page);
+ put_page(page);
+ }
+ }
+
+ vb2_dc_release_sgtable(sgt);
+}
+
+static unsigned long vb2_dc_get_contiguous_size(struct sg_table *sgt)
+{
+ struct scatterlist *s;
+ dma_addr_t
Re: [PATCH 04/10] v4l: vb2: fixes for DMABUF support
Hi Mauro,
On 01/23/2012 03:22 PM, Mauro Carvalho Chehab wrote:
Em 23-01-2012 11:51, Tomasz Stanislawski escreveu:
Signed-off-by: Tomasz Stanislawskit.stanisl...@samsung.com
Signed-off-by: Kyungmin Parkkyungmin.p...@samsung.com
Please better describe this patch. What is it supposing to fix?
Usually compilation error or bugs discovered in previous vb2-dma-contig
patches adding support for dma-buf.
---
drivers/media/video/videobuf2-core.c | 21 +
include/media/videobuf2-core.h |6 +++---
2 files changed, 12 insertions(+), 15 deletions(-)
diff --git a/drivers/media/video/videobuf2-core.c
b/drivers/media/video/videobuf2-core.c
index cb85874..59bb1bc 100644
--- a/drivers/media/video/videobuf2-core.c
+++ b/drivers/media/video/videobuf2-core.c
@@ -119,7 +119,7 @@ static void __vb2_buf_dmabuf_put(struct vb2_buffer *vb)
void *mem_priv = vb-planes[plane].mem_priv;
if (mem_priv) {
- call_memop(q, plane, detach_dmabuf, mem_priv);
+ call_memop(q, detach_dmabuf, mem_priv);
Huh? You're not removing the plane parameter on this patch, but, instead,
on a previous patch.
No patch is allowed to break compilation, as it breaks git bisect.
I agree that patches should not break compilation if patches are
accepted to the mainline. There is a big compilation failure at patch 07
where videobuf2-dma-contig.c disappears.
Note that these are proof-of-concept patches for support of dma-buf
exporting/importing dma-buf in V4L2. It would be a waste of time
polished the patches if they are going to be rejected due to design flaws.
Regards,
Tomasz Stanislawski
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/10] v4l: add buffer exporting via dmabuf
Em 23-01-2012 11:51, Tomasz Stanislawski escreveu:
This patch adds extension to V4L2 api. It allow to export a mmap buffer as
file
descriptor. New ioctl VIDIOC_EXPBUF is added. It takes a buffer offset used by
mmap and return a file descriptor on success.
This requires more discussions.
The usecase for this new API seems to replace the features previously provided
by the overlay mode. There, not only the buffer were exposed to userspace, but
some control were provided, in order to control the overlay window.
Please start a separate thread about that, explaining how are you imagining that
a V4L2 application would use such ioctl.
Regards,
Mauro
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/v4l2-compat-ioctl32.c |1 +
drivers/media/video/v4l2-ioctl.c | 11 +++
include/linux/videodev2.h |1 +
include/media/v4l2-ioctl.h|1 +
4 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/v4l2-compat-ioctl32.c
b/drivers/media/video/v4l2-compat-ioctl32.c
index c68531b..0f18b5e 100644
--- a/drivers/media/video/v4l2-compat-ioctl32.c
+++ b/drivers/media/video/v4l2-compat-ioctl32.c
@@ -954,6 +954,7 @@ long v4l2_compat_ioctl32(struct file *file, unsigned int
cmd, unsigned long arg)
case VIDIOC_S_FBUF32:
case VIDIOC_OVERLAY32:
case VIDIOC_QBUF32:
+ case VIDIOC_EXPBUF:
case VIDIOC_DQBUF32:
case VIDIOC_STREAMON32:
case VIDIOC_STREAMOFF32:
diff --git a/drivers/media/video/v4l2-ioctl.c
b/drivers/media/video/v4l2-ioctl.c
index e1da8fc..cb29e00 100644
--- a/drivers/media/video/v4l2-ioctl.c
+++ b/drivers/media/video/v4l2-ioctl.c
@@ -207,6 +207,7 @@ static const char *v4l2_ioctls[] = {
[_IOC_NR(VIDIOC_S_FBUF)] = VIDIOC_S_FBUF,
[_IOC_NR(VIDIOC_OVERLAY)] = VIDIOC_OVERLAY,
[_IOC_NR(VIDIOC_QBUF)] = VIDIOC_QBUF,
+ [_IOC_NR(VIDIOC_EXPBUF)] = VIDIOC_EXPBUF,
[_IOC_NR(VIDIOC_DQBUF)]= VIDIOC_DQBUF,
[_IOC_NR(VIDIOC_STREAMON)] = VIDIOC_STREAMON,
[_IOC_NR(VIDIOC_STREAMOFF)]= VIDIOC_STREAMOFF,
@@ -932,6 +933,16 @@ static long __video_do_ioctl(struct file *file,
dbgbuf(cmd, vfd, p);
break;
}
+ case VIDIOC_EXPBUF:
+ {
+ unsigned int *p = arg;
+
+ if (!ops-vidioc_expbuf)
+ break;
+
+ ret = ops-vidioc_expbuf(file, fh, *p);
+ break;
+ }
case VIDIOC_DQBUF:
{
struct v4l2_buffer *p = arg;
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 3c0ade1..448fbed 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -2183,6 +2183,7 @@ struct v4l2_create_buffers {
#define VIDIOC_S_FBUF _IOW('V', 11, struct v4l2_framebuffer)
#define VIDIOC_OVERLAY_IOW('V', 14, int)
#define VIDIOC_QBUF _IOWR('V', 15, struct v4l2_buffer)
+#define VIDIOC_EXPBUF_IOWR('V', 16, __u32)
#define VIDIOC_DQBUF _IOWR('V', 17, struct v4l2_buffer)
#define VIDIOC_STREAMON _IOW('V', 18, int)
#define VIDIOC_STREAMOFF _IOW('V', 19, int)
diff --git a/include/media/v4l2-ioctl.h b/include/media/v4l2-ioctl.h
index 4d1c74a..8201546 100644
--- a/include/media/v4l2-ioctl.h
+++ b/include/media/v4l2-ioctl.h
@@ -120,6 +120,7 @@ struct v4l2_ioctl_ops {
int (*vidioc_reqbufs) (struct file *file, void *fh, struct
v4l2_requestbuffers *b);
int (*vidioc_querybuf)(struct file *file, void *fh, struct v4l2_buffer
*b);
int (*vidioc_qbuf)(struct file *file, void *fh, struct v4l2_buffer
*b);
+ int (*vidioc_expbuf) (struct file *file, void *fh, __u32 offset);
int (*vidioc_dqbuf) (struct file *file, void *fh, struct v4l2_buffer
*b);
int (*vidioc_create_bufs)(struct file *file, void *fh, struct
v4l2_create_buffers *b);
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 08/10] v4l: vb2-dma-contig: code refactoring, support for DMABUF exporting
Hi, On 01/23/2012 03:26 PM, Mauro Carvalho Chehab wrote: Em 23-01-2012 11:51, Tomasz Stanislawski escreveu: Signed-off-by: Pawel Osciakpa...@osciak.com [author of the original file] Signed-off-by: Marek Szyprowskim.szyprow...@samsung.com [implemetation of mmap, finish/prepare] Signed-off-by: Andrzej Pietrasiewiczandrze...@samsung.com [implementation of userprt handling] Signed-off-by: Sumit Semwalsumit.sem...@ti.com Signed-off-by: Sumit Semwalsumit.sem...@linaro.org [PoC for importing dmabuf buffer] Signed-off-by: Tomasz Stanislawskit.stanisl...@samsung.com [buffer exporting using dmabuf, code refactoring] Signed-off-by: Kyungmin Parkkyungmin.p...@samsung.com Please provide a diff against the existing driver, in order to allow reviewing what has changed. There is no difference patch due to the reasons described in the cover letter. This is a PoC patch and it is dedicated for easy reading. Regards Tomasz Stanislawski -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] media: vb2-memops: Export vb2_get_vma symbol
The vb2_get_vma() function is called by videobuf2-dma-contig. Export it. Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com --- drivers/media/video/videobuf2-memops.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) Hi Thomas, The following patch is needed to compile videobuf2-dma-contig as a module. diff --git a/drivers/media/video/videobuf2-memops.c b/drivers/media/video/videobuf2-memops.c index 71a7a78..718f70e 100644 --- a/drivers/media/video/videobuf2-memops.c +++ b/drivers/media/video/videobuf2-memops.c @@ -55,6 +55,7 @@ struct vm_area_struct *vb2_get_vma(struct vm_area_struct *vma) return vma_copy; } +EXPORT_SYMBOL_GPL(vb2_get_vma); /** * vb2_put_userptr() - release a userspace virtual memory area -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/10] Integration of videobuf2 with dmabuf
Hi Tomasz/Sumit, Em 23-01-2012 11:51, Tomasz Stanislawski escreveu: Hello everyone, This patchset is an incremental patch to patchset created by Sumit Semwal [1]. The patches are dedicated to help find a better solution for support of buffer sharing by V4L2 API. It is expected to start discussion on final installment for dma-buf in vb2-dma-contig allocator. Current version of the patches contain little documentation. It is going to be fixed after achieving consensus about design for buffer exporting. Moreover the API between vb2-core and the allocator should be revised. I just raised a few points for the discussions for a few patches. Please don't understand them as a full review. It isn't. Btw, it would be nice to have vivi support for the dmabuf sharing, in order to allow the patches to be tested by a wider audience, especially due to the new userspace API proposal. Regards, Mauro The amount of changes to vb2-dma-contig.c was significant making the difference patch very difficult to read. Therefore the patch was split into two parts. One removes old file, the next patch creates the version of the file. The patchset contains extension for DMA API and its implementation for ARM architecture. Therefore the patchset should be applied on the top of: http://git.infradead.org/users/kmpark/linux-2.6-samsung/shortlog/refs/heads/3.2-dma-v5 After applying patches from [2] and [1]. 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/42966/focus=42968 [2] https://lkml.org/lkml/2011/12/26/29 [3] http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/36354/focus=36355 Marek Szyprowski (2): [media] media: vb2: remove plane argument from call_memop and cleanup mempriv usage media: vb2: add prepare/finish callbacks to allocators Tomasz Stanislawski (8): arm: dma: support for dma_get_pages v4l: vb2: fixes for DMABUF support v4l: add buffer exporting via dmabuf v4l: vb2: add buffer exporting via dmabuf v4l: vb2: remove dma-contig allocator v4l: vb2-dma-contig: code refactoring, support for DMABUF exporting v4l: fimc: integrate capture i-face with dmabuf v4l: s5p-tv: mixer: integrate with dmabuf arch/arm/include/asm/dma-mapping.h |8 + arch/arm/mm/dma-mapping.c | 44 ++ drivers/media/video/s5p-fimc/fimc-capture.c | 11 +- drivers/media/video/s5p-tv/mixer_video.c| 11 +- drivers/media/video/v4l2-compat-ioctl32.c |1 + drivers/media/video/v4l2-ioctl.c| 11 + drivers/media/video/videobuf2-core.c| 114 - drivers/media/video/videobuf2-dma-contig.c | 754 +-- include/linux/dma-mapping.h |2 + include/linux/videodev2.h |1 + include/media/v4l2-ioctl.h |1 + include/media/videobuf2-core.h | 10 +- 12 files changed, 789 insertions(+), 179 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/10] v4l: add buffer exporting via dmabuf
Hi Mauro, On Monday 23 January 2012 15:32:40 Mauro Carvalho Chehab wrote: Em 23-01-2012 11:51, Tomasz Stanislawski escreveu: This patch adds extension to V4L2 api. It allow to export a mmap buffer as file descriptor. New ioctl VIDIOC_EXPBUF is added. It takes a buffer offset used by mmap and return a file descriptor on success. This requires more discussions. The usecase for this new API seems to replace the features previously provided by the overlay mode. There, not only the buffer were exposed to userspace, but some control were provided, in order to control the overlay window. Please start a separate thread about that, explaining how are you imagining that a V4L2 application would use such ioctl. I think this is currently just a proof of concept. I'm sure Tomasz will discuss the V4L2 API extension on the linux-media list when the code will be stabilized. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 720p webcam providing VDPAU-compatible video stream?
Hi Kristof, On Sunday 22 January 2012 14:03:29 Csillag Kristof wrote: Dear linux-media users, I have stopped following the advancements in Linux video (and video hw in general) a while ago, so I am no longer up to date with the current technologies, therefore I seek your advice. I am looking for for a webcam that - works properly under GNU/Linux (without proprietary drivers) - connects via USB 2.0 - can capture 720p video at 25 or 30 FPS - provides a video stream that - is hardware compressed by the camera - can be recorded to a file with minimal CPU requirements (Bonus points if it's wrapped a nice container format, so that I can simply record it by something like cat /dev/video0 capture.mpeg - like old Hauppauge PVR-250 cards ) - can be decoded by VDPAU hw acceleration I have tried to look into this, and it seems that the status for H264 streams for UVC webcams is still problematic. I think your best bet is still UVC + H.264, as that's what the market is moving to. Any other compressed format (except for MJPEG) will likely be proprietary. As you correctly mention, H.264 support isn't available yet in the UVC driver. Patches are welcome ;-) However, I don't specifically need neither UVC nor H264; any driver, and any other VDPAU-supported format (like MPEG-2, VC-1, WMV9, etc) could be OK. I am not interested in sykpe; I only want to capture the 720p video stream to files (with as low CPU usage as possible), and play it back using mplayer, on NVidia cards supporting VDPAU hw acceleration - again, with as low CPU usage, as possible. Could someone please recommend me a device that can do this? (Or tell me which device will likely get the required support soon? -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/10] v4l: add buffer exporting via dmabuf
Hi Mauro.
On 01/23/2012 03:32 PM, Mauro Carvalho Chehab wrote:
Em 23-01-2012 11:51, Tomasz Stanislawski escreveu:
This patch adds extension to V4L2 api. It allow to export a mmap buffer as file
descriptor. New ioctl VIDIOC_EXPBUF is added. It takes a buffer offset used by
mmap and return a file descriptor on success.
This requires more discussions.
The usecase for this new API seems to replace the features previously provided
by the overlay mode. There, not only the buffer were exposed to userspace, but
some control were provided, in order to control the overlay window.
This ioctl was introduced to support exporting of V4L2 buffers via
dma-buf interface. This framework was little common with overlay mode.
Could you describe what overlay mode feature is replaced by VIDIOC_EXPBUF?
Please start a separate thread about that, explaining how are you imagining that
a V4L2 application would use such ioctl.
This patch is essential for full implementation of support for DMABUF
framework in V4L2. Therefore the patch cannot be moved to separate thread.
Regrads,
Tomasz Stanislawski
Regards,
Mauro
Signed-off-by: Tomasz Stanislawskit.stanisl...@samsung.com
Signed-off-by: Kyungmin Parkkyungmin.p...@samsung.com
---
drivers/media/video/v4l2-compat-ioctl32.c |1 +
drivers/media/video/v4l2-ioctl.c | 11 +++
include/linux/videodev2.h |1 +
include/media/v4l2-ioctl.h|1 +
4 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/v4l2-compat-ioctl32.c
b/drivers/media/video/v4l2-compat-ioctl32.c
index c68531b..0f18b5e 100644
--- a/drivers/media/video/v4l2-compat-ioctl32.c
+++ b/drivers/media/video/v4l2-compat-ioctl32.c
@@ -954,6 +954,7 @@ long v4l2_compat_ioctl32(struct file *file, unsigned int
cmd, unsigned long arg)
case VIDIOC_S_FBUF32:
case VIDIOC_OVERLAY32:
case VIDIOC_QBUF32:
+ case VIDIOC_EXPBUF:
case VIDIOC_DQBUF32:
case VIDIOC_STREAMON32:
case VIDIOC_STREAMOFF32:
diff --git a/drivers/media/video/v4l2-ioctl.c b/drivers/media/video/v4l2-ioctl.c
index e1da8fc..cb29e00 100644
--- a/drivers/media/video/v4l2-ioctl.c
+++ b/drivers/media/video/v4l2-ioctl.c
@@ -207,6 +207,7 @@ static const char *v4l2_ioctls[] = {
[_IOC_NR(VIDIOC_S_FBUF)] = VIDIOC_S_FBUF,
[_IOC_NR(VIDIOC_OVERLAY)] = VIDIOC_OVERLAY,
[_IOC_NR(VIDIOC_QBUF)] = VIDIOC_QBUF,
+ [_IOC_NR(VIDIOC_EXPBUF)] = VIDIOC_EXPBUF,
[_IOC_NR(VIDIOC_DQBUF)]= VIDIOC_DQBUF,
[_IOC_NR(VIDIOC_STREAMON)] = VIDIOC_STREAMON,
[_IOC_NR(VIDIOC_STREAMOFF)]= VIDIOC_STREAMOFF,
@@ -932,6 +933,16 @@ static long __video_do_ioctl(struct file *file,
dbgbuf(cmd, vfd, p);
break;
}
+ case VIDIOC_EXPBUF:
+ {
+ unsigned int *p = arg;
+
+ if (!ops-vidioc_expbuf)
+ break;
+
+ ret = ops-vidioc_expbuf(file, fh, *p);
+ break;
+ }
case VIDIOC_DQBUF:
{
struct v4l2_buffer *p = arg;
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 3c0ade1..448fbed 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -2183,6 +2183,7 @@ struct v4l2_create_buffers {
#define VIDIOC_S_FBUF _IOW('V', 11, struct v4l2_framebuffer)
#define VIDIOC_OVERLAY _IOW('V', 14, int)
#define VIDIOC_QBUF _IOWR('V', 15, struct v4l2_buffer)
+#define VIDIOC_EXPBUF _IOWR('V', 16, __u32)
#define VIDIOC_DQBUF _IOWR('V', 17, struct v4l2_buffer)
#define VIDIOC_STREAMON_IOW('V', 18, int)
#define VIDIOC_STREAMOFF _IOW('V', 19, int)
diff --git a/include/media/v4l2-ioctl.h b/include/media/v4l2-ioctl.h
index 4d1c74a..8201546 100644
--- a/include/media/v4l2-ioctl.h
+++ b/include/media/v4l2-ioctl.h
@@ -120,6 +120,7 @@ struct v4l2_ioctl_ops {
int (*vidioc_reqbufs) (struct file *file, void *fh, struct
v4l2_requestbuffers *b);
int (*vidioc_querybuf)(struct file *file, void *fh, struct v4l2_buffer
*b);
int (*vidioc_qbuf)(struct file *file, void *fh, struct v4l2_buffer
*b);
+ int (*vidioc_expbuf) (struct file *file, void *fh, __u32 offset);
int (*vidioc_dqbuf) (struct file *file, void *fh, struct v4l2_buffer
*b);
int (*vidioc_create_bufs)(struct file *file, void *fh, struct
v4l2_create_buffers *b);
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 08/10] v4l: vb2-dma-contig: code refactoring, support for DMABUF exporting
Em 23-01-2012 12:35, Tomasz Stanislawski escreveu: Hi, On 01/23/2012 03:26 PM, Mauro Carvalho Chehab wrote: Em 23-01-2012 11:51, Tomasz Stanislawski escreveu: Signed-off-by: Pawel Osciakpa...@osciak.com [author of the original file] Signed-off-by: Marek Szyprowskim.szyprow...@samsung.com [implemetation of mmap, finish/prepare] Signed-off-by: Andrzej Pietrasiewiczandrze...@samsung.com [implementation of userprt handling] Signed-off-by: Sumit Semwalsumit.sem...@ti.com Signed-off-by: Sumit Semwalsumit.sem...@linaro.org [PoC for importing dmabuf buffer] Signed-off-by: Tomasz Stanislawskit.stanisl...@samsung.com [buffer exporting using dmabuf, code refactoring] Signed-off-by: Kyungmin Parkkyungmin.p...@samsung.com Please provide a diff against the existing driver, in order to allow reviewing what has changed. There is no difference patch due to the reasons described in the cover letter. This is a PoC patch and it is dedicated for easy reading. There's no way for a reviewer to check if some regressions were added by it, as there's no diff. Those interested on doing an easy reading of the patch changes could just apply the patch and see the results of it, but removing and re-adding really sucks, as the ones interested on see what changed will be a very bad time, especially if you moved functions inside the code. Regards Tomasz Stanislawski -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] media: vb2-memops: Export vb2_get_vma symbol
Hi Laurent, Thank you for finding a bug in vb2-core. Regards, Tomasz Stanislawski On 01/23/2012 03:35 PM, Laurent Pinchart wrote: The vb2_get_vma() function is called by videobuf2-dma-contig. Export it. Signed-off-by: Laurent Pinchartlaurent.pinch...@ideasonboard.com --- drivers/media/video/videobuf2-memops.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) Hi Thomas, The following patch is needed to compile videobuf2-dma-contig as a module. diff --git a/drivers/media/video/videobuf2-memops.c b/drivers/media/video/videobuf2-memops.c index 71a7a78..718f70e 100644 --- a/drivers/media/video/videobuf2-memops.c +++ b/drivers/media/video/videobuf2-memops.c @@ -55,6 +55,7 @@ struct vm_area_struct *vb2_get_vma(struct vm_area_struct *vma) return vma_copy; } +EXPORT_SYMBOL_GPL(vb2_get_vma); /** * vb2_put_userptr() - release a userspace virtual memory area -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 04/10] v4l: vb2: fixes for DMABUF support
Em 23-01-2012 12:32, Tomasz Stanislawski escreveu:
Hi Mauro,
On 01/23/2012 03:22 PM, Mauro Carvalho Chehab wrote:
Em 23-01-2012 11:51, Tomasz Stanislawski escreveu:
Signed-off-by: Tomasz Stanislawskit.stanisl...@samsung.com
Signed-off-by: Kyungmin Parkkyungmin.p...@samsung.com
Please better describe this patch. What is it supposing to fix?
Usually compilation error or bugs discovered in previous
vb2-dma-contig patches adding support for dma-buf.
---
drivers/media/video/videobuf2-core.c | 21 +
include/media/videobuf2-core.h |6 +++---
2 files changed, 12 insertions(+), 15 deletions(-)
diff --git a/drivers/media/video/videobuf2-core.c
b/drivers/media/video/videobuf2-core.c
index cb85874..59bb1bc 100644
--- a/drivers/media/video/videobuf2-core.c
+++ b/drivers/media/video/videobuf2-core.c
@@ -119,7 +119,7 @@ static void __vb2_buf_dmabuf_put(struct vb2_buffer *vb)
void *mem_priv = vb-planes[plane].mem_priv;
if (mem_priv) {
-call_memop(q, plane, detach_dmabuf, mem_priv);
+call_memop(q, detach_dmabuf, mem_priv);
Huh? You're not removing the plane parameter on this patch, but, instead,
on a previous patch.
No patch is allowed to break compilation, as it breaks git bisect.
I agree that patches should not break compilation if patches are accepted to
the mainline. There is a big compilation failure at patch 07 where
videobuf2-dma-contig.c disappears.
Note that these are proof-of-concept patches for support of dma-buf
exporting/importing dma-buf in V4L2.
It would be a waste of time polished the patches if they are going to be
rejected due to design flaws.
It is a waste of time for the reviewers to see a patch like this one,
as:
- No description of what is inside the patch is provided;
- changes that should be happening inside the other patches are
mixed here.
It is also a waste of your time to submit a patch that will need to be later
polished, as you'll need to work with the same thing twice.
So, please fix your patch workflow. As a general rule, you should
compile every patch you're applying and fix the breakages on them.
Also, if you found bugs that need to be fixed and that aren't
directly related to your current task, those should generate
their own patches, and submitted in separate, in order to be
applied sooner upstream and to stable.
Failing to do that will mean that important fixes for upstream
will be missed.
Regards,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/10] v4l: add buffer exporting via dmabuf
Em 23-01-2012 12:42, Tomasz Stanislawski escreveu:
Hi Mauro.
On 01/23/2012 03:32 PM, Mauro Carvalho Chehab wrote:
Em 23-01-2012 11:51, Tomasz Stanislawski escreveu:
This patch adds extension to V4L2 api. It allow to export a mmap buffer as
file
descriptor. New ioctl VIDIOC_EXPBUF is added. It takes a buffer offset used
by
mmap and return a file descriptor on success.
This requires more discussions.
The usecase for this new API seems to replace the features previously
provided
by the overlay mode. There, not only the buffer were exposed to userspace,
but
some control were provided, in order to control the overlay window.
This ioctl was introduced to support exporting of V4L2 buffers via dma-buf
interface. This framework was little common with overlay mode. Could you
describe what overlay mode feature is replaced by VIDIOC_EXPBUF?
The V4L2 API doesn't just export raw buffers. It provides a logic to control
the streams, with includes buffer settings, buffer queue/dequeue, buffer
meta-data
(like timestamps), etc.
I would expect to see something similar for the dma buffers.
With regards to the overlay mode, this is the old way to export DMA buffers
between
a video capture driver and a graphics adapter driver. A dma-buf interface will
superseed the video overlay mode, as it will provide more features. Yet, care
should be taken when writing the userspace interface, in order to be sure that
all
features needed will be provided there.
Please start a separate thread about that, explaining how are you imagining
that
a V4L2 application would use such ioctl.
This patch is essential for full implementation of support for DMABUF
framework in V4L2. Therefore the patch cannot be moved to separate thread.
I'm not proposing to move the patch to a separate thread. All I'm saying
is that the API extensions for dmabuf requires its own separate discussions.
I couldn't guess, just from your patches, what ioctl's a V4L2 application
like tvtime or xawtv would use the DMABUF.
Regrads,
Tomasz Stanislawski
Regards,
Mauro
Signed-off-by: Tomasz Stanislawskit.stanisl...@samsung.com
Signed-off-by: Kyungmin Parkkyungmin.p...@samsung.com
---
drivers/media/video/v4l2-compat-ioctl32.c |1 +
drivers/media/video/v4l2-ioctl.c | 11 +++
include/linux/videodev2.h |1 +
include/media/v4l2-ioctl.h|1 +
4 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/v4l2-compat-ioctl32.c
b/drivers/media/video/v4l2-compat-ioctl32.c
index c68531b..0f18b5e 100644
--- a/drivers/media/video/v4l2-compat-ioctl32.c
+++ b/drivers/media/video/v4l2-compat-ioctl32.c
@@ -954,6 +954,7 @@ long v4l2_compat_ioctl32(struct file *file, unsigned
int cmd, unsigned long arg)
case VIDIOC_S_FBUF32:
case VIDIOC_OVERLAY32:
case VIDIOC_QBUF32:
+case VIDIOC_EXPBUF:
case VIDIOC_DQBUF32:
case VIDIOC_STREAMON32:
case VIDIOC_STREAMOFF32:
diff --git a/drivers/media/video/v4l2-ioctl.c
b/drivers/media/video/v4l2-ioctl.c
index e1da8fc..cb29e00 100644
--- a/drivers/media/video/v4l2-ioctl.c
+++ b/drivers/media/video/v4l2-ioctl.c
@@ -207,6 +207,7 @@ static const char *v4l2_ioctls[] = {
[_IOC_NR(VIDIOC_S_FBUF)] = VIDIOC_S_FBUF,
[_IOC_NR(VIDIOC_OVERLAY)] = VIDIOC_OVERLAY,
[_IOC_NR(VIDIOC_QBUF)] = VIDIOC_QBUF,
+[_IOC_NR(VIDIOC_EXPBUF)] = VIDIOC_EXPBUF,
[_IOC_NR(VIDIOC_DQBUF)]= VIDIOC_DQBUF,
[_IOC_NR(VIDIOC_STREAMON)] = VIDIOC_STREAMON,
[_IOC_NR(VIDIOC_STREAMOFF)]= VIDIOC_STREAMOFF,
@@ -932,6 +933,16 @@ static long __video_do_ioctl(struct file *file,
dbgbuf(cmd, vfd, p);
break;
}
+case VIDIOC_EXPBUF:
+{
+unsigned int *p = arg;
+
+if (!ops-vidioc_expbuf)
+break;
+
+ret = ops-vidioc_expbuf(file, fh, *p);
+break;
+}
case VIDIOC_DQBUF:
{
struct v4l2_buffer *p = arg;
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 3c0ade1..448fbed 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -2183,6 +2183,7 @@ struct v4l2_create_buffers {
#define VIDIOC_S_FBUF _IOW('V', 11, struct v4l2_framebuffer)
#define VIDIOC_OVERLAY _IOW('V', 14, int)
#define VIDIOC_QBUF_IOWR('V', 15, struct v4l2_buffer)
+#define VIDIOC_EXPBUF_IOWR('V', 16, __u32)
#define VIDIOC_DQBUF_IOWR('V', 17, struct v4l2_buffer)
#define VIDIOC_STREAMON _IOW('V', 18, int)
#define VIDIOC_STREAMOFF _IOW('V', 19, int)
diff --git a/include/media/v4l2-ioctl.h b/include/media/v4l2-ioctl.h
index 4d1c74a..8201546 100644
--- a/include/media/v4l2-ioctl.h
+++ b/include/media/v4l2-ioctl.h
@@ -120,6 +120,7 @@ struct v4l2_ioctl_ops {
int (*vidioc_reqbufs) (struct file
Re: [PATCH 04/10] v4l: vb2: fixes for DMABUF support
Hi Mauro,
On 01/23/2012 03:52 PM, Mauro Carvalho Chehab wrote:
Em 23-01-2012 12:32, Tomasz Stanislawski escreveu:
Hi Mauro,
On 01/23/2012 03:22 PM, Mauro Carvalho Chehab wrote:
Em 23-01-2012 11:51, Tomasz Stanislawski escreveu:
Signed-off-by: Tomasz Stanislawskit.stanisl...@samsung.com
Signed-off-by: Kyungmin Parkkyungmin.p...@samsung.com
Please better describe this patch. What is it supposing to fix?
Usually compilation error or bugs discovered in previous
vb2-dma-contig patches adding support for dma-buf.
---
drivers/media/video/videobuf2-core.c | 21 +
include/media/videobuf2-core.h |6 +++---
2 files changed, 12 insertions(+), 15 deletions(-)
diff --git a/drivers/media/video/videobuf2-core.c
b/drivers/media/video/videobuf2-core.c
index cb85874..59bb1bc 100644
--- a/drivers/media/video/videobuf2-core.c
+++ b/drivers/media/video/videobuf2-core.c
@@ -119,7 +119,7 @@ static void __vb2_buf_dmabuf_put(struct vb2_buffer *vb)
void *mem_priv = vb-planes[plane].mem_priv;
if (mem_priv) {
-call_memop(q, plane, detach_dmabuf, mem_priv);
+call_memop(q, detach_dmabuf, mem_priv);
Huh? You're not removing the plane parameter on this patch, but, instead,
on a previous patch.
No patch is allowed to break compilation, as it breaks git bisect.
I agree that patches should not break compilation if patches are accepted to
the mainline. There is a big compilation failure at patch 07 where
videobuf2-dma-contig.c disappears.
Note that these are proof-of-concept patches for support of dma-buf
exporting/importing dma-buf in V4L2.
It would be a waste of time polished the patches if they are going to be
rejected due to design flaws.
It is a waste of time for the reviewers to see a patch like this one,
as:
- No description of what is inside the patch is provided;
Ok. I should have given more details about the patch. I am sorry for
missing it. My kernel tree failed to compile after applying patches from
[1]
http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/42966/focus=42968
I had to generate this patch to compile the code and test it. Most of
the fixes refer to Sumit's code and I think he will take care of those bugs.
I admit that I focused on other patches. Like DMA extension, exporting
in vb2-core and vb2-dma-contig. Sorry for putting so little attention to
bugfixing patch.
- changes that should be happening inside the other patches are
mixed here.
Right. I missed call_memop here.
It is also a waste of your time to submit a patch that will need to be later
polished, as you'll need to work with the same thing twice.
The problem is that those patches were not intended to be accepted. The
were intended for discussion. The other problem is that there are many
people waiting for those patches. The dma-buf was already accepted to
the mainline. Me and Sumit are trying to help V4L2 to catch-up. The
dma-buf and its support in vb2-core seams to change very dynamically.
Polishing the patch takes much time. If the dma-buf API changes the
design of vb2-core may have to be changed. Therefore time spent on
polishing would be lost. I am sorry for patch flaws. All of them would
be fixed when the design is stabilized.
So, please fix your patch workflow. As a general rule, you should
compile every patch you're applying and fix the breakages on them.
Also, if you found bugs that need to be fixed and that aren't
directly related to your current task, those should generate
their own patches, and submitted in separate, in order to be
applied sooner upstream and to stable.
I wanted to post the complete set of patches that produce compilable
kernel. Therefore most important bugs/issues had to be fixed and
attached to the patchset. Some of the issues in [1] were mentioned by
Laurent and Sakari. I hope Sumit will take care of those problems.
Failing to do that will mean that important fixes for upstream
will be missed.
Ok. It will be fixed.
Regards,
Mauro
Regards,
Tomasz Stanislawski
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/10] v4l: add buffer exporting via dmabuf
Hi Mauro, On 01/23/2012 04:04 PM, Mauro Carvalho Chehab wrote: Em 23-01-2012 12:42, Tomasz Stanislawski escreveu: Hi Mauro. On 01/23/2012 03:32 PM, Mauro Carvalho Chehab wrote: Em 23-01-2012 11:51, Tomasz Stanislawski escreveu: This patch adds extension to V4L2 api. It allow to export a mmap buffer as file descriptor. New ioctl VIDIOC_EXPBUF is added. It takes a buffer offset used by mmap and return a file descriptor on success. This requires more discussions. The usecase for this new API seems to replace the features previously provided by the overlay mode. There, not only the buffer were exposed to userspace, but some control were provided, in order to control the overlay window. This ioctl was introduced to support exporting of V4L2 buffers via dma-buf interface. This framework was little common with overlay mode. Could you describe what overlay mode feature is replaced by VIDIOC_EXPBUF? The V4L2 API doesn't just export raw buffers. It provides a logic to control the streams, with includes buffer settings, buffer queue/dequeue, buffer meta-data (like timestamps), etc. The DMABUF buffers are handled by vb2-core. It provides control for queuing and passing streaming and metadata management (like timestamps) to the driver. I would expect to see something similar for the dma buffers. Those features may be introduced to dma-buf. As I understand queue/dequeue refers to passing ownership between a CPU and a driver. It is handled in vb2-core. Passing buffer between multiple APIs like V4L2 and DRM will be probably handled in the userspace. Currently the dma-buf provides only the mechanism for mapping the same memory by multiple devices. With regards to the overlay mode, this is the old way to export DMA buffers between a video capture driver and a graphics adapter driver. A dma-buf interface will superseed the video overlay mode, as it will provide more features. Yet, care should be taken when writing the userspace interface, in order to be sure that all features needed will be provided there. The s5p-tv and s5p-fimc do not have support for OVERLAY mode. As I know vb2-core has no support for the mode, either. What kind of features present in OVERLAYS are needed in dmabuf? Note that dmabuf do not have be used only for buffers with video data. Please start a separate thread about that, explaining how are you imagining that a V4L2 application would use such ioctl. I will post a simple application that does buffer sharing between two V4L2 devices (camera and TV output). This patch is essential for full implementation of support for DMABUF framework in V4L2. Therefore the patch cannot be moved to separate thread. I'm not proposing to move the patch to a separate thread. All I'm saying is that the API extensions for dmabuf requires its own separate discussions. I agree. However DMA patches plays important role in this PoC patchset so I decided to keep patches to together. Moreover I wanted this code to compile successfully. I prefer to have a good reason for adding extension before proposing it on the mailing list. The DMA buffer sharing seams to be a right reason for adding dma_get_pages but comments for V4L2/Linaro people is needed. I couldn't guess, just from your patches, what ioctl's a V4L2 application like tvtime or xawtv would use the DMABUF. DMABUF is dedicated for application that use streaming between at least two devices. Especially if those devices are controlled by different APIs, like DRM and V4L2. It would be probably used in the middle-ware like gstreamer or OpenMAX. Regards, Tomasz Stanislawski -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 04/10] v4l: vb2: fixes for DMABUF support
Em 23-01-2012 13:25, Tomasz Stanislawski escreveu:
Hi Mauro,
On 01/23/2012 03:52 PM, Mauro Carvalho Chehab wrote:
Em 23-01-2012 12:32, Tomasz Stanislawski escreveu:
Hi Mauro,
On 01/23/2012 03:22 PM, Mauro Carvalho Chehab wrote:
Em 23-01-2012 11:51, Tomasz Stanislawski escreveu:
Signed-off-by: Tomasz Stanislawskit.stanisl...@samsung.com
Signed-off-by: Kyungmin Parkkyungmin.p...@samsung.com
Please better describe this patch. What is it supposing to fix?
Usually compilation error or bugs discovered in previous
vb2-dma-contig patches adding support for dma-buf.
---
drivers/media/video/videobuf2-core.c | 21 +
include/media/videobuf2-core.h |6 +++---
2 files changed, 12 insertions(+), 15 deletions(-)
diff --git a/drivers/media/video/videobuf2-core.c
b/drivers/media/video/videobuf2-core.c
index cb85874..59bb1bc 100644
--- a/drivers/media/video/videobuf2-core.c
+++ b/drivers/media/video/videobuf2-core.c
@@ -119,7 +119,7 @@ static void __vb2_buf_dmabuf_put(struct vb2_buffer
*vb)
void *mem_priv = vb-planes[plane].mem_priv;
if (mem_priv) {
-call_memop(q, plane, detach_dmabuf, mem_priv);
+call_memop(q, detach_dmabuf, mem_priv);
Huh? You're not removing the plane parameter on this patch, but, instead,
on a previous patch.
No patch is allowed to break compilation, as it breaks git bisect.
I agree that patches should not break compilation if patches are accepted to
the mainline. There is a big compilation failure at patch 07 where
videobuf2-dma-contig.c disappears.
Note that these are proof-of-concept patches for support of dma-buf
exporting/importing dma-buf in V4L2.
It would be a waste of time polished the patches if they are going to be
rejected due to design flaws.
It is a waste of time for the reviewers to see a patch like this one,
as:
- No description of what is inside the patch is provided;
Ok. I should have given more details about the patch. I am sorry for missing
it. My kernel tree failed to compile after applying patches from
[1]
http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/42966/focus=42968
I had to generate this patch to compile the code and test it. Most of the
fixes refer to Sumit's code and I think he will take care of those bugs.
Ok.
I admit that I focused on other patches. Like DMA extension, exporting in
vb2-core and vb2-dma-contig. Sorry for putting so little attention to
bugfixing patch.
- changes that should be happening inside the other patches are
mixed here.
Right. I missed call_memop here.
It is also a waste of your time to submit a patch that will need to be later
polished, as you'll need to work with the same thing twice.
The problem is that those patches were not intended to be accepted. The were
intended for discussion.
The patch subjects were not marked with RFC. Please prefix the subject with
something like
git send-email --subject-prefix PATCH RFC
When submitting such patches.
The other problem is that there are many people waiting for those patches.
The dma-buf was already
accepted to the mainline. Me and Sumit are trying to help V4L2 to catch-up.
The dma-buf and its support
in vb2-core seams to change very dynamically. Polishing the patch takes much
time. If the dma-buf API
changes the design of vb2-core may have to be changed. Therefore time spent
on polishing would be lost.
Ok.
I am sorry for patch flaws. All of them would be fixed when the design is
stabilized.
No problem.
So, please fix your patch workflow. As a general rule, you should
compile every patch you're applying and fix the breakages on them.
Also, if you found bugs that need to be fixed and that aren't
directly related to your current task, those should generate
their own patches, and submitted in separate, in order to be
applied sooner upstream and to stable.
I wanted to post the complete set of patches that produce compilable kernel.
herefore most important bugs/issues had to be fixed and attached to the
patchset.
Some of the issues in [1] were mentioned by Laurent and Sakari. I hope Sumit
will
take care of those problems.
Ok. My main concern was not with the driver bits, but with:
1) if fixes are needed at the vb2 core, to ensure that they'll go
upstream earlier;
2) The userspace API changes to properly support for dma buffers.
If you're not ready to discuss (2), that's ok, but I'd like to follow
the discussions for it with care, not only for reviewing the actual
patches, but also since I want to be sure that it will address the
needs for xawtv and for the Xorg v4l driver.
Failing to do that will mean that important fixes for upstream
will be missed.
Ok. It will be fixed.
Thanks!
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo
Re: DVBv5 test report
On 01/19/2012 03:31 PM, Mauro Carvalho Chehab wrote:
[PATCH] dvb-usb: Don't abort stop on -EAGAIN/-EINTR
Note: this patch is not complete. if the DVB demux device is opened on
block mode, it should instead be returning -EAGAIN.
Signed-off-by: Mauro Carvalho Chehabmche...@redhat.com
diff --git a/drivers/media/dvb/dvb-usb/dvb-usb-dvb.c
b/drivers/media/dvb/dvb-usb/dvb-usb-dvb.c
index ddf282f..215ce75 100644
--- a/drivers/media/dvb/dvb-usb/dvb-usb-dvb.c
+++ b/drivers/media/dvb/dvb-usb/dvb-usb-dvb.c
@@ -30,7 +30,9 @@ static int dvb_usb_ctrl_feed(struct dvb_demux_feed
*dvbdmxfeed, int onoff)
usb_urb_kill(adap-fe_adap[adap-active_fe].stream);
if (adap-props.fe[adap-active_fe].streaming_ctrl != NULL) {
- ret =
adap-props.fe[adap-active_fe].streaming_ctrl(adap, 0);
+ do {
+ ret =
adap-props.fe[adap-active_fe].streaming_ctrl(adap, 0);
+ } while ((ret == -EAGAIN) || (ret == -EINTR));
if (ret 0) {
err(error while stopping stream.);
return ret;
That fixes it. But it loops do {...} while around 100 times every I stop
zap. Over 100 times is rather much...
And I think -EINTR is the only code to look, -EAGAIN is maybe for I2C
and can be switched to native -EINTR also.
regards
Antti
--
http://palosaari.fi/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 720p webcam providing VDPAU-compatible video stream?
At 2012-01-23 15:41, Laurent Pinchart wrote: I think your best bet is still UVC + H.264, as that's what the market is moving to. Any other compressed format (except for MJPEG) will likely be proprietary. As you correctly mention, H.264 support isn't available yet in the UVC driver. Patches are welcome ;-) So... do I understand it correctly that with the current hw/sw stack, my original requirements can not be satisfied? In that case, let's try with reduced requirements. What if I give up HD resolution and H264? Is there a camera that can provide a HW-compressed 480p video stream, in MPEG-2 or something like that? Thank you: Kristof -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 04/10] v4l: vb2: fixes for DMABUF support
Hi Mauro, On 01/23/2012 05:06 PM, Mauro Carvalho Chehab wrote: Em 23-01-2012 13:25, Tomasz Stanislawski escreveu: Hi Mauro, On 01/23/2012 03:52 PM, Mauro Carvalho Chehab wrote: Em 23-01-2012 12:32, Tomasz Stanislawski escreveu: Hi Mauro, On 01/23/2012 03:22 PM, Mauro Carvalho Chehab wrote: Em 23-01-2012 11:51, Tomasz Stanislawski escreveu: Signed-off-by: Tomasz Stanislawskit.stanisl...@samsung.com Signed-off-by: Kyungmin Parkkyungmin.p...@samsung.com Please better describe this patch. What is it supposing to fix? [snip] It is also a waste of your time to submit a patch that will need to be later polished, as you'll need to work with the same thing twice. The problem is that those patches were not intended to be accepted. The were intended for discussion. The patch subjects were not marked with RFC. Please prefix the subject with something like git send-email --subject-prefix PATCH RFC When submitting such patches. Right!!! Sorry, I forgot about it. Probably, if I had added those 3 letter we would have avoided this whole misunderstanding about the purpose of the patches :) The other problem is that there are many people waiting for those patches. The dma-buf was already accepted to the mainline. Me and Sumit are trying to help V4L2 to catch-up. The dma-buf and its support in vb2-core seams to change very dynamically. Polishing the patch takes much time. If the dma-buf API changes the design of vb2-core may have to be changed. Therefore time spent on polishing would be lost. Ok. I am sorry for patch flaws. All of them would be fixed when the design is stabilized. No problem. So, please fix your patch workflow. As a general rule, you should compile every patch you're applying and fix the breakages on them. Also, if you found bugs that need to be fixed and that aren't directly related to your current task, those should generate their own patches, and submitted in separate, in order to be applied sooner upstream and to stable. I wanted to post the complete set of patches that produce compilable kernel. herefore most important bugs/issues had to be fixed and attached to the patchset. Some of the issues in [1] were mentioned by Laurent and Sakari. I hope Sumit will take care of those problems. Ok. My main concern was not with the driver bits, but with: 1) if fixes are needed at the vb2 core, to ensure that they'll go upstream earlier; First, we should select patches not related to DMABUF. The fixes related to DMABUF could be postponed because they will be applied in new version for Sumit's patches. Next videobuf2-dma-contig.c file is patched. Fixes to handling of mmap and userptr would go first with all DMABUF related features removed. Lack of DMABUF related callbacks will not break backward compatibility. Next, DMABUF support is added to vb2-core. Finally, that DMABUF exporting/importing patches would be applied. 2) The userspace API changes to properly support for dma buffers. If you're not ready to discuss (2), that's ok, but I'd like to follow the discussions for it with care, not only for reviewing the actual patches, but also since I want to be sure that it will address the needs for xawtv and for the Xorg v4l driver. The support of dmabuf could be easily added to framebuffer API. I expect that it would not be difficult to add it to Xv. The selection API could be used to control scaling and composing of video stream into framebuffer or a texture for composing manager. Regards, Tomasz Stanislawski Failing to do that will mean that important fixes for upstream will be missed. Ok. It will be fixed. Thanks! Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/10] v4l: add buffer exporting via dmabuf
Em 23-01-2012 13:56, Tomasz Stanislawski escreveu:
Hi Mauro,
On 01/23/2012 04:04 PM, Mauro Carvalho Chehab wrote:
Em 23-01-2012 12:42, Tomasz Stanislawski escreveu:
Hi Mauro.
On 01/23/2012 03:32 PM, Mauro Carvalho Chehab wrote:
Em 23-01-2012 11:51, Tomasz Stanislawski escreveu:
This patch adds extension to V4L2 api. It allow to export a mmap buffer
as file
descriptor. New ioctl VIDIOC_EXPBUF is added. It takes a buffer offset
used by
mmap and return a file descriptor on success.
This requires more discussions.
The usecase for this new API seems to replace the features previously
provided
by the overlay mode. There, not only the buffer were exposed to userspace,
but
some control were provided, in order to control the overlay window.
This ioctl was introduced to support exporting of V4L2 buffers via dma-buf
interface. This framework was little common with overlay mode. Could you
describe what overlay mode feature is replaced by VIDIOC_EXPBUF?
The V4L2 API doesn't just export raw buffers. It provides a logic to
control
the streams, with includes buffer settings, buffer queue/dequeue, buffer
meta-data
(like timestamps), etc.
The DMABUF buffers are handled by vb2-core. It provides control for queuing
and passing streaming and metadata management (like timestamps) to the driver.
I would expect to see something similar for the dma buffers.
Those features may be introduced to dma-buf. As I understand queue/dequeue
refers to passing
ownership between a CPU and a driver. It is handled in vb2-core. Passing
buffer between multiple
APIs like V4L2 and DRM will be probably handled in the userspace. Currently
the dma-buf provides
only the mechanism for mapping the same memory by multiple devices.
I'm not sure if the dma-buf itself should have such meta data, but the V4L2 API
likely needs it.
With regards to the overlay mode, this is the old way to export DMA buffers
between
a video capture driver and a graphics adapter driver. A dma-buf interface
will
superseed the video overlay mode, as it will provide more features. Yet, care
should be taken when writing the userspace interface, in order to be sure
that all
features needed will be provided there.
The s5p-tv and s5p-fimc do not have support for OVERLAY mode. As I know
vb2-core
has no support for the mode, either.
True. It was decided that overlay is an old design, and a dma-buffer
oriented approach would be needed. So, the decision were to not implement
anything there, until a proper dma-buf support were not added.
What kind of features present in OVERLAYS are
needed in dmabuf? Note that dmabuf do not have be used only for buffers with
video data.
That's a good point. Basically, Ovelay mode is supported by
those 3 ioctl's:
#define VIDIOC_G_FBUF_IOR('V', 10, struct v4l2_framebuffer)
#define VIDIOC_S_FBUF_IOW('V', 11, struct v4l2_framebuffer)
#define VIDIOC_OVERLAY _IOW('V', 14, int)
With use these structs:
struct v4l2_pix_format {
__u32 width;
__u32 height;
__u32 pixelformat;
enum v4l2_field field;
__u32 bytesperline;
__u32 sizeimage;
enum v4l2_colorspacecolorspace;
__u32 priv;
};
struct v4l2_framebuffer {
__u32 capability;
__u32 flags;
void*base; /* Should be replaced by the
DMA buf specifics */
struct v4l2_pix_format fmt;
};
/* Flags for the 'capability' field. Read only */
#define V4L2_FBUF_CAP_EXTERNOVERLAY 0x0001
#define V4L2_FBUF_CAP_CHROMAKEY 0x0002
#define V4L2_FBUF_CAP_LIST_CLIPPING 0x0004
#define V4L2_FBUF_CAP_BITMAP_CLIPPING 0x0008
#define V4L2_FBUF_CAP_LOCAL_ALPHA 0x0010
#define V4L2_FBUF_CAP_GLOBAL_ALPHA 0x0020
#define V4L2_FBUF_CAP_LOCAL_INV_ALPHA 0x0040
#define V4L2_FBUF_CAP_SRC_CHROMAKEY 0x0080
/* Flags for the 'flags' field. */
#define V4L2_FBUF_FLAG_PRIMARY 0x0001
#define V4L2_FBUF_FLAG_OVERLAY 0x0002
#define V4L2_FBUF_FLAG_CHROMAKEY0x0004
#define V4L2_FBUF_FLAG_LOCAL_ALPHA 0x0008
#define V4L2_FBUF_FLAG_GLOBAL_ALPHA 0x0010
#define V4L2_FBUF_FLAG_LOCAL_INV_ALPHA 0x0020
#define V4L2_FBUF_FLAG_SRC_CHROMAKEY0x0040
It should be noticed that devices that support OVERLAY can provide
data on both dma-buffer sharing and via the standard MMAP/read() mode at
the same time, each with a different video format. So, the VIDIOC_S_FBUF
ioctl needs to set the pixel format, and image size for the overlay,
while the other ioctl's set it for the MMAP (or read) mode.
Buffer queue/dequeue happens internally, and can be started/stopped via
a VIDIOC_OVERLAY call.
Please start a separate thread about that, explaining how are you
imagining that
a V4L2 application would use such ioctl.
Re: [PATCH 04/10] v4l: vb2: fixes for DMABUF support
Em 23-01-2012 14:37, Tomasz Stanislawski escreveu: Hi Mauro, On 01/23/2012 05:06 PM, Mauro Carvalho Chehab wrote: Em 23-01-2012 13:25, Tomasz Stanislawski escreveu: Hi Mauro, On 01/23/2012 03:52 PM, Mauro Carvalho Chehab wrote: Em 23-01-2012 12:32, Tomasz Stanislawski escreveu: Hi Mauro, On 01/23/2012 03:22 PM, Mauro Carvalho Chehab wrote: Em 23-01-2012 11:51, Tomasz Stanislawski escreveu: Signed-off-by: Tomasz Stanislawskit.stanisl...@samsung.com Signed-off-by: Kyungmin Parkkyungmin.p...@samsung.com Please better describe this patch. What is it supposing to fix? [snip] It is also a waste of your time to submit a patch that will need to be later polished, as you'll need to work with the same thing twice. The problem is that those patches were not intended to be accepted. The were intended for discussion. The patch subjects were not marked with RFC. Please prefix the subject with something like git send-email --subject-prefix PATCH RFC When submitting such patches. Right!!! Sorry, I forgot about it. Probably, if I had added those 3 letter we would have avoided this whole misunderstanding about the purpose of the patches :) The other problem is that there are many people waiting for those patches. The dma-buf was already accepted to the mainline. Me and Sumit are trying to help V4L2 to catch-up. The dma-buf and its support in vb2-core seams to change very dynamically. Polishing the patch takes much time. If the dma-buf API changes the design of vb2-core may have to be changed. Therefore time spent on polishing would be lost. Ok. I am sorry for patch flaws. All of them would be fixed when the design is stabilized. No problem. So, please fix your patch workflow. As a general rule, you should compile every patch you're applying and fix the breakages on them. Also, if you found bugs that need to be fixed and that aren't directly related to your current task, those should generate their own patches, and submitted in separate, in order to be applied sooner upstream and to stable. I wanted to post the complete set of patches that produce compilable kernel. herefore most important bugs/issues had to be fixed and attached to the patchset. Some of the issues in [1] were mentioned by Laurent and Sakari. I hope Sumit will take care of those problems. Ok. My main concern was not with the driver bits, but with: 1) if fixes are needed at the vb2 core, to ensure that they'll go upstream earlier; First, we should select patches not related to DMABUF. The fixes related to DMABUF could be postponed because they will be applied in new version for Sumit's patches. Next videobuf2-dma-contig.c file is patched. Fixes to handling of mmap and userptr would go first with all DMABUF related features removed. Lack of DMABUF related callbacks will not break backward compatibility. Next, DMABUF support is added to vb2-core. Finally, that DMABUF exporting/importing patches would be applied. Sounds like a plan. Regards, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
V4L2 Overlay mode replacement by dma-buf - was: Re: [PATCH 05/10] v4l: add buffer exporting via dmabuf
Em 23-01-2012 14:42, Mauro Carvalho Chehab escreveu:
Em 23-01-2012 13:56, Tomasz Stanislawski escreveu:
Hi Mauro,
On 01/23/2012 04:04 PM, Mauro Carvalho Chehab wrote:
Em 23-01-2012 12:42, Tomasz Stanislawski escreveu:
Hi Mauro.
On 01/23/2012 03:32 PM, Mauro Carvalho Chehab wrote:
Em 23-01-2012 11:51, Tomasz Stanislawski escreveu:
This patch adds extension to V4L2 api. It allow to export a mmap buffer
as file
descriptor. New ioctl VIDIOC_EXPBUF is added. It takes a buffer offset
used by
mmap and return a file descriptor on success.
This requires more discussions.
The usecase for this new API seems to replace the features previously
provided
by the overlay mode. There, not only the buffer were exposed to
userspace, but
some control were provided, in order to control the overlay window.
This ioctl was introduced to support exporting of V4L2 buffers via dma-buf
interface. This framework was little common with overlay mode. Could you
describe what overlay mode feature is replaced by VIDIOC_EXPBUF?
The V4L2 API doesn't just export raw buffers. It provides a logic to
control
the streams, with includes buffer settings, buffer queue/dequeue, buffer
meta-data
(like timestamps), etc.
The DMABUF buffers are handled by vb2-core. It provides control for queuing
and passing streaming and metadata management (like timestamps) to the
driver.
I would expect to see something similar for the dma buffers.
Those features may be introduced to dma-buf. As I understand queue/dequeue
refers to passing
ownership between a CPU and a driver. It is handled in vb2-core. Passing
buffer between multiple
APIs like V4L2 and DRM will be probably handled in the userspace. Currently
the dma-buf provides
only the mechanism for mapping the same memory by multiple devices.
I'm not sure if the dma-buf itself should have such meta data, but the V4L2
API
likely needs it.
With regards to the overlay mode, this is the old way to export DMA buffers
between
a video capture driver and a graphics adapter driver. A dma-buf interface
will
superseed the video overlay mode, as it will provide more features. Yet,
care
should be taken when writing the userspace interface, in order to be sure
that all
features needed will be provided there.
The s5p-tv and s5p-fimc do not have support for OVERLAY mode. As I know
vb2-core
has no support for the mode, either.
True. It was decided that overlay is an old design, and a dma-buffer
oriented approach would be needed. So, the decision were to not implement
anything there, until a proper dma-buf support were not added.
What kind of features present in OVERLAYS are
needed in dmabuf? Note that dmabuf do not have be used only for buffers with
video data.
That's a good point. Basically, Ovelay mode is supported by
those 3 ioctl's:
#define VIDIOC_G_FBUF_IOR('V', 10, struct v4l2_framebuffer)
#define VIDIOC_S_FBUF_IOW('V', 11, struct v4l2_framebuffer)
#define VIDIOC_OVERLAY _IOW('V', 14, int)
With use these structs:
struct v4l2_pix_format {
__u32 width;
__u32 height;
__u32 pixelformat;
enum v4l2_field field;
__u32 bytesperline;
__u32 sizeimage;
enum v4l2_colorspacecolorspace;
__u32 priv;
};
struct v4l2_framebuffer {
__u32 capability;
__u32 flags;
void*base;/* Should be replaced
by the DMA buf specifics */
struct v4l2_pix_format fmt;
};
/* Flags for the 'capability' field. Read only */
#define V4L2_FBUF_CAP_EXTERNOVERLAY 0x0001
#define V4L2_FBUF_CAP_CHROMAKEY 0x0002
#define V4L2_FBUF_CAP_LIST_CLIPPING 0x0004
#define V4L2_FBUF_CAP_BITMAP_CLIPPING 0x0008
#define V4L2_FBUF_CAP_LOCAL_ALPHA 0x0010
#define V4L2_FBUF_CAP_GLOBAL_ALPHA 0x0020
#define V4L2_FBUF_CAP_LOCAL_INV_ALPHA 0x0040
#define V4L2_FBUF_CAP_SRC_CHROMAKEY 0x0080
/* Flags for the 'flags' field. */
#define V4L2_FBUF_FLAG_PRIMARY 0x0001
#define V4L2_FBUF_FLAG_OVERLAY 0x0002
#define V4L2_FBUF_FLAG_CHROMAKEY0x0004
#define V4L2_FBUF_FLAG_LOCAL_ALPHA0x0008
#define V4L2_FBUF_FLAG_GLOBAL_ALPHA 0x0010
#define V4L2_FBUF_FLAG_LOCAL_INV_ALPHA 0x0020
#define V4L2_FBUF_FLAG_SRC_CHROMAKEY0x0040
It should be noticed that devices that support OVERLAY can provide
data on both dma-buffer sharing and via the standard MMAP/read() mode at
the same time, each with a different video format. So, the VIDIOC_S_FBUF
ioctl needs to set the pixel format, and image size for the overlay,
while the other ioctl's set it for the MMAP (or read) mode.
Buffer queue/dequeue happens internally, and can be started/stopped via
a VIDIOC_OVERLAY call.
Re: DVBv5 test report
Em 23-01-2012 14:23, Antti Palosaari escreveu:
On 01/19/2012 03:31 PM, Mauro Carvalho Chehab wrote:
[PATCH] dvb-usb: Don't abort stop on -EAGAIN/-EINTR
Note: this patch is not complete. if the DVB demux device is opened on
block mode, it should instead be returning -EAGAIN.
Signed-off-by: Mauro Carvalho Chehabmche...@redhat.com
diff --git a/drivers/media/dvb/dvb-usb/dvb-usb-dvb.c
b/drivers/media/dvb/dvb-usb/dvb-usb-dvb.c
index ddf282f..215ce75 100644
--- a/drivers/media/dvb/dvb-usb/dvb-usb-dvb.c
+++ b/drivers/media/dvb/dvb-usb/dvb-usb-dvb.c
@@ -30,7 +30,9 @@ static int dvb_usb_ctrl_feed(struct dvb_demux_feed
*dvbdmxfeed, int onoff)
usb_urb_kill(adap-fe_adap[adap-active_fe].stream);
if (adap-props.fe[adap-active_fe].streaming_ctrl != NULL) {
-ret = adap-props.fe[adap-active_fe].streaming_ctrl(adap, 0);
+do {
+ret = adap-props.fe[adap-active_fe].streaming_ctrl(adap,
0);
+} while ((ret == -EAGAIN) || (ret == -EINTR));
if (ret 0) {
err(error while stopping stream.);
return ret;
That fixes it. But it loops do {...} while around 100 times every I stop zap.
Over 100 times is rather much...
Yes, this sounds too much.
The issue here is caused by the usage of mutex_lock_interruptible() inside the
streaming_ctrl() callbacks, when the stream should stop.
The new wait_queue wakeup inside the code made the issue more visible, but it
could still happen without it, as a break could be hit during stream_ctl()
stop call anyway.
There are two possible fixes for it:
1) The above solution.
Eventually, a schedule() could be added there:
do {
ret = adap-props.fe[adap-active_fe].streaming_ctrl(adap, 0);
if (ret == -EINTR)
shedule();
} while (ret == -EINTR);
2)
Don't use mutex_lock_interruptible inside the driver's streaming_ctrl,
if the second parameter is 0 (stop).
IMHO, (1) is cleaner, due to a few reasons:
- inside the drivers, the code will be symmetrical: it will call the
same function for
both onoff = 1 and onoff = 0.
- The patch is on just one place;
- with (2), extra care is needed when merging patches, as regressions
and
broken drivers could pass unnoticed.
And I think -EINTR is the only code to look, -EAGAIN is maybe for I2C and can
be switched to native -EINTR also.
Drivers need to be checked, if only -EINTR is added there, as drivers may
be doing things like:
if (mutex_lock_interruptible(...))
return -EAGAIN;
Regards,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] v4l2: handle multiplication overflow
Em 22-12-2011 07:42, Németh Márton escreveu:
From: Márton Németh nm...@freemail.hu
When a V4L2 ioctl is executed the memory provided by the caller in user space
is copied to the kernel space in video_usercopy() function. To find out
how many bytes has to be copied the check_array_args() helper function is
used.
This patch adds a check for multiplication overflow. Without this check the
multiplication may overflow resulting array_size to be zero. This means that
later on uninitialized value can trigger NULL pointer exception.
The overflow happens because ctrls-count is an __u32 multiplied by a constant
coming from sizeof() operator. Multiplication result of two 32bit value may
be a 64bit value, thus overflow can happen. Similarly buf-length is an __u32
multiplied by a constant coming from sizeof() operator.
The chosen error value is -ENOMEM because we are just about to allocate
kernel memory to copy data from userspace. We cannot even store the required
number of bytes in the variable of size_t type.
To trigger the error from user space use the v4l-test 0.19 [1] or essentially
the following code fragment:
struct v4l2_ext_controls controls;
memset(controls, 0, sizeof(controls));
controls.ctrl_class = V4L2_CTRL_CLASS_USER;
controls.count = 0x4000;
controls.controls = NULL;
ret = ioctl(f, VIDIOC_G_EXT_CTRLS, controls);
References:
[1] v4l-test: Test environment for Video For Linux Two (V4L2) API
http://v4l-test.sourceforge.net/
Signed-off-by: Márton Németh nm...@freemail.hu
---
I'm a little bit in doubt whether this is the correct way to check for the
multiplication overflow. In case of x86 architecture the MUL insruction [2]
can be used to multiply EAX with an other 32bit register, and the 64bit result
is placed to EDX:EAX. In case of EDX != 0 the carry and overflow flags are
set.
This means that executing the MUL instruction on x86 already provides
information
whether the result fits to 32bit or not. I might use __u64 as a result of the
multiplication and check whether the upper 32bit is still zero but the optimal
would be to check for the carry or the overflow flag.
Still, there could be a special case when the constant from sizeof() operator
is
a power of 2, in this case the compiler might optimize the multiplication
using
a shift left. In this case something else is needed.
I couldn't really find information about the number of bits for size_t on
different architectures. If size_t happens to be at least 64bit on some
architecture
then this overflow will not happen at all and the array_size will contain the
correct value.
What do you think?
Hi Németh,
IMO, the check should, instead, use a max hard limit for the array size.
There's no sense on allowing very large arrays there.
I think that this patch become obsoleted by this one, already merged:
commit 6c06108be53ca5e94d8b0e93883d534dd9079646
Author: Dan Carpenter dan.carpen...@oracle.com
Date: Thu Jan 5 02:27:57 2012 -0300
[media] V4L/DVB: v4l2-ioctl: integer overflow in video_usercopy()
If ctrls-count is too high the multiplication could overflow and
array_size would be lower than expected. Mauro and Hans Verkuil
suggested that we cap it at 1024. That comes from the maximum
number of controls with lots of room for expantion.
$ grep V4L2_CID include/linux/videodev2.h | wc -l
211
Cc: stable sta...@vger.kernel.org
Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
diff --git a/drivers/media/video/v4l2-ioctl.c b/drivers/media/video/v4l2-ioctl.c
index e1da8fc..639abee 100644
--- a/drivers/media/video/v4l2-ioctl.c
+++ b/drivers/media/video/v4l2-ioctl.c
@@ -2226,6 +2226,10 @@ static int check_array_args(unsigned int cmd, void
*parg, size_t *array_size,
struct v4l2_ext_controls *ctrls = parg;
if (ctrls-count != 0) {
+ if (ctrls-count V4L2_CID_MAX_CTRLS) {
+ ret = -EINVAL;
+ break;
+ }
*user_ptr = (void __user *)ctrls-controls;
*kernel_ptr = (void *)ctrls-controls;
*array_size = sizeof(struct v4l2_ext_control)
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 6bfaa76..b2e1331 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -1132,6 +1132,7 @@ struct v4l2_querymenu {
#define V4L2_CTRL_FLAG_NEXT_CTRL 0x8000
/* User-class control IDs defined by V4L2 */
+#define V4L2_CID_MAX_CTRLS 1024
#define V4L2_CID_BASE (V4L2_CTRL_CLASS_USER | 0x900)
#define V4L2_CID_USER_BASE V4L2_CID_BASE
/* IDs reserved for driver specific controls */
Regards,
Mauro
--
To unsubscribe from this list: send the line unsubscribe
DVB - attach to an open frontend device
Not too sure if this is possible but what I want to do is this open frontend set frequency add demux filters etc record then while this is running I want to attach to the same process and add further demux filters (without retuning - same frequency) any tips? -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] v4l-utils: ir-keytable file parsing errors
Em 08-01-2012 21:31, Chris Pockele escreveu: Hello, While configuring a remote control I noticed that the ir-keytable utility would throw the message Invalid parameter on line 1 if the first line following the table ... type: ... line is a comment. Also, if a configuration line is invalid, the line number indication of the error message is sometimes incorrect, because the comments before it are not counted. This happens because of the continue statement when processing comments (or the table/type line), thus skipping the line counter increase at the end of the loop. The included patch fixes both problems by making sure the counter is always increased. The parse_cfgfile() function had a similar problem. Applied, thanks. For the table ... type: ... configuration line at the beginning of a keyfile, I suggest replacing the marker character by something different from '#'. That way, it can be commented out by the user, and it doesn't have to be on the first line. However, that's something for another patch and probably up to someone else to decide :-). If desirable, I can generate such a patch. Such patch is welcome, provided that it will keep working with the old format, in order to not mangle configs with the old format. Regards, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
cron job: media_tree daily build: WARNINGS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date:Mon Jan 23 19:00:18 CET 2012 git hash:aa104b2fea3ced2a562c480448a2f346c3ab61f4 gcc version: i686-linux-gcc (GCC) 4.6.2 host hardware:x86_64 host os: 3.1-2.slh.1-amd64 linux-git-arm-eabi-enoxys: WARNINGS linux-git-arm-eabi-omap: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: WARNINGS linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-i686: WARNINGS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-3.0-i686: WARNINGS linux-3.1-i686: WARNINGS linux-3.2.1-i686: WARNINGS linux-3.3-rc1-i686: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS linux-3.0-x86_64: WARNINGS linux-3.1-x86_64: WARNINGS linux-3.2.1-x86_64: WARNINGS linux-3.3-rc1-x86_64: WARNINGS apps: WARNINGS spec-git: WARNINGS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] stb0899: fix the limits for signal strength values
Hi Klaus,
The patch didn't apply. It seems to be due to your emailer that mangled the
whitespaces.
The patch looks correct on my eyes. Yet, I'd like to have Manu's ack on it.
Em 19-01-2012 15:39, Klaus Schmidinger escreveu:
stb0899_read_signal_strength() adds an offset to the result of the table
lookup.
That offset must correspond to the lowest value in the lookup table, to make
sure
the result doesn't get below 0, which would mean a very high value since the
parameter is unsigned.
'strength' and 'snr' need to be initialized to 0 to make sure they have a
defined result in case there is no internal-lock.
Signed-off-by: Klaus Schmidinger klaus.schmidin...@tvdr.de
--- a/linux/drivers/media/dvb/frontends/stb0899_drv.c 2011-06-11
16:54:32.0 +0200
+++ b/linux/drivers/media/dvb/frontends/stb0899_drv.c 2011-06-11
16:23:00.0 +0200
@@ -67,7 +67,7 @@
* Crude linear extrapolation below -84.8dBm and above -8.0dBm.
*/
static const struct stb0899_tab stb0899_dvbsrf_tab[] = {
- { -950, -128 },
+ { -750, -128 },
{ -748, -94 },
{ -745, -92 },
{ -735, -90 },
@@ -131,7 +131,7 @@
{ -730, 13645 },
{ -750, 13909 },
{ -766, 14153 },
- { -999, 16383 }
+ { -950, 16383 }
};
/* DVB-S2 Es/N0 quant in dB/100 vs read value * 100*/
@@ -964,6 +964,7 @@
int val;
u32 reg;
+ *strength = 0;
This is not needed, as strength is not initialized only on invalid delivery
systems,
where -EINVAL is returned.
switch (state-delsys) {
case SYS_DVBS:
case SYS_DSS:
@@ -987,7 +988,7 @@
val = STB0899_GETFIELD(IF_AGC_GAIN, reg);
*strength = stb0899_table_lookup(stb0899_dvbs2rf_tab,
ARRAY_SIZE(stb0899_dvbs2rf_tab) - 1, val);
- *strength += 750;
+ *strength += 950;
dprintk(state-verbose, FE_DEBUG, 1, IF_AGC_GAIN =
0x%04x, C = %d * 0.1 dBm,
val 0x3fff, *strength);
}
@@ -1009,6 +1010,7 @@
u8 buf[2];
u32 reg;
+ *snr = 0;
This is not needed, as strength is not initialized only on invalid delivery
systems,
where -EINVAL is returned.
reg = stb0899_read_reg(state, STB0899_VSTATUS);
switch (state-delsys) {
case SYS_DVBS:
PS.: Another alternative for it would be the enclosed patch,
wich will be a little simpler, and will also preserve the slope
on the boundary values, used at the stb0899_table_lookup()
interpolation logic.
Regards,
Mauro
-
[PATCH] stb0899: fix the limits for signal strength values
The current minimal measures for strengh is 750 - 950, for table
stb0899_dvbsrf_tab[], and 750 - 999, for stb0899_dvbs2rf_tab[].
Both are negative values. However, the strength measure is unsigned.
Don't allow negative values for strengh to underflow. Instead,
shift the scale, in order to have 0 as the lowest strength.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
diff --git a/drivers/media/dvb/frontends/stb0899_drv.c
b/drivers/media/dvb/frontends/stb0899_drv.c
index 38565be..9cfdcb2 100644
--- a/drivers/media/dvb/frontends/stb0899_drv.c
+++ b/drivers/media/dvb/frontends/stb0899_drv.c
@@ -975,7 +975,7 @@ static int stb0899_read_signal_strength(struct dvb_frontend
*fe, u16 *strength)
val = (s32)(s8)STB0899_GETFIELD(AGCIQVALUE,
reg);
*strength =
stb0899_table_lookup(stb0899_dvbsrf_tab, ARRAY_SIZE(stb0899_dvbsrf_tab) - 1,
val);
- *strength += 750;
+ *strength += 950;
dprintk(state-verbose, FE_DEBUG, 1,
AGCIQVALUE = 0x%02x, C = %d * 0.1 dBm,
val 0xff, *strength);
}
@@ -987,7 +987,7 @@ static int stb0899_read_signal_strength(struct dvb_frontend
*fe, u16 *strength)
val = STB0899_GETFIELD(IF_AGC_GAIN, reg);
*strength = stb0899_table_lookup(stb0899_dvbs2rf_tab,
ARRAY_SIZE(stb0899_dvbs2rf_tab) - 1, val);
- *strength += 750;
+ *strength += 999;
dprintk(state-verbose, FE_DEBUG, 1, IF_AGC_GAIN =
0x%04x, C = %d * 0.1 dBm,
val 0x3fff, *strength);
}
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [git:v4l-dvb/for_v3.4] [media] cxd2820r: fix dvb_frontend_ops
Are going to push these Kernel 3.4 as topic hints?
These are fixes for 3.3, for example that patch in question...
Antti
On 01/23/2012 10:10 PM, Mauro Carvalho Chehab wrote:
This is an automatic generated email to let you know that the following patch
were queued at the
http://git.linuxtv.org/media_tree.git tree:
Subject: [media] cxd2820r: fix dvb_frontend_ops
Author: Antti Palosaaricr...@iki.fi
Date:Wed Jan 18 13:57:33 2012 -0300
Fix bug introduced by multi-frontend to single-frontend change.
* Add missing DVB-C caps
* Change frontend name as single frontend does all the standards
Signed-off-by: Antti Palosaaricr...@iki.fi
Signed-off-by: Mauro Carvalho Chehabmche...@redhat.com
drivers/media/dvb/frontends/cxd2820r_core.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
---
http://git.linuxtv.org/media_tree.git?a=commitdiff;h=9bf31efa84c898a0cf294bacdfe8edcac24e6318
diff --git a/drivers/media/dvb/frontends/cxd2820r_core.c
b/drivers/media/dvb/frontends/cxd2820r_core.c
index caae7f7..5fe591d 100644
--- a/drivers/media/dvb/frontends/cxd2820r_core.c
+++ b/drivers/media/dvb/frontends/cxd2820r_core.c
@@ -562,7 +562,7 @@ static const struct dvb_frontend_ops cxd2820r_ops = {
.delsys = { SYS_DVBT, SYS_DVBT2, SYS_DVBC_ANNEX_A },
/* default: DVB-T/T2 */
.info = {
- .name = Sony CXD2820R (DVB-T/T2),
+ .name = Sony CXD2820R,
.caps = FE_CAN_FEC_1_2 |
FE_CAN_FEC_2_3 |
@@ -572,7 +572,9 @@ static const struct dvb_frontend_ops cxd2820r_ops = {
FE_CAN_FEC_AUTO |
FE_CAN_QPSK |
FE_CAN_QAM_16 |
+ FE_CAN_QAM_32 |
FE_CAN_QAM_64 |
+ FE_CAN_QAM_128 |
FE_CAN_QAM_256 |
FE_CAN_QAM_AUTO |
FE_CAN_TRANSMISSION_MODE_AUTO |
--
http://palosaari.fi/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [git:v4l-dvb/for_v3.4] [media] cxd2820r: fix dvb_frontend_ops
Em 23-01-2012 18:17, Antti Palosaari escreveu:
Are going to push these Kernel 3.4 as topic hints?
These are fixes for 3.3, for example that patch in question...
Those patches are on my queue for 3.3. I'll now be adding the fixes
also to the current branch, in order to allow them to be tested by
a broader audience, before sending upstream.
commit c79eba92406acc4898adcd1689fc21a6aa91ed0b
Author: Mauro Carvalho Chehab mche...@redhat.com
Date: Mon Jan 23 13:15:22 2012 -0200
[media] cinergyT2-fe: Fix bandwdith settings
Changeset 7830bbaff9f mangled the bandwidth field for CinergyT2.
Properly fill it.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
commit 03652e0ad4b140523ec5ef7fec8d2b3c7218447b
Author: Josh Wu josh...@atmel.com
Date: Wed Jan 11 00:58:29 2012 -0300
[media] V4L: atmel-isi: add clk_prepare()/clk_unprepare() functions
Signed-off-by: Josh Wu josh...@atmel.com
Acked-by: Nicolas Ferre nicolas.fe...@atmel.com
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
commit 72565224609a23a60d10fcdf42f87a2fa8f7b16d
Author: Antti Palosaari cr...@iki.fi
Date: Fri Jan 20 19:48:28 2012 -0300
[media] cxd2820r: sleep on DVB-T/T2 delivery system switch
Fix bug introduced by multi-frontend to single-frontend change.
It is safer to put DVB-T parts sleeping when auto-switching to DVB-T2
and vice versa. That was original behaviour.
Signed-off-by: Antti Palosaari cr...@iki.fi
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
commit 46de20a78ae4b122b79fc02633e9a6c3d539ecad
Author: Antti Palosaari cr...@iki.fi
Date: Fri Jan 20 17:39:17 2012 -0300
[media] anysee: fix CI init
No more error that error seen when device is plugged:
dvb_ca adapter 0: Invalid PC card inserted :(
Signed-off-by: Antti Palosaari cr...@iki.fi
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
commit c2bbbe7b5e79974c5ed1c828690731f6f5106bee
Author: Antti Palosaari cr...@iki.fi
Date: Thu Jan 19 14:46:43 2012 -0300
[media] cxd2820r: remove unused parameter from cxd2820r_attach
Fix bug introduced by multi-frontend to single-frontend change.
This parameter is no longer used after multi-frontend to single-frontend
change.
Signed-off-by: Antti Palosaari cr...@iki.fi
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
commit 9bf31efa84c898a0cf294bacdfe8edcac24e6318
Author: Antti Palosaari cr...@iki.fi
Date: Wed Jan 18 13:57:33 2012 -0300
[media] cxd2820r: fix dvb_frontend_ops
Fix bug introduced by multi-frontend to single-frontend change.
* Add missing DVB-C caps
* Change frontend name as single frontend does all the standards
Signed-off-by: Antti Palosaari cr...@iki.fi
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
Regards,
Mauro.
Antti
On 01/23/2012 10:10 PM, Mauro Carvalho Chehab wrote:
This is an automatic generated email to let you know that the following
patch were queued at the
http://git.linuxtv.org/media_tree.git tree:
Subject: [media] cxd2820r: fix dvb_frontend_ops
Author: Antti Palosaaricr...@iki.fi
Date:Wed Jan 18 13:57:33 2012 -0300
Fix bug introduced by multi-frontend to single-frontend change.
* Add missing DVB-C caps
* Change frontend name as single frontend does all the standards
Signed-off-by: Antti Palosaaricr...@iki.fi
Signed-off-by: Mauro Carvalho Chehabmche...@redhat.com
drivers/media/dvb/frontends/cxd2820r_core.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
---
http://git.linuxtv.org/media_tree.git?a=commitdiff;h=9bf31efa84c898a0cf294bacdfe8edcac24e6318
diff --git a/drivers/media/dvb/frontends/cxd2820r_core.c
b/drivers/media/dvb/frontends/cxd2820r_core.c
index caae7f7..5fe591d 100644
--- a/drivers/media/dvb/frontends/cxd2820r_core.c
+++ b/drivers/media/dvb/frontends/cxd2820r_core.c
@@ -562,7 +562,7 @@ static const struct dvb_frontend_ops cxd2820r_ops = {
.delsys = { SYS_DVBT, SYS_DVBT2, SYS_DVBC_ANNEX_A },
/* default: DVB-T/T2 */
.info = {
-.name = Sony CXD2820R (DVB-T/T2),
+.name = Sony CXD2820R,
.caps =FE_CAN_FEC_1_2|
FE_CAN_FEC_2_3|
@@ -572,7 +572,9 @@ static const struct dvb_frontend_ops cxd2820r_ops = {
FE_CAN_FEC_AUTO|
FE_CAN_QPSK|
FE_CAN_QAM_16|
+FE_CAN_QAM_32|
FE_CAN_QAM_64|
+FE_CAN_QAM_128|
FE_CAN_QAM_256|
FE_CAN_QAM_AUTO|
FE_CAN_TRANSMISSION_MODE_AUTO|
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at
[PATCH] drivers/media/dvb/frontends/drxk_hard.c does not need to include linux/version.h
This patch removes the unneeded include. Signed-off-by: Jesper Juhl j...@chaosbits.net --- drivers/media/dvb/frontends/drxk_hard.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) compile tested only diff --git a/drivers/media/dvb/frontends/drxk_hard.c b/drivers/media/dvb/frontends/drxk_hard.c index 6980ed7..5ab5379 100644 --- a/drivers/media/dvb/frontends/drxk_hard.c +++ b/drivers/media/dvb/frontends/drxk_hard.c @@ -28,7 +28,6 @@ #include linux/delay.h #include linux/firmware.h #include linux/i2c.h -#include linux/version.h #include asm/div64.h #include dvb_frontend.h -- 1.7.8.4 -- Jesper Juhl j...@chaosbits.net http://www.chaosbits.net/ Don't top-post http://www.catb.org/jargon/html/T/top-post.html Plain text mails only, please. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: V4L2 Overlay mode replacement by dma-buf - was: Re: [PATCH 05/10] v4l: add buffer exporting via dmabuf
On Mon, Jan 23, 2012 at 10:57 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: 2) The userspace API changes to properly support for dma buffers. If you're not ready to discuss (2), that's ok, but I'd like to follow the discussions for it with care, not only for reviewing the actual patches, but also since I want to be sure that it will address the needs for xawtv and for the Xorg v4l driver. The support of dmabuf could be easily added to framebuffer API. I expect that it would not be difficult to add it to Xv. You might want to have a look at my dri2video proposal a while back. I plan some minor changes to make the api for multi-planar formats look a bit more like how addfb2 ended up (ie. array of handles, offsets, and pitches), but you could get the basic idea from: http://patchwork.freedesktop.org/patch/7939/ A texture based API is likely needed, at least for it to work with modern PC GPU's. I suspect we will end up w/ an eglImage extension to go dmabuf fd - eglImage, and perhaps handle barriers and userspace mappings. That should, I think, be the best approach to best hide/abstract all the GPU crazy games from the rest of the world. BR, -R -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv1 2/4] v4l:vb2: add support for shared buffer (dma_buf)
On Mon, Jan 23, 2012 at 4:54 AM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Hi Daniel, On Monday 23 January 2012 11:35:01 Daniel Vetter wrote: On Mon, Jan 23, 2012 at 10:48, Laurent Pinchart wrote: On Monday 23 January 2012 10:06:57 Marek Szyprowski wrote: On Friday, January 20, 2012 5:29 PM Laurent Pinchart wrote: On Friday 20 January 2012 17:20:22 Tomasz Stanislawski wrote: IMO, One way to do this is adding field 'struct device *dev' to struct vb2_queue. This field should be filled by a driver prior to calling vb2_queue_init. I haven't looked into the details, but that sounds good to me. Do we have use cases where a queue is allocated before knowing which physical device it will be used for ? I don't think so. In case of S5P drivers, vb2_queue_init is called while opening /dev/videoX. BTW. This struct device may help vb2 to produce logs with more descriptive client annotation. What happens if such a device is NULL. It would happen for vmalloc allocator used by VIVI? Good question. Should dma-buf accept NULL devices ? Or should vivi pass its V4L2 device to vb2 ? I assume you suggested using struct video_device-dev entry in such case. It will not work. DMA-mapping API requires some parameters to be set for the client device, like for example dma mask. struct video_device contains only an artificial struct device entry, which has no relation to any physical device and cannot be used for calling DMA-mapping functions. Performing dma_map_* operations with such artificial struct device doesn't make any sense. It also slows down things significantly due to cache flushing (forced by dma-mapping) which should be avoided if the buffer is accessed only with CPU (like it is done by vb2-vmalloc style drivers). I agree that mapping the buffer to the physical device doesn't make any sense, as there's simple no physical device to map the buffer to. In that case we could simply skip the dma_map/dma_unmap calls. See my other mail, dma_buf v1 does not support cpu access. v1 is in the kernel now, let's start discussing v2 ;-) So if you don't have a device around, you can't use it in it's current form. Note, however, that dma-buf v1 explicitly does not support CPU access by the importer. IMHO this case perfectly shows the design mistake that have been made. The current version simply tries to do too much. Each client of dma_buf should 'map' the provided sgtable/scatterlist on its own. Only the client device driver has all knowledge to make a proper 'mapping'. Real physical devices usually will use dma_map_sg() for such operation, while some virtual ones will only create a kernel mapping for the provided scatterlist (like vivi with vmalloc memory module). I tend to agree with that. Depending on the importer device, drivers could then map/unmap the buffer around each DMA access, or keep a mapping and sync the buffer. Again we've discussed adding a syncing op to the interface that would allow keeping around mappings. The thing is that this also requires an unmap callback or something similar, so that the exporter can inform the importer that the memory just moved around. And the exporter _needs_ to be able to do that, hence also the language in the doc that importers need to braked all uses with a map/unmap and can't sit forever on a dma_buf mapping. Not all exporters need to be able to move buffers around. If I'm not mistaken, only DRM exporters need such a feature (which obviously makes it an important feature). Does the exporter need to be able to do so at any time ? Buffers can't obviously be moved around when they're used by an activa DMA, so I expect the exporter to be able to wait. How long can it wait ? Offhand I think it would usually be a request from userspace (in some cases page faults (although I think only if there is hw de-tiling?), or command submission to gpu involving some buffer(s) that are not currently mapped) that would trigger the exporter to want to be able to evict something. So could be blocked or something else evicted/moved instead. Although perhaps not ideal for performance. (app/toolkit writers seem to have a love of temporary pixmaps, so x11/ddx driver can chew thru a huge number of new buffer allocations in very short amount of time) I'm not sure I would like a callback approach. If we add a sync operation, the exporter could signal to the importer that it must unmap the buffer by returning an appropriate value from the sync operation. Would that be usable for DRM ? It does seem a bit over-complicated.. and deadlock prone. Is there a reason the importer couldn't just unmap when DMA is completed, and the exporter give some hint on next map() that the buffer hasn't actually moved? BR, -R Another option would be to keep the mapping around, and check in the importer if the buffer has moved. If
HVR 4000 hybrid card still producing multiple frontends for single adapter
Hi, I have a HVR 4000 hybrid card which provides both DVB-S2 and DVB-T capabilities on the one adapter. Using the current media tree build updated with the contents of the linux media drivers tarball dated 22/01/2012 the drivers for this card are still generating two frontends on the adapter as below: Jan 23 12:16:44 Nutrigrain kernel: [ 9.346240] DVB: registering adapter 1 frontend 0 (Conexant CX24116/CX24118)... Jan 23 12:16:44 Nutrigrain kernel: [ 9.349110] DVB: registering adapter 1 frontend 1 (Conexant CX22702 DVB-T)... I understand that this behaviour is now deprecated and that the correct behaviour should be to generate one front end with multiple capabilities. Can this please be corrected. Thanks, Mark Hawes. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] v4l2: handle multiplication overflow
Mauro Carvalho Chehab írta:
Em 22-12-2011 07:42, Németh Márton escreveu:
From: Márton Németh nm...@freemail.hu
When a V4L2 ioctl is executed the memory provided by the caller in user space
is copied to the kernel space in video_usercopy() function. To find out
how many bytes has to be copied the check_array_args() helper function is
used.
This patch adds a check for multiplication overflow. Without this check the
multiplication may overflow resulting array_size to be zero. This means that
later on uninitialized value can trigger NULL pointer exception.
The overflow happens because ctrls-count is an __u32 multiplied by a
constant
coming from sizeof() operator. Multiplication result of two 32bit value may
be a 64bit value, thus overflow can happen. Similarly buf-length is an __u32
multiplied by a constant coming from sizeof() operator.
The chosen error value is -ENOMEM because we are just about to allocate
kernel memory to copy data from userspace. We cannot even store the required
number of bytes in the variable of size_t type.
To trigger the error from user space use the v4l-test 0.19 [1] or essentially
the following code fragment:
struct v4l2_ext_controls controls;
memset(controls, 0, sizeof(controls));
controls.ctrl_class = V4L2_CTRL_CLASS_USER;
controls.count = 0x4000;
controls.controls = NULL;
ret = ioctl(f, VIDIOC_G_EXT_CTRLS, controls);
References:
[1] v4l-test: Test environment for Video For Linux Two (V4L2) API
http://v4l-test.sourceforge.net/
Signed-off-by: Márton Németh nm...@freemail.hu
---
I'm a little bit in doubt whether this is the correct way to check for the
multiplication overflow. In case of x86 architecture the MUL insruction [2]
can be used to multiply EAX with an other 32bit register, and the 64bit
result
is placed to EDX:EAX. In case of EDX != 0 the carry and overflow flags are
set.
This means that executing the MUL instruction on x86 already provides
information
whether the result fits to 32bit or not. I might use __u64 as a result of the
multiplication and check whether the upper 32bit is still zero but the
optimal
would be to check for the carry or the overflow flag.
Still, there could be a special case when the constant from sizeof()
operator is
a power of 2, in this case the compiler might optimize the multiplication
using
a shift left. In this case something else is needed.
I couldn't really find information about the number of bits for size_t on
different architectures. If size_t happens to be at least 64bit on some
architecture
then this overflow will not happen at all and the array_size will contain the
correct value.
What do you think?
Hi Németh,
IMO, the check should, instead, use a max hard limit for the array size.
There's no sense on allowing very large arrays there.
I think that this patch become obsoleted by this one, already merged:
Yes, that merged patch is simple and based on real-world practical
limits and also solves the overflow problem.
commit 6c06108be53ca5e94d8b0e93883d534dd9079646
Author: Dan Carpenter dan.carpen...@oracle.com
Date: Thu Jan 5 02:27:57 2012 -0300
[media] V4L/DVB: v4l2-ioctl: integer overflow in video_usercopy()
If ctrls-count is too high the multiplication could overflow and
array_size would be lower than expected. Mauro and Hans Verkuil
suggested that we cap it at 1024. That comes from the maximum
number of controls with lots of room for expantion.
$ grep V4L2_CID include/linux/videodev2.h | wc -l
211
Cc: stable sta...@vger.kernel.org
Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
diff --git a/drivers/media/video/v4l2-ioctl.c
b/drivers/media/video/v4l2-ioctl.c
index e1da8fc..639abee 100644
--- a/drivers/media/video/v4l2-ioctl.c
+++ b/drivers/media/video/v4l2-ioctl.c
@@ -2226,6 +2226,10 @@ static int check_array_args(unsigned int cmd, void
*parg, size_t *array_size,
struct v4l2_ext_controls *ctrls = parg;
if (ctrls-count != 0) {
+ if (ctrls-count V4L2_CID_MAX_CTRLS) {
+ ret = -EINVAL;
+ break;
+ }
*user_ptr = (void __user *)ctrls-controls;
*kernel_ptr = (void *)ctrls-controls;
*array_size = sizeof(struct v4l2_ext_control)
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 6bfaa76..b2e1331 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -1132,6 +1132,7 @@ struct v4l2_querymenu {
#define V4L2_CTRL_FLAG_NEXT_CTRL 0x8000
/* User-class control IDs defined by V4L2 */
+#define V4L2_CID_MAX_CTRLS 1024
#define V4L2_CID_BASE(V4L2_CTRL_CLASS_USER | 0x900)
#define
