Re: Make menuconfig doesn't work anymore
2012/7/12 VDR User user@gmail.com: No, the drivers I need were already there but I just checked my menuconfig and I see: Multimedia support - Customize TV tuners - NXP TDA18212 silicon tuner Is that what you're looking for? If so, all you need, I think, is DVB for Linux and Customize analog and hybrid tuner modules to build to get the Customize TV tuners option. Thanks for the input, but that's not the driver I need. I need the ddbridge compatible (?) driver, NXP TDA18212 DD [*] DVB/ATSC adapters M Digital Devices bridge support [*] Customse the frontend modules to build Customize DVB Frontends → STV 0367 (DD) NXP TDA18212 silicon tuner (DD) -- 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: Media system Summit
Hi Mauro, On 07/12/2012 05:18 AM, Mauro Carvalho Chehab wrote: Em 11-07-2012 05:09, James Bottomley escreveu: Hi All, We have set aside the second day of the kernel summit (Tuesday 28 August) as mini-summit day. So far we have only the PCI mini summit on this day Not sure what happened (or maybe my proposal were not clear enough), but I've submitted a proposal to have a media system summit on KS/2011. Last year was very productive for media developers, so we'd like to do it again ;) Message-ID:4fec74ab.6070...@redhat.com Date: Thu, 28 Jun 2012 12:13:47 -0300 From: Mauro Carvalho Chehabmche...@redhat.com [Ksummit-2012-discuss] [ATTEND] media subsystem I'd like to have media subsystem discussions this year's at kernel summit. The media subsystem is one of the most active driver subsystem, and there are lots of things there that require face-to-face discussions, not only between subsystem developers, but also with other maintainers. In special, during KS/2011, it was identified the need of interacting with video and audio system people, in order to solve some common issues, like HDMI CEC and audio/video synchronization. The increasing complexity of SoC designs used by media devices requires API extensions at the media APIs in order to proper expose and control all hardware functionality on a standard way. A new API to better allow negotiating userspace and Kernelspace capabilities seem to be required. More discussions with regards to shared resources locking is needed, on devices that implement multiple API's, but not a the same time. The incompatibility between udev-182 and the existing drivers will also require lots of discussions, as that affects 64 media drivers, and changing them to comply with the current requirement of using request_firmware_nowait() won't work on several drivers. So, a solution (or a set of solutions) needs to be found, in order to fix such incompatibility. I'd like to add a Common device tree bindings for media devices topic to the agenda for consideration. There were some activities on creating device tree bindings for Samsung and SH Mobile SoCs but this didn't really kick off yet and a face to face discussions could help to bring device tree support in media subsystem to the level many other subsystems already have. -- Thanks, Sylwester -- 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: mx2_camera: Add YUYV output format.
Add explicit conversions from UYVY and YUYV to YUYV so that
csicr1 configuration can be set properly for each format.
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
drivers/media/video/mx2_camera.c | 40 ++
1 file changed, 40 insertions(+)
diff --git a/drivers/media/video/mx2_camera.c b/drivers/media/video/mx2_camera.c
index 0f01e7b..2a33bcb 100644
--- a/drivers/media/video/mx2_camera.c
+++ b/drivers/media/video/mx2_camera.c
@@ -337,6 +337,34 @@ static struct mx2_fmt_cfg mx27_emma_prp_table[] = {
}
},
{
+ .in_fmt = V4L2_MBUS_FMT_UYVY8_2X8,
+ .out_fmt= V4L2_PIX_FMT_YUYV,
+ .cfg= {
+ .channel= 1,
+ .in_fmt = PRP_CNTL_DATA_IN_YUV422,
+ .out_fmt= PRP_CNTL_CH1_OUT_YUV422,
+ .src_pixel = 0x22000888, /* YUV422 (YUYV) */
+ .ch1_pixel = 0x62000888, /* YUV422 (YUYV) */
+ .irq_flags = PRP_INTR_RDERR | PRP_INTR_CH1WERR |
+ PRP_INTR_CH1FC | PRP_INTR_LBOVF,
+ .csicr1 = CSICR1_SWAP16_EN,
+ }
+ },
+ {
+ .in_fmt = V4L2_MBUS_FMT_YUYV8_2X8,
+ .out_fmt= V4L2_PIX_FMT_YUYV,
+ .cfg= {
+ .channel= 1,
+ .in_fmt = PRP_CNTL_DATA_IN_YUV422,
+ .out_fmt= PRP_CNTL_CH1_OUT_YUV422,
+ .src_pixel = 0x22000888, /* YUV422 (YUYV) */
+ .ch1_pixel = 0x62000888, /* YUV422 (YUYV) */
+ .irq_flags = PRP_INTR_RDERR | PRP_INTR_CH1WERR |
+ PRP_INTR_CH1FC | PRP_INTR_LBOVF,
+ .csicr1 = CSICR1_PACK_DIR,
+ }
+ },
+ {
.in_fmt = V4L2_MBUS_FMT_YUYV8_2X8,
.out_fmt= V4L2_PIX_FMT_YUV420,
.cfg= {
@@ -1146,6 +1174,18 @@ static int mx2_camera_get_formats(struct
soc_camera_device *icd,
}
}
+ if (code == V4L2_MBUS_FMT_UYVY8_2X8) {
+ formats++;
+ if (xlate) {
+ xlate-host_fmt =
+ soc_mbus_get_fmtdesc(V4L2_MBUS_FMT_YUYV8_2X8);
+ xlate-code = code;
+ dev_dbg(dev, Providing host format %s for sensor code
%d\n,
+ xlate-host_fmt-name, code);
+ xlate++;
+ }
+ }
+
/* Generic pass-trough */
formats++;
if (xlate) {
--
1.7.9.5
--
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: mx2_camera: Remove MX2_CAMERA_SWAP16 and MX2_CAMERA_PACK_DIR_MSB flags.
These flags are not used any longer and can be safely removed since the following patch: http://www.spinics.net/lists/linux-media/msg50165.html Signed-off-by: Javier Martin javier.mar...@vista-silicon.com --- arch/arm/plat-mxc/include/mach/mx2_cam.h |2 -- 1 file changed, 2 deletions(-) diff --git a/arch/arm/plat-mxc/include/mach/mx2_cam.h b/arch/arm/plat-mxc/include/mach/mx2_cam.h index 3c080a3..7ded6f1 100644 --- a/arch/arm/plat-mxc/include/mach/mx2_cam.h +++ b/arch/arm/plat-mxc/include/mach/mx2_cam.h @@ -23,7 +23,6 @@ #ifndef __MACH_MX2_CAM_H_ #define __MACH_MX2_CAM_H_ -#define MX2_CAMERA_SWAP16 (1 0) #define MX2_CAMERA_EXT_VSYNC (1 1) #define MX2_CAMERA_CCIR(1 2) #define MX2_CAMERA_CCIR_INTERLACE (1 3) @@ -31,7 +30,6 @@ #define MX2_CAMERA_GATED_CLOCK (1 5) #define MX2_CAMERA_INV_DATA(1 6) #define MX2_CAMERA_PCLK_SAMPLE_RISING (1 7) -#define MX2_CAMERA_PACK_DIR_MSB(1 8) /** * struct mx2_camera_platform_data - optional platform data for mx2_camera -- 1.7.9.5 -- 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 1/5] v4l2: Add rangelow and rangehigh fields to the v4l2_hw_freq_seek struct
On Wed 11 July 2012 20:37:14 Hans de Goede wrote: Hi Hans, On 07/11/2012 08:01 PM, Hans Verkuil wrote: Hi Hans, Thanks for the patch. I've CC-ed Halli as well. On Wed July 11 2012 17:47:34 Hans de Goede wrote: To allow apps to limit a hw-freq-seek to a specific band, for further info see the documentation this patch adds for these new fields. Signed-off-by: Hans de Goede hdego...@redhat.com --- .../DocBook/media/v4l/vidioc-s-hw-freq-seek.xml| 44 include/linux/videodev2.h |5 ++- 2 files changed, 40 insertions(+), 9 deletions(-) diff --git a/Documentation/DocBook/media/v4l/vidioc-s-hw-freq-seek.xml b/Documentation/DocBook/media/v4l/vidioc-s-hw-freq-seek.xml index f4db44d..50dc9f8 100644 --- a/Documentation/DocBook/media/v4l/vidioc-s-hw-freq-seek.xml +++ b/Documentation/DocBook/media/v4l/vidioc-s-hw-freq-seek.xml @@ -52,11 +52,21 @@ paraStart a hardware frequency seek from the current frequency. To do this applications initialize the structfieldtuner/structfield, structfieldtype/structfield, structfieldseek_upward/structfield, -structfieldspacing/structfield and -structfieldwrap_around/structfield fields, and zero out the -structfieldreserved/structfield array of a v4l2-hw-freq-seek; and -call the constantVIDIOC_S_HW_FREQ_SEEK/constant ioctl with a pointer -to this structure./para +structfieldwrap_around/structfield, structfieldspacing/structfield, +structfieldrangelow/structfield and structfieldrangehigh/structfield +fields, and zero out the structfieldreserved/structfield array of a +v4l2-hw-freq-seek; and call the constantVIDIOC_S_HW_FREQ_SEEK/constant +ioctl with a pointer to this structure./para + +paraThe structfieldrangelow/structfield and +structfieldrangehigh/structfield fields can be set to a non-zero value to +tell the driver to search a specific band. If the v4l2-tuner; +structfieldcapability/structfield field has the +constantV4L2_TUNER_CAP_HWSEEK_PROG_LIM/constant flag set, these values +must fall within one of the bands returned by VIDIOC-ENUM-FREQ-BANDS;. If +the constantV4L2_TUNER_CAP_HWSEEK_PROG_LIM/constant flag is not set, +then these values must exactly match those of one of the bands returned by +VIDIOC-ENUM-FREQ-BANDS;./para OK, I have some questions here: 1) If you have a multiband tuner, what should happen if both low and high are zero? Currently it is undefined, other than that the seek should start from the current frequency until it reaches some limit. That would be driver specific, we could add the same If rangelow/high is zero a reasonable default value is used. language as used for the spacing. For example for the si470x if both are zero I simply switch to the Japan wide band which covers all frequencies handled by the other bands, but if there is no such covers all ranges band, then the logical thing todo would just keep the band as is (so as determined by the last s_freq). Halli, what does your hardware do? In particular, is the hwseek limited by the US/Europe or Japan band range or can it do the full range? If I'm not mistaken it is the former, right? If it is the former, then you need to explicitly set low + high to ensure that the hwseek uses the correct range because the driver can't guess which of the overlapping bands to use. 2) What happens if the current frequency is outside the low/high range? The hwseek spec says that the seek starts from the current frequency, so that might mean that hwseek returns -ERANGE in this case. What the si470x code currently does is just clamp the frequency to the new range before seeking, but -ERANGE works for me too. Clamping is a better idea IMHO as long as it is documented. 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
[PATCH 1/2 v2] media: Add mem2mem deinterlacing driver.
Some video decoders such as tvp5150 provide separate
video fields (V4L2_FIELD_SEQ_TB/BT). This driver uses
dmaengine to convert this format to V4L2_FIELD_INTERLACED_TB/BT
(weaving) or V4L2_FIELD_NONE (line doubling) so that the
image can be displayed or processed.
Of course there will be combing effect in the image but this
can be accepted for some low quality applications.
Currently YUV420 and YUYV formats are supported but
can be extended later.
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
Changes since v1:
- Added support for V4L2_FIELD_SEQ_BT to V4L2_FIELD_INTERLACED_BT
and V4L2_FIELD_NONE.
---
drivers/media/video/Kconfig |8 +
drivers/media/video/Makefile |2 +
drivers/media/video/m2m-deinterlace.c | 1131 +
3 files changed, 1141 insertions(+)
create mode 100644 drivers/media/video/m2m-deinterlace.c
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 9cebf7b..c0b9233 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -1188,6 +1188,14 @@ config VIDEO_CODA
Coda is a range of video codec IPs that supports
H.264, MPEG-4, and other video formats.
+config VIDEO_MEM2MEM_DEINTERLACE
+ tristate Deinterlace support
+ depends on VIDEO_DEV VIDEO_V4L2 DMA_ENGINE
+ select VIDEOBUF2_DMA_CONTIG
+ select V4L2_MEM2MEM_DEV
+ help
+ Generic deinterlacing V4L2 driver.
+
config VIDEO_SAMSUNG_S5P_G2D
tristate Samsung S5P and EXYNOS4 G2D 2d graphics accelerator driver
depends on VIDEO_DEV VIDEO_V4L2 PLAT_S5P
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index a04c307..b6a01b1 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -189,6 +189,8 @@ obj-$(CONFIG_VIDEO_ATMEL_ISI) += atmel-isi.o
obj-$(CONFIG_VIDEO_MX2_EMMAPRP)+= mx2_emmaprp.o
obj-$(CONFIG_VIDEO_CODA) += coda.o
+obj-$(CONFIG_VIDEO_MEM2MEM_DEINTERLACE)+= m2m-deinterlace.o
+
obj-$(CONFIG_VIDEO_SAMSUNG_S5P_FIMC) += s5p-fimc/
obj-$(CONFIG_VIDEO_SAMSUNG_S5P_JPEG) += s5p-jpeg/
obj-$(CONFIG_VIDEO_SAMSUNG_S5P_MFC)+= s5p-mfc/
diff --git a/drivers/media/video/m2m-deinterlace.c
b/drivers/media/video/m2m-deinterlace.c
new file mode 100644
index 000..4187c80
--- /dev/null
+++ b/drivers/media/video/m2m-deinterlace.c
@@ -0,0 +1,1131 @@
+/*
+ * V4L2 deinterlacing support.
+ *
+ * Copyright (c) 2012 Vista Silicon S.L.
+ * Javier Martin javier.mar...@vista-silicon.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; either version 2 of the
+ * License, or (at your option) any later version
+ */
+
+#include linux/module.h
+#include linux/slab.h
+#include linux/interrupt.h
+#include linux/dmaengine.h
+#include linux/platform_device.h
+
+#include media/v4l2-mem2mem.h
+#include media/v4l2-device.h
+#include media/v4l2-ioctl.h
+#include media/videobuf2-dma-contig.h
+
+#define MEM2MEM_TEST_MODULE_NAME mem2mem-deinterlace
+
+MODULE_DESCRIPTION(mem2mem device which supports deinterlacing using
dmaengine);
+MODULE_AUTHOR(Javier Martin javier.mar...@vista-silicon.com);
+MODULE_LICENSE(GPL);
+MODULE_VERSION(0.0.1);
+
+static bool debug = true;
+module_param(debug, bool, 0644);
+
+/* Flags that indicate a format can be used for capture/output */
+#define MEM2MEM_CAPTURE(1 0)
+#define MEM2MEM_OUTPUT (1 1)
+
+#define MEM2MEM_NAME m2m-deinterlace
+
+#define dprintk(dev, fmt, arg...) \
+ v4l2_dbg(1, debug, dev-v4l2_dev, %s: fmt, __func__, ## arg)
+
+struct deinterlace_fmt {
+ char*name;
+ u32 fourcc;
+ enum v4l2_field field;
+ /* Types the format can be used for */
+ u32 types;
+};
+
+static struct deinterlace_fmt formats[] = {
+ {
+ .name = YUV 4:2:0 Planar (weaving),
+ .fourcc = V4L2_PIX_FMT_YUV420,
+ .field = V4L2_FIELD_INTERLACED_TB,
+ .types = MEM2MEM_CAPTURE,
+ },
+ {
+ .name = YUV 4:2:0 Planar (weaving),
+ .fourcc = V4L2_PIX_FMT_YUV420,
+ .field = V4L2_FIELD_INTERLACED_BT,
+ .types = MEM2MEM_CAPTURE,
+ },
+ {
+ .name = YUV 4:2:0 Planar (line doubling),
+ .fourcc = V4L2_PIX_FMT_YUV420,
+ /* Line doubling, top field */
+ .field = V4L2_FIELD_NONE,
+ .types = MEM2MEM_CAPTURE,
+ },
+ {
+ .name = YUYV 4:2:2 (weaving),
+ .fourcc = V4L2_PIX_FMT_YUYV,
+ .field = V4L2_FIELD_INTERLACED_TB,
+ .types = MEM2MEM_CAPTURE,
+ },
+ {
+ .name = YUYV 4:2:2 (weaving),
+ .fourcc = V4L2_PIX_FMT_YUYV,
+ .field =
[PATCH 2/2 v2] i.MX27: Visstrim_M10: Add support for deinterlacing driver.
Visstrim_M10 have a tvp5150 whose video output must be deinterlaced.
The new mem2mem deinterlacing driver is very useful for that purpose.
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
Changes since v1:
- Removed commented out code.
---
arch/arm/mach-imx/mach-imx27_visstrim_m10.c | 27 ++-
1 file changed, 26 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-imx/mach-imx27_visstrim_m10.c
b/arch/arm/mach-imx/mach-imx27_visstrim_m10.c
index 214e4ff..dbef59d 100644
--- a/arch/arm/mach-imx/mach-imx27_visstrim_m10.c
+++ b/arch/arm/mach-imx/mach-imx27_visstrim_m10.c
@@ -232,7 +232,7 @@ static void __init visstrim_camera_init(void)
static void __init visstrim_reserve(void)
{
/* reserve 4 MiB for mx2-camera */
- mx2_camera_base = arm_memblock_steal(2 * MX2_CAMERA_BUF_SIZE,
+ mx2_camera_base = arm_memblock_steal(3 * MX2_CAMERA_BUF_SIZE,
MX2_CAMERA_BUF_SIZE);
}
@@ -419,6 +419,30 @@ static void __init visstrim_coda_init(void)
return;
}
+/* DMA deinterlace */
+static struct platform_device visstrim_deinterlace = {
+ .name = m2m-deinterlace,
+ .id = 0,
+};
+
+static void __init visstrim_deinterlace_init(void)
+{
+ int ret = -ENOMEM;
+ struct platform_device *pdev = visstrim_deinterlace;
+ int dma;
+
+ ret = platform_device_register(pdev);
+
+ dma = dma_declare_coherent_memory(pdev-dev,
+ mx2_camera_base + 2 *
MX2_CAMERA_BUF_SIZE,
+ mx2_camera_base + 2 *
MX2_CAMERA_BUF_SIZE,
+ MX2_CAMERA_BUF_SIZE,
+ DMA_MEMORY_MAP |
DMA_MEMORY_EXCLUSIVE);
+ if (!(dma DMA_MEMORY_MAP))
+ return;
+}
+
+
static void __init visstrim_m10_revision(void)
{
int exp_version = 0;
@@ -481,6 +505,7 @@ static void __init visstrim_m10_board_init(void)
platform_device_register_resndata(NULL, soc-camera-pdrv, 0, NULL, 0,
iclink_tvp5150, sizeof(iclink_tvp5150));
gpio_led_register_device(0, visstrim_m10_led_data);
+ visstrim_deinterlace_init();
visstrim_camera_init();
visstrim_coda_init();
}
--
1.7.9.5
--
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] videobuf-dma-contig: Use NULL instead of plain integer
Fixes the following sparse warning: drivers/media/video/videobuf-dma-contig.c:59:46: warning: Using plain integer as NULL pointer Signed-off-by: Sachin Kamat sachin.ka...@linaro.org --- drivers/media/video/videobuf-dma-contig.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/media/video/videobuf-dma-contig.c b/drivers/media/video/videobuf-dma-contig.c index 9b9a06f..a5af8b4 100644 --- a/drivers/media/video/videobuf-dma-contig.c +++ b/drivers/media/video/videobuf-dma-contig.c @@ -56,7 +56,7 @@ static int __videobuf_dc_alloc(struct device *dev, dev_err(dev, dma_map_single failed\n); free_pages_exact(mem-vaddr, mem-size); - mem-vaddr = 0; + mem-vaddr = NULL; return err; } } -- 1.7.4.1 -- 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 2/2] [media] s5p-mfc: update MFC v4l2 driver to support MFC6.x
Hi Kyungmin Park, Thank you for the review. Please find my comments inline. On Fri, Jul 6, 2012 at 7:51 PM, Kyungmin Park kmp...@infradead.org wrote: Hi, On Fri, Jul 6, 2012 at 11:00 PM, Arun Kumar K arun...@samsung.com wrote: From: Jeongtae Park jtp.p...@samsung.com Multi Format Codec 6.x is a hardware video coding acceleration module fount in new Exynos5 SoC series. It is capable of handling a range of video codecs and this driver provides a V4L2 interface for video decoding and encoding. Signed-off-by: Jeongtae Park jtp.p...@samsung.com Singed-off-by: Janghyuck Kim janghyuck@samsung.com Singed-off-by: Jaeryul Oh jaeryul...@samsung.com Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com Signed-off-by: Arun Kumar K arun...@samsung.com Cc: Marek Szyprowski m.szyprow...@samsung.com Cc: Kamil Debski k.deb...@samsung.com --- drivers/media/video/Kconfig | 16 +- drivers/media/video/s5p-mfc/Makefile |7 +- drivers/media/video/s5p-mfc/regs-mfc-v6.h| 676 ++ drivers/media/video/s5p-mfc/regs-mfc.h | 29 + drivers/media/video/s5p-mfc/s5p_mfc.c| 163 ++- drivers/media/video/s5p-mfc/s5p_mfc_cmd.c|6 +- drivers/media/video/s5p-mfc/s5p_mfc_cmd.h|3 + drivers/media/video/s5p-mfc/s5p_mfc_cmd_v6.c | 96 ++ drivers/media/video/s5p-mfc/s5p_mfc_common.h | 123 ++- drivers/media/video/s5p-mfc/s5p_mfc_ctrl.c | 160 ++- drivers/media/video/s5p-mfc/s5p_mfc_ctrl.h |1 + drivers/media/video/s5p-mfc/s5p_mfc_dec.c| 210 +++- drivers/media/video/s5p-mfc/s5p_mfc_dec.h|1 + drivers/media/video/s5p-mfc/s5p_mfc_enc.c| 191 ++-- drivers/media/video/s5p-mfc/s5p_mfc_enc.h|1 + drivers/media/video/s5p-mfc/s5p_mfc_intr.c |1 - drivers/media/video/s5p-mfc/s5p_mfc_opr.c| 278 +++-- drivers/media/video/s5p-mfc/s5p_mfc_opr.h| 25 +- drivers/media/video/s5p-mfc/s5p_mfc_opr_v6.c | 1697 ++ drivers/media/video/s5p-mfc/s5p_mfc_opr_v6.h | 140 +++ drivers/media/video/s5p-mfc/s5p_mfc_pm.c |6 +- drivers/media/video/s5p-mfc/s5p_mfc_shm.c| 28 +- drivers/media/video/s5p-mfc/s5p_mfc_shm.h| 13 +- drivers/media/video/v4l2-ctrls.c |1 - 24 files changed, 3476 insertions(+), 396 deletions(-) Doesn't it too big for one patch? Can you split it into several patches? Ok. I will split it in the next patch. create mode 100644 drivers/media/video/s5p-mfc/regs-mfc-v6.h create mode 100644 drivers/media/video/s5p-mfc/s5p_mfc_cmd_v6.c create mode 100644 drivers/media/video/s5p-mfc/s5p_mfc_opr_v6.c create mode 100644 drivers/media/video/s5p-mfc/s5p_mfc_opr_v6.h diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig index 99937c9..0d7fe77 100644 --- a/drivers/media/video/Kconfig +++ b/drivers/media/video/Kconfig @@ -1198,13 +1198,27 @@ config VIDEO_SAMSUNG_S5P_JPEG This is a v4l2 driver for Samsung S5P and EXYNOS4 JPEG codec config VIDEO_SAMSUNG_S5P_MFC + bool + +config VIDEO_SAMSUNG_S5P_MFC_V5 tristate Samsung S5P MFC 5.1 Video Codec - depends on VIDEO_DEV VIDEO_V4L2 PLAT_S5P + depends on VIDEO_DEV VIDEO_V4L2 ARCH_EXYNOS4 + select VIDEO_SAMSUNG_S5P_MFC select VIDEOBUF2_DMA_CONTIG default n help MFC 5.1 driver for V4L2. +config VIDEO_SAMSUNG_S5P_MFC_V6 Yes, I know it's exynos5 series features. however, it's not good idea to add new config. It already handled platform device with proper name. e.g., s5p-mfc-v5, s5p-mfc-v6 and handle it with platform data. Ok. Code changes are required for compiling both v5 and v6 together. Will incorporate in next patch. [snip] -#define MFC_CLKNAMEsclk_mfc +#if defined(CONFIG_VIDEO_SAMSUNG_S5P_MFC_V5) +#define MFC_CLKNAMEsclk_mfc +#elif defined(CONFIG_VIDEO_SAMSUNG_S5P_MFC_V6) +#define MFC_CLKNAMEaclk_333 I think it can handle clkname without new config. Yes I will change it. Regards Arun
RE: [PATCH v2 2/2] [media] s5p-mfc: update MFC v4l2 driver to support MFC6.x
Hi Kamil,
Thank you for the review. Please find my comments inline.
On Tue, Jul 10, 2012 at 8:40 PM, Kamil Debski k.deb...@samsung.com wrote:
Hi Arun,
Please find some additional comments below.
From: Arun Kumar K [mailto:arun...@samsung.com]
Sent: 06 July 2012 16:00
[snip]
diff --git a/drivers/media/video/s5p-mfc/Makefile
b/drivers/media/video/s5p-mfc/Makefile
index d066340..0308d74 100644
--- a/drivers/media/video/s5p-mfc/Makefile
+++ b/drivers/media/video/s5p-mfc/Makefile
@@ -1,5 +1,6 @@
obj-$(CONFIG_VIDEO_SAMSUNG_S5P_MFC) := s5p-mfc.o
-s5p-mfc-y += s5p_mfc.o s5p_mfc_intr.o s5p_mfc_opr.o
+s5p-mfc-y += s5p_mfc.o s5p_mfc_intr.o
s5p-mfc-y += s5p_mfc_dec.o s5p_mfc_enc.o
-s5p-mfc-y += s5p_mfc_ctrl.o s5p_mfc_cmd.o
-s5p-mfc-y += s5p_mfc_pm.o s5p_mfc_shm.o
+s5p-mfc-y += s5p_mfc_ctrl.o s5p_mfc_pm.o
+obj-$(CONFIG_VIDEO_SAMSUNG_S5P_MFC_V5) += s5p_mfc_opr.o s5p_mfc_cmd.o
s5p_mfc_shm.o
+obj-$(CONFIG_VIDEO_SAMSUNG_S5P_MFC_V6) += s5p_mfc_opr_v6.o
s5p_mfc_cmd_v6.o
diff --git a/drivers/media/video/s5p-mfc/regs-mfc-v6.h
b/drivers/media/video/s5p-mfc/regs-mfc-v6.h
new file mode 100644
index 000..f22a159
This Makefile does not work when compiling the driver as a module.
(I also wrote about this in my previous email)
Yes. I will fix it.
[snip]
#endif /* _REGS_FIMV_H */
diff --git a/drivers/media/video/s5p-mfc/s5p_mfc.c
b/drivers/media/video/s5p-mfc/s5p_mfc.c
index 9bb68e7..bec94bc 100644
--- a/drivers/media/video/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/video/s5p-mfc/s5p_mfc.c
[snip]
@@ -285,12 +276,13 @@ static void s5p_mfc_handle_frame(struct
s5p_mfc_ctx
*ctx,
dst_frame_status = s5p_mfc_get_dspl_status()
S5P_FIMV_DEC_STATUS_DECODING_STATUS_MASK;
- res_change = s5p_mfc_get_dspl_status()
- S5P_FIMV_DEC_STATUS_RESOLUTION_MASK;
+ res_change = (s5p_mfc_get_dspl_status()
+ S5P_FIMV_DEC_STATUS_RESOLUTION_MASK)
+ S5P_FIMV_DEC_STATUS_RESOLUTION_SHIFT;
mfc_debug(2, Frame Status: %x\n, dst_frame_status);
if (ctx-state == MFCINST_RES_CHANGE_INIT)
ctx-state = MFCINST_RES_CHANGE_FLUSH;
- if (res_change) {
+ if (res_change res_change != 3) {
Maybe
If (res_change == 1 || res_change == 2) {
would be better, at least it would be more clear.
Sure I will change it that way.
[snip]
diff --git a/drivers/media/video/s5p-mfc/s5p_mfc_common.h
b/drivers/media/video/s5p-mfc/s5p_mfc_common.h
index bd5706a..8c646f4 100644
--- a/drivers/media/video/s5p-mfc/s5p_mfc_common.h
+++ b/drivers/media/video/s5p-mfc/s5p_mfc_common.h
[snip]
@@ -499,37 +563,42 @@ struct s5p_mfc_ctx {
int display_delay;
int display_delay_enable;
int after_packed_pb;
+ int sei_fp_parse;
int dpb_count;
int total_dpb_count;
/* Buffers */
- void *ctx_buf;
- size_t ctx_phys;
- size_t ctx_ofs;
- size_t ctx_size;
-
- void *desc_buf;
- size_t desc_phys;
-
-
- void *shm_alloc;
- void *shm;
- size_t shm_ofs;
+ unsigned int ctx_size;
+ struct s5p_mfc_priv_buf ctx;
+ struct s5p_mfc_priv_buf dsc;
+ struct s5p_mfc_priv_buf shm;
I think that ctx_size could be integrated in struct s5p_mfc_priv_buf.
Also - why unsigned int, where in other places you use size_t for size?
I think it should be consistent. I would choose size_t.
Yes. size_t is better. I will change it.
struct s5p_mfc_enc_params enc_params;
size_t enc_dst_buf_size;
+ size_t luma_dpb_size;
+ size_t chroma_dpb_size;
+ size_t me_buffer_size;
+ size_t tmv_buffer_size;
^^ You use size_t here.
[snip]
diff --git a/drivers/media/video/s5p-mfc/s5p_mfc_ctrl.c
b/drivers/media/video/s5p-mfc/s5p_mfc_ctrl.c
index 08a5cfe..65ff15d 100644
--- a/drivers/media/video/s5p-mfc/s5p_mfc_ctrl.c
+++ b/drivers/media/video/s5p-mfc/s5p_mfc_ctrl.c
@@ -15,7 +15,6 @@
#include linux/firmware.h
#include linux/jiffies.h
#include linux/sched.h
-#include regs-mfc.h
#include s5p_mfc_cmd.h
#include s5p_mfc_common.h
#include s5p_mfc_debug.h
@@ -38,12 +37,12 @@ int s5p_mfc_alloc_and_load_firmware(struct
s5p_mfc_dev *dev)
* into kernel. */
mfc_debug_enter();
err = request_firmware((const struct firmware **)fw_blob,
- s5p-mfc.fw, dev-v4l2_dev.dev);
+ mfc_fw.bin, dev-v4l2_dev.dev);
Another name change? This is getting ridiculous. Nein, nein, nein ! ;)
If you _*really*_ need such a change then go ahead and try to convince
me, but I tell you - it's going to be hard.
Ok. I will retain the old name :)
And as discussed will add new name s5p-mfc-v6.fw for V6.
if (err != 0) {
mfc_err(Firmware is not present in the
[media] tvp5150: signedness bug in tvp5150_selmux()
tvp5150_read() returns negative error codes so this needs to be an int for the error handling to work. Signed-off-by: Dan Carpenter dan.carpen...@oracle.com diff --git a/drivers/media/video/tvp5150.c b/drivers/media/video/tvp5150.c index 0d897cb..a751b6c 100644 --- a/drivers/media/video/tvp5150.c +++ b/drivers/media/video/tvp5150.c @@ -257,7 +257,7 @@ static inline void tvp5150_selmux(struct v4l2_subdev *sd) int opmode = 0; struct tvp5150 *decoder = to_tvp5150(sd); int input = 0; - unsigned char val; + int val; if ((decoder-output TVP5150_BLACK_SCREEN) || !decoder-enable) input = 8; -- 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
Vacation hansg July 13th - July 20th
Hi All, I'm going on vacation for a week starting tomorrow, and I will *not* be reading email, etc. during that time. 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: linux-next: Tree for July 12 (v4l2-ioctl.c)
On 07/11/2012 11:03 PM, Stephen Rothwell wrote: Hi all, Changes since 20120710: on i386 and/or x86_64, drivers/media/video/v4l2-ioctl.c has too many errors to be listed here. This is the beginning few lines of the errors: drivers/media/video/v4l2-ioctl.c:1848:2: error: unknown field 'func' specified in initializer drivers/media/video/v4l2-ioctl.c:1848:2: warning: missing braces around initializer drivers/media/video/v4l2-ioctl.c:1848:2: warning: (near initialization for 'v4l2_ioctls[0].anonymous') drivers/media/video/v4l2-ioctl.c:1848:2: warning: initialization makes integer from pointer without a cast drivers/media/video/v4l2-ioctl.c:1848:2: error: initializer element is not computable at load time drivers/media/video/v4l2-ioctl.c:1848:2: error: (near initialization for 'v4l2_ioctls[0].anonymous.offset') drivers/media/video/v4l2-ioctl.c:1849:2: error: unknown field 'func' specified in initializer drivers/media/video/v4l2-ioctl.c:1849:2: warning: initialization makes integer from pointer without a cast drivers/media/video/v4l2-ioctl.c:1849:2: error: initializer element is not computable at load time drivers/media/video/v4l2-ioctl.c:1849:2: error: (near initialization for 'v4l2_ioctls[2].anonymous.offset') drivers/media/video/v4l2-ioctl.c:1850:2: error: unknown field 'func' specified in initializer drivers/media/video/v4l2-ioctl.c:1850:2: warning: initialization makes integer from pointer without a cast drivers/media/video/v4l2-ioctl.c:1850:2: error: initializer element is not computable at load time drivers/media/video/v4l2-ioctl.c:1850:2: error: (near initialization for 'v4l2_ioctls[4].anonymous.offset') drivers/media/video/v4l2-ioctl.c:1851:2: error: unknown field 'func' specified in initializer drivers/media/video/v4l2-ioctl.c:1851:2: warning: initialization makes integer from pointer without a cast drivers/media/video/v4l2-ioctl.c:1851:2: error: initializer element is not computable at load time drivers/media/video/v4l2-ioctl.c:1851:2: error: (near initialization for 'v4l2_ioctls[5].anonymous.offset') drivers/media/video/v4l2-ioctl.c:1852:2: error: unknown field 'func' specified in initializer drivers/media/video/v4l2-ioctl.c:1852:2: warning: initialization makes integer from pointer without a cast drivers/media/video/v4l2-ioctl.c:1852:2: error: initializer element is not computable at load time drivers/media/video/v4l2-ioctl.c:1852:2: error: (near initialization for 'v4l2_ioctls[8].anonymous.offset') drivers/media/video/v4l2-ioctl.c:1853:2: error: unknown field 'func' specified in initializer -- ~Randy -- 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 1/5] v4l2: Add rangelow and rangehigh fields to the v4l2_hw_freq_seek struct
Hi, On 07/11/2012 08:37 PM, halli manjunatha wrote: On Wed, Jul 11, 2012 at 1:01 PM, Hans Verkuil hverk...@xs4all.nl wrote: Hi Hans, Thanks for the patch. I've CC-ed Halli as well. On Wed July 11 2012 17:47:34 Hans de Goede wrote: To allow apps to limit a hw-freq-seek to a specific band, for further info see the documentation this patch adds for these new fields. Signed-off-by: Hans de Goede hdego...@redhat.com --- .../DocBook/media/v4l/vidioc-s-hw-freq-seek.xml| 44 include/linux/videodev2.h |5 ++- 2 files changed, 40 insertions(+), 9 deletions(-) diff --git a/Documentation/DocBook/media/v4l/vidioc-s-hw-freq-seek.xml b/Documentation/DocBook/media/v4l/vidioc-s-hw-freq-seek.xml index f4db44d..50dc9f8 100644 --- a/Documentation/DocBook/media/v4l/vidioc-s-hw-freq-seek.xml +++ b/Documentation/DocBook/media/v4l/vidioc-s-hw-freq-seek.xml @@ -52,11 +52,21 @@ paraStart a hardware frequency seek from the current frequency. To do this applications initialize the structfieldtuner/structfield, structfieldtype/structfield, structfieldseek_upward/structfield, -structfieldspacing/structfield and -structfieldwrap_around/structfield fields, and zero out the -structfieldreserved/structfield array of a v4l2-hw-freq-seek; and -call the constantVIDIOC_S_HW_FREQ_SEEK/constant ioctl with a pointer -to this structure./para +structfieldwrap_around/structfield, structfieldspacing/structfield, +structfieldrangelow/structfield and structfieldrangehigh/structfield +fields, and zero out the structfieldreserved/structfield array of a +v4l2-hw-freq-seek; and call the constantVIDIOC_S_HW_FREQ_SEEK/constant +ioctl with a pointer to this structure./para + +paraThe structfieldrangelow/structfield and +structfieldrangehigh/structfield fields can be set to a non-zero value to +tell the driver to search a specific band. If the v4l2-tuner; +structfieldcapability/structfield field has the +constantV4L2_TUNER_CAP_HWSEEK_PROG_LIM/constant flag set, these values +must fall within one of the bands returned by VIDIOC-ENUM-FREQ-BANDS;. If +the constantV4L2_TUNER_CAP_HWSEEK_PROG_LIM/constant flag is not set, +then these values must exactly match those of one of the bands returned by +VIDIOC-ENUM-FREQ-BANDS;./para OK, I have some questions here: 1) If you have a multiband tuner, what should happen if both low and high are zero? Currently it is undefined, other than that the seek should start from the current frequency until it reaches some limit. Halli, what does your hardware do? In particular, is the hwseek limited by the US/Europe or Japan band range or can it do the full range? If I'm not mistaken it is the former, right? You are right... my hardware seek is limited by the japan/US band range If it is the former, then you need to explicitly set low + high to ensure that the hwseek uses the correct range because the driver can't guess which of the overlapping bands to use. Yes in my driver I will take care of this :) I think you misunderstood Hans here, not the driver but userspace will need to fill in the rangelow / rangehigh fields of struct v4l2_hw_freq_seek, because if the current freq is in the overlapping area of the bands, the driver cannot know which band to seek, so it will just have to guess, I think it is best to just leave the band at its current setting in that case. The way the new API works (which was done this way to preserve backward compat) is that the bands returned from ENUM_BANDS are there as information only. userspace never explicitly sets a band, so an old app will just see the entire 76-108 MHZ range in the tuner struct and may do a S_FREQUENCY for any of those frequencies, and the driver must automatically switch bands when necessary. With S_HW_FREQ_SEEK we've the 2 new fields to indicate the band to seek for new apps, but with old apps these fields will be 0, and the driver needs to just pick a band to search on a best effort basis, for the si470x IE, if no band is specified in struct v4l2_hw_freq_seek, I simply always switch to the Japan wide band of 76-108 Mhz as that includes all other bands supported by the si470x. 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
[PATCH] Use a named union in struct v4l2_ioctl_info
Hi Mauro,
struct v4l2_ioctl_info uses an anonymous union, which is initialized
in the v4l2_ioctls table.
Unfortunately gcc 4.6 uses a non-standard syntax for that, so trying to
compile v4l2-ioctl.c with an older gcc will fail.
It is possible to work around this by testing the gcc version, but in this
case it is easier to make the union named since it is used in only a few
places.
Randy, Stephen, this patch should solve the v4l2-ioctl.c compilation problem
in linux-next. Since Mauro is still on holiday you'll have to apply it manually.
Regards,
Hans
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
diff --git a/drivers/media/video/v4l2-ioctl.c b/drivers/media/video/v4l2-ioctl.c
index 70e0efb..812beb0 100644
--- a/drivers/media/video/v4l2-ioctl.c
+++ b/drivers/media/video/v4l2-ioctl.c
@@ -1806,7 +1806,7 @@ struct v4l2_ioctl_info {
u32 offset;
int (*func)(const struct v4l2_ioctl_ops *ops,
struct file *file, void *fh, void *p);
- };
+ } u;
void (*debug)(const void *arg, bool write_only);
};
@@ -1831,7 +1831,7 @@ struct v4l2_ioctl_info {
.ioctl = _ioctl,\
.flags = _flags | INFO_FL_STD, \
.name = #_ioctl,\
- .offset = offsetof(struct v4l2_ioctl_ops, _vidioc), \
+ .u.offset = offsetof(struct v4l2_ioctl_ops, _vidioc), \
.debug = _debug,\
}
@@ -1840,7 +1840,7 @@ struct v4l2_ioctl_info {
.ioctl = _ioctl,\
.flags = _flags | INFO_FL_FUNC, \
.name = #_ioctl,\
- .func = _func, \
+ .u.func = _func,\
.debug = _debug,\
}
@@ -2038,11 +2038,11 @@ static long __video_do_ioctl(struct file *file,
if (info-flags INFO_FL_STD) {
typedef int (*vidioc_op)(struct file *file, void *fh, void *p);
const void *p = vfd-ioctl_ops;
- const vidioc_op *vidioc = p + info-offset;
+ const vidioc_op *vidioc = p + info-u.offset;
ret = (*vidioc)(file, fh, arg);
} else if (info-flags INFO_FL_FUNC) {
- ret = info-func(ops, file, fh, arg);
+ ret = info-u.func(ops, file, fh, arg);
} else if (!ops-vidioc_default) {
ret = -ENOTTY;
} else {
--
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 for 3.6] v4l: DocBook: fix version number typo
Signed-off-by: Nicolas Thery nicolas.th...@st.com --- Documentation/DocBook/media/v4l/compat.xml |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/DocBook/media/v4l/compat.xml b/Documentation/DocBook/media/v4l/compat.xml index 97b8951..e519ce6 100644 --- a/Documentation/DocBook/media/v4l/compat.xml +++ b/Documentation/DocBook/media/v4l/compat.xml @@ -2460,7 +2460,7 @@ that used it. It was originally scheduled for removal in 2.6.35. /section section - titleV4L2 in Linux 3.5/title + titleV4L2 in Linux 3.6/title orderedlist listitem paraReplaced structfieldinput/structfield in -- 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: [Ksummit-2012-discuss] Media system Summit
On Thu, Jul 12, 2012 at 10:08:04AM +0200, Sylwester Nawrocki wrote: I'd like to add a Common device tree bindings for media devices topic to the agenda for consideration. It'd be nice to get this to join up with ASoC... -- 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] Use a named union in struct v4l2_ioctl_info
On 07/12/2012 09:06 AM, Hans Verkuil wrote:
Hi Mauro,
struct v4l2_ioctl_info uses an anonymous union, which is initialized
in the v4l2_ioctls table.
Unfortunately gcc 4.6 uses a non-standard syntax for that, so trying to
compile v4l2-ioctl.c with an older gcc will fail.
It is possible to work around this by testing the gcc version, but in this
case it is easier to make the union named since it is used in only a few
places.
Randy, Stephen, this patch should solve the v4l2-ioctl.c compilation problem
in linux-next. Since Mauro is still on holiday you'll have to apply it
manually.
Regards,
Hans
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
Reported-by: Randy Dunlap rdun...@xenotime.net
Acked-by: Randy Dunlap rdun...@xenotime.net
Thanks.
diff --git a/drivers/media/video/v4l2-ioctl.c
b/drivers/media/video/v4l2-ioctl.c
index 70e0efb..812beb0 100644
--- a/drivers/media/video/v4l2-ioctl.c
+++ b/drivers/media/video/v4l2-ioctl.c
@@ -1806,7 +1806,7 @@ struct v4l2_ioctl_info {
u32 offset;
int (*func)(const struct v4l2_ioctl_ops *ops,
struct file *file, void *fh, void *p);
- };
+ } u;
void (*debug)(const void *arg, bool write_only);
};
@@ -1831,7 +1831,7 @@ struct v4l2_ioctl_info {
.ioctl = _ioctl,\
.flags = _flags | INFO_FL_STD, \
.name = #_ioctl,\
- .offset = offsetof(struct v4l2_ioctl_ops, _vidioc), \
+ .u.offset = offsetof(struct v4l2_ioctl_ops, _vidioc), \
.debug = _debug,\
}
@@ -1840,7 +1840,7 @@ struct v4l2_ioctl_info {
.ioctl = _ioctl,\
.flags = _flags | INFO_FL_FUNC, \
.name = #_ioctl,\
- .func = _func, \
+ .u.func = _func,\
.debug = _debug,\
}
@@ -2038,11 +2038,11 @@ static long __video_do_ioctl(struct file *file,
if (info-flags INFO_FL_STD) {
typedef int (*vidioc_op)(struct file *file, void *fh, void *p);
const void *p = vfd-ioctl_ops;
- const vidioc_op *vidioc = p + info-offset;
+ const vidioc_op *vidioc = p + info-u.offset;
ret = (*vidioc)(file, fh, arg);
} else if (info-flags INFO_FL_FUNC) {
- ret = info-func(ops, file, fh, arg);
+ ret = info-u.func(ops, file, fh, arg);
} else if (!ops-vidioc_default) {
ret = -ENOTTY;
} else {
--
--
~Randy
--
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: [Ksummit-2012-discuss] Media system Summit
On Thu, Jul 12, 2012 at 9:18 AM, Mark Brown broo...@opensource.wolfsonmicro.com wrote: On Thu, Jul 12, 2012 at 10:08:04AM +0200, Sylwester Nawrocki wrote: I'd like to add a Common device tree bindings for media devices topic to the agenda for consideration. It'd be nice to get this to join up with ASoC... There's a handful of various subsystems that have similar topics, maybe slice it the other way and do a device-tree/ACPI breakout that cuts across the various areas instead? Communication really needs to be two-way: Crafting good bindings for a complex piece of hardware isn't trivial and having someone know both the subsystem and device tree principles is rare. At least getting all those people into the same room would be good. There's obvious overlap with ARM here as well, since it's one of the current big pushers of DT use, but I think it would be better to hold this as a separate breakout from that. -Olof -- 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
RFC: Add support for limiting hw freq seeks to a certain band (v2)
This patchset, which builds on top of hverkuil's bands2 branch, which adds the VIDIOC_ENUM_FREQ_BANDS API, add support for limiting hw freq seeks to one of the bands from VIDIOC_ENUM_FREQ_BANDS, or a subset there of. The first patch introduces the new API and documents its, the other patches are patches to the si470x radio driver, implementing the new API, and removing the band module parameter as this is no longer needed with this new API. A git tree with all hverkuils patches included is here: http://git.linuxtv.org/hgoede/gspca.git/shortlog/refs/heads/media-for_v3.6-wip A git tree of xawtv3 with its radio app modified to support the new API is here: http://git.linuxtv.org/hgoede/xawtv3.git/shortlog/refs/heads/band-support Changes in v2: -improve / clarify the documentation on how the rangelow and rangehigh fields of the v4l2_hw_freq_seek struct are used 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
[PATCH 1/5] v4l2 spec: add VIDIOC_ENUM_FREQ_BANDS documentation.
From: Hans Verkuil hans.verk...@cisco.com Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- Documentation/DocBook/media/v4l/compat.xml | 12 ++ Documentation/DocBook/media/v4l/v4l2.xml |6 + .../DocBook/media/v4l/vidioc-enum-freq-bands.xml | 179 .../DocBook/media/v4l/vidioc-g-frequency.xml |7 +- Documentation/DocBook/media/v4l/vidioc-g-tuner.xml | 26 ++- 5 files changed, 221 insertions(+), 9 deletions(-) create mode 100644 Documentation/DocBook/media/v4l/vidioc-enum-freq-bands.xml diff --git a/Documentation/DocBook/media/v4l/compat.xml b/Documentation/DocBook/media/v4l/compat.xml index 97b8951..aa28015 100644 --- a/Documentation/DocBook/media/v4l/compat.xml +++ b/Documentation/DocBook/media/v4l/compat.xml @@ -2471,6 +2471,15 @@ that used it. It was originally scheduled for removal in 2.6.35. /orderedlist /section +section + titleV4L2 in Linux 3.6/title + orderedlist +listitem + paraAdded support for frequency band enumerations: VIDIOC-ENUM-FREQ-BANDS;./para +/listitem + /orderedlist +/section + section id=other titleRelation of V4L2 to other Linux multimedia APIs/title @@ -2600,6 +2609,9 @@ ioctls./para paralink linkend=v4l2-auto-focus-areaconstant V4L2_CID_AUTO_FOCUS_AREA/constant/link control./para /listitem +listitem + paraSupport for frequency band enumeration: VIDIOC-ENUM-FREQ-BANDS; ioctl./para +/listitem /itemizedlist /section diff --git a/Documentation/DocBook/media/v4l/v4l2.xml b/Documentation/DocBook/media/v4l/v4l2.xml index 36bafc4..eee6908 100644 --- a/Documentation/DocBook/media/v4l/v4l2.xml +++ b/Documentation/DocBook/media/v4l/v4l2.xml @@ -140,6 +140,11 @@ structs, ioctls) must be noted in more detail in the history chapter applications. -- revision + revnumber3.6/revnumber + date2012-07-02/date + authorinitialshv/authorinitials + revremarkAdded VIDIOC_ENUM_FREQ_BANDS. + /revremark revnumber3.5/revnumber date2012-05-07/date authorinitialssa, sn/authorinitials @@ -534,6 +539,7 @@ and discussions on the V4L mailing list./revremark sub-enum-fmt; sub-enum-framesizes; sub-enum-frameintervals; +sub-enum-freq-bands; sub-enuminput; sub-enumoutput; sub-enumstd; diff --git a/Documentation/DocBook/media/v4l/vidioc-enum-freq-bands.xml b/Documentation/DocBook/media/v4l/vidioc-enum-freq-bands.xml new file mode 100644 index 000..6541ba0 --- /dev/null +++ b/Documentation/DocBook/media/v4l/vidioc-enum-freq-bands.xml @@ -0,0 +1,179 @@ +refentry id=vidioc-enum-freq-bands + refmeta +refentrytitleioctl VIDIOC_ENUM_FREQ_BANDS/refentrytitle +manvol; + /refmeta + + refnamediv +refnameVIDIOC_ENUM_FREQ_BANDS/refname +refpurposeEnumerate supported frequency bands/refpurpose + /refnamediv + + refsynopsisdiv +funcsynopsis + funcprototype + funcdefint functionioctl/function/funcdef + paramdefint parameterfd/parameter/paramdef + paramdefint parameterrequest/parameter/paramdef + paramdefstruct v4l2_frequency_band +*parameterargp/parameter/paramdef + /funcprototype +/funcsynopsis + /refsynopsisdiv + + refsect1 +titleArguments/title + +variablelist + varlistentry + termparameterfd/parameter/term + listitem + parafd;/para + /listitem + /varlistentry + varlistentry + termparameterrequest/parameter/term + listitem + paraVIDIOC_ENUM_FREQ_BANDS/para + /listitem + /varlistentry + varlistentry + termparameterargp/parameter/term + listitem + para/para + /listitem + /varlistentry +/variablelist + /refsect1 + + refsect1 +titleDescription/title + +note + titleExperimental/title + paraThis is an link linkend=experimental experimental /link + interface and may change in the future./para +/note + +paraEnumerates the frequency bands that a tuner or modulator supports. +To do this applications initialize the structfieldtuner/structfield, +structfieldtype/structfield and structfieldindex/structfield fields, +and zero out the structfieldreserved/structfield array of a v4l2-frequency-band; and +call the constantVIDIOC_ENUM_FREQ_BANDS/constant ioctl with a pointer +to this structure./para + +paraThis ioctl is supported if the constantV4L2_TUNER_CAP_FREQ_BANDS/constant capability +of the corresponding tuner/modulator is set./para + +table pgwide=1 frame=none id=v4l2-frequency-band + titlestruct structnamev4l2_frequency_band/structname/title + tgroup cols=3 + cs-str; + tbody valign=top + row + entry__u32/entry + entrystructfieldtuner/structfield/entry + entryThe tuner or modulator index number. This is the +same value as in the v4l2-input;
[PATCH 2/5] v4l2: Add rangelow and rangehigh fields to the v4l2_hw_freq_seek struct
To allow apps to limit a hw-freq-seek to a specific band, for further
info see the documentation this patch adds for these new fields.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
.../DocBook/media/v4l/vidioc-s-hw-freq-seek.xml| 50
include/linux/videodev2.h |5 +-
2 files changed, 46 insertions(+), 9 deletions(-)
diff --git a/Documentation/DocBook/media/v4l/vidioc-s-hw-freq-seek.xml
b/Documentation/DocBook/media/v4l/vidioc-s-hw-freq-seek.xml
index f4db44d..3dd1bec 100644
--- a/Documentation/DocBook/media/v4l/vidioc-s-hw-freq-seek.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-s-hw-freq-seek.xml
@@ -52,11 +52,23 @@
paraStart a hardware frequency seek from the current frequency.
To do this applications initialize the structfieldtuner/structfield,
structfieldtype/structfield, structfieldseek_upward/structfield,
-structfieldspacing/structfield and
-structfieldwrap_around/structfield fields, and zero out the
-structfieldreserved/structfield array of a v4l2-hw-freq-seek; and
-call the constantVIDIOC_S_HW_FREQ_SEEK/constant ioctl with a pointer
-to this structure./para
+structfieldwrap_around/structfield, structfieldspacing/structfield,
+structfieldrangelow/structfield and structfieldrangehigh/structfield
+fields, and zero out the structfieldreserved/structfield array of a
+v4l2-hw-freq-seek; and call the constantVIDIOC_S_HW_FREQ_SEEK/constant
+ioctl with a pointer to this structure./para
+
+paraThe structfieldrangelow/structfield and
+structfieldrangehigh/structfield fields can be set to a non-zero value to
+tell the driver to search a specific band. If the v4l2-tuner;
+structfieldcapability/structfield field has the
+constantV4L2_TUNER_CAP_HWSEEK_PROG_LIM/constant flag set, these values
+must fall within one of the bands returned by VIDIOC-ENUM-FREQ-BANDS;. If
+the constantV4L2_TUNER_CAP_HWSEEK_PROG_LIM/constant flag is not set,
+then these values must exactly match those of one of the bands returned by
+VIDIOC-ENUM-FREQ-BANDS;. If the current frequency of the tuner does not fall
+within the selected band it will be clamped to fit in the band before the
+seek is started./para
paraIf an error is returned, then the original frequency will
be restored./para
@@ -102,7 +114,27 @@ field and the v4l2-tuner;
structfieldindex/structfield field./entry
/row
row
entry__u32/entry
- entrystructfieldreserved/structfield[7]/entry
+ entrystructfieldrangelow/structfield/entry
+ entryIf non-zero, the lowest tunable frequency of the band to
+search in units of 62.5 kHz, or if the v4l2-tuner;
+structfieldcapability/structfield field has the
+constantV4L2_TUNER_CAP_LOW/constant flag set, in units of 62.5 Hz.
+If structfieldrangelow/structfield is zero a reasonable default value
+is used./entry
+ /row
+ row
+ entry__u32/entry
+ entrystructfieldrangehigh/structfield/entry
+ entryIf non-zero, the highest tunable frequency of the band to
+search in units of 62.5 kHz, or if the v4l2-tuner;
+structfieldcapability/structfield field has the
+constantV4L2_TUNER_CAP_LOW/constant flag set, in units of 62.5 Hz.
+If structfieldrangehigh/structfield is zero a reasonable default value
+is used./entry
+ /row
+ row
+ entry__u32/entry
+ entrystructfieldreserved/structfield[5]/entry
entryReserved for future extensions. Applications
must set the array to zero./entry
/row
@@ -119,8 +151,10 @@ field and the v4l2-tuner;
structfieldindex/structfield field./entry
termerrorcodeEINVAL/errorcode/term
listitem
paraThe structfieldtuner/structfield index is out of
-bounds, the wrap_around value is not supported or the value in the
structfieldtype/structfield field is
-wrong./para
+bounds, the structfieldwrap_around/structfield value is not supported or
+one of the values in the structfieldtype/structfield,
+structfieldrangelow/structfield or structfieldrangehigh/structfield
+fields is wrong./para
/listitem
/varlistentry
varlistentry
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 9fa822a..1c6aa63 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -2029,6 +2029,7 @@ struct v4l2_modulator {
#define V4L2_TUNER_CAP_RDS_BLOCK_IO0x0100
#define V4L2_TUNER_CAP_RDS_CONTROLS0x0200
#define V4L2_TUNER_CAP_FREQ_BANDS 0x0400
+#define V4L2_TUNER_CAP_HWSEEK_PROG_LIM 0x0800
/* Flags for the 'rxsubchans' field */
#define V4L2_TUNER_SUB_MONO0x0001
@@ -2074,7 +2075,9 @@ struct v4l2_hw_freq_seek {
__u32 seek_upward;
__u32 wrap_around;
__u32 spacing;
- __u32 reserved[7];
+ __u32 rangelow;
+ __u32 rangehigh;
+ __u32 reserved[5];
};
/*
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
[PATCH 4/5] radio-si470x: Fix band selection
The mask was wrong resulting in band 0 and 1 always ending up as band 0 in the register. Signed-off-by: Hans de Goede hdego...@redhat.com --- drivers/media/radio/si470x/radio-si470x.h |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/radio/si470x/radio-si470x.h b/drivers/media/radio/si470x/radio-si470x.h index b3b612f..11f14b6 100644 --- a/drivers/media/radio/si470x/radio-si470x.h +++ b/drivers/media/radio/si470x/radio-si470x.h @@ -87,7 +87,7 @@ #define SYSCONFIG2 5 /* System Configuration 2 */ #define SYSCONFIG2_SEEKTH 0xff00 /* bits 15..08: RSSI Seek Threshold */ -#define SYSCONFIG2_BAND0x0080 /* bits 07..06: Band Select */ +#define SYSCONFIG2_BAND0x00c0 /* bits 07..06: Band Select */ #define SYSCONFIG2_SPACE 0x0030 /* bits 05..04: Channel Spacing */ #define SYSCONFIG2_VOLUME 0x000f /* bits 03..00: Volume */ -- 1.7.10.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 3/5] radio-si470x: restore ctrl settings after suspend/resume
Signed-off-by: Hans de Goede hdego...@redhat.com
---
drivers/media/radio/si470x/radio-si470x-usb.c |7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/media/radio/si470x/radio-si470x-usb.c
b/drivers/media/radio/si470x/radio-si470x-usb.c
index 40b963c..0204cf4 100644
--- a/drivers/media/radio/si470x/radio-si470x-usb.c
+++ b/drivers/media/radio/si470x/radio-si470x-usb.c
@@ -792,11 +792,16 @@ static int si470x_usb_driver_suspend(struct usb_interface
*intf,
static int si470x_usb_driver_resume(struct usb_interface *intf)
{
struct si470x_device *radio = usb_get_intfdata(intf);
+ int ret;
dev_info(intf-dev, resuming now...\n);
/* start radio */
- return si470x_start_usb(radio);
+ ret = si470x_start_usb(radio);
+ if (ret == 0)
+ v4l2_ctrl_handler_setup(radio-hdl);
+
+ return ret;
}
--
1.7.10.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 5/5] radio-si470x: Add support for the new band APIs
Signed-off-by: Hans de Goede hdego...@redhat.com
---
drivers/media/radio/si470x/radio-si470x-common.c | 215 +-
drivers/media/radio/si470x/radio-si470x-i2c.c|1 +
drivers/media/radio/si470x/radio-si470x-usb.c|1 +
drivers/media/radio/si470x/radio-si470x.h|1 +
4 files changed, 126 insertions(+), 92 deletions(-)
diff --git a/drivers/media/radio/si470x/radio-si470x-common.c
b/drivers/media/radio/si470x/radio-si470x-common.c
index 84ab3d57..9e38132 100644
--- a/drivers/media/radio/si470x/radio-si470x-common.c
+++ b/drivers/media/radio/si470x/radio-si470x-common.c
@@ -4,6 +4,7 @@
* Driver for radios with Silicon Labs Si470x FM Radio Receivers
*
* Copyright (c) 2009 Tobias Lorenz tobias.lor...@gmx.net
+ * Copyright (c) 2012 Hans de Goede hdego...@redhat.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
@@ -127,14 +128,6 @@ static unsigned short space = 2;
module_param(space, ushort, 0444);
MODULE_PARM_DESC(space, Spacing: 0=200kHz 1=100kHz *2=50kHz*);
-/* Bottom of Band (MHz) */
-/* 0: 87.5 - 108 MHz (USA, Europe)*/
-/* 1: 76 - 108 MHz (Japan wide band) */
-/* 2: 76 - 90 MHz (Japan) */
-static unsigned short band = 1;
-module_param(band, ushort, 0444);
-MODULE_PARM_DESC(band, Band: 0=87.5..108MHz *1=76..108MHz* 2=76..90MHz);
-
/* De-emphasis */
/* 0: 75 us (USA) */
/* 1: 50 us (Europe, Australia, Japan) */
@@ -152,13 +145,61 @@ static unsigned int seek_timeout = 5000;
module_param(seek_timeout, uint, 0644);
MODULE_PARM_DESC(seek_timeout, Seek timeout: *5000*);
-
+static const struct v4l2_frequency_band bands[] = {
+ {
+ .type = V4L2_TUNER_RADIO,
+ .index = 0,
+ .capability = V4L2_TUNER_CAP_LOW | V4L2_TUNER_CAP_STEREO |
+ V4L2_TUNER_CAP_RDS | V4L2_TUNER_CAP_RDS_BLOCK_IO |
+ V4L2_TUNER_CAP_HWSEEK_BOUNDED |
+ V4L2_TUNER_CAP_HWSEEK_WRAP,
+ .rangelow = 87500 * 16,
+ .rangehigh = 108000 * 16,
+ .modulation = V4L2_BAND_MODULATION_FM,
+ },
+ {
+ .type = V4L2_TUNER_RADIO,
+ .index = 1,
+ .capability = V4L2_TUNER_CAP_LOW | V4L2_TUNER_CAP_STEREO |
+ V4L2_TUNER_CAP_RDS | V4L2_TUNER_CAP_RDS_BLOCK_IO |
+ V4L2_TUNER_CAP_HWSEEK_BOUNDED |
+ V4L2_TUNER_CAP_HWSEEK_WRAP,
+ .rangelow = 76000 * 16,
+ .rangehigh = 108000 * 16,
+ .modulation = V4L2_BAND_MODULATION_FM,
+ },
+ {
+ .type = V4L2_TUNER_RADIO,
+ .index = 2,
+ .capability = V4L2_TUNER_CAP_LOW | V4L2_TUNER_CAP_STEREO |
+ V4L2_TUNER_CAP_RDS | V4L2_TUNER_CAP_RDS_BLOCK_IO |
+ V4L2_TUNER_CAP_HWSEEK_BOUNDED |
+ V4L2_TUNER_CAP_HWSEEK_WRAP,
+ .rangelow = 76000 * 16,
+ .rangehigh = 9 * 16,
+ .modulation = V4L2_BAND_MODULATION_FM,
+ },
+};
/**
* Generic Functions
**/
/*
+ * si470x_set_band - set the band
+ */
+static int si470x_set_band(struct si470x_device *radio, int band)
+{
+ if (radio-band == band)
+ return 0;
+
+ radio-band = band;
+ radio-registers[SYSCONFIG2] = ~SYSCONFIG2_BAND;
+ radio-registers[SYSCONFIG2] |= radio-band 6;
+ return si470x_set_register(radio, SYSCONFIG2);
+}
+
+/*
* si470x_set_chan - set the channel
*/
static int si470x_set_chan(struct si470x_device *radio, unsigned short chan)
@@ -194,48 +235,39 @@ done:
return retval;
}
-
/*
- * si470x_get_freq - get the frequency
+ * si470x_get_step - get channel spacing
*/
-static int si470x_get_freq(struct si470x_device *radio, unsigned int *freq)
+static unsigned int si470x_get_step(struct si470x_device *radio)
{
- unsigned int spacing, band_bottom;
- unsigned short chan;
- int retval;
-
/* Spacing (kHz) */
switch ((radio-registers[SYSCONFIG2] SYSCONFIG2_SPACE) 4) {
/* 0: 200 kHz (USA, Australia) */
case 0:
- spacing = 0.200 * FREQ_MUL; break;
+ return 200 * 16;
/* 1: 100 kHz (Europe, Japan) */
case 1:
- spacing = 0.100 * FREQ_MUL; break;
+ return 100 * 16;
/* 2: 50 kHz */
default:
- spacing = 0.050 * FREQ_MUL; break;
+ return 50 * 16;
};
+}
- /* Bottom of Band (MHz) */
- switch ((radio-registers[SYSCONFIG2] SYSCONFIG2_BAND) 6) {
- /* 0: 87.5 - 108 MHz (USA, Europe) */
- case 0:
-
Re: [Ksummit-2012-discuss] Media system Summit
On Thu, 12 Jul 2012, Hans Verkuil wrote: On Thu July 12 2012 18:48:23 Olof Johansson wrote: On Thu, Jul 12, 2012 at 9:18 AM, Mark Brown broo...@opensource.wolfsonmicro.com wrote: On Thu, Jul 12, 2012 at 10:08:04AM +0200, Sylwester Nawrocki wrote: I'd like to add a Common device tree bindings for media devices topic to the agenda for consideration. It'd be nice to get this to join up with ASoC... There's a handful of various subsystems that have similar topics, maybe slice it the other way and do a device-tree/ACPI breakout that cuts across the various areas instead? Communication really needs to be two-way: Crafting good bindings for a complex piece of hardware isn't trivial and having someone know both the subsystem and device tree principles is rare. At least getting all those people into the same room would be good. I'm not so sure: I think that most decisions that need to be made are quite subsystem specific. Trying to figure out how to implement DT for multiple subsystems in one workshop seems unlikely to succeed, simply because of lack of time. I also don't think there is much overlap between subsystems in this respect, so while the DT implementation for one subsystem is discussed, the representatives of other subsystems are twiddling their thumbs. It might be more productive to have one or two DT experts around who rotate over the various workshops that have to deal with the DT and can offer advice. I'm sure everyone has seen this, but just to have it mentioned here: a href=http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/50755; shameless self-advertisement/a I'm not sure whether the overlap with other subsystems is large or not, but there definitely is some, also with video (fbdev / drm), e.g., http://thread.gmane.org/gmane.linux.drivers.devicetree/17495 As for whether or not discuss DT for various subsystems together - why not do both? First short sessions in each subsystems, of course, this would only work if proposals have been prepared beforehand and at least preliminary discussions on the MLs have taken place, and then another (also short) combined session? Of course, it also depends on how much time we can and want to dedicate to this. Thanks Guennadi Regards, Hans There's obvious overlap with ARM here as well, since it's one of the current big pushers of DT use, but I think it would be better to hold this as a separate breakout from that. -Olof -- 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 --- 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: GPIO interface between DVB sub-drivers (bridge, demod, tuner)
Resend in plaintext, it got bounced from vger. On Thu, Jul 12, 2012 at 4:49 PM, Steven Toth st...@kernellabs.com wrote: Is there anyone who could say straight now what is best approach and where to look example? I don't have an answer but the topic does interest me. :) Nobody understands the relationship between the bridge and the sub-component as well as the bridge driver. The current interfaces are limiting in many ways. We solve that today with rather ugly 'attach' structures that are inflexible, for example to set gpios to a default state. Then, once that interface is attached, the bridge effectively loses most of the control to the tuner and/or demod. The result is a large disconnect between the bridge and subcomponents. Why limit any interface extension to GPIOs? Why not make something a little more flexible so we can pass custom messages around? get(int parm, *value) and set(int parm, value) Bridges and demods can define whatever parmid's they like in their attach headers. (Like we do for callbacks currently). For example, some tuners have temperature sensors, I have no ability to read that today from the bridge, other than via I2C - then I'm pulling i2c device specific logic into the bridge. :( It would be nice to be able to demod/tunerptr-get(XC5000_PARAM_TEMP, value), for example. Get/Set I/F is a bit of a classic, between tuners and video decoders. This (at least a while ago) was poorly handled, or not at all. Only the bridge really knows how to deal with odd component configurations like this, yet it has little or no control. I'd want to see a list of 4 or 5 good get/set use cases though, with some unusual parms, before I'd really believe a generic get/set is more appropriate than a strongly typed set of additional function pointers. What did you ever decide about the enable/disable of the LNA? And, how would the bridge do that in your proposed solution? Via the proposed GPIO interface? Regards, -- Steven Toth - Kernel Labs http://www.kernellabs.com +1.646.355.8490 -- 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 v4] media: Add stk1160 new driver
Hans, On Tue, Jul 10, 2012 at 3:39 AM, Hans Verkuil hverk...@xs4all.nl wrote: Take a look at the latest videobuf2-core.h: I've added helper functions that check the owner. You can probably simplify the driver code quite a bit by using those helpers. Indeed, using latest vb2_xxx_fop and vb2_ioctl_xxx the driver can be heavily reduced. (Great work, by the way) Almost every function looks like a direct replacement, except for mmap. If you look at current stk1160, I'm taking the lock for mmap: mutex_lock(dev-v4l_lock); rc = vb2_mmap(dev-vb_vidq, vma); mutex_unlock(dev-v4l_lock); However, vb2_fop_mmap does no locking. I'm having a hard time understanding why this is not needed, perhaps you could clarify this a bit? Thanks, Ezequiel. -- 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: GPIO interface between DVB sub-drivers (bridge, demod, tuner)
On 07/13/2012 12:07 AM, Steven Toth wrote: Resend in plaintext, it got bounced from vger. On Thu, Jul 12, 2012 at 4:49 PM, Steven Toth st...@kernellabs.com wrote: Is there anyone who could say straight now what is best approach and where to look example? I don't have an answer but the topic does interest me. :) Nobody understands the relationship between the bridge and the sub-component as well as the bridge driver. The current interfaces are limiting in many ways. We solve that today with rather ugly 'attach' structures that are inflexible, for example to set gpios to a default state. Then, once that interface is attached, the bridge effectively loses most of the control to the tuner and/or demod. The result is a large disconnect between the bridge and subcomponents. I agree that mostly. For example that GPIO. It fits very poorly for interfaces that are highly given hardware design dependent like GPIOs. You can code logic like GPIO0 is LED, GPIO0 is tuner reset, GPIO0 is LNA and then set that logic in attach(). Due to that I am looking for better alternative. Why limit any interface extension to GPIOs? Why not make something a little more flexible so we can pass custom messages around? get(int parm, *value) and set(int parm, value) Bridges and demods can define whatever parmid's they like in their attach headers. (Like we do for callbacks currently). For example, some tuners have temperature sensors, I have no ability to read that today from the bridge, other than via I2C - then I'm pulling i2c device specific logic into the bridge. :( Yes! indeed, it is only possibly just like you said. Fortunately this kind of properties are not very common. Temperature is offered by many tuners, but there is no much need for that info in bridge. Maybe force sleep or switch powers totally off by using GPIO to prevent overheat. It would be nice to be able to demod/tunerptr-get(XC5000_PARAM_TEMP, value), for example. Get/Set I/F is a bit of a classic, between tuners and video decoders. This (at least a while ago) was poorly handled, or not at all. Only the bridge really knows how to deal with odd component configurations like this, yet it has little or no control. IF information is now set tuner on attach() and then tuner delivers that info to demodulator via .get_if_frequency() which is member of tuner ops. Technically that solution works. If hardware design based IFs are not given as parameter on tuner attach() tuner should use tuner default IFs which are likely quite correct. I'd want to see a list of 4 or 5 good get/set use cases though, with some unusual parms, before I'd really believe a generic get/set is more appropriate than a strongly typed set of additional function pointers. Generally speaking for that set/get, I sent mail about ~same issue yesterday. http://www.spinics.net/lists/linux-media/msg50202.html There is set_property() and get_property() callbacks defined for FE already. But those are not used. My opinion is that those callbacks should be changed to deliver data for demodulator and for tuner too instead of current method - which is common huge properties cache structure shared between all sub-drivers. I don't like it all as it is stupid to add stuff that common structure for every standard we has. Lets take example device that supports DVB-C and other device supports ISDB-T. How many common parameters we has? I think only one - frequency. All the others are just waste. What I think I am going to make new RFC which changes that so every parameter from userspace is passed to the demodulator driver (using set_property() - change it current functionality) and not cached to the common cache at all. Shortly: change current common cache based parameter transmission to happen set parameter to demodulator one by one. What did you ever decide about the enable/disable of the LNA? And, how would the bridge do that in your proposed solution? Via the proposed GPIO interface? I sent PATCH RFC for DVB API to add LNA support yesterday. It is new API parameter. User could select ON/OFF/AUTO and on AUTO mode driver should make decision, likely taking signal measurements etc. New callback is added for frontend. If bridge likes to handle LNA it sets that callback in order to get user requests. When bridge gets that set_lna() callback it examines what user request and likely sets GPIOs. 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
Device-tree cross-subsystem binding workshop [was Media system Summit]
On Thu, Jul 12, 2012 at 12:03 PM, Hans Verkuil hverk...@xs4all.nl wrote: On Thu July 12 2012 18:48:23 Olof Johansson wrote: On Thu, Jul 12, 2012 at 9:18 AM, Mark Brown broo...@opensource.wolfsonmicro.com wrote: On Thu, Jul 12, 2012 at 10:08:04AM +0200, Sylwester Nawrocki wrote: I'd like to add a Common device tree bindings for media devices topic to the agenda for consideration. It'd be nice to get this to join up with ASoC... There's a handful of various subsystems that have similar topics, maybe slice it the other way and do a device-tree/ACPI breakout that cuts across the various areas instead? Communication really needs to be two-way: Crafting good bindings for a complex piece of hardware isn't trivial and having someone know both the subsystem and device tree principles is rare. At least getting all those people into the same room would be good. I'm not so sure: I think that most decisions that need to be made are quite subsystem specific. Trying to figure out how to implement DT for multiple subsystems in one workshop seems unlikely to succeed, simply because of lack of time. I also don't think there is much overlap between subsystems in this respect, so while the DT implementation for one subsystem is discussed, the representatives of other subsystems are twiddling their thumbs. It might be more productive to have one or two DT experts around who rotate over the various workshops that have to deal with the DT and can offer advice. One of the real problems right now is the lack of DT reviewers and general reviewer fatigue. In particular, many of the proposed bindings tend to have the same issues (focusing too much on how the platform_data is structured today and not on what the hardware actually is), and a few other similar things. Based on that I don't think it's a better solution to have the same few people walk from room to room to cover the same thing multiple times. No one has to sit there the whole day and listen on it all, but for those who are genuinely interested in how other subsystems will handle these bindings, I think it would be very useful to learn from how they made their decisions. Don't work in a vacuum, etc. So, I'd like to formally propose this as a mini-summit or workshop or whatever you might want to call it. I can help organize it together with Rob and Grant if needed (especially since Grant has a lot of other things going on at the moment). If there's insufficent interest to do this as a separate event we can try to accomodate for it as part of the ARM mini-summit, but squeezing all of that in with the rest of the ARM activities in one day will be hard. -Olof -- 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] Use a named union in struct v4l2_ioctl_info
Hi Hans, On Thu, 12 Jul 2012 18:06:24 +0200 Hans Verkuil hverk...@xs4all.nl wrote: struct v4l2_ioctl_info uses an anonymous union, which is initialized in the v4l2_ioctls table. Unfortunately gcc 4.6 uses a non-standard syntax for that, so trying to compile v4l2-ioctl.c with an older gcc will fail. It is possible to work around this by testing the gcc version, but in this case it is easier to make the union named since it is used in only a few places. Randy, Stephen, this patch should solve the v4l2-ioctl.c compilation problem in linux-next. Since Mauro is still on holiday you'll have to apply it manually. I have added this as a merge fix for today. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpSuVrtLAYNM.pgp Description: PGP signature
Re: [Ksummit-2012-discuss] Media system Summit
On Thu, Jul 12, 2012 at 2:05 PM, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: On Thu, 12 Jul 2012, Hans Verkuil wrote: On Thu July 12 2012 18:48:23 Olof Johansson wrote: On Thu, Jul 12, 2012 at 9:18 AM, Mark Brown broo...@opensource.wolfsonmicro.com wrote: On Thu, Jul 12, 2012 at 10:08:04AM +0200, Sylwester Nawrocki wrote: I'd like to add a Common device tree bindings for media devices topic to the agenda for consideration. It'd be nice to get this to join up with ASoC... There's a handful of various subsystems that have similar topics, maybe slice it the other way and do a device-tree/ACPI breakout that cuts across the various areas instead? Communication really needs to be two-way: Crafting good bindings for a complex piece of hardware isn't trivial and having someone know both the subsystem and device tree principles is rare. At least getting all those people into the same room would be good. I'm not so sure: I think that most decisions that need to be made are quite subsystem specific. Trying to figure out how to implement DT for multiple subsystems in one workshop seems unlikely to succeed, simply because of lack of time. I also don't think there is much overlap between subsystems in this respect, so while the DT implementation for one subsystem is discussed, the representatives of other subsystems are twiddling their thumbs. It might be more productive to have one or two DT experts around who rotate over the various workshops that have to deal with the DT and can offer advice. I'm sure everyone has seen this, but just to have it mentioned here: a href=http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/50755; shameless self-advertisement/a I hadn't seen it, since you didn't cc devicetree-discuss. Well, I'm also generally behind on list email right now since I am travelling but I couldn't find it in any list folder I subscribe to. As for whether or not discuss DT for various subsystems together - why not do both? First short sessions in each subsystems, of course, this would only work if proposals have been prepared beforehand and at least preliminary discussions on the MLs have taken place, and then another (also short) combined session? Of course, it also depends on how much time we can and want to dedicate to this. The agenda for such a day should probably be partially broken down per subsystem, yes, and it would make sense for people from the various areas to describe the kind of setup that they need to be able to define, similar to how you did in your writeup above. In some cases it would be a matter of in-person review/discussion/arguments of already proposed bindings, in other cases it would probably be a seeding discussion for upcoming bindings instead. Having the latter piggy-back on hearing what's discussed with the former category would likely be a good idea. -Olof -- 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: OMAP4 support
Hi Gary, On Tue, Jul 10, 2012 at 2:31 PM, Gary Thomas g...@mlbassoc.com wrote: On 2012-07-10 11:05, Chris Lalancette wrote: On Tue, Jul 10, 2012 at 9:41 AM, Gary Thomas g...@mlbassoc.com wrote: I'm looking for video support on OMAP4 platforms. I've found the PandaBoard camera project (http://www.omappedia.org/wiki/PandaBoard_Camera_Support) and this is starting to work. That said, I'm having some issues with setting up the pipeline, etc. Can this list help out? I'm not sure exactly what kind of cameras you want to get working, but if you are looking to get CSI2 cameras going through the ISS, Sergio Aguirre has been working on support. He also works on the media-ctl tool, which is used for configuring the media framework pipeline. The latest versions that I am aware of are here: git://gitorious.org/omap4-v4l2-camera/omap4-v4l2-camera.git Yes, this is the tree I've been working with (pointed to by the page I mentioned). My kernel can see the camera OV5650 and set up the pipeline. I am able to grab the raw SGRBG10 data but I'd like to get the ISS to convert this to a more usable UYVY format. Here's what I tried: media-ctl -r media-ctl -l 'OMAP4 ISS CSI2a:1 - OMAP4 ISS ISP IPIPEIF:0 [1]' media-ctl -l 'OMAP4 ISS ISP IPIPEIF:1 - OMAP4 ISS ISP IPIPEIF output:0 [1]' media-ctl -f 'ov5650 3-0036:0 [SGRBG10 2592x1944]' media-ctl -f 'OMAP4 ISS CSI2a:0 [SGRBG10 2592x1944]' media-ctl -f 'OMAP4 ISS ISP IPIPEIF:0 [SGRBG10 2592x1944]','OMAP4 ISS ISP IPIPEIF:1 [UYVY 2592x1944]' Sadly, I can't get the IPIPEIF element to take SGRGB10 in and put UYVY out (my reading of the manual implies that this _should_ be possible). I always see this pipeline setup: - entity 5: OMAP4 ISS ISP IPIPEIF (3 pads, 4 links) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev2 pad0: Input [SGRBG10 2592x1944] - 'OMAP4 ISS CSI2a':pad1 [ACTIVE] - 'OMAP4 ISS CSI2b':pad1 [] pad1: Output [SGRBG10 2592x1944] - 'OMAP4 ISS ISP IPIPEIF output':pad0 [ACTIVE] pad2: Output [SGRBG10 2592x1944] - 'OMAP4 ISS ISP resizer':pad0 [] Am I missing something? How can I make this conversion in the ISS? The core problem is that, i haven't published any support for RAW10-YUV conversion, which is part of the IPIPE module (not the IPIPEIF, like you mention). I had some patches, but sadly it is unfinished work. :/ Now, there's a main non-technical problem... I no longer work at TI since end of June this year, and I don't have the right HW setup available anymore. Those sensors were company's asset, and I couldn't keep any. Now, we can make this work with cooperation of someone who has the right setup, and me sharing my patches and some advice on my experience. What do you think? Note: if this is not the appropriate place to ask these questions, please redirect me (hopefully to a useful list :-) As I'm the main person who has been actively developing this, I'm your guy to ask questions :). By the way, this development has been my initiative the whole time, and not an official TI objective, so, to be honest, asking TI for official support won't help much right now. Regards, Sergio Thanks -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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
Getting a webcam to work
It's labelled V-Gear TalkCamPro from lsusb: Bus 001 Device 012: ID eb1a:2711 eMPIA Technology, Inc. and: /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci_hcd/5p, 480M |__ Port 1: Dev 2, If 0, Class=hub, Driver=hub/7p, 480M |__ Port 1: Dev 12, If 0, Class=vend., Driver=, 480M |__ Port 1: Dev 12, If 1, Class=audio, Driver=snd-usb-audio, 480M |__ Port 1: Dev 12, If 2, Class=audio, Driver=snd-usb-audio, 480M It looks like the audio part is recognised, but the video not. I see in http://lxr.linux.no/linux+*/drivers/media/video/em28xx/em28xx-cards.c that product ids 2710, 2750 and 2751 are recognised by the driver, but not 2711. I'm tempted to add it as a EM2800_BOARD_UNKNOWN and see if it works. Is there some methodology I should follow to get a new webcam to work? Thanks, Alex PS. I'm not subscribed. -- 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: Device-tree cross-subsystem binding workshop [was Media system Summit]
On 07/12/2012 08:20 PM, Olof Johansson wrote: On Thu, Jul 12, 2012 at 12:03 PM, Hans Verkuil hverk...@xs4all.nl wrote: On Thu July 12 2012 18:48:23 Olof Johansson wrote: On Thu, Jul 12, 2012 at 9:18 AM, Mark Brown broo...@opensource.wolfsonmicro.com wrote: On Thu, Jul 12, 2012 at 10:08:04AM +0200, Sylwester Nawrocki wrote: I'd like to add a Common device tree bindings for media devices topic to the agenda for consideration. It'd be nice to get this to join up with ASoC... There's a handful of various subsystems that have similar topics, maybe slice it the other way and do a device-tree/ACPI breakout that cuts across the various areas instead? Communication really needs to be two-way: Crafting good bindings for a complex piece of hardware isn't trivial and having someone know both the subsystem and device tree principles is rare. At least getting all those people into the same room would be good. I'm not so sure: I think that most decisions that need to be made are quite subsystem specific. Trying to figure out how to implement DT for multiple subsystems in one workshop seems unlikely to succeed, simply because of lack of time. I also don't think there is much overlap between subsystems in this respect, so while the DT implementation for one subsystem is discussed, the representatives of other subsystems are twiddling their thumbs. It might be more productive to have one or two DT experts around who rotate over the various workshops that have to deal with the DT and can offer advice. One of the real problems right now is the lack of DT reviewers and general reviewer fatigue. In particular, many of the proposed bindings tend to have the same issues (focusing too much on how the platform_data is structured today and not on what the hardware actually is), and a few other similar things. Agreed. It's hard to review things spanning across all subsystems and define something which works well across platforms. Often within a single subsystem we repeat things as platforms one by one convert to DT. On the other hand, I guess re-occurring review issues is a common problem across the kernel. Perhaps part of the issue is we're trying to put too much into DT? It's unfortunate that other than the recovering PPC developers now working on ARM, there has not been a lot of review from folks that have worked with DT for a bit longer. Based on that I don't think it's a better solution to have the same few people walk from room to room to cover the same thing multiple times. No one has to sit there the whole day and listen on it all, but for those who are genuinely interested in how other subsystems will handle these bindings, I think it would be very useful to learn from how they made their decisions. Don't work in a vacuum, etc. So, I'd like to formally propose this as a mini-summit or workshop or whatever you might want to call it. I can help organize it together with Rob and Grant if needed (especially since Grant has a lot of other things going on at the moment). If there's insufficent interest to do this as a separate event we can try to accomodate for it as part of the ARM mini-summit, but squeezing all of that in with the rest of the ARM activities in one day will be hard. I happy to help organize it. I think keeping it separate from ARM mini-summit is better otherwise we may end up with somewhat the same group of ARM developers as past DT discussions. Rob -Olof -- 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
