RE: Bah! How do I change channels?

[George Adams]

Thanks again to both of you for your help.  I gave the no_poweroff flag a try, 
but didn't see any difference.  I also tried a "setchannel 3" during the middle 
of the encoding session, and also saw no change.
 
But I think I've found the problem:
 
> v4lctl setnorm NTSC; v4lctl setfreqtab us-bcast; v4lctl -v 1 setchannel 3
vid-open: trying: v4l2-old... 
vid-open: failed: v4l2-old
vid-open: trying: v4l2... 
v4l2: open
v4l2: device info:
  em28xx 0.1.1 / Pinnacle PCTV HD Pro Stick @ usb-:00:1a.7-1
vid-open: ok: v4l2
freq: reading /usr/share/xawtv/Index.map
v4l2:   tuner cap:
v4l2:   tuner rxs:
v4l2:   tuner cur: MONO
cmd: "setchannel" "3"
v4l2: freq: 0.000
v4l2: close
 
 
What?  freq: 0.000 ?  After finding the ivtv package and compiling its utils, I 
confirm it with this:
 
> v4l2-ctl -F
Frequency: 0 (0.00 MHz)
 
> ivtv-tune -c 3
/dev/video0: 61.250 MHz
 
> v4l2-ctl -F  
Frequency: 980 (61.25 MHz)
 
> v4lctl setchannel 3

> v4l2-ctl -F  
Frequency: 0 (0.00 MHz)
 
 
So mysteriously, it seems like v4lctl is just plain not working.  And 
ivtv-tune, on the other hand, is working just fine.  After I do that and start 
Helix Producer, I see channel 3 just like I had hoped.
 
(strangely, v4lctl can do other things fine, like change the norm from NTSC to 
PAL.  It just can't change the channel.)
 
So, sorry that it went off in rabbit trails of the device powering down and so 
forth.  I wonder what happened to my v4lctl program, though?  xawtv itself 
(running in X) seems to work fine when I tell it to change the channel...
 

 
 
 

> Date: Fri, 26 Jun 2009 09:42:06 -0400
> Subject: Re: Bah! How do I change channels?
> From: dheitmuel...@kernellabs.com
> To: awa...@radix.net
> CC: g_adam...@hotmail.com; video4linux-l...@redhat.com; 
> linux-media@vger.kernel.org
> 
> On Fri, Jun 26, 2009 at 7:50 AM, Andy Walls wrote:
>> I use either v4l2-ctl or ivtv-tune
>>
>> $ ivtv-tune -d /dev/video0 -t us-bcast -c 3
>> /dev/video0: 61.250 MHz
>>
>> $ v4l2-ctl -d /dev/video0 -f 61.250
>> Frequency set to 980 (61.25 MHz)
>>
>>
>> Regards,
>> Andy
> 
> Hello Andy,
> 
> I had sent George some email off-list with basically the same
> commands. I think what might be happening here is the tuner gets
> powered down when not in use, so I think it might be powered down
> between the v4l-ctl command and the running of the other application.
> 
> I have sent him a series of commands to try where he modprobes the
> xc3028 driver with "no_poweroff=1", and we will see if that starts
> working.
> 
> Devin
> 
> -- 
> Devin J. Heitmueller - Kernel Labs
> http://www.kernellabs.com
_
Lauren found her dream laptop. Find the PC that’s right for you.
http://www.microsoft.com/windows/choosepc/?ocid=ftp_val_wl_290--
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

fix for unrecognized Haupauge WinTV Nova-T

[Robert Millan]

Hi,

My Haupauge WinTV Nova-T (USB) wasn't being properly recognized.  I
got these in dmesg when sending IR signals to it:

[  433.353038] dib0700: Unknown remote controller key: 1D  3  0  0

It seems the driver is trying to match the vendor field with 0x1E,
whereas 0x1D is not listed.

The following worked for me:

sed -i drivers/media/dvb/dvb-usb/dib0700_devices.c -e "s/{ 0x1e, /{ 0x1d, /g"
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/3 - v0] davinci: platform changes to support vpfe camera capture

[m-karicheri2]

From: Muralidharan Karicheri 

Following are the changes:-
1) moved i2c board specific part to sub device configuration
structure so that sub device can be loaded from vpfe capture
using the new v4l2_i2c_new_subdev_board() api
2) adding mt9t031 sub device configuration information for
DM355 as part of camera capture support to vpfe capture
3) adding support to setup raw data path and i2c switch
when capturing from mt9t031

NOTE: Depends on v3 version of vpfe capture driver patch

Mandatory Reviewers: Kevin Hilman 
Mandatory Reviewers: Hans Verkuil 

Signed-off-by: Muralidharan Karicheri 
---
Applies to DaVinci GIT Tree

 arch/arm/mach-davinci/board-dm355-evm.c  |  208 --
 arch/arm/mach-davinci/board-dm644x-evm.c |   24 ++--
 2 files changed, 210 insertions(+), 22 deletions(-)

diff --git a/arch/arm/mach-davinci/board-dm355-evm.c 
b/arch/arm/mach-davinci/board-dm355-evm.c
index 513be53..a781ca2 100644
--- a/arch/arm/mach-davinci/board-dm355-evm.c
+++ b/arch/arm/mach-davinci/board-dm355-evm.c
@@ -136,10 +136,66 @@ static void dm355evm_mmcsd_gpios(unsigned gpio)
dm355evm_mmc_gpios = gpio;
 }
 
-static struct tvp514x_platform_data tvp5146_pdata = {
-   .clk_polarity = 0,
-   .hs_polarity = 1,
-   .vs_polarity = 1
+/*
+ * MSP430 supports RTC, card detection, input from IR remote, and
+ * a bit more.  It triggers interrupts on GPIO(7) from pressing
+ * buttons on the IR remote, and for card detect switches.
+ */
+static struct i2c_client *dm355evm_msp;
+
+static int dm355evm_msp_probe(struct i2c_client *client,
+   const struct i2c_device_id *id)
+{
+   dm355evm_msp = client;
+   return 0;
+}
+
+static int dm355evm_msp_remove(struct i2c_client *client)
+{
+   dm355evm_msp = NULL;
+   return 0;
+}
+
+static const struct i2c_device_id dm355evm_msp_ids[] = {
+   { "dm355evm_msp", 0, },
+   { /* end of list */ },
+};
+
+static struct i2c_driver dm355evm_msp_driver = {
+   .driver.name= "dm355evm_msp",
+   .id_table   = dm355evm_msp_ids,
+   .probe  = dm355evm_msp_probe,
+   .remove = dm355evm_msp_remove,
+};
+
+#define PCA9543A_I2C_ADDR   (0x73)
+
+static struct i2c_client *pca9543a;
+
+static int pca9543a_probe(struct i2c_client *client,
+   const struct i2c_device_id *id)
+{
+   pca9543a = client;
+   return 0;
+}
+
+static int pca9543a_remove(struct i2c_client *client)
+{
+   pca9543a = NULL;
+   return 0;
+}
+
+static const struct i2c_device_id pca9543a_ids[] = {
+   { "PCA9543A", 0, },
+   { /* end of list */ },
+};
+
+/* This is for i2c driver for the MT9T031 header i2c switch */
+static struct i2c_driver pca9543a_driver = {
+   .driver.name= "PCA9543A",
+   .id_table   = pca9543a_ids,
+   .probe  = pca9543a_probe,
+   .remove = pca9543a_remove,
 };
 
 static struct i2c_board_info dm355evm_i2c_info[] = {
@@ -147,13 +203,22 @@ static struct i2c_board_info dm355evm_i2c_info[] = {
.platform_data = dm355evm_mmcsd_gpios,
},
{
-   I2C_BOARD_INFO("tvp5146", 0x5d),
-   .platform_data = &tvp5146_pdata,
+   I2C_BOARD_INFO("PCA9543A", 0x73),
},
/* { plus irq  }, */
/* { I2C_BOARD_INFO("tlv320aic3x", 0x1b), }, */
 };
 
+/* have_sensor() - Check if we have support for sensor interface */
+static inline int have_sensor(void)
+{
+#ifdef CONFIG_SOC_CAMERA_MT9T031
+   return 1;
+#else
+   return 0;
+#endif
+}
+
 static void __init evm_init_i2c(void)
 {
davinci_init_i2c(&i2c_pdata);
@@ -161,9 +226,12 @@ static void __init evm_init_i2c(void)
gpio_request(5, "dm355evm_msp");
gpio_direction_input(5);
dm355evm_i2c_info[0].irq = gpio_to_irq(5);
-
+   i2c_add_driver(&dm355evm_msp_driver);
+   if (have_sensor())
+   i2c_add_driver(&pca9543a_driver);
i2c_register_board_info(1, dm355evm_i2c_info,
ARRAY_SIZE(dm355evm_i2c_info));
+
 }
 
 static struct resource dm355evm_dm9000_rsrc[] = {
@@ -190,6 +258,104 @@ static struct platform_device dm355evm_dm9000 = {
.num_resources  = ARRAY_SIZE(dm355evm_dm9000_rsrc),
 };
 
+/**
+ * dm355evm_enable_raw_data_path() - Enable/Disable raw data path
+ * @en: enable/disbale flag
+ */
+static int dm355evm_enable_raw_data_path(int en)
+{
+   static char txbuf[2] = { 8, 0x80 };
+   int status;
+   struct i2c_msg msg = {
+   .flags = 0,
+   .len = 2,
+   .buf = (void __force *)txbuf,
+   };
+
+   if (!en)
+   txbuf[1] = 0;
+
+   if (!dm355evm_msp)
+   return -ENXIO;
+
+   msg.addr = dm355evm_msp->addr,
+   /* turn on/off the raw data path through msp430 */
+   status = i2c_transfer(dm355evm_msp->adapter, &msg, 1);
+   return status;
+}

[PATCH 2/3 - v0] V4L: ccdc driver - adding support for camera capture

[m-karicheri2]

From: Muralidharan Karicheri 

Following updates to ccdc driver :-
1) Adding support for camera capture using mt9t031
2) Changed default resolution for ycbcr capture to NTSC to match
   with tvp514x driver.
3) Returns proper error code from ccdc_init (comments against previous 
patch
   version v3)

Mandatory Reviewers: Hans Verkuil 

Signed-off-by: Muralidharan Karicheri 
---
Applies to v4l-dvb repository

 drivers/media/video/davinci/dm355_ccdc.c  |   21 +
 drivers/media/video/davinci/dm644x_ccdc.c |   13 +
 include/media/davinci/dm355_ccdc.h|2 +-
 include/media/davinci/dm644x_ccdc.h   |2 +-
 4 files changed, 24 insertions(+), 14 deletions(-)

diff --git a/drivers/media/video/davinci/dm355_ccdc.c 
b/drivers/media/video/davinci/dm355_ccdc.c
index 69e38d0..6c6e77c 100644
--- a/drivers/media/video/davinci/dm355_ccdc.c
+++ b/drivers/media/video/davinci/dm355_ccdc.c
@@ -28,10 +28,9 @@
  * files. The setparams() API is called by vpfe_capture driver
  * to configure module parameters
  *
- * TODO: 1) Raw bayer parameter settings and bayer capture
- *  2) Split module parameter structure to module specific ioctl structs
- *  3) add support for lense shading correction
- *  4) investigate if enum used for user space type definition
+ * TODO: 1) Split module parameter structure to module specific ioctl structs
+ *  2) add support for lense shading correction
+ *  3) investigate if enum used for user space type definition
  * to be replaced by #defines or integer
  */
 #include 
