Leadtek DTV2000DS Support
Hi, I recently purchased a Leadtek DTV2000DS PCI tuner to go in my mythtv pc. This is a AF9015 + AF9013 + NXP TDA18211 based PCI card. My PC previously had 2 Leadtek DTV1000S tuners and I was hoping to replace one or possibly both of them with the DTV2000DS which is dual tuner. I was just wondering if the DTV2000DS is supported by v4l-dvb and if there are any known issues? My PC is running an up to date Fedora13 (uname -a output) Linux mediabox 2.6.33.5-112.fc13.x86_64 #1 SMP Thu May 27 02:28:31 UTC 2010 x86_64 x86_64 x86_64 GNU/Linux I have also installed the current hg v4b-dvb source from here http://linuxtv.org/hg/v4l-dvb and downloaded the latest firmware for this card The problem I am seeing is that I have a lot of messages like this in /var/log/messages af9015: command failed:2 af9013: I2C read failed reg:d2e6 af9015: command failed:2 af9013: I2C read failed reg:d330 af9015: command failed:2 af9013: I2C read failed reg:d330 af9015: command failed:2 af9013: I2C read failed reg:d330 af9015: command failed:2 af9013: I2C read failed reg:9bee I also couldn't get the card to tune with mythtv, although it did seem to get a lock and record a picture using scan/tzap. Below is my the relevant parts of my dmesg output (my PC current has both a DTV1000S and the DTV200DS installed) Linux video capture interface: v2.00 saa7130/34: v4l2 driver version 0.2.16 loaded ACPI: PCI Interrupt Link [APC2] enabled at IRQ 17 alloc irq_desc for 17 on node 0 alloc kstat_irqs on node 0 saa7134 :01:07.0: PCI INT A - Link[APC2] - GSI 17 (level, low) - IRQ 17 saa7130[0]: found at :01:07.0, rev: 1, irq: 17, latency: 32, mmio: 0xfdeff000 saa7130[0]: subsystem: 107d:6655, board: Leadtek Winfast DTV1000S [card=175,autodetected] saa7130[0]: board init: gpio is 202 dvb-usb: found a 'Leadtek WinFast DTV2000DS' in warm state. dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. DVB: registering new adapter (Leadtek WinFast DTV2000DS) k8temp :00:18.3: Temperature readouts might be wrong - check erratum #141 IR NEC protocol handler initialized Registered IR keymap rc-winfast input: saa7134 IR (Leadtek Winfast DTV as /devices/pci:00/:00:08.0/:01:07.0/rc/rc0/input5 rc0: saa7134 IR (Leadtek Winfast DTV as /devices/pci:00/:00:08.0/:01:07.0/rc/rc0 IRQ 17/saa7130[0]: IRQF_DISABLED is not guaranteed on shared IRQs IR RC5(x) protocol handler initialized IR RC6 protocol handler initialized af9013: firmware version:5.1.0 DVB: registering adapter 0 frontend 0 (Afatech AF9013 DVB-T)... IR JVC protocol handler initialized saa7130[0]: i2c eeprom 00: 7d 10 55 66 54 20 1c 00 43 43 a9 1c 55 d2 b2 92 saa7130[0]: i2c eeprom 10: 00 ff 82 0e ff 20 ff ff ff ff ff ff ff ff ff ff saa7130[0]: i2c eeprom 20: 01 40 01 01 01 ff 01 03 08 ff 00 8a ff ff ff ff saa7130[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7130[0]: i2c eeprom 40: ff 35 00 c0 00 10 03 02 ff 04 ff ff ff ff ff ff saa7130[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7130[0]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7130[0]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7130[0]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7130[0]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7130[0]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7130[0]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7130[0]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7130[0]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7130[0]: i2c eeprom e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7130[0]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ACPI: PCI Interrupt Link [AAZA] enabled at IRQ 22 HDA Intel :00:07.0: PCI INT A - Link[AAZA] - GSI 22 (level, low) - IRQ 22 hda_intel: Disable MSI for Nvidia chipset hda_intel: position_fix set to 1 for device 1458:a022 HDA Intel :00:07.0: setting latency timer to 64 IR Sony protocol handler initialized hda_codec: ALC888: BIOS auto-probing. ALSA sound/pci/hda/hda_codec.c:4284: autoconfig: line_outs=4 (0x14/0x15/0x16/0x17/0x0) ALSA sound/pci/hda/hda_codec.c:4288:speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) ALSA sound/pci/hda/hda_codec.c:4292:hp_outs=1 (0x1b/0x0/0x0/0x0/0x0) ALSA sound/pci/hda/hda_codec.c:4293:mono: mono_out=0x0 ALSA sound/pci/hda/hda_codec.c:4296:dig-out=0x1e/0x0 ALSA sound/pci/hda/hda_codec.c:4304:inputs: mic=0x18, fmic=0x19, line=0x1a, fline=0x0, cd=0x1c, aux=0x0 tda18271 4-00c0: creating new instance TDA18271HD/C2 detected @ 4-00c0 ALSA sound/pci/hda/patch_realtek.c:1313: realtek: Enabling init ASM_ID=0xe601 CODEC_ID=10ec0888 Chip ID is not zero. It is not a TEA5767 tuner 6-0060: chip found @ 0xc0 (saa7130[0]) tda8290: no gate control were provided! saa7130[0]: registered device video0 [v4l2]
How to Integrate camera, mpeg decoder, colorspace conversion hardware into linux?
Hello, I'm looking for pointers on how to properly integrate the following SoC functions into Linux (media). The SoC in question has the following components: - camera interface - MPEG2/4 HW decoder - yuv-rgb conversion and scaling engine I have prototype code which captures 2 interlaced fields from the camera interface, constructs a full frame in system memory using the chips DMA engine and finally uses the scaler to convert the yuv data to rgb and scale it up to full display resulution; however it is one monolithic driver and one has to unload it to use the mpeg decoder (which also uses the scaler). The hardware blocks work independently from each other, the scaler is usually used to DMA its output into one of four framebuffer windows. The goal is to have mplayer capture analog video from the camera interface and/or have it feed digital video (DVB) through the mpeg decoder and display it. Additionally, since the scaler is indepedent from the rest, mplayer should be able to at least use the colorspace converter and decode other video formats in software. Are there any drivers in the kernel already which implement this kind of scheme? Thanks! Manuel Lauss -- 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] libv4l1: support up to 256 different frame sizes
Hi, Thanks for the patch I've applied it to the v4l-utils tree. Regards, Hans On 06/08/2010 07:36 PM, Balint Reczey wrote: Logitech, Inc. Webcam Pro 9000 supports 18 wich is more than the the originally supported 16. 256 should be enough for a while. --- lib/libv4lconvert/libv4lconvert-priv.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/lib/libv4lconvert/libv4lconvert-priv.h b/lib/libv4lconvert/libv4lconvert-priv.h index 6e880f8..b3e4c4e 100644 --- a/lib/libv4lconvert/libv4lconvert-priv.h +++ b/lib/libv4lconvert/libv4lconvert-priv.h @@ -29,7 +29,7 @@ #define ARRAY_SIZE(x) ((int)sizeof(x)/(int)sizeof((x)[0])) #define V4LCONVERT_ERROR_MSG_SIZE 256 -#define V4LCONVERT_MAX_FRAMESIZES 16 +#define V4LCONVERT_MAX_FRAMESIZES 256 #define V4LCONVERT_ERR(...) \ snprintf(data-error_msg, V4LCONVERT_ERROR_MSG_SIZE, \ -- 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] OMAP: V4L2: Enable V4L2 on ZOOM2/3 3630SDP
Defconfig changes to enable V4L2 on zoom2, zoom3 and 3630sdp boards. Signed-off-by: Mukund Mittal mmit...@ti.com Signed-off-by: Sudeep Basavaraj sudeep.basava...@ti.com Signed-off-by: Kishore Y kishor...@ti.com Signed-off-by: Rajkumar N rajkumar.nagara...@ti.com --- arch/arm/configs/omap_3630sdp_defconfig | 100 ++- arch/arm/configs/omap_zoom2_defconfig | 91 +++- arch/arm/configs/omap_zoom3_defconfig | 100 ++- 3 files changed, 284 insertions(+), 7 deletions(-) diff --git a/arch/arm/configs/omap_3630sdp_defconfig b/arch/arm/configs/omap_3630sdp_defconfig index 57c1c4f..6b6da13 100644 --- a/arch/arm/configs/omap_3630sdp_defconfig +++ b/arch/arm/configs/omap_3630sdp_defconfig @@ -879,7 +879,103 @@ CONFIG_REGULATOR_TWL4030=y # CONFIG_REGULATOR_LP3971 is not set # CONFIG_REGULATOR_TPS65023 is not set # CONFIG_REGULATOR_TPS6507X is not set -# CONFIG_MEDIA_SUPPORT is not set +CONFIG_MEDIA_SUPPORT=y + +# +# Multimedia core support +# +CONFIG_VIDEO_DEV=y +CONFIG_VIDEO_V4L2_COMMON=y +# CONFIG_VIDEO_ALLOW_V4L1 is not set +CONFIG_VIDEO_V4L1_COMPAT=y +# CONFIG_DVB_CORE is not set +CONFIG_VIDEO_MEDIA=y + +# +# Multimedia drivers +# +# CONFIG_MEDIA_ATTACH is not set +CONFIG_MEDIA_TUNER=y +# CONFIG_MEDIA_TUNER_CUSTOMISE is not set +CONFIG_MEDIA_TUNER_SIMPLE=y +CONFIG_MEDIA_TUNER_TDA8290=y +CONFIG_MEDIA_TUNER_TDA9887=y +CONFIG_MEDIA_TUNER_TEA5761=y +CONFIG_MEDIA_TUNER_TEA5767=y +CONFIG_MEDIA_TUNER_MT20XX=y +CONFIG_MEDIA_TUNER_XC2028=y +CONFIG_MEDIA_TUNER_XC5000=y +CONFIG_MEDIA_TUNER_MC44S803=y +CONFIG_VIDEO_V4L2=y +CONFIG_VIDEOBUF_GEN=y +CONFIG_VIDEOBUF_DMA_SG=y +CONFIG_VIDEO_CAPTURE_DRIVERS=y +# CONFIG_VIDEO_ADV_DEBUG is not set +# CONFIG_VIDEO_FIXED_MINOR_RANGES is not set +CONFIG_VIDEO_HELPER_CHIPS_AUTO=y +# CONFIG_VIDEO_VIVI is not set +# CONFIG_VIDEO_SAA5246A is not set +# CONFIG_VIDEO_SAA5249 is not set +CONFIG_VIDEO_OMAP3_OUT=y +CONFIG_VIDEO_OMAP2_VOUT=y +# CONFIG_SOC_CAMERA is not set +CONFIG_V4L_USB_DRIVERS=y +# CONFIG_USB_VIDEO_CLASS is not set +CONFIG_USB_VIDEO_CLASS_INPUT_EVDEV=y +CONFIG_USB_GSPCA=m +# CONFIG_USB_M5602 is not set +# CONFIG_USB_STV06XX is not set +# CONFIG_USB_GL860 is not set +# CONFIG_USB_GSPCA_CONEX is not set +# CONFIG_USB_GSPCA_ETOMS is not set +# CONFIG_USB_GSPCA_FINEPIX is not set +# CONFIG_USB_GSPCA_JEILINJ is not set +# CONFIG_USB_GSPCA_MARS is not set +# CONFIG_USB_GSPCA_MR97310A is not set +# CONFIG_USB_GSPCA_OV519 is not set +# CONFIG_USB_GSPCA_OV534 is not set +# CONFIG_USB_GSPCA_PAC207 is not set +# CONFIG_USB_GSPCA_PAC7302 is not set +# CONFIG_USB_GSPCA_PAC7311 is not set +# CONFIG_USB_GSPCA_SN9C20X is not set +# CONFIG_USB_GSPCA_SONIXB is not set +# CONFIG_USB_GSPCA_SONIXJ is not set +# CONFIG_USB_GSPCA_SPCA500 is not set +# CONFIG_USB_GSPCA_SPCA501 is not set +# CONFIG_USB_GSPCA_SPCA505 is not set +# CONFIG_USB_GSPCA_SPCA506 is not set +# CONFIG_USB_GSPCA_SPCA508 is not set +# CONFIG_USB_GSPCA_SPCA561 is not set +# CONFIG_USB_GSPCA_SQ905 is not set +# CONFIG_USB_GSPCA_SQ905C is not set +# CONFIG_USB_GSPCA_STK014 is not set +# CONFIG_USB_GSPCA_STV0680 is not set +# CONFIG_USB_GSPCA_SUNPLUS is not set +# CONFIG_USB_GSPCA_T613 is not set +# CONFIG_USB_GSPCA_TV8532 is not set +# CONFIG_USB_GSPCA_VC032X is not set +# CONFIG_USB_GSPCA_ZC3XX is not set +# CONFIG_VIDEO_PVRUSB2 is not set +# CONFIG_VIDEO_HDPVR is not set +# CONFIG_VIDEO_EM28XX is not set +# CONFIG_VIDEO_CX231XX is not set +# CONFIG_VIDEO_USBVISION is not set +# CONFIG_USB_ET61X251 is not set +# CONFIG_USB_SN9C102 is not set +# CONFIG_USB_ZC0301 is not set +CONFIG_USB_PWC_INPUT_EVDEV=y +# CONFIG_USB_ZR364XX is not set +# CONFIG_USB_STKWEBCAM is not set +# CONFIG_USB_S2255 is not set +CONFIG_RADIO_ADAPTERS=y +# CONFIG_I2C_SI4713 is not set +# CONFIG_RADIO_SI4713 is not set +# CONFIG_USB_DSBR is not set +# CONFIG_RADIO_SI470X is not set +# CONFIG_USB_MR800 is not set +# CONFIG_RADIO_TEA5764 is not set +# CONFIG_RADIO_TEF6862 is not set +# CONFIG_DAB is not set # # Graphics support @@ -929,7 +1025,7 @@ CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK=4 CONFIG_FB_OMAP2=y # CONFIG_FB_OMAP2_DEBUG_SUPPORT is not set # CONFIG_FB_OMAP2_FORCE_AUTO_UPDATE is not set -CONFIG_FB_OMAP2_NUM_FBS=3 +CONFIG_FB_OMAP2_NUM_FBS=1 # # OMAP2/3 Display Device Drivers diff --git a/arch/arm/configs/omap_zoom2_defconfig b/arch/arm/configs/omap_zoom2_defconfig index 50b2bb8..a95a550 100644 --- a/arch/arm/configs/omap_zoom2_defconfig +++ b/arch/arm/configs/omap_zoom2_defconfig @@ -845,12 +845,96 @@ CONFIG_TWL4030_CORE=y # # Multimedia core support # -# CONFIG_VIDEO_DEV is not set +CONFIG_VIDEO_DEV=y +CONFIG_VIDEO_V4L2_COMMON=y +# CONFIG_VIDEO_ALLOW_V4L1 is not set +CONFIG_VIDEO_V4L1_COMPAT=y # CONFIG_DVB_CORE is not set -# CONFIG_VIDEO_MEDIA is not set +CONFIG_VIDEO_MEDIA=y # # Multimedia drivers +# CONFIG_MEDIA_ATTACH is not set +CONFIG_MEDIA_TUNER=y +# CONFIG_MEDIA_TUNER_CUSTOMISE is not set +CONFIG_MEDIA_TUNER_SIMPLE=y
Re: [PATCH] OMAP: V4L2: Enable V4L2 on ZOOM2/3 3630SDP
Hi Rajkumar, On Wednesday 09 June 2010 11:51:45 Nagarajan, Rajkumar wrote: Defconfig changes to enable V4L2 on zoom2, zoom3 and 3630sdp boards. Defconfigs on ARM are going away. See the http://lkml.org/lkml/2010/6/2/472 thread on LKML. There's also a lengthy discussion about that on LAKML. Linus will not accept any change to the defconfig files anymore and currently plans to remove them completely for 2.6.36. -- 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] OMAP: V4L2: Enable V4L2 on ZOOM2/3 3630SDP
-Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Laurent Pinchart Sent: Wednesday, June 09, 2010 3:57 PM To: Nagarajan, Rajkumar Cc: linux-media@vger.kernel.org Subject: Re: [PATCH] OMAP: V4L2: Enable V4L2 on ZOOM2/3 3630SDP Hi Rajkumar, On Wednesday 09 June 2010 11:51:45 Nagarajan, Rajkumar wrote: Defconfig changes to enable V4L2 on zoom2, zoom3 and 3630sdp boards. Defconfigs on ARM are going away. See the http://lkml.org/lkml/2010/6/2/472 thread on LKML. There's also a lengthy discussion about that on LAKML. Linus will not accept any change to the defconfig files anymore and currently plans to remove them completely for 2.6.36. [Hiremath, Vaibhav] That's correct, and also FYI, you must cc linux-omap mailing list for the patches which touch any files under arch/arm/* Thanks, Vaibhav -- 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 -- 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
Attempting to use 2 KWorld PlusTV Dual DVB-T PCI tuners
Hi, I'm attempting to use 2 (I believe identical) KWorld PlusTV Dual DVB-T PCI tuners in my system. I have downloaded the firmware and at boot can see the cards being (nearly) successfully detected. It seems that both turners are being detected on one card, but only one on the second. I haven't had much time to test the cards and I'm afraid I'm not near the box to be able to provide the boot log at the moment. Looking through the code I can see static struct dvb_usb_device_properties af9015_properties[3]; here: http://lxr.linux.no/#linux+v2.6.32/drivers/media/dvb/dvb-usb/af9015.c#L43 Which suggests to me that it's only going to be able to register 3 tuners (or is it 3 cards?), is that the case? Martyn -- 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: [Bugme-new] [Bug 16050] New: The ibmcam driver is not working
Hi, On 06/03/2010 06:17 PM, Bill Davidsen wrote: So would you be willing to test the new driver (when it is finished) ? Sure, just let me know what kernel the patch is against. As you say, my cams are Model2 in the old nomenclature. Interesting that the size is set to 352x240 rather than CIF 352x288. And while xawtv sort of works with the latest 2.6.33.5-112.fc13.x86_64 koji kernel, cheese doesn't, not that I need it, but it worked on the early kernels. Ok, I've a version of the new driver ready for testing. To test you need the latest libv4l, and my gspca tree: First update libv4l, do: git clone git://linuxtv.org/v4l-utils.git cd v4l-utils/lib And then follow the instructions here: http://hansdegoede.livejournal.com/7622.html Then get my gspca tree, and compile and install it, note that this is based on the special hg v4l-dvb tree, which is meant as an overlay to your running kernel, so doing this will replace the v4l and dvb subsystems of your kernel while leaving the rest as is: hg clone http://linuxtv.org/hg/~hgoede/ibmcam cd ibmcam make menuconfig deselect the ibmcam driver and make any other changes you wish make sudo make install reboot, yes really Now after the reboot do the following as root: echo 63 /sys/module/gspca_main/parameters/debug And then try using your camera with a v4l app such as cheese, camorama or some such. Please collect the output of dmesg and mail it to me. Also please try running at a resolution of 176x144. If things don't work (chances are they won't) please try to describe what exactly is the problem. ie is the image shifted left / right / up / down with some garbage or black area being shown on the other side, is there no image at all is it to dark / light, are the colors wrong etc. Thanks Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] V4L/DVB: Use custom I2C probing function mechanism
Hi Jean, On Tue, Jun 08, 2010 at 10:01:00AM +0200, Jean Delvare wrote: Now that i2c-core offers the possibility to provide custom probing function for I2C devices, let's make use of it. Signed-off-by: Jean Delvare kh...@linux-fr.org Acked-by: Mauro Carvalho Chehab mche...@redhat.com If this custom function is in i2c-core, maybe it should be documented? Regards, Wolfram -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature
[PATCH] v4l: Add MPC5121e VIU video capture driver
From: Hongjun Chen hong-jun.c...@freescale.com
Adds support for Video-In (VIU) unit of MPC5121e.
The driver supports RGB888/RGB565 formats, capture
and overlay on MPC5121e DIU frame buffer.
Signed-off-by: Hongjun Chen hong-jun.c...@freescale.com
Signed-off-by: Anatolij Gustschin ag...@denx.de
---
Please consider this driver for inclusion in 2.6.36. Thanks!
drivers/media/video/Kconfig | 12 +
drivers/media/video/Makefile |1 +
drivers/media/video/fsl-viu.c | 1620 +
3 files changed, 1633 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/fsl-viu.c
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index bdbc9d3..45bef41 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -557,6 +557,18 @@ config VIDEO_DAVINCI_VPIF
To compile this driver as a module, choose M here: the
module will be called vpif.
+config VIDEO_VIU
+ tristate Freescale VIU Video Driver
+ depends on VIDEO_V4L2 PPC_MPC512x
+ select VIDEOBUF_DMA_CONTIG
+ default y
+ ---help---
+ Support for Freescale VIU video driver. This device captures
+ video data, or overlays video on DIU frame buffer.
+
+ Say Y here if you want to enable VIU device on MPC5121e Rev2+.
+ In doubt, say N.
+
config VIDEO_VIVI
tristate Virtual Video Driver
depends on VIDEO_DEV VIDEO_V4L2 !SPARC32 !SPARC64 FONTS
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index cc93859..542d786 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -151,6 +151,7 @@ obj-$(CONFIG_USB_S2255) += s2255drv.o
obj-$(CONFIG_VIDEO_IVTV) += ivtv/
obj-$(CONFIG_VIDEO_CX18) += cx18/
+obj-$(CONFIG_VIDEO_VIU) += fsl-viu.o
obj-$(CONFIG_VIDEO_VIVI) += vivi.o
obj-$(CONFIG_VIDEO_MEM2MEM_TESTDEV) += mem2mem_testdev.o
obj-$(CONFIG_VIDEO_CX23885) += cx23885/
diff --git a/drivers/media/video/fsl-viu.c b/drivers/media/video/fsl-viu.c
new file mode 100644
index 000..efec0a0
--- /dev/null
+++ b/drivers/media/video/fsl-viu.c
@@ -0,0 +1,1620 @@
+/*
+ * Copyright 2008 Freescale Semiconductor, Inc. All Rights Reserved.
+ *
+ * Freescale VIU video driver
+ *
+ * Authors: Hongjun Chen hong-jun.c...@freescale.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ */
+
+#include linux/module.h
+#include linux/clk.h
+#include linux/kernel.h
+#include linux/i2c.h
+#include linux/init.h
+#include linux/interrupt.h
+#include linux/io.h
+#include linux/of_platform.h
+#include linux/version.h
+#include media/v4l2-common.h
+#include media/v4l2-device.h
+#include media/v4l2-ioctl.h
+#include media/videobuf-dma-contig.h
+
+#define BUFFER_TIMEOUT msecs_to_jiffies(500) /* 0.5 seconds */
+
+static struct viu_reg reg_val;
+static char first = 1, dma_done;
+
+#define DRV_NAME fsl_viu
+#define VIU_MAJOR_VERSION 0
+#define VIU_MINOR_VERSION 4
+#define VIU_RELEASE0
+#define VIU_VERSIONKERNEL_VERSION(VIU_MAJOR_VERSION, \
+ VIU_MINOR_VERSION, \
+ VIU_RELEASE)
+
+#defineVIU_VID_MEM_LIMIT 4 /* Video memory limit, in Mb */
+
+/* I2C address of video decoder chip is 0x4A */
+#define VIU_VIDEO_DECODER_ADDR 0x25
+
+/* supported controls */
+static struct v4l2_queryctrl viu_qctrl[] = {
+ {
+ .id= V4L2_CID_BRIGHTNESS,
+ .type = V4L2_CTRL_TYPE_INTEGER,
+ .name = Brightness,
+ .minimum = 0,
+ .maximum = 255,
+ .step = 1,
+ .default_value = 127,
+ .flags = 0,
+ }, {
+ .id= V4L2_CID_CONTRAST,
+ .type = V4L2_CTRL_TYPE_INTEGER,
+ .name = Contrast,
+ .minimum = 0,
+ .maximum = 255,
+ .step = 0x1,
+ .default_value = 0x10,
+ .flags = 0,
+ }, {
+ .id= V4L2_CID_SATURATION,
+ .type = V4L2_CTRL_TYPE_INTEGER,
+ .name = Saturation,
+ .minimum = 0,
+ .maximum = 255,
+ .step = 0x1,
+ .default_value = 127,
+ .flags = 0,
+ }, {
+ .id= V4L2_CID_HUE,
+ .type = V4L2_CTRL_TYPE_INTEGER,
+ .name = Hue,
+ .minimum = -128,
+ .maximum = 127,
+ .step
Re: [PATCH 2/2] V4L/DVB: Use custom I2C probing function mechanism
Hi Wolfram, On Wed, 9 Jun 2010 17:05:40 +0200, Wolfram Sang wrote: Hi Jean, On Tue, Jun 08, 2010 at 10:01:00AM +0200, Jean Delvare wrote: Now that i2c-core offers the possibility to provide custom probing function for I2C devices, let's make use of it. Signed-off-by: Jean Delvare kh...@linux-fr.org Acked-by: Mauro Carvalho Chehab mche...@redhat.com If this custom function is in i2c-core, maybe it should be documented? What kind of documentation would you expect for a one-line function? Where, and aimed at who? Patch welcome ;) -- Jean Delvare -- 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 3/4] ir-core: move decoding state to ir_raw_event_ctrl
On Wed, Jun 09, 2010 at 09:29:08AM -0400, Jarod Wilson wrote: On Tue, Jun 08, 2010 at 11:46:36PM -0400, Jarod Wilson wrote: On Tue, Jun 8, 2010 at 1:50 PM, David Härdeman da...@hardeman.nu wrote: b) Mauro mentioned in 4bdf28c0.4060...@redhat.com that: I liked the idea of your redesign, but I didn't like the removal of a per-decoder sysfs entry. As already discussed, there are cases where we'll need a per-decoder sysfs entry (lirc_dev is probably one of those cases - also Jarod's imon driver is currently implementing a modprobe parameter that needs to be moved to the driver). could you please confirm if your lirc and/or imon drivers would be negatively affected by the proposed patches? Will do so once I get them wedged in on top. Got it all merged and compiling, but not yet runtime tested. Compiling alone sheds some light on things though... So this definitely negatively impacts my ir-core-to-lirc_dev (ir-lirc-codec.c) bridge driver, as it was doing the lirc_dev device registration work in its register function. However, if (after your patchset) we add a new pair of callbacks replacing raw_register and raw_unregister, which are optional, that work could be done there instead, so I don't think this is an insurmountable obstacle for the lirc bits. While I'm not sure exactly what callbacks you're suggesting, it still sounds like the callbacks would have the exact same problems that the current code has (i.e. the decoder will be blissfully unaware of hardware which exists before the decoder is loaded). Right? As for the imon driver, the modprobe parameter in question (iirc) was already removed from the driver, as its functionality is replaced by implementing a change_protocol callback. However, there's a request to add it (or something like it) back to the driver to allow disabling the IR part altogether, and there are a few other modparams that might be better suited as sysfs entries. However, its actually not relevant to the case of registering raw protocol handlers, as the imon devices do their decoding in hardware. I can see the possibility for protocol-specific knobs in sysfs though. But I think the same optional callbacks I'd use to keep the lirc bits working could also be used for this. Can't think of a good name for these yet, probably need more coffee first... ;) But those sysfs entries wouldn't be per-decoder-per-hardware-devicethey'd just be per-hardware-device...right? -- David Härdeman -- 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 3/4] ir-core: move decoding state to ir_raw_event_ctrl
On Wed, Jun 09, 2010 at 07:56:21PM +0200, David Härdeman wrote: On Wed, Jun 09, 2010 at 09:29:08AM -0400, Jarod Wilson wrote: On Tue, Jun 08, 2010 at 11:46:36PM -0400, Jarod Wilson wrote: On Tue, Jun 8, 2010 at 1:50 PM, David Härdeman da...@hardeman.nu wrote: b) Mauro mentioned in 4bdf28c0.4060...@redhat.com that: I liked the idea of your redesign, but I didn't like the removal of a per-decoder sysfs entry. As already discussed, there are cases where we'll need a per-decoder sysfs entry (lirc_dev is probably one of those cases - also Jarod's imon driver is currently implementing a modprobe parameter that needs to be moved to the driver). could you please confirm if your lirc and/or imon drivers would be negatively affected by the proposed patches? Will do so once I get them wedged in on top. Got it all merged and compiling, but not yet runtime tested. Compiling alone sheds some light on things though... So this definitely negatively impacts my ir-core-to-lirc_dev (ir-lirc-codec.c) bridge driver, as it was doing the lirc_dev device registration work in its register function. However, if (after your patchset) we add a new pair of callbacks replacing raw_register and raw_unregister, which are optional, that work could be done there instead, so I don't think this is an insurmountable obstacle for the lirc bits. While I'm not sure exactly what callbacks you're suggesting, Essentially: .setup_other_crap .tear_down_other_crap ...which in the ir-lirc-codec case, register ir-lirc-codec for a specific hardware receiver as an lirc_dev client, and conversely, tear it down. it still sounds like the callbacks would have the exact same problems that the current code has (i.e. the decoder will be blissfully unaware of hardware which exists before the decoder is loaded). Right? In my head, this was going to work out, but you're correct, I still have the exact same problem -- its not in ir_raw_handler_list yet when ir_raw_event_register runs, and thus the callback never fires, so lirc_dev never actually gets wired up to ir-lirc-codec. It now knows about the lirc decoder, but its completely useless. Narf. As for the imon driver, the modprobe parameter in question (iirc) was already removed from the driver, as its functionality is replaced by implementing a change_protocol callback. However, there's a request to add it (or something like it) back to the driver to allow disabling the IR part altogether, and there are a few other modparams that might be better suited as sysfs entries. However, its actually not relevant to the case of registering raw protocol handlers, as the imon devices do their decoding in hardware. I can see the possibility for protocol-specific knobs in sysfs though. But I think the same optional callbacks I'd use to keep the lirc bits working could also be used for this. Can't think of a good name for these yet, probably need more coffee first... ;) But those sysfs entries wouldn't be per-decoder-per-hardware-devicethey'd just be per-hardware-device...right? Most likely. But I think its possible someone would want to want to tweak some parameter that is both protocol and hardware device specific. Just sheer speculation at the moment though, I don't have a concrete example. -- Jarod Wilson ja...@redhat.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
[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Wed Jun 9 19:00:57 CEST 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 14944:973004c9c2ae git master: f6760aa024199cfbce564311dc4bc4d47b6fb349 git media-master: 41c5f984b67b331064e69acc9fca5e99bf73d400 gcc version: i686-linux-gcc (GCC) 4.4.3 host hardware:x86_64 host os: 2.6.32.5 linux-2.6.32.6-armv5: OK linux-2.6.33-armv5: OK linux-2.6.34-armv5: WARNINGS linux-2.6.35-rc1-armv5: ERRORS linux-2.6.32.6-armv5-davinci: OK linux-2.6.33-armv5-davinci: OK linux-2.6.34-armv5-davinci: WARNINGS linux-2.6.35-rc1-armv5-davinci: ERRORS linux-2.6.32.6-armv5-ixp: WARNINGS linux-2.6.33-armv5-ixp: WARNINGS linux-2.6.34-armv5-ixp: WARNINGS linux-2.6.35-rc1-armv5-ixp: ERRORS linux-2.6.32.6-armv5-omap2: OK linux-2.6.33-armv5-omap2: OK linux-2.6.34-armv5-omap2: WARNINGS linux-2.6.35-rc1-armv5-omap2: ERRORS linux-2.6.22.19-i686: ERRORS linux-2.6.23.17-i686: ERRORS linux-2.6.24.7-i686: WARNINGS linux-2.6.25.20-i686: WARNINGS linux-2.6.26.8-i686: WARNINGS linux-2.6.27.44-i686: WARNINGS linux-2.6.28.10-i686: WARNINGS linux-2.6.29.1-i686: WARNINGS linux-2.6.30.10-i686: WARNINGS linux-2.6.31.12-i686: OK linux-2.6.32.6-i686: OK linux-2.6.33-i686: OK linux-2.6.34-i686: WARNINGS linux-2.6.35-rc1-i686: ERRORS linux-2.6.32.6-m32r: OK linux-2.6.33-m32r: OK linux-2.6.34-m32r: WARNINGS linux-2.6.35-rc1-m32r: ERRORS linux-2.6.32.6-mips: OK linux-2.6.33-mips: OK linux-2.6.34-mips: WARNINGS linux-2.6.35-rc1-mips: ERRORS linux-2.6.32.6-powerpc64: OK linux-2.6.33-powerpc64: OK linux-2.6.34-powerpc64: WARNINGS linux-2.6.35-rc1-powerpc64: ERRORS linux-2.6.22.19-x86_64: ERRORS linux-2.6.23.17-x86_64: ERRORS linux-2.6.24.7-x86_64: WARNINGS linux-2.6.25.20-x86_64: WARNINGS linux-2.6.26.8-x86_64: WARNINGS linux-2.6.27.44-x86_64: WARNINGS linux-2.6.28.10-x86_64: WARNINGS linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30.10-x86_64: WARNINGS linux-2.6.31.12-x86_64: OK linux-2.6.32.6-x86_64: OK linux-2.6.33-x86_64: OK linux-2.6.34-x86_64: WARNINGS linux-2.6.35-rc1-x86_64: ERRORS linux-git-armv5: WARNINGS linux-git-armv5-davinci: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-armv5-omap2: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-x86_64: WARNINGS spec: ERRORS spec-git: OK sparse: ERRORS linux-2.6.16.62-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: ERRORS linux-2.6.19.7-i686: ERRORS linux-2.6.20.21-i686: ERRORS linux-2.6.21.7-i686: ERRORS linux-2.6.16.62-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: ERRORS linux-2.6.19.7-x86_64: ERRORS linux-2.6.20.21-x86_64: ERRORS linux-2.6.21.7-x86_64: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.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
avertv h830 hybrid tv usb stick
I just have bought an avertv h830 hybrid tv usb stick, the vendor having certified to me it will work under linux... By now it does not. When I plug the stick, no /dev/video device is created. I suppose it lacks some firmware supporting this hardware. Does somebody know if this stick will be supported in the future ? Jacques Weber -- 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: avertv h830 hybrid tv usb stick
On Wed, Jun 9, 2010 at 6:41 PM, Jacques Weber jacqwe...@gmail.com wrote: I just have bought an avertv h830 hybrid tv usb stick, the vendor having certified to me it will work under linux... By now it does not. When I plug the stick, no /dev/video device is created. I suppose it lacks some firmware supporting this hardware. Does somebody know if this stick will be supported in the future ? If the vendor certified it, then you should be calling their technical support instead of asking us. 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 3/4] ir-core: move decoding state to ir_raw_event_ctrl
On Wed, Jun 9, 2010 at 2:15 PM, Jarod Wilson ja...@redhat.com wrote: On Wed, Jun 09, 2010 at 07:56:21PM +0200, David Härdeman wrote: On Wed, Jun 09, 2010 at 09:29:08AM -0400, Jarod Wilson wrote: ... So this definitely negatively impacts my ir-core-to-lirc_dev (ir-lirc-codec.c) bridge driver, as it was doing the lirc_dev device registration work in its register function. However, if (after your patchset) we add a new pair of callbacks replacing raw_register and raw_unregister, which are optional, that work could be done there instead, so I don't think this is an insurmountable obstacle for the lirc bits. While I'm not sure exactly what callbacks you're suggesting, Essentially: .setup_other_crap .tear_down_other_crap ...which in the ir-lirc-codec case, register ir-lirc-codec for a specific hardware receiver as an lirc_dev client, and conversely, tear it down. it still sounds like the callbacks would have the exact same problems that the current code has (i.e. the decoder will be blissfully unaware of hardware which exists before the decoder is loaded). Right? In my head, this was going to work out, but you're correct, I still have the exact same problem -- its not in ir_raw_handler_list yet when ir_raw_event_register runs, and thus the callback never fires, so lirc_dev never actually gets wired up to ir-lirc-codec. It now knows about the lirc decoder, but its completely useless. Narf. And now I have it working atop your patches. Its a bit of a nasty-ish hack, at least for the lirc case, but its working, even in the case where the decoder drivers aren't actually loaded until after the device driver. I've added one extra param to each protocol-specific struct in ir-core-priv.h (bool initialized) and hooked into the protocol-specific decode functions to both determine whether a protocol should be enabled or disabled by default, and to run any additionally required initialization (such as in the ir-lirc-codec case). So initially, mceusb comes up with all decoders enabled. Then when ir comes in, every protocol-specific decoder fires. Each of them check for whether or not they've been fully initialized, and if not, we check the loaded keymap, and if it doesn't match, we disable that decoder (bringing back the disable protocol handlers we don't need functionality that disappeared w/this patchset). In the lirc case, we actually do all the work needed to wire up the connection over to lirc_dev. This works perfectly fine for all the in-kernel decoders, but has one minor shortcoming for ir-lirc-codec, in that /dev/lirc0 won't actually exist until the first incoming ir signal is seen. lircd can handle this case just fine, it'll wait for /dev/lirc0 to show up, but it doesn't come up fast enough to catch and decode the very first incoming ir signal. Subsequent ones work perfectly fine though. This need to initialize the link via incoming ir is a bit problematic if you're using a device for transmit-only (e.g., and mceusb device hooked to a mythtv backend in the closet or something), as there would be a strong possibility of /dev/lirc0 never getting hooked up. I can think of a few workarounds, but none are particularly clean and/or automagic. Not sure how palatable it is, but here it is: http://git.wilsonet.com/linux-2.6-ir-wip.git/?a=commitdiff;h=8f2be576ecb82448daa0c0d789bf0c978c66b103 -- Jarod Wilson ja...@wilsonet.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
V4L Camera frame timestamp question
Hi, I'm currently using the V4L-DVB driver to control a few logitech webcams and playstation eye cameras on a Gubuntu system. Everything works just fine except one thing: the buffer timestamp value seems wrong. The way I get the timestamp value is through the v4l2_buffer struct like this: struct v4l2_buffer buf; CLEAR(buf); buf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE; buf.memory = V4L2_MEMORY_MMAP; assert(ioctl(fd_, VIDIOC_DQBUF, buf)); printf(timestamp = %.3f, buf.timestamp.tv_sec + buf.timestamp.tv_usec / 100); this should be the timestamp of when the image is taken (similar to gettimeofday() function) but the value I got is something way smaller (e.g. 75000) than what it should be (e.g. 1275931384) Is this a known problem? Thanks! -- 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
[cx231xx 1/2] Added support for s5h1432 demod
From 53df9742b92902b5fa9d28b2dcc949cb495725a5 Mon Sep 17 00:00:00 2001
Message-Id:
53df9742b92902b5fa9d28b2dcc949cb495725a5.1276143429.git.palash.bandyopadh...@conexant.com
From: palash palash.bandyopadh...@conexant.com
Date: Wed, 9 Jun 2010 21:13:17 -0700
Subject: [cx231xx 1/2] Added support for s5h1432 demod
To: linux-media@vger.kernel.org
Signed-off-by: palash palash.bandyopadh...@conexant.com
create mode 100644 drivers/media/dvb/frontends/s5h1432.c
create mode 100644 drivers/media/dvb/frontends/s5h1432.h
diff --git a/drivers/media/dvb/frontends/Kconfig
b/drivers/media/dvb/frontends/Kconfig
index cd7f9b7..257c2fa 100644
--- a/drivers/media/dvb/frontends/Kconfig
+++ b/drivers/media/dvb/frontends/Kconfig
@@ -257,6 +257,13 @@ config DVB_CX22702
help
A DVB-T tuner module. Say Y when you want to support this frontend.
+config DVB_S5H1432
+ tristate Samsung s5h1432 demodulator (OFDM)
+ depends on DVB_CORE I2C
+ default m if DVB_FE_CUSTOMISE
+ help
+ A DVB-T tuner module. Say Y when you want to support this frontend.
+
config DVB_DRX397XD
tristate Micronas DRX3975D/DRX3977D based
depends on DVB_CORE I2C
diff --git a/drivers/media/dvb/frontends/Makefile
b/drivers/media/dvb/frontends/Makefile
index 874e8ad..faaa9aa 100644
--- a/drivers/media/dvb/frontends/Makefile
+++ b/drivers/media/dvb/frontends/Makefile
@@ -16,6 +16,7 @@ obj-$(CONFIG_DVB_STB0899) += stb0899.o
obj-$(CONFIG_DVB_STB6100) += stb6100.o
obj-$(CONFIG_DVB_SP8870) += sp8870.o
obj-$(CONFIG_DVB_CX22700) += cx22700.o
+obj-$(CONFIG_DVB_S5H1432) += s5h1432.o
obj-$(CONFIG_DVB_CX24110) += cx24110.o
obj-$(CONFIG_DVB_TDA8083) += tda8083.o
obj-$(CONFIG_DVB_L64781) += l64781.o
diff --git a/drivers/media/dvb/frontends/s5h1432.c
b/drivers/media/dvb/frontends/s5h1432.c
new file mode 100644
index 000..92d134e
--- /dev/null
+++ b/drivers/media/dvb/frontends/s5h1432.c
@@ -0,0 +1,446 @@
+/*
+Samsung s5h1432 DVB-T demodulator driver
+
+Copyright (C) 2009 Bill Liu bill@conexant.com
+
+This program is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 2 of the License, or
+(at your option) any later version.
+
+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., 675 Mass Ave, Cambridge, MA 02139, USA.
+
+*/
+
+#include linux/kernel.h
+#include linux/init.h
+#include linux/module.h
+#include linux/string.h
+#include linux/slab.h
+#include linux/delay.h
+#include dvb_frontend.h
+#include s5h1432.h
+
+struct s5h1432_state {
+
+ struct i2c_adapter *i2c;
+
+ /* configuration settings */
+ const struct s5h1432_config *config;
+
+ struct dvb_frontend frontend;
+
+ fe_modulation_t current_modulation;
+ unsigned int first_tune:1;
+
+ u32 current_frequency;
+ int if_freq;
+
+ u8 inversion;
+};
+
+static int debug;
+
+#define dprintk(arg...) do { \
+ if (debug) \
+ printk(arg);\
+ } while (0)
+
+
+static int s5h1432_writereg(struct s5h1432_state *state,
+ u8 addr, u8 reg, u8 data)
+{
+ int ret;
+ u8 buf[] = { reg, data };
+
+ struct i2c_msg msg = { .addr = addr, .flags = 0, .buf = buf, .len = 2 };
+
+ ret = i2c_transfer(state-i2c, msg, 1);
+
+ if (ret != 1)
+ printk(KERN_ERR %s: writereg error 0x%02x 0x%02x 0x%04x,
+ ret == %i)\n, __func__, addr, reg, data, ret);
+
+ return (ret != 1) ? -1 : 0;
+}
+
+static u8 s5h1432_readreg(struct s5h1432_state *state, u8 addr, u8 reg)
+{
+ int ret;
+ u8 b0[] = { reg };
+ u8 b1[] = { 0 };
+
+ struct i2c_msg msg[] = {
+ { .addr = addr, .flags = 0, .buf = b0, .len = 1 },
+ { .addr = addr, .flags = I2C_M_RD, .buf = b1, .len = 1 } };
+
+ ret = i2c_transfer(state-i2c, msg, 2);
+
+ if (ret != 2)
+ printk(KERN_ERR %s: readreg error (ret == %i)\n,
+ __func__, ret);
+ return b1[0];
+}
+
+static int s5h1432_sleep(struct dvb_frontend *fe)
+{
+ return 0;
+}
+
+static int s5h1432_set_channel_bandwidth(struct dvb_frontend *fe, u32
bandwidth)
+{
+
+ struct s5h1432_state *state = fe-demodulator_priv;
+
+ u8 reg = 0;
+
+
+/* Register[0x2E] bit 3:2 : 8MHz = 0; 7MHz = 1; 6MHz = 2*/
+ reg = s5h1432_readreg(state, S5H1432_I2C_TOP_ADDR, 0x2E);
+ reg = ~(0x0C);
+ switch (bandwidth) {
+ case 6:
+ reg |= 0x08;
+ break;
+
Re: [PATCH v3 0/3] Driver for the i.MX2x CMOS Sensor Interface
Hi linux-media list,
Ping?
Any news on this?
baruch
On Wed, May 26, 2010 at 12:13:15PM +0300, Baruch Siach wrote:
This series contains a soc_camera driver for the i.MX25/i.MX27 CSI device, and
platform code for the i.MX25 and i.MX27 chips. This driver is based on a
driver for i.MX27 CSI from Sascha Hauer, that Alan Carvalho de Assis has
posted in linux-media last December[1]. I tested the mx2_camera driver on the
i.MX25 PDK. Sascha Hauer has tested a earlier version of this driver on an
i.MX27 based board. I included in this version some fixes from Sascha that
enable i.MX27 support.
[1] https://patchwork.kernel.org/patch/67636/
Changes v2 - v3
Address more comments from Guennadi Liakhovetski.
Applied part of Sashca's patch that I forgot in v2.
Changes v1 - v2
Addressed the comments of Guennadi Liakhovetski except from the following:
1. The mclk_get_divisor implementation, since I don't know what this code
is good for
2. mx2_videobuf_release should not set pcdev-active on i.MX27, because
mx27_camera_frame_done needs this pointer
3. In mx27_camera_emma_buf_init I don't know the meaning of those hard
coded magic numbers
Applied i.MX27 fixes from Sascha.
Baruch Siach (3):
mx2_camera: Add soc_camera support for i.MX25/i.MX27
mx27: add support for the CSI device
mx25: add support for the CSI device
arch/arm/mach-mx2/clock_imx27.c |2 +-
arch/arm/mach-mx2/devices.c | 31 +
arch/arm/mach-mx2/devices.h |1 +
arch/arm/mach-mx25/clock.c | 14 +-
arch/arm/mach-mx25/devices.c | 22 +
arch/arm/mach-mx25/devices.h |1 +
arch/arm/plat-mxc/include/mach/memory.h |4 +-
arch/arm/plat-mxc/include/mach/mx25.h|2 +
arch/arm/plat-mxc/include/mach/mx2_cam.h | 46 +
drivers/media/video/Kconfig | 13 +
drivers/media/video/Makefile |1 +
drivers/media/video/mx2_camera.c | 1488
++
12 files changed, 1620 insertions(+), 5 deletions(-)
create mode 100644 arch/arm/plat-mxc/include/mach/mx2_cam.h
create mode 100644 drivers/media/video/mx2_camera.c
--
~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
--
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
