[PATCH] media: rc: Add support to decode Remotes using NECx IR protocol
Some remotes use NECx IR protocol to send remote control key events. Present nec decoder in rc framework is assuming to have 2 stop bits (pulse width of 560us space width 5600us) in NECx, but in reality NECx sends only pulse of 560us and space untill next frame.So here we can ignore the space width in stop bit as it is variable. Signed-off-by: Ravi Kumar V kumar...@codeaurora.org --- drivers/media/rc/ir-nec-decoder.c |6 +- 1 files changed, 5 insertions(+), 1 deletions(-) diff --git a/drivers/media/rc/ir-nec-decoder.c b/drivers/media/rc/ir-nec-decoder.c index 3c9431a..a3fe1c8 100644 --- a/drivers/media/rc/ir-nec-decoder.c +++ b/drivers/media/rc/ir-nec-decoder.c @@ -149,6 +149,10 @@ static int ir_nec_decode(struct rc_dev *dev, struct ir_raw_event ev) break; data-state = STATE_TRAILER_SPACE; + + if (data-is_nec_x) + goto rc_data; + return 0; case STATE_TRAILER_SPACE: @@ -157,7 +161,7 @@ static int ir_nec_decode(struct rc_dev *dev, struct ir_raw_event ev) if (!geq_margin(ev.duration, NEC_TRAILER_SPACE, NEC_UNIT / 2)) break; - +rc_data: address = bitrev8((data-bits 24) 0xff); not_address = bitrev8((data-bits 16) 0xff); command = bitrev8((data-bits 8) 0xff); -- Sent by a consultant of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- 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] [media] s5k6aa: Use devm_kzalloc function
devm_kzalloc() eliminates the need to free explicitly thereby making the code a bit simpler. Signed-off-by: Sachin Kamat sachin.ka...@linaro.org --- drivers/media/video/s5k6aa.c |7 ++- 1 files changed, 2 insertions(+), 5 deletions(-) diff --git a/drivers/media/video/s5k6aa.c b/drivers/media/video/s5k6aa.c index 6625e46..0c3bc58 100644 --- a/drivers/media/video/s5k6aa.c +++ b/drivers/media/video/s5k6aa.c @@ -1568,7 +1568,7 @@ static int s5k6aa_probe(struct i2c_client *client, return -EINVAL; } - s5k6aa = kzalloc(sizeof(*s5k6aa), GFP_KERNEL); + s5k6aa = devm_kzalloc(client-dev, sizeof(*s5k6aa), GFP_KERNEL); if (!s5k6aa) return -ENOMEM; @@ -1592,7 +1592,7 @@ static int s5k6aa_probe(struct i2c_client *client, sd-entity.type = MEDIA_ENT_T_V4L2_SUBDEV_SENSOR; ret = media_entity_init(sd-entity, 1, s5k6aa-pad, 0); if (ret) - goto out_err1; + return ret; ret = s5k6aa_configure_gpios(s5k6aa, pdata); if (ret) @@ -1627,8 +1627,6 @@ out_err3: s5k6aa_free_gpios(s5k6aa); out_err2: media_entity_cleanup(s5k6aa-sd.entity); -out_err1: - kfree(s5k6aa); return ret; } @@ -1642,7 +1640,6 @@ static int s5k6aa_remove(struct i2c_client *client) media_entity_cleanup(sd-entity); regulator_bulk_free(S5K6AA_NUM_SUPPLIES, s5k6aa-supplies); s5k6aa_free_gpios(s5k6aa); - kfree(s5k6aa); return 0; } -- 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
[PATCH 2/2] [media] s5k6aa: Add missing static storage class specifier
Fixes the following sparse warning:
drivers/media/video/s5k6aa.c:1439:5: warning:
symbol 's5k6aa_check_fw_revision' was not declared. Should it be static?
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
drivers/media/video/s5k6aa.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/s5k6aa.c b/drivers/media/video/s5k6aa.c
index 0c3bc58..045ca7f 100644
--- a/drivers/media/video/s5k6aa.c
+++ b/drivers/media/video/s5k6aa.c
@@ -1436,7 +1436,7 @@ static int s5k6aa_open(struct v4l2_subdev *sd, struct
v4l2_subdev_fh *fh)
return 0;
}
-int s5k6aa_check_fw_revision(struct s5k6aa *s5k6aa)
+static int s5k6aa_check_fw_revision(struct s5k6aa *s5k6aa)
{
struct i2c_client *client = v4l2_get_subdevdata(s5k6aa-sd);
u16 api_ver = 0, fw_rev = 0;
--
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: [Workshop-2011] Media summit at the Kernel Summit - was: Fwd: Re: [Ksummit-2012-discuss] Organising Mini Summits within the Kernel Summit
On Wed, 25 Jul 2012 08:21:05 +0200, Hans Verkuil hverk...@xs4all.nl wrote: On Tue July 24 2012 22:37:35 Rémi Denis-Courmont wrote: Le mardi 24 juillet 2012 23:31:42 Andy Walls, vous avez écrit : I would strongly be in favor of this. One thing that we get far to little of is feedback from actual userland developers making use of the V4L and DVB interfaces (aside from the SoC vendors, which is a completely different target audience than the traditional V4L and DVB consumers) Devin Ditto. Input from user application developers is something that kernel developers need and value greatly. Note, that I will not be at the workshop of Plumbers this year. :( Is the media summit timed with LPC or the kernel summit? If I come, I have to leave on Thursday to catch the VideoLAN conference in Paris on the next week- end... It's timed with the kernel summit and it will be on Tuesday. So you should have ample time. Oh? Is this firm yet? There's some pressure to book flights early here... -- Rémi Denis-Courmont Sent from my collocated server -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL] video_visstrim for 3.6
Hi Mauro, this pull request is composed of two series that provide support for two mem2mem devices: - 'm2m-deinterlace' video deinterlacer - 'coda video codec' I've included platform support for them too. The following changes since commit 6887a4131da3adaab011613776d865f4bcfb5678: Linux 3.5-rc5 (2012-06-30 16:08:57 -0700) are available in the git repository at: https://github.com/jmartinc/video_visstrim.git for_3.6 for you to fetch changes up to 9bb10266da63ae7f8f198573e099580e9f98f4e8: i.MX27: Visstrim_M10: Add support for deinterlacing driver. (2012-07-26 10:57:30 +0200) Javier Martin (5): i.MX: coda: Add platform support for coda in i.MX27. media: coda: Add driver for Coda video codec. Visstrim M10: Add support for Coda. media: Add mem2mem deinterlacing driver. i.MX27: Visstrim_M10: Add support for deinterlacing driver. arch/arm/mach-imx/clk-imx27.c |4 +- arch/arm/mach-imx/devices-imx27.h |4 + arch/arm/mach-imx/mach-imx27_visstrim_m10.c | 49 +- arch/arm/plat-mxc/devices/Kconfig |6 +- arch/arm/plat-mxc/devices/Makefile |1 + arch/arm/plat-mxc/devices/platform-imx27-coda.c | 37 + arch/arm/plat-mxc/include/mach/devices-common.h |8 + drivers/media/video/Kconfig | 17 + drivers/media/video/Makefile|3 + drivers/media/video/coda.c | 1848 +++ drivers/media/video/coda.h | 216 +++ drivers/media/video/m2m-deinterlace.c | 1119 ++ 12 files changed, 3305 insertions(+), 7 deletions(-) create mode 100644 arch/arm/plat-mxc/devices/platform-imx27-coda.c create mode 100644 drivers/media/video/coda.c create mode 100644 drivers/media/video/coda.h create mode 100644 drivers/media/video/m2m-deinterlace.c Thanks, Javier. -- 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: [Workshop-2011] Media summit at the Kernel Summit - was: Fwd: Re: [Ksummit-2012-discuss] Organising Mini Summits within the Kernel Summit
On Thu 26 July 2012 11:32:56 Rémi Denis-Courmont wrote: On Wed, 25 Jul 2012 08:21:05 +0200, Hans Verkuil hverk...@xs4all.nl wrote: On Tue July 24 2012 22:37:35 Rémi Denis-Courmont wrote: Le mardi 24 juillet 2012 23:31:42 Andy Walls, vous avez écrit : I would strongly be in favor of this. One thing that we get far to little of is feedback from actual userland developers making use of the V4L and DVB interfaces (aside from the SoC vendors, which is a completely different target audience than the traditional V4L and DVB consumers) Devin Ditto. Input from user application developers is something that kernel developers need and value greatly. Note, that I will not be at the workshop of Plumbers this year. :( Is the media summit timed with LPC or the kernel summit? If I come, I have to leave on Thursday to catch the VideoLAN conference in Paris on the next week- end... It's timed with the kernel summit and it will be on Tuesday. So you should have ample time. Oh? Is this firm yet? There's some pressure to book flights early here... Yes, that's firm. 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 v2 0/4] Use dma_mmap_coherent to support IOMMU mapper
There is a dma_mmap_coherent() API in some architectures. This API provides a mmap function for memory allocated by dma_alloc_coherent(). Some drivers mmap a dma_addr_t returned by dma_alloc_coherent() as a physical address. But such drivers do not work correctly when IOMMU mapper is used. v2: - Rebase on fbdev-next branch of git://github.com/schandinat/linux-2.6.git. - Initialize .fb_mmap in both sh_mobile_lcdc_overlay_ops and sh_mobile_lcdc_ops. - Add Laurent's clean up patch. Hideki EIRAKU (3): ARM: dma-mapping: define ARCH_HAS_DMA_MMAP_COHERENT media: videobuf2-dma-contig: use dma_mmap_coherent if available fbdev: sh_mobile_lcdc: use dma_mmap_coherent if available Laurent Pinchart (1): ALSA: pcm - Don't define ARCH_HAS_DMA_MMAP_COHERENT privately for ARM arch/arm/include/asm/dma-mapping.h |1 + drivers/media/video/videobuf2-dma-contig.c | 18 ++ drivers/video/sh_mobile_lcdcfb.c | 28 sound/core/pcm_native.c|7 --- 4 files changed, 47 insertions(+), 7 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/4] ARM: dma-mapping: define ARCH_HAS_DMA_MMAP_COHERENT
ARCH_HAS_DMA_MMAP_COHERENT indicates that there is dma_mmap_coherent() API in this architecture. The name is already defined in PowerPC. Signed-off-by: Hideki EIRAKU h...@igel.co.jp --- arch/arm/include/asm/dma-mapping.h |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/include/asm/dma-mapping.h b/arch/arm/include/asm/dma-mapping.h index bbef15d..f41cd30 100644 --- a/arch/arm/include/asm/dma-mapping.h +++ b/arch/arm/include/asm/dma-mapping.h @@ -187,6 +187,7 @@ extern int arm_dma_mmap(struct device *dev, struct vm_area_struct *vma, struct dma_attrs *attrs); #define dma_mmap_coherent(d, v, c, h, s) dma_mmap_attrs(d, v, c, h, s, NULL) +#define ARCH_HAS_DMA_MMAP_COHERENT static inline int dma_mmap_attrs(struct device *dev, struct vm_area_struct *vma, void *cpu_addr, dma_addr_t dma_addr, -- 1.7.0.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 v2 2/4] ALSA: pcm - Don't define ARCH_HAS_DMA_MMAP_COHERENT privately for ARM
From: Laurent Pinchart laurent.pinch...@ideasonboard.com
The ARM architecture now defines ARCH_HAS_DMA_MMAP_COHERENT, there's no
need to define it privately anymore.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
sound/core/pcm_native.c |7 ---
1 files changed, 0 insertions(+), 7 deletions(-)
diff --git a/sound/core/pcm_native.c b/sound/core/pcm_native.c
index 53b5ada..84ead60 100644
--- a/sound/core/pcm_native.c
+++ b/sound/core/pcm_native.c
@@ -3156,13 +3156,6 @@ static const struct vm_operations_struct
snd_pcm_vm_ops_data_fault = {
.fault =snd_pcm_mmap_data_fault,
};
-#ifndef ARCH_HAS_DMA_MMAP_COHERENT
-/* This should be defined / handled globally! */
-#ifdef CONFIG_ARM
-#define ARCH_HAS_DMA_MMAP_COHERENT
-#endif
-#endif
-
/*
* mmap the DMA buffer on RAM
*/
--
1.7.0.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 v2 4/4] fbdev: sh_mobile_lcdc: use dma_mmap_coherent if available
fb_mmap() implemented in fbmem.c uses smem_start as the physical
address of the frame buffer. In the sh_mobile_lcdc driver, the
smem_start is a dma_addr_t that is not a physical address when IOMMU is
enabled. dma_mmap_coherent() maps the address correctly. It is
available on ARM platforms.
Signed-off-by: Hideki EIRAKU h...@igel.co.jp
---
drivers/video/sh_mobile_lcdcfb.c | 28
1 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/drivers/video/sh_mobile_lcdcfb.c b/drivers/video/sh_mobile_lcdcfb.c
index 8cb653b..c8cba7a 100644
--- a/drivers/video/sh_mobile_lcdcfb.c
+++ b/drivers/video/sh_mobile_lcdcfb.c
@@ -1614,6 +1614,17 @@ static int sh_mobile_lcdc_overlay_blank(int blank,
struct fb_info *info)
return 1;
}
+#ifdef ARCH_HAS_DMA_MMAP_COHERENT
+static int
+sh_mobile_lcdc_overlay_mmap(struct fb_info *info, struct vm_area_struct *vma)
+{
+ struct sh_mobile_lcdc_overlay *ovl = info-par;
+
+ return dma_mmap_coherent(ovl-channel-lcdc-dev, vma, ovl-fb_mem,
+ovl-dma_handle, ovl-fb_size);
+}
+#endif
+
static struct fb_ops sh_mobile_lcdc_overlay_ops = {
.owner = THIS_MODULE,
.fb_read= fb_sys_read,
@@ -1626,6 +1637,9 @@ static struct fb_ops sh_mobile_lcdc_overlay_ops = {
.fb_ioctl = sh_mobile_lcdc_overlay_ioctl,
.fb_check_var = sh_mobile_lcdc_overlay_check_var,
.fb_set_par = sh_mobile_lcdc_overlay_set_par,
+#ifdef ARCH_HAS_DMA_MMAP_COHERENT
+ .fb_mmap= sh_mobile_lcdc_overlay_mmap,
+#endif
};
static void
@@ -2093,6 +2107,17 @@ static int sh_mobile_lcdc_blank(int blank, struct
fb_info *info)
return 0;
}
+#ifdef ARCH_HAS_DMA_MMAP_COHERENT
+static int
+sh_mobile_lcdc_mmap(struct fb_info *info, struct vm_area_struct *vma)
+{
+ struct sh_mobile_lcdc_chan *ch = info-par;
+
+ return dma_mmap_coherent(ch-lcdc-dev, vma, ch-fb_mem,
+ch-dma_handle, ch-fb_size);
+}
+#endif
+
static struct fb_ops sh_mobile_lcdc_ops = {
.owner = THIS_MODULE,
.fb_setcolreg = sh_mobile_lcdc_setcolreg,
@@ -2108,6 +2133,9 @@ static struct fb_ops sh_mobile_lcdc_ops = {
.fb_release = sh_mobile_lcdc_release,
.fb_check_var = sh_mobile_lcdc_check_var,
.fb_set_par = sh_mobile_lcdc_set_par,
+#ifdef ARCH_HAS_DMA_MMAP_COHERENT
+ .fb_mmap= sh_mobile_lcdc_mmap,
+#endif
};
static void
--
1.7.0.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 v2 3/4] media: videobuf2-dma-contig: use dma_mmap_coherent if available
Previously the vb2_dma_contig_mmap() function was using a dma_addr_t as a
physical address. The two addressses are not necessarily the same.
For example, when using the IOMMU funtion on certain platforms, dma_addr_t
addresses are not directly mappable physical address.
dma_mmap_coherent() maps the address correctly.
It is available on ARM platforms.
Signed-off-by: Hideki EIRAKU h...@igel.co.jp
---
drivers/media/video/videobuf2-dma-contig.c | 18 ++
1 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/videobuf2-dma-contig.c
b/drivers/media/video/videobuf2-dma-contig.c
index 4b71326..4dc85ab 100644
--- a/drivers/media/video/videobuf2-dma-contig.c
+++ b/drivers/media/video/videobuf2-dma-contig.c
@@ -101,14 +101,32 @@ static unsigned int vb2_dma_contig_num_users(void
*buf_priv)
static int vb2_dma_contig_mmap(void *buf_priv, struct vm_area_struct *vma)
{
struct vb2_dc_buf *buf = buf_priv;
+#ifdef ARCH_HAS_DMA_MMAP_COHERENT
+ int ret;
+#endif
if (!buf) {
printk(KERN_ERR No buffer to map\n);
return -EINVAL;
}
+#ifdef ARCH_HAS_DMA_MMAP_COHERENT
+ vma-vm_page_prot = pgprot_noncached(vma-vm_page_prot);
+ ret = dma_mmap_coherent(buf-conf-dev, vma, buf-vaddr, buf-dma_addr,
+ buf-size);
+ if (ret) {
+ pr_err(Remapping memory failed, error: %d\n, ret);
+ return ret;
+ }
+ vma-vm_flags |= VM_DONTEXPAND | VM_RESERVED;
+ vma-vm_private_data = buf-handler;
+ vma-vm_ops = vb2_common_vm_ops;
+ vma-vm_ops-open(vma);
+ return 0;
+#else
return vb2_mmap_pfn_range(vma, buf-dma_addr, buf-size,
vb2_common_vm_ops, buf-handler);
+#endif
}
static void *vb2_dma_contig_get_userptr(void *alloc_ctx, unsigned long vaddr,
--
1.7.0.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
Re: [PATCH v2 4/4] fbdev: sh_mobile_lcdc: use dma_mmap_coherent if available
Hi Eiraku-san, On Thursday 26 July 2012 20:13:11 Hideki EIRAKU wrote: fb_mmap() implemented in fbmem.c uses smem_start as the physical address of the frame buffer. In the sh_mobile_lcdc driver, the smem_start is a dma_addr_t that is not a physical address when IOMMU is enabled. dma_mmap_coherent() maps the address correctly. It is available on ARM platforms. Signed-off-by: Hideki EIRAKU h...@igel.co.jp Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/4] Fix clocks for i.MX27 in mx2_camera.c
The following series follows the steps purposed by Guennadi (http://www.spinics.net/lists/arm-kernel/msg18.html) in order to fix clock handlings for i.MX27 in mx2_camera.c [PATCH 1/4] i.MX27: Fix emma-prp and csi clocks. [PATCH 2/4] media: mx2_camera: Mark i.MX25 support as BROKEN. [PATCH 3/4] Schedule removal of i.MX25 support in mx2_camera.c [PATCH 4/4] media: mx2_camera: Fix clock handling for i.MX27. -- 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/4] i.MX27: Fix emma-prp and csi clocks.
Naming of emma-prp related clocks for the i.MX27 is not correct. Signed-off-by: Javier Martin javier.mar...@vista-silicon.com --- arch/arm/mach-imx/clk-imx27.c |8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/arch/arm/mach-imx/clk-imx27.c b/arch/arm/mach-imx/clk-imx27.c index b1d343c..6e9cb02 100644 --- a/arch/arm/mach-imx/clk-imx27.c +++ b/arch/arm/mach-imx/clk-imx27.c @@ -223,7 +223,7 @@ int __init mx27_clocks_init(unsigned long fref) clk_register_clkdev(clk[per3_gate], per, imx-fb.0); clk_register_clkdev(clk[lcdc_ipg_gate], ipg, imx-fb.0); clk_register_clkdev(clk[lcdc_ahb_gate], ahb, imx-fb.0); - clk_register_clkdev(clk[csi_ahb_gate], NULL, mx2-camera.0); + clk_register_clkdev(clk[csi_ahb_gate], ahb, mx2-camera.0); clk_register_clkdev(clk[usb_div], per, fsl-usb2-udc); clk_register_clkdev(clk[usb_ipg_gate], ipg, fsl-usb2-udc); clk_register_clkdev(clk[usb_ahb_gate], ahb, fsl-usb2-udc); @@ -250,8 +250,10 @@ int __init mx27_clocks_init(unsigned long fref) clk_register_clkdev(clk[i2c2_ipg_gate], NULL, imx-i2c.1); clk_register_clkdev(clk[owire_ipg_gate], NULL, mxc_w1.0); clk_register_clkdev(clk[kpp_ipg_gate], NULL, imx-keypad); - clk_register_clkdev(clk[emma_ahb_gate], ahb, imx-emma); - clk_register_clkdev(clk[emma_ipg_gate], ipg, imx-emma); + clk_register_clkdev(clk[emma_ahb_gate], emma-ahb, mx2-camera.0); + clk_register_clkdev(clk[emma_ipg_gate], emma-ipg, mx2-camera.0); + clk_register_clkdev(clk[emma_ahb_gate], ahb, m2m-emmaprp.0); + clk_register_clkdev(clk[emma_ipg_gate], ipg, m2m-emmaprp.0); clk_register_clkdev(clk[iim_ipg_gate], iim, NULL); clk_register_clkdev(clk[gpio_ipg_gate], gpio, NULL); clk_register_clkdev(clk[brom_ahb_gate], brom, NULL); -- 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 2/4] media: mx2_camera: Mark i.MX25 support as BROKEN.
i.MX25 support is known to have been broken for almost a year. Signed-off-by: Javier Martin javier.mar...@vista-silicon.com --- drivers/media/video/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig index c0b9233..af9d2d0 100644 --- a/drivers/media/video/Kconfig +++ b/drivers/media/video/Kconfig @@ -1136,7 +1136,7 @@ config VIDEO_MX2_HOSTSUPPORT config VIDEO_MX2 tristate i.MX27/i.MX25 Camera Sensor Interface driver - depends on VIDEO_DEV SOC_CAMERA (MACH_MX27 || ARCH_MX25) + depends on VIDEO_DEV SOC_CAMERA (MACH_MX27 || (ARCH_MX25 BROKEN)) select VIDEOBUF2_DMA_CONTIG select VIDEO_MX2_HOSTSUPPORT ---help--- -- 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 4/4] media: mx2_camera: Fix clock handling for i.MX27.
This driver wasn't converted to the new clock framework
(e038ed50a4a767add205094c035b6943e7b30140).
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
drivers/media/video/mx2_camera.c | 67 ++
1 file changed, 39 insertions(+), 28 deletions(-)
diff --git a/drivers/media/video/mx2_camera.c b/drivers/media/video/mx2_camera.c
index 3c38b5f..88dcae6 100644
--- a/drivers/media/video/mx2_camera.c
+++ b/drivers/media/video/mx2_camera.c
@@ -273,7 +273,7 @@ struct mx2_camera_dev {
struct device *dev;
struct soc_camera_host soc_host;
struct soc_camera_device *icd;
- struct clk *clk_csi, *clk_emma;
+ struct clk *clk_csi, *clk_emma_ahb, *clk_emma_ipg;
unsigned intirq_csi, irq_emma;
void __iomem*base_csi, *base_emma;
@@ -436,7 +436,8 @@ static void mx2_camera_deactivate(struct mx2_camera_dev
*pcdev)
{
unsigned long flags;
- clk_disable(pcdev-clk_csi);
+ if (cpu_is_mx27())
+ clk_disable_unprepare(pcdev-clk_csi);
writel(0, pcdev-base_csi + CSICR1);
if (cpu_is_mx27()) {
writel(0, pcdev-base_emma + PRP_CNTL);
@@ -464,9 +465,11 @@ static int mx2_camera_add_device(struct soc_camera_device
*icd)
if (pcdev-icd)
return -EBUSY;
- ret = clk_enable(pcdev-clk_csi);
- if (ret 0)
- return ret;
+ if (cpu_is_mx27()) {
+ ret = clk_prepare_enable(pcdev-clk_csi);
+ if (ret 0)
+ return ret;
+ }
csicr1 = CSICR1_MCLKEN;
@@ -1675,23 +1678,12 @@ static int __devinit mx27_camera_emma_init(struct
mx2_camera_dev *pcdev)
goto exit_iounmap;
}
- pcdev-clk_emma = clk_get(NULL, emma);
- if (IS_ERR(pcdev-clk_emma)) {
- err = PTR_ERR(pcdev-clk_emma);
- goto exit_free_irq;
- }
-
- clk_enable(pcdev-clk_emma);
-
err = mx27_camera_emma_prp_reset(pcdev);
if (err)
- goto exit_clk_emma_put;
+ goto exit_free_irq;
return err;
-exit_clk_emma_put:
- clk_disable(pcdev-clk_emma);
- clk_put(pcdev-clk_emma);
exit_free_irq:
free_irq(pcdev-irq_emma, pcdev);
exit_iounmap:
@@ -1714,6 +1706,7 @@ static int __devinit mx2_camera_probe(struct
platform_device *pdev)
res_csi = platform_get_resource(pdev, IORESOURCE_MEM, 0);
irq_csi = platform_get_irq(pdev, 0);
+
if (res_csi == NULL || irq_csi 0) {
dev_err(pdev-dev, Missing platform resources data\n);
err = -ENODEV;
@@ -1727,11 +1720,26 @@ static int __devinit mx2_camera_probe(struct
platform_device *pdev)
goto exit;
}
- pcdev-clk_csi = clk_get(pdev-dev, NULL);
- if (IS_ERR(pcdev-clk_csi)) {
- dev_err(pdev-dev, Could not get csi clock\n);
- err = PTR_ERR(pcdev-clk_csi);
- goto exit_kfree;
+ if (cpu_is_mx27()) {
+ pcdev-clk_csi = devm_clk_get(pdev-dev, ahb);
+ if (IS_ERR(pcdev-clk_csi)) {
+ dev_err(pdev-dev, Could not get csi clock\n);
+ err = PTR_ERR(pcdev-clk_csi);
+ goto exit_kfree;
+ }
+ pcdev-clk_emma_ipg = devm_clk_get(pdev-dev, emma-ipg);
+ if (IS_ERR(pcdev-clk_emma_ipg)) {
+ err = PTR_ERR(pcdev-clk_emma_ipg);
+ goto exit_kfree;
+ }
+ pcdev-clk_emma_ahb = devm_clk_get(pdev-dev, emma-ahb);
+ if (IS_ERR(pcdev-clk_emma_ahb)) {
+ err = PTR_ERR(pcdev-clk_emma_ahb);
+ goto exit_kfree;
+ }
+ clk_prepare_enable(pcdev-clk_csi);
+ clk_prepare_enable(pcdev-clk_emma_ipg);
+ clk_prepare_enable(pcdev-clk_emma_ahb);
}
pcdev-res_csi = res_csi;
@@ -1827,8 +1835,8 @@ exit_free_emma:
eallocctx:
if (cpu_is_mx27()) {
free_irq(pcdev-irq_emma, pcdev);
- clk_disable(pcdev-clk_emma);
- clk_put(pcdev-clk_emma);
+ clk_disable_unprepare(pcdev-clk_emma_ipg);
+ clk_disable_unprepare(pcdev-clk_emma_ahb);
iounmap(pcdev-base_emma);
release_mem_region(pcdev-res_emma-start,
resource_size(pcdev-res_emma));
}
@@ -1840,7 +1848,11 @@ exit_iounmap:
exit_release:
release_mem_region(res_csi-start, resource_size(res_csi));
exit_dma_free:
- clk_put(pcdev-clk_csi);
+ if (cpu_is_mx27()) {
+ clk_disable_unprepare(pcdev-clk_emma_ipg);
+ clk_disable_unprepare(pcdev-clk_emma_ahb);
+ clk_disable_unprepare(pcdev-clk_csi);
+ }
exit_kfree:
kfree(pcdev);
exit:
@@ -1854,7 +1866,6 @@
[PATCH 3/4] Schedule removal of i.MX25 support in mx2_camera.c
Support for i.MX25 in mx2_camera.c has been broken for a year. Furthermore, i.MX25 video capture HW doesn't have much in common with i.MX27. A separate driver would be desirable. Signed-off-by: Javier Martin javier.mar...@vista-silicon.com --- Documentation/feature-removal-schedule.txt |9 + 1 file changed, 9 insertions(+) diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index 56000b3..6c50a17 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt @@ -6,6 +6,15 @@ be removed from this file. The suggested deprecation period is 3 releases. --- +What: support for i.mx25 in mx2_camera.c +When: v3.8 +Why: it's been broken for a year. Furthermore, i.MX25 video capture + HW doesn't have much in common with i.MX27. A separate driver + will be needed for it. +Who: Javier Martinjavier.mar...@vista-silicon.com + +--- + What: ddebug_query=query boot cmdline param When: v3.8 Why: obsoleted by dyndbg=query and module.dyndbg=query -- 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
[RFC] omap3-isp G_FMT ENUM_FMT
Hello, I would like to (re)submit a couple of patches to support V4L2 behavior at the V4L2 device nodes of the omap3-isp driver, but I'm guessing they require some discussion first. I've previously submitted one of them here [1] to support ENUM_FMT for the omap3-isp. This sparked some discussion, the result of which was that my patch probably made sense. Later [2], Laurent mentioned that there was some discussion/decision about adding profiles to the V4L2 specification, and the OMAP3 ISP would probably implement the streaming profile. That was 7 months ago and I haven't seen any discussion of such profiles. Can somebody bring me up to speed on this? The purpose of these two patches is for the V4L2 device nodes to support mandatory V4L2 ioctls G_FMT and ENUM_FMT, such that a pure V4L2 application, ignorant of the media controller, can still stream the images from the video nodes. This presumes that the media controller would have been pre-configured. This approach is often seen on the mailing list using 'media-ctl' to configure the ISP, then 'yavta' to retrieve images. Currently this works because yavta doesn't require ENUM_FMT (unlike Gstreamer), and only as long as one sets the same format with yavta as had already been set with media-ctl. I think yavta should be able to just do G_FMT to see what is configured. To be clear (as discussed in [1]), ENUM_FMT does not behave according to its original intent, because it cannot enumerate possible formats the ISP can deliver. It will enumerate only one format: the one configured with the media controller. In a sense this complies with the specification, because S_FMT wouldn't be able to change the format to anything else. I have tested these patches on v3.4, but I have rebased them to v3.5 here. I would remove the pr_debug() calls before submitting upstream, but they're useful for testing. [1] http://www.mail-archive.com/linux-media@vger.kernel.org/msg29640.html [2] http://www.mail-archive.com/linux-media@vger.kernel.org/msg40618.html Michael Jones (2): [media] omap3isp: implement ENUM_FMT [media] omap3isp: support G_FMT drivers/media/video/omap3isp/ispvideo.c | 50 +++ 1 files changed, 50 insertions(+), 0 deletions(-) -- 1.7.4.1 MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner, Erhard Meier -- 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] [media] omap3isp: implement ENUM_FMT
ENUM_FMT will not enumerate all formats that the ISP is capable of,
it will only return the format which has been previously configured
using the media controller, because this is the only format available
to a V4L2 application which is unaware of the media controller.
Signed-off-by: Michael Jones michael.jo...@matrix-vision.de
---
drivers/media/video/omap3isp/ispvideo.c | 23 +++
1 files changed, 23 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/omap3isp/ispvideo.c
b/drivers/media/video/omap3isp/ispvideo.c
index b37379d..d1d2c14 100644
--- a/drivers/media/video/omap3isp/ispvideo.c
+++ b/drivers/media/video/omap3isp/ispvideo.c
@@ -678,6 +678,28 @@ isp_video_get_format(struct file *file, void *fh, struct
v4l2_format *format)
}
static int
+isp_video_enum_format(struct file *file, void *fh, struct v4l2_fmtdesc
*fmtdesc)
+{
+ struct isp_video_fh *vfh = to_isp_video_fh(fh);
+ struct isp_video *video = video_drvdata(file);
+
+ if (fmtdesc-index)
+ return -EINVAL;
+
+ if (fmtdesc-type != video-type)
+ return -EINVAL;
+
+ fmtdesc-flags = 0;
+ fmtdesc-description[0] = 0;
+
+ mutex_lock(video-mutex);
+ fmtdesc-pixelformat = vfh-format.fmt.pix.pixelformat;
+ mutex_unlock(video-mutex);
+
+ return 0;
+}
+
+static int
isp_video_set_format(struct file *file, void *fh, struct v4l2_format *format)
{
struct isp_video_fh *vfh = to_isp_video_fh(fh);
@@ -1191,6 +1213,7 @@ isp_video_s_input(struct file *file, void *fh, unsigned
int input)
static const struct v4l2_ioctl_ops isp_video_ioctl_ops = {
.vidioc_querycap= isp_video_querycap,
+ .vidioc_enum_fmt_vid_cap= isp_video_enum_format,
.vidioc_g_fmt_vid_cap = isp_video_get_format,
.vidioc_s_fmt_vid_cap = isp_video_set_format,
.vidioc_try_fmt_vid_cap = isp_video_try_format,
--
1.7.4.1
MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner, Erhard Meier
--
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 2/2] [media] omap3isp: support G_FMT
This allows a V4L2 application which has no knowledge of the media
controller to open a video device node of the already-configured ISP
and query what it will deliver. Previously, G_FMT only worked after a
S_FMT had already been done.
Signed-off-by: Michael Jones michael.jo...@matrix-vision.de
---
drivers/media/video/omap3isp/ispvideo.c | 27 +++
1 files changed, 27 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/omap3isp/ispvideo.c
b/drivers/media/video/omap3isp/ispvideo.c
index d1d2c14..955211b 100644
--- a/drivers/media/video/omap3isp/ispvideo.c
+++ b/drivers/media/video/omap3isp/ispvideo.c
@@ -1244,6 +1244,7 @@ static int isp_video_open(struct file *file)
{
struct isp_video *video = video_drvdata(file);
struct isp_video_fh *handle;
+ struct media_pad *src_pad;
int ret = 0;
handle = kzalloc(sizeof(*handle), GFP_KERNEL);
@@ -1273,6 +1274,32 @@ static int isp_video_open(struct file *file)
handle-format.type = video-type;
handle-timeperframe.denominator = 1;
+ src_pad = media_entity_remote_source(video-pad);
+
+ if (src_pad) { /* it's on an active link */
+ struct v4l2_subdev_format srcfmt = {
+ .pad = src_pad-index,
+ .which = V4L2_SUBDEV_FORMAT_ACTIVE,
+ };
+ struct v4l2_subdev *src_subdev =
+ isp_video_remote_subdev(video, NULL);
+ pr_debug(%s src_subdev=\%s\\n, __func__, src_subdev-name);
+
+ ret = v4l2_subdev_call(src_subdev, pad, get_fmt, NULL, srcfmt);
+ if (ret)
+ goto done;
+ pr_debug(%s MBUS format %dx%d code:%x\n, __func__,
+ srcfmt.format.width, srcfmt.format.height,
+ srcfmt.format.code);
+
+ isp_video_mbus_to_pix(video, srcfmt.format,
+ handle-format.fmt.pix);
+ pr_debug(%s V4L format %dx%d 4CC:%x\n, __func__,
+ handle-format.fmt.pix.width,
+ handle-format.fmt.pix.height,
+ handle-format.fmt.pix.pixelformat);
+ }
+
handle-video = video;
file-private_data = handle-vfh;
--
1.7.4.1
MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner, Erhard Meier
--
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 v3.6] v4l2-dev.c: Move video_put() after debug printk
It is possible that video_put() releases video_device struct, provoking a panic when debug printk wants to get video_device node name. Signed-off-by: Ezequiel Garcia elezegar...@gmail.com --- drivers/media/video/v4l2-dev.c | 12 ++-- 1 files changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/media/video/v4l2-dev.c b/drivers/media/video/v4l2-dev.c index af70f93..3210fd5 100644 --- a/drivers/media/video/v4l2-dev.c +++ b/drivers/media/video/v4l2-dev.c @@ -478,12 +478,12 @@ static int v4l2_open(struct inode *inode, struct file *filp) } err: - /* decrease the refcount in case of an error */ - if (ret) - video_put(vdev); if (vdev-debug) printk(KERN_DEBUG %s: open (%d)\n, video_device_node_name(vdev), ret); + /* decrease the refcount in case of an error */ + if (ret) + video_put(vdev); return ret; } @@ -500,12 +500,12 @@ static int v4l2_release(struct inode *inode, struct file *filp) if (test_bit(V4L2_FL_LOCK_ALL_FOPS, vdev-flags)) mutex_unlock(vdev-lock); } - /* decrease the refcount unconditionally since the release() - return value is ignored. */ - video_put(vdev); if (vdev-debug) printk(KERN_DEBUG %s: release\n, video_device_node_name(vdev)); + /* decrease the refcount unconditionally since the release() + return value is ignored. */ + video_put(vdev); return ret; } -- 1.7.4.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
Re: [Workshop-2011] Media summit at the Kernel Summit - was: Fwd: Re: [Ksummit-2012-discuss] Organising Mini Summits within the Kernel Summit
On Thu, 26 Jul 2012 11:42:15 +0200, Hans Verkuil hverk...@xs4all.nl wrote: It's timed with the kernel summit and it will be on Tuesday. So you should have ample time. Oh? Is this firm yet? There's some pressure to book flights early here... Yes, that's firm. Sorry again... Does that mean nothing happens on Sunday and Monday? Also, when do get confirmed invitations to attend the media summit? -- Rémi Denis-Courmont Sent from my collocated server -- 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 for v3.6] v4l2-dev.c: Move video_put() after debug printk
On Thu 26 July 2012 13:59:04 Ezequiel Garcia wrote: It is possible that video_put() releases video_device struct, provoking a panic when debug printk wants to get video_device node name. Signed-off-by: Ezequiel Garcia elezegar...@gmail.com Acked-by: Hans Verkuil hans.verk...@cisco.com Good catch! Regards, Hans --- drivers/media/video/v4l2-dev.c | 12 ++-- 1 files changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/media/video/v4l2-dev.c b/drivers/media/video/v4l2-dev.c index af70f93..3210fd5 100644 --- a/drivers/media/video/v4l2-dev.c +++ b/drivers/media/video/v4l2-dev.c @@ -478,12 +478,12 @@ static int v4l2_open(struct inode *inode, struct file *filp) } err: - /* decrease the refcount in case of an error */ - if (ret) - video_put(vdev); if (vdev-debug) printk(KERN_DEBUG %s: open (%d)\n, video_device_node_name(vdev), ret); + /* decrease the refcount in case of an error */ + if (ret) + video_put(vdev); return ret; } @@ -500,12 +500,12 @@ static int v4l2_release(struct inode *inode, struct file *filp) if (test_bit(V4L2_FL_LOCK_ALL_FOPS, vdev-flags)) mutex_unlock(vdev-lock); } - /* decrease the refcount unconditionally since the release() -return value is ignored. */ - video_put(vdev); if (vdev-debug) printk(KERN_DEBUG %s: release\n, video_device_node_name(vdev)); + /* decrease the refcount unconditionally since the release() +return value is ignored. */ + video_put(vdev); return ret; } -- 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: [RFC] omap3-isp G_FMT ENUM_FMT
On Thu 26 July 2012 13:59:54 Michael Jones wrote: Hello, I would like to (re)submit a couple of patches to support V4L2 behavior at the V4L2 device nodes of the omap3-isp driver, but I'm guessing they require some discussion first. I've previously submitted one of them here [1] to support ENUM_FMT for the omap3-isp. This sparked some discussion, the result of which was that my patch probably made sense. Later [2], Laurent mentioned that there was some discussion/decision about adding profiles to the V4L2 specification, and the OMAP3 ISP would probably implement the streaming profile. That was 7 months ago and I haven't seen any discussion of such profiles. Can somebody bring me up to speed on this? Not much has happened. Actually, I've prepared a 'radio' profile which I hope to post before the V4L2 workshop next month. But no other profiles were made yet. In practice the v4l2-compliance tool does lots of checks that very closely resemble a 'profile' checker. But it will need some more work to correctly support low-level media controller-based drivers. Regards, Hans The purpose of these two patches is for the V4L2 device nodes to support mandatory V4L2 ioctls G_FMT and ENUM_FMT, such that a pure V4L2 application, ignorant of the media controller, can still stream the images from the video nodes. This presumes that the media controller would have been pre-configured. This approach is often seen on the mailing list using 'media-ctl' to configure the ISP, then 'yavta' to retrieve images. Currently this works because yavta doesn't require ENUM_FMT (unlike Gstreamer), and only as long as one sets the same format with yavta as had already been set with media-ctl. I think yavta should be able to just do G_FMT to see what is configured. To be clear (as discussed in [1]), ENUM_FMT does not behave according to its original intent, because it cannot enumerate possible formats the ISP can deliver. It will enumerate only one format: the one configured with the media controller. In a sense this complies with the specification, because S_FMT wouldn't be able to change the format to anything else. I have tested these patches on v3.4, but I have rebased them to v3.5 here. I would remove the pr_debug() calls before submitting upstream, but they're useful for testing. [1] http://www.mail-archive.com/linux-media@vger.kernel.org/msg29640.html [2] http://www.mail-archive.com/linux-media@vger.kernel.org/msg40618.html Michael Jones (2): [media] omap3isp: implement ENUM_FMT [media] omap3isp: support G_FMT drivers/media/video/omap3isp/ispvideo.c | 50 +++ 1 files changed, 50 insertions(+), 0 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Workshop-2011] Media summit at the Kernel Summit - was: Fwd: Re: [Ksummit-2012-discuss] Organising Mini Summits within the Kernel Summit
On Thu 26 July 2012 14:05:51 Rémi Denis-Courmont wrote: On Thu, 26 Jul 2012 11:42:15 +0200, Hans Verkuil hverk...@xs4all.nl wrote: It's timed with the kernel summit and it will be on Tuesday. So you should have ample time. Oh? Is this firm yet? There's some pressure to book flights early here... Yes, that's firm. Sorry again... Does that mean nothing happens on Sunday and Monday? To my knowledge there is nothing planned with respect to V4L/DVB. Monday is the closed session of the kernel summit. All workshops of the various subsystems are scheduled on Tuesday. That doesn't mean nothing happens: I'll be attending the gstreamer conference on Monday myself. Also, when do get confirmed invitations to attend the media summit? I'll make sure you'll be invited. I'm not even sure you need an official invite for the workshop. I know that anyone who also attends the LPC can get an invite for the workshops on Tuesday for free. Anyway, I'll put your name on the list and make sure that Mauro will pass that on to the organizers once he's back from vacation. 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: [Workshop-2011] Media summit at the Kernel Summit - was: Fwd: Re: [Ksummit-2012-discuss] Organising Mini Summits within the Kernel Summit
Hi Rémi, On Thursday 26 July 2012 14:05:51 Rémi Denis-Courmont wrote: On Thu, 26 Jul 2012 11:42:15 +0200, Hans Verkuil wrote: It's timed with the kernel summit and it will be on Tuesday. So you should have ample time. Oh? Is this firm yet? There's some pressure to book flights early here... Yes, that's firm. Sorry again... Does that mean nothing happens on Sunday and Monday? Nothing is a bit too strong of a word :-) Several developers will already be present on Sunday and Monday, so it could be possible to already hold meetings (although getting a room might not be easy). You can also attend the GStreamer Conference on Monday if you wish. Also, when do get confirmed invitations to attend the media summit? I expect Mauro to send them when he will be back from holidays. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: tda18271 driver power consumption
On Wed, Jul 25, 2012 at 11:18 PM, Michael Krufky mkru...@linuxtv.org wrote: On Tue, Jul 24, 2012 at 8:43 PM, Antti Palosaari cr...@iki.fi wrote: On 07/25/2012 03:15 AM, Michael Krufky wrote: On Tue, Jul 24, 2012 at 6:17 PM, Michael Krufky mkru...@linuxtv.org wrote: On Tue, Jul 24, 2012 at 6:12 PM, Antti Palosaari cr...@iki.fi wrote: On 07/25/2012 12:55 AM, Michael Krufky wrote: On Sun, Jul 22, 2012 at 3:59 PM, Antti Palosaari cr...@iki.fi wrote: Moi Michael, I just realized tda18271 driver eats 160mA too much current after attach. This means, there is power management bug. When I plug my nanoStick it eats total 240mA, after tda18271 sleep is called it eats only 80mA total which is reasonable. If I use Digital Devices tda18271c2dd driver it is total 110mA after attach, which is also quite OK. Thanks for the report -- I will take a look at it. ...patches are welcome, of course :-) I suspect it does some tweaking on attach() and chip leaves powered (I saw demod debugs at calls I2C-gate control quite many times thus this suspicion). When chip is powered-up it is usually in some sleep state by default. Also, on attach() there should be no I/O unless very good reason. For example chip ID is allowed to read and download firmware in case it is really needed to continue - like for tuner communication. What I found quickly testing few DVB USB sticks there seems to be very much power management problems... I am now waiting for new multimeter in order to make better measurements and likely return fixing these issues later. The driver does some calibration during attach, some of which is a one-time initialization to determine a temperature differential for tune calculation later on, which can take some time on slower USB buses. The fix for the power usage issue would just be to make sure to sleep the device before exiting the attach() function. I'm not looking to remove the calibration from the attach -- this was done on purpose. Antti, After looking again, I realize that we are purposefully not sleeping the device before we exit the attach() function. The tda18271 is commonly found in multi-chip designs that may or may not include an analog demodulator and / or other tda18271 tuners. In such designs, the chips tend to be daisy-chained to each other, using the xtal output and loop-thru features of the tda18271. We set the required features in the attach-time configuration structure. However, we must keep in mind that this is a hybrid tuner chip, and the analog side of the bridge driver may actually come up before the digital side. Since the actual configuration tends to be done in the digital bring-up, the analog side is brought up within tuner.ko using the most generic one-size-fits all configuration, which gets overridden when the digital side initializes. It is absolutely crucial that if we actually need the xtal output feature enabled, that it must *never* be turned off, otherwise the i2c bus may get wedged unrecoverably. So, we make sure to leave this feature enabled during the attach function, since we don't yet know at that point whether there is another instance of this same tuner yet to be initialized. It is not safe to power off that feature until after we are sure that the bridge has completely initialized. In order to rectify this issue from within your driver, you should call sleep after you complete the attach. For instance, this is what we do in the cx23885 driver: if (fe0-dvb.frontend-ops.analog_ops.standby) fe0-dvb.frontend-ops.analog_ops.standby(fe0-dvb.frontend); ...except you should call into the tuner_ops-sleep() function instead of analog_demod_ops-standby() Does this clear things up for you? Surely this is possible and it will resolve power drain issue. But it is not nice looking and causes more deviation compared to others. Could you add configuration option bool do_not_powerdown_on_attach ? I have quite many tda18271 devices here and all those are DVB onlỵ (OK, PCTV 520e is DVB + analog, but analog is not supported). Having configuration parameter sounds like better plan. Come to think of it, since the generic one-size-fits-all configuration leaves the loop thru and xtal output enabled, it should be safe to go to the lowest power level allowed (based on the configuration) at the end of the attach() function. I'll put up a patch within the next few days... Thanks for noticing this, Antti. :-) We wont need to add any new configuration option :-) -Mike Antti, This small patch should do the trick -- can you test it? The following changes since commit 0c7d5a6da75caecc677be1fda207b7578936770d: Linux 3.5-rc5 (2012-07-03 22:57:41 +0300) are available in the git repository at: git://git.linuxtv.org/mkrufky/tuners tda18271 for you to fetch changes up to 782b28e20d3b253d317cc71879639bf3c108b200: tda18271: enter low-power standby mode at the end of
[PATCH] mt9v032: Provide link frequency control
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/mt9v032.c | 48
include/media/mt9v032.h |3 ++
2 files changed, 46 insertions(+), 5 deletions(-)
diff --git a/drivers/media/video/mt9v032.c b/drivers/media/video/mt9v032.c
index 2203a6f..39217b8 100644
--- a/drivers/media/video/mt9v032.c
+++ b/drivers/media/video/mt9v032.c
@@ -29,6 +29,8 @@
#define MT9V032_PIXEL_ARRAY_HEIGHT 492
#define MT9V032_PIXEL_ARRAY_WIDTH 782
+#define MT9V032_SYSCLK_FREQ_DEF2660
+
#define MT9V032_CHIP_VERSION 0x00
#defineMT9V032_CHIP_ID_REV10x1311
#defineMT9V032_CHIP_ID_REV30x1313
@@ -122,13 +124,18 @@ struct mt9v032 {
struct v4l2_mbus_framefmt format;
struct v4l2_rect crop;
- struct v4l2_ctrl *pixel_rate;
struct v4l2_ctrl_handler ctrls;
+ struct {
+ struct v4l2_ctrl *link_freq;
+ struct v4l2_ctrl *pixel_rate;
+ };
struct mutex power_lock;
int power_count;
struct mt9v032_platform_data *pdata;
+
+ u32 sysclk;
u16 chip_control;
u16 aec_agc;
};
@@ -196,7 +203,7 @@ static int mt9v032_power_on(struct mt9v032 *mt9v032)
int ret;
if (mt9v032-pdata-set_clock) {
- mt9v032-pdata-set_clock(mt9v032-subdev, EXT_CLK);
+ mt9v032-pdata-set_clock(mt9v032-subdev, mt9v032-sysclk);
udelay(1);
}
@@ -374,7 +381,8 @@ static void mt9v032_configure_pixel_rate(struct mt9v032
*mt9v032,
struct i2c_client *client = v4l2_get_subdevdata(mt9v032-subdev);
int ret;
- ret = v4l2_ctrl_s_ctrl_int64(mt9v032-pixel_rate, EXT_CLK / hratio);
+ ret = v4l2_ctrl_s_ctrl_int64(mt9v032-pixel_rate,
+mt9v032-sysclk / hratio);
if (ret 0)
dev_warn(client-dev, failed to set pixel rate (%d)\n, ret);
}
@@ -487,6 +495,7 @@ static int mt9v032_s_ctrl(struct v4l2_ctrl *ctrl)
struct mt9v032 *mt9v032 =
container_of(ctrl-handler, struct mt9v032, ctrls);
struct i2c_client *client = v4l2_get_subdevdata(mt9v032-subdev);
+ u32 freq;
u16 data;
switch (ctrl-id) {
@@ -505,6 +514,16 @@ static int mt9v032_s_ctrl(struct v4l2_ctrl *ctrl)
return mt9v032_write(client, MT9V032_TOTAL_SHUTTER_WIDTH,
ctrl-val);
+ case V4L2_CID_PIXEL_RATE:
+ case V4L2_CID_LINK_FREQ:
+ if (mt9v032-link_freq == NULL)
+ break;
+
+ freq = mt9v032-pdata-link_freqs[mt9v032-link_freq-val];
+ mt9v032-pixel_rate-cur.val = freq;
+ mt9v032-sysclk = freq;
+ break;
+
case V4L2_CID_TEST_PATTERN:
switch (ctrl-val) {
case 0:
@@ -683,6 +702,7 @@ static const struct v4l2_subdev_internal_ops
mt9v032_subdev_internal_ops = {
static int mt9v032_probe(struct i2c_client *client,
const struct i2c_device_id *did)
{
+ struct mt9v032_platform_data *pdata = client-dev.platform_data;
struct mt9v032 *mt9v032;
unsigned int i;
int ret;
@@ -699,9 +719,9 @@ static int mt9v032_probe(struct i2c_client *client,
return -ENOMEM;
mutex_init(mt9v032-power_lock);
- mt9v032-pdata = client-dev.platform_data;
+ mt9v032-pdata = pdata;
- v4l2_ctrl_handler_init(mt9v032-ctrls, ARRAY_SIZE(mt9v032_ctrls) + 5);
+ v4l2_ctrl_handler_init(mt9v032-ctrls, ARRAY_SIZE(mt9v032_ctrls) + 6);
v4l2_ctrl_new_std(mt9v032-ctrls, mt9v032_ctrl_ops,
V4L2_CID_AUTOGAIN, 0, 1, 1, 1);
@@ -715,10 +735,27 @@ static int mt9v032_probe(struct i2c_client *client,
V4L2_CID_EXPOSURE, MT9V032_TOTAL_SHUTTER_WIDTH_MIN,
MT9V032_TOTAL_SHUTTER_WIDTH_MAX, 1,
MT9V032_TOTAL_SHUTTER_WIDTH_DEF);
+
mt9v032-pixel_rate =
v4l2_ctrl_new_std(mt9v032-ctrls, mt9v032_ctrl_ops,
V4L2_CID_PIXEL_RATE, 0, 0, 1, 0);
+ if (pdata pdata-link_freqs) {
+ unsigned int def = 0;
+
+ for (i = 0; pdata-link_freqs[i]; ++i) {
+ if (pdata-link_freqs[i] == pdata-link_def_freq)
+ def = i;
+ }
+
+ mt9v032-link_freq =
+ v4l2_ctrl_new_int_menu(mt9v032-ctrls,
+ mt9v032_ctrl_ops,
+ V4L2_CID_LINK_FREQ, i - 1, def,
+ pdata-link_freqs);
+ v4l2_ctrl_cluster(2, mt9v032-link_freq);
+ }
+
Re: [PATCH] mt9v032: Provide link frequency control
On Thu 26 July 2012 14:56:56 Laurent Pinchart wrote:
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/mt9v032.c | 48
include/media/mt9v032.h |3 ++
2 files changed, 46 insertions(+), 5 deletions(-)
diff --git a/drivers/media/video/mt9v032.c b/drivers/media/video/mt9v032.c
index 2203a6f..39217b8 100644
--- a/drivers/media/video/mt9v032.c
+++ b/drivers/media/video/mt9v032.c
@@ -29,6 +29,8 @@
#define MT9V032_PIXEL_ARRAY_HEIGHT 492
#define MT9V032_PIXEL_ARRAY_WIDTH782
+#define MT9V032_SYSCLK_FREQ_DEF 2660
+
#define MT9V032_CHIP_VERSION 0x00
#define MT9V032_CHIP_ID_REV10x1311
#define MT9V032_CHIP_ID_REV30x1313
@@ -122,13 +124,18 @@ struct mt9v032 {
struct v4l2_mbus_framefmt format;
struct v4l2_rect crop;
- struct v4l2_ctrl *pixel_rate;
struct v4l2_ctrl_handler ctrls;
+ struct {
+ struct v4l2_ctrl *link_freq;
+ struct v4l2_ctrl *pixel_rate;
+ };
struct mutex power_lock;
int power_count;
struct mt9v032_platform_data *pdata;
+
+ u32 sysclk;
u16 chip_control;
u16 aec_agc;
};
@@ -196,7 +203,7 @@ static int mt9v032_power_on(struct mt9v032 *mt9v032)
int ret;
if (mt9v032-pdata-set_clock) {
- mt9v032-pdata-set_clock(mt9v032-subdev, EXT_CLK);
+ mt9v032-pdata-set_clock(mt9v032-subdev, mt9v032-sysclk);
udelay(1);
}
@@ -374,7 +381,8 @@ static void mt9v032_configure_pixel_rate(struct mt9v032
*mt9v032,
struct i2c_client *client = v4l2_get_subdevdata(mt9v032-subdev);
int ret;
- ret = v4l2_ctrl_s_ctrl_int64(mt9v032-pixel_rate, EXT_CLK / hratio);
+ ret = v4l2_ctrl_s_ctrl_int64(mt9v032-pixel_rate,
+ mt9v032-sysclk / hratio);
if (ret 0)
dev_warn(client-dev, failed to set pixel rate (%d)\n, ret);
}
@@ -487,6 +495,7 @@ static int mt9v032_s_ctrl(struct v4l2_ctrl *ctrl)
struct mt9v032 *mt9v032 =
container_of(ctrl-handler, struct mt9v032, ctrls);
struct i2c_client *client = v4l2_get_subdevdata(mt9v032-subdev);
+ u32 freq;
u16 data;
switch (ctrl-id) {
@@ -505,6 +514,16 @@ static int mt9v032_s_ctrl(struct v4l2_ctrl *ctrl)
return mt9v032_write(client, MT9V032_TOTAL_SHUTTER_WIDTH,
ctrl-val);
+ case V4L2_CID_PIXEL_RATE:
+ case V4L2_CID_LINK_FREQ:
+ if (mt9v032-link_freq == NULL)
+ break;
+
+ freq = mt9v032-pdata-link_freqs[mt9v032-link_freq-val];
+ mt9v032-pixel_rate-cur.val = freq;
That should be 'mt9v032-pixel_rate-val = freq;'.
It used to be cur.val some time ago, but that was changed. You never set cur.val
anymore inside a s_ctrl handler.
Regards,
Hans
+ mt9v032-sysclk = freq;
+ break;
+
case V4L2_CID_TEST_PATTERN:
switch (ctrl-val) {
case 0:
@@ -683,6 +702,7 @@ static const struct v4l2_subdev_internal_ops
mt9v032_subdev_internal_ops = {
static int mt9v032_probe(struct i2c_client *client,
const struct i2c_device_id *did)
{
+ struct mt9v032_platform_data *pdata = client-dev.platform_data;
struct mt9v032 *mt9v032;
unsigned int i;
int ret;
@@ -699,9 +719,9 @@ static int mt9v032_probe(struct i2c_client *client,
return -ENOMEM;
mutex_init(mt9v032-power_lock);
- mt9v032-pdata = client-dev.platform_data;
+ mt9v032-pdata = pdata;
- v4l2_ctrl_handler_init(mt9v032-ctrls, ARRAY_SIZE(mt9v032_ctrls) + 5);
+ v4l2_ctrl_handler_init(mt9v032-ctrls, ARRAY_SIZE(mt9v032_ctrls) + 6);
v4l2_ctrl_new_std(mt9v032-ctrls, mt9v032_ctrl_ops,
V4L2_CID_AUTOGAIN, 0, 1, 1, 1);
@@ -715,10 +735,27 @@ static int mt9v032_probe(struct i2c_client *client,
V4L2_CID_EXPOSURE, MT9V032_TOTAL_SHUTTER_WIDTH_MIN,
MT9V032_TOTAL_SHUTTER_WIDTH_MAX, 1,
MT9V032_TOTAL_SHUTTER_WIDTH_DEF);
+
mt9v032-pixel_rate =
v4l2_ctrl_new_std(mt9v032-ctrls, mt9v032_ctrl_ops,
V4L2_CID_PIXEL_RATE, 0, 0, 1, 0);
+ if (pdata pdata-link_freqs) {
+ unsigned int def = 0;
+
+ for (i = 0; pdata-link_freqs[i]; ++i) {
+ if (pdata-link_freqs[i] == pdata-link_def_freq)
+ def = i;
+ }
+
+ mt9v032-link_freq =
+ v4l2_ctrl_new_int_menu(mt9v032-ctrls,
+mt9v032_ctrl_ops,
+
Re: [PATCH] mt9v032: Provide link frequency control
Hi Hans, Thanks for the review. On Thursday 26 July 2012 15:16:04 Hans Verkuil wrote: On Thu 26 July 2012 14:56:56 Laurent Pinchart wrote: Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com --- drivers/media/video/mt9v032.c | 48 include/media/mt9v032.h |3 ++ 2 files changed, 46 insertions(+), 5 deletions(-) diff --git a/drivers/media/video/mt9v032.c b/drivers/media/video/mt9v032.c index 2203a6f..39217b8 100644 --- a/drivers/media/video/mt9v032.c +++ b/drivers/media/video/mt9v032.c [snip] @@ -505,6 +514,16 @@ static int mt9v032_s_ctrl(struct v4l2_ctrl *ctrl) return mt9v032_write(client, MT9V032_TOTAL_SHUTTER_WIDTH, ctrl-val); + case V4L2_CID_PIXEL_RATE: + case V4L2_CID_LINK_FREQ: + if (mt9v032-link_freq == NULL) + break; + + freq = mt9v032-pdata-link_freqs[mt9v032-link_freq-val]; + mt9v032-pixel_rate-cur.val = freq; That should be 'mt9v032-pixel_rate-val = freq;'. It used to be cur.val some time ago, but that was changed. You never set cur.val anymore inside a s_ctrl handler. Thanks. I'll fix that. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] omap3-isp G_FMT ENUM_FMT
Hi Michael, On Thursday 26 July 2012 13:59:54 Michael Jones wrote: Hello, I would like to (re)submit a couple of patches to support V4L2 behavior at the V4L2 device nodes of the omap3-isp driver, but I'm guessing they require some discussion first. Indeed. The main reason why the OMAP3 ISP driver implements G_FMT/S_FMT as it does today is to hack around a restriction in the V4L2 API. We needed a way to preallocate and possibly prequeue buffers for snapshot, which wasn't possible in a standard-compliant way back then. The situation has since changed, and we now have the VIDIOC_CREATE_BUFS and VIDIOC_PREPARE_BUF ioctls. My plan is to - port the OMAP3 ISP driver to videobuf2 - implement support for CREATE_BUFS and PREPARE_BUF - fix the G_FMT/S_FMT/ENUM_FMT behaviour The real problem will be to find time to implement this. I've previously submitted one of them here [1] to support ENUM_FMT for the omap3-isp. This sparked some discussion, the result of which was that my patch probably made sense. Later [2], Laurent mentioned that there was some discussion/decision about adding profiles to the V4L2 specification, and the OMAP3 ISP would probably implement the streaming profile. That was 7 months ago and I haven't seen any discussion of such profiles. Can somebody bring me up to speed on this? The purpose of these two patches is for the V4L2 device nodes to support mandatory V4L2 ioctls G_FMT and ENUM_FMT, such that a pure V4L2 application, ignorant of the media controller, can still stream the images from the video nodes. This presumes that the media controller would have been pre-configured. This approach is often seen on the mailing list using 'media-ctl' to configure the ISP, then 'yavta' to retrieve images. Currently this works because yavta doesn't require ENUM_FMT (unlike Gstreamer), and only as long as one sets the same format with yavta as had already been set with media-ctl. I think yavta should be able to just do G_FMT to see what is configured. To be clear (as discussed in [1]), ENUM_FMT does not behave according to its original intent, because it cannot enumerate possible formats the ISP can deliver. It will enumerate only one format: the one configured with the media controller. In a sense this complies with the specification, because S_FMT wouldn't be able to change the format to anything else. I have tested these patches on v3.4, but I have rebased them to v3.5 here. I would remove the pr_debug() calls before submitting upstream, but they're useful for testing. [1] http://www.mail-archive.com/linux-media@vger.kernel.org/msg29640.html [2] http://www.mail-archive.com/linux-media@vger.kernel.org/msg40618.html Michael Jones (2): [media] omap3isp: implement ENUM_FMT [media] omap3isp: support G_FMT drivers/media/video/omap3isp/ispvideo.c | 50 1 files changed, 50 insertions(+), 0 deletions(-) -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] omap3-isp G_FMT ENUM_FMT
Hi Laurent, Thanks for the reply. On 07/26/2012 04:05 PM, Laurent Pinchart wrote: Hi Michael, On Thursday 26 July 2012 13:59:54 Michael Jones wrote: Hello, I would like to (re)submit a couple of patches to support V4L2 behavior at the V4L2 device nodes of the omap3-isp driver, but I'm guessing they require some discussion first. Indeed. The main reason why the OMAP3 ISP driver implements G_FMT/S_FMT as it does today is to hack around a restriction in the V4L2 API. We needed a way to preallocate and possibly prequeue buffers for snapshot, which wasn't possible in a standard-compliant way back then. The situation has since changed, and we now have the VIDIOC_CREATE_BUFS and VIDIOC_PREPARE_BUF ioctls. My plan is to - port the OMAP3 ISP driver to videobuf2 - implement support for CREATE_BUFS and PREPARE_BUF - fix the G_FMT/S_FMT/ENUM_FMT behaviour What will the G_FMT/S_FMT/ENUM_FMT behavior be then? Can you contrast it with the behavior of my patches? If the behavior will be the same for user space, and your proposed changes won't be in very soon, can we use my patches until you make your changes? MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner, Erhard Meier -- 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: [RFC PATCH 1/2] Initial version of the RDS-decoder library Signed-off-by: Konke Radlow krad...@cisco.com
PATCH 1/2 was missing the public header for the rds library. I'm sorry for
that mistake:
diff --git a/lib/include/libv4l2rds.h b/lib/include/libv4l2rds.h
new file mode 100644
index 000..04843d3
--- /dev/null
+++ b/lib/include/libv4l2rds.h
@@ -0,0 +1,203 @@
+/*
+ * Copyright 2012 Cisco Systems, Inc. and/or its affiliates. All rights
reserved.
+ * Author: Konke Radlow korad...@gmail.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
by
+ * the Free Software Foundation; either version 2.1 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Suite 500, Boston, MA 02110-1335
USA
+ */
+
+#ifndef __LIBV4L2RDS
+#define __LIBV4L2RDS
+
+#include errno.h
+#include stdio.h
+#include stdlib.h
+#include string.h
+#include stdbool.h
+#include unistd.h
+#include stdint.h
+#include sys/types.h
+#include sys/mman.h
+
+#include linux/videodev2.h
+
+#ifdef __cplusplus
+extern C {
+#endif /* __cplusplus */
+
+#if __GNUC__ = 4
+#define LIBV4L_PUBLIC __attribute__ ((visibility(default)))
+#else
+#define LIBV4L_PUBLIC
+#endif
+
+/* used to define the current version (version field) of the v4l2_rds struct */
+#define V4L2_RDS_VERSION (1)
+
+/* Constants used to define the size of arrays used to store RDS information
*/
+#define MAX_ODA_CNT 18 /* there are 16 groups each with type a or b.
Of these
+* 32 distinct groups, 18 can be used for ODA
purposes*/
+#define MAX_AF_CNT 25 /* AF Method A allows a maximum of 25 AFs to be
defined
+* AF Method B does not impose a limit on the number of
AFs
+* but it is not fully supported at the moment and will
+* not receive more than 25 AFs */
+
+/* Define Constants for the possible types of RDS information
+ * used to address the relevant bit in the valid_bitmask */
+#define V4L2_RDS_PI0x01/* Program Identification */
+#define V4L2_RDS_PTY 0x02/* Program Type */
+#define V4L2_RDS_TP0x04/* Traffic Program */
+#define V4L2_RDS_PS0x08/* Program Service Name */
+#define V4L2_RDS_TA0x10/* Traffic Announcement */
+#define V4L2_RDS_DI0x20/* Decoder Information */
+#define V4L2_RDS_MS0x40/* Music / Speech code */
+#define V4L2_RDS_PTYN 0x80/* Program Type Name */
+#define V4L2_RDS_RT0x100 /* Radio-Text */
+#define V4L2_RDS_TIME 0x200 /* Date and Time information */
+#define V4L2_RDS_TMC 0x400 /* TMC availability */
+#define V4L2_RDS_AF0x800 /* AF (alternative freq) available */
+#define V4L2_RDS_ECC 0x1000 /* Extended County Code */
+#define V4L2_RDS_LC0x2000 /* Language Code */
+
+/* Define Constants for the state of the RDS decoding process
+ * used to address the relevant bit in the state_bitmask */
+#define V4L2_RDS_GROUP_NEW 0x01/* New group received */
+#define V4L2_RDS_ODA 0x02/* Open Data Group announced */
+
+/* Decoder Information (DI) codes
+ * used to decode the DI information according to the RDS standard */
+#define V4L2_RDS_FLAG_STEREO 0x01
+#define V4L2_RDS_FLAG_ARTIFICIAL_HEAD 0x02
+#define V4L2_RDS_FLAG_COMPRESSED 0x04
+#define V4L2_RDS_FLAG_STATIC_PTY 0x08
+
+/* struct to encapsulate one complete RDS group */
+struct v4l2_rds_group {
+ uint16_t pi;
+ char group_version;
+ bool traffic_prog;
+ uint8_t group_id;
+ uint8_t pty;
+ uint8_t data_b_lsb;
+ uint8_t data_c_msb;
+ uint8_t data_c_lsb;
+ uint8_t data_d_msb;
+ uint8_t data_d_lsb;
+};
+
+/* struct to encapsulate some statistical information about the decoding
process */
+struct v4l2_rds_statistics {
+ uint32_t block_cnt;
+ uint32_t group_cnt;
+ uint32_t block_error_cnt;
+ uint32_t group_error_cnt;
+ uint32_t block_corrected_cnt;
+ uint32_t group_type_cnt[16];
+};
+
+/* struct to encapsulate the definition of one ODA (Open Data Application)
type */
+struct v4l2_rds_oda {
+ uint8_t group_id;
+ char group_version;
+ uint16_t aid; /* Application Identification */
+};
+
+/* struct to encapsulate an array of all defined ODA types for a channel */
+struct v4l2_rds_oda_set {
+ uint8_t size;
+ struct v4l2_rds_oda oda[MAX_ODA_CNT];
+};
+
+/* struct to encapsulate an array of all defined Alternative
Re: [RFC PATCH 1/2] Initial version of the RDS-decoder library Signed-off-by: Konke Radlow krad...@cisco.com
Hi Konke, + +libv4l2rds_la_SOURCES = libv4l2rds.c +libv4l2rds_la_CPPFLAGS = -fvisibility=hidden $(ENFORCE_LIBV4L_STATIC) -std=c99 +libv4l2rds_la_LDFLAGS = -version-info 0 -lpthread $(DLOPEN_LIBS) $(ENFORCE_LIBV4L_STATIC) diff --git a/lib/libv4l2rds/libv4l2rds.c b/lib/libv4l2rds/libv4l2rds.c new file mode 100644 index 000..0bacaa2 --- /dev/null +++ b/lib/libv4l2rds/libv4l2rds.c @@ -0,0 +1,871 @@ +/* + * Copyright 2012 Cisco Systems, Inc. and/or its affiliates. All rights reserved. [snip] + * This program is free software; you can redistribute it and/or modify Just a -probably silly- question... How can it be free software yet claim All rights reserved ? Is this correct? Regards, 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: [PATCH v3 3/5] media: gscaler: Add core functionality for the G-Scaler driver
Hi Shaik,
Thank you for addressing my comments.
On 07/25/2012 02:26 PM, Shaik Ameer Basha wrote:
+static int gsc_probe(struct platform_device *pdev)
+{
+ struct gsc_dev *gsc;
+ struct resource *res;
+ struct gsc_driverdata *drv_data = gsc_get_drv_data(pdev);
+ struct device *dev = pdev-dev;
+ int ret = 0;
+
+ gsc = devm_kzalloc(dev, sizeof(struct gsc_dev), GFP_KERNEL);
+ if (!gsc)
+ return -ENOMEM;
+
+ if (dev-of_node)
+ gsc-id = of_alias_get_id(pdev-dev.of_node, gsc);
+ else
+ gsc-id = pdev-id;
+
+ if (gsc-id 0 || gsc-id = drv_data-num_entities) {
+ dev_err(dev, Invalid platform device id: %d\n, gsc-id);
+ return -EINVAL;
+ }
+
+ pdev-id = gsc-id;
+ gsc-variant = drv_data-variant[gsc-id];
+ gsc-pdev = pdev;
+ gsc-pdata = dev-platform_data;
+
+ init_waitqueue_head(gsc-irq_queue);
+ spin_lock_init(gsc-slock);
+ mutex_init(gsc-lock);
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ gsc-regs = devm_request_and_ioremap(dev, res);
+ if (!gsc-regs) {
+ dev_err(dev, failed to map registers\n);
+ return -ENOENT;
+ }
+
+ res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
+ if (!res) {
+ dev_err(dev, failed to get IRQ resource\n);
+ return -ENXIO;
+ }
+
+ ret = gsc_clk_get(gsc);
+ if (ret)
+ return ret;
+
+ ret = devm_request_irq(dev, res-start, gsc_irq_handler,
+ 0, pdev-name, gsc);
One more small note, this should be:
0, dev_name(pdev-dev), gsc);
Then it's easier to identify which interrupts come from which
gscaler instance.
Regards,
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
Re: [RFC/PATCH 02/13] media: s5p-csis: Add device tree support
Hi Sylwester, On Tuesday 17 July 2012 20:16:23 Sylwester Nawrocki wrote: On 07/16/2012 10:55 AM, Guennadi Liakhovetski wrote: Hi Sylwester Thanks for your comments to my RFC and for pointing out to this your earlier patch series. Unfortunately, I missed in in May, let me try to provide some thoughts about this, we should really try to converge our proposals. Maybe a discussion at KS would help too. Thank you for the review. I was happy to see your RFC, as previously there seemed to be not much interest in DT among the media guys. Certainly, we need to work on a common approach to ensure interoperability of existing drivers and to avoid having people inventing different bindings for common features. I would also expect some share of device specific bindings, as diversity of media devices is significant. I'd be great to discuss these things at KS, especially support for proper suspend/resume sequences. Also having common sessions with other subsystems folks, like ASoC, for example, might be a good idea. I'm not sure if I'll be travelling to the KS though. :) On Fri, 25 May 2012, Sylwester Nawrocki wrote: s5p-csis is platform device driver for MIPI-CSI frontend to the FIMC (camera host interface DMA engine and image processor). This patch adds support for instantiating the MIPI-CSIS devices from DT and parsing all SoC and board specific properties from device tree. The MIPI DPHY control callback is now called directly from within the driver, the platform code must ensure this callback does the right thing for each SoC. The cell-index property is used to ensure proper signal routing, from physical camera port, through MIPI-CSI2 receiver to the DMA engine (FIMC?). It's also helpful in exposing the device topology in user space at /dev/media? devnode (Media Controller API). This patch also defines a common property (data-lanes) for MIPI-CSI receivers and transmitters. Signed-off-by: Sylwester Nawrockis.nawro...@samsung.com Signed-off-by: Kyungmin Parkkyungmin.p...@samsung.com --- Documentation/devicetree/bindings/video/mipi.txt |5 + .../bindings/video/samsung-mipi-csis.txt | 47 ++ drivers/media/video/s5p-fimc/mipi-csis.c | 97 +++- drivers/media/video/s5p-fimc/mipi-csis.h |1 + 4 files changed, 126 insertions(+), 24 deletions(-) create mode 100644 Documentation/devicetree/bindings/video/mipi.txt create mode 100644 Documentation/devicetree/bindings/video/samsung-mipi-csis.txt diff --git a/Documentation/devicetree/bindings/video/mipi.txt b/Documentation/devicetree/bindings/video/mipi.txt new file mode 100644 index 000..5aed285 --- /dev/null +++ b/Documentation/devicetree/bindings/video/mipi.txt @@ -0,0 +1,5 @@ +Common properties of MIPI-CSI1 and MIPI-CSI2 receivers and transmitters + + - data-lanes : number of differential data lanes wired and actively used in + communication between the transmitter and the receiver, this + excludes the clock lane; Wouldn't it be better to use the standard bus-width DT property? I can't see any problems with using bus-width. It seems sufficient and could indeed be better, without a need to invent new MIPI-CSI specific names. That was my first RFC on that and my perspective wasn't probably broad enough. :) What about CSI receivers that can reroute the lanes internally ? We would need to specify lane indices for each lane then, maybe with something like clock-lane = 0; data-lanes = 2 3 1; For receivers that can't reroute lanes internally, the data-lanes property would be need to specify lanes in sequence. data-lanes = 1 2 3; -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/2] Initial version of the RDS-decoder library Signed-off-by: Konke Radlow krad...@cisco.com
On Thu 26 July 2012 16:28:20 Ezequiel Garcia wrote: Hi Konke, + +libv4l2rds_la_SOURCES = libv4l2rds.c +libv4l2rds_la_CPPFLAGS = -fvisibility=hidden $(ENFORCE_LIBV4L_STATIC) -std=c99 +libv4l2rds_la_LDFLAGS = -version-info 0 -lpthread $(DLOPEN_LIBS) $(ENFORCE_LIBV4L_STATIC) diff --git a/lib/libv4l2rds/libv4l2rds.c b/lib/libv4l2rds/libv4l2rds.c new file mode 100644 index 000..0bacaa2 --- /dev/null +++ b/lib/libv4l2rds/libv4l2rds.c @@ -0,0 +1,871 @@ +/* + * Copyright 2012 Cisco Systems, Inc. and/or its affiliates. All rights reserved. [snip] + * This program is free software; you can redistribute it and/or modify Just a -probably silly- question... How can it be free software yet claim All rights reserved ? Is this correct? Yeah, it's correct. I had the same question when I was told that this was the correct phrase to use. Check other copyright lines in the kernel and you'll see the same line. Since it is covered by the LGPLv2 license there aren't many rights to reserve :-) The only right there is in practice is the right to decide whether or not to allow other licenses as well. 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: [RFC PATCH 1/2] Initial version of the RDS-decoder library Signed-off-by: Konke Radlow krad...@cisco.com
On Thu, Jul 26, 2012 at 11:39 AM, Hans Verkuil hverk...@xs4all.nl wrote: On Thu 26 July 2012 16:28:20 Ezequiel Garcia wrote: Hi Konke, + +libv4l2rds_la_SOURCES = libv4l2rds.c +libv4l2rds_la_CPPFLAGS = -fvisibility=hidden $(ENFORCE_LIBV4L_STATIC) -std=c99 +libv4l2rds_la_LDFLAGS = -version-info 0 -lpthread $(DLOPEN_LIBS) $(ENFORCE_LIBV4L_STATIC) diff --git a/lib/libv4l2rds/libv4l2rds.c b/lib/libv4l2rds/libv4l2rds.c new file mode 100644 index 000..0bacaa2 --- /dev/null +++ b/lib/libv4l2rds/libv4l2rds.c @@ -0,0 +1,871 @@ +/* + * Copyright 2012 Cisco Systems, Inc. and/or its affiliates. All rights reserved. [snip] + * This program is free software; you can redistribute it and/or modify Just a -probably silly- question... How can it be free software yet claim All rights reserved ? Is this correct? Yeah, it's correct. I had the same question when I was told that this was the correct phrase to use. Check other copyright lines in the kernel and you'll see the same line. Since it is covered by the LGPLv2 license there aren't many rights to reserve :-) The only right there is in practice is the right to decide whether or not to allow other licenses as well. For some reason, I must read this several times before really catching it. Thanks for the explanation, 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: [RFC/PATCH 01/13] ARM: Samsung: Extend MIPI PHY callback with an index argument
Hi Sylwester, On Friday 25 May 2012 21:52:40 Sylwester Nawrocki wrote: For systems instantiated from device tree struct platform_device id field is always -1, add an 'id' argument to the s5p_csis_phy_enable() function so the MIPI-CSIS hardware instance index can be passed in by driver, for CONFIG_OF=y. Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- arch/arm/plat-s5p/setup-mipiphy.c | 20 arch/arm/plat-samsung/include/plat/mipi_csis.h | 10 ++ 2 files changed, 14 insertions(+), 16 deletions(-) diff --git a/arch/arm/plat-s5p/setup-mipiphy.c b/arch/arm/plat-s5p/setup-mipiphy.c index 683c466..146ecc3 100644 --- a/arch/arm/plat-s5p/setup-mipiphy.c +++ b/arch/arm/plat-s5p/setup-mipiphy.c @@ -14,24 +14,19 @@ #include linux/spinlock.h #include mach/regs-clock.h -static int __s5p_mipi_phy_control(struct platform_device *pdev, +static int __s5p_mipi_phy_control(struct platform_device *pdev, int id, bool on, u32 reset) What about removing the pdev argument, as it's now not needed ? -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] v4l2: typos
Signed-off-by: Michael Jones michael.jo...@matrix-vision.de --- Documentation/video4linux/v4l2-framework.txt |2 +- drivers/media/video/omap3isp/ispqueue.c |2 +- drivers/media/video/omap3isp/ispresizer.c|6 +++--- drivers/media/video/v4l2-common.c|2 +- include/media/v4l2-common.h |4 ++-- include/media/v4l2-subdev.h |2 +- 6 files changed, 9 insertions(+), 9 deletions(-) diff --git a/Documentation/video4linux/v4l2-framework.txt b/Documentation/video4linux/v4l2-framework.txt index 1f59052..fa01440 100644 --- a/Documentation/video4linux/v4l2-framework.txt +++ b/Documentation/video4linux/v4l2-framework.txt @@ -666,7 +666,7 @@ can take a long time you may want to do your own locking for the buffer queuing ioctls. If you want still finer-grained locking then you have to set mutex_lock to NULL -and do you own locking completely. +and do your own locking completely. It is up to the driver developer to decide which method to use. However, if your driver has high-latency operations (for example, changing the exposure diff --git a/drivers/media/video/omap3isp/ispqueue.c b/drivers/media/video/omap3isp/ispqueue.c index 9bebb1e..61fc87d 100644 --- a/drivers/media/video/omap3isp/ispqueue.c +++ b/drivers/media/video/omap3isp/ispqueue.c @@ -647,7 +647,7 @@ static int isp_video_queue_alloc(struct isp_video_queue *queue, if (ret 0) return ret; - /* Bail out of no buffers should be allocated. */ + /* Bail out if no buffers should be allocated. */ if (nbuffers == 0) return 0; diff --git a/drivers/media/video/omap3isp/ispresizer.c b/drivers/media/video/omap3isp/ispresizer.c index 14041c9..46ac6df 100644 --- a/drivers/media/video/omap3isp/ispresizer.c +++ b/drivers/media/video/omap3isp/ispresizer.c @@ -690,7 +690,7 @@ static void resizer_print_status(struct isp_res_device *res) } /* - * resizer_calc_ratios - Helper function for calculate resizer ratios + * resizer_calc_ratios - Helper function for calculating resizer ratios * @res: pointer to resizer private data structure * @input: input frame size * @output: output frame size @@ -734,7 +734,7 @@ static void resizer_print_status(struct isp_res_device *res) * value will still satisfy the original inequality, as b will disappear when * the expression will be shifted right by 8. * - * The reverted the equations thus become + * The reverted equations thus become * * - 8-phase, 4-tap mode * hrsz = ((iw - 7) * 256 + 255 - 16 - 32 * sph) / (ow - 1) @@ -759,7 +759,7 @@ static void resizer_print_status(struct isp_res_device *res) * loop', the smallest of the ratio values will be used, never exceeding the * requested input size. * - * We first clamp the output size according to the hardware capabilitie to avoid + * We first clamp the output size according to the hardware capability to avoid * auto-cropping the input more than required to satisfy the TRM equations. The * minimum output size is achieved with a scaling factor of 1024. It is thus * computed using the 7-tap equations. diff --git a/drivers/media/video/v4l2-common.c b/drivers/media/video/v4l2-common.c index 1baec83..105f88c 100644 --- a/drivers/media/video/v4l2-common.c +++ b/drivers/media/video/v4l2-common.c @@ -418,7 +418,7 @@ EXPORT_SYMBOL_GPL(v4l2_i2c_tuner_addrs); #if defined(CONFIG_SPI) -/* Load a spi sub-device. */ +/* Load an spi sub-device. */ void v4l2_spi_subdev_init(struct v4l2_subdev *sd, struct spi_device *spi, const struct v4l2_subdev_ops *ops) diff --git a/include/media/v4l2-common.h b/include/media/v4l2-common.h index a298ec4..4404829 100644 --- a/include/media/v4l2-common.h +++ b/include/media/v4l2-common.h @@ -133,7 +133,7 @@ struct v4l2_subdev *v4l2_i2c_new_subdev_board(struct v4l2_device *v4l2_dev, struct i2c_adapter *adapter, struct i2c_board_info *info, const unsigned short *probe_addrs); -/* Initialize an v4l2_subdev with data from an i2c_client struct */ +/* Initialize a v4l2_subdev with data from an i2c_client struct */ void v4l2_i2c_subdev_init(struct v4l2_subdev *sd, struct i2c_client *client, const struct v4l2_subdev_ops *ops); /* Return i2c client address of v4l2_subdev. */ @@ -166,7 +166,7 @@ struct spi_device; struct v4l2_subdev *v4l2_spi_new_subdev(struct v4l2_device *v4l2_dev, struct spi_master *master, struct spi_board_info *info); -/* Initialize an v4l2_subdev with data from an spi_device struct */ +/* Initialize a v4l2_subdev with data from an spi_device struct */ void v4l2_spi_subdev_init(struct v4l2_subdev *sd, struct spi_device *spi, const struct v4l2_subdev_ops *ops); #endif diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h index c35a354..4cc1652 100644 --- a/include/media/v4l2-subdev.h +++ b/include/media/v4l2-subdev.h @@ -120,7 +120,7 @@ struct
Re: [PATCH] v4l2: typos
On Thu 26 July 2012 16:48:25 Michael Jones wrote: Signed-off-by: Michael Jones michael.jo...@matrix-vision.de Acked-by: Hans Verkuil hans.verk...@cisco.com Yup, all typos :-) Thanks, Hans --- Documentation/video4linux/v4l2-framework.txt |2 +- drivers/media/video/omap3isp/ispqueue.c |2 +- drivers/media/video/omap3isp/ispresizer.c|6 +++--- drivers/media/video/v4l2-common.c|2 +- include/media/v4l2-common.h |4 ++-- include/media/v4l2-subdev.h |2 +- 6 files changed, 9 insertions(+), 9 deletions(-) diff --git a/Documentation/video4linux/v4l2-framework.txt b/Documentation/video4linux/v4l2-framework.txt index 1f59052..fa01440 100644 --- a/Documentation/video4linux/v4l2-framework.txt +++ b/Documentation/video4linux/v4l2-framework.txt @@ -666,7 +666,7 @@ can take a long time you may want to do your own locking for the buffer queuing ioctls. If you want still finer-grained locking then you have to set mutex_lock to NULL -and do you own locking completely. +and do your own locking completely. It is up to the driver developer to decide which method to use. However, if your driver has high-latency operations (for example, changing the exposure diff --git a/drivers/media/video/omap3isp/ispqueue.c b/drivers/media/video/omap3isp/ispqueue.c index 9bebb1e..61fc87d 100644 --- a/drivers/media/video/omap3isp/ispqueue.c +++ b/drivers/media/video/omap3isp/ispqueue.c @@ -647,7 +647,7 @@ static int isp_video_queue_alloc(struct isp_video_queue *queue, if (ret 0) return ret; - /* Bail out of no buffers should be allocated. */ + /* Bail out if no buffers should be allocated. */ if (nbuffers == 0) return 0; diff --git a/drivers/media/video/omap3isp/ispresizer.c b/drivers/media/video/omap3isp/ispresizer.c index 14041c9..46ac6df 100644 --- a/drivers/media/video/omap3isp/ispresizer.c +++ b/drivers/media/video/omap3isp/ispresizer.c @@ -690,7 +690,7 @@ static void resizer_print_status(struct isp_res_device *res) } /* - * resizer_calc_ratios - Helper function for calculate resizer ratios + * resizer_calc_ratios - Helper function for calculating resizer ratios * @res: pointer to resizer private data structure * @input: input frame size * @output: output frame size @@ -734,7 +734,7 @@ static void resizer_print_status(struct isp_res_device *res) * value will still satisfy the original inequality, as b will disappear when * the expression will be shifted right by 8. * - * The reverted the equations thus become + * The reverted equations thus become * * - 8-phase, 4-tap mode * hrsz = ((iw - 7) * 256 + 255 - 16 - 32 * sph) / (ow - 1) @@ -759,7 +759,7 @@ static void resizer_print_status(struct isp_res_device *res) * loop', the smallest of the ratio values will be used, never exceeding the * requested input size. * - * We first clamp the output size according to the hardware capabilitie to avoid + * We first clamp the output size according to the hardware capability to avoid * auto-cropping the input more than required to satisfy the TRM equations. The * minimum output size is achieved with a scaling factor of 1024. It is thus * computed using the 7-tap equations. diff --git a/drivers/media/video/v4l2-common.c b/drivers/media/video/v4l2-common.c index 1baec83..105f88c 100644 --- a/drivers/media/video/v4l2-common.c +++ b/drivers/media/video/v4l2-common.c @@ -418,7 +418,7 @@ EXPORT_SYMBOL_GPL(v4l2_i2c_tuner_addrs); #if defined(CONFIG_SPI) -/* Load a spi sub-device. */ +/* Load an spi sub-device. */ void v4l2_spi_subdev_init(struct v4l2_subdev *sd, struct spi_device *spi, const struct v4l2_subdev_ops *ops) diff --git a/include/media/v4l2-common.h b/include/media/v4l2-common.h index a298ec4..4404829 100644 --- a/include/media/v4l2-common.h +++ b/include/media/v4l2-common.h @@ -133,7 +133,7 @@ struct v4l2_subdev *v4l2_i2c_new_subdev_board(struct v4l2_device *v4l2_dev, struct i2c_adapter *adapter, struct i2c_board_info *info, const unsigned short *probe_addrs); -/* Initialize an v4l2_subdev with data from an i2c_client struct */ +/* Initialize a v4l2_subdev with data from an i2c_client struct */ void v4l2_i2c_subdev_init(struct v4l2_subdev *sd, struct i2c_client *client, const struct v4l2_subdev_ops *ops); /* Return i2c client address of v4l2_subdev. */ @@ -166,7 +166,7 @@ struct spi_device; struct v4l2_subdev *v4l2_spi_new_subdev(struct v4l2_device *v4l2_dev, struct spi_master *master, struct spi_board_info *info); -/* Initialize an v4l2_subdev with data from an spi_device struct */ +/* Initialize a v4l2_subdev with data from an spi_device struct */ void v4l2_spi_subdev_init(struct v4l2_subdev *sd, struct spi_device *spi, const
Re: [RFC/PATCH 05/13] media: s5p-fimc: Add device tree support for FIMC devices
Hi Sylwester, On Wednesday 18 July 2012 21:53:34 Sylwester Nawrocki wrote: On 07/18/2012 10:17 AM, Guennadi Liakhovetski wrote: On Tue, 17 Jul 2012, Sylwester Nawrocki wrote: On 07/16/2012 11:13 AM, Guennadi Liakhovetski wrote: On Fri, 25 May 2012, Sylwester Nawrocki wrote: Signed-off-by: Sylwester Nawrockis.nawro...@samsung.com Signed-off-by: Karol Lewandowskik.lewando...@samsung.com Signed-off-by: Kyungmin Parkkyungmin.p...@samsung.com From the documentation below I think, I understand what it does, but why is it needed? It doesn't describe your video subsystem topology, right? How various subdevices are connected. It just lists them all in one node... A description for this patch would be very welcome IMHO and, maybe, such a node can be completely avoided? Sorry, I'll provide better description in next iteration. It's true it doesn't describe the topology in detail, as there are multiple one-to many possible connections between sub-devices. An exact topology is coded in the driver and can be changed through MC API. The samsung,camif-mux-id and video-bus-type properties at sensor nodes just specify to which physical SoC camera port an image sensor is connected. So, don't you think my media-link child nodes are a good solution for this? Not quite yet ;) It would be good to see some example implementation and how it actually works. Originally the all camera devices were supposed to land under common 'camera' node. And a top level driver would be registering all platform devices. With this approach it would be possible to better control PM handling (which currently depends on an order of registering devices to the driver core). But then we discovered that we couldn't use OF_DEV_AUXDATA in such case, which was required to preserve platform device names, in order for the clock API to work. So I've moved some sub-devices out of 'camera' node and have added only a list of phandles to them in that node. This is rather a cheap workaround.. I think all camera sub-devices should be placed under common node, as there are some properties that don't belong to any sub-node: GPIO config, clocks, to name a few. Of course simpler devices might not need such a composite node. I think we can treat the sub-device interdependencies as an issue separate from a need for a common node. If some devices need to reflect the topology better, we probably could include in some nodes (a list of) phandles to other nodes. This could ease parsing the topology at the drivers, by using existing OF infrastructure. Ok, I think you have some good ideas in your RFC's, an interesting question now is - how to proceed. Do you think we'd be able to work out a combined RFC? Or would you prefer to make two versions and then see what others think? In either case it would be nice, I think, if you could try to separate what you see as common V4L DT bindings, then we could discuss that separately. Whereas what you think is private to your hardware, we can also look at for common ideas, or maybe even some of those properties we'll wake to make common too. I think we need a one combined RFC and continue discussions in one thread. Agreed. Still, our proposals are quite different, but I believe we need something in between. I presume we should focus more to have common bindings for subdevs that are reused among different host/ISP devices, i.e. sensors and encoders. For simple host interfaces we can likely come up with common binding patterns, but more complex processing pipelines may require a sort of individual approach. The suspend/resume handling is still something I don't have an idea on how the solution for might look like.. Instantiating all devices from a top level driver could help, but it is only going to work when platforms are converted to the common clock framework and have their clocks instantiated from device tree. This week I'm out of office, and next one or two I have some pending assignments. So there might be some delay before I can dedicate some reasonable amount of time to carry on with that topic. I unfortunately won't be attending KS this time. That's bad news :-( I still think this topic should be discussed during KS, I expect several developers to be interested. The media workshop might not be the best venue though, as we might need quite a lot of time. Until KS let's continue the discussion by e-mail. I'll try to prepare some summary with topics that appear common. And also to restructure my RFC series to better separate new common features and specific H/W support. In the meantime we could possibly continue discussions in your RFC thread. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mceusb: Add Twisted Melon USB IDs
On 12-07-11 06:53 PM, Mark Lord wrote:
Add USB identifiers for MCE compatible I/R transceivers from Twisted Melon.
Signed-off-by: Mark Lord ml...@pobox.com
---
Mauro, please queue this up for inclusion in linux-3.6.
Patch is also attached to bypass emailer mangling.
Thanks.
--- linux-3.5-rc6/drivers/media/rc/mceusb.c 2012-07-07 20:23:56.0
-0400
+++ new/drivers/media/rc/mceusb.c 2012-07-11 18:44:03.113727658 -0400
@@ -199,6 +199,7 @@
#define VENDOR_REALTEK 0x0bda
#define VENDOR_TIVO 0x105a
#define VENDOR_CONEXANT 0x0572
+#define VENDOR_TWISTEDMELON 0x2596
enum mceusb_model_type {
MCE_GEN2 = 0, /* Most boards */
@@ -391,6 +392,12 @@
/* Conexant Hybrid TV RDU253S Polaris */
{ USB_DEVICE(VENDOR_CONEXANT, 0x58a5),
.driver_info = CX_HYBRID_TV },
+ /* Twisted Melon Inc. - Manta Mini Receiver */
+ { USB_DEVICE(VENDOR_TWISTEDMELON, 0x8008) },
+ /* Twisted Melon Inc. - Manta Pico Receiver */
+ { USB_DEVICE(VENDOR_TWISTEDMELON, 0x8016) },
+ /* Twisted Melon Inc. - Manta Transceiver */
+ { USB_DEVICE(VENDOR_TWISTEDMELON, 0x8042) },
/* Terminating entry */
{ }
};
Mauro, what is the status of this patch?
Is it going upstream through your tree for Linux-3.6?
If not, I'll send it directly to Linus.
Thanks
--
Mark Lord
Real-Time Remedies Inc.
ml...@pobox.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 09/13] media: s5k6aa: Add support for device tree based instantiation
Hi Sylwester, On Wednesday 18 July 2012 11:18:33 Sylwester Nawrocki wrote: On 07/16/2012 11:42 AM, Guennadi Liakhovetski wrote: On Fri, 25 May 2012, Sylwester Nawrocki wrote: The driver initializes all board related properties except the s_power() callback to board code. The platforms that require this callback are not supported by this driver yet for CONFIG_OF=y. Signed-off-by: Sylwester Nawrockis.nawro...@samsung.com Signed-off-by: Bartlomiej Zolnierkiewiczb.zolnier...@samsung.com Signed-off-by: Kyungmin Parkkyungmin.p...@samsung.com --- .../bindings/camera/samsung-s5k6aafx.txt | 57 + drivers/media/video/s5k6aa.c | 129 ++-- 2 files changed, 146 insertions(+), 40 deletions(-) create mode 100644 Documentation/devicetree/bindings/camera/samsung-s5k6aafx.txt diff --git a/Documentation/devicetree/bindings/camera/samsung-s5k6aafx.txt b/Documentation/devicetree/bindings/camera/samsung-s5k6aafx.txt new file mode 100644 index 000..6685a9c --- /dev/null +++ b/Documentation/devicetree/bindings/camera/samsung-s5k6aafx.txt @@ -0,0 +1,57 @@ +Samsung S5K6AAFX camera sensor +-- + +Required properties: + +- compatible : samsung,s5k6aafx; +- reg : base address of the device on I2C bus; You said you ended up putting your sensors outside of I2C busses, is this one of changes, that are present in your git-tree but not in this series? No, I must have been not clear enough on that. Our idea was to keep I2C slave device nodes as an I2C controller's child nodes, according to the current convention. The 'sensor' nodes (the 'camera''s children) would only contain a phandle to a respective I2C slave node. This implies that we cannot access I2C bus in I2C client's device probe() callback. An actual H/W access could begin only from within and after invocation of v4l2_subdev .registered callback.. That's how I've envisioned the DT bindings for sensors as well, this sounds good. The real challenge will be to get hold of the subdev to register it without race conditions. +- video-itu-601-bus : parallel bus with HSYNC and VSYNC - ITU-R BT.601; If this is a boolean property, it cannot be required? Otherwise, as discussed in a different patch comment, this property might not be required, and if it is, I would use the same definition for both the camera interface and for sensors. Yeah, that's an omission, a leftover from previous versions. It should have been 'video-bus-type', for this series. Here is the updated binding documentation: 8-- Required properties: - compatible : samsung,s5k6aafx; - reg : base address of the device on I2C bus; - vdd_core-supply : digital core voltage supply 1.5V (1.4V to 1.6V); - vdda-supply : analog circuits voltage supply 2.8V (2.6V to 3.0V); - vdd_reg-supply : regulator input voltage supply 1.8V (1.7V to 1.9V) or 2.8V (2.6V to 3.0); - vddio-supply : I/O voltage supply 1.8V (1.65V to 1.95V) or 2.8V (2.5V to 3.1V); - video-bus-type : sensor video output bus type, must be one of: itu-601, mipi-csi2; - clock-frequency : the sensor's master clock frequency in Hz; Optional properties: - data-lanes : number of physical MIPI-CSI2 data lanes used (default is 2 when this property is not specified); - gpios : specifies gpios connected to the sensor's reset reset (RSTN) and standby (STBYN) pins, the order of gpios is: RSTN, STBYN; If any of these gpios is not used, its specifier shall be 0; - samsung,s5k6aa-gpio-lvls : this property (bits [1:0]) specifies an active state of the S5K6AAFX reset and stand-by signals; the meaning of bits is: bit[1:0] = [RST, STBY], e.g. bit[1] = 0 indicates the GPIO driving the S5K6AAFX's standby pin should be set to 1 to bring the sensor out from stand-by to normal operation state. - samsung,s5k6aa-hflip : sets the default horizontal image flipping; - samsung,s5k6aa-vflip : sets the default vertical image flipping; 8-- +- vdd_core-supply : digital core voltage supply 1.5V (1.4V to 1.6V); +- vdda-supply : analog power voltage supply 2.8V (2.6V to 3.0V); +- vdd_reg-supply : regulator input power voltage supply 1.8V (1.7V to 1.9V) + or 2.8V (2.6V to 3.0); I think, underscores in property names are generally frowned upon. Indeed, I felt something might be wrong here;) It's in this form because I just copied regulator supply names from the existing driver. And I didn't want to change them, to avoid updating them in all board files where they're used. Thanks for pointing it out, I'll fix that in next iteration. +- vddio-supply : I/O voltage supply 1.8V
Re: [RFC/PATCH 09/13] media: s5k6aa: Add support for device tree based instantiation
Hi Sylwester,
On Friday 25 May 2012 21:52:48 Sylwester Nawrocki wrote:
The driver initializes all board related properties except the s_power()
callback to board code. The platforms that require this callback are not
supported by this driver yet for CONFIG_OF=y.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
.../bindings/camera/samsung-s5k6aafx.txt | 57 +
drivers/media/video/s5k6aa.c | 129 -
2 files changed, 146 insertions(+), 40 deletions(-)
create mode 100644
Documentation/devicetree/bindings/camera/samsung-s5k6aafx.txt
diff --git a/Documentation/devicetree/bindings/camera/samsung-s5k6aafx.txt
b/Documentation/devicetree/bindings/camera/samsung-s5k6aafx.txt new file
mode 100644
index 000..6685a9c
--- /dev/null
+++ b/Documentation/devicetree/bindings/camera/samsung-s5k6aafx.txt
@@ -0,0 +1,57 @@
+Samsung S5K6AAFX camera sensor
+--
+
+Required properties:
+
+- compatible : samsung,s5k6aafx;
+- reg : base address of the device on I2C bus;
+- video-itu-601-bus : parallel bus with HSYNC and VSYNC - ITU-R BT.601;
+- vdd_core-supply : digital core voltage supply 1.5V (1.4V to 1.6V);
+- vdda-supply : analog power voltage supply 2.8V (2.6V to 3.0V);
+- vdd_reg-supply : regulator input power voltage supply 1.8V (1.7V to 1.9V)
+or 2.8V (2.6V to 3.0);
+- vddio-supply : I/O voltage supply 1.8V (1.65V to 1.95V)
+ or 2.8V (2.5V to 3.1V);
+
+Optional properties:
+
+- clock-frequency : the IP's main (system bus) clock frequency in Hz, the
default
Is that the input clock frequency ? Can't it vary ? Instead of accessing the
sensor clock frequency from the FIMC driver you should reference a clock in
the sensor DT node. That obviously requires generic clock support, which might
not be available for your platform yet (that's one of the reasons the OMAP3
ISP driver doesn't support DT yet).
+ value when this property is not specified is 24 MHz;
+- data-lanes : number of physical lanes used (default 2 if not specified);
+- gpio-stby : specifies the S5K6AA_STBY GPIO
+- gpio-rst : specifies the S5K6AA_RST GPIO
+- samsung,s5k6aa-inv-stby : set inverted S5K6AA_STBY GPIO level;
+- samsung,s5k6aa-inv-rst : set inverted S5K6AA_RST GPIO level;
+- samsung,s5k6aa-hflip : set the default horizontal image flipping;
+- samsung,s5k6aa-vflip : set the default vertical image flipping;
+
+
+Example:
+
+ gpl2: gpio-controller@0 {
+ };
+
+ reg0: regulator@0 {
+ };
+
+ reg1: regulator@1 {
+ };
+
+ reg2: regulator@2 {
+ };
+
+ reg3: regulator@3 {
+ };
+
+ s5k6aafx@3c {
+ compatible = samsung,s5k6aafx;
+ reg = 0x3c;
+ clock-frequency = 2400;
+ gpio-rst = gpl2 0 2 0 3;
+ gpio-stby = gpl2 1 2 0 3;
+ video-itu-601-bus;
+ vdd_core-supply = reg0;
+ vdda-supply = reg1;
+ vdd_reg-supply = reg2;
+ vddio-supply = reg3;
+ };
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] omap3isp: #include videodev2.h in omap3isp.h
include/linux/omap3isp.h uses BASE_VIDIOC_PRIVATE from include/linux/videodev2.h but didn't include this file. Signed-off-by: Michael Jones michael.jo...@matrix-vision.de --- include/linux/omap3isp.h |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/include/linux/omap3isp.h b/include/linux/omap3isp.h index c73a34c..e7a79db 100644 --- a/include/linux/omap3isp.h +++ b/include/linux/omap3isp.h @@ -28,6 +28,7 @@ #define OMAP3_ISP_USER_H #include linux/types.h +#include linux/videodev2.h /* * Private IOCTLs -- 1.7.4.1 MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner, Erhard Meier -- 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] omap3isp: #include videodev2.h in omap3isp.h
Hi Michael, On Thursday 26 July 2012 17:31:51 Michael Jones wrote: include/linux/omap3isp.h uses BASE_VIDIOC_PRIVATE from include/linux/videodev2.h but didn't include this file. Signed-off-by: Michael Jones michael.jo...@matrix-vision.de Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com I've added the patch to my tree. --- include/linux/omap3isp.h |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/include/linux/omap3isp.h b/include/linux/omap3isp.h index c73a34c..e7a79db 100644 --- a/include/linux/omap3isp.h +++ b/include/linux/omap3isp.h @@ -28,6 +28,7 @@ #define OMAP3_ISP_USER_H #include linux/types.h +#include linux/videodev2.h /* * Private IOCTLs -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] cx25840: Declare MODULE_FIRMWARE usage
Cc: Mauro Carvalho Chehab mche...@infradead.org
Cc: linux-media@vger.kernel.org
Signed-off-by: Tim Gardner tim.gard...@canonical.com
---
drivers/media/video/cx25840/cx25840-firmware.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/media/video/cx25840/cx25840-firmware.c
b/drivers/media/video/cx25840/cx25840-firmware.c
index 8150200..b3169f9 100644
--- a/drivers/media/video/cx25840/cx25840-firmware.c
+++ b/drivers/media/video/cx25840/cx25840-firmware.c
@@ -61,6 +61,10 @@ static void end_fw_load(struct i2c_client *client)
cx25840_write(client, 0x803, 0x03);
}
+#define CX2388x_FIRMWARE v4l-cx23885-avcore-01.fw
+#define CX231xx_FIRMWARE v4l-cx231xx-avcore-01.fw
+#define CX25840_FIRMWARE v4l-cx25840.fw
+
static const char *get_fw_name(struct i2c_client *client)
{
struct cx25840_state *state = to_state(i2c_get_clientdata(client));
@@ -68,10 +72,10 @@ static const char *get_fw_name(struct i2c_client *client)
if (firmware[0])
return firmware;
if (is_cx2388x(state))
- return v4l-cx23885-avcore-01.fw;
+ return CX2388x_FIRMWARE;
if (is_cx231xx(state))
- return v4l-cx231xx-avcore-01.fw;
- return v4l-cx25840.fw;
+ return CX231xx_FIRMWARE;
+ return CX25840_FIRMWARE;
}
static int check_fw_load(struct i2c_client *client, int size)
@@ -164,3 +168,8 @@ int cx25840_loadfw(struct i2c_client *client)
return check_fw_load(client, size);
}
+
+MODULE_FIRMWARE(CX2388x_FIRMWARE);
+MODULE_FIRMWARE(CX231xx_FIRMWARE);
+MODULE_FIRMWARE(CX25840_FIRMWARE);
+
--
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] cx18: Declare MODULE_FIRMWARE usage
Cc: Andy Walls awa...@md.metrocast.net
Cc: Mauro Carvalho Chehab mche...@infradead.org
Cc: ivtv-de...@ivtvdriver.org
Cc: linux-media@vger.kernel.org
Signed-off-by: Tim Gardner tim.gard...@canonical.com
---
drivers/media/video/cx18/cx18-driver.c |1 +
drivers/media/video/cx18/cx18-firmware.c | 10 --
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/media/video/cx18/cx18-driver.c
b/drivers/media/video/cx18/cx18-driver.c
index 7e5ffd6..c67733d 100644
--- a/drivers/media/video/cx18/cx18-driver.c
+++ b/drivers/media/video/cx18/cx18-driver.c
@@ -1357,3 +1357,4 @@ static void __exit module_cleanup(void)
module_init(module_start);
module_exit(module_cleanup);
+MODULE_FIRMWARE(XC2028_DEFAULT_FIRMWARE);
diff --git a/drivers/media/video/cx18/cx18-firmware.c
b/drivers/media/video/cx18/cx18-firmware.c
index b85c292..a1c1cec 100644
--- a/drivers/media/video/cx18/cx18-firmware.c
+++ b/drivers/media/video/cx18/cx18-firmware.c
@@ -376,6 +376,9 @@ void cx18_init_memory(struct cx18 *cx)
cx18_write_reg(cx, 0x0101, CX18_WMB_CLIENT14); /* AVO */
}
+#define CX18_CPU_FIRMWARE v4l-cx23418-cpu.fw
+#define CX18_APU_FIRMWARE v4l-cx23418-apu.fw
+
int cx18_firmware_init(struct cx18 *cx)
{
u32 fw_entry_addr;
@@ -400,7 +403,7 @@ int cx18_firmware_init(struct cx18 *cx)
cx18_sw1_irq_enable(cx, IRQ_CPU_TO_EPU | IRQ_APU_TO_EPU);
cx18_sw2_irq_enable(cx, IRQ_CPU_TO_EPU_ACK | IRQ_APU_TO_EPU_ACK);
- sz = load_cpu_fw_direct(v4l-cx23418-cpu.fw, cx-enc_mem, cx);
+ sz = load_cpu_fw_direct(CX18_CPU_FIRMWARE, cx-enc_mem, cx);
if (sz = 0)
return sz;
@@ -408,7 +411,7 @@ int cx18_firmware_init(struct cx18 *cx)
cx18_init_scb(cx);
fw_entry_addr = 0;
- sz = load_apu_fw_direct(v4l-cx23418-apu.fw, cx-enc_mem, cx,
+ sz = load_apu_fw_direct(CX18_APU_FIRMWARE, cx-enc_mem, cx,
fw_entry_addr);
if (sz = 0)
return sz;
@@ -451,3 +454,6 @@ int cx18_firmware_init(struct cx18 *cx)
cx18_write_reg_expect(cx, 0x14001400, 0xc78110, 0x1400, 0x14001400);
return 0;
}
+
+MODULE_FIRMWARE(CX18_CPU_FIRMWARE);
+MODULE_FIRMWARE(CX18_APU_FIRMWARE);
--
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: cx231xx interlace-like artifacts
On Wed, Jul 25, 2012 at 8:51 PM, Yan Seiner y...@seiner.com wrote: Yan Seiner wrote: I just recently changed my vidcap to a Hauppage . Now I get these interlace-like artifacts: http://seiner.com/cz/rtpictures/2012_07_25T14h20m46sZ_0.451651_44.090619_-123.126059.jpg http://seiner.com/cz/rtpictures/2012_07_25T14h22m48sZ_0.224624_44.089669_-123.139100.jpg The video you are capturing is inherently interlaced. The Hauppauge device does raw capture of interlaced video, and takes no responsibility for deinterlacing. You need your application to do such deinterlacing (all the major applications support such: mplayer, vlc, tvtime, etc). cxx231x.h has the following line: #define CX231XX_INTERLACED_DEFAULT 1 Is there some way to turn off interlacing with a parameter? This parameter doesn't do what you think. It's used for cases where progressive video is being delivered by the camera (or progressive scan DVD player). It doesn't cause the device to perform deinterlacing. In short, everything you are seeing is expected behavior. If you want to deinterlace the video, you need to do this in the application. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] cx18: Declare MODULE_FIRMWARE usage
Missed a firmware file in cx18-av-firmware.c
rtg
--
Tim Gardner tim.gard...@canonical.com
From 9b4be013f173efc12bb2776394bf6a5abb8725b6 Mon Sep 17 00:00:00 2001
From: Tim Gardner tim.gard...@canonical.com
Date: Thu, 26 Jul 2012 11:03:51 -0600
Subject: [PATCH v2] cx18: Declare MODULE_FIRMWARE usage
Cc: Andy Walls awa...@md.metrocast.net
Cc: Mauro Carvalho Chehab mche...@infradead.org
Cc: ivtv-de...@ivtvdriver.org
Cc: linux-media@vger.kernel.org
Signed-off-by: Tim Gardner tim.gard...@canonical.com
---
drivers/media/video/cx18/cx18-av-firmware.c |2 ++
drivers/media/video/cx18/cx18-driver.c |1 +
drivers/media/video/cx18/cx18-firmware.c| 10 --
3 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/media/video/cx18/cx18-av-firmware.c b/drivers/media/video/cx18/cx18-av-firmware.c
index 280aa4d..a34fd08 100644
--- a/drivers/media/video/cx18/cx18-av-firmware.c
+++ b/drivers/media/video/cx18/cx18-av-firmware.c
@@ -221,3 +221,5 @@ int cx18_av_loadfw(struct cx18 *cx)
release_firmware(fw);
return 0;
}
+
+MODULE_FIRMWARE(FWFILE);
diff --git a/drivers/media/video/cx18/cx18-driver.c b/drivers/media/video/cx18/cx18-driver.c
index 7e5ffd6..c67733d 100644
--- a/drivers/media/video/cx18/cx18-driver.c
+++ b/drivers/media/video/cx18/cx18-driver.c
@@ -1357,3 +1357,4 @@ static void __exit module_cleanup(void)
module_init(module_start);
module_exit(module_cleanup);
+MODULE_FIRMWARE(XC2028_DEFAULT_FIRMWARE);
diff --git a/drivers/media/video/cx18/cx18-firmware.c b/drivers/media/video/cx18/cx18-firmware.c
index b85c292..a1c1cec 100644
--- a/drivers/media/video/cx18/cx18-firmware.c
+++ b/drivers/media/video/cx18/cx18-firmware.c
@@ -376,6 +376,9 @@ void cx18_init_memory(struct cx18 *cx)
cx18_write_reg(cx, 0x0101, CX18_WMB_CLIENT14); /* AVO */
}
+#define CX18_CPU_FIRMWARE v4l-cx23418-cpu.fw
+#define CX18_APU_FIRMWARE v4l-cx23418-apu.fw
+
int cx18_firmware_init(struct cx18 *cx)
{
u32 fw_entry_addr;
@@ -400,7 +403,7 @@ int cx18_firmware_init(struct cx18 *cx)
cx18_sw1_irq_enable(cx, IRQ_CPU_TO_EPU | IRQ_APU_TO_EPU);
cx18_sw2_irq_enable(cx, IRQ_CPU_TO_EPU_ACK | IRQ_APU_TO_EPU_ACK);
- sz = load_cpu_fw_direct(v4l-cx23418-cpu.fw, cx-enc_mem, cx);
+ sz = load_cpu_fw_direct(CX18_CPU_FIRMWARE, cx-enc_mem, cx);
if (sz = 0)
return sz;
@@ -408,7 +411,7 @@ int cx18_firmware_init(struct cx18 *cx)
cx18_init_scb(cx);
fw_entry_addr = 0;
- sz = load_apu_fw_direct(v4l-cx23418-apu.fw, cx-enc_mem, cx,
+ sz = load_apu_fw_direct(CX18_APU_FIRMWARE, cx-enc_mem, cx,
fw_entry_addr);
if (sz = 0)
return sz;
@@ -451,3 +454,6 @@ int cx18_firmware_init(struct cx18 *cx)
cx18_write_reg_expect(cx, 0x14001400, 0xc78110, 0x1400, 0x14001400);
return 0;
}
+
+MODULE_FIRMWARE(CX18_CPU_FIRMWARE);
+MODULE_FIRMWARE(CX18_APU_FIRMWARE);
--
1.7.9.5
[PATCH] ivtv: Declare MODULE_FIRMWARE usage
Cc: Andy Walls awa...@md.metrocast.net Cc: Mauro Carvalho Chehab mche...@infradead.org Cc: ivtv-de...@ivtvdriver.org Cc: linux-media@vger.kernel.org Signed-off-by: Tim Gardner tim.gard...@canonical.com --- drivers/media/video/ivtv/ivtv-firmware.c |4 1 file changed, 4 insertions(+) diff --git a/drivers/media/video/ivtv/ivtv-firmware.c b/drivers/media/video/ivtv/ivtv-firmware.c index 02c5ade..6ec7705 100644 --- a/drivers/media/video/ivtv/ivtv-firmware.c +++ b/drivers/media/video/ivtv/ivtv-firmware.c @@ -396,3 +396,7 @@ int ivtv_firmware_check(struct ivtv *itv, char *where) return res; } + +MODULE_FIRMWARE(CX2341X_FIRM_ENC_FILENAME); +MODULE_FIRMWARE(CX2341X_FIRM_DEC_FILENAME); +MODULE_FIRMWARE(IVTV_DECODE_INIT_MPEG_FILENAME); -- 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] cx231xx: Declare MODULE_FIRMWARE usage
Cc: Mauro Carvalho Chehab mche...@infradead.org Cc: Hans Verkuil hans.verk...@cisco.com Cc: linux-media@vger.kernel.org Signed-off-by: Tim Gardner tim.gard...@canonical.com --- drivers/media/video/cx231xx/cx231xx-417.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/media/video/cx231xx/cx231xx-417.c b/drivers/media/video/cx231xx/cx231xx-417.c index ce2f622..b024e51 100644 --- a/drivers/media/video/cx231xx/cx231xx-417.c +++ b/drivers/media/video/cx231xx/cx231xx-417.c @@ -2193,3 +2193,5 @@ int cx231xx_417_register(struct cx231xx *dev) return 0; } + +MODULE_FIRMWARE(CX231xx_FIRM_IMAGE_NAME); -- 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] cx23885: Declare MODULE_FIRMWARE usage
Cc: Mauro Carvalho Chehab mche...@infradead.org Cc: Steven Toth st...@kernellabs.com Cc: Hans Verkuil hans.verk...@cisco.com Cc: linux-media@vger.kernel.org Signed-off-by: Tim Gardner tim.gard...@canonical.com --- drivers/media/video/cx23885/cx23885-417.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/media/video/cx23885/cx23885-417.c b/drivers/media/video/cx23885/cx23885-417.c index f5c79e5..5d5052d 100644 --- a/drivers/media/video/cx23885/cx23885-417.c +++ b/drivers/media/video/cx23885/cx23885-417.c @@ -1786,3 +1786,5 @@ int cx23885_417_register(struct cx23885_dev *dev) return 0; } + +MODULE_FIRMWARE(CX23885_FIRM_IMAGE_NAME); -- 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] Add support for Prof Revolution DVB-S2 8000 PCI-E card
The device is based on STV0903 demodulator, STB6100 tuner
and CX23885 chipset; subsystem id: 8000:3034
Signed-off-by: Mariusz Bialonczyk ma...@skyboo.net
---
drivers/media/video/cx23885/Kconfig |1 +
drivers/media/video/cx23885/cx23885-cards.c | 10 +
drivers/media/video/cx23885/cx23885-dvb.c | 56 +++
drivers/media/video/cx23885/cx23885.h |1 +
4 files changed, 68 insertions(+)
diff --git a/drivers/media/video/cx23885/Kconfig
b/drivers/media/video/cx23885/Kconfig
index b391e9b..510adfe 100644
--- a/drivers/media/video/cx23885/Kconfig
+++ b/drivers/media/video/cx23885/Kconfig
@@ -21,6 +21,7 @@ config VIDEO_CX23885
select DVB_STV6110 if !DVB_FE_CUSTOMISE
select DVB_CX24116 if !DVB_FE_CUSTOMISE
select DVB_STV0900 if !DVB_FE_CUSTOMISE
+ select DVB_STV090x if !DVB_FE_CUSTOMISE
select DVB_DS3000 if !DVB_FE_CUSTOMISE
select DVB_STV0367 if !DVB_FE_CUSTOMISE
select MEDIA_TUNER_MT2131 if !MEDIA_TUNER_CUSTOMISE
diff --git a/drivers/media/video/cx23885/cx23885-cards.c
b/drivers/media/video/cx23885/cx23885-cards.c
index 080e111..50fedff 100644
--- a/drivers/media/video/cx23885/cx23885-cards.c
+++ b/drivers/media/video/cx23885/cx23885-cards.c
@@ -564,6 +564,10 @@ struct cx23885_board cx23885_boards[] = {
[CX23885_BOARD_TEVII_S471] = {
.name = TeVii S471,
.portb = CX23885_MPEG_DVB,
+ },
+ [CX23885_BOARD_PROF_8000] = {
+ .name = Prof Revolution DVB-S2 8000,
+ .portb = CX23885_MPEG_DVB,
}
};
const unsigned int cx23885_bcount = ARRAY_SIZE(cx23885_boards);
@@ -776,6 +780,10 @@ struct cx23885_subid cx23885_subids[] = {
.subvendor = 0xd471,
.subdevice = 0x9022,
.card = CX23885_BOARD_TEVII_S471,
+ }, {
+ .subvendor = 0x8000,
+ .subdevice = 0x3034,
+ .card = CX23885_BOARD_PROF_8000,
},
};
const unsigned int cx23885_idcount = ARRAY_SIZE(cx23885_subids);
@@ -1155,6 +1163,7 @@ void cx23885_gpio_setup(struct cx23885_dev *dev)
cx_set(GP0_IO, 0x00040004);
break;
case CX23885_BOARD_TBS_6920:
+ case CX23885_BOARD_PROF_8000:
cx_write(MC417_CTL, 0x0036);
cx_write(MC417_OEN, 0x1000);
cx_set(MC417_RWD, 0x0002);
@@ -1536,6 +1545,7 @@ void cx23885_card_setup(struct cx23885_dev *dev)
case CX23885_BOARD_TEVII_S470:
case CX23885_BOARD_TEVII_S471:
case CX23885_BOARD_DVBWORLD_2005:
+ case CX23885_BOARD_PROF_8000:
ts1-gen_ctrl_val = 0x5; /* Parallel */
ts1-ts_clk_en_val = 0x1; /* Enable TS_CLK */
ts1-src_sel_val = CX23885_SRC_SEL_PARALLEL_MPEG_VIDEO;
diff --git a/drivers/media/video/cx23885/cx23885-dvb.c
b/drivers/media/video/cx23885/cx23885-dvb.c
index cd54268..ba046ea 100644
--- a/drivers/media/video/cx23885/cx23885-dvb.c
+++ b/drivers/media/video/cx23885/cx23885-dvb.c
@@ -63,6 +63,9 @@
#include stv0367.h
#include drxk.h
#include mt2063.h
+#include stv090x.h
+#include stb6100.h
+#include stb6100_cfg.h
static unsigned int debug;
@@ -489,6 +492,42 @@ static struct xc5000_config mygica_x8506_xc5000_config = {
.if_khz = 5380,
};
+static struct stv090x_config prof_8000_stv090x_config = {
+.device = STV0903,
+.demod_mode = STV090x_SINGLE,
+.clk_mode = STV090x_CLK_EXT,
+.xtal = 2700,
+.address= 0x6A,
+.ts1_mode = STV090x_TSMODE_PARALLEL_PUNCTURED,
+.repeater_level = STV090x_RPTLEVEL_64,
+.adc1_range = STV090x_ADC_2Vpp,
+.diseqc_envelope_mode = false,
+
+.tuner_get_frequency= stb6100_get_frequency,
+.tuner_set_frequency= stb6100_set_frequency,
+.tuner_set_bandwidth= stb6100_set_bandwidth,
+.tuner_get_bandwidth= stb6100_get_bandwidth,
+};
+
+static struct stb6100_config prof_8000_stb6100_config = {
+ .tuner_address = 0x60,
+ .refclock = 2700,
+};
+
+static int p8000_set_voltage(struct dvb_frontend *fe, fe_sec_voltage_t voltage)
+{
+ struct cx23885_tsport *port = fe-dvb-priv;
+ struct cx23885_dev *dev = port-dev;
+
+ if (voltage == SEC_VOLTAGE_18)
+ cx_write(MC417_RWD, 0x1e00);
+ else if (voltage == SEC_VOLTAGE_13)
+ cx_write(MC417_RWD, 0x1a00);
+ else
+ cx_write(MC417_RWD, 0x1800);
+ return 0;
+}
+
static int cx23885_dvb_set_frontend(struct dvb_frontend *fe)
{
struct dtv_frontend_properties *p = fe-dtv_property_cache;
@@ -1186,6 +1225,23 @@ static int dvb_register(struct cx23885_tsport *port)
tevii_ds3000_config,
Re: [RFC PATCH 0/2] Add support for RDS decoding
Hello Konke, On 7/25/12 7:43 PM, Konke Radlow wrote: The latest version of the code can always be found in my github repository: https://github.com/koradlow/v4l2-rds-ctl In the github dir is a lib/include/libv4l2rd.h file. I cannot find it in the patchset. It also looks like you're bases on an older revision of the tree. Please rebase your patches. In the mentioned header files please replace the condition in #if __GNUC__ = 4 #define LIBV4L_PUBLIC __attribute__ ((visibility(default))) #else #define LIBV4L_PUBLIC #endif with the ones found in libv4l2.h. Thanks, Gregor -- 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: [RFC PATCH 1/2] Initial version of the RDS-decoder library Signed-off-by: Konke Radlow krad...@cisco.com
On 7/25/12 7:44 PM, Konke Radlow wrote: diff --git a/configure.ac b/configure.ac index 8ddcc9d..1d7eb29 100644 --- a/configure.ac +++ b/configure.ac ... @@ -146,13 +148,17 @@ AC_ARG_WITH(libv4l2subdir, AS_HELP_STRING(--with-libv4l2subdir=DIR,set libv4l2 l AC_ARG_WITH(libv4lconvertsubdir, AS_HELP_STRING(--with-libv4lconvertsubdir=DIR,set libv4lconvert library subdir [default=libv4l]), libv4lconvertsubdir=$withval, libv4lconvertsubdir=libv4l) +AC_ARG_WITH(libv4l2rdssubdir, AS_HELP_STRING(--with-libv4l2rdssubdir=DIR,set libv4l2rds library subdir [default=libv4l]), + libv4l2rdssubdir=$withval, libv4l2rdssubdir=libv4l) + AC_ARG_WITH(udevdir, AS_HELP_STRING(--with-udevdir=DIR,set udev directory [default=/lib/udev]), udevdir=$withval, udevdir=/lib/udev) - + libv4l1privdir=$libdir/$libv4l1subdir libv4l2privdir=$libdir/$libv4l2subdir libv4l2plugindir=$libv4l2privdir/plugins libv4lconvertprivdir=$libdir/$libv4lconvertsubdir +libv4l2rdsprivdir=$libdir/$libv4l2rdssubdir keytablesystemdir=$udevdir/rc_keymaps keytableuserdir=$sysconfdir/rc_keymaps @@ -166,6 +172,7 @@ AC_SUBST(libv4lconvertprivdir) AC_SUBST(keytablesystemdir) AC_SUBST(keytableuserdir) AC_SUBST(udevrulesdir) +AC_SUBST(libv4l2rdsprivdir) AC_SUBST(pkgconfigdir) AC_DEFINE_UNQUOTED([V4L_UTILS_VERSION], [$PACKAGE_VERSION], [v4l-utils version string]) @@ -173,6 +180,7 @@ AC_DEFINE_DIR([LIBV4L1_PRIV_DIR], [libv4l1privdir], [libv4l1 private lib directo AC_DEFINE_DIR([LIBV4L2_PRIV_DIR], [libv4l2privdir], [libv4l2 private lib directory]) AC_DEFINE_DIR([LIBV4L2_PLUGIN_DIR], [libv4l2plugindir], [libv4l2 plugin directory]) AC_DEFINE_DIR([LIBV4LCONVERT_PRIV_DIR], [libv4lconvertprivdir], [libv4lconvert private lib directory]) +AC_DEFINE_DIR([LIBV4L2RDS_PRIV_DIR], [libv4l2rdsprivdir], [libv4l2rds private lib directory]) AC_DEFINE_DIR([IR_KEYTABLE_SYSTEM_DIR], [keytablesystemdir], [ir-keytable preinstalled tables directory]) AC_DEFINE_DIR([IR_KEYTABLE_USER_DIR], [keytableuserdir], [ir-keytable user defined tables directory]) I don't think you need these changes. In libv4l these are for the wrapper libraries. You don't have one. Thanks, Gregor -- 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: [RFC PATCH 1/2] Initial version of the RDS-decoder library Signed-off-by: Konke Radlow krad...@cisco.com
On 7/25/12 7:44 PM, Konke Radlow wrote: --- /dev/null +++ b/lib/libv4l2rds/Makefile.am @@ -0,0 +1,11 @@ +if WITH_LIBV4L +lib_LTLIBRARIES = libv4l2rds.la +include_HEADERS = ../include/libv4l2rds.h +pkgconfig_DATA = libv4l2rds.pc +else +noinst_LTLIBRARIES = libv4l2rds.la +endif + +libv4l2rds_la_SOURCES = libv4l2rds.c +libv4l2rds_la_CPPFLAGS = -fvisibility=hidden $(ENFORCE_LIBV4L_STATIC) -std=c99 +libv4l2rds_la_LDFLAGS = -version-info 0 -lpthread $(DLOPEN_LIBS) $(ENFORCE_LIBV4L_STATIC) You don't call dlopen, so you can drop $(DLOPEN_LIBS) -- 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] pvrusb2: Declare MODULE_FIRMWARE usage
Cc: Mike Isely is...@pobox.com
Cc: Mauro Carvalho Chehab mche...@infradead.org
Cc: linux-media@vger.kernel.org
Signed-off-by: Tim Gardner tim.gard...@canonical.com
---
drivers/media/video/pvrusb2/pvrusb2-devattr.c | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/media/video/pvrusb2/pvrusb2-devattr.c
b/drivers/media/video/pvrusb2/pvrusb2-devattr.c
index d8c8982..adc501d3 100644
--- a/drivers/media/video/pvrusb2/pvrusb2-devattr.c
+++ b/drivers/media/video/pvrusb2/pvrusb2-devattr.c
@@ -54,8 +54,9 @@ static const struct pvr2_device_client_desc pvr2_cli_29xxx[]
= {
{ .module_id = PVR2_CLIENT_ID_DEMOD },
};
+#define PVR2_FIRMWARE_29xxx v4l-pvrusb2-29xxx-01.fw
static const char *pvr2_fw1_names_29xxx[] = {
- v4l-pvrusb2-29xxx-01.fw,
+ PVR2_FIRMWARE_29xxx,
};
static const struct pvr2_device_desc pvr2_device_29xxx = {
@@ -87,8 +88,9 @@ static const struct pvr2_device_client_desc pvr2_cli_24xxx[]
= {
{ .module_id = PVR2_CLIENT_ID_DEMOD },
};
+#define PVR2_FIRMWARE_24xxx v4l-pvrusb2-24xxx-01.fw
static const char *pvr2_fw1_names_24xxx[] = {
- v4l-pvrusb2-24xxx-01.fw,
+ PVR2_FIRMWARE_24xxx,
};
static const struct pvr2_device_desc pvr2_device_24xxx = {
@@ -369,8 +371,9 @@ static const struct pvr2_device_client_desc
pvr2_cli_73xxx[] = {
.i2c_address_list = \x42},
};
+#define PVR2_FIRMWARE_73xxx v4l-pvrusb2-73xxx-01.fw
static const char *pvr2_fw1_names_73xxx[] = {
- v4l-pvrusb2-73xxx-01.fw,
+ PVR2_FIRMWARE_73xxx,
};
static const struct pvr2_device_desc pvr2_device_73xxx = {
@@ -475,8 +478,9 @@ static const struct pvr2_dvb_props pvr2_751xx_dvb_props = {
};
#endif
+#define PVR2_FIRMWARE_75xxx v4l-pvrusb2-73xxx-01.fw
static const char *pvr2_fw1_names_75xxx[] = {
- v4l-pvrusb2-73xxx-01.fw,
+ PVR2_FIRMWARE_75xxx,
};
static const struct pvr2_device_desc pvr2_device_750xx = {
@@ -556,7 +560,10 @@ struct usb_device_id pvr2_device_table[] = {
};
MODULE_DEVICE_TABLE(usb, pvr2_device_table);
-
+MODULE_FIRMWARE(PVR2_FIRMWARE_29xxx);
+MODULE_FIRMWARE(PVR2_FIRMWARE_24xxx);
+MODULE_FIRMWARE(PVR2_FIRMWARE_73xxx);
+MODULE_FIRMWARE(PVR2_FIRMWARE_75xxx);
/*
Stuff for Emacs to see, in order to encourage consistent editing style:
--
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: [RFC PATCH 2/2] Initial version of RDS Control utility Signed-off-by: Konke Radlow krad...@cisco.com
On 7/25/12 7:44 PM, Konke Radlow wrote:
--- /dev/null
+++ b/utils/rds-ctl/rds-ctl.cpp
@@ -0,0 +1,978 @@
+/*
+ * rds-ctl.cpp is based on v4l2-ctl.cpp
+ *
+ * the following applies for all RDS related parts:
+ * Copyright 2012 Cisco Systems, Inc. and/or its affiliates. All rights
reserved.
+ * Author: Konke Radlow korad...@gmail.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
by
+ * the Free Software Foundation; either version 2.1 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Suite 500, Boston, MA 02110-1335
USA
+ */
+
+#include unistd.h
+#include stdlib.h
+#include stdio.h
+#include string.h
+#include wchar.h
+#include locale.h
+#include inttypes.h
+#include getopt.h
+#include sys/types.h
+#include fcntl.h
+#include errno.h
+#include sys/ioctl.h
+#include sys/time.h
+#include dirent.h
+#include config.h
+#include signal.h
+
+#ifdef HAVE_SYS_KLOG_H
+#include sys/klog.h
+#endif
You don't call klog, so you can drop these three lines
+static int parse_cl(int argc, char **argv)
+{
+ int i = 0;
+ int idx = 0;
+ int opt = 0;
+ char short_options[26 * 2 * 2 + 1];
+
+ if (argc == 1) {
+ usage_hint();
+ exit(1);
+ }
+ for (i = 0; long_options[i].name; i++) {
+ if (!isalpha(long_options[i].val))
+ continue;
+ short_options[idx++] = long_options[i].val;
+ if (long_options[i].has_arg == required_argument)
+ short_options[idx++] = ':';
+ }
+ while (1) {
+ // TODO: remove option_index ?
+ int option_index = 0;
+
+ short_options[idx] = 0;
+ opt = getopt_long(argc, argv, short_options,
+ long_options, option_index);
+ if (opt == -1)
+ break;
+
+ params.options[(int)opt] = 1;
+ switch (opt) {
+ case OptSetDevice:
+ strncpy(params.fd_name, optarg, 80);
+ if (optarg[0] = '0' optarg[0] = '9' optarg[1]
== 0) {
see isdigit from types.h (or std::isdigit from ctypes)
Thanks,
Gregor
--
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: [RFC PATCH 2/2] Initial version of RDS Control utility Signed-off-by: Konke Radlow krad...@cisco.com
On 7/25/12 7:44 PM, Konke Radlow wrote:
+static void print_rds_af(struct v4l2_rds_af_set *af_set)
+{
+ int counter = 0;
+
+ printf(\nAnnounced AFs: %u, af_set-announced_af);
+ for (int i = 0; i af_set-size i af_set-announced_af; i++,
counter++) {
+ if (af_set-af[i] = 8750 ) {
+ printf(\nAF%02d: %.1fMHz, counter, af_set-af[i] /
100.0);
+ continue;
+ }
+ printf(\nAF%02d: %.1fkHz, counter, af_set-af[i] / 1000.0);
+ }
+}
+
+static void print_rds_pi(const struct v4l2_rds *handle)
+{
+ printf(\nArea Coverage: %s, v4l2_rds_get_coverage_str(handle));
+}
+
+static void print_rds_data(struct v4l2_rds *handle, uint32_t updated_fields)
+{
+ if (params.options[OptPrintBlock])
+ updated_fields = 0x;
You could use UINT32_MAX here
+
+ if (updated_fields V4L2_RDS_PI
+ handle-valid_fields V4L2_RDS_PI) {
+ printf(\nPI: %04x, handle-pi);
+ print_rds_pi(handle);
+ }
+static int parse_cl(int argc, char **argv)
+{
+ int i = 0;
+ int idx = 0;
+ int opt = 0;
+ char short_options[26 * 2 * 2 + 1];
Where comes the 26 and 2 from?
Could this be (ARRAY_SIZE(long_options) + 1 ) * 2?
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
cron job: media_tree daily build: ERRORS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date:Thu Jul 26 19:00:18 CEST 2012 git hash:931efdf58bd83af8d0578a6cc53421675daf6d41 gcc version: i686-linux-gcc (GCC) 4.7.1 host hardware:x86_64 host os: 3.4.07-marune linux-git-arm-eabi-davinci: ERRORS linux-git-arm-eabi-exynos: OK linux-git-arm-eabi-omap: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: WARNINGS linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS linux-3.0-x86_64: WARNINGS linux-3.1-x86_64: WARNINGS linux-3.2.1-x86_64: WARNINGS linux-3.3-x86_64: WARNINGS linux-3.4-x86_64: WARNINGS linux-3.5-x86_64: ERRORS linux-2.6.31.12-i686: WARNINGS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-3.0-i686: WARNINGS linux-3.1-i686: WARNINGS linux-3.2.1-i686: WARNINGS linux-3.3-i686: WARNINGS linux-3.4-i686: WARNINGS linux-3.5-i686: ERRORS apps: WARNINGS spec-git: WARNINGS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 2/2] Initial version of RDS Control utility Signed-off-by: Konke Radlow krad...@cisco.com
1.
+#ifdef HAVE_SYS_KLOG_H
+#include sys/klog.h
+#endif
I'll drop those lines
2.
+ case OptSetDevice:
+ strncpy(params.fd_name, optarg, 80);
+ if (optarg[0] = '0' optarg[0] = '9' optarg[1]
== 0) {
I didn't know about the isalpha function, thanks for the hint
3.
+ if (params.options[OptPrintBlock])
+ updated_fields = 0x;
will use that handy definition (UINT32_MAX )
4.
+ int opt = 0;
+ char short_options[26 * 2 * 2 + 1];
the number 26 was taken over from the code of the v4l2-ctl tool. I don't know
where that magic number is coming from. I just checked the v4l2-ctl code again
and there seem to be 26 short options defined in the enum Option type.
Thank you for your comments so far. I'll incorporate them tomorrow
morning when I'm
back on my working machine,
regards,
Konke
On Thu, Jul 26, 2012 at 9:13 PM, Gregor Jasny gja...@googlemail.com wrote:
On 7/25/12 7:44 PM, Konke Radlow wrote:
+static void print_rds_af(struct v4l2_rds_af_set *af_set)
+{
+ int counter = 0;
+
+ printf(\nAnnounced AFs: %u, af_set-announced_af);
+ for (int i = 0; i af_set-size i af_set-announced_af; i++,
counter++) {
+ if (af_set-af[i] = 8750 ) {
+ printf(\nAF%02d: %.1fMHz, counter, af_set-af[i] /
100.0);
+ continue;
+ }
+ printf(\nAF%02d: %.1fkHz, counter, af_set-af[i] / 1000.0);
+ }
+}
+
+static void print_rds_pi(const struct v4l2_rds *handle)
+{
+ printf(\nArea Coverage: %s, v4l2_rds_get_coverage_str(handle));
+}
+
+static void print_rds_data(struct v4l2_rds *handle, uint32_t
updated_fields)
+{
+ if (params.options[OptPrintBlock])
+ updated_fields = 0x;
You could use UINT32_MAX here
+
+ if (updated_fields V4L2_RDS_PI
+ handle-valid_fields V4L2_RDS_PI) {
+ printf(\nPI: %04x, handle-pi);
+ print_rds_pi(handle);
+ }
+static int parse_cl(int argc, char **argv)
+{
+ int i = 0;
+ int idx = 0;
+ int opt = 0;
+ char short_options[26 * 2 * 2 + 1];
Where comes the 26 and 2 from?
Could this be (ARRAY_SIZE(long_options) + 1 ) * 2?
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 02/13] media: s5p-csis: Add device tree support
Hi Laurent, On 07/26/2012 04:38 PM, Laurent Pinchart wrote: --- /dev/null +++ b/Documentation/devicetree/bindings/video/mipi.txt @@ -0,0 +1,5 @@ +Common properties of MIPI-CSI1 and MIPI-CSI2 receivers and transmitters + + - data-lanes : number of differential data lanes wired and actively used in + communication between the transmitter and the receiver, this + excludes the clock lane; Wouldn't it be better to use the standard bus-width DT property? I can't see any problems with using bus-width. It seems sufficient and could indeed be better, without a need to invent new MIPI-CSI specific names. That was my first RFC on that and my perspective wasn't probably broad enough. :) What about CSI receivers that can reroute the lanes internally ? We would need to specify lane indices for each lane then, maybe with something like clock-lane =0; data-lanes =2 3 1; Sounds good to me. And the clock-lane could be made optional, as not all devices would need it. However, as far as I can see, there is currently no generic API for handling this kind of data structure. E.g. number of cells for the interrupts property is specified with an additional #interrupt-cells property. It would have been much easier to handle something like: data-lanes = 2, 3, 1; i.e. an array of the lane indexes. For receivers that can't reroute lanes internally, the data-lanes property would be need to specify lanes in sequence. data-lanes =1 2 3; In this case we would be only interested in the number of cells in this property, but how it could be retrieved ? With an array, it could have been calculated from property length returned by of_property_find() (divided by sizof(u32)). -- Regards, 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] v4l-dev.c: Use 'ret' variable to return release() exit code
Commit 65d9ff9c85d3c2e06d22aed78efee8404563eff6:
V4L/DVB (11390): 2-dev.c: return 0 for NULL open and release callbacks,
introduced this bug.
The bug this patch fixes is almost innocuous because nobody
really cares about release() exit code.
Signed-off-by: Ezequiel Garcia elezegar...@gmail.com
---
drivers/media/video/v4l2-dev.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/v4l2-dev.c b/drivers/media/video/v4l2-dev.c
index d13c47f..337c370 100644
--- a/drivers/media/video/v4l2-dev.c
+++ b/drivers/media/video/v4l2-dev.c
@@ -496,7 +496,7 @@ static int v4l2_release(struct inode *inode, struct file
*filp)
if (vdev-fops-release) {
if (test_bit(V4L2_FL_LOCK_ALL_FOPS, vdev-flags))
mutex_lock(vdev-lock);
- vdev-fops-release(filp);
+ ret = vdev-fops-release(filp);
if (test_bit(V4L2_FL_LOCK_ALL_FOPS, vdev-flags))
mutex_unlock(vdev-lock);
}
--
1.7.8.6
--
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: [RFC/PATCH 09/13] media: s5k6aa: Add support for device tree based instantiation
Hi Laurent, On 07/26/2012 05:21 PM, Laurent Pinchart wrote: On Friday 25 May 2012 21:52:48 Sylwester Nawrocki wrote: The driver initializes all board related properties except the s_power() callback to board code. The platforms that require this callback are not supported by this driver yet for CONFIG_OF=y. Signed-off-by: Sylwester Nawrockis.nawro...@samsung.com Signed-off-by: Bartlomiej Zolnierkiewiczb.zolnier...@samsung.com Signed-off-by: Kyungmin Parkkyungmin.p...@samsung.com --- .../bindings/camera/samsung-s5k6aafx.txt | 57 + drivers/media/video/s5k6aa.c | 129 - 2 files changed, 146 insertions(+), 40 deletions(-) create mode 100644 Documentation/devicetree/bindings/camera/samsung-s5k6aafx.txt diff --git a/Documentation/devicetree/bindings/camera/samsung-s5k6aafx.txt b/Documentation/devicetree/bindings/camera/samsung-s5k6aafx.txt new file mode 100644 index 000..6685a9c --- /dev/null +++ b/Documentation/devicetree/bindings/camera/samsung-s5k6aafx.txt @@ -0,0 +1,57 @@ +Samsung S5K6AAFX camera sensor +-- + +Required properties: + +- compatible : samsung,s5k6aafx; +- reg : base address of the device on I2C bus; +- video-itu-601-bus : parallel bus with HSYNC and VSYNC - ITU-R BT.601; +- vdd_core-supply : digital core voltage supply 1.5V (1.4V to 1.6V); +- vdda-supply : analog power voltage supply 2.8V (2.6V to 3.0V); +- vdd_reg-supply : regulator input power voltage supply 1.8V (1.7V to 1.9V) + or 2.8V (2.6V to 3.0); +- vddio-supply : I/O voltage supply 1.8V (1.65V to 1.95V) + or 2.8V (2.5V to 3.1V); + +Optional properties: + +- clock-frequency : the IP's main (system bus) clock frequency in Hz, the default Is that the input clock frequency ? Can't it vary ? Instead of accessing the Yes, the description is incorrect in this patch, it should read: +- clock-frequency : the sensor's master clock frequency in Hz; and be a required property. As in this patch: https://github.com/snawrocki/linux/commit/e8a5f890dec0d7414b656bb1d1ac97d5e7abe563 It could vary (as this is a PLL input frequency), so probably a range would be a better alternative. Given that host device won't always be able to set this exact value... sensor clock frequency from the FIMC driver you should reference a clock in the sensor DT node. That obviously requires generic clock support, which might not be available for your platform yet (that's one of the reasons the OMAP3 ISP driver doesn't support DT yet). I agree it might be better, but waiting unknown number of kernel releases for the platforms to get converted to common clock API is not a good alternative either. I guess we could have some transitional solutions while other subsystems are getting adapted. Yet we need to specify the clock frequency range per sensor, so 1. either we specify it at a sensor node and host device driver references it, or 2. it could be added to a sensor specific child node of a host device mode, and then only the host would reference it, and sensor would reference a clock in its DT node; I guess it's not a problem that in most cases the camera host device is a clock provider. -- Regards, 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
Re: Advice on extending libv4l for media controller support
Hi, Sorry to be late to the party... I wanted to follow up on this discussion, but forgot and haven't read anything about it since... On 10.05.2012 17:09, Ivan T. Ivanov wrote: On Wed, May 9, 2012 at 7:08 PM, Sergio Aguirre sergio.a.agui...@gmail.com wrote: I want to create some sort of plugin with specific media controller configurations, to avoid userspace to worry about component names and specific usecases (use sensor resizer, or SoC ISP resizer, etc.). Probably following links can help you. They have been tested with the OMAP3 ISP. Regards, iivanov [1] http://www.spinics.net/lists/linux-media/msg31901.html [2] http://comments.gmane.org/gmane.linux.drivers.video-input-infrastructure/32704 I recently extended Yordan Kamenov's libv4l-mcplugin to support multiple trees per device with extended configurations (-stolen from- inspired by media-ctl) not tied to specific device nodes (but to device names instead). I uploaded the patches here https://sites.google.com/site/rawbdagslair/libv4l-mcplugin.7z?attredirects=0d=1(16kB). Basically, I used Yordan's patches as a base and worked from there to fix up his source code and Makefile for cross-compiling using OpenEmbedded/Yocto. There are a ton of minor issues with this, starting with the fact that I did not put proper copyright notices in any of these files. Please advise if this poses a problem. Only integral frame size support and no support for native read() calls. There's a dummy read() function, because for some reason this is required in libv4l2 0.9.0-test though it's not mentioned anywhere. As the original plug-in by Yordan, there is currently no cleaning-up of the internal data structures. I used this in conjunction with the Gumstix CASPA FS (MT9V032) camera using some of Laurent's patches and some custom patches which add ENUM_FMT support to the driver. Basically, upon opening a given device, all trees are configured once to load the respective end-point's formats for emulation of setting and getting formats. Then regular format negotiation by the user application takes place. Regards, Robert -- 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] mt9v032: Export horizontal and vertical blanking as V4L2 controls
Hi Laurent, Thanks for the patch. On Tue, Jul 24, 2012 at 01:10:42AM +0200, Laurent Pinchart wrote: Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com --- drivers/media/video/mt9v032.c | 36 +--- 1 files changed, 33 insertions(+), 3 deletions(-) Changes since v1: - Make sure the total horizontal time will not go below 660 when setting the horizontal blanking control - Restrict the vertical blanking value to 3000 as documented in the datasheet. Increasing the exposure time actually extends vertical blanking, as long as the user doesn't forget to turn auto-exposure off... Does binning either horizontally or vertically affect the blanking limits? If the process is analogue then the answer is typically yes. It's not directly related to this patch, but the effect of the driver just exposing one sub-device really shows better now. Besides lacking the way to specify binning as in the V4L2 subdev API (compose selection target), the user also can't use the crop bounds selection target to get the size of the pixel array. We could either accept this for the time being and fix it later on of fix it now. I prefer fixing it right now but admit that this patch isn't breaking anything, it rather is missing quite relevant functionality to control the sensor in a generic way. Kind regards, -- Sakari Ailus e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: sai...@retiisi.org.uk -- 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 0/4] Aptinate sensors patches
On Mon, Jul 23, 2012 at 08:34:58PM +0200, Laurent Pinchart wrote: Hi everybody, Here are three fixes/patches for the MT9P031 and MT9V032 sensor drivers. The second patch (mt9v032 pixel rate control) requires a control framework modification (1/4) that has already been reviewed. Sakari, I've rebased your patch on top of the latest media tree, could you please review it ? For patches 1, 2 and 4: Acked-by: Sakari Ailus sakari.ai...@iki.fi -- Sakari Ailus e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: sai...@retiisi.org.uk -- 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] cx25840: Declare MODULE_FIRMWARE usage
On Thu, 2012-07-26 at 10:44 -0600, Tim Gardner wrote:
Cc: Mauro Carvalho Chehab mche...@infradead.org
Cc: linux-media@vger.kernel.org
Signed-off-by: Tim Gardner tim.gard...@canonical.com
---
drivers/media/video/cx25840/cx25840-firmware.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/media/video/cx25840/cx25840-firmware.c
b/drivers/media/video/cx25840/cx25840-firmware.c
index 8150200..b3169f9 100644
--- a/drivers/media/video/cx25840/cx25840-firmware.c
+++ b/drivers/media/video/cx25840/cx25840-firmware.c
@@ -61,6 +61,10 @@ static void end_fw_load(struct i2c_client *client)
cx25840_write(client, 0x803, 0x03);
}
+#define CX2388x_FIRMWARE v4l-cx23885-avcore-01.fw
+#define CX231xx_FIRMWARE v4l-cx231xx-avcore-01.fw
+#define CX25840_FIRMWARE v4l-cx25840.fw
+
static const char *get_fw_name(struct i2c_client *client)
{
struct cx25840_state *state = to_state(i2c_get_clientdata(client));
@@ -68,10 +72,10 @@ static const char *get_fw_name(struct i2c_client *client)
if (firmware[0])
return firmware;
if (is_cx2388x(state))
- return v4l-cx23885-avcore-01.fw;
+ return CX2388x_FIRMWARE;
if (is_cx231xx(state))
- return v4l-cx231xx-avcore-01.fw;
- return v4l-cx25840.fw;
+ return CX231xx_FIRMWARE;
+ return CX25840_FIRMWARE;
}
static int check_fw_load(struct i2c_client *client, int size)
@@ -164,3 +168,8 @@ int cx25840_loadfw(struct i2c_client *client)
return check_fw_load(client, size);
}
+
+MODULE_FIRMWARE(CX2388x_FIRMWARE);
+MODULE_FIRMWARE(CX231xx_FIRMWARE);
+MODULE_FIRMWARE(CX25840_FIRMWARE);
+
How will the firmware attribute in the .module_info section be used?
For any one model of TV capture device, the cx25840 only needs one of
the above firmware files. The others need not exist.
I would not want anything in user or kernel space to refuse to load the
module just because all 3 firmware files are not present.
Regards,
Andy
--
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] cx18: Declare MODULE_FIRMWARE usage
On Thu, 2012-07-26 at 11:05 -0600, Tim Gardner wrote:
Cc: Andy Walls awa...@md.metrocast.net
Cc: Mauro Carvalho Chehab mche...@infradead.org
Cc: ivtv-de...@ivtvdriver.org
Cc: linux-media@vger.kernel.org
Signed-off-by: Tim Gardner tim.gard...@canonical.com
You missed v4l-cx23418-dig.fw, in cx18-av-firmware.c, which is required
by all CX23418 devices.
You missed dvb-cx18-mpc718-mt352.fw, in cx18-dvb.c, which is only needed
by certain variants of the Yuan MPC-718 mini-PCI card.
In cx18, the dvb-cx18-mpc718-mt352.fw need not exist for all common
CX23418 based cards. I would not want anything in user space or the
kernel to prevent module load, if this file does not exist. This
firmware file is especially a pain, since it has to be snipped out of a
Windows driver binary. Most users will not have it.
Regards,
Andy
---
drivers/media/video/cx18/cx18-driver.c |1 +
drivers/media/video/cx18/cx18-firmware.c | 10 --
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/media/video/cx18/cx18-driver.c
b/drivers/media/video/cx18/cx18-driver.c
index 7e5ffd6..c67733d 100644
--- a/drivers/media/video/cx18/cx18-driver.c
+++ b/drivers/media/video/cx18/cx18-driver.c
@@ -1357,3 +1357,4 @@ static void __exit module_cleanup(void)
module_init(module_start);
module_exit(module_cleanup);
+MODULE_FIRMWARE(XC2028_DEFAULT_FIRMWARE);
diff --git a/drivers/media/video/cx18/cx18-firmware.c
b/drivers/media/video/cx18/cx18-firmware.c
index b85c292..a1c1cec 100644
--- a/drivers/media/video/cx18/cx18-firmware.c
+++ b/drivers/media/video/cx18/cx18-firmware.c
@@ -376,6 +376,9 @@ void cx18_init_memory(struct cx18 *cx)
cx18_write_reg(cx, 0x0101, CX18_WMB_CLIENT14); /* AVO */
}
+#define CX18_CPU_FIRMWARE v4l-cx23418-cpu.fw
+#define CX18_APU_FIRMWARE v4l-cx23418-apu.fw
+
int cx18_firmware_init(struct cx18 *cx)
{
u32 fw_entry_addr;
@@ -400,7 +403,7 @@ int cx18_firmware_init(struct cx18 *cx)
cx18_sw1_irq_enable(cx, IRQ_CPU_TO_EPU | IRQ_APU_TO_EPU);
cx18_sw2_irq_enable(cx, IRQ_CPU_TO_EPU_ACK | IRQ_APU_TO_EPU_ACK);
- sz = load_cpu_fw_direct(v4l-cx23418-cpu.fw, cx-enc_mem, cx);
+ sz = load_cpu_fw_direct(CX18_CPU_FIRMWARE, cx-enc_mem, cx);
if (sz = 0)
return sz;
@@ -408,7 +411,7 @@ int cx18_firmware_init(struct cx18 *cx)
cx18_init_scb(cx);
fw_entry_addr = 0;
- sz = load_apu_fw_direct(v4l-cx23418-apu.fw, cx-enc_mem, cx,
+ sz = load_apu_fw_direct(CX18_APU_FIRMWARE, cx-enc_mem, cx,
fw_entry_addr);
if (sz = 0)
return sz;
@@ -451,3 +454,6 @@ int cx18_firmware_init(struct cx18 *cx)
cx18_write_reg_expect(cx, 0x14001400, 0xc78110, 0x1400, 0x14001400);
return 0;
}
+
+MODULE_FIRMWARE(CX18_CPU_FIRMWARE);
+MODULE_FIRMWARE(CX18_APU_FIRMWARE);
--
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] cx18: Declare MODULE_FIRMWARE usage
On Thu, 2012-07-26 at 11:21 -0600, Tim Gardner wrote:
Missed a firmware file in cx18-av-firmware.c
rtg
Please send patches in-line vs. an attachment.
This is still missing the firmware file in cx18-dvb.c.
Regards,
Andy
From 9b4be013f173efc12bb2776394bf6a5abb8725b6 Mon Sep 17 00:00:00 2001
From: Tim Gardner tim.gard...@canonical.com
Date: Thu, 26 Jul 2012 11:03:51 -0600
Subject: [PATCH v2] cx18: Declare MODULE_FIRMWARE usage
Cc: Andy Walls awa...@md.metrocast.net
Cc: Mauro Carvalho Chehab mche...@infradead.org
Cc: ivtv-de...@ivtvdriver.org
Cc: linux-media@vger.kernel.org
Signed-off-by: Tim Gardner tim.gard...@canonical.com
---
drivers/media/video/cx18/cx18-av-firmware.c |2 ++
drivers/media/video/cx18/cx18-driver.c |1 +
drivers/media/video/cx18/cx18-firmware.c| 10 --
3 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/media/video/cx18/cx18-av-firmware.c
b/drivers/media/video/cx18/cx18-av-firmware.c
index 280aa4d..a34fd08 100644
--- a/drivers/media/video/cx18/cx18-av-firmware.c
+++ b/drivers/media/video/cx18/cx18-av-firmware.c
@@ -221,3 +221,5 @@ int cx18_av_loadfw(struct cx18 *cx)
release_firmware(fw);
return 0;
}
+
+MODULE_FIRMWARE(FWFILE);
diff --git a/drivers/media/video/cx18/cx18-driver.c
b/drivers/media/video/cx18/cx18-driver.c
index 7e5ffd6..c67733d 100644
--- a/drivers/media/video/cx18/cx18-driver.c
+++ b/drivers/media/video/cx18/cx18-driver.c
@@ -1357,3 +1357,4 @@ static void __exit module_cleanup(void)
module_init(module_start);
module_exit(module_cleanup);
+MODULE_FIRMWARE(XC2028_DEFAULT_FIRMWARE);
diff --git a/drivers/media/video/cx18/cx18-firmware.c
b/drivers/media/video/cx18/cx18-firmware.c
index b85c292..a1c1cec 100644
--- a/drivers/media/video/cx18/cx18-firmware.c
+++ b/drivers/media/video/cx18/cx18-firmware.c
@@ -376,6 +376,9 @@ void cx18_init_memory(struct cx18 *cx)
cx18_write_reg(cx, 0x0101, CX18_WMB_CLIENT14); /* AVO */
}
+#define CX18_CPU_FIRMWARE v4l-cx23418-cpu.fw
+#define CX18_APU_FIRMWARE v4l-cx23418-apu.fw
+
int cx18_firmware_init(struct cx18 *cx)
{
u32 fw_entry_addr;
@@ -400,7 +403,7 @@ int cx18_firmware_init(struct cx18 *cx)
cx18_sw1_irq_enable(cx, IRQ_CPU_TO_EPU | IRQ_APU_TO_EPU);
cx18_sw2_irq_enable(cx, IRQ_CPU_TO_EPU_ACK |
IRQ_APU_TO_EPU_ACK);
- sz = load_cpu_fw_direct(v4l-cx23418-cpu.fw, cx-enc_mem,
cx);
+ sz = load_cpu_fw_direct(CX18_CPU_FIRMWARE, cx-enc_mem, cx);
if (sz = 0)
return sz;
@@ -408,7 +411,7 @@ int cx18_firmware_init(struct cx18 *cx)
cx18_init_scb(cx);
fw_entry_addr = 0;
- sz = load_apu_fw_direct(v4l-cx23418-apu.fw, cx-enc_mem, cx,
+ sz = load_apu_fw_direct(CX18_APU_FIRMWARE, cx-enc_mem, cx,
fw_entry_addr);
if (sz = 0)
return sz;
@@ -451,3 +454,6 @@ int cx18_firmware_init(struct cx18 *cx)
cx18_write_reg_expect(cx, 0x14001400, 0xc78110, 0x1400,
0x14001400);
return 0;
}
+
+MODULE_FIRMWARE(CX18_CPU_FIRMWARE);
+MODULE_FIRMWARE(CX18_APU_FIRMWARE);
--
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] ivtv: Declare MODULE_FIRMWARE usage
On Thu, 2012-07-26 at 12:26 -0600, Tim Gardner wrote: Cc: Andy Walls awa...@md.metrocast.net Cc: Mauro Carvalho Chehab mche...@infradead.org Cc: ivtv-de...@ivtvdriver.org Cc: linux-media@vger.kernel.org Signed-off-by: Tim Gardner tim.gard...@canonical.com --- drivers/media/video/ivtv/ivtv-firmware.c |4 1 file changed, 4 insertions(+) diff --git a/drivers/media/video/ivtv/ivtv-firmware.c b/drivers/media/video/ivtv/ivtv-firmware.c index 02c5ade..6ec7705 100644 --- a/drivers/media/video/ivtv/ivtv-firmware.c +++ b/drivers/media/video/ivtv/ivtv-firmware.c @@ -396,3 +396,7 @@ int ivtv_firmware_check(struct ivtv *itv, char *where) return res; } + +MODULE_FIRMWARE(CX2341X_FIRM_ENC_FILENAME); +MODULE_FIRMWARE(CX2341X_FIRM_DEC_FILENAME); +MODULE_FIRMWARE(IVTV_DECODE_INIT_MPEG_FILENAME); Only the PVR-350, based on the iTVC-15/CX23415 chip, needs the CX2341X_FIRM_DEC_FILENAME and IVTV_DECODE_INIT_MPEG_FILENAME. (And even in the case of that card, not having the IVTV_DECODE_INIT_MPEG_FILENAME file is non-fatal.) I would not want anything in user-space or kernel space preventing the ivtv module from loading, if some of those files don't exist. Regards, Andy -- 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: [RFC/PATCH 02/13] media: s5p-csis: Add device tree support
Hi Sylwester, On Thursday 26 July 2012 21:51:30 Sylwester Nawrocki wrote: On 07/26/2012 04:38 PM, Laurent Pinchart wrote: --- /dev/null +++ b/Documentation/devicetree/bindings/video/mipi.txt @@ -0,0 +1,5 @@ +Common properties of MIPI-CSI1 and MIPI-CSI2 receivers and transmitters + + - data-lanes : number of differential data lanes wired and actively used in +communication between the transmitter and the receiver, this +excludes the clock lane; Wouldn't it be better to use the standard bus-width DT property? I can't see any problems with using bus-width. It seems sufficient and could indeed be better, without a need to invent new MIPI-CSI specific names. That was my first RFC on that and my perspective wasn't probably broad enough. :) What about CSI receivers that can reroute the lanes internally ? We would need to specify lane indices for each lane then, maybe with something like clock-lane =0; data-lanes =2 3 1; Sounds good to me. And the clock-lane could be made optional, as not all devices would need it. However, as far as I can see, there is currently no generic API for handling this kind of data structure. E.g. number of cells for the interrupts property is specified with an additional #interrupt-cells property. It would have been much easier to handle something like: data-lanes = 2, 3, 1; i.e. an array of the lane indexes. I'm fine with that. For receivers that can't reroute lanes internally, the data-lanes property would be need to specify lanes in sequence. data-lanes =1 2 3; In this case we would be only interested in the number of cells in this property, but how it could be retrieved ? With an array, it could have been calculated from property length returned by of_property_find() (divided by sizof(u32)). Agreed. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 09/13] media: s5k6aa: Add support for device tree based instantiation
Hi Sylwester, On Thursday 26 July 2012 22:39:31 Sylwester Nawrocki wrote: On 07/26/2012 05:21 PM, Laurent Pinchart wrote: On Friday 25 May 2012 21:52:48 Sylwester Nawrocki wrote: The driver initializes all board related properties except the s_power() callback to board code. The platforms that require this callback are not supported by this driver yet for CONFIG_OF=y. Signed-off-by: Sylwester Nawrockis.nawro...@samsung.com Signed-off-by: Bartlomiej Zolnierkiewiczb.zolnier...@samsung.com Signed-off-by: Kyungmin Parkkyungmin.p...@samsung.com --- .../bindings/camera/samsung-s5k6aafx.txt | 57 + drivers/media/video/s5k6aa.c | 129 + 2 files changed, 146 insertions(+), 40 deletions(-) create mode 100644 Documentation/devicetree/bindings/camera/samsung-s5k6aafx.txt diff --git a/Documentation/devicetree/bindings/camera/samsung-s5k6aafx.txt b/Documentation/devicetree/bindings/camera/samsung-s5k6aafx.txt new file mode 100644 index 000..6685a9c --- /dev/null +++ b/Documentation/devicetree/bindings/camera/samsung-s5k6aafx.txt @@ -0,0 +1,57 @@ +Samsung S5K6AAFX camera sensor +-- + +Required properties: + +- compatible : samsung,s5k6aafx; +- reg : base address of the device on I2C bus; +- video-itu-601-bus : parallel bus with HSYNC and VSYNC - ITU-R BT.601; +- vdd_core-supply : digital core voltage supply 1.5V (1.4V to 1.6V); +- vdda-supply : analog power voltage supply 2.8V (2.6V to 3.0V); +- vdd_reg-supply : regulator input power voltage supply 1.8V (1.7V to 1.9V) + or 2.8V (2.6V to 3.0); +- vddio-supply : I/O voltage supply 1.8V (1.65V to 1.95V) + or 2.8V (2.5V to 3.1V); + +Optional properties: + +- clock-frequency : the IP's main (system bus) clock frequency in Hz, the default Is that the input clock frequency ? Can't it vary ? Instead of accessing the Yes, the description is incorrect in this patch, it should read: +- clock-frequency : the sensor's master clock frequency in Hz; and be a required property. As in this patch: https://github.com/snawrocki/linux/commit/e8a5f890dec0d7414b656bb1d1ac97d5e7 abe563 It could vary (as this is a PLL input frequency), so probably a range would be a better alternative. Given that host device won't always be able to set this exact value... A range sounds good, or perhaps a list of ranges. Sakari, what would you need for the SMIA++ driver ? sensor clock frequency from the FIMC driver you should reference a clock in the sensor DT node. That obviously requires generic clock support, which might not be available for your platform yet (that's one of the reasons the OMAP3 ISP driver doesn't support DT yet). I agree it might be better, but waiting unknown number of kernel releases for the platforms to get converted to common clock API is not a good alternative either. I guess we could have some transitional solutions while other subsystems are getting adapted. I agree, we need an interim solution. Yet we need to specify the clock frequency range per sensor, so 1. either we specify it at a sensor node and host device driver references it, or 2. it could be added to a sensor specific child node of a host device mode, and then only the host would reference it, and sensor would reference a clock in its DT node; I guess it's not a problem that in most cases the camera host device is a clock provider. The sensor will need to configure the clock rate, so a (list of) clock frequency range(s) will be needed in the sensor node anyway. As an interim solution the host can access that property. When the platform will be ported to the common clock API no modification to the DT will be needed. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] mt9v032: Export horizontal and vertical blanking as V4L2 controls
Hi Sakari, On Thursday 26 July 2012 23:54:01 Sakari Ailus wrote: On Tue, Jul 24, 2012 at 01:10:42AM +0200, Laurent Pinchart wrote: Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com --- drivers/media/video/mt9v032.c | 36 +--- 1 files changed, 33 insertions(+), 3 deletions(-) Changes since v1: - Make sure the total horizontal time will not go below 660 when setting the horizontal blanking control - Restrict the vertical blanking value to 3000 as documented in the datasheet. Increasing the exposure time actually extends vertical blanking, as long as the user doesn't forget to turn auto-exposure off... Does binning either horizontally or vertically affect the blanking limits? If the process is analogue then the answer is typically yes. The datasheet doesn't specify whether binning and blanking can influence each other. It's not directly related to this patch, but the effect of the driver just exposing one sub-device really shows better now. Besides lacking the way to specify binning as in the V4L2 subdev API (compose selection target), the user also can't use the crop bounds selection target to get the size of the pixel array. We could either accept this for the time being and fix it later on of fix it now. I prefer fixing it right now but admit that this patch isn't breaking anything, it rather is missing quite relevant functionality to control the sensor in a generic way. I'd rather apply this patch first, as it doesn't break anything :-) Fixing the problem will require discussions, and that will take time. Binning/skipping is a pretty common feature in sensors. Exposing two sub- devices like the SMIA++ driver does is one way to fix the problem, but do we really want to do that for the vast majority of sensors ? -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] omap3-isp G_FMT ENUM_FMT
Hi Michael, On Thursday 26 July 2012 16:22:17 Michael Jones wrote: On 07/26/2012 04:05 PM, Laurent Pinchart wrote: On Thursday 26 July 2012 13:59:54 Michael Jones wrote: Hello, I would like to (re)submit a couple of patches to support V4L2 behavior at the V4L2 device nodes of the omap3-isp driver, but I'm guessing they require some discussion first. Indeed. The main reason why the OMAP3 ISP driver implements G_FMT/S_FMT as it does today is to hack around a restriction in the V4L2 API. We needed a way to preallocate and possibly prequeue buffers for snapshot, which wasn't possible in a standard-compliant way back then. The situation has since changed, and we now have the VIDIOC_CREATE_BUFS and VIDIOC_PREPARE_BUF ioctls. My plan is to - port the OMAP3 ISP driver to videobuf2 - implement support for CREATE_BUFS and PREPARE_BUF - fix the G_FMT/S_FMT/ENUM_FMT behaviour What will the G_FMT/S_FMT/ENUM_FMT behavior be then? Can you contrast it with the behavior of my patches? If the behavior will be the same for user space, and your proposed changes won't be in very soon, can we use my patches until you make your changes? At the moment the driver accepts any format you give it in a S_FMT call, regardless of the format of the connected pad. The reason for that is to allow VIDIOC_REQBUFS to allocate buffers for an arbitrary size. With CREATE_BUFS and PREPARE_BUFS support, G_FMT, S_FMT and ENUM_FMT should return the format of the connected pad. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] pvrusb2: Declare MODULE_FIRMWARE usage
Acked-By: Mike Isely is...@pobox.com
-Mike
On Thu, 26 Jul 2012, Tim Gardner wrote:
Cc: Mike Isely is...@pobox.com
Cc: Mauro Carvalho Chehab mche...@infradead.org
Cc: linux-media@vger.kernel.org
Signed-off-by: Tim Gardner tim.gard...@canonical.com
---
drivers/media/video/pvrusb2/pvrusb2-devattr.c | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/media/video/pvrusb2/pvrusb2-devattr.c
b/drivers/media/video/pvrusb2/pvrusb2-devattr.c
index d8c8982..adc501d3 100644
--- a/drivers/media/video/pvrusb2/pvrusb2-devattr.c
+++ b/drivers/media/video/pvrusb2/pvrusb2-devattr.c
@@ -54,8 +54,9 @@ static const struct pvr2_device_client_desc
pvr2_cli_29xxx[] = {
{ .module_id = PVR2_CLIENT_ID_DEMOD },
};
+#define PVR2_FIRMWARE_29xxx v4l-pvrusb2-29xxx-01.fw
static const char *pvr2_fw1_names_29xxx[] = {
- v4l-pvrusb2-29xxx-01.fw,
+ PVR2_FIRMWARE_29xxx,
};
static const struct pvr2_device_desc pvr2_device_29xxx = {
@@ -87,8 +88,9 @@ static const struct pvr2_device_client_desc
pvr2_cli_24xxx[] = {
{ .module_id = PVR2_CLIENT_ID_DEMOD },
};
+#define PVR2_FIRMWARE_24xxx v4l-pvrusb2-24xxx-01.fw
static const char *pvr2_fw1_names_24xxx[] = {
- v4l-pvrusb2-24xxx-01.fw,
+ PVR2_FIRMWARE_24xxx,
};
static const struct pvr2_device_desc pvr2_device_24xxx = {
@@ -369,8 +371,9 @@ static const struct pvr2_device_client_desc
pvr2_cli_73xxx[] = {
.i2c_address_list = \x42},
};
+#define PVR2_FIRMWARE_73xxx v4l-pvrusb2-73xxx-01.fw
static const char *pvr2_fw1_names_73xxx[] = {
- v4l-pvrusb2-73xxx-01.fw,
+ PVR2_FIRMWARE_73xxx,
};
static const struct pvr2_device_desc pvr2_device_73xxx = {
@@ -475,8 +478,9 @@ static const struct pvr2_dvb_props pvr2_751xx_dvb_props =
{
};
#endif
+#define PVR2_FIRMWARE_75xxx v4l-pvrusb2-73xxx-01.fw
static const char *pvr2_fw1_names_75xxx[] = {
- v4l-pvrusb2-73xxx-01.fw,
+ PVR2_FIRMWARE_75xxx,
};
static const struct pvr2_device_desc pvr2_device_750xx = {
@@ -556,7 +560,10 @@ struct usb_device_id pvr2_device_table[] = {
};
MODULE_DEVICE_TABLE(usb, pvr2_device_table);
-
+MODULE_FIRMWARE(PVR2_FIRMWARE_29xxx);
+MODULE_FIRMWARE(PVR2_FIRMWARE_24xxx);
+MODULE_FIRMWARE(PVR2_FIRMWARE_73xxx);
+MODULE_FIRMWARE(PVR2_FIRMWARE_75xxx);
/*
Stuff for Emacs to see, in order to encourage consistent editing style:
--
Mike Isely
isely @ isely (dot) net
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] [media] davinci: vpfe: Add documentation
Laurent,
Thank you for your comments.
On Thu, Jul 26, 2012 at 05:55:31, Laurent Pinchart wrote:
Hi Manjunath,
On Tuesday 17 July 2012 10:43:54 Hadli, Manjunath wrote:
On Sun, Jul 15, 2012 at 18:16:25, Laurent Pinchart wrote:
On Wednesday 11 July 2012 21:09:26 Manjunath Hadli wrote:
Add documentation on the Davinci VPFE driver. Document the subdevs,
and private IOTCLs the driver implements
Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Signed-off-by: Lad, Prabhakar prabhakar@ti.com
[snip]
+Private IOCTLs
+==
+
+The Davinci Video processing Front End (VPFE) driver supports standard
V4L2 +IOCTLs and controls where possible and practical. Much of the
functions provided
+by the VPFE, however, does not fall under the standard IOCTLs.
+
+In general, there is a private ioctl for configuring each of the blocks
+containing hardware-dependent functions.
+
+The following private IOCTLs are supported:
+
+1: IOCTL: PREV_S_PARAM/PREV_G_PARAM
+Description:
+ Sets/Gets the parameters required by the previewer module
+Parameter:
+ /**
+* struct prev_module_param- structure to configure preview
modules
+* @version: Version of the preview module
Who is responsible for filling this field, the application or the driver ?
The application is responsible for filling this info. He would enumerate the
capabilities first and set them using S_PARAM/G_PARAM.
And what's the point of the application setting the version field ? How does
the driver use it ?
The version may not be required. Will remove it.
+* @len: Length of the module config structure
+* @module_id: Module id
+* @param: pointer to module config parameter.
What is module_id for ? What does param point to ?
There are a lot of tiny modules in the previewer/resizer which are
enumerated as individual modules. The param points to the parameter set
that the module expects to be set.
Why don't you implement something similar to
VPFE_CMD_S_CCDC_RAW_PARAMS/VPFE_CMD_G_CCDC_RAW_PARAMS instead ?
I feel if we implement direct IOCTLS there might be many of them. To make sure
than independent of the number of internal modules present, having the same
IOCTL used for all modules is a good idea.
+*/
+ struct prev_module_param {
+ char version[IMP_MAX_NAME_SIZE];
Is there a need to express the version as a string instead of an integer ?
It could be integer. It is generally a fixed point num, and easy to read it
as a string than an integer. Can I keep it as a string?
Let's first decide whether a version field is needed at all :-)
Will remove.
+ unsigned short len;
+ unsigned short module_id;
+ void *param;
+ };
+
+2: IOCTL: PREV_S_CONFIG/PREV_G_CONFIG
+Description:
+ Sets/Gets the configuration required by the previewer channel
+Parameter:
+ /**
+* struct prev_channel_config - structure for configuring the
previewer
channel
+* @len: Length of the user configuration
+* @config: pointer to either single shot config or continuous
+*/
+ struct prev_channel_config {
+ unsigned short len;
+ void *config;
+ };
What's the difference between parameters and configuration ? What does
config point to ?
Config is setting which is required for a subdev to function based on what
it is set for (single shot/continuous.) common to all platforms. Parameters
are the settings for individual small sub-ips which might be slightly
different from one platform to another. Config points to
prev_single_shot_config or prev_continuous_config currently defined in
linux/dm3656ipipe.h. I think we will move it to a common location.
Why don't you implement something similar to
VPFE_CMD_S_CCDC_RAW_PARAMS/VPFE_CMD_G_CCDC_RAW_PARAMS here as well (same for
the resizer configuration ioctls) ?
Ditto.
+
+3: IOCTL: PREV_ENUM_CAP
+Description:
+ Queries the modules available in the image processor for
preview the
+ input image.
+Parameter:
+ /**
+* struct prev_cap - structure to enumerate capabilities of
previewer
+* @index: application use this to iterate over the available
modules
+* @version: version of the preview module
+* @module_id: module id
+* @control: control operation allowed in continuous mode? 1 -
allowed, 0
- not allowed
+* @path: path on which the module is sitting
+* @module_name: module name
+*/
+ struct prev_cap {
+ unsigned short index;
+ char
