Re: [PATCH] v4l: make sure drivers supply a zeroed struct v4l2_subdev

[Hans Verkuil]

On Friday, April 01, 2011 19:12:02 Herton Ronaldo Krzesinski wrote:
 Some v4l drivers currently don't initialize their struct v4l2_subdev
 with zeros, and this is a problem since some of the v4l2 code expects
 this. One example is the addition of internal_ops in commit 45f6f84,
 after that we are at risk of random oopses with these drivers when code
 in v4l2_device_register_subdev tries to dereference sd-internal_ops-*,
 as can be shown by the report at http://bugs.launchpad.net/bugs/745213
 and analysis of its crash at https://lkml.org/lkml/2011/4/1/168
 
 Use kzalloc within problematic drivers to ensure we have a zeroed struct
 v4l2_subdev.
 
 BugLink: http://bugs.launchpad.net/bugs/745213
 Cc: sta...@kernel.org
 Signed-off-by: Herton Ronaldo Krzesinski herton.krzesin...@canonical.com

Acked-by: Hans Verkuil hverk...@xs4all.nl

Thanks!

Hans

 ---
  drivers/media/radio/saa7706h.c  |2 +-
  drivers/media/radio/tef6862.c   |2 +-
  drivers/media/video/m52790.c|2 +-
  drivers/media/video/tda9840.c   |2 +-
  drivers/media/video/tea6415c.c  |2 +-
  drivers/media/video/tea6420.c   |2 +-
  drivers/media/video/upd64031a.c |2 +-
  drivers/media/video/upd64083.c  |2 +-
  8 files changed, 8 insertions(+), 8 deletions(-)
 
 diff --git a/drivers/media/radio/saa7706h.c b/drivers/media/radio/saa7706h.c
 index 585680f..b1193df 100644
 --- a/drivers/media/radio/saa7706h.c
 +++ b/drivers/media/radio/saa7706h.c
 @@ -376,7 +376,7 @@ static int __devinit saa7706h_probe(struct i2c_client 
 *client,
   v4l_info(client, chip found @ 0x%02x (%s)\n,
   client-addr  1, client-adapter-name);
  
 - state = kmalloc(sizeof(struct saa7706h_state), GFP_KERNEL);
 + state = kzalloc(sizeof(struct saa7706h_state), GFP_KERNEL);
   if (state == NULL)
   return -ENOMEM;
   sd = state-sd;
 diff --git a/drivers/media/radio/tef6862.c b/drivers/media/radio/tef6862.c
 index 7c0d777..0991e19 100644
 --- a/drivers/media/radio/tef6862.c
 +++ b/drivers/media/radio/tef6862.c
 @@ -176,7 +176,7 @@ static int __devinit tef6862_probe(struct i2c_client 
 *client,
   v4l_info(client, chip found @ 0x%02x (%s)\n,
   client-addr  1, client-adapter-name);
  
 - state = kmalloc(sizeof(struct tef6862_state), GFP_KERNEL);
 + state = kzalloc(sizeof(struct tef6862_state), GFP_KERNEL);
   if (state == NULL)
   return -ENOMEM;
   state-freq = TEF6862_LO_FREQ;
 diff --git a/drivers/media/video/m52790.c b/drivers/media/video/m52790.c
 index 5e1c9a8..303ffa7 100644
 --- a/drivers/media/video/m52790.c
 +++ b/drivers/media/video/m52790.c
 @@ -174,7 +174,7 @@ static int m52790_probe(struct i2c_client *client,
   v4l_info(client, chip found @ 0x%x (%s)\n,
   client-addr  1, client-adapter-name);
  
 - state = kmalloc(sizeof(struct m52790_state), GFP_KERNEL);
 + state = kzalloc(sizeof(struct m52790_state), GFP_KERNEL);
   if (state == NULL)
   return -ENOMEM;
  
 diff --git a/drivers/media/video/tda9840.c b/drivers/media/video/tda9840.c
 index 5d4cf3b..22fa820 100644
 --- a/drivers/media/video/tda9840.c
 +++ b/drivers/media/video/tda9840.c
 @@ -171,7 +171,7 @@ static int tda9840_probe(struct i2c_client *client,
   v4l_info(client, chip found @ 0x%x (%s)\n,
   client-addr  1, client-adapter-name);
  
 - sd = kmalloc(sizeof(struct v4l2_subdev), GFP_KERNEL);
 + sd = kzalloc(sizeof(struct v4l2_subdev), GFP_KERNEL);
   if (sd == NULL)
   return -ENOMEM;
   v4l2_i2c_subdev_init(sd, client, tda9840_ops);
 diff --git a/drivers/media/video/tea6415c.c b/drivers/media/video/tea6415c.c
 index 19621ed..827425c 100644
 --- a/drivers/media/video/tea6415c.c
 +++ b/drivers/media/video/tea6415c.c
 @@ -152,7 +152,7 @@ static int tea6415c_probe(struct i2c_client *client,
  
   v4l_info(client, chip found @ 0x%x (%s)\n,
   client-addr  1, client-adapter-name);
 - sd = kmalloc(sizeof(struct v4l2_subdev), GFP_KERNEL);
 + sd = kzalloc(sizeof(struct v4l2_subdev), GFP_KERNEL);
   if (sd == NULL)
   return -ENOMEM;
   v4l2_i2c_subdev_init(sd, client, tea6415c_ops);
 diff --git a/drivers/media/video/tea6420.c b/drivers/media/video/tea6420.c
 index 5ea8404..f350b6c 100644
 --- a/drivers/media/video/tea6420.c
 +++ b/drivers/media/video/tea6420.c
 @@ -125,7 +125,7 @@ static int tea6420_probe(struct i2c_client *client,
   v4l_info(client, chip found @ 0x%x (%s)\n,
   client-addr  1, client-adapter-name);
  
 - sd = kmalloc(sizeof(struct v4l2_subdev), GFP_KERNEL);
 + sd = kzalloc(sizeof(struct v4l2_subdev), GFP_KERNEL);
   if (sd == NULL)
   return -ENOMEM;
   v4l2_i2c_subdev_init(sd, client, tea6420_ops);
 diff --git a/drivers/media/video/upd64031a.c b/drivers/media/video/upd64031a.c
 index f8138c7..1aab96a 100644
 --- a/drivers/media/video/upd64031a.c
 +++ 

Re: [patch] Fix AF9015 Dual tuner i2c write failures

[Antti Palosaari]

On 04/02/2011 04:24 AM, adq wrote:

Hi, just been trying it out, with no success. On my test machine, FE0
no longer tunes, but FE1 is still fine, so I've just been testing FE0.


You try to say other frontend / tuner is physically dead? Which one?


I've tried your suggestions, mainly concentrating on the af9013's
GPIOs, but I also tried your power management suggestion.

Since I was just using FE0, I've just been setting all the GPIOs at
the start of af9013.c's set_frontend() implementation; I've tried
turning them all off, all on, on-mdelay-off, and also
off-mdelay-on. Nothing works.


So GPIOs are blocked out.

I wonder if someone can ran similar many day tuning stress test using 
Windows drivers to see if that happen.


Antti

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

[RFC/PATCH 0/3] locking fixes for cx88

[Jonathan Nieder]

Hi,

Huber Andreas wrote[1]:

 Processes that try to open a cx88-blackbird driven MPEG device will hang up.

Here's a possible fix based on a patch by Ben Hutchings and
corrections from Andi Huber.  Warning: probably full of mistakes (my
fault) since I'm not familiar with any of this stuff.  Untested.
Review and testing would be welcome.

Ben Hutchings (2):
  [media] cx88: fix locking of sub-driver operations
  [media] cx88: use a mutex to protect cx8802_devlist

Jonathan Nieder (1):
  [media] cx88: protect per-device driver list with device lock

 drivers/media/video/cx88/cx88-blackbird.c |3 +-
 drivers/media/video/cx88/cx88-dvb.c   |2 +
 drivers/media/video/cx88/cx88-mpeg.c  |   35 +++-
 drivers/media/video/cx88/cx88.h   |   10 +++-
 4 files changed, 37 insertions(+), 13 deletions(-)
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v16 00/13] davinci vpbe: dm6446 v4l2 driver

[Manjunath Hadli]

The more important among the patch history from previous comments
1. Removal of platform resource overlap.
2. Removal of unused macros.
3. Fixing the module params typo.
4. Minor changes in the GPL licensing header.
5. Removed the initializer for field inversion parameter.
6. Changing the Field inversion #ifdef to platform 
   based implementation.
7. Interchanged platform and board specific patches due to dependencies.
8. Fixed sparse warnings.

Manjunath Hadli (13):
  davinci vpbe: V4L2 display driver for DM644X SoC
  davinci vpbe: VPBE display driver
  davinci vpbe: OSD(On Screen Display) block
  davinci vpbe: VENC( Video Encoder) implementation
  davinci vpbe: Build infrastructure for VPBE driver
  davinci vpbe: Readme text for Dm6446 vpbe
  davinci: move DM64XX_VDD3P3V_PWDN to devices.c
  davinci: eliminate use of IO_ADDRESS() on sysmod
  davinci: dm644x: Replace register base value with a defined macro
  davinci: dm644x: change vpfe capture structure variables for
consistency
  davinci: dm644x: move vpfe init from soc to board specific files
  davinci: dm644x: add support for v4l2 video display
  davinci: dm644x EVM: add support for VPBE display

 Documentation/video4linux/README.davinci-vpbe |   93 ++
 arch/arm/mach-davinci/board-dm644x-evm.c  |  131 ++-
 arch/arm/mach-davinci/devices.c   |   25 +-
 arch/arm/mach-davinci/dm355.c |1 +
 arch/arm/mach-davinci/dm365.c |1 +
 arch/arm/mach-davinci/dm644x.c|  177 ++-
 arch/arm/mach-davinci/dm646x.c|1 +
 arch/arm/mach-davinci/include/mach/dm644x.h   |6 +-
 arch/arm/mach-davinci/include/mach/hardware.h |7 +-
 drivers/media/video/davinci/Kconfig   |   22 +
 drivers/media/video/davinci/Makefile  |2 +
 drivers/media/video/davinci/vpbe.c|  827 ++
 drivers/media/video/davinci/vpbe_display.c| 2085 +
 drivers/media/video/davinci/vpbe_osd.c| 1216 ++
 drivers/media/video/davinci/vpbe_osd_regs.h   |  364 +
 drivers/media/video/davinci/vpbe_venc.c   |  556 +++
 drivers/media/video/davinci/vpbe_venc_regs.h  |  177 +++
 include/media/davinci/vpbe.h  |  182 +++
 include/media/davinci/vpbe_display.h  |  146 ++
 include/media/davinci/vpbe_osd.h  |  397 +
 include/media/davinci/vpbe_types.h|   91 ++
 include/media/davinci/vpbe_venc.h |   44 +
 22 files changed, 6507 insertions(+), 44 deletions(-)
 create mode 100644 Documentation/video4linux/README.davinci-vpbe
 create mode 100644 drivers/media/video/davinci/vpbe.c
 create mode 100644 drivers/media/video/davinci/vpbe_display.c
 create mode 100644 drivers/media/video/davinci/vpbe_osd.c
 create mode 100644 drivers/media/video/davinci/vpbe_osd_regs.h
 create mode 100644 drivers/media/video/davinci/vpbe_venc.c
 create mode 100644 drivers/media/video/davinci/vpbe_venc_regs.h
 create mode 100644 include/media/davinci/vpbe.h
 create mode 100644 include/media/davinci/vpbe_display.h
 create mode 100644 include/media/davinci/vpbe_osd.h
 create mode 100644 include/media/davinci/vpbe_types.h
 create mode 100644 include/media/davinci/vpbe_venc.h

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

[PATCH 1/3] [media] cx88: protect per-device driver list with device lock

[Jonathan Nieder]

The BKL conversion of this family of drivers seems to have gone wrong.
Opening cx88-blackbird will deadlock.  Various other uses of the
sub-device and driver lists appear to be subject to race conditions.

For example: various functions access drvlist without a relevant
lock held, which will race against removal of drivers.  Let's
start with that --- clean up by consistently protecting dev-drvlist
with dev-core-lock, noting driver functions that require the device
lock to be held or not held.

The only goal is to make the semantics clearer in preparation for
other changes.  There are still some relevant races (noted in
comments) and the deadlock noticed by Andi remains; later patches
will address that.

Based-on-patch-by: Ben Hutchings b...@decadent.org.uk
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
Cc: Andi Huber hob...@gmx.at
Cc: sta...@kernel.org
---
 drivers/media/video/cx88/cx88-blackbird.c |8 +++-
 drivers/media/video/cx88/cx88-dvb.c   |8 
 drivers/media/video/cx88/cx88-mpeg.c  |   11 +++
 drivers/media/video/cx88/cx88.h   |9 -
 4 files changed, 30 insertions(+), 6 deletions(-)

diff --git a/drivers/media/video/cx88/cx88-blackbird.c 
b/drivers/media/video/cx88/cx88-blackbird.c
index bca307e..85910c6 100644
--- a/drivers/media/video/cx88/cx88-blackbird.c
+++ b/drivers/media/video/cx88/cx88-blackbird.c
@@ -1122,10 +1122,16 @@ static int mpeg_release(struct file *file)
mutex_lock(dev-core-lock);
file-private_data = NULL;
kfree(fh);
-   mutex_unlock(dev-core-lock);
 
/* Make sure we release the hardware */
drv = cx8802_get_driver(dev, CX88_MPEG_BLACKBIRD);
+   mutex_unlock(dev-core-lock);
+
+   /*
+* NEEDSWORK: the driver can be yanked from under our feet.
+* The following really ought to be protected with core-lock.
+*/
+
if (drv)
drv-request_release(drv);
 
diff --git a/drivers/media/video/cx88/cx88-dvb.c 
b/drivers/media/video/cx88/cx88-dvb.c
index 7b8c9d3..5d0f947 100644
--- a/drivers/media/video/cx88/cx88-dvb.c
+++ b/drivers/media/video/cx88/cx88-dvb.c
@@ -133,7 +133,15 @@ static int cx88_dvb_bus_ctrl(struct dvb_frontend* fe, int 
acquire)
return -EINVAL;
}
 
+   mutex_lock(dev-core-lock);
drv = cx8802_get_driver(dev, CX88_MPEG_DVB);
+   mutex_unlock(dev-core-lock);
+
+   /*
+* NEEDSWORK: The driver can be yanked from under our feet now.
+* We ought to keep holding core-lock during the below.
+*/
+
if (drv) {
if (acquire){
dev-frontends.active_fe_id = fe_id;
diff --git a/drivers/media/video/cx88/cx88-mpeg.c 
b/drivers/media/video/cx88/cx88-mpeg.c
index addf954..918172b 100644
--- a/drivers/media/video/cx88/cx88-mpeg.c
+++ b/drivers/media/video/cx88/cx88-mpeg.c
@@ -748,6 +748,8 @@ int cx8802_unregister_driver(struct cx8802_driver *drv)
   dev-pci-subsystem_device, dev-core-board.name,
   dev-core-boardnr);
 
+   mutex_lock(dev-core-lock);
+
list_for_each_entry_safe(d, dtmp, dev-drvlist, drvlist) {
/* only unregister the correct driver type */
if (d-type_id != drv-type_id)
@@ -755,15 +757,14 @@ int cx8802_unregister_driver(struct cx8802_driver *drv)
 
err = d-remove(d);
if (err == 0) {
-   mutex_lock(drv-core-lock);
list_del(d-drvlist);
-   mutex_unlock(drv-core-lock);
kfree(d);
} else
printk(KERN_ERR %s/2: cx8802 driver remove 
   failed (%d)\n, dev-core-name, err);
}
 
+   mutex_unlock(dev-core-lock);
}
 
return err;
@@ -827,6 +828,8 @@ static void __devexit cx8802_remove(struct pci_dev *pci_dev)
 
flush_request_modules(dev);
 
+   mutex_lock(dev-core-lock);
+
if (!list_empty(dev-drvlist)) {
struct cx8802_driver *drv, *tmp;
int err;
@@ -838,9 +841,7 @@ static void __devexit cx8802_remove(struct pci_dev *pci_dev)
list_for_each_entry_safe(drv, tmp, dev-drvlist, drvlist) {
err = drv-remove(drv);
if (err == 0) {
-   mutex_lock(drv-core-lock);
list_del(drv-drvlist);
-   mutex_unlock(drv-core-lock);
} else
printk(KERN_ERR %s/2: cx8802 driver remove 
   failed (%d)\n, dev-core-name, err);
@@ -848,6 +849,8 @@ static void __devexit cx8802_remove(struct pci_dev *pci_dev)
}
}
 
+   

[PATCH v16 02/13] davinci vpbe: VPBE display driver

[Manjunath Hadli]

This patch implements the core functionality of the display driver,
mainly controlling the VENC and other encoders, and acting as
the one point interface for the main V4L2 driver. This implements
the core of each of the V4L2 IOCTLs.

Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Acked-by: Muralidharan Karicheri m-kariche...@ti.com
Acked-by: Hans Verkuil hverk...@xs4all.nl
---
 drivers/media/video/davinci/vpbe.c |  827 
 include/media/davinci/vpbe.h   |  182 
 2 files changed, 1009 insertions(+), 0 deletions(-)
 create mode 100644 drivers/media/video/davinci/vpbe.c
 create mode 100644 include/media/davinci/vpbe.h

diff --git a/drivers/media/video/davinci/vpbe.c 
b/drivers/media/video/davinci/vpbe.c
new file mode 100644
index 000..2cdba70
--- /dev/null
+++ b/drivers/media/video/davinci/vpbe.c
@@ -0,0 +1,827 @@
+/*
+ * Copyright (C) 2010 Texas Instruments Inc
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation version 2.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+#include linux/kernel.h
+#include linux/init.h
+#include linux/module.h
+#include linux/errno.h
+#include linux/fs.h
+#include linux/string.h
+#include linux/wait.h
+#include linux/time.h
+#include linux/platform_device.h
+#include linux/io.h
+#include linux/slab.h
+#include linux/clk.h
+#include linux/err.h
+
+#include media/v4l2-device.h
+#include media/davinci/vpbe_types.h
+#include media/davinci/vpbe.h
+#include media/davinci/vpss.h
+#include media/davinci/vpbe_venc.h
+
+#define VPBE_DEFAULT_OUTPUTComposite
+#define VPBE_DEFAULT_MODE  ntsc
+
+static char *def_output = VPBE_DEFAULT_OUTPUT;
+static char *def_mode = VPBE_DEFAULT_MODE;
+static  struct osd_state *osd_device;
+static struct venc_platform_data *venc_device;
+static int debug;
+
+module_param(def_output, charp, S_IRUGO);
+module_param(def_mode, charp, S_IRUGO);
+module_param(debug, int, 0644);
+
+MODULE_PARM_DESC(def_output, vpbe output name (default:Composite));
+MODULE_PARM_DESC(def_mode, vpbe output mode name (default:ntsc);
+MODULE_PARM_DESC(debug, Debug level 0-1);
+
+MODULE_DESCRIPTION(TI DMXXX VPBE Display controller);
+MODULE_LICENSE(GPL);
+MODULE_AUTHOR(Texas Instruments);
+
+/**
+ * vpbe_current_encoder_info - Get config info for current encoder
+ * @vpbe_dev - vpbe device ptr
+ *
+ * Return ptr to current encoder config info
+ */
+static struct encoder_config_info*
+vpbe_current_encoder_info(struct vpbe_device *vpbe_dev)
+{
+   struct vpbe_config *cfg = vpbe_dev-cfg;
+   int index = vpbe_dev-current_sd_index;
+
+   return ((index == 0) ? cfg-venc :
+   cfg-ext_encoders[index-1]);
+}
+
+/**
+ * vpbe_find_encoder_sd_index - Given a name find encoder sd index
+ *
+ * @vpbe_config - ptr to vpbe cfg
+ * @output_index - index used by application
+ *
+ * Return sd index of the encoder
+ */
+static int vpbe_find_encoder_sd_index(struct vpbe_config *cfg,
+int index)
+{
+   char *encoder_name = cfg-outputs[index].subdev_name;
+   int i;
+
+   /* Venc is always first */
+   if (!strcmp(encoder_name, cfg-venc.module_name))
+   return 0;
+
+   for (i = 0; i  cfg-num_ext_encoders; i++) {
+   if (!strcmp(encoder_name,
+cfg-ext_encoders[i].module_name))
+   return i+1;
+   }
+   return -EINVAL;
+}
+
+/**
+ * vpbe_g_cropcap - Get crop capabilities of the display
+ * @vpbe_dev - vpbe device ptr
+ * @cropcap - cropcap is a ptr to struct v4l2_cropcap
+ *
+ * Update the crop capabilities in crop cap for current
+ * mode
+ */
+static int vpbe_g_cropcap(struct vpbe_device *vpbe_dev,
+ struct v4l2_cropcap *cropcap)
+{
+   if (NULL == cropcap)
+   return -EINVAL;
+   cropcap-bounds.left = 0;
+   cropcap-bounds.top = 0;
+   cropcap-bounds.width = vpbe_dev-current_timings.xres;
+   cropcap-bounds.height = vpbe_dev-current_timings.yres;
+   cropcap-defrect = cropcap-bounds;
+   return 0;
+}
+
+/**
+ * vpbe_enum_outputs - enumerate outputs
+ * @vpbe_dev - vpbe device ptr
+ * @output - ptr to v4l2_output structure
+ *
+ * Enumerates the outputs available at the vpbe display
+ * returns the status, -EINVAL if end of output list
+ */
+static int vpbe_enum_outputs(struct vpbe_device *vpbe_dev,
+struct v4l2_output *output)
+{
+   struct 

[PATCH v16 03/13] davinci vpbe: OSD(On Screen Display) block

[Manjunath Hadli]

This patch implements the functionality of the OSD block
of the VPBE. The OSD in total supports 4 planes or Video
sources - 2 mainly RGB and 2 Video. The patch implements general
handling of all the planes, with specific emphasis on the Video
plane capabilities as the Video planes are supported through the
V4L2 driver.

Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Acked-by: Muralidharan Karicheri m-kariche...@ti.com
Acked-by: Hans Verkuil hverk...@xs4all.nl
---
 drivers/media/video/davinci/vpbe_osd.c  | 1216 +++
 drivers/media/video/davinci/vpbe_osd_regs.h |  364 
 include/media/davinci/vpbe_osd.h|  397 +
 3 files changed, 1977 insertions(+), 0 deletions(-)
 create mode 100644 drivers/media/video/davinci/vpbe_osd.c
 create mode 100644 drivers/media/video/davinci/vpbe_osd_regs.h
 create mode 100644 include/media/davinci/vpbe_osd.h

diff --git a/drivers/media/video/davinci/vpbe_osd.c 
b/drivers/media/video/davinci/vpbe_osd.c
new file mode 100644
index 000..bbc43ea
--- /dev/null
+++ b/drivers/media/video/davinci/vpbe_osd.c
@@ -0,0 +1,1216 @@
+/*
+ * Copyright (C) 2007-2010 Texas Instruments Inc
+ * Copyright (C) 2007 MontaVista Software, Inc.
+ *
+ * Andy Lowe (al...@mvista.com), MontaVista Software
+ * - Initial version
+ * Murali Karicheri (mkarich...@gmail.com), Texas Instruments Ltd.
+ * - ported to sub device interface
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation version 2.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ *
+ */
+#include linux/module.h
+#include linux/kernel.h
+#include linux/interrupt.h
+#include linux/platform_device.h
+#include linux/clk.h
+#include linux/slab.h
+
+#include mach/io.h
+#include mach/cputype.h
+#include mach/hardware.h
+
+#include media/davinci/vpss.h
+#include media/v4l2-device.h
+#include media/davinci/vpbe_types.h
+#include media/davinci/vpbe_osd.h
+
+#include linux/io.h
+#include vpbe_osd_regs.h
+
+#define MODULE_NAMEVPBE_OSD_SUBDEV_NAME
+
+/* register access routines */
+static inline u32 osd_read(struct osd_state *sd, u32 offset)
+{
+   struct osd_state *osd = sd;
+   return readl(osd-osd_base + offset);
+}
+
+static inline u32 osd_write(struct osd_state *sd, u32 val, u32 offset)
+{
+   struct osd_state *osd = sd;
+   writel(val, osd-osd_base + offset);
+   return val;
+}
+
+static inline u32 osd_set(struct osd_state *sd, u32 mask, u32 offset)
+{
+   struct osd_state *osd = sd;
+
+   u32 addr = osd-osd_base + offset;
+   u32 val = readl(addr) | mask;
+
+   writel(val, addr);
+   return val;
+}
+
+static inline u32 osd_clear(struct osd_state *sd, u32 mask, u32 offset)
+{
+   struct osd_state *osd = sd;
+   u32 addr = osd-osd_base + offset;
+   u32 val = readl(addr)  ~mask;
+
+   writel(val, addr);
+   return val;
+}
+
+static inline u32 osd_modify(struct osd_state *sd, u32 mask, u32 val,
+u32 offset)
+{
+   struct osd_state *osd = sd;
+
+   u32 addr = osd-osd_base + offset;
+   u32 new_val = (readl(addr)  ~mask) | (val  mask);
+   writel(new_val, addr);
+   return new_val;
+}
+
+/* define some macros for layer and pixfmt classification */
+#define is_osd_win(layer) (((layer) == WIN_OSD0) || ((layer) == WIN_OSD1))
+#define is_vid_win(layer) (((layer) == WIN_VID0) || ((layer) == WIN_VID1))
+#define is_rgb_pixfmt(pixfmt) \
+   (((pixfmt) == PIXFMT_RGB565) || ((pixfmt) == PIXFMT_RGB888))
+#define is_yc_pixfmt(pixfmt) \
+   (((pixfmt) == PIXFMT_YCbCrI) || ((pixfmt) == PIXFMT_YCrCbI) || \
+   ((pixfmt) == PIXFMT_NV12))
+#define MAX_WIN_SIZE OSD_VIDWIN0XP_V0X
+#define MAX_LINE_LENGTH (OSD_VIDWIN0OFST_V0LO  5)
+
+/**
+ * _osd_dm6446_vid0_pingpong() - field inversion fix for DM6446
+ * @sd - ptr to struct osd_state
+ * @field_inversion - inversion flag
+ * @fb_base_phys - frame buffer address
+ * @lconfig - ptr to layer config
+ *
+ * This routine implements a workaround for the field signal inversion silicon
+ * erratum described in Advisory 1.3.8 for the DM6446.  The fb_base_phys and
+ * lconfig parameters apply to the vid0 window.  This routine should be called
+ * whenever the vid0 layer configuration or start address is modified, or when
+ * the OSD field inversion setting is modified.
+ * Returns: 1 if the ping-pong buffers need to be toggled in the vsync isr, or
+ *  0 otherwise
+ */
+static int 

[PATCH v16 04/13] davinci vpbe: VENC( Video Encoder) implementation

[Manjunath Hadli]

This patch adds the VENC or the Video encoder, which is responsible
for the blending of all source planes and timing generation for Video
modes like NTSC, PAL and other digital outputs. the VENC implementation
currently supports COMPOSITE and COMPONENT outputs and NTSC and PAL
resolutions through the analog DACs. The venc block is implemented
as a subdevice, allowing for additional external and internal encoders
of other kind to plug-in.

Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Acked-by: Muralidharan Karicheri m-kariche...@ti.com
Acked-by: Hans Verkuil hverk...@xs4all.nl
---
 drivers/media/video/davinci/vpbe_venc.c  |  556 ++
 drivers/media/video/davinci/vpbe_venc_regs.h |  177 
 include/media/davinci/vpbe_venc.h|   44 ++
 3 files changed, 777 insertions(+), 0 deletions(-)
 create mode 100644 drivers/media/video/davinci/vpbe_venc.c
 create mode 100644 drivers/media/video/davinci/vpbe_venc_regs.h
 create mode 100644 include/media/davinci/vpbe_venc.h

diff --git a/drivers/media/video/davinci/vpbe_venc.c 
b/drivers/media/video/davinci/vpbe_venc.c
new file mode 100644
index 000..1131e2d
--- /dev/null
+++ b/drivers/media/video/davinci/vpbe_venc.c
@@ -0,0 +1,556 @@
+/*
+ * Copyright (C) 2010 Texas Instruments Inc
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation version 2.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ */
+#include linux/module.h
+#include linux/kernel.h
+#include linux/init.h
+#include linux/ctype.h
+#include linux/delay.h
+#include linux/device.h
+#include linux/interrupt.h
+#include linux/platform_device.h
+#include linux/videodev2.h
+#include linux/slab.h
+
+#include mach/hardware.h
+#include mach/mux.h
+#include mach/io.h
+#include mach/i2c.h
+
+#include linux/io.h
+
+#include media/davinci/vpbe_types.h
+#include media/davinci/vpbe_venc.h
+#include media/davinci/vpss.h
+#include media/v4l2-device.h
+
+#include vpbe_venc_regs.h
+
+#define MODULE_NAMEVPBE_VENC_SUBDEV_NAME
+
+static int debug = 2;
+module_param(debug, int, 0644);
+MODULE_PARM_DESC(debug, Debug level 0-2);
+
+struct venc_state {
+   struct v4l2_subdev sd;
+   struct venc_callback *callback;
+   struct venc_platform_data *pdata;
+   struct device *pdev;
+   u32 output;
+   v4l2_std_id std;
+   spinlock_t lock;
+   void __iomem *venc_base;
+   void __iomem *vdaccfg_reg;
+};
+
+static inline struct venc_state *to_state(struct v4l2_subdev *sd)
+{
+   return container_of(sd, struct venc_state, sd);
+}
+
+static inline u32 venc_read(struct v4l2_subdev *sd, u32 offset)
+{
+   struct venc_state *venc = to_state(sd);
+
+   return readl(venc-venc_base + offset);
+}
+
+static inline u32 venc_write(struct v4l2_subdev *sd, u32 offset, u32 val)
+{
+   struct venc_state *venc = to_state(sd);
+   writel(val, (venc-venc_base + offset));
+   return val;
+}
+
+static inline u32 venc_modify(struct v4l2_subdev *sd, u32 offset,
+u32 val, u32 mask)
+{
+   u32 new_val = (venc_read(sd, offset)  ~mask) | (val  mask);
+
+   venc_write(sd, offset, new_val);
+   return new_val;
+}
+
+static inline u32 vdaccfg_write(struct v4l2_subdev *sd, u32 val)
+{
+   struct venc_state *venc = to_state(sd);
+
+   writel(val, venc-vdaccfg_reg);
+
+   val = readl(venc-vdaccfg_reg);
+   return val;
+}
+
+/* This function sets the dac of the VPBE for various outputs
+ */
+static int venc_set_dac(struct v4l2_subdev *sd, u32 out_index)
+{
+   int ret = 0;
+
+   switch (out_index) {
+   case 0:
+   v4l2_dbg(debug, 1, sd, Setting output to Composite\n);
+   venc_write(sd, VENC_DACSEL, 0);
+   break;
+   case 1:
+   v4l2_dbg(debug, 1, sd, Setting output to S-Video\n);
+   venc_write(sd, VENC_DACSEL, 0x210);
+   break;
+   case  2:
+   venc_write(sd, VENC_DACSEL, 0x543);
+   break;
+   default:
+   ret = -EINVAL;
+   }
+   return ret;
+}
+
+static void venc_enabledigitaloutput(struct v4l2_subdev *sd, int benable)
+{
+   v4l2_dbg(debug, 2, sd, venc_enabledigitaloutput\n);
+
+   if (benable) {
+   venc_write(sd, VENC_VMOD, 0);
+   venc_write(sd, VENC_CVBS, 0);
+   venc_write(sd, VENC_LCDOUT, 0);
+   venc_write(sd, VENC_HSPLS, 0);
+   

[PATCH 2/3] [media] cx88: fix locking of sub-driver operations

[Jonathan Nieder]

From: Ben Hutchings b...@decadent.org.uk
Date: Tue, 29 Mar 2011 03:25:15 +0100

The BKL conversion of this family of drivers seems to have gone wrong.
Opening cx88-blackbird will deadlock.  Various other uses of the
sub-device and driver lists appear to be subject to race conditions.

In particular, mpeg_ops::open in the cx2388x blackbird driver acquires
the device lock and then calls the drivers' request_acquire, which
tries to acquire the lock again --- deadlock.  Fix it by clarifying
the semantics of request_acquire, request_release, advise_acquire, and
advise_release: all require the caller to hold the device lock now.

[jn: split from a larger patch, with new commit message]

Reported-by: Andi Huber hob...@gmx.at
Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=31962
Signed-off-by: Ben Hutchings b...@decadent.org.uk
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
Cc: sta...@kernel.org
---
 drivers/media/video/cx88/cx88-blackbird.c |9 ++---
 drivers/media/video/cx88/cx88-dvb.c   |8 +---
 drivers/media/video/cx88/cx88-mpeg.c  |4 
 drivers/media/video/cx88/cx88.h   |3 ++-
 4 files changed, 5 insertions(+), 19 deletions(-)

diff --git a/drivers/media/video/cx88/cx88-blackbird.c 
b/drivers/media/video/cx88/cx88-blackbird.c
index 85910c6..a6f7d53 100644
--- a/drivers/media/video/cx88/cx88-blackbird.c
+++ b/drivers/media/video/cx88/cx88-blackbird.c
@@ -1125,18 +1125,13 @@ static int mpeg_release(struct file *file)
 
/* Make sure we release the hardware */
drv = cx8802_get_driver(dev, CX88_MPEG_BLACKBIRD);
-   mutex_unlock(dev-core-lock);
-
-   /*
-* NEEDSWORK: the driver can be yanked from under our feet.
-* The following really ought to be protected with core-lock.
-*/
-
if (drv)
drv-request_release(drv);
 
atomic_dec(dev-core-mpeg_users);
 
+   mutex_unlock(dev-core-lock);
+
return 0;
 }
 
diff --git a/drivers/media/video/cx88/cx88-dvb.c 
b/drivers/media/video/cx88/cx88-dvb.c
index 5d0f947..c69df7e 100644
--- a/drivers/media/video/cx88/cx88-dvb.c
+++ b/drivers/media/video/cx88/cx88-dvb.c
@@ -135,13 +135,6 @@ static int cx88_dvb_bus_ctrl(struct dvb_frontend* fe, int 
acquire)
 
mutex_lock(dev-core-lock);
drv = cx8802_get_driver(dev, CX88_MPEG_DVB);
-   mutex_unlock(dev-core-lock);
-
-   /*
-* NEEDSWORK: The driver can be yanked from under our feet now.
-* We ought to keep holding core-lock during the below.
-*/
-
if (drv) {
if (acquire){
dev-frontends.active_fe_id = fe_id;
@@ -151,6 +144,7 @@ static int cx88_dvb_bus_ctrl(struct dvb_frontend* fe, int 
acquire)
dev-frontends.active_fe_id = 0;
}
}
+   mutex_unlock(dev-core-lock);
 
return ret;
 }
diff --git a/drivers/media/video/cx88/cx88-mpeg.c 
b/drivers/media/video/cx88/cx88-mpeg.c
index 918172b..9147c16 100644
--- a/drivers/media/video/cx88/cx88-mpeg.c
+++ b/drivers/media/video/cx88/cx88-mpeg.c
@@ -624,13 +624,11 @@ static int cx8802_request_acquire(struct cx8802_driver 
*drv)
 
if (drv-advise_acquire)
{
-   mutex_lock(drv-core-lock);
core-active_ref++;
if (core-active_type_id == CX88_BOARD_NONE) {
core-active_type_id = drv-type_id;
drv-advise_acquire(drv);
}
-   mutex_unlock(drv-core-lock);
 
mpeg_dbg(1,%s() Post acquire GPIO=%x\n, __func__, 
cx_read(MO_GP0_IO));
}
@@ -643,14 +641,12 @@ static int cx8802_request_release(struct cx8802_driver 
*drv)
 {
struct cx88_core *core = drv-core;
 
-   mutex_lock(drv-core-lock);
if (drv-advise_release  --core-active_ref == 0)
{
drv-advise_release(drv);
core-active_type_id = CX88_BOARD_NONE;
mpeg_dbg(1,%s() Post release GPIO=%x\n, __func__, 
cx_read(MO_GP0_IO));
}
-   mutex_unlock(drv-core-lock);
 
return 0;
 }
diff --git a/drivers/media/video/cx88/cx88.h b/drivers/media/video/cx88/cx88.h
index e3d56c2..9731daa 100644
--- a/drivers/media/video/cx88/cx88.h
+++ b/drivers/media/video/cx88/cx88.h
@@ -510,7 +510,8 @@ struct cx8802_driver {
/* Caller must _not_ hold core-lock */
int (*probe)(struct cx8802_driver *drv);
 
-   /* Caller must hold core-lock */
+   /* Callers to the following functions must hold core-lock */
+
int (*remove)(struct cx8802_driver *drv);
 
/* MPEG 8802 - mini driver - Access for hardware control */
-- 
1.7.5.rc0

--
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 v16 05/13] davinci vpbe: Build infrastructure for VPBE driver

[Manjunath Hadli]

This patch adds the build infra-structure for Davinci
VPBE dislay driver.

Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Acked-by: Muralidharan Karicheri m-kariche...@ti.com
Acked-by: Hans Verkuil hverk...@xs4all.nl
---
 drivers/media/video/davinci/Kconfig  |   22 ++
 drivers/media/video/davinci/Makefile |2 ++
 2 files changed, 24 insertions(+), 0 deletions(-)

diff --git a/drivers/media/video/davinci/Kconfig 
b/drivers/media/video/davinci/Kconfig
index 6b19540..a7f11e7 100644
--- a/drivers/media/video/davinci/Kconfig
+++ b/drivers/media/video/davinci/Kconfig
@@ -91,3 +91,25 @@ config VIDEO_ISIF
 
   To compile this driver as a module, choose M here: the
   module will be called vpfe.
+
+config VIDEO_DM644X_VPBE
+   tristate DM644X VPBE HW module
+   select VIDEO_VPSS_SYSTEM
+   select VIDEOBUF_DMA_CONTIG
+   help
+   Enables VPBE modules used for display on a DM644x
+   SoC.
+
+   To compile this driver as a module, choose M here: the
+   module will be called vpbe.
+
+
+config VIDEO_VPBE_DISPLAY
+   tristate VPBE V4L2 Display driver
+   select VIDEO_DM644X_VPBE
+   default y
+   help
+   Enables VPBE V4L2 Display driver on a DMXXX device
+
+   To compile this driver as a module, choose M here: the
+   module will be called vpbe_display.
diff --git a/drivers/media/video/davinci/Makefile 
b/drivers/media/video/davinci/Makefile
index a379557..ae7dafb 100644
--- a/drivers/media/video/davinci/Makefile
+++ b/drivers/media/video/davinci/Makefile
@@ -16,3 +16,5 @@ obj-$(CONFIG_VIDEO_VPFE_CAPTURE) += vpfe_capture.o
 obj-$(CONFIG_VIDEO_DM6446_CCDC) += dm644x_ccdc.o
 obj-$(CONFIG_VIDEO_DM355_CCDC) += dm355_ccdc.o
 obj-$(CONFIG_VIDEO_ISIF) += isif.o
+obj-$(CONFIG_VIDEO_DM644X_VPBE) += vpbe.o vpbe_osd.o vpbe_venc.o
+obj-$(CONFIG_VIDEO_VPBE_DISPLAY) += vpbe_display.o
-- 
1.6.2.4

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

[PATCH v16 06/13] davinci vpbe: Readme text for Dm6446 vpbe

[Manjunath Hadli]

Please refer to this file for detailed documentation of
davinci vpbe v4l2 driver.

Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Acked-by: Muralidharan Karicheri m-kariche...@ti.com
Acked-by: Hans Verkuil hverk...@xs4all.nl
---
 Documentation/video4linux/README.davinci-vpbe |   93 +
 1 files changed, 93 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/video4linux/README.davinci-vpbe

diff --git a/Documentation/video4linux/README.davinci-vpbe 
b/Documentation/video4linux/README.davinci-vpbe
new file mode 100644
index 000..7a460b0
--- /dev/null
+++ b/Documentation/video4linux/README.davinci-vpbe
@@ -0,0 +1,93 @@
+
+VPBE V4L2 driver design
+ ==
+
+ File partitioning
+ -
+ V4L2 display device driver
+ drivers/media/video/davinci/vpbe_display.c
+ drivers/media/video/davinci/vpbe_display.h
+
+ VPBE display controller
+ drivers/media/video/davinci/vpbe.c
+ drivers/media/video/davinci/vpbe.h
+
+ VPBE venc sub device driver
+ drivers/media/video/davinci/vpbe_venc.c
+ drivers/media/video/davinci/vpbe_venc.h
+ drivers/media/video/davinci/vpbe_venc_regs.h
+
+ VPBE osd driver
+ drivers/media/video/davinci/vpbe_osd.c
+ drivers/media/video/davinci/vpbe_osd.h
+ drivers/media/video/davinci/vpbe_osd_regs.h
+
+ Functional partitioning
+ ---
+
+ Consists of the following (in the same order as the list under file
+ partitioning):-
+
+ 1. V4L2 display driver
+Implements creation of video2 and video3 device nodes and
+provides v4l2 device interface to manage VID0 and VID1 layers.
+
+ 2. Display controller
+Loads up VENC, OSD and external encoders such as ths8200. It provides
+a set of API calls to V4L2 drivers to set the output/standards
+in the VENC or external sub devices. It also provides
+a device object to access the services from OSD subdevice
+using sub device ops. The connection of external encoders to VENC LCD
+controller port is done at init time based on default output and standard
+selection or at run time when application change the output through
+V4L2 IOCTLs.
+
+When connected to an external encoder, vpbe controller is also responsible
+for setting up the interface between VENC and external encoders based on
+board specific settings (specified in board-xxx-evm.c). This allows
+interfacing external encoders such as ths8200. The setup_if_config()
+is implemented for this as well as configure_venc() (part of the next 
patch)
+API to set timings in VENC for a specific display resolution. As of this
+patch series, the interconnection and enabling and setting of the external
+encoders is not present, and would be a part of the next patch series.
+
+ 3. VENC subdevice module
+Responsible for setting outputs provided through internal DACs and also
+setting timings at LCD controller port when external encoders are connected
+at the port or LCD panel timings required. When external encoder/LCD panel
+is connected, the timings for a specific standard/preset is retrieved from
+the board specific table and the values are used to set the timings in
+venc using non-standard timing mode.
+
+Support LCD Panel displays using the VENC. For example to support a Logic
+PD display, it requires setting up the LCD controller port with a set of
+timings for the resolution supported and setting the dot clock. So we could
+add the available outputs as a board specific entry (i.e add the LogicPD
+output name to board-xxx-evm.c). A table of timings for various LCDs
+supported can be maintained in the board specific setup file to support
+various LCD displays.As of this patch a basic driver is present, and this
+support for external encoders and displays forms a part of the next
+patch series.
+
+ 4. OSD module
+OSD module implements all OSD layer management and hardware specific
+features. The VPBE module interacts with the OSD for enabling and
+disabling appropriate features of the OSD.
+
+ Current status:-
+
+ A fully functional working version of the V4L2 driver is available. This
+ driver has been tested with NTSC and PAL standards and buffer streaming.
+
+ Following are TBDs.
+
+ vpbe display controller
+- Add support for external encoders.
+- add support for selecting external encoder as default at probe time.
+
+ vpbe venc sub device
+- add timings for supporting ths8200
+- add support for LogicPD LCD.
+
+ FB drivers
+- Add support for fbdev drivers.- Ready and part of subsequent patches.
-- 
1.6.2.4

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

[PATCH v18 07/13] davinci: move DM64XX_VDD3P3V_PWDN to devices.c

[Manjunath Hadli]

Move the definition of DM64XX_VDD3P3V_PWDN from hardware.h
to devices.c since it is used only there.

Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Acked-by: Sekhar Nori nsek...@ti.com
---
 arch/arm/mach-davinci/devices.c   |1 +
 arch/arm/mach-davinci/include/mach/hardware.h |3 ---
 2 files changed, 1 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-davinci/devices.c b/arch/arm/mach-davinci/devices.c
index 22ebc64..4e1b663 100644
--- a/arch/arm/mach-davinci/devices.c
+++ b/arch/arm/mach-davinci/devices.c
@@ -182,6 +182,7 @@ static struct platform_device davinci_mmcsd1_device = {
.resource = mmcsd1_resources,
 };
 
+#define DM64XX_VDD3P3V_PWDN0x48
 
 void __init davinci_setup_mmc(int module, struct davinci_mmc_config *config)
 {
diff --git a/arch/arm/mach-davinci/include/mach/hardware.h 
b/arch/arm/mach-davinci/include/mach/hardware.h
index c45ba1f..414e0b9 100644
--- a/arch/arm/mach-davinci/include/mach/hardware.h
+++ b/arch/arm/mach-davinci/include/mach/hardware.h
@@ -21,9 +21,6 @@
  */
 #define DAVINCI_SYSTEM_MODULE_BASE0x01C4
 
-/* System control register offsets */
-#define DM64XX_VDD3P3V_PWDN0x48
-
 /*
  * I/O mapping
  */
-- 
1.6.2.4

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

[PATCH v18 10/13] davinci: dm644x: change vpfe capture structure variables for consistency

[Manjunath Hadli]

Add SoC and board prefixes to variable names so that it is
consistent with the rest of the file.

Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Acked-by: Sekhar Nori nsek...@ti.com
---
 arch/arm/mach-davinci/board-dm644x-evm.c |   24 
 arch/arm/mach-davinci/dm644x.c   |   12 ++--
 2 files changed, 18 insertions(+), 18 deletions(-)

diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c 
b/arch/arm/mach-davinci/board-dm644x-evm.c
index 0ca90b8..6919f28 100644
--- a/arch/arm/mach-davinci/board-dm644x-evm.c
+++ b/arch/arm/mach-davinci/board-dm644x-evm.c
@@ -188,7 +188,7 @@ static struct platform_device davinci_fb_device = {
.num_resources = 0,
 };
 
-static struct tvp514x_platform_data tvp5146_pdata = {
+static struct tvp514x_platform_data dm644xevm_tvp5146_pdata = {
.clk_polarity = 0,
.hs_polarity = 1,
.vs_polarity = 1
@@ -196,7 +196,7 @@ static struct tvp514x_platform_data tvp5146_pdata = {
 
 #define TVP514X_STD_ALL(V4L2_STD_NTSC | V4L2_STD_PAL)
 /* Inputs available at the TVP5146 */
-static struct v4l2_input tvp5146_inputs[] = {
+static struct v4l2_input dm644xevm_tvp5146_inputs[] = {
{
.index = 0,
.name = Composite,
@@ -216,7 +216,7 @@ static struct v4l2_input tvp5146_inputs[] = {
  * ouput that goes to vpfe. There is a one to one correspondence
  * with tvp5146_inputs
  */
-static struct vpfe_route tvp5146_routes[] = {
+static struct vpfe_route dm644xevm_tvp5146_routes[] = {
{
.input = INPUT_CVBS_VI2B,
.output = OUTPUT_10BIT_422_EMBEDDED_SYNC,
@@ -227,13 +227,13 @@ static struct vpfe_route tvp5146_routes[] = {
},
 };
 
-static struct vpfe_subdev_info vpfe_sub_devs[] = {
+static struct vpfe_subdev_info dm644xevm_vpfe_sub_devs[] = {
{
.name = tvp5146,
.grp_id = 0,
-   .num_inputs = ARRAY_SIZE(tvp5146_inputs),
-   .inputs = tvp5146_inputs,
-   .routes = tvp5146_routes,
+   .num_inputs = ARRAY_SIZE(dm644xevm_tvp5146_inputs),
+   .inputs = dm644xevm_tvp5146_inputs,
+   .routes = dm644xevm_tvp5146_routes,
.can_route = 1,
.ccdc_if_params = {
.if_type = VPFE_BT656,
@@ -242,15 +242,15 @@ static struct vpfe_subdev_info vpfe_sub_devs[] = {
},
.board_info = {
I2C_BOARD_INFO(tvp5146, 0x5d),
-   .platform_data = tvp5146_pdata,
+   .platform_data = dm644xevm_tvp5146_pdata,
},
},
 };
 
-static struct vpfe_config vpfe_cfg = {
-   .num_subdevs = ARRAY_SIZE(vpfe_sub_devs),
+static struct vpfe_config dm644xevm_capture_cfg = {
+   .num_subdevs = ARRAY_SIZE(dm644xevm_vpfe_sub_devs),
.i2c_adapter_id = 1,
-   .sub_devs = vpfe_sub_devs,
+   .sub_devs = dm644xevm_vpfe_sub_devs,
.card_name = DM6446 EVM,
.ccdc = DM6446 CCDC,
 };
@@ -629,7 +629,7 @@ static void __init
 davinci_evm_map_io(void)
 {
/* setup input configuration for VPFE input devices */
-   dm644x_set_vpfe_config(vpfe_cfg);
+   dm644x_set_vpfe_config(dm644xevm_capture_cfg);
dm644x_init();
 }
 
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index 6edb5d1..e258c54 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -606,7 +606,7 @@ static struct platform_device dm644x_vpss_device = {
.resource   = dm644x_vpss_resources,
 };
 
-static struct resource vpfe_resources[] = {
+static struct resource dm644x_vpfe_resources[] = {
{
.start  = IRQ_VDINT0,
.end= IRQ_VDINT0,
@@ -640,11 +640,11 @@ static struct platform_device dm644x_ccdc_dev = {
},
 };
 
-static struct platform_device vpfe_capture_dev = {
+static struct platform_device dm644x_vpfe_dev = {
.name   = CAPTURE_DRV_NAME,
.id = -1,
-   .num_resources  = ARRAY_SIZE(vpfe_resources),
-   .resource   = vpfe_resources,
+   .num_resources  = ARRAY_SIZE(dm644x_vpfe_resources),
+   .resource   = dm644x_vpfe_resources,
.dev = {
.dma_mask   = vpfe_capture_dma_mask,
.coherent_dma_mask  = DMA_BIT_MASK(32),
@@ -653,7 +653,7 @@ static struct platform_device vpfe_capture_dev = {
 
 void dm644x_set_vpfe_config(struct vpfe_config *cfg)
 {
-   vpfe_capture_dev.dev.platform_data = cfg;
+   dm644x_vpfe_dev.dev.platform_data = cfg;
 }
 
 /*--*/
@@ -801,7 +801,7 @@ static int __init dm644x_init_devices(void)
 
platform_device_register(dm644x_vpss_device);
platform_device_register(dm644x_ccdc_dev);
-   platform_device_register(vpfe_capture_dev);
+   

[PATCH v18 11/13] davinci: dm644x: move vpfe init from soc to board specific files

[Manjunath Hadli]

Move all vpfe platform device registrations to the board specific
file like the rest of the devices, and have all of them together.

This would remove the  restriction of inclusion and registration of
vpfe platform devices for non-vpfe boards.

Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Acked-by: Sekhar Nori nsek...@ti.com
---
 arch/arm/mach-davinci/board-dm644x-evm.c|3 +-
 arch/arm/mach-davinci/dm644x.c  |   29 +++---
 arch/arm/mach-davinci/include/mach/dm644x.h |2 +-
 3 files changed, 19 insertions(+), 15 deletions(-)

diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c 
b/arch/arm/mach-davinci/board-dm644x-evm.c
index 6919f28..d1542b1 100644
--- a/arch/arm/mach-davinci/board-dm644x-evm.c
+++ b/arch/arm/mach-davinci/board-dm644x-evm.c
@@ -628,8 +628,6 @@ static struct davinci_uart_config uart_config __initdata = {
 static void __init
 davinci_evm_map_io(void)
 {
-   /* setup input configuration for VPFE input devices */
-   dm644x_set_vpfe_config(dm644xevm_capture_cfg);
dm644x_init();
 }
 
@@ -701,6 +699,7 @@ static __init void davinci_evm_init(void)
evm_init_i2c();
 
davinci_setup_mmc(0, dm6446evm_mmc_config);
+   dm644x_init_video(dm644xevm_capture_cfg);
 
davinci_serial_init(uart_config);
dm644x_init_asp(dm644x_evm_snd_data);
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index e258c54..36d4d72 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -651,11 +651,6 @@ static struct platform_device dm644x_vpfe_dev = {
},
 };
 
-void dm644x_set_vpfe_config(struct vpfe_config *cfg)
-{
-   dm644x_vpfe_dev.dev.platform_data = cfg;
-}
-
 /*--*/
 
 static struct map_desc dm644x_io_desc[] = {
@@ -784,14 +779,28 @@ void __init dm644x_init(void)
davinci_map_sysmod();
 }
 
+static struct platform_device *dm644x_video_devices[] __initdata = {
+   dm644x_vpss_device,
+   dm644x_ccdc_dev,
+   dm644x_vpfe_dev,
+};
+
+int __init dm644x_init_video(struct vpfe_config *vpfe_cfg)
+{
+   dm644x_vpfe_dev.dev.platform_data = vpfe_cfg;
+   /* Add ccdc clock aliases */
+   clk_add_alias(master, dm644x_ccdc_dev.name, vpss_master, NULL);
+   clk_add_alias(slave, dm644x_ccdc_dev.name, vpss_slave, NULL);
+   platform_add_devices(dm644x_video_devices,
+   ARRAY_SIZE(dm644x_video_devices));
+   return 0;
+}
+
 static int __init dm644x_init_devices(void)
 {
if (!cpu_is_davinci_dm644x())
return 0;
 
-   /* Add ccdc clock aliases */
-   clk_add_alias(master, dm644x_ccdc_dev.name, vpss_master, NULL);
-   clk_add_alias(slave, dm644x_ccdc_dev.name, vpss_slave, NULL);
platform_device_register(dm644x_edma_device);
 
platform_device_register(dm644x_mdio_device);
@@ -799,10 +808,6 @@ static int __init dm644x_init_devices(void)
clk_add_alias(NULL, dev_name(dm644x_mdio_device.dev),
  NULL, dm644x_emac_device.dev);
 
-   platform_device_register(dm644x_vpss_device);
-   platform_device_register(dm644x_ccdc_dev);
-   platform_device_register(dm644x_vpfe_dev);
-
return 0;
 }
 postcore_initcall(dm644x_init_devices);
diff --git a/arch/arm/mach-davinci/include/mach/dm644x.h 
b/arch/arm/mach-davinci/include/mach/dm644x.h
index 5a1b26d..29a9e24 100644
--- a/arch/arm/mach-davinci/include/mach/dm644x.h
+++ b/arch/arm/mach-davinci/include/mach/dm644x.h
@@ -42,6 +42,6 @@
 
 void __init dm644x_init(void);
 void __init dm644x_init_asp(struct snd_platform_data *pdata);
-void dm644x_set_vpfe_config(struct vpfe_config *cfg);
+int __init dm644x_init_video(struct vpfe_config *);
 
 #endif /* __ASM_ARCH_DM644X_H */
-- 
1.6.2.4

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

[PATCH v18 08/13] davinci: eliminate use of IO_ADDRESS() on sysmod

[Manjunath Hadli]

Current devices.c file has a number of instances where
IO_ADDRESS() is used for system module register
access. Eliminate this in favor of a ioremap()
based access.

Consequent to this, a new global pointer davinci_sysmodbase
has been introduced which gets initialized during
the initialization of each relevant SoC

Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Acked-by: Sekhar Nori nsek...@ti.com
---
 arch/arm/mach-davinci/devices.c   |   24 +++-
 arch/arm/mach-davinci/dm355.c |1 +
 arch/arm/mach-davinci/dm365.c |1 +
 arch/arm/mach-davinci/dm644x.c|1 +
 arch/arm/mach-davinci/dm646x.c|1 +
 arch/arm/mach-davinci/include/mach/hardware.h |6 ++
 6 files changed, 25 insertions(+), 9 deletions(-)

diff --git a/arch/arm/mach-davinci/devices.c b/arch/arm/mach-davinci/devices.c
index 4e1b663..529b440 100644
--- a/arch/arm/mach-davinci/devices.c
+++ b/arch/arm/mach-davinci/devices.c
@@ -33,6 +33,14 @@
 #define DM365_MMCSD0_BASE   0x01D11000
 #define DM365_MMCSD1_BASE   0x01D0
 
+void __iomem  *davinci_sysmodbase;
+
+void davinci_map_sysmod(void)
+{
+   davinci_sysmodbase = ioremap_nocache(DAVINCI_SYSTEM_MODULE_BASE, 0x800);
+   WARN_ON(!davinci_sysmodbase);
+}
+
 static struct resource i2c_resources[] = {
{
.start  = DAVINCI_I2C_BASE,
@@ -210,12 +218,12 @@ void __init davinci_setup_mmc(int module, struct 
davinci_mmc_config *config)
davinci_cfg_reg(DM355_SD1_DATA2);
davinci_cfg_reg(DM355_SD1_DATA3);
} else if (cpu_is_davinci_dm365()) {
-   void __iomem *pupdctl1 =
-   IO_ADDRESS(DAVINCI_SYSTEM_MODULE_BASE + 0x7c);
-
/* Configure pull down control */
-   __raw_writel((__raw_readl(pupdctl1)  ~0xfc0),
-   pupdctl1);
+   void __iomem *pupdctl1 = DAVINCI_SYSMODULE_VIRT(0x7c);
+   unsigned v;
+
+   v = __raw_readl(pupdctl1);
+   __raw_writel(v  ~0xfc0, pupdctl1);
 
mmcsd1_resources[0].start = DM365_MMCSD1_BASE;
mmcsd1_resources[0].end = DM365_MMCSD1_BASE +
@@ -244,11 +252,9 @@ void __init davinci_setup_mmc(int module, struct 
davinci_mmc_config *config)
mmcsd0_resources[2].start = IRQ_DM365_SDIOINT0;
} else if (cpu_is_davinci_dm644x()) {
/* REVISIT: should this be in board-init code? */
-   void __iomem *base =
-   IO_ADDRESS(DAVINCI_SYSTEM_MODULE_BASE);
-
/* Power-on 3.3V IO cells */
-   __raw_writel(0, base + DM64XX_VDD3P3V_PWDN);
+   __raw_writel(0,
+   DAVINCI_SYSMODULE_VIRT(DM64XX_VDD3P3V_PWDN));
/*Set up the pull regiter for MMC */
davinci_cfg_reg(DM644X_MSTK);
}
diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
index a5f8a80..1baab94 100644
--- a/arch/arm/mach-davinci/dm355.c
+++ b/arch/arm/mach-davinci/dm355.c
@@ -874,6 +874,7 @@ void __init dm355_init_asp1(u32 evt_enable, struct 
snd_platform_data *pdata)
 void __init dm355_init(void)
 {
davinci_common_init(davinci_soc_info_dm355);
+   davinci_map_sysmod();
 }
 
 static int __init dm355_init_devices(void)
diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index 02d2cc3..a788980 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -1127,6 +1127,7 @@ void __init dm365_init_rtc(void)
 void __init dm365_init(void)
 {
davinci_common_init(davinci_soc_info_dm365);
+   davinci_map_sysmod();
 }
 
 static struct resource dm365_vpss_resources[] = {
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index 9a2376b..77dea11 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -779,6 +779,7 @@ void __init dm644x_init_asp(struct snd_platform_data *pdata)
 void __init dm644x_init(void)
 {
davinci_common_init(davinci_soc_info_dm644x);
+   davinci_map_sysmod();
 }
 
 static int __init dm644x_init_devices(void)
diff --git a/arch/arm/mach-davinci/dm646x.c b/arch/arm/mach-davinci/dm646x.c
index 1e0f809..ce93b83 100644
--- a/arch/arm/mach-davinci/dm646x.c
+++ b/arch/arm/mach-davinci/dm646x.c
@@ -903,6 +903,7 @@ void __init dm646x_init(void)
 {
dm646x_board_setup_refclk(ref_clk);
davinci_common_init(davinci_soc_info_dm646x);
+   davinci_map_sysmod();
 }
 
 static int __init dm646x_init_devices(void)
diff --git a/arch/arm/mach-davinci/include/mach/hardware.h 
b/arch/arm/mach-davinci/include/mach/hardware.h
index 414e0b9..2a6b560 100644
--- 

[PATCH v18 12/13] davinci: dm644x: add support for v4l2 video display

[Manjunath Hadli]

Create platform devices for various video modules like venc,osd,
vpbe and v4l2 driver for dm644x. Change the dm644x_init_video to
make room for display config, and register the vpfe or vpbe devices
based on the config pointer validity to make sure boards without vpfe
or vpbe can be built with minimal changes.

Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Acked-by: Sekhar Nori nsek...@ti.com
---
 arch/arm/mach-davinci/board-dm644x-evm.c|2 +-
 arch/arm/mach-davinci/dm644x.c  |  163 ---
 arch/arm/mach-davinci/include/mach/dm644x.h |6 +-
 3 files changed, 153 insertions(+), 18 deletions(-)

diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c 
b/arch/arm/mach-davinci/board-dm644x-evm.c
index d1542b1..afa88ac 100644
--- a/arch/arm/mach-davinci/board-dm644x-evm.c
+++ b/arch/arm/mach-davinci/board-dm644x-evm.c
@@ -699,7 +699,7 @@ static __init void davinci_evm_init(void)
evm_init_i2c();
 
davinci_setup_mmc(0, dm6446evm_mmc_config);
-   dm644x_init_video(dm644xevm_capture_cfg);
+   dm644x_init_video(dm644xevm_capture_cfg, NULL);
 
davinci_serial_init(uart_config);
dm644x_init_asp(dm644x_evm_snd_data);
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index 36d4d72..91e979d 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -619,7 +619,7 @@ static struct resource dm644x_vpfe_resources[] = {
},
 };
 
-static u64 vpfe_capture_dma_mask = DMA_BIT_MASK(32);
+static u64 dm644x_video_dma_mask = DMA_BIT_MASK(32);
 static struct resource dm644x_ccdc_resource[] = {
/* CCDC Base address */
{
@@ -635,7 +635,7 @@ static struct platform_device dm644x_ccdc_dev = {
.num_resources  = ARRAY_SIZE(dm644x_ccdc_resource),
.resource   = dm644x_ccdc_resource,
.dev = {
-   .dma_mask   = vpfe_capture_dma_mask,
+   .dma_mask   = dm644x_video_dma_mask,
.coherent_dma_mask  = DMA_BIT_MASK(32),
},
 };
@@ -646,7 +646,127 @@ static struct platform_device dm644x_vpfe_dev = {
.num_resources  = ARRAY_SIZE(dm644x_vpfe_resources),
.resource   = dm644x_vpfe_resources,
.dev = {
-   .dma_mask   = vpfe_capture_dma_mask,
+   .dma_mask   = dm644x_video_dma_mask,
+   .coherent_dma_mask  = DMA_BIT_MASK(32),
+   },
+};
+
+#define DM644X_OSD_REG_BASE0x01C72600
+
+static struct resource dm644x_osd_resources[] = {
+   {
+   .start  = DM644X_OSD_REG_BASE,
+   .end= DM644X_OSD_REG_BASE + 0x1ff,
+   .flags  = IORESOURCE_MEM,
+   },
+};
+
+static struct osd_platform_data dm644x_osd_data = {
+   .vpbe_type = VPBE_VERSION_1,
+};
+
+static struct platform_device dm644x_osd_dev = {
+   .name   = VPBE_OSD_SUBDEV_NAME,
+   .id = -1,
+   .num_resources  = ARRAY_SIZE(dm644x_osd_resources),
+   .resource   = dm644x_osd_resources,
+   .dev= {
+   .dma_mask   = dm644x_video_dma_mask,
+   .coherent_dma_mask  = DMA_BIT_MASK(32),
+   .platform_data  = dm644x_osd_data,
+   },
+};
+
+#define DM644X_VENC_REG_BASE   0x01C72400
+
+static struct resource dm644x_venc_resources[] = {
+   {
+   .start  = DM644X_VENC_REG_BASE,
+   .end= DM644X_VENC_REG_BASE + 0x17f,
+   .flags  = IORESOURCE_MEM,
+   },
+};
+
+static int dm644x_venc_setup_clock(enum vpbe_enc_timings_type type,
+  unsigned int mode)
+{
+   int ret = 0;
+   void __iomem *vpss_clkctl_reg;
+
+   vpss_clkctl_reg = DAVINCI_SYSMODULE_VIRT(0x44);
+
+   switch (type) {
+   case VPBE_ENC_STD:
+   writel(0x18, vpss_clkctl_reg);
+   break;
+   case VPBE_ENC_DV_PRESET:
+   switch ((unsigned int)mode) {
+   case V4L2_DV_480P59_94:
+   case V4L2_DV_576P50:
+   writel(0x19, vpss_clkctl_reg);
+   break;
+   case V4L2_DV_720P60:
+   case V4L2_DV_1080I60:
+   case V4L2_DV_1080P30:
+   /*
+* For HD, use external clock source since
+* HD requires higher clock rate
+*/
+   writel(0xa, vpss_clkctl_reg);
+   break;
+   default:
+   ret = -EINVAL;
+   break;
+   }
+   break;
+   default:
+   ret  = -EINVAL;
+   }
+
+   return ret;
+}
+
+static struct resource dm644x_v4l2_disp_resources[] = {
+   {
+   .start  = IRQ_VENCINT,
+   .end= IRQ_VENCINT,
+   .flags  = IORESOURCE_IRQ,

[PATCH v18 09/13] davinci: dm644x: Replace register base value with a defined macro

[Manjunath Hadli]

Replace hard coded value of vpss register base to a define macro
DM644X_VPSS_REG_BASE for proper readability

Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Acked-by: Sekhar Nori nsek...@ti.com
---
 arch/arm/mach-davinci/dm644x.c |8 +---
 1 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index 77dea11..6edb5d1 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -586,13 +586,15 @@ static struct platform_device dm644x_asp_device = {
.resource   = dm644x_asp_resources,
 };
 
+#define DM644X_VPSS_REG_BASE   0x01c73400
+
 static struct resource dm644x_vpss_resources[] = {
{
/* VPSS Base address */
.name   = vpss,
-   .start  = 0x01c73400,
-   .end= 0x01c73400 + 0xff,
-   .flags  = IORESOURCE_MEM,
+   .start  = DM644X_VPSS_REG_BASE,
+   .end= DM644X_VPSS_REG_BASE + 0xff,
+   .flags  = IORESOURCE_MEM,
},
 };
 
-- 
1.6.2.4

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

[PATCH v18 13/13] davinci: dm644x EVM: add support for VPBE display

[Manjunath Hadli]

This patch adds support for V4L2 video display to DM6446 EVM.
Support for SD and ED modes is provided, along with Composite
and Component outputs.Also added vpbe_config as a parameter for
dm644x_init_video to allow for registration of vpbe platform devices.

Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Acked-by: Sekhar Nori nsek...@ti.com
---
 arch/arm/mach-davinci/board-dm644x-evm.c |  108 +-
 1 files changed, 107 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c 
b/arch/arm/mach-davinci/board-dm644x-evm.c
index afa88ac..4a642dd 100644
--- a/arch/arm/mach-davinci/board-dm644x-evm.c
+++ b/arch/arm/mach-davinci/board-dm644x-evm.c
@@ -616,6 +616,112 @@ static void __init evm_init_i2c(void)
i2c_register_board_info(1, i2c_info, ARRAY_SIZE(i2c_info));
 }
 
+#define VENC_STD_ALL   (V4L2_STD_NTSC | V4L2_STD_PAL)
+
+/* venc standard timings */
+static struct vpbe_enc_mode_info dm644xevm_enc_std_timing[] = {
+   {
+   .name   = ntsc,
+   .timings_type   = VPBE_ENC_STD,
+   .timings= {V4L2_STD_525_60},
+   .interlaced = 1,
+   .xres   = 720,
+   .yres   = 480,
+   .aspect = {11, 10},
+   .fps= {3, 1001},
+   .left_margin= 0x79,
+   .upper_margin   = 0x10,
+   },
+   {
+   .name   = pal,
+   .timings_type   = VPBE_ENC_STD,
+   .timings= {V4L2_STD_625_50},
+   .interlaced = 1,
+   .xres   = 720,
+   .yres   = 576,
+   .aspect = {54, 59},
+   .fps= {25, 1},
+   .left_margin= 0x7E,
+   .upper_margin   = 0x16,
+   },
+};
+
+/* venc dv preset timings */
+static struct vpbe_enc_mode_info dm644xevm_enc_preset_timing[] = {
+   {
+   .name   = 480p59_94,
+   .timings_type   = VPBE_ENC_DV_PRESET,
+   .timings= {V4L2_DV_480P59_94},
+   .interlaced = 0,
+   .xres   = 720,
+   .yres   = 480,
+   .aspect = {1, 1},
+   .fps= {5994, 100},
+   .left_margin= 0x80,
+   .upper_margin   = 0x20,
+   },
+   {
+   .name   = 576p50,
+   .timings_type   = VPBE_ENC_DV_PRESET,
+   .timings= {V4L2_DV_576P50},
+   .interlaced = 0,
+   .xres   = 720,
+   .yres   = 576,
+   .aspect = {1, 1},
+   .fps= {50, 1},
+   .left_margin= 0x7E,
+   .upper_margin   = 0x30,
+   },
+};
+
+/*
+ * The outputs available from VPBE + encoders. Keep the order same
+ * as that of encoders. First those from venc followed by that from
+ * encoders. Index in the output refers to index on a particular encoder.
+ * Driver uses this index to pass it to encoder when it supports more than
+ * one output. Application uses index of the array to set an output.
+ */
+static struct vpbe_output dm644xevm_vpbe_outputs[] = {
+   {
+   .output = {
+   .index  = 0,
+   .name   = Composite,
+   .type   = V4L2_OUTPUT_TYPE_ANALOG,
+   .std= VENC_STD_ALL,
+   .capabilities   = V4L2_OUT_CAP_STD,
+   },
+   .subdev_name= VPBE_VENC_SUBDEV_NAME,
+   .default_mode   = ntsc,
+   .num_modes  = ARRAY_SIZE(dm644xevm_enc_std_timing),
+   .modes  = dm644xevm_enc_std_timing,
+   },
+   {
+   .output = {
+   .index  = 1,
+   .name   = Component,
+   .type   = V4L2_OUTPUT_TYPE_ANALOG,
+   .capabilities   = V4L2_OUT_CAP_PRESETS,
+   },
+   .subdev_name= VPBE_VENC_SUBDEV_NAME,
+   .default_mode   = 480p59_94,
+   .num_modes  = ARRAY_SIZE(dm644xevm_enc_preset_timing),
+   .modes  = dm644xevm_enc_preset_timing,
+   },
+};
+
+static struct vpbe_config dm644xevm_display_cfg = {
+   .module_name= dm644x-vpbe-display,
+   .i2c_adapter_id = 1,
+   .osd= {
+   .module_name= VPBE_OSD_SUBDEV_NAME,
+   },
+   .venc   = {
+   .module_name= VPBE_VENC_SUBDEV_NAME,
+   },
+   .num_outputs= ARRAY_SIZE(dm644xevm_vpbe_outputs),
+   .outputs= dm644xevm_vpbe_outputs,
+};
+
 static struct platform_device *davinci_evm_devices[] __initdata = {
davinci_fb_device,
 

[GIT PULL for 2.6.39-rc2] media fixes

[Mauro Carvalho Chehab]

Hi Linus,

Please pull from:
  ssh://master.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git 
v4l_for_linus

For two small bug fixes.

Thanks!
Mauro.

The following changes since commit 0ce790e7d736cedc563e1fb4e998babf5a4dbc3d:

  Linux 2.6.39-rc1 (2011-03-29 12:09:47 -0700)

are available in the git repository at:
  ssh://master.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git 
v4l_for_linus

Manjunatha Halli (1):
  [media] radio: wl128x: Update registration process with ST

Randy Dunlap (1):
  [media] staging: altera-jtag needs delay.h

 drivers/media/radio/wl128x/fmdrv_common.c  |   16 +---
 drivers/staging/altera-stapl/altera-jtag.c |1 +
 2 files changed, 14 insertions(+), 3 deletions(-)

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

Re: [GIT PULL] HVR-900 R2 and PCTV 330e DVB support

[Mauro Carvalho Chehab]

Hi Devin,

Em 25-03-2011 13:09, Devin Heitmueller escreveu:
 On Fri, Mar 25, 2011 at 11:50 AM, Mauro Carvalho Chehab
 mche...@redhat.com wrote:
 I've added a patch for it at the end of the series.

 Could you please double check if everything is ok, for me to move this 
 upstream?

 Thanks!
 Mauro

 
 Sure, I will find some time this weekend to try out your tree.

Any news?

Thanks!
Mauro
--
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] Fix AF9015 Dual tuner i2c write failures

[adq]

2011/4/2 Antti Palosaari cr...@iki.fi:
 On 04/02/2011 04:24 AM, adq wrote:

 Hi, just been trying it out, with no success. On my test machine, FE0
 no longer tunes, but FE1 is still fine, so I've just been testing FE0.

 You try to say other frontend / tuner is physically dead? Which one?

No no - I can revive it by simply unplugging and replugging the
device, but I was avoiding doing that to see if we could either track
down something erroneous, or be able to reset it from software.

It'd be /really/ handy if they'd connected that reset tuner GPIO :(
There isn't a way to completely reset the device from software I take
it? Or any other GPIOs hanging about I could test with?

I have an MXL5005R tuner apparently - id 30 - BTW.

 I've tried your suggestions, mainly concentrating on the af9013's
 GPIOs, but I also tried your power management suggestion.

 Since I was just using FE0, I've just been setting all the GPIOs at
 the start of af9013.c's set_frontend() implementation; I've tried
 turning them all off, all on, on-mdelay-off, and also
 off-mdelay-on. Nothing works.

 So GPIOs are blocked out.

 I wonder if someone can ran similar many day tuning stress test using
 Windows drivers to see if that happen.

Might be hard to script under windows I suppose...
--
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] Fix AF9015 Dual tuner i2c write failures

[adq]

2011/4/2 adq a...@lidskialf.net:
 2011/4/2 Antti Palosaari cr...@iki.fi:
 On 04/02/2011 04:24 AM, adq wrote:

 Hi, just been trying it out, with no success. On my test machine, FE0
 no longer tunes, but FE1 is still fine, so I've just been testing FE0.

 You try to say other frontend / tuner is physically dead? Which one?

 No no - I can revive it by simply unplugging and replugging the
 device, but I was avoiding doing that to see if we could either track
 down something erroneous, or be able to reset it from software.

 It'd be /really/ handy if they'd connected that reset tuner GPIO :(
 There isn't a way to completely reset the device from software I take
 it? Or any other GPIOs hanging about I could test with?

 I have an MXL5005R tuner apparently - id 30 - BTW.

Forgot to mention - its the tuner attached to the internal af9013
(fe0) that is having the problem. The one attached to the external one
(fe1) is still fine. I don't know if this is always the case though.

 I've tried your suggestions, mainly concentrating on the af9013's
 GPIOs, but I also tried your power management suggestion.

 Since I was just using FE0, I've just been setting all the GPIOs at
 the start of af9013.c's set_frontend() implementation; I've tried
 turning them all off, all on, on-mdelay-off, and also
 off-mdelay-on. Nothing works.

 So GPIOs are blocked out.

 I wonder if someone can ran similar many day tuning stress test using
 Windows drivers to see if that happen.

 Might be hard to script under windows I suppose...

--
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: Technisat Cablestar HD2 not automatically detected by kernel 2.6.33?

[Jos Hoekstra]

Op 31-3-2011 14:32, Bjørn Mork schreef:

Jos Hoekstrajoshoeks...@gmx.net  writes:


I got this card and it doesn't seem to be detected by Ubuntu 10.4.2
with kernel 2.6.35(-25-generic #44~lucid1-Ubuntu SMP Tue Jan 25
19:17:25 UTC 2011 x86_64 GNU/Linux)

The wiki seems to indicate that this card is supported as of kernel
2.6.33, however it doesn't show up as a dvb-adapter.

[..]

After rebooting it however seems I need to manually modprobe mantis
and restart the backend to have mythtv work with this card. Is there a
way to make these modules load automatically after a reboot?

The best way to work around the problem until you upgrade your kernel to
2.6.38 or newer, is probably just adding mantis to /etc/modules.


Bjørn


This work-around solved this little issue for me, thanks :)

Is there a how-to for handing in initial scan-files or complete scans? 
I'm on fiber and afaik this goes for the whole network excluding local 
stations.


Thanks,

Jos Hoekstra
--
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] Fix AF9015 Dual tuner i2c write failures

[Antti Palosaari]

On 04/02/2011 02:06 PM, adq wrote:

2011/4/2 Antti Palosaaricr...@iki.fi:

On 04/02/2011 04:24 AM, adq wrote:


Hi, just been trying it out, with no success. On my test machine, FE0
no longer tunes, but FE1 is still fine, so I've just been testing FE0.


You try to say other frontend / tuner is physically dead? Which one?


No no - I can revive it by simply unplugging and replugging the
device, but I was avoiding doing that to see if we could either track
down something erroneous, or be able to reset it from software.

It'd be /really/ handy if they'd connected that reset tuner GPIO :(
There isn't a way to completely reset the device from software I take
it? Or any other GPIOs hanging about I could test with?


There is few I know, USB command 0x13 boots AF9015 somehow, USB command 
0x5a reconnects it from USB bus. But most interesting one is demodulator 
reset register 0xe205, write 1 to that reg should reset it.



I have an MXL5005R tuner apparently - id 30 - BTW.


I suspect it is demod which hangs since I have feeling it happens every 
tuner used.



I've tried your suggestions, mainly concentrating on the af9013's
GPIOs, but I also tried your power management suggestion.

Since I was just using FE0, I've just been setting all the GPIOs at
the start of af9013.c's set_frontend() implementation; I've tried
turning them all off, all on, on-mdelay-off, and also
off-mdelay-on. Nothing works.


So GPIOs are blocked out.

I wonder if someone can ran similar many day tuning stress test using
Windows drivers to see if that happen.


Might be hard to script under windows I suppose...


I am not aware any good commandline BDA tuning app for Windows. Only one 
I know is ScanChannelsBDA.exe which is rather buggy - but works.


Antti
--
http://palosaari.fi/
--
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] v1.82 DM04/QQBOX dvb-usb-lmedm04 diseqc timing changes

[Malcolm Priestley]

On Sat, 2011-03-26 at 23:29 +, Malcolm Priestley wrote:
 Frontend timing change for diseqc functions.
 
 Timing on the STV0288 and STV0299 frontends cause initial disegc errors
 on some applications.
 
 
 Signed-off-by: Malcolm Priestley tvbox...@gmail.com
 ---
  drivers/media/dvb/dvb-usb/lmedm04.c |9 +
  1 files changed, 5 insertions(+), 4 deletions(-)
 

A bug has been found in a stv0288 register, v1.82 is now withdrawn
pending changes.  

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

dibusb device with lock problems

[Mr Tux]

Hi list, hello Patrick,

A locking problem with specific dib3000mb devices is still present in
kernel 2.6.38.

Now people upgrading from lenny to squeeze are also affected - see: [1]

Please have a look at my previous post in [2] for a detailed description and 
links to this bug's history.

I'm sending a cc of this to the people who once where affected by this bug or 
involved with the code change that introduced it.

Anyone can confirm this is fixed/pending for his device and what dib3000mb 
device he is using out of the linuxtv wiki list of 14 dib3000mb devices [3]?

I have 3 devices of the hama usb 1.1 series: [4], that's number 66 in the wiki 
listing - they all are affected by this bug with kernels  2.6.31

Thanks for some feedback. Can we fix this for good for the pending devices?


[1] http://www.vdr-portal.de/index.php?page=ThreadpostID=991041
[2] http://www.spinics.net/lists/linux-media/msg28817.html
[3] http://www.linuxtv.org/wiki/index.php/DVB-T_USB_Devices/Full
[4] http://www.hama.de/bilder/00049/abb/00049021abb.jpg
--
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] Fix AF9015 Dual tuner i2c write failures

[adq]

2011/4/2 Antti Palosaari cr...@iki.fi:
 On 04/02/2011 02:06 PM, adq wrote:

 2011/4/2 Antti Palosaaricr...@iki.fi:

 On 04/02/2011 04:24 AM, adq wrote:

 Hi, just been trying it out, with no success. On my test machine, FE0
 no longer tunes, but FE1 is still fine, so I've just been testing FE0.

 You try to say other frontend / tuner is physically dead? Which one?

 No no - I can revive it by simply unplugging and replugging the
 device, but I was avoiding doing that to see if we could either track
 down something erroneous, or be able to reset it from software.

 It'd be /really/ handy if they'd connected that reset tuner GPIO :(
 There isn't a way to completely reset the device from software I take
 it? Or any other GPIOs hanging about I could test with?

 There is few I know, USB command 0x13 boots AF9015 somehow, USB command 0x5a
 reconnects it from USB bus. But most interesting one is demodulator reset
 register 0xe205, write 1 to that reg should reset it.

Just tried writing 1 to 0xe205 - no change.

Looks like USB commands 0x13/0x5a will be done as part of a normal
module reload? (In which case it doesn't fix it).

I can actually reboot the machine completely, and the problem stays!
Only physically unplugging the device sorts it.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/2] DM04/QQBOX stv0288 register 42 - incorrect setting.

[Malcolm Priestley]

 stv0288 Register 42 bits 6  7 should be set to 0.
 This is causing intermittent lock, the dvb-usb-lmedm04 driver uses
 register 50 (auto fine mode) to correct for this, this register is
 now returned to its default setting.

Signed-off-by: Malcolm Priestley tvbox...@gmail.com
---
 drivers/media/dvb/dvb-usb/lmedm04.h |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/dvb/dvb-usb/lmedm04.h 
b/drivers/media/dvb/dvb-usb/lmedm04.h
index e6af16c..3a30ab1 100644
--- a/drivers/media/dvb/dvb-usb/lmedm04.h
+++ b/drivers/media/dvb/dvb-usb/lmedm04.h
@@ -108,14 +108,14 @@ static u8 s7395_inittab[] = {
0x3d, 0x30,
0x40, 0x63,
0x41, 0x04,
-   0x42, 0x60,
+   0x42, 0x20,
0x43, 0x00,
0x44, 0x00,
0x45, 0x00,
0x46, 0x00,
0x47, 0x00,
0x4a, 0x00,
-   0x50, 0x12,
+   0x50, 0x10,
0x51, 0x36,
0x52, 0x21,
0x53, 0x94,
-- 
1.7.4.1

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

Re: [RFC/PATCH 0/3] locking fixes for cx88

[Ben Hutchings]

On Sat, 2011-04-02 at 04:38 -0500, Jonathan Nieder wrote:
 Hi,
 
 Huber Andreas wrote[1]:
 
  Processes that try to open a cx88-blackbird driven MPEG device will hang up.
 
 Here's a possible fix based on a patch by Ben Hutchings and
 corrections from Andi Huber.  Warning: probably full of mistakes (my
 fault) since I'm not familiar with any of this stuff.  Untested.
 Review and testing would be welcome.

Since you have split up and otherwise modified the patch I sent, please
remove the 'From' and 'Signed-off-by' lines with my name and address.
Just state that the patches are based on my work.

Ben.

 Ben Hutchings (2):
   [media] cx88: fix locking of sub-driver operations
   [media] cx88: use a mutex to protect cx8802_devlist
 
 Jonathan Nieder (1):
   [media] cx88: protect per-device driver list with device lock
 
  drivers/media/video/cx88/cx88-blackbird.c |3 +-
  drivers/media/video/cx88/cx88-dvb.c   |2 +
  drivers/media/video/cx88/cx88-mpeg.c  |   35 +++-
  drivers/media/video/cx88/cx88.h   |   10 +++-
  4 files changed, 37 insertions(+), 13 deletions(-)
 

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.


signature.asc
Description: This is a digitally signed message part

[cron job] v4l-dvb daily build: 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:Sat Apr  2 19:00:36 CEST 2011
git hash:28df73703e738d8ae7a958350f74b08b2e9fe9ed
gcc version:  i686-linux-gcc (GCC) 4.5.1
host hardware:x86_64
host os:  2.6.32.5

linux-git-armv5: OK
linux-git-armv5-davinci: OK
linux-git-armv5-ixp: OK
linux-git-armv5-omap2: OK
linux-git-i686: OK
linux-git-m32r: OK
linux-git-mips: WARNINGS
linux-git-powerpc64: OK
linux-git-x86_64: OK
linux-2.6.31.12-i686: ERRORS
linux-2.6.32.6-i686: ERRORS
linux-2.6.33-i686: WARNINGS
linux-2.6.34-i686: WARNINGS
linux-2.6.35.3-i686: WARNINGS
linux-2.6.36-i686: WARNINGS
linux-2.6.37-i686: WARNINGS
linux-2.6.31.12-x86_64: ERRORS
linux-2.6.32.6-x86_64: ERRORS
linux-2.6.33-x86_64: WARNINGS
linux-2.6.34-x86_64: WARNINGS
linux-2.6.35.3-x86_64: WARNINGS
linux-2.6.36-x86_64: WARNINGS
linux-2.6.37-x86_64: WARNINGS
spec-git: OK
sparse: ERRORS

Detailed results are available here:

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

Full logs are available here:

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

The V4L-DVB specification from this daily build is here:

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

Anysee E30 Combo Plus failing to tune

[Sami Haahtinen]

Hey,
I have a Anysee E30 Combo Plus and i'm having trouble getting it to
detect properly. According to various sources it should be supported,
but yet it fails for me. I've tried with the stock driver and the
backports one (one instructed in wiki) and neither work.

the device is as follows:

---8--
Bus 001 Device 007: ID 1c73:861f AMT Anysee E30 USB 2.0 DVB-T Receiver
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   2.00
  bDeviceClass0 (Defined at Interface level)
  bDeviceSubClass 0
  bDeviceProtocol 0
  bMaxPacketSize064
  idVendor   0x1c73 AMT
  idProduct  0x861f Anysee E30 USB 2.0 DVB-T Receiver
  bcdDevice1.00
  iManufacturer   1
  iProduct2
  iSerial 0
  bNumConfigurations  1
---8--

Manufacturer has packaged it as Anysee E30 Combo Plus, which is listed
as supported. It could be that there have been changes in revision,
the device doesn't list it clearly anywhere and i've yet to take it
apart.

So far i've tried with both DVB-C and DVB-T. Out of the two, DVB-C
doesn't produce any errors, but fails to tune in to any known
frequency, even if the same device is able to tune in under windows.
As for DVB-T, i'm getting a bunch of nasty errors

---8--
[  463.200473] zl10353: write to reg 62 failed (err = -110)!
[  465.200492] dvb-usb: bulk message failed: -110 (64/0)
[  465.200509] samsung_dtos403ih102a_set: i2c_transfer failed:-110
[  467.200446] dvb-usb: bulk message failed: -110 (64/0)
[  467.200465] zl10353: write to reg 67 failed (err = -110)!
[  469.200454] dvb-usb: bulk message failed: -110 (64/0)
[  469.200471] zl10353: write to reg 5f failed (err = -110)!
[  471.200452] dvb-usb: bulk message failed: -110 (64/0)
[  471.200470] zl10353: write to reg 70 failed (err = -110)!
[  473.200452] dvb-usb: bulk message failed: -110 (64/0)
[  473.200469] dvb-usb: error -110 while querying for an remote control event.
---8--

these are the starting points, what info do you need to debug this? I
can also provide access to a host with this device installed if
required.

Regards,
--
Sami Haahtinen
Bad Wolf Oy
+358443302775
--
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: Anysee E30 Combo Plus failing to tune

[Sami Haahtinen]

On Sat, Apr 2, 2011 at 21:52, Sami Haahtinen s...@haahtinen.name wrote:
 Manufacturer has packaged it as Anysee E30 Combo Plus, which is listed
 as supported. It could be that there have been changes in revision,
 the device doesn't list it clearly anywhere and i've yet to take it
 apart.

Ok, board revision is 1.4. Pictures of the board available here:
https://picasaweb.google.com/ressukka/Junk

Regards,
-- 
Sami Haahtinen
Bad Wolf Oy
+358443302775
--
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: Anysee E30 Combo Plus failing to tune

[Antti Palosaari]

Moi Sami,

On 04/02/2011 09:52 PM, Sami Haahtinen wrote:

Hey,
I have a Anysee E30 Combo Plus and i'm having trouble getting it to
detect properly. According to various sources it should be supported,
but yet it fails for me. I've tried with the stock driver and the
backports one (one instructed in wiki) and neither work.


I think your device is newer model where is new DNOD44CDV086A tuner 
module and inside that module is TDA18212 silicon tuner which does not 
have working driver yet. If your device have antenna loop-through it 
does have this new tuner module.


Unfortunately I don't have this device model, I got older one :-(. But 
luckily enough I have got E7TC which is almost similar as E30 Combo. I 
have DVB-C and DVB-T picture out from E7TC, it is just up to few weeks I 
will get TDA18212 tuner driver ready.




Antti


--
http://palosaari.fi/
--
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: Anysee E30 Combo Plus failing to tune

[Sami Haahtinen]

Hey,

On Sat, Apr 2, 2011 at 22:16, Antti Palosaari cr...@iki.fi wrote:
 On 04/02/2011 09:52 PM, Sami Haahtinen wrote:
 I have a Anysee E30 Combo Plus and i'm having trouble getting it to
 detect properly. According to various sources it should be supported,
 but yet it fails for me. I've tried with the stock driver and the
 backports one (one instructed in wiki) and neither work.
 I think your device is newer model where is new DNOD44CDV086A tuner module
 and inside that module is TDA18212 silicon tuner which does not have working
 driver yet. If your device have antenna loop-through it does have this new
 tuner module.

Yup, it has a loop through. So it is most likely a newer model.

 Unfortunately I don't have this device model, I got older one :-(. But
 luckily enough I have got E7TC which is almost similar as E30 Combo. I have
 DVB-C and DVB-T picture out from E7TC, it is just up to few weeks I will get
 TDA18212 tuner driver ready.

If you need one of these buggers for development use, I can arrange that..

Regards,
-- 
Sami Haahtinen
Bad Wolf Oy
+358443302775
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/3] [media] cx88: use a mutex to protect cx8802_devlist

[Jonathan Nieder]

Hi Andreas,

(please turn off HTML mail.)
Andreas Huber wrote:

 There is a reference count bug in the driver code. The driver's
 active_ref count may become negative which leads to unpredictable
 behavior. (mpeg video device inaccessible, etc ...)

Hmm, the patchset didn't touch active_ref handling.

active_ref was added by v2.6.25-rc3~132^2~7 (V4L/DVB (7194):
cx88-mpeg: Allow concurrent access to cx88-mpeg devices, 2008-02-11)
and relies on three assumptions:

 * (successful) calls to cx8802_driver::request_acquire are balanced
   with calls to cx8802_driver::request_release;

 * cx8802_driver::advise_acquire is non-null if and only if
   cx8802_driver::advise_release is (since both are NULL for
   blackbird, non-NULL for dvb);

 * no data races.

I suppose it would be more idiomatic to use an atomic_t, but access to
active_ref was previously protected by the BKL and now it is protected
by core-lock.  So it's not clear to me why this doesn't work.

Any hints?  (e.g., a detailed reproduction recipe, or a log after
adding a printk to find out when exactly active_ref becomes negative)

Thanks for reporting.
Jonathan
--
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

Skystar 2 2.6 broken in kernel 2.6.38

[Steffen Barszus]

Hi 

I just installed natty and found that one of the drivers i use is
broken. Is this a known issue ?


[6.115925] [ cut here ]
[6.115931] WARNING: at /build/buildd/linux-2.6.38/fs/proc/generic.c:323 
__xlate_proc_name+0xbb/0xd0()
[6.115933] Hardware name: EP45T-UD3LR
[6.115934] name 'Technisat/B2C2 FlexCop II/IIb/III Digital TV PCI Driver'
[6.115935] Modules linked in: videobuf_dvb(+) b2c2_flexcop_pci(+) 
videobuf_core joydev v4l2_common b2c2_flexcop snd(+) dvb_core cx24123 cx24113 
videodev btcx_risc soundcore s5h1420 tveeprom snd_page_alloc serio_raw 
sunrpc(+) lp parport hid_gyration usbhid hid r8169 pata_jmicron
[6.115953] Pid: 518, comm: modprobe Tainted: P2.6.38-7-generic 
#39-Ubuntu
[6.115955] Call Trace:
[6.115959]  [c104f912] ? warn_slowpath_common+0x72/0xa0
[6.115962]  [c1174a5b] ? __xlate_proc_name+0xbb/0xd0
[6.115964]  [c1174a5b] ? __xlate_proc_name+0xbb/0xd0
[6.115967]  [c104f9e3] ? warn_slowpath_fmt+0x33/0x40
[6.115970]  [c1174a5b] ? __xlate_proc_name+0xbb/0xd0
[6.115973]  [c1175101] ? __proc_create+0x61/0x110
[6.115975]  [c11754b6] ? proc_mkdir_mode+0x26/0x60
[6.115978]  [c1175504] ? proc_mkdir+0x14/0x20
[6.115981]  [c10b2fbb] ? register_handler_proc+0xeb/0x110
[6.115984]  [c10b0e37] ? __setup_irq+0x1a7/0x2f0
[6.115987]  [c111a7ad] ? kmem_cache_alloc_trace+0xdd/0x100
[6.115989]  [c10b0ff9] ? request_threaded_irq+0x79/0x120
[6.115992]  [c10b0ff9] ? request_threaded_irq+0x79/0x120
[6.116012]  [f18d6270] ? flexcop_pci_isr+0x0/0x140 [b2c2_flexcop_pci]
[6.116015]  [c10b103c] ? request_threaded_irq+0xbc/0x120
[6.116018]  [c127f5ce] ? pci_iomap+0x9e/0xb0
[6.116021]  [f18d6214] ? flexcop_pci_init+0xc4/0x120 [b2c2_flexcop_pci]
[6.116025]  [f18d6455] ? flexcop_pci_probe+0xa5/0x1d0 [b2c2_flexcop_pci]
[6.116028]  [c1291d37] ? local_pci_probe+0x47/0xb0
[6.116030]  [c12931b8] ? pci_device_probe+0x68/0x90
[6.116034]  [c1333b0d] ? really_probe+0x4d/0x150
[6.116036]  [c133bd7b] ? pm_runtime_barrier+0x4b/0xb0
[6.116039]  [c1333dac] ? driver_probe_device+0x3c/0x60
[6.116041]  [c1333e51] ? __driver_attach+0x81/0x90
[6.116043]  [c1333dd0] ? __driver_attach+0x0/0x90
[6.116046]  [c1332f08] ? bus_for_each_dev+0x48/0x70
[6.116048]  [c1292bc0] ? pci_device_remove+0x0/0xf0
[6.116050]  [c13339be] ? driver_attach+0x1e/0x20
[6.116052]  [c1333dd0] ? __driver_attach+0x0/0x90
[6.116054]  [c13335d8] ? bus_add_driver+0xb8/0x250
[6.116057]  [c1292bc0] ? pci_device_remove+0x0/0xf0
[6.116059]  [c1334096] ? driver_register+0x66/0x110
[6.116062]  [c12922d5] ? __pci_register_driver+0x45/0xb0
[6.116065]  [ef8aa017] ? flexcop_pci_module_init+0x17/0x1000 
[b2c2_flexcop_pci]
[6.116068]  [c1001255] ? do_one_initcall+0x35/0x170
[6.116070]  [ef8aa000] ? flexcop_pci_module_init+0x0/0x1000 
[b2c2_flexcop_pci]
[6.116074]  [c10b] ? sys_init_module+0xdb/0x230
[6.116077]  [c1509904] ? syscall_call+0x7/0xb
[6.116079] ---[ end trace ea1b091448ed01ea ]---
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/3] [media] cx88: use a mutex to protect cx8802_devlist

[Andreas Huber]

Hi Jonathan, thanks for locking into it.
I'll try to debug more deeply what's going wrong and keep you up to date.
Andi.

On 02.04.2011 21:29, Jonathan Nieder wrote:

Hi Andreas,

(please turn off HTML mail.)
Andreas Huber wrote:


There is a reference count bug in the driver code. The driver's
active_ref count may become negative which leads to unpredictable
behavior. (mpeg video device inaccessible, etc ...)

Hmm, the patchset didn't touch active_ref handling.

active_ref was added by v2.6.25-rc3~132^2~7 (V4L/DVB (7194):
cx88-mpeg: Allow concurrent access to cx88-mpeg devices, 2008-02-11)
and relies on three assumptions:

  * (successful) calls to cx8802_driver::request_acquire are balanced
with calls to cx8802_driver::request_release;

  * cx8802_driver::advise_acquire is non-null if and only if
cx8802_driver::advise_release is (since both are NULL for
blackbird, non-NULL for dvb);

  * no data races.

I suppose it would be more idiomatic to use an atomic_t, but access to
active_ref was previously protected by the BKL and now it is protected
by core-lock.  So it's not clear to me why this doesn't work.

Any hints?  (e.g., a detailed reproduction recipe, or a log after
adding a printk to find out when exactly active_ref becomes negative)

Thanks for reporting.
Jonathan


--
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] DM04/QQBOX v1.84 added PID filter

[Malcolm Priestley]

A greatly simplified version of the PID Filter now added
back to the Driver.

The driver allows for the PID filter to be turned off.

applied after patch 683781.

Signed-off-by: Malcolm Priestley tvbox...@gmail.com
---
 drivers/media/dvb/dvb-usb/lmedm04.c |   87 +-
 drivers/media/dvb/dvb-usb/lmedm04.h |1 +
 2 files changed, 85 insertions(+), 3 deletions(-)

diff --git a/drivers/media/dvb/dvb-usb/lmedm04.c 
b/drivers/media/dvb/dvb-usb/lmedm04.c
index ec0f5a7..4e5c521 100644
--- a/drivers/media/dvb/dvb-usb/lmedm04.c
+++ b/drivers/media/dvb/dvb-usb/lmedm04.c
@@ -62,8 +62,6 @@
  * LME2510: SHARP:BS2F7HZ0194(MV0194) cannot cold reset and share system
  * with other tuners. After a cold reset streaming will not start.
  *
- * PID functions have been removed from this driver version due to
- * problems with different firmware and application versions.
  */
 #define DVB_USB_LOG_PREFIX LME2510(C)
 #include linux/usb.h
@@ -104,6 +102,10 @@ static int dvb_usb_lme2510_firmware;
 module_param_named(firmware, dvb_usb_lme2510_firmware, int, 0644);
 MODULE_PARM_DESC(firmware, set default firmware 0=Sharp7395 1=LG);
 
+static int pid_filter;
+module_param_named(pid, pid_filter, int, 0644);
+MODULE_PARM_DESC(pid, set default 0=on 1=off);
+
 
 DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);
 
@@ -216,6 +218,38 @@ static int lme2510_remote_keypress(struct dvb_usb_adapter 
*adap, u32 keypress)
return 0;
 }
 
+static int lme2510_enable_pid(struct dvb_usb_device *d, u8 index, u16 pid_out)
+{
+   struct lme2510_state *st = d-priv;
+   static u8 pid_buff[] = LME_ZERO_PID;
+   static u8 rbuf[1];
+   u8 pid_no = index * 2;
+   int ret = 0;
+   deb_info(1, PID Setting Pid %04x, pid_out);
+
+   pid_buff[2] = pid_no;
+   pid_buff[3] = (u8)pid_out  0xff;
+   pid_buff[4] = pid_no + 1;
+   pid_buff[5] = (u8)(pid_out  8);
+
+   /* wait for i2c mutex */
+   ret = mutex_lock_interruptible(d-i2c_mutex);
+   if (ret  0) {
+   ret = -EAGAIN;
+   return ret;
+   }
+
+   ret |= lme2510_usb_talk(d, pid_buff ,
+   sizeof(pid_buff) , rbuf, sizeof(rbuf));
+
+   if (st-stream_on  1)
+   ret |= lme2510_stream_restart(d);
+
+   mutex_unlock(d-i2c_mutex);
+
+   return ret;
+}
+
 static void lme2510_int_response(struct urb *lme_urb)
 {
struct dvb_usb_adapter *adap = lme_urb-context;
@@ -326,6 +360,41 @@ static int lme2510_int_read(struct dvb_usb_adapter *adap)
return 0;
 }
 
+static int lme2510_pid_filter_ctrl(struct dvb_usb_adapter *adap, int onoff)
+{
+   static u8 clear_pid_reg[] = LME_CLEAR_PID;
+   static u8 rbuf[1];
+   int ret = 0;
+
+   deb_info(1, PID Clearing Filter);
+
+   ret = mutex_lock_interruptible(adap-dev-i2c_mutex);
+
+   if (!onoff)
+   ret |= lme2510_usb_talk(adap-dev, clear_pid_reg,
+   sizeof(clear_pid_reg), rbuf, sizeof(rbuf));
+
+   mutex_unlock(adap-dev-i2c_mutex);
+
+   return 0;
+}
+
+static int lme2510_pid_filter(struct dvb_usb_adapter *adap, int index, u16 pid,
+   int onoff)
+{
+   int ret = 0;
+
+   deb_info(3, %s PID=%04x Index=%04x onoff=%02x, __func__,
+   pid, index, onoff);
+
+   if (onoff)
+   if (!pid_filter)
+   ret = lme2510_enable_pid(adap-dev, index, pid);
+
+   return ret;
+}
+
+
 static int lme2510_return_status(struct usb_device *dev)
 {
int ret = 0;
@@ -1088,7 +1157,13 @@ static struct dvb_usb_device_properties 
lme2510_properties = {
.num_adapters = 1,
.adapter = {
{
+   .caps = DVB_USB_ADAP_HAS_PID_FILTER|
+   DVB_USB_ADAP_NEED_PID_FILTERING|
+   DVB_USB_ADAP_PID_FILTER_CAN_BE_TURNED_OFF,
.streaming_ctrl   = lme2510_streaming_ctrl,
+   .pid_filter_count = 15,
+   .pid_filter = lme2510_pid_filter,
+   .pid_filter_ctrl  = lme2510_pid_filter_ctrl,
.frontend_attach  = dm04_lme2510_frontend_attach,
.tuner_attach = dm04_lme2510_tuner,
/* parameter for the MPEG2-data transfer */
@@ -1124,7 +1199,13 @@ static struct dvb_usb_device_properties 
lme2510c_properties = {
.num_adapters = 1,
.adapter = {
{
+   .caps = DVB_USB_ADAP_HAS_PID_FILTER|
+   DVB_USB_ADAP_NEED_PID_FILTERING|
+   DVB_USB_ADAP_PID_FILTER_CAN_BE_TURNED_OFF,
.streaming_ctrl   = lme2510_streaming_ctrl,
+   .pid_filter_count = 15,
+   .pid_filter = lme2510_pid_filter,
+   .pid_filter_ctrl  = lme2510_pid_filter_ctrl,
.frontend_attach  = dm04_lme2510_frontend_attach,

Re: [PULL] soc-camera: one more patch

[Mauro Carvalho Chehab]

Em 23-03-2011 17:51, Guennadi Liakhovetski escreveu:
 Hi Mauro
 
 Sorry, would be nice if we could manage to push one more patch for 2.6.39:
 
 The following changes since commit f772f016e15a0b93b5aa9680203107ab8cb9bdc6:
 
   [media] media-devnode: don't depend on BKL stuff (2011-03-22 19:43:01 -0300)
 
 are available in the git repository at:
   git://linuxtv.org/gliakhovetski/v4l-dvb.git for-2.6.39
 
 Guennadi Liakhovetski (1):
   V4L: soc_camera_platform: add helper functions to manage device 
 instances
 
  include/media/soc_camera_platform.h |   50 
 +++
  1 files changed, 50 insertions(+), 0 deletions(-)

Guennadi,

While it would be probably ok to send this patch after the end of the merge 
window,
there's no sense on doing it, as no other driver is using the new stuff. So, I 
just
added it at stating/for_2.6.40.
 
 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

--
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] soc-camera: one more patch

[Guennadi Liakhovetski]

Hi Mauro

On Sat, 2 Apr 2011, Mauro Carvalho Chehab wrote:

 Em 23-03-2011 17:51, Guennadi Liakhovetski escreveu:
  Hi Mauro
  
  Sorry, would be nice if we could manage to push one more patch for 2.6.39:
  
  The following changes since commit f772f016e15a0b93b5aa9680203107ab8cb9bdc6:
  
[media] media-devnode: don't depend on BKL stuff (2011-03-22 19:43:01 
  -0300)
  
  are available in the git repository at:
git://linuxtv.org/gliakhovetski/v4l-dvb.git for-2.6.39
  
  Guennadi Liakhovetski (1):
V4L: soc_camera_platform: add helper functions to manage device 
  instances
  
   include/media/soc_camera_platform.h |   50 
  +++
   1 files changed, 50 insertions(+), 0 deletions(-)
 
 Guennadi,
 
 While it would be probably ok to send this patch after the end of the merge 
 window,
 there's no sense on doing it, as no other driver is using the new stuff. So, 
 I just
 added it at stating/for_2.6.40.

These helper functions are for use not by drivers, but by platforms, and I 
was planning to push 2 users after this patch gets merged. But yes, I 
think, it's not that critical...

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

vb2_plane 'mapped' signed bit field

[Dr. David Alan Gilbert]

Hi Pawel,
  'sparse' spotted that vb2_plane's mapped field is a signed
bitfield:

include/media/videobuf2-core.h:78:41 1 bit signed int

struct vb2_plane {
   void*mem_priv;
   int mapped:1;
};

that probably should be an unsigned int (I can see code that assigns
1 to it that just won't fit).

(Introduced by e23ccc0ad9258634e6d52cedf473b35dc34416c7 , spotted in
2.6.39-rc1 )

Dave
-- 
 -Open up your eyes, open up your mind, open up your code ---   
/ Dr. David Alan Gilbert|   Running GNU/Linux   | Happy  \ 
\ gro.gilbert @ treblig.org |   | In Hex /
 \ _|_ http://www.treblig.org   |___/
--
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: vb2_plane 'mapped' signed bit field

[Dr. David Alan Gilbert]

(Originally sent to Pawel's Samsung address that bounced)

* Dr. David Alan Gilbert (li...@treblig.org) wrote:
 Hi Pawel,
   'sparse' spotted that vb2_plane's mapped field is a signed
 bitfield:
 
 include/media/videobuf2-core.h:78:41 1 bit signed int
 
 struct vb2_plane {
void*mem_priv;
int mapped:1;
 };
 
 that probably should be an unsigned int (I can see code that assigns
 1 to it that just won't fit).
 
 (Introduced by e23ccc0ad9258634e6d52cedf473b35dc34416c7 , spotted in
 2.6.39-rc1 )
 
 Dave
 -- 
  -Open up your eyes, open up your mind, open up your code ---   
 / Dr. David Alan Gilbert|   Running GNU/Linux   | Happy  \ 
 \ gro.gilbert @ treblig.org |   | In Hex /
  \ _|_ http://www.treblig.org   |___/
-- 
 -Open up your eyes, open up your mind, open up your code ---   
/ Dr. David Alan Gilbert|   Running GNU/Linux   | Happy  \ 
\ gro.gilbert @ treblig.org |   | In Hex /
 \ _|_ http://www.treblig.org   |___/
--
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