@@ -92,7 +91,7 @@ static struct ccdc_params_raw ccdc_hw_params_raw = {
 
 /* Object for CCDC ycbcr mode */
 static struct ccdc_params_ycbcr ccdc_hw_params_ycbcr = {
-   .win = CCDC_WIN_PAL,
+   .win = CCDC_WIN_NTSC,
.pix_fmt = CCDC_PIXFMT_YCBCR_8BIT,
.frm_fmt = CCDC_FRMFMT_INTERLACED,
.fid_pol = VPFE_PINPOL_POSITIVE,
@@ -1107,8 +1106,11 @@ static int ccdc_set_hw_if_params(struct vpfe_hw_if_param 
*params)
ccdc_hw_params_ycbcr.vd_pol = params->vdpol;
ccdc_hw_params_ycbcr.hd_pol = params->hdpol;
break;
+   case VPFE_RAW_BAYER:
+   ccdc_hw_params_raw.vd_pol = params->vdpol;
+   ccdc_hw_params_raw.hd_pol = params->hdpol;
+   break;
default:
-   /* TODO add support for raw bayer here */
return -EINVAL;
}
return 0;
@@ -1146,9 +1148,12 @@ static struct ccdc_hw_device ccdc_hw_dev = {
 
 static int dm355_ccdc_init(void)
 {
+   int ret;
+
printk(KERN_NOTICE "dm355_ccdc_init\n");
-   if (vpfe_register_ccdc_device(&ccdc_hw_dev) < 0)
-   return -1;
+   ret = vpfe_register_ccdc_device(&ccdc_hw_dev);
+   if (ret < 0)
+   return ret;
printk(KERN_NOTICE "%s is registered with vpfe.\n",
ccdc_hw_dev.name);
return 0;
diff --git a/drivers/media/video/davinci/dm644x_ccdc.c 
b/drivers/media/video/davinci/dm644x_ccdc.c
index 2f19a91..5dff8d9 100644
--- a/drivers/media/video/davinci/dm644x_ccdc.c
+++ b/drivers/media/video/davinci/dm644x_ccdc.c
@@ -65,7 +65,7 @@ static struct ccdc_params_raw ccdc_hw_params_raw = {
 static struct ccdc_params_ycbcr ccdc_hw_params_ycbcr = {
.pix_fmt = CCDC_PIXFMT_YCBCR_8BIT,
.frm_fmt = CCDC_FRMFMT_INTERLACED,
-   .win = CCDC_WIN_PAL,
+   .win = CCDC_WIN_NTSC,
.fid_pol = VPFE_PINPOL_POSITIVE,
.vd_pol = VPFE_PINPOL_POSITIVE,
.hd_pol = VPFE_PINPOL_POSITIVE,
@@ -825,8 +825,10 @@ static int ccdc_set_hw_if_params(struct vpfe_hw_if_param 
*params)
ccdc_hw_params_ycbcr.vd_pol = params->vdpol;
ccdc_hw_params_ycbcr.hd_pol = params->hdpol;
break;
+   case VPFE_RAW_BAYER:
+   ccdc_hw_params_raw.vd_pol = params->vdpol;
+   ccdc_hw_params_raw.hd_pol = params->hdpol;
default:
-   /* TODO add support for raw bayer here */
return -EINVAL;
}
return 0;
@@ -861,9 +863,12 @@ static struct ccdc_hw_device ccdc_hw_dev = {
 
 static int dm644x_ccdc_init(void)
 {
+   int ret;
+
printk(KERN_NOTICE "dm644x_ccdc_init\n");
-   if (vpfe_register_ccdc_device(&ccdc_hw_dev) < 0)
-   return -1;
+   ret = vpfe_register_ccdc_device(&ccdc_hw_dev);
+   if (ret < 0)
+   return ret;
printk(KERN_NOTICE "%s is registered with vpfe.\n",
ccdc_hw_dev.name);
return 0;
diff --git a/include/media/davinci/dm355_ccdc.h 
b/include/media/davinci/dm355_ccdc.h
index b0ce1af..3526920 100644
--- a/include/media/davinci/dm355_ccdc.h
+++ b/include/media/davinci/dm355_ccdc.h
@@ -254,7 +254,7 @@ struct ccdc_config_params_raw {
 #ifdef __KERNEL__
 #include 
 
-#define CCDC_WIN_PAL   {0, 0, 720, 576}
+#define CCDC_WIN_NTSC  {0, 0, 720, 480}
 #define CCDC_WIN_VGA   {0, 0, 640, 480}

[PATCH 1/3 - v0] V4L: vpfe capture driver - adding support for camera capture

[m-karicheri2]

From: Muralidharan Karicheri 

Re-sending adding Hans to CC

Following updates to vpfe capture driver :-
1) Adding support for camera capture using mt9t031 driver
   (A patch for mt9t031 is already sent for review)
2) Use v4l2_i2c_new_subdev_board() for loading sub devices
3) Fixed a bug in s_input and g_input handler
4) removed g_std() since it is already taken care by
   v4l2 framework based on current_norm
5) return proper error code from ccdc register function

Mandatory Reviewers: Hans Verkuil 

NOTE: Requires support for v4l2_i2c_new_subdev_board() which was recently
added to v4l2 framework by Hans Verkuil.

Signed-off-by: Muralidharan Karicheri 
---
Applies to v4l-dvb repository

 drivers/media/video/davinci/vpfe_capture.c |  356 
 include/media/davinci/vpfe_capture.h   |   16 ++
 2 files changed, 271 insertions(+), 101 deletions(-)

diff --git a/drivers/media/video/davinci/vpfe_capture.c 
b/drivers/media/video/davinci/vpfe_capture.c
index a4cbe2a..414a7b4 100644
--- a/drivers/media/video/davinci/vpfe_capture.c
+++ b/drivers/media/video/davinci/vpfe_capture.c
@@ -59,7 +59,6 @@
  *TODO list
  * - Support multiple REQBUF after open
  * - Support for de-allocating buffers through REQBUF
- * - Support for Raw Bayer RGB capture
  * - Support for chaining Image Processor
  * - Support for static allocation of buffers
  * - Support for USERPTR IO
@@ -74,18 +73,29 @@
 #include 
 #include 
 #include 
-#include 
-#include 
 #include "ccdc_hw_device.h"
 
 static int debug;
 static u32 numbuffers = 3;
 static u32 bufsize = (720 * 576 * 2);
+static int interface;
 
+module_param(interface, bool, S_IRUGO);
 module_param(numbuffers, uint, S_IRUGO);
 module_param(bufsize, uint, S_IRUGO);
-module_param(debug, int, 0644);
-
+module_param(debug, bool, 0644);
+
+/**
+ * VPFE capture can be used for capturing video such as from TVP5146 or TVP7002
+ * and for capture raw bayer data from camera sensors such as MT9T031. At this
+ * point there is problem in co-existence of mt9t031 and tvp5146 due to i2c
+ * address collision. So set the variable below from bootargs to do either 
video
+ * capture or camera capture.
+ * interface = 0 - video capture (from TVP514x or such),
+ * interface = 1 - Camera capture (from MT9T031 or such)
+ * Re-visit this when we fix the co-existence issue
+ */
+MODULE_PARM_DESC(interface, "interface 0-1 (default:0)");
 MODULE_PARM_DESC(numbuffers, "buffer count (default:3)");
 MODULE_PARM_DESC(bufsize, "buffer size in bytes (default:720 x 576 x 2)");
 MODULE_PARM_DESC(debug, "Debug level 0-1");
@@ -145,6 +155,7 @@ static const struct vpfe_pixel_format vpfe_pix_fmts[] = {
.pixelformat = V4L2_PIX_FMT_SBGGR8,
},
.bpp = 1,
+   .subdev_pix_fmt = V4L2_PIX_FMT_SGRBG10,
},
{
.fmtdesc = {
@@ -154,6 +165,7 @@ static const struct vpfe_pixel_format vpfe_pix_fmts[] = {
.pixelformat = V4L2_PIX_FMT_SBGGR16,
},
.bpp = 2,
+   .subdev_pix_fmt = V4L2_PIX_FMT_SGRBG10,
},
{
.fmtdesc = {
@@ -163,6 +175,7 @@ static const struct vpfe_pixel_format vpfe_pix_fmts[] = {
.pixelformat = V4L2_PIX_FMT_SGRBG10DPCM8,
},
.bpp = 1,
+   .subdev_pix_fmt = V4L2_PIX_FMT_SGRBG10,
},
{
.fmtdesc = {
@@ -172,6 +185,7 @@ static const struct vpfe_pixel_format vpfe_pix_fmts[] = {
.pixelformat = V4L2_PIX_FMT_UYVY,
},
.bpp = 2,
+   .subdev_pix_fmt = V4L2_PIX_FMT_UYVY,
},
{
.fmtdesc = {
@@ -181,6 +195,7 @@ static const struct vpfe_pixel_format vpfe_pix_fmts[] = {
.pixelformat = V4L2_PIX_FMT_YUYV,
},
.bpp = 2,
+   .subdev_pix_fmt = V4L2_PIX_FMT_UYVY,
},
{
.fmtdesc = {
@@ -190,12 +205,15 @@ static const struct vpfe_pixel_format vpfe_pix_fmts[] = {
.pixelformat = V4L2_PIX_FMT_NV12,
},
.bpp = 1,
+   .subdev_pix_fmt = V4L2_PIX_FMT_UYVY,
},
 };
 
-/*
- * vpfe_lookup_pix_format()
- * lookup an entry in the vpfe pix format table based on pix_format
+/**
+ * vpfe_lookup_pix_format() - lookup an entry in the vpfe pix format table
+ * @pix_format: v4l pix format
+ * This function lookup an entry in the vpfe pix format table based on
+ * pix_format
  */
 static const struct vpfe_pixel_format *vpfe_lookup_pix_format(u32 pix_format)
 {
@@ -243,19 +261,19 @@ int vpfe_register_ccdc_device(struct ccdc_hw_device *dev)
 * walk through it during vpfe probe
 */
printk(KERN_ERR "vpfe capture not

[PATCH 1/3 - v0] V4L: vpfe capture driver - adding support for camera capture

[m-karicheri2]

From: Muralidharan Karicheri 

Following updates to vpfe capture driver :-
1) Adding support for camera capture using mt9t031 driver
   (A patch for mt9t031 is already sent for review)
2) Use v4l2_i2c_new_subdev_board() for loading sub devices
3) Fixed a bug in s_input and g_input handler
4) removed g_std() since it is already taken care by
   v4l2 framework based on current_norm
5) return proper error code from ccdc register function

Mandatory Reviewers: Hans Verkuil 

NOTE: Requires support for v4l2_i2c_new_subdev_board() which was recently
added to v4l2 framework by Hans Verkuil.

Signed-off-by: Muralidharan Karicheri 
---
Applies to v4l-dvb repository

 drivers/media/video/davinci/vpfe_capture.c |  356 
 include/media/davinci/vpfe_capture.h   |   16 ++
 2 files changed, 271 insertions(+), 101 deletions(-)

diff --git a/drivers/media/video/davinci/vpfe_capture.c 
b/drivers/media/video/davinci/vpfe_capture.c
index a4cbe2a..414a7b4 100644
--- a/drivers/media/video/davinci/vpfe_capture.c
+++ b/drivers/media/video/davinci/vpfe_capture.c
@@ -59,7 +59,6 @@
  *TODO list
  * - Support multiple REQBUF after open
  * - Support for de-allocating buffers through REQBUF
- * - Support for Raw Bayer RGB capture
  * - Support for chaining Image Processor
  * - Support for static allocation of buffers
  * - Support for USERPTR IO
@@ -74,18 +73,29 @@
 #include 
 #include 
 #include 
-#include 
-#include 
 #include "ccdc_hw_device.h"
 
 static int debug;
 static u32 numbuffers = 3;
 static u32 bufsize = (720 * 576 * 2);
+static int interface;
 
+module_param(interface, bool, S_IRUGO);
 module_param(numbuffers, uint, S_IRUGO);
 module_param(bufsize, uint, S_IRUGO);
-module_param(debug, int, 0644);
-
+module_param(debug, bool, 0644);
+
+/**
+ * VPFE capture can be used for capturing video such as from TVP5146 or TVP7002
+ * and for capture raw bayer data from camera sensors such as MT9T031. At this
+ * point there is problem in co-existence of mt9t031 and tvp5146 due to i2c
+ * address collision. So set the variable below from bootargs to do either 
video
+ * capture or camera capture.
+ * interface = 0 - video capture (from TVP514x or such),
+ * interface = 1 - Camera capture (from MT9T031 or such)
+ * Re-visit this when we fix the co-existence issue
+ */
+MODULE_PARM_DESC(interface, "interface 0-1 (default:0)");
 MODULE_PARM_DESC(numbuffers, "buffer count (default:3)");
 MODULE_PARM_DESC(bufsize, "buffer size in bytes (default:720 x 576 x 2)");
 MODULE_PARM_DESC(debug, "Debug level 0-1");
@@ -145,6 +155,7 @@ static const struct vpfe_pixel_format vpfe_pix_fmts[] = {
.pixelformat = V4L2_PIX_FMT_SBGGR8,
},
.bpp = 1,
+   .subdev_pix_fmt = V4L2_PIX_FMT_SGRBG10,
},
{
.fmtdesc = {
@@ -154,6 +165,7 @@ static const struct vpfe_pixel_format vpfe_pix_fmts[] = {
.pixelformat = V4L2_PIX_FMT_SBGGR16,
},
.bpp = 2,
+   .subdev_pix_fmt = V4L2_PIX_FMT_SGRBG10,
},
{
.fmtdesc = {
@@ -163,6 +175,7 @@ static const struct vpfe_pixel_format vpfe_pix_fmts[] = {
.pixelformat = V4L2_PIX_FMT_SGRBG10DPCM8,
},
.bpp = 1,
+   .subdev_pix_fmt = V4L2_PIX_FMT_SGRBG10,
},
{
.fmtdesc = {
@@ -172,6 +185,7 @@ static const struct vpfe_pixel_format vpfe_pix_fmts[] = {
.pixelformat = V4L2_PIX_FMT_UYVY,
},
.bpp = 2,
+   .subdev_pix_fmt = V4L2_PIX_FMT_UYVY,
},
{
.fmtdesc = {
@@ -181,6 +195,7 @@ static const struct vpfe_pixel_format vpfe_pix_fmts[] = {
.pixelformat = V4L2_PIX_FMT_YUYV,
},
.bpp = 2,
+   .subdev_pix_fmt = V4L2_PIX_FMT_UYVY,
},
{
.fmtdesc = {
@@ -190,12 +205,15 @@ static const struct vpfe_pixel_format vpfe_pix_fmts[] = {
.pixelformat = V4L2_PIX_FMT_NV12,
},
.bpp = 1,
+   .subdev_pix_fmt = V4L2_PIX_FMT_UYVY,
},
 };
 
-/*
- * vpfe_lookup_pix_format()
- * lookup an entry in the vpfe pix format table based on pix_format
+/**
+ * vpfe_lookup_pix_format() - lookup an entry in the vpfe pix format table
+ * @pix_format: v4l pix format
+ * This function lookup an entry in the vpfe pix format table based on
+ * pix_format
  */
 static const struct vpfe_pixel_format *vpfe_lookup_pix_format(u32 pix_format)
 {
@@ -243,19 +261,19 @@ int vpfe_register_ccdc_device(struct ccdc_hw_device *dev)
 * walk through it during vpfe probe
 */
printk(KERN_ERR "vpfe capture not initialized\n");
-   

Re: Bah! How do I change channels?

[Andy Walls]

On Fri, 2009-06-26 at 15:29 -0400, Devin Heitmueller wrote: 
> On Fri, Jun 26, 2009 at 3:02 PM, Andy Walls wrote:
> > All I'm saying is that it is obviously the expected behavior, it the
> > specified behavior, and all the userland apps and scripts are written
> > with that behavior in mind.
> >
> > The applications' expectation of that behavior is, of course, why we are
> > having this discussion.
> >
> > Assuming arguendo, maintaing state in the face of power management is a
> > hard requirement on the driver; I'll still contend it's harder to change
> > the existing base of applications and user scripts.  Until the spec and
> > all the existing apps change, not adhering to the spec leads to user
> > confusion.
> 
> I guess that means that every product that has a tuner which
> implements the sleep callback is broken.  And yet this is the first
> case I've heard a user complain, which makes me wonder how big a
> population is out there that is using scripts to control the tuner.  I
> suspect most people are just using applications like MythTV, xawtv or
> tvtime, which won't have these issues.


> I don't intend to come across as argumentative, but if we haven't
> heard a massive outcry about this by now, maybe nobody actually cares
> and thus we shouldn't spend the time to build a whole infrastructure
> to preserve the driver state across the low power mode.

Devin,

I'm not saying we need to fix every broken tuner driver.  I would
suggest, however, that if you fix the one at hand, you will provide a
template which others could follow as the problem crops up with other
devices.


>   Those people
> who really do care can just disable the power management with a
> modprobe option.

I doubt you'll here a massive outcry, as most users use a large
monlithic application (e.g. MyhtTV) that keep at least two device nodes
open, so even if they momentarily close one, it doesn't matter.

Where it hurts not to preserve state is for:

1. development and troubleshooting - small tools that do one thing and
can do them in whatever order you want simply are really nice to have
work.

In this thread I've seen a user trying to troubleshoot being affected by
not preserving state.



2. user work arounds or conveniences - a small tool used in a script to
twiddle a device setting.

Preserving state is often *not* used for saving the last tuned
frequency, but for other things like the last used input, volume level,
VBI settings, etc.




As I wave the V4L2 spec around like a blind follower of some sacred law,
I'm begin to feel like Piggy clinging to the conch shell in
_The_Lord_of_the_Flies_ , so

If you think the V4L2 spec is bad, then propose a modification in
writing (an RFC) that you think makes sense.  Propose exceptions for
tuners and/or power management.

I'm not trying to be argumentative either.  I guess I'm just not a big
fan of "kicking the can down the road".  We all bear the burden of the
spec non-compliance in the power managment design and/or implementation,
in the form of additional user support and less flexible troubleshooting
steps, until it is resolved.  

I do, however, appreciate that there is only so much time to do useful
work and that one has to prioritize.  And I do also appreciate the large
amount of enegry you put into v4l-dvb.

Regards,
Andy

> Devin


--
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: Bah! How do I change channels?

[Devin Heitmueller]

On Fri, Jun 26, 2009 at 3:56 PM, Robert Vincent
> I care and I love the infrastructure that has been created.  However, it
> seems as though there are devices that do not conform to the paradigm or
> maybe they are not truly in "low power" mode.  My guess is the latter
> otherwise there would be a flurry of complaints.

Unfortunately, it's a little more complicated.  In the beginning, none
of the drivers did power management, and nobody cared because they
were all PCI cards and nobody would notice a 1 watt difference in
consumption on a 300 watt power supply.  These devices would maintain
persistent state across v4l closes because the chips were never
powered down.

Other devices, such as some USB devices, do have the power management
hooks implemented.  I don't know what the percentages are here (I
would have to look at the driver code to figure that out).  These
devices power down the chips when asked to by the bridge, and it is
typically triggered when no userland apps still have the v4l device
open.  In cases such as this, the power management works but it would
break cases where people used scripts to control the device.

There's probably a third class of devices worth mentioning: those that
really should be doing power management but aren't.  This includes all
the USB devices which burn your fingers and drain your laptop battery
from the time you plug it in until the time you unplug it, regardless
of whether you are using it.

It's not about "caring" or how much we do or do not love the
infrastructure.  It's about deciding what are the most important goals
given limited developer resources.  In this case, it's a question of
which is more important: incurring the cost of overhauling all the
drivers that do power management to have state persist after a power
down versus telling those users who use scripts to manually disable
power management.

Since we have no idea how many users use scripts to control their
tuners, and right now we don't know how many devices are effected, we
cannot really make any decisions one way or the other.

My hope is to see power management properly implemented in more
drivers since I'm concerned about the environment.  However, if I have
to do a huge overhaul of the state management in every driver just to
accommodate an unknown quantity of users, then I would have to think
twice about that.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Bah! How do I change channels?

[Robert Vincent Krakora]

Devin Heitmueller wrote:

On Fri, Jun 26, 2009 at 3:02 PM, Andy Walls wrote:
  

All I'm saying is that it is obviously the expected behavior, it the
specified behavior, and all the userland apps and scripts are written
with that behavior in mind.

The applications' expectation of that behavior is, of course, why we are
having this discussion.

Assuming arguendo, maintaing state in the face of power management is a
hard requirement on the driver; I'll still contend it's harder to change
the existing base of applications and user scripts.  Until the spec and
all the existing apps change, not adhering to the spec leads to user
confusion.



I guess that means that every product that has a tuner which
implements the sleep callback is broken.  And yet this is the first
case I've heard a user complain, which makes me wonder how big a
population is out there that is using scripts to control the tuner.  I
suspect most people are just using applications like MythTV, xawtv or
tvtime, which won't have these issues.

I don't intend to come across as argumentative, but if we haven't
heard a massive outcry about this by now, maybe nobody actually cares
and thus we shouldn't spend the time to build a whole infrastructure
to preserve the driver state across the low power mode.  Those people
who really do care can just disable the power management with a
modprobe option.

Devin

  

Devin:

I care and I love the infrastructure that has been created.  However, it 
seems as though there are devices that do not conform to the paradigm or 
maybe they are not truly in "low power" mode.  My guess is the latter 
otherwise there would be a flurry of complaints.


Best Regards,

--
Rob Krakora
Senior Software Engineer
MessageNet Systems
101 East Carmel Dr. Suite 105
Carmel, IN 46032
(317)566-1677 Ext. 206
(317)663-0808 Fax
--
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: [PARTIALLY SOLVED] Can't use my Pinnacle PCTV HD Pro stick - what am I doing wrong?

[Michael Krufky]

On Fri, Jun 26, 2009 at 1:59 PM, Devin
Heitmueller wrote:
> On Fri, Jun 26, 2009 at 1:50 PM, Hans Verkuil wrote:
>> On Thursday 25 June 2009 20:25:31 Devin Heitmueller wrote:
>>> Hans,
>>>
>>> I just spoke with mkrufky, and he confirmed the issue does occur with
>>> the HVR-950.  However, the em28xx driver does not do a printk() when
>>> the subdev registration fails (I will submit a patch to fix that).
>>>
>>> Please let me know if you have any further question.
>>>
>>> Thanks for your assistance,
>>>
>>> Devin
>>>
>>
>> Fixed in my http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-misc tree.
>>
>> A pull request for this has already been posted, so it should be merged soon
>> I hope.
>>
>> It was a trivial change: originally the new i2c API would be used for kernels
>> 2.6.22 and up, until it was discovered that there was a serious bug in the 
>> i2c
>> core that wasn't fixed until 2.6.26. So I changed it to kernel 2.6.26.
>>
>> Unfortunately, the em28xx driver was still using 2.6.22 as the cut-off point,
>> preventing i2c drivers from being initialized. So em28xx was broken for
>> kernels 2.6.22-2.6.25.
>
> Ok, I will submit a comparable fix for au0828.  I guess maybe it makes
> sense also to audit all the bridges where we set the .class field to
> ensure they all are for 2.6.26.

Thanks Devin and Hans.

I fixed it in the au0828 driver...  Fix and pull request are here:

http://www.spinics.net/lists/linux-media/msg07360.html

Cheers,

Mike
--
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] http://kernellabs.com/hg/~mkrufky/au0828

[Michael Krufky]

Mauro,

Please pull from:

http://kernellabs.com/hg/~mkrufky/au0828

for the following kernel-compat fix:

- au0828: fix i2c for kernels prior to 2.6.26

 au0828-i2c.c |3 +++
 1 file changed, 3 insertions(+)

Please note that this tree also contains some changesets from Hans
Verkuil's v4l-dvb-misc tree -- Most likely, you will see his pull
request and merge it first before you get to this one.

Please *also* note that I am still waiting for you to merge my pending
changsets from:

http://kernellabs.com/hg/~mkrufky/k2c2

for the following fixes that should be merged into Linus' tree for 2.6.31:

- cx23885: override set_frontend to allow rf input path switching on the HVR1275
- cx23885: add FIXME comment above set_frontend override

 cx23885-dvb.c |   30 ++
 cx23885.h |4 
 2 files changed, 34 insertions(+)

Cheers,

Mike
--
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: Bah! How do I change channels?

[Devin Heitmueller]

On Fri, Jun 26, 2009 at 3:02 PM, Andy Walls wrote:
> All I'm saying is that it is obviously the expected behavior, it the
> specified behavior, and all the userland apps and scripts are written
> with that behavior in mind.
>
> The applications' expectation of that behavior is, of course, why we are
> having this discussion.
>
> Assuming arguendo, maintaing state in the face of power management is a
> hard requirement on the driver; I'll still contend it's harder to change
> the existing base of applications and user scripts.  Until the spec and
> all the existing apps change, not adhering to the spec leads to user
> confusion.

I guess that means that every product that has a tuner which
implements the sleep callback is broken.  And yet this is the first
case I've heard a user complain, which makes me wonder how big a
population is out there that is using scripts to control the tuner.  I
suspect most people are just using applications like MythTV, xawtv or
tvtime, which won't have these issues.

I don't intend to come across as argumentative, but if we haven't
heard a massive outcry about this by now, maybe nobody actually cares
and thus we shouldn't spend the time to build a whole infrastructure
to preserve the driver state across the low power mode.  Those people
who really do care can just disable the power management with a
modprobe option.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: v4l2_subdev GPIO and Pin Control ops (Re: PxDVR3200 H LinuxTV v4l-dvb patch : Pull GPIO-20 low for DVB-T)

[Andy Walls]

On Fri, 2009-06-26 at 12:25 -0400, Steven Toth wrote:
> On 6/26/09 12:12 PM, Andy Walls wrote:
> > On Fri, 2009-06-26 at 10:37 -0400, Steven Toth wrote:
> >> On 6/25/09 7:15 AM, Andy Walls wrote:
> >>> On Thu, 2009-06-25 at 08:39 +0200, Hans Verkuil wrote:
>  On Thursday 25 June 2009 04:40:11 Andy Walls wrote:
> > On Tue, 2009-06-23 at 14:33 +0200, Hans Verkuil wrote:
> >>> On Tue, 2009-06-23 at 11:39 +0800, Terry Wu wrote:
> >>>
> >> There is already an s_gpio in the core ops. It would be simple to add a
> >> g_gpio as well if needed.
> > Hans,
> >
> > As you probably know
> >
> > int (*s_gpio)(v4l2_subdev *sd, u32 val);
> >
> > is a little too simple for initial setup of GPIO pins.  With the
> > collection of chips&   cores supported by cx25840 module, setting the
> > GPIO configuration also requires:
> >
> > direction: In or Out
> > multiplexed pins: GPIO or some other function
> >
> > I could tack on direction as an argument to s_gpio(), but I think that
> > is a bit inconvenient..  I'd rather have a
> >
> > int (*s_gpio_config)(v4l2_subdev *sd, u32 dir, u32 initval);
> >
> > but that leaves out the method for multiplexed pin/pad configuration.
> > Perhaps explicity setting a GPIO direction to OUT could be an implicit
> > indication that a multiplexed pin should be set to it's GPIO function.
> > However, that doesn't help for GPIO inputs that might have their pins
> > multiplexed with other functions.
> >
> > Here's an idea on how to specify multiplexed pin configuration
> > information and it could involve pins that multiplex functions other
> > than GPIO (the CX25843 is quite flexible in this regard):
> >
> > int (*s_pin_function)(v4l2_subdev *sd, u32 pin_id, u32 
> > function);
> >
> > The type checking ends up pretty weak, but I figured it was better than
> > a 'void *config' that had a subdev specific collection of pin
> > configuration information.
> >
> > Comments?
>  Hi Andy,
> 
>  Is there any driver that needs to setup the multiplex functions? If not, 
>  then
>  I would not add support for this at the moment.
> >>> Well, the group of GPIO pins in question for the CX23885 are all
> >>> multiplexed with other functions.  We could just initialize the CX23885
> >>> to have those pins set as GPIOs, but I have to check the cx23885 driver
> >>> to make sure that's safe.
> >> I'm in the process of rationalizing the GPIO handing inside the cx23885 
> >> driver,
> >> largely because of the cx23417. The current encoder driver has a hardcoded 
> >> GPIO
> >> used on GPIO 15. (legacy from the first HVR1800 implementation, which I'm
> >> cleaning up).
> >>
> >> I would add this to the conversation, the product I'm working on now 
> >> HVR1850
> >> needs to switch GPIO's on the fly to enable and disable parts (the ATSC 
> >> demod)
> >> via an encoder GPIO pin, depending on the cards operating mode. This isn't 
> >> a
> >> one-time operation, it needs to be dynamic.
> >>
> >> In effect we have to tri-state / float certain parts depending whether 
> >> we're in
> >> analog or digital mode, and depending on which tuner is being used.
> >
> >
> > Steve,
> >
> > The setting of GPIO's is (or will be) dynamic via the .s_gpio()
> > v4l2_subdev operation.
> >
> > Just to clarify some things above:
> >
> > 1. I assume setting of GPIO direction is not required to be done the
> > fly.  Is that correct?
> 
> No, incorrect. We have cases where we need to float the GPIO (HVR1300, 
> HVR1850) 
> we hack around this at the moment for various encoders and demods. Generally 
> we 
> need this functionality across a number of drivers.
> 
> >
> > 2. I assume switching of the internal routing of signals to chip pins is
> > not required to be done on the fly.  Is that correct?
> 
> No, incorrect. Same as above.
> 
> >
> >
> >
> > My plan was to add the necessary support to the cx25840 module for
> > setting up the cx23885 pin control multiplexers (subdev config time),
> > the GPIO 23-19 directions (subdev config time), and the GPIO 23-19
> > output states (dynamically as needed via subdev's .s_gpio call).
> 
> Ahh. I'm already working on this, the code is partially merged for the GPIO 
> overhaul (a few weeks ago). I'm currently on the next stage. You should see 
> some 
> todo comments in the current cx23885 driver.
> 
> Doesn't the cx23885 driver already configure the multiplexer pins at config 
> time 
> for the cx25840? Check the -cards.c for the HVR1800 entry.
> 
> >
> > Is this a bad plan for your needs?
> 
> It sounds like in some respects were working on the same thing, perhaps from 
> different approaches. Although my needs are not to modify the 25840 driver as 
> such, but have the cx23885 bridge be intelligent enough to be able to flip 
> all 
> 32 GPIO's regardless of whether they're in the a

Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-dm646x

[Hans Verkuil]

On Friday 26 June 2009 21:01:50 Hans Verkuil wrote:
> Hi Mauro,
> 
> Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-dm646x for the 
> following:
> 
> - ARM: DaVinci: DM646x Video: VPIF driver
> - ARM: DaVinci: DM646x Video: Add VPIF display driver
> - ARM: DaVinci: DM646x Video: Makefile and config files modifications for 
> Display
> - ARM: DaVinci: DM646x Video: Fix compile time warnings for mutex locking

Minor update: by request from Kevin I've removed the 'ARM: ' prefix in the
patch subject lines.

Regards,

Hans

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
--
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] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-dm646x

[Hans Verkuil]

Hi Mauro,

Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-dm646x for the 
following:

- ARM: DaVinci: DM646x Video: VPIF driver
- ARM: DaVinci: DM646x Video: Add VPIF display driver
- ARM: DaVinci: DM646x Video: Makefile and config files modifications for 
Display
- ARM: DaVinci: DM646x Video: Fix compile time warnings for mutex locking

Note that these four patches depend on the attached platform patch that
should be applied to the git tree first.

If possible, it would be great if this (like the vpfe capture driver) can be
merged for 2.6.31.

Thanks,

Hans

diffstat:
 b/linux/drivers/media/video/davinci/Makefile   |9
 b/linux/drivers/media/video/davinci/vpif.c |  234 ++
 b/linux/drivers/media/video/davinci/vpif.h |  632 +++
 b/linux/drivers/media/video/davinci/vpif_display.c | 1664 +
 b/linux/drivers/media/video/davinci/vpif_display.h |  175 ++
 linux/drivers/media/video/Kconfig  |   22
 linux/drivers/media/video/Makefile |2
 linux/drivers/media/video/davinci/vpif_display.c   |   31
 8 files changed, 2761 insertions(+), 8 deletions(-)

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
[PATCH] ARM: DaVinci: DM646x Video: Platform and board specific setup
From: Chaithrika U S 

Platform specific display device setup for DM646x EVM

Add platform device and resource structures. Also define a platform specific
clock setup function that can be accessed by the driver to configure the clock
and CPLD.

Signed-off-by: Chaithrika U S 
Signed-off-by: Manjunath Hadli 
Signed-off-by: Brijesh Jadav 
Signed-off-by: Kevin Hilman 

 arch/arm/mach-davinci/board-dm646x-evm.c|  122 +++
 arch/arm/mach-davinci/dm646x.c  |   62 ++
 arch/arm/mach-davinci/include/mach/dm646x.h |   24 +
 3 files changed, 208 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-davinci/board-dm646x-evm.c b/arch/arm/mach-davinci/board-dm646x-evm.c
index e17de63..eb4bd01 100644
--- a/arch/arm/mach-davinci/board-dm646x-evm.c
+++ b/arch/arm/mach-davinci/board-dm646x-evm.c
@@ -52,6 +52,19 @@
 #define DM646X_EVM_PHY_MASK		(0x2)
 #define DM646X_EVM_MDIO_FREQUENCY	(220) /* PHY bus frequency */
 
+#define VIDCLKCTL_OFFSET	(0x38)
+#define VSCLKDIS_OFFSET		(0x6c)
+
+#define VCH2CLK_MASK		(BIT_MASK(10) | BIT_MASK(9) | BIT_MASK(8))
+#define VCH2CLK_SYSCLK8		(BIT(9))
+#define VCH2CLK_AUXCLK		(BIT(9) | BIT(8))
+#define VCH3CLK_MASK		(BIT_MASK(14) | BIT_MASK(13) | BIT_MASK(12))
+#define VCH3CLK_SYSCLK8		(BIT(13))
+#define VCH3CLK_AUXCLK		(BIT(14) | BIT(13))
+
+#define VIDCH2CLK		(BIT(10))
+#define VIDCH3CLK		(BIT(11))
+
 static struct davinci_uart_config uart_config __initdata = {
 	.enabled_uarts = (1 << 0),
 };
@@ -207,6 +220,40 @@ static struct at24_platform_data eeprom_info = {
 	.context	= (void *)0x7f00,
 };
 
+static struct i2c_client *cpld_client;
+
+static int cpld_video_probe(struct i2c_client *client,
+			const struct i2c_device_id *id)
+{
+	cpld_client = client;
+	return 0;
+}
+
+static int __devexit cpld_video_remove(struct i2c_client *client)
+{
+	cpld_client = NULL;
+	return 0;
+}
+
+static const struct i2c_device_id cpld_video_id[] = {
+	{ "cpld_video", 0 },
+	{ }
+};
+
+static struct i2c_driver cpld_video_driver = {
+	.driver = {
+		.name	= "cpld_video",
+	},
+	.probe		= cpld_video_probe,
+	.remove		= cpld_video_remove,
+	.id_table	= cpld_video_id,
+};
+
+static void evm_init_cpld(void)
+{
+	i2c_add_driver(&cpld_video_driver);
+}
+
 static struct i2c_board_info __initdata i2c_info[] =  {
 	{
 		I2C_BOARD_INFO("24c256", 0x50),
@@ -216,6 +263,9 @@ static struct i2c_board_info __initdata i2c_info[] =  {
 		I2C_BOARD_INFO("pcf8574a", 0x38),
 		.platform_data	= &pcf_data,
 	},
+	{
+		I2C_BOARD_INFO("cpld_video", 0x3B),
+	},
 };
 
 static struct davinci_i2c_platform_data i2c_pdata = {
@@ -223,10 +273,81 @@ static struct davinci_i2c_platform_data i2c_pdata = {
 	.bus_delay  = 0 /* usec */,
 };
 
+static int set_vpif_clock(int mux_mode, int hd)
+{
+	int val = 0;
+	int err = 0;
+	unsigned int value;
+	void __iomem *base = IO_ADDRESS(DAVINCI_SYSTEM_MODULE_BASE);
+
+	/* disable the clock */
+	value = __raw_readl(base + VSCLKDIS_OFFSET);
+	value |= (VIDCH3CLK | VIDCH2CLK);
+	__raw_writel(value, base + VSCLKDIS_OFFSET);
+
+	val = i2c_smbus_read_byte(cpld_client);
+	if (val < 0)
+		return val;
+
+	if (mux_mode == 1)
+		val &= ~0x40;
+	else
+		val |= 0x40;
+
+	err = i2c_smbus_write_byte(cpld_client, val);
+	if (err)
+		return err;
+
+	value = __raw_readl(base + VIDCLKCTL_OFFSET);
+	value &= ~(VCH2CLK_MASK);
+	value &= ~(VCH3CLK_MASK);
+
+	if (hd >= 1)
+		value |= (VCH2CLK_SYSCLK8 | VCH3CLK_SYSCLK8);
+	else
+		value |= (VCH2CLK_AUXCLK | VCH3CLK_AUXCLK);
+
+	__raw_writel(value, base + VIDCLKCTL_OFFSET);
+
+	/* enable the clock */
+	value = __raw_readl(base + VSCLKDIS_OFFSET);
+	value &= ~(VIDCH3CLK | VIDCH2CLK);
+	__raw_writel(value, base + VSCLKDIS_OFFSET);
+
+	return 

Re: Bah! How do I change channels?

[Andy Walls]

On Fri, 2009-06-26 at 14:47 -0400, Devin Heitmueller wrote:
> On Fri, Jun 26, 2009 at 2:34 PM, Andy Walls wrote:
> > Hmm, that sure sounds like a V4L2 spec violation.  From the V4L2 close()
> > description:
> >
> > "Closes the device. Any I/O in progress is terminated and resources
> > associated with the file descriptor are freed. However data format
> > parameters, current input or output, control values or other properties
> > remain unchanged."
> >
> >
> > Regards,
> > Andy
> 
> I have no idea how that would work with power management.  It would
> mean that all the tuners and demod drivers which don't maintain state
> across powerdown would have to maintain some sort of cache of all of
> the programmed registers, and we would need to add some sort of
> "wakeup" callback which reprograms the device accordingly (currently
> we have a sleep callback but not a corresponding callback to wake the
> device back up).

That sounds about right.


> As a requirement, it might have been suitable for PCI cards where you
> don't care about power management (and therefore never power anything
> down), but I don't know how practical that is for USB or minicard
> devices where power management is critical because you're on a
> battery.

All I'm saying is that it is obviously the expected behavior, it the
specified behavior, and all the userland apps and scripts are written
with that behavior in mind.

The applications' expectation of that behavior is, of course, why we are
having this discussion.

Assuming arguendo, maintaing state in the face of power management is a
hard requirement on the driver; I'll still contend it's harder to change
the existing base of applications and user scripts.  Until the spec and
all the existing apps change, not adhering to the spec leads to user
confusion.

My $0.02

Regards,
Andy

> Devin


--
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: Bah! How do I change channels?

[Devin Heitmueller]

On Fri, Jun 26, 2009 at 2:34 PM, Andy Walls wrote:
> Hmm, that sure sounds like a V4L2 spec violation.  From the V4L2 close()
> description:
>
> "Closes the device. Any I/O in progress is terminated and resources
> associated with the file descriptor are freed. However data format
> parameters, current input or output, control values or other properties
> remain unchanged."
>
>
> Regards,
> Andy

I have no idea how that would work with power management.  It would
mean that all the tuners and demod drivers which don't maintain state
across powerdown would have to maintain some sort of cache of all of
the programmed registers, and we would need to add some sort of
"wakeup" callback which reprograms the device accordingly (currently
we have a sleep callback but not a corresponding callback to wake the
device back up).

As a requirement, it might have been suitable for PCI cards where you
don't care about power management (and therefore never power anything
down), but I don't know how practical that is for USB or minicard
devices where power management is critical because you're on a
battery.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Subject: [PATCH v3 1/4] ARM: DaVinci: DM646x Video: Platform and board specific setup

[Hans Verkuil]

On Friday 26 June 2009 20:25:42 Kevin Hilman wrote:
> Hans Verkuil  writes:
> 
> > On Monday 22 June 2009 10:14:30 chaithrika wrote:
> >> Kevin,
> >> 
> >> I think this patch has to be taken into DaVinci tree so that it
> >> can be submitted upstream. This patch has to be present in the Linux 
> >> tree for Hans to prepare a pull request for DM646x display driver 
> >> patches.
> >
> > What are the plans for this patch? Will Kevin take care of this? In that
> > case the v4l patches will have to wait until this patch is in Linus' git
> > tree. Alternatively, we can pull this in via the v4l-dvb git tree. I think
> > that is propably the easiest approach.
> 
> Hans, I'm ok if you pull this directly into v4l-dvb git.   But first, I
> there are a couple minor problems with this patch.  I'll reply
> to the original post.

OK. I'll wait for the fixed patch and I'll then ask Mauro to merge this
platform patch and the vpif display driver into the v4l-dvb git tree.

> Also, please let me know the url and branch so I can be sure to handle
> any problems with other davinci patces going upstream.

git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-next.git#master

> Is this tree part of linux-next?

Yes.

> I now have a 'for-next' branch 
> of DaVinci git which is included in linux-next so any potential
> conflicts will be found there as well.

Regards,

Hans

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
--
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] Subject: [PATCH v3 1/4] ARM: DaVinci: DM646x Video: Platform and board specific setup

[Kevin Hilman]

Kevin Hilman  writes:

> Chaithrika U S  writes:
>
>> Platform specific display device setup for DM646x EVM
>>
>> Add platform device and resource structures. Also define a platform specific
>> clock setup function that can be accessed by the driver to configure the 
>> clock
>> and CPLD.
>>
>> This patch is dependent on a patch submitted earlier, which adds
>> Pin Mux and clock definitions for Video on DM646x.
>>
>> Signed-off-by: Manjunath Hadli 
>> Signed-off-by: Brijesh Jadav 
>> Signed-off-by: Chaithrika U S 
>> ---
>> Applies to Davinci GIT tree
>
> Needs an update to apply to current linus or davinci git.

Please ignore this review, I see there was a newer version posted.
Will review shortly.

Sorry for the confusion.

Kevin

--
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: Bah! How do I change channels?

[Andy Walls]

On Fri, 2009-06-26 at 13:23 -0400, Devin Heitmueller wrote:
> On Fri, Jun 26, 2009 at 1:19 PM, Robert
> Krakora wrote:
> > I had ran into this before with the KWorld a few months back.
> > However, whatever problem existed that forced me to add
> > "no_poweroff=1" to modprobe.conf for the em28xx module has went away.
> > I have been able to use v4l-ctl or ivtv-tune without any problems to
> > tune analog channels over cable.
> 
> Well, bear in mind that if you run v4l-ctl *after* the program is
> streaming it should work.  However, if you run v4l-ctl and then try to
> stream I suspect it will fail.
> 
> If it's working, then perhaps I should take a look at the power
> management code in em28xx/xc2028 since I don't know why it would work


Hmm, that sure sounds like a V4L2 spec violation.  From the V4L2 close()
description:

"Closes the device. Any I/O in progress is terminated and resources
associated with the file descriptor are freed. However data format
parameters, current input or output, control values or other properties
remain unchanged."


Regards,
Andy

> (and perhaps the tuner is *not* being powered down like it should be).
> 
> Devin
> 

--
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] Subject: [PATCH v3 1/4] ARM: DaVinci: DM646x Video: Platform and board specific setup

[Kevin Hilman]

Chaithrika U S  writes:

> Platform specific display device setup for DM646x EVM
>
> Add platform device and resource structures. Also define a platform specific
> clock setup function that can be accessed by the driver to configure the clock
> and CPLD.
>
> This patch is dependent on a patch submitted earlier, which adds
> Pin Mux and clock definitions for Video on DM646x.
>
> Signed-off-by: Manjunath Hadli 
> Signed-off-by: Brijesh Jadav 
> Signed-off-by: Chaithrika U S 
> ---
> Applies to Davinci GIT tree

Needs an update to apply to current linus or davinci git.

Other comments below...

[...]

>  static __init void davinci_dm646x_evm_irq_init(void)
> diff --git a/arch/arm/mach-davinci/dm646x.c b/arch/arm/mach-davinci/dm646x.c
> index 3cd09c1..94e17a3 100644
> --- a/arch/arm/mach-davinci/dm646x.c
> +++ b/arch/arm/mach-davinci/dm646x.c

[...]

> +static u64 vpif_dma_mask = DMA_32BIT_MASK;

This usage is deprecated, it should be DMA_BIT_MASK(32) as all the
other uses in mach-davinci/*

[...]

> index 7afc613..9c3666c 100644
> --- a/arch/arm/mach-davinci/include/mach/dm646x.h
> +++ b/arch/arm/mach-davinci/include/mach/dm646x.h
> @@ -12,6 +12,7 @@
>  #define __ASM_ARCH_DM646X_H
>  
>  #include 
> +#include 

This part needs a refresh against current trees, but also please drop
this include, I don't see any users of i2c stuff in this file.

Kevin
--
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] Subject: [PATCH v3 1/4] ARM: DaVinci: DM646x Video: Platform and board specific setup

[Kevin Hilman]

Hans Verkuil  writes:

> On Monday 22 June 2009 10:14:30 chaithrika wrote:
>> Kevin,
>> 
>> I think this patch has to be taken into DaVinci tree so that it
>> can be submitted upstream. This patch has to be present in the Linux 
>> tree for Hans to prepare a pull request for DM646x display driver 
>> patches.
>
> What are the plans for this patch? Will Kevin take care of this? In that
> case the v4l patches will have to wait until this patch is in Linus' git
> tree. Alternatively, we can pull this in via the v4l-dvb git tree. I think
> that is propably the easiest approach.

Hans, I'm ok if you pull this directly into v4l-dvb git.   But first, I
there are a couple minor problems with this patch.  I'll reply
to the original post.

Also, please let me know the url and branch so I can be sure to handle
any problems with other davinci patces going upstream.

Is this tree part of linux-next?  I now have a 'for-next' branch
of DaVinci git which is included in linux-next so any potential
conflicts will be found there as well.

Thanks,

Kevin
--
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: Cropping with Hauppauge HVR-1900

[Andy Walls]

On Fri, 2009-06-26 at 11:33 -0500, Mike Isely wrote:
> On Fri, 26 Jun 2009, jmdk wrote:
> 
> > Hello,
> > 
> > I have a Hauppauge HVR-1900 which works fine with the pvrusb2 driver.
> > However because most TV channels now air with 16:9 content inside 4:3
> > images, I would like to crop out the top and bottom black bars before
> > encoding via the hardware MPEG2 encoder. I tried using the ctl_crop_top
> > and ctl_crop_height in  /sysfs as well as the --set-crop option of
> > v4l2-ctrl but only received error messages indicating a value out of range.
> > 
> > The card has a cx25843 which should support cropping. Does anyone know
> > how to get this feature to work ?
> > 
> > Thanks in advance for the help,
> 
> Unfortunately the cx25840 driver does not implement any cropping 
> capability and the recent change to the v4l-subdevice architecture 
> currently lacks the API entrypoints to make such a thing possible :-(
> 
> A pvrusb2 user a while back (it's in the pvrusb2 list archives) came up 
> with some patches to the cx25840 driver that implement cropping.  He 
> also generated corresponding patches for the pvrusb2 driver.  I merged 
> his pvrusb2 patches (which is why you see that support in the driver) 
> but not the cx25840 patches since I'm not an expert on that chip and I 
> don't have the ability to verify that the patches preserve correct 
> behavior for all the other devices that use the same chip.  I did pass 
> the cx25840 patches to Hans Verkuil and he tried them out at the time 
> and basically pronounced them "ok" but I think even he wasn't sure if it 
> was doing everything right.
> 
> That was a while ago and the cx25840 driver has undergone enough other 
> changes to make merging those patches a lot more difficult - plus the 
> v4l-subdevice stuff needs additional changes to support the extra 
> cropping API.

Not only that, doing cropping with the CX2584x chips and friends appears
to break VBI extraction in interaction with the CX2341x encoding engine.

A good bit of experimentation would need to be done to keep VBI working
with cropping.

Regards,
Andy

>   -Mike


--
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: Bah! How do I change channels?

[Robert Vincent Krakora]

Devin Heitmueller wrote:

On Fri, Jun 26, 2009 at 1:28 PM, Robert
Krakora wrote:
  

Yes, it is run after mplayer initially tunes it.  However, what is the
difference between mplayer tuning and v4l-ctl tuning?  They are both
submitting the same IOCTLs to the driver to accomplish the same end
result; or is mplayer probably submitting some additional IOCTLS to
"wake" the device?



The issue is that the tuner gets powered down when the v4l device is
closed.  So, when running mplayer first, and then v4l-ctl is being
used to tune, the file handle is held active by mplayer.  But if you
run v4l-ctl first, the v4l-ctl opens the handle, tunes successfully,
and then closes the handle (which powers down the tuner).  Then when
running mplayer (or whatever app), the handle gets reopened but the
tuner is not tuned to the target frequency that v4l-ctl set.

Devin

  
Aaahh yes...I think that you have told me that once before...sorry for 
making you repeat yourself...


However, with ivtv-tune I can issue a tune to a channel and then open 
mplayer with no tuning parameters and that channel is playing...


--
Rob Krakora
Senior Software Engineer
MessageNet Systems
101 East Carmel Dr. Suite 105
Carmel, IN 46032
(317)566-1677 Ext. 206
(317)663-0808 Fax
--
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: v4l2_subdev GPIO and Pin Control ops (Re: PxDVR3200 H LinuxTV v4l-dvb patch : Pull GPIO-20 low for DVB-T)

[Andy Walls]

On Fri, 2009-06-26 at 12:25 -0400, Steven Toth wrote:
> On 6/26/09 12:12 PM, Andy Walls wrote:

> >
> > My plan was to add the necessary support to the cx25840 module for
> > setting up the cx23885 pin control multiplexers (subdev config time),
> > the GPIO 23-19 directions (subdev config time), and the GPIO 23-19
> > output states (dynamically as needed via subdev's .s_gpio call).
> 
> Ahh. I'm already working on this, the code is partially merged for the GPIO 
> overhaul (a few weeks ago). I'm currently on the next stage. You should see 
> some 
> todo comments in the current cx23885 driver.
> 
> Doesn't the cx23885 driver already configure the multiplexer pins at config 
> time 
> for the cx25840? Check the -cards.c for the HVR1800 entry.

I'm not talking about the AFE Mux, I was refering to things like, as an
example, if an external pin could be configured as either GPIO[n] pin or
an audio sample clock.  The mux setting that handles that. 

Regards,
Andy

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ok more details: Re: bttv problem loading takes about several minutes

[Hans Verkuil]

On Friday 19 June 2009 14:47:33 Hans Verkuil wrote:
> On Friday 19 June 2009 13:49:37 Halim Sahin wrote:
> > Hi,
> > Ok I have tested
> > modprobe bttv audiodev=-1 card=34 tuner=24 gbuffers=16
> >
> > I am seeing again the delay.
> > More ideas?
> 
> Use more printk messages in the bttv_init_card2() function to try and narrow 
> down the exact function call that is causing the delay. I still have no 
> idea what it might be.
> 
> Regards,
> 
>   Hans
> 

Hi Halim,

Did you have time to try and narrow this down?

Regards,

Hans

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS

[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:Fri Jun 26 19:00:03 CEST 2009
path:http://www.linuxtv.org/hg/v4l-dvb
changeset:   12133:05e6c5c9bcb4
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-armv5: OK
linux-2.6.31-rc1-armv5: ERRORS
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-armv5-ixp: WARNINGS
linux-2.6.31-rc1-armv5-ixp: ERRORS
linux-2.6.28-armv5-omap2: WARNINGS
linux-2.6.29.1-armv5-omap2: WARNINGS
linux-2.6.30-armv5-omap2: WARNINGS
linux-2.6.31-rc1-armv5-omap2: ERRORS
linux-2.6.22.19-i686: WARNINGS
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-i686: WARNINGS
linux-2.6.31-rc1-i686: ERRORS
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-m32r: OK
linux-2.6.31-rc1-m32r: ERRORS
linux-2.6.30-mips: WARNINGS
linux-2.6.31-rc1-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-powerpc64: WARNINGS
linux-2.6.31-rc1-powerpc64: ERRORS
linux-2.6.22.19-x86_64: WARNINGS
linux-2.6.23.12-x86_64: WARNINGS
linux-2.6.24.7-x86_64: WARNINGS
linux-2.6.25.11-x86_64: WARNINGS
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-x86_64: WARNINGS
linux-2.6.31-rc1-x86_64: ERRORS
sparse (linux-2.6.30): OK
sparse (linux-2.6.31-rc1): 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: WARNINGS
linux-2.6.21.7-i686: WARNINGS
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: WARNINGS
linux-2.6.21.7-x86_64: WARNINGS

Detailed results are available here:

http://www.xs4all.nl/~hverkuil/logs/Friday.log

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Friday.tar.bz2

The V4L2 specification failed to build, but the last compiled spec 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: [PATCH] Subject: [PATCH v3 1/4] ARM: DaVinci: DM646x Video: Platform and board specific setup

[Hans Verkuil]

On Monday 22 June 2009 10:14:30 chaithrika wrote:
> Kevin,
> 
> I think this patch has to be taken into DaVinci tree so that it
> can be submitted upstream. This patch has to be present in the Linux 
> tree for Hans to prepare a pull request for DM646x display driver 
> patches.

What are the plans for this patch? Will Kevin take care of this? In that
case the v4l patches will have to wait until this patch is in Linus' git
tree. Alternatively, we can pull this in via the v4l-dvb git tree. I think
that is propably the easiest approach.

I just need to know who will do what so we don't do duplicate work.

Regards,

Hans

> 
> Regards,
> Chaithrika
> 
> > -Original Message-
> > From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
> > ow...@vger.kernel.org] On Behalf Of Chaithrika U S
> > Sent: Friday, May 08, 2009 6:56 PM
> > To: linux-media@vger.kernel.org
> > Cc: davinci-linux-open-sou...@linux.davincidsp.com; Chaithrika U S;
> > Manjunath Hadli; Brijesh Jadav
> > Subject: [PATCH] Subject: [PATCH v3 1/4] ARM: DaVinci: DM646x Video:
> > Platform and board specific setup
> > 
> > Platform specific display device setup for DM646x EVM
> > 
> > Add platform device and resource structures. Also define a platform
> > specific
> > clock setup function that can be accessed by the driver to configure
> > the clock
> > and CPLD.
> > 
> > This patch is dependent on a patch submitted earlier, which adds
> > Pin Mux and clock definitions for Video on DM646x.
> > 
> > Signed-off-by: Manjunath Hadli 
> > Signed-off-by: Brijesh Jadav 
> > Signed-off-by: Chaithrika U S 
> > ---
> > Applies to Davinci GIT tree
> > 
> >  arch/arm/mach-davinci/board-dm646x-evm.c|  122
> > +++
> >  arch/arm/mach-davinci/dm646x.c  |   63 ++
> >  arch/arm/mach-davinci/include/mach/dm646x.h |   25 ++
> >  3 files changed, 210 insertions(+), 0 deletions(-)
> > 



-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
--
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

cx18: MPC718 MT352 "firmware" load needs testing (Re: Acer aspire idea 500?)

[Andy Walls]

On Tue, 2009-06-23 at 17:49 -0400, Andy Walls wrote:
> On Tue, 2009-06-23 at 16:59 +0100, Steve Firth wrote:
> > Just another quick update. 
> > 
> > I've now reinstalled the 2nd tuner card back into the ACER 500, and I
> > can confirm  that the patched drivers for the Yuan MPC718 work fine on
> > DVB-T both inside and outside of mythtv. 
> 
> Glad to hear it's working. 

> > I don't know how your release procedures work or if further testing or
> > trials are needed but if you require me to do any e.g. regression
> > testing  just let me know
> 
> I'd like to get 2 more things done:
> 
> 1. Get the EEPROM dump working for the MPC-718 working properly.  It
> will hopefully be useful for identifying variants of the card in the
> future.
> 
> 2. Change the function to init the mt352 DVB-T demodulator to read in a
> "firmware" file.  The init sequence in my repository was extracted from
> the windows driver.  I strongly believe I cannot have that committed to
> the Linux kernel, even though it is only 46 bytes from a 143 kilobyte
> file.  I will also have to write an extraction tool to pull the sequence
> out of the windows binary and put instructions on a wiki page.
> 
> 
> I will need you to test both of these changes when I'm ready.

Steve,

To ensure MPC-718 DVB-T support can be included in the Linux kernel, I
have checked in changes to my MPC-718 development repo to:

1. extract a "firmware" sequence from the MPC-718 Windows driver
2. load that firmware in the cx18 driver to help init the MT352 on the
MPC-718

See

http://linuxtv.org/hg/~awalls/cx18-mpc718



Please test it when you can

1. Run the get_dvb_firmware script with my changes from that repo and
install the new firmware file:

$ cd cx18-mpc718
$ chmod u+x linux/Documentation/dvb/get_dvb_firmware
$ linux/Documentation/dvb/get_dvb_firmware mpc718
$ sudo cp dvb-cx18-mpc718-mt352.fw /lib/firmware   (or wherever for 
your distro)

2. Compile, install, and test the updated cx18 driver from that repo.


Once we know it works for you, I can build a cleaned up patch set and
ask for it to be pulled to the main v4l-dvb repo.

I'd still like to fix (and have you test) the EEPROM dump after we know
the DVB-T changes are good.


Regards,
Andy


--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PARTIALLY SOLVED] Can't use my Pinnacle PCTV HD Pro stick - what am I doing wrong?

[Devin Heitmueller]

On Fri, Jun 26, 2009 at 1:50 PM, Hans Verkuil wrote:
> On Thursday 25 June 2009 20:25:31 Devin Heitmueller wrote:
>> Hans,
>>
>> I just spoke with mkrufky, and he confirmed the issue does occur with
>> the HVR-950.  However, the em28xx driver does not do a printk() when
>> the subdev registration fails (I will submit a patch to fix that).
>>
>> Please let me know if you have any further question.
>>
>> Thanks for your assistance,
>>
>> Devin
>>
>
> Fixed in my http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-misc tree.
>
> A pull request for this has already been posted, so it should be merged soon
> I hope.
>
> It was a trivial change: originally the new i2c API would be used for kernels
> 2.6.22 and up, until it was discovered that there was a serious bug in the i2c
> core that wasn't fixed until 2.6.26. So I changed it to kernel 2.6.26.
>
> Unfortunately, the em28xx driver was still using 2.6.22 as the cut-off point,
> preventing i2c drivers from being initialized. So em28xx was broken for
> kernels 2.6.22-2.6.25.

Ok, I will submit a comparable fix for au0828.  I guess maybe it makes
sense also to audit all the bridges where we set the .class field to
ensure they all are for 2.6.26.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PARTIALLY SOLVED] Can't use my Pinnacle PCTV HD Pro stick - what am I doing wrong?

[Hans Verkuil]

On Thursday 25 June 2009 20:25:31 Devin Heitmueller wrote:
> Hans,
> 
> I just spoke with mkrufky, and he confirmed the issue does occur with
> the HVR-950.  However, the em28xx driver does not do a printk() when
> the subdev registration fails (I will submit a patch to fix that).
> 
> Please let me know if you have any further question.
> 
> Thanks for your assistance,
> 
> Devin
> 

Fixed in my http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-misc tree.

A pull request for this has already been posted, so it should be merged soon
I hope.

It was a trivial change: originally the new i2c API would be used for kernels
2.6.22 and up, until it was discovered that there was a serious bug in the i2c
core that wasn't fixed until 2.6.26. So I changed it to kernel 2.6.26.

Unfortunately, the em28xx driver was still using 2.6.22 as the cut-off point,
preventing i2c drivers from being initialized. So em28xx was broken for
kernels 2.6.22-2.6.25.

Regards,

Hans

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
--
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: Cropping with Hauppauge HVR-1900

[Hans Verkuil]

On Friday 26 June 2009 18:33:11 Mike Isely wrote:
> On Fri, 26 Jun 2009, jmdk wrote:
> 
> > Hello,
> > 
> > I have a Hauppauge HVR-1900 which works fine with the pvrusb2 driver.
> > However because most TV channels now air with 16:9 content inside 4:3
> > images, I would like to crop out the top and bottom black bars before
> > encoding via the hardware MPEG2 encoder. I tried using the ctl_crop_top
> > and ctl_crop_height in  /sysfs as well as the --set-crop option of
> > v4l2-ctrl but only received error messages indicating a value out of range.
> > 
> > The card has a cx25843 which should support cropping. Does anyone know
> > how to get this feature to work ?
> > 
> > Thanks in advance for the help,
> 
> Unfortunately the cx25840 driver does not implement any cropping 
> capability and the recent change to the v4l-subdevice architecture 
> currently lacks the API entrypoints to make such a thing possible :-(
> 
> A pvrusb2 user a while back (it's in the pvrusb2 list archives) came up 
> with some patches to the cx25840 driver that implement cropping.  He 
> also generated corresponding patches for the pvrusb2 driver.  I merged 
> his pvrusb2 patches (which is why you see that support in the driver) 
> but not the cx25840 patches since I'm not an expert on that chip and I 
> don't have the ability to verify that the patches preserve correct 
> behavior for all the other devices that use the same chip.  I did pass 
> the cx25840 patches to Hans Verkuil and he tried them out at the time 
> and basically pronounced them "ok" but I think even he wasn't sure if it 
> was doing everything right.
> 
> That was a while ago and the cx25840 driver has undergone enough other 
> changes to make merging those patches a lot more difficult - plus the 
> v4l-subdevice stuff needs additional changes to support the extra 
> cropping API.

Just a quick heads-up: the cropping API will be added to the v4l2_subdev API
soon. A pull request from Guennadi that does this is already posted to the
list.

Regards,

Hans

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
--
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: Bah! How do I change channels?

[Robert Krakora]

On Fri, Jun 26, 2009 at 9:42 AM, Devin
Heitmueller wrote:
> On Fri, Jun 26, 2009 at 7:50 AM, Andy Walls wrote:
>> I use either v4l2-ctl or ivtv-tune
>>
>> $ ivtv-tune -d /dev/video0 -t us-bcast -c 3
>> /dev/video0: 61.250 MHz
>>
>> $ v4l2-ctl -d /dev/video0 -f 61.250
>> Frequency set to 980 (61.25 MHz)
>>
>>
>> Regards,
>> Andy
>
> Hello Andy,
>
> I had sent George some email off-list with basically the same
> commands.  I think what might be happening here is the tuner gets
> powered down when not in use, so I think it might be powered down
> between the v4l-ctl command and the running of the other application.
>
> I have sent him a series of commands to try where he modprobes the
> xc3028 driver with "no_poweroff=1", and we will see if that starts
> working.
>
> Devin
>
> --
> Devin J. Heitmueller - Kernel Labs
> http://www.kernellabs.com
>
> --
> video4linux-list mailing list
> Unsubscribe mailto:video4linux-list-requ...@redhat.com?subject=unsubscribe
> https://www.redhat.com/mailman/listinfo/video4linux-list
>
>

I had ran into this before with the KWorld a few months back.
However, whatever problem existed that forced me to add
"no_poweroff=1" to modprobe.conf for the em28xx module has went away.
I have been able to use v4l-ctl or ivtv-tune without any problems to
tune analog channels over cable.

-- 
Rob Krakora
Senior Software Engineer
MessageNet Systems
101 East Carmel Dr. Suite 105
Carmel, IN 46032
(317)566-1677 Ext. 206
(317)663-0808 Fax
--
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: Bah! How do I change channels?

[Devin Heitmueller]

On Fri, Jun 26, 2009 at 1:28 PM, Robert
Krakora wrote:
> Yes, it is run after mplayer initially tunes it.  However, what is the
> difference between mplayer tuning and v4l-ctl tuning?  They are both
> submitting the same IOCTLs to the driver to accomplish the same end
> result; or is mplayer probably submitting some additional IOCTLS to
> "wake" the device?

The issue is that the tuner gets powered down when the v4l device is
closed.  So, when running mplayer first, and then v4l-ctl is being
used to tune, the file handle is held active by mplayer.  But if you
run v4l-ctl first, the v4l-ctl opens the handle, tunes successfully,
and then closes the handle (which powers down the tuner).  Then when
running mplayer (or whatever app), the handle gets reopened but the
tuner is not tuned to the target frequency that v4l-ctl set.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Bah! How do I change channels?

[Robert Krakora]

On Fri, Jun 26, 2009 at 1:23 PM, Devin
Heitmueller wrote:
> On Fri, Jun 26, 2009 at 1:19 PM, Robert
> Krakora wrote:
>> I had ran into this before with the KWorld a few months back.
>> However, whatever problem existed that forced me to add
>> "no_poweroff=1" to modprobe.conf for the em28xx module has went away.
>> I have been able to use v4l-ctl or ivtv-tune without any problems to
>> tune analog channels over cable.
>
> Well, bear in mind that if you run v4l-ctl *after* the program is
> streaming it should work.  However, if you run v4l-ctl and then try to
> stream I suspect it will fail.
>
> If it's working, then perhaps I should take a look at the power
> management code in em28xx/xc2028 since I don't know why it would work
> (and perhaps the tuner is *not* being powered down like it should be).
>
> Devin
>
> --
> Devin J. Heitmueller - Kernel Labs
> http://www.kernellabs.com
>
>

Devin:

Yes, it is run after mplayer initially tunes it.  However, what is the
difference between mplayer tuning and v4l-ctl tuning?  They are both
submitting the same IOCTLs to the driver to accomplish the same end
result; or is mplayer probably submitting some additional IOCTLS to
"wake" the device?

Best Regards,

-- 
Rob Krakora
Senior Software Engineer
MessageNet Systems
101 East Carmel Dr. Suite 105
Carmel, IN 46032
(317)566-1677 Ext. 206
(317)663-0808 Fax
--
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: Bah! How do I change channels?

[Devin Heitmueller]

On Fri, Jun 26, 2009 at 1:19 PM, Robert
Krakora wrote:
> I had ran into this before with the KWorld a few months back.
> However, whatever problem existed that forced me to add
> "no_poweroff=1" to modprobe.conf for the em28xx module has went away.
> I have been able to use v4l-ctl or ivtv-tune without any problems to
> tune analog channels over cable.

Well, bear in mind that if you run v4l-ctl *after* the program is
streaming it should work.  However, if you run v4l-ctl and then try to
stream I suspect it will fail.

If it's working, then perhaps I should take a look at the power
management code in em28xx/xc2028 since I don't know why it would work
(and perhaps the tuner is *not* being powered down like it should be).

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-subdev2

[Karicheri, Muralidharan]

Hans,

I see it. Thanks.

Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
Phone : 301-515-3736
email: m-kariche...@ti.com

>-Original Message-
>From: Hans Verkuil [mailto:hverk...@xs4all.nl]
>Sent: Friday, June 26, 2009 2:53 AM
>To: Karicheri, Muralidharan
>Cc: linux-media@vger.kernel.org; Mauro Carvalho Chehab
>Subject: Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-subdev2
>
>On Friday 26 June 2009 08:17:05 Hans Verkuil wrote:
>> On Thursday 25 June 2009 20:18:06 Karicheri, Muralidharan wrote:
>> > Hans,
>> >
>> > I have tried to pull the latest from
>   git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git
>> >
>> > I can't see it part of this. Which GIT tree can I use to see the sub
>dev api changes or latest that went into 2.6.31? Is vpfe capture part of
>2.6.31?
>>
>> Ah, it is not yet pulled into the git tree. Mauro did send a pull request
>for
>> this to Linus, though. So I hope it will appear soon.
>
>Oops, I didn't look carefully enough. These API changes *are* merged in
>2.6.31.
>
>I'm using Linus' git tree.
>
>Regards,
>
>   Hans
>
>>
>> Regards,
>>
>>  Hans
>>
>> >
>> > Thanks.
>> >
>> > Murali Karicheri
>> > Software Design Engineer
>> > Texas Instruments Inc.
>> > Germantown, MD 20874
>> > email: m-kariche...@ti.com
>> >
>> > >-Original Message-
>> > >From: Hans Verkuil [mailto:hverk...@xs4all.nl]
>> > >Sent: Thursday, June 25, 2009 11:18 AM
>> > >To: Karicheri, Muralidharan
>> > >Cc: linux-media@vger.kernel.org; Mauro Carvalho Chehab
>> > >Subject: RE: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-
>subdev2
>> > >
>> > >
>> > >> Hi, Mauro,
>> > >>
>> > >> I am using the v4l2_i2c_new_subdev_board() API for the next set of
>vpfe
>> > >> capture driver patches. So when do you think this will be merged?
>> > >
>> > >This has already been merged and is also in the 2.6.31 git tree.
>> > >
>> > >I'm very pleased that this is in as that will make life easier for
>several
>> > >embedded system developments.
>> > >
>> > >Regards,
>> > >
>> > >Hans
>> > >
>> > >>
>> > >> Murali Karicheri
>> > >> Software Design Engineer
>> > >> Texas Instruments Inc.
>> > >> Germantown, MD 20874
>> > >> email: m-kariche...@ti.com
>> > >>
>> > >>>-Original Message-
>> > >>>From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
>> > >>>ow...@vger.kernel.org] On Behalf Of Hans Verkuil
>> > >>>Sent: Saturday, June 20, 2009 9:11 AM
>> > >>>To: linux-media@vger.kernel.org
>> > >>>Cc: Mauro Carvalho Chehab
>> > >>>Subject: Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-
>subdev2
>> > >>>
>> > >>>On Tuesday 09 June 2009 22:40:35 Hans Verkuil wrote:
>> >  Hi Mauro,
>> > 
>> >  Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-
>subdev2
>> >  for
>> >  the following:
>> > 
>> >  - v4l2: add new s_config subdev ops and
>v4l2_i2c_new_subdev_cfg/board
>> >  calls - v4l2-device: fix incorrect kernel check
>> >  - v4l-compat: add I2C_ADDRS macro.
>> >  - v4l2: update framework documentation.
>> >  - v4l2-subdev: remove unnecessary check
>> > 
>> >  This time I've only added new functions and left the existing ones
>in
>> >  place. I did add a bit of code to the existing
>> >  v4l2_i2c_new_(probed_)subdev functions to call the new s_config op
>if
>> >  it
>> >  is available. Existing subdev drivers never set this new op, so
>this
>> >  code
>> >  will not effect current behavior. But for new drivers that do set
>> >  s_config it is important that it is called no matter what flavor
>of
>> >  these
>> >  functions is used.
>> > 
>> >  At the end of the 2.6.31 cycle we can replace the current
>> >  v4l2_i2c_new_(probed_)subdev calls with the new one I had in my
>earlier
>> >  patches.
>> > >>>
>> > >>>Hi Mauro,
>> > >>>
>> > >>>I've posted these changes as an RFC more than a week ago, but since
>there
>> > >>>were no comments I hope you can pull from this tree for 2.6.31.
>> > >>>
>> > >>>I would really, really like to get this into 2.6.31. It will help
>anyone
>> > >>>who
>> > >>>is working with subdevs on embedded platforms.
>> > >>>
>> > >>>Regards,
>> > >>>
>> > >>>Hans
>> > >>>
>> > 
>> >  Thanks,
>> > 
>> >  Hans
>> > 
>> >  diffstat:
>> >   linux/Documentation/video4linux/v4l2-framework.txt |   24 +++
>> >   linux/drivers/media/video/v4l2-common.c|  166
>> >  +
>> >   linux/drivers/media/video/v4l2-device.c|2
>> >   linux/include/media/v4l2-common.h  |   18 ++
>> >   linux/include/media/v4l2-subdev.h  |9 -
>> >   v4l/compat.h   |6
>> >   6 files changed, 222 insertions(+), 3 deletions(-)
>> > >>>
>> > >>>
>> > >>>
>> > >>>--
>> > >>>Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
>> 

Re: Cropping with Hauppauge HVR-1900

[Mike Isely]

On Fri, 26 Jun 2009, jmdk wrote:

> Hello,
> 
> I have a Hauppauge HVR-1900 which works fine with the pvrusb2 driver.
> However because most TV channels now air with 16:9 content inside 4:3
> images, I would like to crop out the top and bottom black bars before
> encoding via the hardware MPEG2 encoder. I tried using the ctl_crop_top
> and ctl_crop_height in  /sysfs as well as the --set-crop option of
> v4l2-ctrl but only received error messages indicating a value out of range.
> 
> The card has a cx25843 which should support cropping. Does anyone know
> how to get this feature to work ?
> 
> Thanks in advance for the help,

Unfortunately the cx25840 driver does not implement any cropping 
capability and the recent change to the v4l-subdevice architecture 
currently lacks the API entrypoints to make such a thing possible :-(

A pvrusb2 user a while back (it's in the pvrusb2 list archives) came up 
with some patches to the cx25840 driver that implement cropping.  He 
also generated corresponding patches for the pvrusb2 driver.  I merged 
his pvrusb2 patches (which is why you see that support in the driver) 
but not the cx25840 patches since I'm not an expert on that chip and I 
don't have the ability to verify that the patches preserve correct 
behavior for all the other devices that use the same chip.  I did pass 
the cx25840 patches to Hans Verkuil and he tried them out at the time 
and basically pronounced them "ok" but I think even he wasn't sure if it 
was doing everything right.

That was a while ago and the cx25840 driver has undergone enough other 
changes to make merging those patches a lot more difficult - plus the 
v4l-subdevice stuff needs additional changes to support the extra 
cropping API.

  -Mike


-- 

Mike Isely
isely @ isely (dot) net
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: v4l2_subdev GPIO and Pin Control ops (Re: PxDVR3200 H LinuxTV v4l-dvb patch : Pull GPIO-20 low for DVB-T)

[Steven Toth]

On 6/26/09 12:12 PM, Andy Walls wrote:

On Fri, 2009-06-26 at 10:37 -0400, Steven Toth wrote:

On 6/25/09 7:15 AM, Andy Walls wrote:

On Thu, 2009-06-25 at 08:39 +0200, Hans Verkuil wrote:

On Thursday 25 June 2009 04:40:11 Andy Walls wrote:

On Tue, 2009-06-23 at 14:33 +0200, Hans Verkuil wrote:

On Tue, 2009-06-23 at 11:39 +0800, Terry Wu wrote:


There is already an s_gpio in the core ops. It would be simple to add a
g_gpio as well if needed.

Hans,

As you probably know

int (*s_gpio)(v4l2_subdev *sd, u32 val);

is a little too simple for initial setup of GPIO pins.  With the
collection of chips&   cores supported by cx25840 module, setting the
GPIO configuration also requires:

direction: In or Out
multiplexed pins: GPIO or some other function

I could tack on direction as an argument to s_gpio(), but I think that
is a bit inconvenient..  I'd rather have a

int (*s_gpio_config)(v4l2_subdev *sd, u32 dir, u32 initval);

but that leaves out the method for multiplexed pin/pad configuration.
Perhaps explicity setting a GPIO direction to OUT could be an implicit
indication that a multiplexed pin should be set to it's GPIO function.
However, that doesn't help for GPIO inputs that might have their pins
multiplexed with other functions.

Here's an idea on how to specify multiplexed pin configuration
information and it could involve pins that multiplex functions other
than GPIO (the CX25843 is quite flexible in this regard):

int (*s_pin_function)(v4l2_subdev *sd, u32 pin_id, u32 function);

The type checking ends up pretty weak, but I figured it was better than
a 'void *config' that had a subdev specific collection of pin
configuration information.

Comments?

Hi Andy,

Is there any driver that needs to setup the multiplex functions? If not, then
I would not add support for this at the moment.

Well, the group of GPIO pins in question for the CX23885 are all
multiplexed with other functions.  We could just initialize the CX23885
to have those pins set as GPIOs, but I have to check the cx23885 driver
to make sure that's safe.

I'm in the process of rationalizing the GPIO handing inside the cx23885 driver,
largely because of the cx23417. The current encoder driver has a hardcoded GPIO
used on GPIO 15. (legacy from the first HVR1800 implementation, which I'm
cleaning up).

I would add this to the conversation, the product I'm working on now HVR1850
needs to switch GPIO's on the fly to enable and disable parts (the ATSC demod)
via an encoder GPIO pin, depending on the cards operating mode. This isn't a
one-time operation, it needs to be dynamic.

In effect we have to tri-state / float certain parts depending whether we're in
analog or digital mode, and depending on which tuner is being used.



Steve,

The setting of GPIO's is (or will be) dynamic via the .s_gpio()
v4l2_subdev operation.

Just to clarify some things above:

1. I assume setting of GPIO direction is not required to be done the
fly.  Is that correct?


No, incorrect. We have cases where we need to float the GPIO (HVR1300, HVR1850) 
we hack around this at the moment for various encoders and demods. Generally we 
need this functionality across a number of drivers.




2. I assume switching of the internal routing of signals to chip pins is
not required to be done on the fly.  Is that correct?


No, incorrect. Same as above.





My plan was to add the necessary support to the cx25840 module for
setting up the cx23885 pin control multiplexers (subdev config time),
the GPIO 23-19 directions (subdev config time), and the GPIO 23-19
output states (dynamically as needed via subdev's .s_gpio call).


Ahh. I'm already working on this, the code is partially merged for the GPIO 
overhaul (a few weeks ago). I'm currently on the next stage. You should see some 
todo comments in the current cx23885 driver.


Doesn't the cx23885 driver already configure the multiplexer pins at config time 
for the cx25840? Check the -cards.c for the HVR1800 entry.




Is this a bad plan for your needs?


It sounds like in some respects were working on the same thing, perhaps from 
different approaches. Although my needs are not to modify the 25840 driver as 
such, but have the cx23885 bridge be intelligent enough to be able to flip all 
32 GPIO's regardless of whether they're in the avcore (embedded 25840), or the 
encoder or on the bridge itself.


If I'm late to the party and I've missed something obvious then I apologize in 
advance.


--
Steven Toth - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: v4l2_subdev GPIO and Pin Control ops (Re: PxDVR3200 H LinuxTV v4l-dvb patch : Pull GPIO-20 low for DVB-T)

[Andy Walls]

On Fri, 2009-06-26 at 10:37 -0400, Steven Toth wrote:
> On 6/25/09 7:15 AM, Andy Walls wrote:
> > On Thu, 2009-06-25 at 08:39 +0200, Hans Verkuil wrote:
> >> On Thursday 25 June 2009 04:40:11 Andy Walls wrote:
> >>> On Tue, 2009-06-23 at 14:33 +0200, Hans Verkuil wrote:
> > On Tue, 2009-06-23 at 11:39 +0800, Terry Wu wrote:
> >
>  There is already an s_gpio in the core ops. It would be simple to add a
>  g_gpio as well if needed.
> >>> Hans,
> >>>
> >>> As you probably know
> >>>
> >>>   int (*s_gpio)(v4l2_subdev *sd, u32 val);
> >>>
> >>> is a little too simple for initial setup of GPIO pins.  With the
> >>> collection of chips&  cores supported by cx25840 module, setting the
> >>> GPIO configuration also requires:
> >>>
> >>>   direction: In or Out
> >>>   multiplexed pins: GPIO or some other function
> >>>
> >>> I could tack on direction as an argument to s_gpio(), but I think that
> >>> is a bit inconvenient..  I'd rather have a
> >>>
> >>>   int (*s_gpio_config)(v4l2_subdev *sd, u32 dir, u32 initval);
> >>>
> >>> but that leaves out the method for multiplexed pin/pad configuration.
> >>> Perhaps explicity setting a GPIO direction to OUT could be an implicit
> >>> indication that a multiplexed pin should be set to it's GPIO function.
> >>> However, that doesn't help for GPIO inputs that might have their pins
> >>> multiplexed with other functions.
> >>>
> >>> Here's an idea on how to specify multiplexed pin configuration
> >>> information and it could involve pins that multiplex functions other
> >>> than GPIO (the CX25843 is quite flexible in this regard):
> >>>
> >>>   int (*s_pin_function)(v4l2_subdev *sd, u32 pin_id, u32 function);
> >>>
> >>> The type checking ends up pretty weak, but I figured it was better than
> >>> a 'void *config' that had a subdev specific collection of pin
> >>> configuration information.
> >>>
> >>> Comments?
> >> Hi Andy,
> >>
> >> Is there any driver that needs to setup the multiplex functions? If not, 
> >> then
> >> I would not add support for this at the moment.
> >
> > Well, the group of GPIO pins in question for the CX23885 are all
> > multiplexed with other functions.  We could just initialize the CX23885
> > to have those pins set as GPIOs, but I have to check the cx23885 driver
> > to make sure that's safe.
> 
> I'm in the process of rationalizing the GPIO handing inside the cx23885 
> driver, 
> largely because of the cx23417. The current encoder driver has a hardcoded 
> GPIO 
> used on GPIO 15. (legacy from the first HVR1800 implementation, which I'm 
> cleaning up).
> 
> I would add this to the conversation, the product I'm working on now HVR1850 
> needs to switch GPIO's on the fly to enable and disable parts (the ATSC 
> demod) 
> via an encoder GPIO pin, depending on the cards operating mode. This isn't a 
> one-time operation, it needs to be dynamic.
> 
> In effect we have to tri-state / float certain parts depending whether we're 
> in 
> analog or digital mode, and depending on which tuner is being used.


Steve,

The setting of GPIO's is (or will be) dynamic via the .s_gpio()
v4l2_subdev operation.

Just to clarify some things above:

1. I assume setting of GPIO direction is not required to be done the
fly.  Is that correct?

2. I assume switching of the internal routing of signals to chip pins is
not required to be done on the fly.  Is that correct?



My plan was to add the necessary support to the cx25840 module for
setting up the cx23885 pin control multiplexers (subdev config time),
the GPIO 23-19 directions (subdev config time), and the GPIO 23-19
output states (dynamically as needed via subdev's .s_gpio call).

Is this a bad plan for your needs?

Regards,
Andy

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH] mt9t031 - migration to sub device frame work

[Guennadi Liakhovetski]

On Fri, 26 Jun 2009, Karicheri, Muralidharan wrote:

> I see your point. I think what we could do is to keep this patch in our 
> internal tree until you complete fixing the cropping/scaling issue. I 
> will merge your future patches to this version. When you are ready to do 
> the migration to sub device frame work, we could review this driver 
> again and merge. Could you agree with this plan?

Yep, perfect.

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

RE: [PATCH] mt9t031 - migration to sub device frame work

[Karicheri, Muralidharan]

Guennadi,


>
>I thought you would be doing the latter part - v4l2-subdev conversion.
>Which is good. But, you wrote:
>
>> This patch migrates mt9t031 driver from SOC Camera interface to
>> sub device interface. This is sent to get a feedback about the
>> changes done since I am not sure if some of the functionality
>> that is removed works okay with SOC Camera bridge driver or
>> not. Following functions are to be discussed and added as needed:-
>
>which I understand like you probably have broken soc-camera functionality
>of this driver, which I cannot accept. Yes, I want to move forward to
>v4l2-subdev, but - we cannot introduce regressions!
>
That is why the review is done with your help to make sure there are no gaps.


>> I don't see a point in duplicating the work already done by me.
>
>I don't like duplicating work either, and I don't think we're doing that.
>As I said, what I am doing at the moment is fixing all soc-camera drivers
>for proper cropping / scaling. In principle I welcome your help with the
>v4l2-subdev migration, but currently it conflicts with my above work, and
>it introduces a regression.
>
I see your point. I think what we could do is to keep this patch in our 
internal tree until you complete fixing the cropping/scaling issue. I will 
merge your future patches to this version. When you are ready to do the 
migration to sub device frame work, we could review this driver again and 
merge. Could you agree with this plan?

>> So could you
>> please work with me by reviewing this patch and then use this for your
>> work? I will take care of merging any updates to this based on your
>> patches (like the crop one)
>
>Unfortunately, I do not think I'll be able to review your patch today,
>will have to wait until the next week, sorry.
>
Any way there is no hurry since it will stay in our internal tree for the time 
being. So please review when you get a chance. I will post a patch based on 
Han's comment. 
>> >> > >>  {
>> >> > >> -s32 data = i2c_smbus_read_word_data(client, reg);
>> >> > >> +s32 data;
>> >> > >> +
>> >> > >> +data = i2c_smbus_read_word_data(client, reg);
>> >> > >>  return data < 0 ? data : swab16(data);
>> >
>> >Looks like it will take me considerable time to review the patch and NAK
>> >all changes like this one...
>> >
>> I didn't get it. Are you referring to the 3 lines of code above? For
>> this patch this code change is unnecessary, but I have to do this if sd
>> is used as argument to this function as suggested by Hans.
>
>Exactly. It is _not_ needed for this patch. Only if we _do_ accept Hans'
>suggestion to use the subdev pointer all the way down to register-access
>functions, _then_ you might need to modify this code.
>
>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

RE: [PATCH] mt9t031 - migration to sub device frame work

[Guennadi Liakhovetski]

On Fri, 26 Jun 2009, Karicheri, Muralidharan wrote:

> >
> >). I started by converting mx3-camera and mt9t031, and I shall upload an
> >incomplete patch, converting only these drivers to my "testing" area,
> >while I shall start converting the rest of the drivers... So, it is
> >advisable to wait for that patch to appear and base any future (including
> >this one) work on it, because it is a pretty big change and merging would
> >be non-trivial.
> >
> I thought you wanted to offload some of the migration work and I had 
> volunteered to do this since it is of interest to vpfe-capture.

Yes, but these are two unrelated (at least in theory) changes: fixing 
cropping / scaling behaviour of _all_ aoc-camera drivers and the 
soc-camera framework core, and removing the remaining bonds between 
subdevice drivers and the soc-camera framework and replacing it properly 
with v4l2-subdev API.

I thought you would be doing the latter part - v4l2-subdev conversion. 
Which is good. But, you wrote:

> This patch migrates mt9t031 driver from SOC Camera interface to
> sub device interface. This is sent to get a feedback about the
> changes done since I am not sure if some of the functionality
> that is removed works okay with SOC Camera bridge driver or
> not. Following functions are to be discussed and added as needed:-

which I understand like you probably have broken soc-camera functionality 
of this driver, which I cannot accept. Yes, I want to move forward to 
v4l2-subdev, but - we cannot introduce regressions!

> I don't see a point in duplicating the work already done by me.

I don't like duplicating work either, and I don't think we're doing that. 
As I said, what I am doing at the moment is fixing all soc-camera drivers 
for proper cropping / scaling. In principle I welcome your help with the 
v4l2-subdev migration, but currently it conflicts with my above work, and 
it introduces a regression.

> So could you 
> please work with me by reviewing this patch and then use this for your 
> work? I will take care of merging any updates to this based on your 
> patches (like the crop one)

Unfortunately, I do not think I'll be able to review your patch today, 
will have to wait until the next week, sorry.

> >> > >>  {
> >> > >> -s32 data = i2c_smbus_read_word_data(client, reg);
> >> > >> +s32 data;
> >> > >> +
> >> > >> +data = i2c_smbus_read_word_data(client, reg);
> >> > >>  return data < 0 ? data : swab16(data);
> >
> >Looks like it will take me considerable time to review the patch and NAK
> >all changes like this one...
> >
> I didn't get it. Are you referring to the 3 lines of code above? For 
> this patch this code change is unnecessary, but I have to do this if sd 
> is used as argument to this function as suggested by Hans.

Exactly. It is _not_ needed for this patch. Only if we _do_ accept Hans' 
suggestion to use the subdev pointer all the way down to register-access 
functions, _then_ you might need to modify this code.

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

Re: LGDT3304 help (AverMedia Duet A188)

[Devin Heitmueller]

On Fri, Jun 26, 2009 at 10:42 AM, oblib wrote:
>
> I'm trying to put together a driver for the AverMedia A188, which is 
> currently unsupported. Manu Abraham is working on the SAA716x driver which it 
> needs, but the frontends seem to be two LGDT3304's.
>
> My google-fu is failing me and I can't find any documentation on the chip. 
> Support for the chip was committed last year, but I don't see any drivers 
> actually using it.
>
> Does anyone have any documentation for the chip, or even better, some 
> examples of how to set it up for a driver. Also I don't know how to find 
> their I2C addresses.
>
> Thanks for any help in advance.

Work was recently done for lgdt3304 support for the K-World 330u by
Jarod Wilson and Michael Krufky.  That work should be making its way
into the mainline driver soon.

Cheers,

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH] mt9t031 - migration to sub device frame work

[Karicheri, Muralidharan]

>
>). I started by converting mx3-camera and mt9t031, and I shall upload an
>incomplete patch, converting only these drivers to my "testing" area,
>while I shall start converting the rest of the drivers... So, it is
>advisable to wait for that patch to appear and base any future (including
>this one) work on it, because it is a pretty big change and merging would
>be non-trivial.
>
I thought you wanted to offload some of the migration work and I had 
volunteered to do this since it is of interest to vpfe-capture. I don't see a 
point in duplicating the work already done by me. So could you please work with 
me by reviewing this patch and then use this for your work? I will take care of 
merging any updates to this based on your patches (like the crop one)

>
>> > >>  {
>> > >> -s32 data = i2c_smbus_read_word_data(client, reg);
>> > >> +s32 data;
>> > >> +
>> > >> +data = i2c_smbus_read_word_data(client, reg);
>> > >>  return data < 0 ? data : swab16(data);
>
>Looks like it will take me considerable time to review the patch and NAK
>all changes like this one...
>
I didn't get it. Are you referring to the 3 lines of code above? For this patch 
this code change is unnecessary, but I have to do this if sd is used as 
argument to this function as suggested by Hans. 

>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

Re: Pinnacle Systems PCTV 330e and Hauppauge WinTV HVR 900 (R2) not working under Debian 2.6.30-1

[Devin Heitmueller]

On Fri, Jun 26, 2009 at 10:36 AM, Simon Kenyon wrote:
> as you know i have the xl10353 variant. and you got it to work on my
> machine.
>
> now i know you don't want to hear this but the same code will not work on
> another machine.
> both are running 2.6.28-gentoo-r5, however i'm pretty sure the
> configurations are different.
> the working machine has an MSI KA780G MS-7551 [SB700 chipset] motherboard
> and
> the non-working machine has an ASUSTeK M3N78-EM [GeForce 8200 chipset]
> motherboard
>
> in fact, i've seen reference on this list to the fact that there are
> problems with the SB700. that seems to be the opposite to me.
> i will check it out on an Atom based netbook and an old Intel Centrino
> laptop to see if the code works there.
> i suspect it will - but need to confirm it.
>
> i'm afriad it is two steps forward and one step backwards
> --
> simon

Well, that's better than one step forward and two steps backward.  :-)

Send me the dmesg offline and I will work with you to try to debug the
issue.  I have some significant doubts this is an em28xx issue though.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

LGDT3304 help (AverMedia Duet A188)

[oblib]

I'm trying to put together a driver for the AverMedia A188, which is currently 
unsupported. Manu Abraham is working on the SAA716x driver which it needs, but 
the frontends seem to be two LGDT3304's. 

My google-fu is failing me and I can't find any documentation on the chip. 
Support for the chip was committed last year, but I don't see any drivers 
actually using it.

Does anyone have any documentation for the chip, or even better, some examples 
of how to set it up for a driver. Also I don't know how to find their I2C 
addresses.

Thanks for any help in advance.


  
--
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: v4l2_int_device vs v4l2_subdev?

[Aguirre Rodriguez, Sergio Alberto]

> > But in user space there is nothing changed having access to
> > device and control them.
> > As you know, subdev and int-device is all about how to bind
> > interface(or host?) and device and make them communicated each other.
> > But using subdev device driver with int-device supporting interface
> > (or host) device driver? it won't make any communication.
> > So if you are running out of time with your project, you'd better use
> > old driver of TVP. Like TVP driver in kernel 2.6.28 I suppose. But if
> > you have enough time and wanna be challenging, try to convert
> > in-device based omap3 camera interface driver to subdev supporting
> > one.
> 
> Someone's got to do this. v4l2_subdev is the future and it has many
> advantages over the older interfaces. The ability to be able to use the
> same i2c driver in anything from USB webcams to PCI capture cards to
> omap/davinci embedded platforms is very powerful.

Hi,

We have already this framework migration planned, but we haven't been
able to do it, because we are still solving stability issues on the driver.

I beg for your patience, and i hope i can get my hands on this pretty soon.

I'll be updating my tree when i have something.

Regards,
Sergio--
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: Hauppauge WinTV-HVR 900H support on Linux, any news?

[Steven Toth]

On 6/25/09 6:49 AM, Antonio Jimenez wrote:

Hi all,


is there any news or progress with the work for Hauppauge WinTV-HVR 900H
under Linux?

I read in March some emails here about this theme and I was very happy
with it, because I have one of these cards. But suddenly there were no
more news about it. I am still reading the linux-media mail list summary
every day, but there are no more news.

I can help testing, but only the digital section, cause here where I
live the analogic TV is already disabled.

Please.. any ray of hope? :)


Hope is not lost, but news is slow.

Hauppauge are in negotiations with a silicon vendor to release a datasheet. It's 
taking longer than we'd all like. Once this is done and the 900H is working then 
I'd expect a number of other products to also benefit from the work.


No ETA currently.

--
Steven Toth - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: v4l2_subdev GPIO and Pin Control ops (Re: PxDVR3200 H LinuxTV v4l-dvb patch : Pull GPIO-20 low for DVB-T)

[Steven Toth]

On 6/25/09 7:15 AM, Andy Walls wrote:

On Thu, 2009-06-25 at 08:39 +0200, Hans Verkuil wrote:

On Thursday 25 June 2009 04:40:11 Andy Walls wrote:

On Tue, 2009-06-23 at 14:33 +0200, Hans Verkuil wrote:

On Tue, 2009-06-23 at 11:39 +0800, Terry Wu wrote:


There is already an s_gpio in the core ops. It would be simple to add a
g_gpio as well if needed.

Hans,

As you probably know

int (*s_gpio)(v4l2_subdev *sd, u32 val);

is a little too simple for initial setup of GPIO pins.  With the
collection of chips&  cores supported by cx25840 module, setting the
GPIO configuration also requires:

direction: In or Out
multiplexed pins: GPIO or some other function

I could tack on direction as an argument to s_gpio(), but I think that
is a bit inconvenient..  I'd rather have a

int (*s_gpio_config)(v4l2_subdev *sd, u32 dir, u32 initval);

but that leaves out the method for multiplexed pin/pad configuration.
Perhaps explicity setting a GPIO direction to OUT could be an implicit
indication that a multiplexed pin should be set to it's GPIO function.
However, that doesn't help for GPIO inputs that might have their pins
multiplexed with other functions.

Here's an idea on how to specify multiplexed pin configuration
information and it could involve pins that multiplex functions other
than GPIO (the CX25843 is quite flexible in this regard):

int (*s_pin_function)(v4l2_subdev *sd, u32 pin_id, u32 function);

The type checking ends up pretty weak, but I figured it was better than
a 'void *config' that had a subdev specific collection of pin
configuration information.

Comments?

Hi Andy,

Is there any driver that needs to setup the multiplex functions? If not, then
I would not add support for this at the moment.


Well, the group of GPIO pins in question for the CX23885 are all
multiplexed with other functions.  We could just initialize the CX23885
to have those pins set as GPIOs, but I have to check the cx23885 driver
to make sure that's safe.


I'm in the process of rationalizing the GPIO handing inside the cx23885 driver, 
largely because of the cx23417. The current encoder driver has a hardcoded GPIO 
used on GPIO 15. (legacy from the first HVR1800 implementation, which I'm 
cleaning up).


I would add this to the conversation, the product I'm working on now HVR1850 
needs to switch GPIO's on the fly to enable and disable parts (the ATSC demod) 
via an encoder GPIO pin, depending on the cards operating mode. This isn't a 
one-time operation, it needs to be dynamic.


In effect we have to tri-state / float certain parts depending whether we're in 
analog or digital mode, and depending on which tuner is being used.


--
Steven Toth - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Pinnacle Systems PCTV 330e and Hauppauge WinTV HVR 900 (R2) not working under Debian 2.6.30-1

[Simon Kenyon]

Devin Heitmueller wrote:

Regarding the Terratec Cinergy T XS USB you sent me...  there are two
variants of the same device with the same USB ID.  One has the zl10353
and the other has the mt352.  I found one bug that was common to both,
one bug in the zl10353 version, and one bug in the mt352.  I issued a
PULL request for the zl10353 version last Tuesday.
  
as you know i have the xl10353 variant. and you got it to work on my 
machine.


now i know you don't want to hear this but the same code will not work 
on another machine.
both are running 2.6.28-gentoo-r5, however i'm pretty sure the 
configurations are different.
the working machine has an MSI KA780G MS-7551 [SB700 chipset] 
motherboard and
the non-working machine has an ASUSTeK M3N78-EM [GeForce 8200 chipset] 
motherboard


in fact, i've seen reference on this list to the fact that there are 
problems with the SB700. that seems to be the opposite to me.
i will check it out on an Atom based netbook and an old Intel Centrino 
laptop to see if the code works there.

i suspect it will - but need to confirm it.

i'm afriad it is two steps forward and one step backwards
--
simon
--
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: Bah! How do I change channels?

[Devin Heitmueller]

On Fri, Jun 26, 2009 at 7:50 AM, Andy Walls wrote:
> I use either v4l2-ctl or ivtv-tune
>
> $ ivtv-tune -d /dev/video0 -t us-bcast -c 3
> /dev/video0: 61.250 MHz
>
> $ v4l2-ctl -d /dev/video0 -f 61.250
> Frequency set to 980 (61.25 MHz)
>
>
> Regards,
> Andy

Hello Andy,

I had sent George some email off-list with basically the same
commands.  I think what might be happening here is the tuner gets
powered down when not in use, so I think it might be powered down
between the v4l-ctl command and the running of the other application.

I have sent him a series of commands to try where he modprobes the
xc3028 driver with "no_poweroff=1", and we will see if that starts
working.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Pinnacle Systems PCTV 330e and Hauppauge WinTV HVR 900 (R2) not working under Debian 2.6.30-1

[Devin Heitmueller]

On Fri, Jun 26, 2009 at 4:26 AM, Jelle de Jong wrote:
> Hi all,
>
> This is sort of an updated report, I tested my em28xx based hybrid
> devices again and the dvb-t still does not work under the 2.6.30 kernel.
> I am not interested in the analog parts. So how is the process going on
> getting support for dvb-t in the kernel. I am also not interested in any
> non free non mainstream maintained code bases.
>
> I believe I sent some em28xx devices to Devin, so how is the process
> going, any luck?
>
> Question for Antti if he had any luck with the devices (rtl2831-r2) I send?
>
> Best regards,
>
> Jelle de Jong

Hello Jelle,

Unfortunately, I could have told you without your having done any
testing that the 330e and HVR-900 R2 are not any closer to working -
nobody is working on them.  They both use the Micronas drx-d, for
which we have a reverse engineered driver that is not currently used
in any devices and it is unknown whether it actually works.  Devices
attempting to use the driver require a config structure which has
something like 27 inputs, so while I do have the HVR-900 R2 hardware I
didn't feel comfortable attempting to get it to work without a signal
generator.

Regarding the Terratec Cinergy T XS USB you sent me...  there are two
variants of the same device with the same USB ID.  One has the zl10353
and the other has the mt352.  I found one bug that was common to both,
one bug in the zl10353 version, and one bug in the mt352.  I issued a
PULL request for the zl10353 version last Tuesday.

So, I've fixed three bugs and gotten the zl10353 version working.  The
mt352 version (which is the one you sent me) has the fixes above, but
according to the one user who has been willing to test the changes,
the device still does not work.  I do not know whether this is really
a bug in the driver or a problem in the user's environment (since he
doesn't own any other tuners to verify his signal and antenna with).
Contrary to my expectations, I haven't been been able to get access to
the signal generator, so I haven't been able to fully test/debug the
device myself.

If there are any other users out there with the mt352 version of the
Terratec Cinergy T XS who can do testing, I would definitely be
willing to work with them.

I am continuing to try to get access to a generator, and looking for
other testers who can try the changes.  I'm at a point now where I was
debating just sending it back to you and having you see if it works
(given the fixes I've already made), and attempting to debug any
issues remotely.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Bah! How do I change channels?

[Andy Walls]

On Thu, 2009-06-25 at 23:04 -0400, George Adams wrote:
> Having gotten my Pinnacle HDTV Pro Stick working again under some old
> v4l drivers, I'm now facing a much more mundane problem - I can't
> figure out how to use the command line to change the channel.
> 
> The video feed (a closed-circuit feed) that's coming to the card is
> over a coax cable, and is on (analog) channel 3.  My goal is to take
> the input and use Helix Encoder to produce RealVideo output that can
> be played using Real Player (yeah, not the ideal situation, but it's
> what we're using for now)
> 
> Helix Producer (unlike "mencoder/mplayer") doesn't have the ability to
> change the channel - it can only take whatever is coming over the
> channel that the Pinnacle device is currently tuned to.  Devin pointed
> me to the "v4lctl" command, but I'm not having any luck with it yet.  

I use either v4l2-ctl or ivtv-tune

$ ivtv-tune -d /dev/video0 -t us-bcast -c 3
/dev/video0: 61.250 MHz

$ v4l2-ctl -d /dev/video0 -f 61.250
Frequency set to 980 (61.25 MHz)


Regards,
Andy


--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Cropping with Hauppauge HVR-1900

[jmdk]

Hello,

I have a Hauppauge HVR-1900 which works fine with the pvrusb2 driver.
However because most TV channels now air with 16:9 content inside 4:3
images, I would like to crop out the top and bottom black bars before
encoding via the hardware MPEG2 encoder. I tried using the ctl_crop_top
and ctl_crop_height in  /sysfs as well as the --set-crop option of
v4l2-ctrl but only received error messages indicating a value out of range.

The card has a cx25843 which should support cropping. Does anyone know
how to get this feature to work ?

Thanks in advance for the help,

Joseph
--
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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-misc

[Hans Verkuil]

> On Tuesday 23 June 2009 08:45:51 Hans Verkuil wrote:
>> Hi Mauro,
>>
>> Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-misc for
>> the
>> following:
>>
>> - v4l2-spec: add missing V4L2_PIX_FMT_OV511 documentation.
>
> Added this patch:
>
> - v4l2-common: fix uninitialized variable
>
> Note that this variable was only uninitialized when compiled for kernels
> older than 2.6.26.

And this patch:

- em28xx: enable new-style i2c API for kernels >= 2.6.26, not 2.6.22.

This fixes the em28xx driver when v4l-dvb is compiled for kernels
2.6.22-2.6.25.

Regards,

   Hans

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG

--
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

Pinnacle Systems PCTV 330e and Hauppauge WinTV HVR 900 (R2) not working under Debian 2.6.30-1

[Jelle de Jong]

Hi all,

This is sort of an updated report, I tested my em28xx based hybrid
devices again and the dvb-t still does not work under the 2.6.30 kernel.
I am not interested in the analog parts. So how is the process going on
getting support for dvb-t in the kernel. I am also not interested in any
non free non mainstream maintained code bases.

I believe I sent some em28xx devices to Devin, so how is the process
going, any luck?

Question for Antti if he had any luck with the devices (rtl2831-r2) I send?

Best regards,

Jelle de Jong
$ cat /proc/version
Linux version 2.6.30-1-686 (Debian 2.6.30-1) (wa...@debian.org) (gcc version 
4.3.3 (Debian 4.3.3-11) ) #1 SMP Sun Jun 14 16:11:32 UTC 2009

[ 2629.292634] usb 1-2: New USB device found, idVendor=2304, idProduct=0226
[ 2629.292648] usb 1-2: New USB device strings: Mfr=3, Product=1, SerialNumber=2
[ 2629.292660] usb 1-2: Product: PCTV 330e
[ 2629.292669] usb 1-2: Manufacturer: Pinnacle Systems
[ 2629.292678] usb 1-2: SerialNumber: 070901090280
[ 2629.293003] usb 1-2: configuration #1 chosen from 1 choice
[ 2629.380840] Linux video capture interface: v2.00
[ 2629.458285] em28xx: New device Pinnacle Systems PCTV 330e @ 480 Mbps 
(2304:0226, interface 0, class 0)
[ 2629.458319] em28xx #0: Identified as Pinnacle Hybrid Pro (2) (card=56)
[ 2629.458684] em28xx #0: chip ID is em2882/em2883
[ 2629.632618] em28xx #0: i2c eeprom 00: 1a eb 67 95 04 23 26 02 d0 12 5c 03 8e 
16 a4 1c
[ 2629.632666] em28xx #0: i2c eeprom 10: 6a 24 27 57 46 07 01 00 00 00 00 00 00 
00 00 00
[ 2629.632707] em28xx #0: i2c eeprom 20: 46 00 01 00 f0 10 02 00 b8 00 00 00 5b 
e0 00 00
[ 2629.632747] em28xx #0: i2c eeprom 30: 00 00 20 40 20 6e 02 20 10 01 00 00 00 
00 00 00
[ 2629.632787] em28xx #0: i2c eeprom 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00
[ 2629.632826] em28xx #0: i2c eeprom 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00
[ 2629.632865] em28xx #0: i2c eeprom 60: 00 00 00 00 00 00 00 00 00 00 24 03 50 
00 69 00
[ 2629.632905] em28xx #0: i2c eeprom 70: 6e 00 6e 00 61 00 63 00 6c 00 65 00 20 
00 53 00
[ 2629.632945] em28xx #0: i2c eeprom 80: 79 00 73 00 74 00 65 00 6d 00 73 00 00 
00 16 03
[ 2629.632985] em28xx #0: i2c eeprom 90: 50 00 43 00 54 00 56 00 20 00 33 00 33 
00 30 00
[ 2629.633039] em28xx #0: i2c eeprom a0: 65 00 00 00 1c 03 30 00 37 00 30 00 39 
00 30 00
[ 2629.633084] em28xx #0: i2c eeprom b0: 31 00 30 00 39 00 30 00 32 00 38 00 30 
00 00 00
[ 2629.633124] em28xx #0: i2c eeprom c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00
[ 2629.633163] em28xx #0: i2c eeprom d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00
[ 2629.633203] em28xx #0: i2c eeprom e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00
[ 2629.633242] em28xx #0: i2c eeprom f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00
[ 2629.633287] em28xx #0: EEPROM ID= 0x9567eb1a, EEPROM hash = 0x87b3a5bf
[ 2629.633295] em28xx #0: EEPROM info:
[ 2629.633303] em28xx #0:   AC97 audio (5 sample rates)
[ 2629.633310] em28xx #0:   500mA max power
[ 2629.633321] em28xx #0:   Table at 0x27, strings=0x168e, 0x1ca4, 0x246a
[ 2629.61] em28xx #0:
[ 2629.65]
[ 2629.633345] em28xx #0: The support for this board weren't valid yet.
[ 2629.633354] em28xx #0: Please send a report of having this working
[ 2629.633363] em28xx #0: not to V4L mailing list (and/or to other addresses)
[ 2629.633369]
[ 2629.646677] tvp5150 1-005c: chip found @ 0xb8 (em28xx #0)
[ 2629.668207] tuner 1-0061: chip found @ 0xc2 (em28xx #0)
[ 2629.707303] xc2028 1-0061: creating new instance
[ 2629.707318] xc2028 1-0061: type set to XCeive xc2028/xc3028 tuner
[ 2629.707346] i2c-adapter i2c-1: firmware: requesting xc3028-v27.fw
[ 2629.725562] xc2028 1-0061: Loading 80 firmware images from xc3028-v27.fw, 
type: xc2028 firmware, ver 2.7
[ 2629.776067] xc2028 1-0061: Loading firmware for type=BASE MTS (5), id 
.
[ 2630.787641] xc2028 1-0061: Loading firmware for type=MTS (4), id 
b700.
[ 2630.804877] xc2028 1-0061: Loading SCODE for type=MTS LCD NOGD MONO IF SCODE 
HAS_IF_4500 (6002b004), id b700.
[ 2630.988331] em28xx #0: Config register raw data: 0xd0
[ 2630.989121] em28xx #0: AC97 vendor ID = 0x
[ 2630.989496] em28xx #0: AC97 features = 0x6a90
[ 2630.989506] em28xx #0: Empia 202 AC97 audio processor detected
[ 2631.116623] tvp5150 1-005c: tvp5150am1 detected.
[ 2631.237132] em28xx #0: v4l2 driver version 0.1.2
[ 2631.319217] em28xx #0: V4L2 device registered as /dev/video0 and /dev/vbi0
[ 2631.332140] usbcore: registered new interface driver em28xx
[ 2631.332159] em28xx driver loaded
[ 2631.385655] em28xx-audio.c: probing for em28x1 non standard usbaudio
[ 2631.385671] em28xx-audio.c: Copyright (C) 2006 Markus Rechberger
[ 2631.387359] Em28xx: Initialized (Em28xx Audio Extension) extension
[ 2631.656608] tvp5150 1-005c: tvp5150am1 detected.



[ 2749.140095] usb 1-2: new high speed USB device using ehci_hcd and address 9
[

Afatech AF9013 DVB-T not working with mplayer radio streams

[Jelle de Jong]

Hi all,

Because i now use a new kernel and new mplayer versions I did some
testing again on one of my long standing issues.

My Afatech AF9015 DVB-T USB2.0 stick does not work with mplayer, other
em28xx devices do work with mplayer.

Would somebody be willing to do some tests and see if mplayers works on
your devices?

Debian 2.6.30-1

/usr/bin/mplayer -identify -v -dvbin timeout=10 dvb://"3FM(Digitenne)"

See the attachments for full details.

Best regards,

Jelle de Jong
$ dmesg
[ 1179.756075] usb 1-2: new high speed USB device using ehci_hcd and address 7
[ 1179.892943] usb 1-2: New USB device found, idVendor=15a4, idProduct=9016
[ 1179.892958] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 1179.892969] usb 1-2: Product: DVB-T
[ 1179.892978] usb 1-2: Manufacturer: Afatech
[ 1179.893314] usb 1-2: configuration #1 chosen from 1 choice
[ 1179.917431] dvb-usb: found a 'Afatech AF9015 DVB-T USB2.0 stick' in cold state, will try to load a firmware
[ 1179.917458] usb 1-2: firmware: requesting dvb-usb-af9015.fw
[ 1179.955337] dvb-usb: downloading firmware from file 'dvb-usb-af9015.fw'
[ 1180.029702] dvb-usb: found a 'Afatech AF9015 DVB-T USB2.0 stick' in warm state.
[ 1180.029843] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer.
[ 1180.030323] DVB: registering new adapter (Afatech AF9015 DVB-T USB2.0 stick)
[ 1180.445189] af9013: firmware version:4.95.0
[ 1180.450068] DVB: registering adapter 0 frontend 0 (Afatech AF9013 DVB-T)...
[ 1180.453854] MT2060: successfully identified (IF1 = 1220)
[ 1180.923942] dvb-usb: Afatech AF9015 DVB-T USB2.0 stick successfully initialized and connected.
[ 1180.942283] Afatech DVB-T: Fixing fullspeed to highspeed interval: 16 -> 8
[ 1180.943283] input: Afatech DVB-T as /devices/pci:00/:00:1d.7/usb1/1-2/1-2:1.1/input/input11
[ 1180.943730] generic-usb 0003:15A4:9016.0004: input,hidraw0: USB HID v1.01 Keyboard [Afatech DVB-T] on usb-:00:1d.7-2/input1

$ sudo lsusb -v -d 15a4:9016
Bus 001 Device 007: ID 15a4:9016
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   2.00
  bDeviceClass0 (Defined at Interface level)
  bDeviceSubClass 0
  bDeviceProtocol 0
  bMaxPacketSize064
  idVendor   0x15a4
  idProduct  0x9016
  bcdDevice2.00
  iManufacturer   1 Afatech
  iProduct2 DVB-T
  iSerial 0
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   71
bNumInterfaces  2
bConfigurationValue 1
iConfiguration  0
bmAttributes 0x80
  (Bus Powered)
MaxPower  500mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   4
  bInterfaceClass   255 Vendor Specific Class
  bInterfaceSubClass  0
  bInterfaceProtocol  0
  iInterface  0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81  EP 1 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval   0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02  EP 2 OUT
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval   0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x84  EP 4 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval   0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x85  EP 5 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval   0
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber1
  bAlternateSetting   0
  bNumEndpoints   1
  bInterfaceClass 3 Human Interface Device
  bInterfaceSubClass  0 No Subclass
  bInterfaceProtocol  1 Keyboard
  iInterface  0
  ** UNRECOGNIZED:  09 2

Re: [PATCH] mt9t031 - migration to sub device frame work

[Hans Verkuil]

> On Fri, 26 Jun 2009, Hans Verkuil wrote:
>
>> On Thursday 25 June 2009 22:17:04 Karicheri, Muralidharan wrote:
>> >
>> > >-Original Message-
>> > >From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
>> > >ow...@vger.kernel.org] On Behalf Of Guennadi Liakhovetski
>> > >Sent: Thursday, June 25, 2009 1:46 PM
>> > >To: Karicheri, Muralidharan
>> > >Cc: linux-media@vger.kernel.org; davinci-linux-open-
>> > >sou...@linux.davincidsp.com
>> > >Subject: Re: [PATCH] mt9t031 - migration to sub device frame work
>> > >
>> > >On Wed, 24 Jun 2009, m-kariche...@ti.com wrote:
>> > >
>> > >> From: Muralidharan Karicheri 
>> > >>
>> > >> This patch migrates mt9t031 driver from SOC Camera interface to
>> > >> sub device interface. This is sent to get a feedback about the
>> > >> changes done since I am not sure if some of the functionality
>> > >> that is removed works okay with SOC Camera bridge driver or
>> > >> not. Following functions are to be discussed and added as needed:-
>> > >>
>> > >>  1) query bus parameters
>> > >>  2) set bus parameters
>> > >>  3) set crop
>>
>> 3 is fixed in a pending patch from Guennadi. Should be in soon I hope.
>> I hope to take a final look at 1+2 this weekend.
>
> Hans, you can read unsubmitted patches?:-)

Good, isn't it? :-)

Actually, I assumed Karicheri was referring to the missing s_crop et al
ops in v4l2_subdev. Those you added in a patch in a pull request from you.

> In fact, yes, I am working on a
> big S_CROP / S_FMT revamp right now, which should make soc-camera
> behaviour standard compliant (or at least compliant with my _current_
> understanding of the standard, which is:
>
> S_CROP sets the input (sensor / decoder / ...) window and tries to
> preserve scaling factors if possible. Output window may change. The user
> has to verify the actual changes performed by issuing G_FMT / G_CROP.
>
> S_FMT sets output window and tries to preserve the input window by
> changing scaling factors. The actually configured window is also returned
> in the ioctl argument. To retrieve the input window the user shall issue
> G_CROP.
>
> ). I started by converting mx3-camera and mt9t031, and I shall upload an
> incomplete patch, converting only these drivers to my "testing" area,
> while I shall start converting the rest of the drivers... So, it is
> advisable to wait for that patch to appear and base any future (including
> this one) work on it, because it is a pretty big change and merging would
> be non-trivial.
>
>> > >> +static inline struct mt9t031 *to_mt9t031(struct v4l2_subdev *sd)
>> > >> +{
>> > >> +return container_of(sd, struct mt9t031, sd);
>> > >> +}
>> > >> +
>> > >>  static int reg_read(struct i2c_client *client, const u8 reg)
>>
>> I recommend using struct v4l2_subdev *sd here instead of the client
>> pointer.
>> Experience shows that it is usually best to push the sd -> client
>> conversion
>> to the lowest level possible.
>
> Why? I actually have done the opposite on a few occasions - switched from
> passing a struct soc_camera_device pointer to passing a struct i2c_client
> pointer directly, which led to some nice code simplifications. Just
> imagine issuing reg_read multiple times in a function, so, you would have
> to convert it every time? The compiler _might_ happen to be smart enough
> to optimise this away by inining them, but I wouldn't rely on that.

v4l2_get_subdevdata is a simple inline (just returns sd->priv), so I think
we can safely rely on it being inlined. Also remember that the actual i2c
transfer is many, many, many times slower then the worst-case scenario of
doing a function call. So whether a compiler optimizes this or not is
completely irrelevant. Code readability is, though.

> Besides, there are also some mid-level functions, which don't need the
> subdev / soc-camera pointer either, but would have to deal with it if we
> were to use it in low-level ones. So, I cannot say I agree straight away
> on this one.

Until now in all the drivers I converted I think there was only one where
I didn't push this conversion down to the lowest level due to a lot of
mid-level functions. In all others it was much simpler to push it down.
And that definitely improved readability and the quality of the code.

Regards,

  Hans


-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG

--
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] mt9t031 - migration to sub device frame work

[Guennadi Liakhovetski]

On Fri, 26 Jun 2009, Hans Verkuil wrote:

> On Thursday 25 June 2009 22:17:04 Karicheri, Muralidharan wrote:
> > 
> > >-Original Message-
> > >From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
> > >ow...@vger.kernel.org] On Behalf Of Guennadi Liakhovetski
> > >Sent: Thursday, June 25, 2009 1:46 PM
> > >To: Karicheri, Muralidharan
> > >Cc: linux-media@vger.kernel.org; davinci-linux-open-
> > >sou...@linux.davincidsp.com
> > >Subject: Re: [PATCH] mt9t031 - migration to sub device frame work
> > >
> > >On Wed, 24 Jun 2009, m-kariche...@ti.com wrote:
> > >
> > >> From: Muralidharan Karicheri 
> > >>
> > >> This patch migrates mt9t031 driver from SOC Camera interface to
> > >> sub device interface. This is sent to get a feedback about the
> > >> changes done since I am not sure if some of the functionality
> > >> that is removed works okay with SOC Camera bridge driver or
> > >> not. Following functions are to be discussed and added as needed:-
> > >>
> > >>  1) query bus parameters
> > >>  2) set bus parameters
> > >>  3) set crop
> 
> 3 is fixed in a pending patch from Guennadi. Should be in soon I hope.
> I hope to take a final look at 1+2 this weekend.

Hans, you can read unsubmitted patches?:-) In fact, yes, I am working on a 
big S_CROP / S_FMT revamp right now, which should make soc-camera 
behaviour standard compliant (or at least compliant with my _current_ 
understanding of the standard, which is:

S_CROP sets the input (sensor / decoder / ...) window and tries to 
preserve scaling factors if possible. Output window may change. The user 
has to verify the actual changes performed by issuing G_FMT / G_CROP.

S_FMT sets output window and tries to preserve the input window by 
changing scaling factors. The actually configured window is also returned 
in the ioctl argument. To retrieve the input window the user shall issue 
G_CROP.

). I started by converting mx3-camera and mt9t031, and I shall upload an 
incomplete patch, converting only these drivers to my "testing" area, 
while I shall start converting the rest of the drivers... So, it is 
advisable to wait for that patch to appear and base any future (including 
this one) work on it, because it is a pretty big change and merging would 
be non-trivial.

> > >> +static inline struct mt9t031 *to_mt9t031(struct v4l2_subdev *sd)
> > >> +{
> > >> +return container_of(sd, struct mt9t031, sd);
> > >> +}
> > >> +
> > >>  static int reg_read(struct i2c_client *client, const u8 reg)
> 
> I recommend using struct v4l2_subdev *sd here instead of the client pointer.
> Experience shows that it is usually best to push the sd -> client conversion
> to the lowest level possible.

Why? I actually have done the opposite on a few occasions - switched from 
passing a struct soc_camera_device pointer to passing a struct i2c_client 
pointer directly, which led to some nice code simplifications. Just 
imagine issuing reg_read multiple times in a function, so, you would have 
to convert it every time? The compiler _might_ happen to be smart enough 
to optimise this away by inining them, but I wouldn't rely on that. 
Besides, there are also some mid-level functions, which don't need the 
subdev / soc-camera pointer either, but would have to deal with it if we 
were to use it in low-level ones. So, I cannot say I agree straight away 
on this one.

> > >>  {
> > >> -s32 data = i2c_smbus_read_word_data(client, reg);
> > >> +s32 data;
> > >> +
> > >> +data = i2c_smbus_read_word_data(client, reg);
> > >>  return data < 0 ? data : swab16(data);

Looks like it will take me considerable time to review the patch and NAK 
all changes like this one...

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

Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-misc

[Hans Verkuil]

On Tuesday 23 June 2009 08:45:51 Hans Verkuil wrote:
> Hi Mauro,
> 
> Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-misc for the
> following:
> 
> - v4l2-spec: add missing V4L2_PIX_FMT_OV511 documentation.

Added this patch:

- v4l2-common: fix uninitialized variable

Note that this variable was only uninitialized when compiled for kernels
older than 2.6.26.

Regards,

Hans

> 
> Hans, when you modify the videodev2.h header you should also do a 'make spec'
> to check whether the v4l2-spec still builds. It's easy to forget that, but
> it's important to keep the spec up to date.
> 
> Thanks,
> 
> Hans
> 
> diffstat:
>  pixfmt.sgml |7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 



-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
--
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