Re: [linux-dvb] szap2 and Band L???

2009-05-07 Thread Markus Hahn
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

2009-05-07 Thread Jean-Francois Moine
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

2009-05-07 Thread Michal Pastor
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!

2009-05-07 Thread John R.


 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

2009-05-07 Thread Dmitri Belimov
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

2009-05-07 Thread Agustin

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

2009-05-07 Thread chaithrika
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

2009-05-07 Thread chaithrika
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

2009-05-07 Thread Agustin Ferrin Pozuelo

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

2009-05-07 Thread Guennadi Liakhovetski
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

2009-05-07 Thread Guennadi Liakhovetski
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

2009-05-07 Thread Reinhard Katzmann

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

2009-05-07 Thread Hans Verkuil
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

2009-05-07 Thread Antonio Ospite
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

2009-05-07 Thread vasaka
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

2009-05-07 Thread Erik Andrén
 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)

2009-05-07 Thread Andy Walls
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.

2009-05-07 Thread Rex J

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.

2009-05-07 Thread Rex J

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

2009-05-07 Thread hermann pitton

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

2009-05-07 Thread figo.zhang
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

2009-05-07 Thread figo.zhang
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

2009-05-07 Thread figo.zhang
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