kernel.git/drivers/media/platform/Kconfig, branch linux-3.14.y

[media] omap24xx/tcm825x: move to staging for future removal

2013-12-20T15:45:22Z

The omap24xx driver and the tcm825x sensor driver are the only two remaining drivers to still use the old deprecated v4l2-int-device API. Nobody maintains these drivers anymore. But unfortunately the v4l2-int-device API is used by out-of-tree drivers (MXC platform). This is a very bad situation since as long as this deprecated API stays in the kernel there is no reason for those out-of-tree drivers to convert. This patch moves v4l2-int-device and the two drivers that depend on it to staging in preparation for their removal. If someone would be interested in getting these drivers to work, then start with this since it's not very far from the state where they used to work: The branch is n800-cam. Porting to up-to-date APIs can then be done. David might have done some work in that area, so check with him first. Signed-off-by: Hans Verkuil Cc: Sakari Ailus Cc: David Cohen Signed-off-by: Mauro Carvalho Chehab

[media] v4l: sh_vou: Enable driver compilation with COMPILE_TEST

2013-12-10T11:08:59Z

This helps increasing build testing coverage. Cc: Guennadi Liakhovetski Signed-off-by: Laurent Pinchart Acked-by: Simon Horman Signed-off-by: Mauro Carvalho Chehab

Merge branch 'v4l_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media

2013-11-18T23:08:02Z

Pull media updates from Mauro Carvalho Chehab: "This series include: - a new Remote Controller driver for ST SoC with the corresponding DT bindings - a new frontend (cx24117) - a new I2C camera flash driver (lm3560) - a new mem2mem driver for TI SoC (ti-vpe) - support for Raphael r828d added to r820t driver - some improvements on buffer allocation at VB2 core - usual driver fixes and improvements PS this time, we have a smaller number of patches. While it is hard to pinpoint to the reasons, I believe that it is mainly due to: 1) there are several patch series ready, but depending on DT review. I decided to grant some extra time for DT maintainers to look on it, as they're expecting to have more time with the changes agreed during ARM mini-summit and KS. If they can't review in time for 3.14, I'll review myself and apply for the next merge window. 2) I suspect that having both LinuxCon EU and LinuxCon NA happening during the same merge window affected the development productivity, as several core media developers participated on both events" * 'v4l_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media: (151 commits) [media] media: st-rc: Add ST remote control driver [media] gpio-ir-recv: Include linux/of.h header [media] tvp7002: Include linux/of.h header [media] tvp514x: Include linux/of.h header [media] ths8200: Include linux/of.h header [media] adv7343: Include linux/of.h header [media] v4l: Fix typo in v4l2_subdev_get_try_crop() [media] media: i2c: add driver for dual LED Flash, lm3560 [media] rtl28xxu: add 15f4:0131 Astrometa DVB-T2 [media] rtl28xxu: add RTL2832P + R828D support [media] rtl2832: add new tuner R828D [media] r820t: add support for R828D [media] media/i2c: ths8200: fix build failure with gcc 4.5.4 [media] Add support for KWorld UB435-Q V2 [media] staging/media: fix msi3101 build errors [media] ddbridge: Remove casting the return value which is a void pointer [media] ngene: Remove casting the return value which is a void pointer [media] dm1105: remove unneeded not-null test [media] sh_mobile_ceu_camera: remove deprecated IRQF_DISABLED [media] media: rcar_vin: Add preliminary r8a7790 support ...

[media] platform: Kconfig: Select SRAM for VIDEO_CODA

2013-10-28T18:51:08Z

Running the coda driver without CONFIG_SRAM selected leads to the following probe error: coda 63ff4000.vpu: iram pool not available coda: probe of 63ff4000.vpu failed with error -12 In order to avoid it, select CONFIG_SRAM inside VIDEO_CODA. Signed-off-by: Fabio Estevam Signed-off-by: Kamil Debski Signed-off-by: Mauro Carvalho Chehab

[media] v4l: ti-vpe: Add VPE mem to mem driver

2013-10-28T17:17:30Z

