Re: [linux-dvb] szap2 and Band L???
Hi, of course does szap tune on L-Band, nothing else. Try to set lnb settings (LOF = 0) On Wednesday 06 May 2009 10:03:00 armel frey wrote: Hi, I have a Hauppauge HVR-4000 and i would like to receive DVB-S2 ! The card works well in DVB-S and seems to work with szap-s2, but my problem is that i have to receive DVB-S2 in Band L (950...2150MHz) and szap2 don't tune this low fréquency. I would like to know if there is a patch or something else which make it possible?? 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
Re: [PATCH] sonixj new USB ID
On Wed, 6 May 2009 17:26:23 +0300 Jani Monoses j...@ubuntu.com wrote: This adds the Hercules Deluxe Optical Glass USBID to gspca, it appears to be the same or at least very similar to the Hercules Silver Classic (which is 0x06f8, 0x3004) With this patch I had the camera showing pictures. Patch is against http://linuxtv.org/hg/~jfrancois/gspca/http://linuxtv.org/hg/%7Ejfrancois/gspca/tree as of today. Signed-off-by: Jani Monoses j...@ubuntu.com Added. Thanks. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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] MSI t...@nywhere A/D (not 1.1!) IR remote control
Hi, I just made the IR remote control for MSI t...@nywhere A/D work and I want to test it on some other cards, so I decided to send this patch to this mailing list. This patch is originally created against kernel sources 2.6.29.1. I was unable to detect remote, because i2c port is not answering without some inicialization, so I add parameter to module ir-kbd-i2c. Parameter is called i2cport and for my MSI t...@nywhere A/D must be set to 0x0b. (modprobe ir-kbd-i2c i2cport=0x0b) I also added new card type 222 (just for testing) whitch is detected automatically with PCI device 4e42:3306, because this card is supposet to be clone of LifeWiev FlyDVB-T Hybrid, but when I tested some patches for this card, sometimes it doesn't work, so I think, there can be some differences. So please if you have this card, can you test it and respond? (you can try it with LifeView FlyDVB-T Hybrid too) Thank all developers of V4L for great work and sorry for my terrible english :) Mike Fly Czech republic diff -upr drivers/media/common/ir-keymaps.c drivers/media/common/ir-keymaps.c --- drivers/media/common/ir-keymaps.c 2009-04-02 22:55:27.0 +0200 +++ drivers/media/common/ir-keymaps.c 2009-05-06 07:58:10.0 +0200 @@ -2604,3 +2604,41 @@ IR_KEYTAB_TYPE ir_codes_ati_tv_wonder_hd }; EXPORT_SYMBOL_GPL(ir_codes_ati_tv_wonder_hd_600); + +IR_KEYTAB_TYPE ir_codes_msi_tvanywhere_ad[IR_KEYTAB_SIZE] = { + [ 0x00 ] = KEY_POWER, + [ 0x01 ] = KEY_F, + [ 0x03 ] = KEY_1, + [ 0x04 ] = KEY_2, + [ 0x05 ] = KEY_3, + [ 0x07 ] = KEY_4, + [ 0x08 ] = KEY_5, + [ 0x09 ] = KEY_6, + [ 0x0b ] = KEY_7, + [ 0x0c ] = KEY_8, + [ 0x0d ] = KEY_9, + [ 0x0f ] = KEY_0, + [ 0x06 ] = KEY_F1, + [ 0x10 ] = KEY_MUTE, + [ 0x02 ] = KEY_F2, + [ 0x1b ] = KEY_F3, + [ 0x12 ] = KEY_UP, + [ 0x13 ] = KEY_DOWN, + [ 0x17 ] = KEY_LEFT, + [ 0x14 ] = KEY_RIGHT, + [ 0x1d ] = KEY_ENTER, + [ 0x1a ] = KEY_F4, + [ 0x18 ] = KEY_F5, + [ 0x1e ] = KEY_RECORD, + [ 0x15 ] = KEY_F6, + [ 0x1c ] = KEY_F7, + [ 0x19 ] = KEY_REWIND, + [ 0x0a ] = KEY_PAUSE, + [ 0x1f ] = KEY_FORWARD, + [ 0x16 ] = KEY_BACK, + [ 0x11 ] = KEY_STOP, + [ 0x0e ] = KEY_END, +}; +EXPORT_SYMBOL_GPL(ir_codes_msi_tvanywhere_ad); + diff -upr drivers/media/video/saa7134/saa7134-cards.c drivers/media/video/saa7134/saa7134-cards.c --- drivers/media/video/saa7134/saa7134-cards.c 2009-04-02 22:55:27.0 +0200 +++ drivers/media/video/saa7134/saa7134-cards.c 2009-05-06 07:26:52.0 +0200 @@ -4673,6 +4673,40 @@ struct saa7134_board saa7134_boards[] = .amux = TV, .gpio = 0x01, }, + }, + [SAA7134_BOARD_MSI_TVANYWHERE_AD] = { + .name = LifeView FlyDVB-T Hybrid Cardbus/MSI TV @nywhere A/D NB, + .audio_clock= 0x0020, + .tuner_type = TUNER_PHILIPS_TDA8290, + .radio_type = UNSET, + .tuner_addr = ADDR_UNSET, + .radio_addr = ADDR_UNSET, + .mpeg = SAA7134_MPEG_DVB, + .gpiomask = 0x0060, /* Bit 21 0=Radio, Bit 22 0=TV */ + .inputs = {{ + .name = name_tv, + .vmux = 1, + .amux = TV, + .gpio = 0x20, /* GPIO21=High for TV input */ + .tv = 1, + },{ + .name = name_svideo,/* S-Video signal on S-Video input */ + .vmux = 8, + .amux = LINE2, + },{ + .name = name_comp1, /* Composite signal on S-Video input */ + .vmux = 0, + .amux = LINE2, + },{ + .name = name_comp2, /* Composite input */ + .vmux = 3, + .amux = LINE2, + }}, + .radio = { + .name = name_radio, + .amux = TV, + .gpio = 0x00, /* GPIO21=Low for FM radio antenna */ + }, }, }; @@ -5291,6 +5325,12 @@ struct pci_device_id saa7134_pci_tbl[] = },{ .vendor = PCI_VENDOR_ID_PHILIPS, .device = PCI_DEVICE_ID_PHILIPS_SAA7133, + .subvendor= 0x4e42, + .subdevice= 0x3306, + .driver_data = SAA7134_BOARD_MSI_TVANYWHERE_AD, + },{ + .vendor = PCI_VENDOR_ID_PHILIPS, + .device = PCI_DEVICE_ID_PHILIPS_SAA7133, .subvendor= 0x5168, .subdevice= 0x3502, /* whats the difference to 0x3306 ?*/ .driver_data =
Re: XC5000 improvements: call for testers!
Original Message Subject: Re: XC5000 improvements: call for testers! Date: Wed, 06 May 2009 19:09:23 -0500 From: John R. jo...@wowway.com To: Linux Media Mailing List linux-media@vger.kernel.org References: 412bdbff0905052114r7f481759r373fd0b814f4...@mail.gmail.com John R. wrote: Devin Heitmueller wrote: [snip] Unfortunately, current users are going to have to upgrade to the new firmware. However, this is a one time cost and I will work with the distros to get it bundled so that users won't have to do this in the future: http://www.devinheitmueller.com/xc5000/dvb-fe-xc5000-1.6.114.fw http://www.devinheitmueller.com/xc5000/README.xc5000 I downloaded the tip archive for xc5000-improvements-beta, compiled and installed it. I copied the firmware above into /lib/firmware (where the old one was). However, when the driver loads it still loads the old firmware. If this is a non-linux-media question then feel free to direct me where to look. My searching hasn't yet yielded anything yet. Thanks, John After some off-list pointers by Devin, I tracked this down to user error. I thought I was compiling tip for xc5000-improvements-beta but was not. This is now working and composite input video works well on my 950Q. I notice no difference from previous version (wouldn't really expect to based on changes). Thanks, John -- 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] FM1216ME_MK3 some changes
Hi Andy Sorry me delay. I discuss about it with our programmer. On Wed, 2009-04-29 at 20:12 +1000, Dmitri Belimov wrote: Hi, Am Dienstag, den 28.04.2009, 19:59 +1000 schrieb Dmitri Belimov: On Tue, 28 Apr 2009 15:18:32 -0300 Mauro Carvalho Chehab mche...@infradead.org wrote: On Mon, 27 Apr 2009 19:29:05 +1000 Dmitri Belimov d.beli...@gmail.com wrote: Hi All Step by step. This is patch for change only range of FM1216ME_MK3. Slow tunning is not a big problem. Dmitri, I'll mark those patches as RFC at patchwork until the end of those discussions. After that, please send it again into a new thread. You mark patch with TOP AGC not this. I think need discuss about FM1216ME_MK3 because I'll have a big patch for support control TOP AGC (sensitivity) of this tuner. It can be bad for compatible tuners. hmm, in Europe, that TOP AGC did not ever made much difference and it is an insmod option since ever. I can't tell for Sibiria and initially that tuner had no SECAM-DK support officially at all. There are no good/much_better tuners for FTA at all and never have been ;) Some examples, user success reports, to make it more easily to understand? I think it can only change some _very little_ under already worst conditions. This is my idea for RFC about TOP AGC: 1. Add gain variable to tuner structure. 2. Add V4L2_CID_GAIN control to saa7134 and disable this control. 3. Add workaround to simple_post_tune function for write sensitivity level to the tuner. 4. Enable V4L2_CID_GAIN control when module load if card is right. My expirience not so good, step 4 segfault the kernel. How to we can make it? Our windows end-user programm control the sensitivity of each TV channel and change when channel changed. What you think about it?? Dmitri, From my understanding the take over point is the signal strength level that you want the second stage (an IF demod chip like the TDA9887) to take over automatic gain control from the first stage (a tuner chip like the TUA6030). The objective is to set the TOP to achieve maximum gain in the first stage while avoiding clipping in the first stage. When the input signal level is smaller than the TOP, the first stage gain is at a maximum, and the second stage is performing automatic gain control internally. When the input signal level becomes greater than the TOP, the first stage gain needs to be reduced by an AGC, and the second stage gain remains constant. As I understand it, it would be best to set the first stage (TUA6030 or similar) to External AGC and set the take over point in the second stage (the TDA9887), if the pins between the chips are wired up properly inside the tuner. This should coordinate the AGC in both the first stage and second stage of the tuner, as the second stage will be providing the gain control to the first stage as needed when the signal reaches the TOP. http://www.comsec.com/usrp/microtune/NF_tutorial.pdf It allows you to achieve maximum gain in the first stage to minimize overall receiver noise figure, and avoid clipping the input signal in the first stage (TUA6030) with a proper TOP setting in the second stage (TDA9887). The TOP setting in the second stage needs to take into account IF SAW filter attenuation of course. Do the circuit board traces in the FM1216ME_MK3 support the TDA9887 controlling the gain of the first stage? (I've never opened an equivalent NTSC tuner assembly to take a look.) If not, then, if I understand things correctly, you need to set the first stage and second stage TOP settings so that they refer to about the same signal level before the IF SAW filter. You are right. My patch set AGC TOP level for RF signal in TUA6030. The TOP of TDA9887 control only IF signal. If set high level of AGC TOP for RF and RF signal is strengh, we can see white horizontal junk on TV image. For removing this junk need reduce AGC TOP RF for this channel. It can be only with Secam channels. With my best regards, Dmitry. I would think AGC TOP settings, for both stages of the tuner, are tuner-dependent and relatively constant once you figure out what they should be. Do you have a different understanding or insight? Regards, Andy If TV card is not touch V4L2_CTRL_FLAG_DISABLED in this control. The programm can't change AGC TOP. And write default value to AGC TOP like now. diff -r 43dbc8ebb5a2 linux/drivers/media/common/tuners/tuner-simple.c --- a/linux/drivers/media/common/tuners/tuner-simple.c Tue Jan 27 23:47:50 2009 -0200 +++ b/linux/drivers/media/common/tuners/tuner-simple.c Tue Apr 21 09:44:38 2009 +1000 @@ -116,6 +116,7 @@ u32 frequency; u32 bandwidth; + signed int gain; }; /*
Re: soc-camera: timing out during capture - Re: Testing latest mx3_camera.c
On Tue, 5 May 2009, Guennadi Liakhovetski wrote: On Tue, 5 May 2009, Agustin wrote: No, as there is no driver_match_device() in 2.6.29 nor in my patched version. How important is that? No, sorry, forget it, that's not your problem. Meanwhile I noticed that IRQ 176 is being triggered, then discarded as unhandled by ipu_idmac, who gives the message IRQ on active buffer on channel 7, active 0, ready 0, 0, current 0! below... Yes, and this is not good. If you look in drivers/dma/ipu/ipu_idmac.c idmac_interrupt() you'll see, that this message is printed when IDMAC produces an interrupt for a DMA buffer, but at the same time it says, that the buffer, that should have completed is still in use... I've seen a few of such inconsistencies, and up to now always managed to get rid of them in one or another way. But that should not be related to the conversion. Maybe your formats on the sensor and on the SoC do not match, verify that. Thanks for the tip but I am still out of luck. I enabled DEBUG in ipu_idmac.c just to see that frame start and end are happening more or less when they should: [...] camera 0-0: mx3_camera: Submitted cookie 2 DMA 0x8640 Got SOF IRQ 177 on Channel 7 Got EOF IRQ 178 on Channel 7 dma dma0chan7: ipu_idmac: IDMAC irq 176, buf 0 dma dma0chan7: ipu_idmac: IRQ on active buffer on channel 7, active 0, ready 0, 0, current 0! Select timeout. [...] I also configured everything to the simplest mode I can have: 8-bit bus, sample falling. So I am now looking at IDMAC, trying to guess what could be wrong, but I feel quite lost at the moment. I am starting to fear that I introduced some subtle bug while merging your stack into Sascha's... Where can I check mx3_camera.c, ipu_idmac.c, soc_camera.c prior to the subdev changes? I would like them to check that my edited patches lead to the same sources as the originals. Thanks regards, --Agustín. I am not sure where to look for the problem, so here is a debug dump in case you can point me in the right direction... r...@sixcam:~ insmod sixcam.ko sixcam_mod_init(): ok Sixcam TRIGGER on Sixcam board: ATA_CS0~MCU3_26 sixcam_i2c_probe(): ok camera 0-0: mx3_camera: Set SENS_CONF to f00, rate 19523897 sixcam_init(): initialized camera. camera 0-0: MX3 Camera driver attached to camera 0 sixcam_video_probe(): probed camera. mx3-camera mx3-camera.0: soc_camera: Allocated video_device c6080a00 sixcam_release(): ok camera 0-0: MX3 Camera driver detached from camera 0 r...@sixcam:~ capture --bpp 8 --size 1536x1024 mx3-camera.0: mx3_camera: requested bus width 8 bit: 0 mx3-camera.0: mx3_camera: requested bus width 15 bit: 0 mx3-camera.0: mx3_camera: requested bus width 10 bit: 0 camera 0-0: soc_camera: Found 0 supported formats. mx3-camera.0: mx3_camera: requested bus width 8 bit: 0 mx3-camera.0: mx3_camera: Providing format Monochrome 8 bit in pass-through mode mx3-camera.0: mx3_camera: requested bus width 15 bit: 0 mx3-camera.0: mx3_camera: Providing format Monochrome 16 bit in pass-through mode mx3-camera.0: mx3_camera: requested bus width 10 bit: 0 mx3-camera.0: mx3_camera: Providing format Sixcam 10-bit in pass-through mode camera 0-0: mx3_camera: Set SENS_CONF to f00, rate 19523897 sixcam_init(): initialized camera. camera 0-0: MX3 Camera driver attached to camera 0 camera 0-0: soc_camera: camera device open sixcam_set_fmt(): 640x480+0+0 sixcam_try_fmt(): icd-width=640 icd-height=480 fmt.pix.width=1536 fmt.pix.height=1024. -- fmt.pix.width=1536 fmt.pix.height=1024. ipu-core: ipu_idmac: timeout = 0 * 10ms ipu-core: ipu_idmac: init channel = 7 ipu-core: ipu_idmac: IDMAC_CONF 0x70, IC_CONF 0x0, IDMAC_CHA_EN 0x0, IDMAC_CHA_PRI 0x80, IDMAC_CHA_BUSY 0x0 ipu-core: ipu_idmac: BUF0_RDY 0x0, BUF1_RDY 0x0, CUR_BUF 0x0, DB_MODE 0x0, TASKS_STAT 0x3 dma dma0chan7: ipu_idmac: Found channel 0x7, irq 176 sixcam_set_fmt(): 1536x1024+0+0 camera 0-0: soc_camera: set width: 1536 height: 1024 mx3-camera.0: mx3_camera: requested bus width 8 bit: 0 mx3-camera.0: mx3_camera: Flags cam: 0x2695 host: 0xf0fd common: 0x2095 sixcam_set_bus_param(): 0x2095 mx3-camera.0: mx3_camera: Set SENS_CONF to 708 VIDIOC_S_FMT: width 1536, heightcamera 0-0: soc_camera: soc_camera_reqbufs: 1 1024, pixelformat = 'GREY' mx3-camera.0: videobuf_dma_contig: __videobuf_mmap_free camera 0-0: soc_camera: mmap called, vma=0xc4f886e0 mx3-camera.0: videobuf_dma_contig: __videobuf_mmap_mapper mx3-camera.0: videobuf_dma_contig: dma_alloc_coherent data is at addr c900 (size 1572864) mx3-camera.0: videobuf_dma_contig: mmap c4fafec0: q=c8b63004 40147000-402c7000 (18) pgoff 00084000 buf 0 mx3-camera.0: videobuf_dma_contig: vm_open c4fafec0
[PATCH v3] v4l: TI THS7303 video amplifier driver code
From: Chaithrika U S chaithr...@ti.com This patch adds driver for TI THS7303 video amplifier. This driver is implemented as a v4l2 sub device. Tested on TI DM646x EVM. This version has updates based on review comments by Mauro Chehab. Signed-off-by: Chaithrika U S chaithr...@ti.com Reviewed-by: Hans Verkuil hverk...@xs4all.nl Signed-off-by: Hans Verkuil hverk...@xs4all.nl --- drivers/media/video/Kconfig |9 +++ drivers/media/video/Makefile|1 + drivers/media/video/ths7303.c | 151 +++ include/media/v4l2-chip-ident.h |3 + 4 files changed, 164 insertions(+), 0 deletions(-) create mode 100644 drivers/media/video/ths7303.c diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig index 9d48da2..f99348c 100644 --- a/drivers/media/video/Kconfig +++ b/drivers/media/video/Kconfig @@ -440,6 +440,15 @@ config VIDEO_ADV7175 To compile this driver as a module, choose M here: the module will be called adv7175. +config VIDEO_THS7303 + tristate THS7303 Video Amplifier + depends on I2C + help + Support for TI THS7303 video amplifier + + To compile this driver as a module, choose M here: the + module will be called ths7303. + comment Video improvement chips config VIDEO_UPD64031A diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile index 7aefac6..352dd6d 100644 --- a/drivers/media/video/Makefile +++ b/drivers/media/video/Makefile @@ -54,6 +54,7 @@ obj-$(CONFIG_VIDEO_BT819) += bt819.o obj-$(CONFIG_VIDEO_BT856) += bt856.o obj-$(CONFIG_VIDEO_BT866) += bt866.o obj-$(CONFIG_VIDEO_KS0127) += ks0127.o +obj-$(CONFIG_VIDEO_THS7303) += ths7303.o obj-$(CONFIG_VIDEO_ZORAN) += zoran/ diff --git a/drivers/media/video/ths7303.c b/drivers/media/video/ths7303.c new file mode 100644 index 000..21781f8 --- /dev/null +++ b/drivers/media/video/ths7303.c @@ -0,0 +1,151 @@ +/* + * ths7303- THS7303 Video Amplifier driver + * + * Copyright (C) 2009 Texas Instruments Incorporated - http://www.ti.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 version 2. + * + * This program is distributed .as is. WITHOUT ANY WARRANTY of any + * kind, whether express or implied; without even the implied warranty + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#include linux/kernel.h +#include linux/init.h +#include linux/ctype.h +#include linux/i2c.h +#include linux/device.h +#include linux/delay.h +#include linux/module.h +#include linux/uaccess.h +#include linux/videodev2.h + +#include media/v4l2-device.h +#include media/v4l2-subdev.h +#include media/v4l2-chip-ident.h + +MODULE_DESCRIPTION(TI THS7303 video amplifier driver); +MODULE_AUTHOR(Chaithrika U S); +MODULE_LICENSE(GPL); + +static int debug; +module_param(debug, int, 0644); +MODULE_PARM_DESC(debug, Debug level 0-1); + +/* following function is used to set ths7303 */ +static int ths7303_setvalue(struct v4l2_subdev *sd, v4l2_std_id std) +{ + int err = 0; + u8 val; + struct i2c_client *client; + + client = v4l2_get_subdevdata(sd); + + if (std (V4L2_STD_ALL ~V4L2_STD_SECAM)) { + val = 0x02; + v4l2_dbg(1, debug, sd, setting value for SDTV format\n); + } else { + val = 0x00; + v4l2_dbg(1, debug, sd, disabling all channels\n); + } + + err |= i2c_smbus_write_byte_data(client, 0x01, val); + err |= i2c_smbus_write_byte_data(client, 0x02, val); + err |= i2c_smbus_write_byte_data(client, 0x03, val); + + if (err) + v4l2_err(sd, write failed\n); + + return err; +} + +static int ths7303_s_std_output(struct v4l2_subdev *sd, v4l2_std_id norm) +{ + return ths7303_setvalue(sd, norm); +} + +static int ths7303_g_chip_ident(struct v4l2_subdev *sd, + struct v4l2_dbg_chip_ident *chip) +{ + struct i2c_client *client = v4l2_get_subdevdata(sd); + + return v4l2_chip_ident_i2c_client(client, chip, V4L2_IDENT_THS7303, 0); +} + +static const struct v4l2_subdev_video_ops ths7303_video_ops = { + .s_std_output = ths7303_s_std_output, +}; + +static const struct v4l2_subdev_core_ops ths7303_core_ops = { + .g_chip_ident = ths7303_g_chip_ident, +}; + +static const struct v4l2_subdev_ops ths7303_ops = { + .core = ths7303_core_ops, + .video = ths7303_video_ops, +}; + +static int ths7303_probe(struct i2c_client *client, + const struct i2c_device_id *id) +{ + struct v4l2_subdev *sd; + v4l2_std_id std_id = V4L2_STD_NTSC; + + if (!i2c_check_functionality(client-adapter, I2C_FUNC_SMBUS_BYTE_DATA)) + return -ENODEV; + + v4l_info(client, chip found @ 0x%x (%s)\n, +
[PATCH v4] v4l: Analog Devices ADV7343 video encoder driver
From: Chaithrika U S chaithr...@ti.com Add ADV7343 I2C based video encoder driver. This follows the v4l2-subdev framework. This driver has been tested on TI DM646x EVM. It has been tested for Composite and Component outputs. Updates as per review by Mauro Chehab, added support for more standards supported by the encoder. Also adding the missed out signed-offs.Tested only NTSC and PAL standards. Signed-off-by: Manjunath Hadli m...@ti.com Signed-off-by: Brijesh Jadav brijes...@ti.com Signed-off-by: Chaithrika U S chaithr...@ti.com [hverk...@xs4all.nl: s_routing API changed, updated driver to use new API] Signed-off-by: Hans Verkuil hverk...@xs4all.nl --- drivers/media/video/Kconfig|9 + drivers/media/video/Makefile |1 + drivers/media/video/adv7343.c | 534 drivers/media/video/adv7343_regs.h | 185 + include/media/adv7343.h| 23 ++ include/media/v4l2-chip-ident.h|3 + 6 files changed, 755 insertions(+), 0 deletions(-) create mode 100644 drivers/media/video/adv7343.c create mode 100644 drivers/media/video/adv7343_regs.h create mode 100644 include/media/adv7343.h diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig index f99348c..7a1f43d 100644 --- a/drivers/media/video/Kconfig +++ b/drivers/media/video/Kconfig @@ -449,6 +449,15 @@ config VIDEO_THS7303 To compile this driver as a module, choose M here: the module will be called ths7303. +config VIDEO_ADV7343 + tristate ADV7343 video encoder + depends on I2C + help + Support for Analog Devices I2C bus based ADV7343 encoder. + + To compile this driver as a module, choose M here: the + module will be called adv7343. + comment Video improvement chips config VIDEO_UPD64031A diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile index 352dd6d..f7d9a4c 100644 --- a/drivers/media/video/Makefile +++ b/drivers/media/video/Makefile @@ -49,6 +49,7 @@ obj-$(CONFIG_VIDEO_SAA7185) += saa7185.o obj-$(CONFIG_VIDEO_SAA7191) += saa7191.o obj-$(CONFIG_VIDEO_ADV7170) += adv7170.o obj-$(CONFIG_VIDEO_ADV7175) += adv7175.o +obj-$(CONFIG_VIDEO_ADV7343) += adv7343.o obj-$(CONFIG_VIDEO_VPX3220) += vpx3220.o obj-$(CONFIG_VIDEO_BT819) += bt819.o obj-$(CONFIG_VIDEO_BT856) += bt856.o diff --git a/drivers/media/video/adv7343.c b/drivers/media/video/adv7343.c new file mode 100644 index 000..30f5caf --- /dev/null +++ b/drivers/media/video/adv7343.c @@ -0,0 +1,534 @@ +/* + * adv7343 - ADV7343 Video Encoder Driver + * + * The encoder hardware does not support SECAM. + * + * Copyright (C) 2009 Texas Instruments Incorporated - http://www.ti.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 version 2. + * + * This program is distributed .as is. WITHOUT ANY WARRANTY of any + * kind, whether express or implied; without even the implied warranty + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#include linux/kernel.h +#include linux/init.h +#include linux/ctype.h +#include linux/i2c.h +#include linux/device.h +#include linux/delay.h +#include linux/module.h +#include linux/videodev2.h +#include linux/uaccess.h +#include linux/version.h + +#include media/adv7343.h +#include media/v4l2-device.h +#include media/v4l2-chip-ident.h + +#include adv7343_regs.h + +MODULE_DESCRIPTION(ADV7343 video encoder driver); +MODULE_LICENSE(GPL); + +static int debug; +module_param(debug, int, 0644); +MODULE_PARM_DESC(debug, Debug level 0-1); + +struct adv7343_state { + struct v4l2_subdev sd; + u8 reg00; + u8 reg01; + u8 reg02; + u8 reg35; + u8 reg80; + u8 reg82; + int bright; + int hue; + int gain; + u32 output; + v4l2_std_id std; +}; + +static inline struct adv7343_state *to_state(struct v4l2_subdev *sd) +{ + return container_of(sd, struct adv7343_state, sd); +} + +static inline int adv7343_write(struct v4l2_subdev *sd, u8 reg, u8 value) +{ + struct i2c_client *client = v4l2_get_subdevdata(sd); + + return i2c_smbus_write_byte_data(client, reg, value); +} + +static const u8 adv7343_init_reg_val[] = { + ADV7343_SOFT_RESET, ADV7343_SOFT_RESET_DEFAULT, + ADV7343_POWER_MODE_REG, ADV7343_POWER_MODE_REG_DEFAULT, + + ADV7343_HD_MODE_REG1, ADV7343_HD_MODE_REG1_DEFAULT, + ADV7343_HD_MODE_REG2, ADV7343_HD_MODE_REG2_DEFAULT, + ADV7343_HD_MODE_REG3, ADV7343_HD_MODE_REG3_DEFAULT, + ADV7343_HD_MODE_REG4, ADV7343_HD_MODE_REG4_DEFAULT, + ADV7343_HD_MODE_REG5, ADV7343_HD_MODE_REG5_DEFAULT, + ADV7343_HD_MODE_REG6, ADV7343_HD_MODE_REG6_DEFAULT, + ADV7343_HD_MODE_REG7, ADV7343_HD_MODE_REG7_DEFAULT, + + ADV7343_SD_MODE_REG1, ADV7343_SD_MODE_REG1_DEFAULT, +
Solved? - Re: soc-camera: timing out during capture - Re: Testing latest mx3_camera.c
Holy cow... On Tue, 5 May 2009, Agustin wrote: On Tue, 5 May 2009, Guennadi Liakhovetski wrote: On Tue, 5 May 2009, Agustin wrote: No, as there is no driver_match_device() in 2.6.29 nor in my patched version. How important is that? No, sorry, forget it, that's not your problem. Meanwhile I noticed that IRQ 176 is being triggered, then discarded as unhandled by ipu_idmac, who gives the message IRQ on active buffer on channel 7, active 0, ready 0, 0, current 0! below... Yes, and this is not good. If you look in drivers/dma/ipu/ipu_idmac.c idmac_interrupt() you'll see, that this message is printed when IDMAC produces an interrupt for a DMA buffer, but at the same time it says, that the buffer, that should have completed is still in use... I've seen a few of such inconsistencies, and up to now always managed to get rid of them in one or another way. But that should not be related to the conversion. Maybe your formats on the sensor and on the SoC do not match, verify that. Thanks for the tip but I am still out of luck. I enabled DEBUG in ipu_idmac.c just to see that frame start and end are happening more or less when they should: [...] camera 0-0: mx3_camera: Submitted cookie 2 DMA 0x8640 Got SOF IRQ 177 on Channel 7 Got EOF IRQ 178 on Channel 7 dma dma0chan7: ipu_idmac: IDMAC irq 176, buf 0 dma dma0chan7: ipu_idmac: IRQ on active buffer on channel 7, active 0, ready 0, 0, current 0! Select timeout. [...] I also configured everything to the simplest mode I can have: 8-bit bus, sample falling. So I am now looking at IDMAC, trying to guess what could be wrong... [snip] After checking out every single bit in CSI and IDMAC to be correct according to reference and the same I had in the previous/working version... I thought about the fact that I was only queuing one buffer, and that this might be a corner case as sample code uses a lot of them. And that in the older code that funny things could happen in the handler if we ran out of buffers, though they didn't happen. So I have queued an extra buffer and voila, got it working. So thanks again! However, this could be a bug in ipu_idmac (or some other point), as using a single buffer is very plausible, specially when grabbing huge stills. --Agustín. [snip!] -- 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: Solved? - Re: soc-camera: timing out during capture - Re: Testing latest mx3_camera.c
On Thu, 7 May 2009, Agustin Ferrin Pozuelo wrote: Holy cow... mu-u-u-u-u-u?:-) After checking out every single bit in CSI and IDMAC to be correct according to reference and the same I had in the previous/working version... I thought about the fact that I was only queuing one buffer, and that this might be a corner case as sample code uses a lot of them. And that in the older code that funny things could happen in the handler if we ran out of buffers, though they didn't happen. So I have queued an extra buffer and voila, got it working. So thanks again! However, this could be a bug in ipu_idmac (or some other point), as using a single buffer is very plausible, specially when grabbing huge stills. Great, thanks for testing and debugging! Ok, so, I will have to test this case some time... Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL] soc-camera: one commit as v4l2-dev preparation
Hi Mauro, Please pull from http://linuxtv.org/hg/~gliakhovetski/v4l-dvb for the following changeset: 01/01: soc-camera: prepare for the platform driver conversion http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=0a8bf9a89ae4 drivers/media/video/soc_camera.c | 73 +++ include/media/soc_camera.h |5 ++ 2 files changed, 72 insertions(+), 6 deletions(-) I posted this patch about 2 weeks ago to the list for review, it creates basis for gradual conversion of all affected platforms to the intermediate platform driver stage of soc-camera, on its way to v4l2-subdev API. With this patch we shall be able then to convert all platforms one by one to their final form, which they shall then be able to preserve also when the v4l2-subdev API is in place. So, it would help, if you could push this change ASAP to linux-next, so we can start converting single platforms. Thanks, Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GSPCA] Driver Development for Speed Link VAD Laplace
Hi, I hope I'm on the correct list for gspca driver development. By searching I came up to the old driver page and the gspca project page http://linuxtv.org/hg/~jfrancois/gspca/ I recently bought a nice new webcam without Linux support (that was not very important for me as I have a working webcam already but this one has several useful features especially at work where I often don't or can't use Linux unfortunately). The webcam is called VAD (Vicious and Divine) Laplace from the manufacturer Speed Link. So I thought helping to get a driver for this cam. What I can offer is USB sniffing on a certain OS (no MAC drivers available too so there is not much choice). I already know that the cam is not UVC compliant. I have searched for some more hardware information than from the vendor available but in vain (though the cam is about 1 year old already). I know that especially the video format the webcam delivers would be important to know for driver development. If there are any (freeware) tools available except those USB sniffers to find out any more hardware details please let me know, so I can help with the driver. The basic hardware SPECS are below and I attached USB HW information from /proc/bus/usb/devices (with lsusb). IDs are idVendor=1ae7, idProduct=9003 (9004 is the other variant of the webcam in black). - 2 MP Photo, 1.3 MP Video resolution, USB 2.0 (1.1 supported) - 3x digital zoom, Flash, Night illumination (3 hardware buttons) - Noise-suppressing microphone, Mute button - Z-fold positioning, 0.6m cable CAM, 1.4m extra USB extension cable - max. resolution 1280x960/15fps, 640x480/30fps, photo 1600x1200 Sorry, it's not really much I found out so far. But I hope that I can be of further help for driver work. I intend to do some further tests. I think it's most appropriate to post results on the linuxtv wiki, so I created a new page there: http://linuxtv.org/wiki/index.php/VAD_Laplace Regards, Reinhard Katzmann -- Software-Engineer, Developer of User Interfaces Project: Canorus - the next generation music score editor - http://canorus.berlios.de GnuPG Public Key available on request [sua...@localhost]$ sudo lsusb -v Bus 006 Device 008: ID 1ae7:9003 Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x1ae7 idProduct 0x9003 bcdDevice2.03 iManufacturer 0 iProduct0 iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 126 bNumInterfaces 3 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 500mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 1 Audio bInterfaceSubClass 1 Control Device bInterfaceProtocol 0 iInterface 0 AudioControl Interface Descriptor: bLength 9 bDescriptorType36 bDescriptorSubtype 1 (HEADER) bcdADC 1.00 wTotalLength 40 bInCollection 1 baInterfaceNr( 0) 1 AudioControl Interface Descriptor: bLength12 bDescriptorType36 bDescriptorSubtype 2 (INPUT_TERMINAL) bTerminalID 1 wTerminalType 0x0201 Microphone bAssocTerminal 0 bNrChannels 2 wChannelConfig 0x iChannelNames 0 iTerminal 0 AudioControl Interface Descriptor: bLength10 bDescriptorType36 bDescriptorSubtype 6 (FEATURE_UNIT) bUnitID 2 bSourceID 1 bControlSize1 bmaControls( 0) 0x03 Mute Volume bmaControls( 1) 0x00 bmaControls( 2) 0x00 iFeature0 AudioControl Interface Descriptor: bLength 9 bDescriptorType36 bDescriptorSubtype 3 (OUTPUT_TERMINAL) bTerminalID 3 wTerminalType 0x0101 USB Streaming bAssocTerminal 0 bSourceID 2 iTerminal 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber1 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 1 Audio
[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:Thu May 7 19:00:03 CEST 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 11696:fe524e0a6412 gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.22.19-armv5: OK linux-2.6.23.12-armv5: OK linux-2.6.24.7-armv5: OK linux-2.6.25.11-armv5: OK linux-2.6.26-armv5: OK linux-2.6.27-armv5: OK linux-2.6.28-armv5: OK linux-2.6.29.1-armv5: OK linux-2.6.30-rc4-armv5: OK linux-2.6.27-armv5-ixp: WARNINGS linux-2.6.28-armv5-ixp: WARNINGS linux-2.6.29.1-armv5-ixp: WARNINGS linux-2.6.30-rc4-armv5-ixp: WARNINGS linux-2.6.28-armv5-omap2: WARNINGS linux-2.6.29.1-armv5-omap2: WARNINGS linux-2.6.30-rc4-armv5-omap2: WARNINGS linux-2.6.22.19-i686: OK linux-2.6.23.12-i686: WARNINGS linux-2.6.24.7-i686: WARNINGS linux-2.6.25.11-i686: WARNINGS linux-2.6.26-i686: WARNINGS linux-2.6.27-i686: WARNINGS linux-2.6.28-i686: WARNINGS linux-2.6.29.1-i686: WARNINGS linux-2.6.30-rc4-i686: WARNINGS linux-2.6.23.12-m32r: OK linux-2.6.24.7-m32r: OK linux-2.6.25.11-m32r: OK linux-2.6.26-m32r: OK linux-2.6.27-m32r: OK linux-2.6.28-m32r: OK linux-2.6.29.1-m32r: OK linux-2.6.30-rc4-m32r: OK linux-2.6.22.19-mips: ERRORS linux-2.6.26-mips: ERRORS linux-2.6.27-mips: ERRORS linux-2.6.28-mips: ERRORS linux-2.6.29.1-mips: ERRORS linux-2.6.30-rc4-mips: ERRORS linux-2.6.27-powerpc64: WARNINGS linux-2.6.28-powerpc64: WARNINGS linux-2.6.29.1-powerpc64: WARNINGS linux-2.6.30-rc4-powerpc64: WARNINGS linux-2.6.22.19-x86_64: OK linux-2.6.23.12-x86_64: OK linux-2.6.24.7-x86_64: OK linux-2.6.25.11-x86_64: OK linux-2.6.26-x86_64: OK linux-2.6.27-x86_64: OK linux-2.6.28-x86_64: OK linux-2.6.29.1-x86_64: OK linux-2.6.30-rc4-x86_64: WARNINGS sparse (linux-2.6.29.1): OK sparse (linux-2.6.30-rc4): OK linux-2.6.16.61-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: ERRORS linux-2.6.19.5-i686: WARNINGS linux-2.6.20.21-i686: ERRORS linux-2.6.21.7-i686: ERRORS linux-2.6.16.61-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: ERRORS linux-2.6.19.5-x86_64: WARNINGS 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/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.tar.bz2 The V4L2 specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/v4l2.html The DVB API specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/dvbapi.pdf -- 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: [REVIEW] v4l2 loopback
On Thu, 7 May 2009 02:54:00 +0300 Vasily vas...@gmail.com wrote: This patch introduces v4l2 loopback module Hi Vasily, next time it would be useful to summarize what you changed from the previous version, and put a revision number in the Subject, like [PATCH v2] [PATCH v3], etc. Also, the patch has some style problems reported by checkpatch.pl, please fix those. Even if the driver wouldn't go mainline you do want to follow the style guidelines. And some more typos I spotted, see inlined comments. I am not a native English speaker either, so I learned to use spell checkers even in source code comments :) Anyhow, finally I tested the driver, and I have only a question as a user: couldn't it be possible to make a default input enabled by default? This way, if a writer knows the format to use it doesn't have to setup the device format on its own, and can treat the device as a normal file. Thanks, Antonio From: Vasily Levin vas...@gmail.com This is v4l2 loopback driver which can be used to make available any userspace video as v4l2 device. Initialy it was written to make videoeffects available Typo: Initialy - Initially to Skype, but in fact it have many more uses. Priority: normal Signed-off-by: Vasily Levin vas...@gmail.com diff -uprN v4l-dvb.orig/linux/drivers/media/video/Kconfig v4l-dvb.my/linux/drivers/media/video/Kconfig --- v4l-dvb.orig/linux/drivers/media/video/Kconfig2009-04-25 04:41:20.0 +0300 +++ v4l-dvb.my/linux/drivers/media/video/Kconfig 2009-05-07 01:49:38.0 +0300 @@ -479,6 +479,17 @@ config VIDEO_VIVI Say Y here if you want to test video apps or debug V4L devices. In doubt, say N. +config VIDEO_V4L2_LOOPBACK + tristate v4l2 loopback driver + depends on VIDEO_V4L2 VIDEO_DEV + help + Say Y if you want to use v4l2 loopback driver. + Looback driver allows it's user to present any userspace typo: it's - its + video as a v4l2 device that can be handy for tesring purpose, typo: tesring - testing + or for fixing bugs like upside down image, or for adding + nice effects to videochats + This driver can be compiled as a module, called v4l2loopback. + source drivers/media/video/bt8xx/Kconfig config VIDEO_PMS diff -uprN v4l-dvb.orig/linux/drivers/media/video/Makefile v4l-dvb.my/linux/drivers/media/video/Makefile --- v4l-dvb.orig/linux/drivers/media/video/Makefile 2009-05-07 01:31:32.0 +0300 +++ v4l-dvb.my/linux/drivers/media/video/Makefile 2009-05-07 01:50:11.0 +0300 @@ -132,6 +132,7 @@ obj-$(CONFIG_VIDEO_IVTV) += ivtv/ obj-$(CONFIG_VIDEO_CX18) += cx18/ obj-$(CONFIG_VIDEO_VIVI) += vivi.o +obj-$(CONFIG_VIDEO_V4L2_LOOPBACK) += v4l2loopback.o obj-$(CONFIG_VIDEO_CX23885) += cx23885/ obj-$(CONFIG_VIDEO_OMAP2)+= omap2cam.o diff -uprN v4l-dvb.orig/linux/drivers/media/video/v4l2loopback.c v4l-dvb.my/linux/drivers/media/video/v4l2loopback.c --- v4l-dvb.orig/linux/drivers/media/video/v4l2loopback.c 1970-01-01 03:00:00.0 +0300 +++ v4l-dvb.my/linux/drivers/media/video/v4l2loopback.c 2009-05-07 02:30:08.0 +0300 @@ -0,0 +1,775 @@ +/* + * v4l2loopback.c -- video 4 linux loopback driver + * + * Copyright (C) 2005-2009 + * Vasily Levin (vas...@gmail.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/version.h +#include linux/vmalloc.h +#include linux/mm.h +#include linux/time.h +#include linux/module.h +#include media/v4l2-ioctl.h +#include linux/videodev2.h +#include media/v4l2-common.h + Usually the includes with the same prefix come all near one another, you could move #include linux/videodev2.h one line up. +#define YAVLD_STREAMING + +MODULE_DESCRIPTION(V4L2 loopback video device); +MODULE_VERSION(0.1.1); +MODULE_AUTHOR(Vasily Levin); +MODULE_LICENSE(GPL); + +/* module structures */ +/* TODO(vasaka) use typenames which are common to kernel, but first find out if + * it is needed */ +/* struct keeping state and settings of loopback device */ +struct v4l2_loopback_device { + struct video_device *vdev; + /* pixel and stream format */ + struct v4l2_pix_format pix_format; + struct v4l2_captureparm capture_param; + /* buffers stuff */ + u8 *image; /* pointer to actual buffers data */ + int buffers_number; /* should not be big, 4 is a good choice */ + struct v4l2_buffer *buffers;/* inner driver buffers */ + int write_position; /* number of last written frame + 1 */ + long buffer_size; + /* sync stuff */ + atomic_t open_count; + int ready_for_capture;/* set to true when at least one writer opened + *
Re: [REVIEW] v4l2 loopback
On Thu, May 7, 2009 at 9:28 PM, Antonio Ospite osp...@studenti.unina.it wrote: On Thu, 7 May 2009 02:54:00 +0300 Vasily vas...@gmail.com wrote: This patch introduces v4l2 loopback module Hi Vasily, next time it would be useful to summarize what you changed from the previous version, and put a revision number in the Subject, like [PATCH v2] [PATCH v3], etc. ok Also, the patch has some style problems reported by checkpatch.pl, please fix those. Even if the driver wouldn't go mainline you do want to follow the style guidelines. I have checked it with make commit in v4l-dvb tree, and it did not complain, I'll look into that. And some more typos I spotted, see inlined comments. I am not a native English speaker either, so I learned to use spell checkers even in source code comments :) Anyhow, finally I tested the driver, and I have only a question as a user: couldn't it be possible to make a default input enabled by default? This way, if a writer knows the format to use it doesn't have to setup the device format on its own, and can treat the device as a normal file. I think it is a good improvement, but what format should be default? and even if I'll do so user will have to make syscalls to change format. Also please exclude scopic addres from recipients when you answering this message, I added this addres by mistake Thanks, Vasily Thanks, Antonio From: Vasily Levin vas...@gmail.com This is v4l2 loopback driver which can be used to make available any userspace video as v4l2 device. Initialy it was written to make videoeffects available Typo: Initialy - Initially to Skype, but in fact it have many more uses. Priority: normal Signed-off-by: Vasily Levin vas...@gmail.com diff -uprN v4l-dvb.orig/linux/drivers/media/video/Kconfig v4l-dvb.my/linux/drivers/media/video/Kconfig --- v4l-dvb.orig/linux/drivers/media/video/Kconfig 2009-04-25 04:41:20.0 +0300 +++ v4l-dvb.my/linux/drivers/media/video/Kconfig 2009-05-07 01:49:38.0 +0300 @@ -479,6 +479,17 @@ config VIDEO_VIVI Say Y here if you want to test video apps or debug V4L devices. In doubt, say N. +config VIDEO_V4L2_LOOPBACK + tristate v4l2 loopback driver + depends on VIDEO_V4L2 VIDEO_DEV + help + Say Y if you want to use v4l2 loopback driver. + Looback driver allows it's user to present any userspace typo: it's - its + video as a v4l2 device that can be handy for tesring purpose, typo: tesring - testing + or for fixing bugs like upside down image, or for adding + nice effects to videochats + This driver can be compiled as a module, called v4l2loopback. + source drivers/media/video/bt8xx/Kconfig config VIDEO_PMS diff -uprN v4l-dvb.orig/linux/drivers/media/video/Makefile v4l-dvb.my/linux/drivers/media/video/Makefile --- v4l-dvb.orig/linux/drivers/media/video/Makefile 2009-05-07 01:31:32.0 +0300 +++ v4l-dvb.my/linux/drivers/media/video/Makefile 2009-05-07 01:50:11.0 +0300 @@ -132,6 +132,7 @@ obj-$(CONFIG_VIDEO_IVTV) += ivtv/ obj-$(CONFIG_VIDEO_CX18) += cx18/ obj-$(CONFIG_VIDEO_VIVI) += vivi.o +obj-$(CONFIG_VIDEO_V4L2_LOOPBACK) += v4l2loopback.o obj-$(CONFIG_VIDEO_CX23885) += cx23885/ obj-$(CONFIG_VIDEO_OMAP2) += omap2cam.o diff -uprN v4l-dvb.orig/linux/drivers/media/video/v4l2loopback.c v4l-dvb.my/linux/drivers/media/video/v4l2loopback.c --- v4l-dvb.orig/linux/drivers/media/video/v4l2loopback.c 1970-01-01 03:00:00.0 +0300 +++ v4l-dvb.my/linux/drivers/media/video/v4l2loopback.c 2009-05-07 02:30:08.0 +0300 @@ -0,0 +1,775 @@ +/* + * v4l2loopback.c -- video 4 linux loopback driver + * + * Copyright (C) 2005-2009 + * Vasily Levin (vas...@gmail.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/version.h +#include linux/vmalloc.h +#include linux/mm.h +#include linux/time.h +#include linux/module.h +#include media/v4l2-ioctl.h +#include linux/videodev2.h +#include media/v4l2-common.h + Usually the includes with the same prefix come all near one another, you could move #include linux/videodev2.h one line up. +#define YAVLD_STREAMING + +MODULE_DESCRIPTION(V4L2 loopback video device); +MODULE_VERSION(0.1.1); +MODULE_AUTHOR(Vasily Levin); +MODULE_LICENSE(GPL); + +/* module structures */ +/* TODO(vasaka) use typenames which are common to kernel, but first find out if + * it is needed */ +/* struct keeping state and settings of loopback device */ +struct v4l2_loopback_device { + struct video_device *vdev; + /* pixel and stream format */ + struct v4l2_pix_format pix_format; + struct v4l2_captureparm capture_param; + /*
Re: [GSPCA] Driver Development for Speed Link VAD Laplace
I have searched for some more hardware information than from the vendor available but in vain (though the cam is about 1 year old already). I know that especially the video format the webcam delivers would be important to know for driver development. If there are any (freeware) tools available except those USB sniffers to find out any more hardware details please let me know, so I can help with the driver. Hi, If possible, you can open the case and inspect what chips that are inside. That should give you a head start. Best regards, Erik -- 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
Scoping the effort to add a media controller )Re: [ivtv-users] Delay loading v4l-cx25840.fw)
On Sat, 2009-05-02 at 17:49 +0200, Hans Verkuil wrote: On Friday 01 May 2009 04:21:36 Andy Walls wrote: On Wed, 2009-04-29 at 21:18 -0400, Andy Walls wrote: On Wed, 2009-04-29 at 13:33 +0200, Hans Verkuil wrote: Hans, it sounds like your media_controller device node idea is really what we need to get implemented here for user space to do queires on hardware. This problem obviously affects more than the ivtv driver so I'd recommend against an ivtv band-aid. We'd also want to coordinate with the hald folks and other user space app/plumbing developers, as this likely affects a few v4l2 drivers. It sounds like an LPC agenda item to me... Regards, Andy I agree. A media controller device is exactly what we need. It's ideal for applications and daemons like hald. Now all I need is the time to work on it and I don't see that happening anytime soon. :-( Any volunteers? I have a general idea of how it should be implemented, but it needs a fair amount of research as well. I recall a design document or brief: can you provide a pointer to them? What is the research that you think needs to be done? Regards, Andy 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: CX24123 no FE_HAS_LOCK/tuning failed.
Thanks for the reply John, he Hauppauge WinTV Nova-S-Plus has had problems with hi-band transponders since the 2.6.20 kernel or thereabouts. The Optus D1 transponders all seem to be hi-band. See the thread at: http://bugzilla.kernel.org/show_bug.cgi?id=9476 where I outlined a fix which works OK for this card, but is not robust enough for general use. I've added this to the latest version of ... r...@mythbox:/usr/src/v4l-dvb# hg diff linux/drivers/media/dvb/frontends/isl6421.c diff -r fe524e0a6412 linux/drivers/media/dvb/frontends/isl6421.c --- a/linux/drivers/media/dvb/frontends/isl6421.cTue May 05 08:50:54 2009 -0300 +++ b/linux/drivers/media/dvb/frontends/isl6421.cFri May 08 11:30:07 2009 +1200 @@ -99,6 +99,33 @@ fe-sec_priv = NULL; } +static int isl6421_set_tone(struct dvb_frontend* fe, fe_sec_tone_mode_t tone) +{ +struct isl6421 *isl6421 = (struct isl6421 *) fe-sec_priv; +struct i2c_msg msg = {.addr = isl6421-i2c_addr, .flags = 0, +.buf = isl6421-config, +.len = sizeof(isl6421-config) }; + +switch (tone) { +case SEC_TONE_ON: +isl6421-config |= ISL6421_ENT1; +printk(KERN_INFO %s(SEC_TONE_ON), __func__); +break; +case SEC_TONE_OFF: +isl6421-config = ~ISL6421_ENT1; +printk(KERN_INFO %s(SEC_TONE_OFF), __func__); +break; +default: +printk(KERN_ERR %s: Invalid, tone=%d\n, __func__, tone); +return -EINVAL; +} + +isl6421-config |= isl6421-override_or; +isl6421-config = isl6421-override_and; + +return (i2c_transfer(isl6421-i2c, msg, 1) == 1) ? 0 : -EIO; +} + struct dvb_frontend *isl6421_attach(struct dvb_frontend *fe, struct i2c_adapter *i2c, u8 i2c_addr, u8 override_set, u8 override_clear) { @@ -130,12 +157,14 @@ /* override frontend ops */ fe-ops.set_voltage = isl6421_set_voltage; +fe-ops.set_tone = isl6421_set_tone; fe-ops.enable_high_lnb_voltage = isl6421_enable_high_lnb_voltage; return fe; } EXPORT_SYMBOL(isl6421_attach); + MODULE_DESCRIPTION(Driver for lnb supply and control ic isl6421); MODULE_AUTHOR(Andrew de Quincey Oliver Endriss); MODULE_LICENSE(GPL); *Unfortunately it didn't seem to help* r...@mythbox:/usr/src/v4l-dvb# !scan scan -vvv -a 0 ~tv/OptusD1 scanning /home/tv/OptusD1 using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' initial transponder 12456000 H 2250 3 initial transponder 12483000 H 2250 3 tune to: 12456:h:0:22500 DiSEqC: switch pos 0, 18V, hiband (index 3) diseqc_send_msg:59: DiSEqC: e0 10 38 f3 00 00 tuning status == 0x01 tuning status == 0x01 May 8 11:31:22 mythbox kernel: [ 3205.651828] cx88[0]/2-dvb: cx8802_dvb_advise_acquire May 8 11:31:22 mythbox kernel: [ 3205.652323] CX24123: cx24123_initfe: init frontend May 8 11:31:22 mythbox kernel: [ 3205.672802] isl6421_set_tone(SEC_TONE_OFF)7CX24123: cx24123_send_diseqc_msg: May 8 11:31:22 mythbox kernel: [ 3205.836714] CX24123: cx24123_diseqc_send_burst: May 8 11:31:22 mythbox kernel: [ 3205.952866] isl6421_set_tone(SEC_TONE_ON)7CX24123: cx24123_set_frontend: May 8 11:31:22 mythbox kernel: [ 3206.004824] CX24123: cx24123_set_inversion: inversion auto May 8 11:31:22 mythbox kernel: [ 3206.007124] CX24123: cx24123_set_fec: set FEC to 3/4 May 8 11:31:22 mythbox kernel: [ 3206.011208] CX24123: cx24123_set_symbolrate: srate=2250, ratio=0x0038f7b8, sample_rate=50555000 sample_gain=1 May 8 11:31:22 mythbox kernel: [ 3206.011213] CX24123: cx24123_pll_tune: frequency=1856000 May 8 11:31:22 mythbox kernel: [ 3206.011215] CX24123: cx24123_pll_writereg: pll writereg called, data=0x00100e3f May 8 11:31:22 mythbox kernel: [ 3206.017467] CX24123: cx24123_pll_writereg: pll writereg called, data=0x000a0180 May 8 11:31:22 mythbox kernel: [ 3206.023693] CX24123: cx24123_pll_writereg: pll writereg called, data=0x0220 May 8 11:31:22 mythbox kernel: [ 3206.030443] CX24123: cx24123_pll_writereg: pll writereg called, data=0x001f472b May 8 11:31:22 mythbox kernel: [ 3206.038349] CX24123: cx24123_pll_tune: pll tune VCA=1052223, band=544, pll=2049835 tuning status == 0x01 tuning status == 0x01 tuning status == 0x01 tuning status == 0x01 tuning status == 0x01 tuning status == 0x01 tuning status == 0x01 tuning status == 0x01 WARNING: tuning failed!!! tune to: 12456:h:0:22500 (tuning failed) DiSEqC: switch pos 0, 18V, hiband (index 3) diseqc_send_msg:59: DiSEqC: e0 10 38 f3 00 00 May 8 11:31:24 mythbox kernel: [ 3208.017792] isl6421_set_tone(SEC_TONE_OFF)7CX24123: cx24123_send_diseqc_msg: May 8 11:31:25 mythbox kernel: [ 3208.195719] CX24123: cx24123_diseqc_send_burst: May 8 11:31:25 mythbox kernel: [ 3208.312913] isl6421_set_tone(SEC_TONE_ON)7CX24123: cx24123_set_frontend: May 8 11:31:25 mythbox kernel: [ 3208.364885] CX24123: cx24123_set_inversion: inversion auto May 8 11:31:25 mythbox kernel: [ 3208.367181] CX24123: cx24123_set_fec: set FEC to 3/4 May 8 11:31:25 mythbox
Re: CX24123 no FE_HAS_LOCK/tuning failed.
John Donoghue wrote: http://bugzilla.kernel.org/show_bug.cgi?id=9476 where I outlined a More, i created a channels.conf file, tried using szap, to no avail. r...@mythbox:~# szap TV ONE reading channels from file '/home/rex/.szap/channels.conf' zapping to 2 'TV ONE': sat 0, frequency = 12483 MHz H, symbolrate 2250, vpid = 0x0203, apid = 0x028d using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' May 8 12:07:20 mythbox kernel: [ 953.539426] cx88[0]/2-dvb: cx8802_dvb_advise_acquire May 8 12:07:20 mythbox kernel: [ 953.539497] CX24123: cx24123_initfe: init frontend May 8 12:07:20 mythbox kernel: [ 953.559600] isl6421_set_tone(SEC_TONE_OFF)7CX24123: cx24123_send_diseqc_msg: May 8 12:07:20 mythbox kernel: [ 953.723705] CX24123: cx24123_diseqc_send_burst: status 01 | signal 0700 | snr a423 | ber | unc fffe | May 8 12:07:20 mythbox kernel: [ 953.840857] isl6421_set_tone(SEC_TONE_ON)7CX24123: cx24123_set_frontend: May 8 12:07:20 mythbox kernel: [ 953.842555] CX24123: cx24123_set_inversion: inversion auto May 8 12:07:20 mythbox kernel: [ 953.844856] CX24123: cx24123_set_fec: set FEC to auto May 8 12:07:20 mythbox kernel: [ 953.848464] CX24123: cx24123_set_symbolrate: srate=2250, ratio=0x0038f7b8, sample_rate=50555000 sample_gain=1 May 8 12:07:20 mythbox kernel: [ 953.848469] CX24123: cx24123_pll_tune: frequency=1883000 May 8 12:07:20 mythbox kernel: [ 953.848471] CX24123: cx24123_pll_writereg: pll writereg called, data=0x00100e3f May 8 12:07:20 mythbox kernel: [ 953.854740] CX24123: cx24123_pll_writereg: pll writereg called, data=0x000a0180 May 8 12:07:20 mythbox kernel: [ 953.860992] CX24123: cx24123_pll_writereg: pll writereg called, data=0x0220 May 8 12:07:20 mythbox kernel: [ 953.867270] CX24123: cx24123_pll_writereg: pll writereg called, data=0x001f4746 May 8 12:07:20 mythbox kernel: [ 953.875157] CX24123: cx24123_pll_tune: pll tune VCA=1052223, band=544, pll=2049862 May 8 12:07:20 mythbox kernel: [ 953.880585] CX24123: cx24123_read_signal_strength: Signal strength = 1792 May 8 12:07:20 mythbox kernel: [ 953.881930] CX24123: cx24123_read_snr: read S/N index = 42019 May 8 12:07:20 mythbox kernel: [ 953.883928] CX24123: cx24123_read_ber: BER = 0 status 01 | signal 0600 | snr a327 | ber | unc fffe | May 8 12:07:21 mythbox kernel: [ 954.885962] CX24123: cx24123_read_signal_strength: Signal strength = 1536 May 8 12:07:21 mythbox kernel: [ 954.887293] CX24123: cx24123_read_snr: read S/N index = 41767 May 8 12:07:21 mythbox kernel: [ 954.889290] CX24123: cx24123_read_ber: BER = 0 status 01 | signal 0600 | snr a2b0 | ber | unc fffe | May 8 12:07:22 mythbox kernel: [ 955.891312] CX24123: cx24123_read_signal_strength: Signal strength = 1536 May 8 12:07:22 mythbox kernel: [ 955.892636] CX24123: cx24123_read_snr: read S/N index = 41648 May 8 12:07:22 mythbox kernel: [ 955.894627] CX24123: cx24123_read_ber: BER = 0 status 01 | signal 0600 | snr a33a | ber | unc fffe | May 8 12:07:23 mythbox kernel: [ 956.896657] CX24123: cx24123_read_signal_strength: Signal strength = 1536 May 8 12:07:23 mythbox kernel: [ 956.897991] CX24123: cx24123_read_snr: read S/N index = 41786 May 8 12:07:23 mythbox kernel: [ 956.899987] CX24123: cx24123_read_ber: BER = 0 status 01 | signal 0600 | snr a3d4 | ber | unc fffe | *What is this telling me?* Cheers, Rex -- 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] FM1216ME_MK3 some changes
Am Mittwoch, den 06.05.2009, 23:03 -0400 schrieb Andy Walls: On Thu, 2009-05-07 at 02:01 +0200, hermann pitton wrote: Hi, Am Mittwoch, den 06.05.2009, 04:42 +1000 schrieb Dmitri Belimov: Hi Hermann Hi Dmitry, Am Mittwoch, den 29.04.2009, 20:12 +1000 schrieb Dmitri Belimov: Hi, Am Dienstag, den 28.04.2009, 19:59 +1000 schrieb Dmitri Belimov: On Tue, 28 Apr 2009 15:18:32 -0300 Mauro Carvalho Chehab mche...@infradead.org wrote: On Mon, 27 Apr 2009 19:29:05 +1000 Dmitri Belimov d.beli...@gmail.com wrote: Hi All Step by step. This is patch for change only range of FM1216ME_MK3. Slow tunning is not a big problem. Dmitri, I'll mark those patches as RFC at patchwork until the end of those discussions. After that, please send it again into a new thread. You mark patch with TOP AGC not this. I think need discuss about FM1216ME_MK3 because I'll have a big patch for support control TOP AGC (sensitivity) of this tuner. It can be bad for compatible tuners. hmm, in Europe, that TOP AGC did not ever made much difference and it is an insmod option since ever. From the tda9887_3 datasheet. 8.2 Tuner AGC and VIF-AGC This block adapts the voltages, generated at the VIF-AGC and SIF-AGC detectors, to the internal signal processing at the VIF and SIF amplifiers and performs the tuner AGC control current generation. The onset of the tuner AGC control current generation can be set either via the I2C-bus (see Table 13) or optionally by a potentiometer at pin TOP (in case that the I2C-bus information cannot be stored). The presence of a potentiometer is automatically detected and the I2C-bus setting is disabled. Reads for me that on some tuners, like NTSC only, the tuner AGC is fix. To change it per channel is not needed at all. I've started looking at the photographs of the tuner that Hermann sent. Looking at the TDA9887 v4 datasheet, I can see how the TOP related pins are (not) wired to the 1st stage oscillator/mixer chip. Pin 9 (TOP) is supposed to either be tied to ground through a resistor or left open. This design has the pin connected to a white SMT capacitor(?) which I will assume the TDA9887 will see as an open circuit. This means the TOP in the TDA9887 should be programmable via I2C. Pin 14 (TAGC) looks like it is unconnected. This means the TDA9887 TAGC output is not actively taking over gain control of the 1st stage RF mixer/oscialltor chip. So this answers a question I had posed to Dmitry: Is this tuner wired up so the TDA9887 can adjust the gain of the 1st stage? That answer is no. That means, that in this tuner, the AGC's in the two chips are operating independently and need their TOP's set in a coordinated manner that takes into account the IF filter losses and the modulation. Since the FM1216ME data sheet makes recommendations for TOP values for both chips: RF mixer/osc chip: 109 dBμV Recommended for negative modulation 106 dBμV Recommended for positive modulation It is recommended to set the TOP at 109 dBμV for PAL B/G, D/K, I For system L/L’, it is recommended to set the TOP at 106 dBμV. For FM radio, it is also recommended to set the TOP to 109 dBμV IF demod chip: C4-C0 = 1 [0 dB, 17 mV (RMS) according to the TDA9887 datasheet] for all FM modes and B/G D/K I L and L' systems it is probably best to use those. I can try and look at the IF filter from the picutres Hermann sent, but I'm not sure I'd be able to figure out the loss and come up with better TOP setting recommendations than the manufacturer's datasheet. I can't tell for Sibiria and initially that tuner had no SECAM-DK support officially at all. There are no good/much_better tuners for FTA at all and never have been ;) Some examples, user success reports, to make it more easily to understand? I think it can only change some _very little_ under already worst conditions. This is my idea for RFC about TOP AGC: what about to create a new FM1216ME MK3 tuner type for testing? Yes. Can you do it? I start add MK5 tuner. Yes, if really needed, but I see no hint anywhere that it should be useful to have TOP settings per channel for user applications and will stay away from it. Right now, I don't think the tuner-simple.c code adjusts the TOP value based on the video system or FM mode. It probably should. I don't think a user control will be very useful. For the change of UHF start I don't see any problem. If you're talking about the frequency for the bandswitch, I don't see a problem either in general. It may cause a problem for clones of the FM1216ME MK3 that don't
[PATCH][RESEND]saa7134-video.c: fix the block bug
when re-open or re-start (video_streamon), the q-curr would not be NULL in saa7134_buffer_queue(), and all the qbuf will add to q-queue list,no one to do activate to start DMA,and then no interrupt would happened,so it will be block. In VIDEOBUF_NEEDS_INIT state , inital the curr pointer to be NULL int the buffer_prepare(). Signed-off-by: Figo.zhang figo.zh...@kolorific.com --- drivers/media/video/saa7134/saa7134-video.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/media/video/saa7134/saa7134-video.c b/drivers/media/video/saa7134/saa7134-video.c index 493cad9..550d6ce 100644 --- a/drivers/media/video/saa7134/saa7134-video.c +++ b/drivers/media/video/saa7134/saa7134-video.c @@ -1057,6 +1057,7 @@ static int buffer_prepare(struct videobuf_queue *q, buf-vb.field = field; buf-fmt = fh-fmt; buf-pt= fh-pt_cap; + dev-video_q.curr = NULL; err = videobuf_iolock(q,buf-vb,dev-ovbuf); if (err) -- 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]saa7134-video.c: fix the block bug
when re-open or re-start (video_streamon), the q-curr would not be NULL in saa7134_buffer_queue(), and all the qbuf will add to q-queue list,no one to do activate to start DMA,and then no interrupt would happened,so it will be block. In VIDEOBUF_NEEDS_INIT state , inital the curr pointer to be NULL int the buffer_prepare(). Signed-off-by: Figo.zhang figo.zh...@kolorific.com --- drivers/media/video/saa7134/saa7134-video.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/media/video/saa7134/saa7134-video.c b/drivers/media/video/saa7134/saa7134-video.c index 493cad9..550d6ce 100644 --- a/drivers/media/video/saa7134/saa7134-video.c +++ b/drivers/media/video/saa7134/saa7134-video.c @@ -1057,6 +1057,7 @@ static int buffer_prepare(struct videobuf_queue *q, buf-vb.field = field; buf-fmt = fh-fmt; buf-pt= fh-pt_cap; + dev-video_q.curr = NULL; err = videobuf_iolock(q,buf-vb,dev-ovbuf); if (err) -- 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][RESEND]saa7134-video.c: fix the block bug
when re-open or re-start (video_streamon), the q-curr would not be NULL in saa7134_buffer_queue(), and all the qbuf will add to q-queue list,no one to do activate to start DMA,and then no interrupt would happened,so it will be block. In VIDEOBUF_NEEDS_INIT state , initial the curr pointer to be NULL in the buffer_prepare() function. Signed-off-by: Figo.zhang figo.zh...@kolorific.com --- drivers/media/video/saa7134/saa7134-video.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/media/video/saa7134/saa7134-video.c b/drivers/media/video/saa7134/saa7134-video.c index 493cad9..550d6ce 100644 --- a/drivers/media/video/saa7134/saa7134-video.c +++ b/drivers/media/video/saa7134/saa7134-video.c @@ -1057,6 +1057,7 @@ static int buffer_prepare(struct videobuf_queue *q, buf-vb.field = field; buf-fmt = fh-fmt; buf-pt= fh-pt_cap; + dev-video_q.curr = NULL; err = videobuf_iolock(q,buf-vb,dev-ovbuf); if (err) -- 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