VPE is a block which consists of a single memory to memory path which can perform chrominance up/down sampling, de-interlacing, scaling, and color space conversion of raster or tiled YUV420 coplanar, YUV422 coplanar or YUV422 interleaved video formats. We create a mem2mem driver based primarily on the mem2mem-testdev example. The de-interlacer, scaler and color space converter are all bypassed for now to keep the driver simple. Chroma up/down sampler blocks are implemented, so conversion beteen different YUV formats is possible. Each mem2mem context allocates a buffer for VPE MMR values which it will use when it gets access to the VPE HW via the mem2mem queue, it also allocates a VPDMA descriptor list to which configuration and data descriptors are added. Based on the information received via v4l2 ioctls for the source and destination queues, the driver configures the values for the MMRs, and stores them in the buffer. There are also some VPDMA parameters like frame start and line mode which needs to be configured, these are configured by direct register writes via the VPDMA helper functions. The driver's device_run() mem2mem op will add each descriptor based on how the source and destination queues are set up for the given ctx, once the list is prepared, it's submitted to VPDMA, these descriptors when parsed by VPDMA will upload MMR registers, start DMA of video buffers on the various input and output clients/ports. When the list is parsed completely(and the DMAs on all the output ports done), an interrupt is generated which we use to notify that the source and destination buffers are done. The rest of the driver is quite similar to other mem2mem drivers, we use the multiplane v4l2 ioctls as the HW support coplanar formats. Signed-off-by: Archit Taneja Acked-by: Hans Verkuil Signed-off-by: Kamil Debski Signed-off-by: Mauro Carvalho Chehab

s3c-camif: Use CONFIG_ARCH_S3C64XX to check for S3C64XX support

2013-10-06T00:01:56Z

Since CONFIG_PLAT_S3C64XX is going to be removed, this patch modifies the Kconfig entry of s3c-camif driver to use the proper way of checking for S3C64xx support - CONFIG_ARCH_S3C64XX. Signed-off-by: Tomasz Figa Signed-off-by: Kukjin Kim

[media] media/v4l2: VIDEO_RENESAS_VSP1 should depend on HAS_DMA

2013-10-03T17:09:03Z

If NO_DMA=y: warning: (... && VIDEO_RENESAS_VSP1 && ...) selects VIDEOBUF2_DMA_CONTIG which has unmet direct dependencies (MEDIA_SUPPORT && HAS_DMA) drivers/media/v4l2-core/videobuf2-dma-contig.c: In function ‘vb2_dc_mmap’: drivers/media/v4l2-core/videobuf2-dma-contig.c:202: error: implicit declaration of function ‘dma_mmap_coherent’ drivers/media/v4l2-core/videobuf2-dma-contig.c: In function ‘vb2_dc_get_base_sgt’: drivers/media/v4l2-core/videobuf2-dma-contig.c:385: error: implicit declaration of function ‘dma_get_sgtable’ make[7]: *** [drivers/media/v4l2-core/videobuf2-dma-contig.o] Error 1 VIDEO_RENESAS_VSP1 (which doesn't have a platform dependency) selects VIDEOBUF2_DMA_CONTIG, but the latter depends on HAS_DMA. Make VIDEO_RENESAS_VSP1 depend on HAS_DMA to fix this. Signed-off-by: Geert Uytterhoeven Acked-by: Laurent Pinchart Signed-off-by: Mauro Carvalho Chehab

Remove GENERIC_HARDIRQ config option

2013-09-13T13:09:52Z

After the last architecture switched to generic hard irqs the config options HAVE_GENERIC_HARDIRQS & GENERIC_HARDIRQS and the related code for !CONFIG_GENERIC_HARDIRQS can be removed. Signed-off-by: Martin Schwidefsky

[media] media/v4l2: VIDEO_SH_VEU should depend on HAS_DMA

2013-08-23T08:46:08Z

If NO_DMA=y: drivers/media/v4l2-core/videobuf2-dma-contig.c: In function ‘vb2_dc_mmap’: drivers/media/v4l2-core/videobuf2-dma-contig.c:204: error: implicit declaration of function ‘dma_mmap_coherent’ drivers/media/v4l2-core/videobuf2-dma-contig.c: In function ‘vb2_dc_get_base_sgt’: drivers/media/v4l2-core/videobuf2-dma-contig.c:387: error: implicit declaration of function ‘dma_get_sgtable’ Commit da508f5799659241a359e2d07abb8af905f6291c ("[media] media/v4l2: VIDEOBUF2_DMA_CONTIG should depend on HAS_DMA") added a dependency on HAS_DMA to VIDEO_SH_VEU, as it selects VIDEOBUF2_DMA_CONTIG. However, this got lost in the merge conflict resolution in commit df90e2258950fd631cdbf322c1ee1f22068391aa ("Merge branch 'devel-for-v3.10' into v4l_for_linus"). Re-add the dependency to fix this. Signed-off-by: Geert Uytterhoeven Signed-off-by: Mauro Carvalho Chehab

[media] v4l: Renesas R-Car VSP1 driver

2013-08-18T10:30:16Z

The VSP1 is a video processing engine that includes a blender, scalers, filters and statistics computation. Configurable data path routing logic allows ordering the internal blocks in a flexible way. Due to the configurable nature of the pipeline the driver implements the media controller API and doesn't use the V4L2 mem-to-mem framework, even though the device usually operates in memory to memory mode. Only the read pixel formatters, up/down scalers, write pixel formatters and LCDC interface are supported at this stage. Signed-off-by: Laurent Pinchart Acked-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab