Re: [PATCH v2 1/6] SoC Camera: add driver for OMAP1 camera interface

[Guennadi Liakhovetski]

On Wed, 22 Sep 2010, hermann pitton wrote:

 Am Mittwoch, den 22.09.2010, 01:23 +0200 schrieb Guennadi Liakhovetski:
  On Sat, 11 Sep 2010, Janusz Krzysztofik wrote:
  
   This is a V4L2 driver for TI OMAP1 SoC camera interface.
 
 [snip]
 
   +
   + } else {
   + dev_warn(dev, %s: unhandled camera interrupt, status == 
   + 0x%0x\n, __func__, it_status);
  
  Please, don't split strings
 
 sorry for any OT interference.
 
 But, are there any new rules out?
 
 Maybe I missed them.
 
 Either way, the above was forced during the last three years.
 
 Not at all ?

No. Splitting print strings has always been discouraged, because it makes 
tracking back kernel logs difficult. The reason for this has been the 80 
character line length limit, which has now been effectively lifted. I'm 
sure you can find enough links on the internet for any of these topics.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 2/6] OMAP1: Add support for SoC camera interface

[Guennadi Liakhovetski]

That's up to the platform maintainer to review / apply this one, but if 
you like, a couple of nit-picks from me:

On Sat, 11 Sep 2010, Janusz Krzysztofik wrote:

 This patch adds support for SoC camera interface to OMAP1 devices.
 
 Created and tested against linux-2.6.36-rc3 on Amstrad Delta.
 
 For successfull compilation, requires a header file provided by PATCH 1/6 
 from 
 this series, SoC Camera: add driver for OMAP1 camera interface.
 
 Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
 ---
 v1-v2 changes:
 - no functional changes,
 - refreshed against linux-2.6.36-rc3
 
 
  arch/arm/mach-omap1/devices.c |   43 
 ++
  arch/arm/mach-omap1/include/mach/camera.h |8 +
  2 files changed, 51 insertions(+)
 
 
 diff -upr linux-2.6.36-rc3.orig/arch/arm/mach-omap1/devices.c 
 linux-2.6.36-rc3/arch/arm/mach-omap1/devices.c
 --- linux-2.6.36-rc3.orig/arch/arm/mach-omap1/devices.c   2010-09-03 
 22:29:00.0 +0200
 +++ linux-2.6.36-rc3/arch/arm/mach-omap1/devices.c2010-09-09 
 18:42:30.0 +0200
 @@ -15,6 +15,7 @@
  #include linux/platform_device.h
  #include linux/io.h
  #include linux/spi/spi.h
 +#include linux/dma-mapping.h
  
  #include mach/hardware.h
  #include asm/mach/map.h
 @@ -25,6 +26,7 @@
  #include mach/gpio.h
  #include plat/mmc.h
  #include plat/omap7xx.h
 +#include mach/camera.h

You might want to try to group headers according to their location, i.e., 
put mach/... higher - together with mach/gpio.h, also it helps to have 
headers alphabetically ordered.

  
  /*-*/
  
 @@ -191,6 +193,47 @@ static inline void omap_init_spi100k(voi
  }
  #endif
  
 +
 +#define OMAP1_CAMERA_BASE0xfffb6800
 +
 +static struct resource omap1_camera_resources[] = {
 + [0] = {
 + .start  = OMAP1_CAMERA_BASE,
 + .end= OMAP1_CAMERA_BASE + OMAP1_CAMERA_IOSIZE - 1,
 + .flags  = IORESOURCE_MEM,
 + },
 + [1] = {
 + .start  = INT_CAMERA,
 + .flags  = IORESOURCE_IRQ,
 + },
 +};
 +
 +static u64 omap1_camera_dma_mask = DMA_BIT_MASK(32);
 +
 +static struct platform_device omap1_camera_device = {
 + .name   = omap1-camera,
 + .id = 0, /* This is used to put cameras on this interface */
 + .dev= {
 + .dma_mask   = omap1_camera_dma_mask,
 + .coherent_dma_mask  = DMA_BIT_MASK(32),
 + },
 + .num_resources  = ARRAY_SIZE(omap1_camera_resources),
 + .resource   = omap1_camera_resources,
 +};
 +
 +void __init omap1_set_camera_info(struct omap1_cam_platform_data *info)
 +{
 + struct platform_device *dev = omap1_camera_device;
 + int ret;
 +
 + dev-dev.platform_data = info;
 +
 + ret = platform_device_register(dev);
 + if (ret)
 + dev_err(dev-dev, unable to register device: %d\n, ret);
 +}
 +
 +
  /*-*/
  
  static inline void omap_init_sti(void) {}
 diff -upr linux-2.6.36-rc3.orig/arch/arm/mach-omap1/include/mach/camera.h 
 linux-2.6.36-rc3/arch/arm/mach-omap1/include/mach/camera.h
 --- linux-2.6.36-rc3.orig/arch/arm/mach-omap1/include/mach/camera.h   
 2010-09-03 
 22:34:03.0 +0200
 +++ linux-2.6.36-rc3/arch/arm/mach-omap1/include/mach/camera.h
 2010-09-09 
 18:42:30.0 +0200
 @@ -0,0 +1,8 @@
 +#ifndef __ASM_ARCH_CAMERA_H_
 +#define __ASM_ARCH_CAMERA_H_
 +
 +#include media/omap1_camera.h
 +
 +extern void omap1_set_camera_info(struct omap1_cam_platform_data *);

function declarations don't need an extern - something I've also been 
doing needlessly for a few years...

 +
 +#endif /* __ASM_ARCH_CAMERA_H_ */

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 3/6] SoC Camera: add driver for OV6650 sensor

[Guennadi Liakhovetski]

Ok, just a couple more comments, all looking quite good so far, if we get 
a new version soon enough, we still might manage it for 2.6.37

On Sat, 11 Sep 2010, Janusz Krzysztofik wrote:

[snip]

 +/* write a register */
 +static int ov6650_reg_write(struct i2c_client *client, u8 reg, u8 val)
 +{
 + int ret;
 + unsigned char data[2] = { reg, val };
 + struct i2c_msg msg = {
 + .addr   = client-addr,
 + .flags  = 0,
 + .len= 2,
 + .buf= data,
 + };
 +
 + ret = i2c_transfer(client-adapter, msg, 1);
 + msleep_interruptible(1);

Why do you want _interruptible here? Firstly it's just 1ms, secondly - 
why?...

 +
 + if (ret  0) {
 + dev_err(client-dev, Failed writing register 0x%02x!\n, reg);
 + return ret;
 + }
 + return 0;
 +}

...

 +/* set the format we will capture in */
 +static int ov6650_s_fmt(struct v4l2_subdev *sd,
 + struct v4l2_mbus_framefmt *mf)
 +{
 + struct i2c_client *client = sd-priv;
 + struct soc_camera_device *icd   = client-dev.platform_data;
 + struct soc_camera_sense *sense = icd-sense;
 + struct ov6650 *priv = to_ov6650(client);
 + enum v4l2_mbus_pixelcode code = mf-code;
 + unsigned long pclk;
 + u8 coma_set = 0, coma_mask = 0, coml_set = 0, coml_mask = 0;
 + u8 clkrc, clkrc_div;
 + int ret;
 +
 + /* select color matrix configuration for given color encoding */
 + switch (code) {
 + case V4L2_MBUS_FMT_GREY8_1X8:
 + dev_dbg(client-dev, pixel format GREY8_1X8\n);
 + coma_set |= COMA_BW;
 + coma_mask |= COMA_RGB | COMA_WORD_SWAP | COMA_BYTE_SWAP;
 + break;
 + case V4L2_MBUS_FMT_YUYV8_2X8:
 + dev_dbg(client-dev, pixel format YUYV8_2X8_LE\n);
 + coma_set |= COMA_WORD_SWAP;
 + coma_mask |= COMA_RGB | COMA_BW | COMA_BYTE_SWAP;
 + break;
 + case V4L2_MBUS_FMT_YVYU8_2X8:
 + dev_dbg(client-dev, pixel format YVYU8_2X8_LE (untested)\n);
 + coma_mask |= COMA_RGB | COMA_BW | COMA_WORD_SWAP |
 + COMA_BYTE_SWAP;
 + break;
 + case V4L2_MBUS_FMT_UYVY8_2X8:
 + dev_dbg(client-dev, pixel format YUYV8_2X8_BE\n);
 + if (mf-width == W_CIF) {
 + coma_set |= COMA_BYTE_SWAP | COMA_WORD_SWAP;
 + coma_mask |= COMA_RGB | COMA_BW;
 + } else {
 + coma_set |= COMA_BYTE_SWAP;
 + coma_mask |= COMA_RGB | COMA_BW | COMA_WORD_SWAP;
 + }
 + break;
 + case V4L2_MBUS_FMT_VYUY8_2X8:
 + dev_dbg(client-dev, pixel format YVYU8_2X8_BE (untested)\n);
 + if (mf-width == W_CIF) {
 + coma_set |= COMA_BYTE_SWAP;
 + coma_mask |= COMA_RGB | COMA_BW | COMA_WORD_SWAP;
 + } else {
 + coma_set |= COMA_BYTE_SWAP | COMA_WORD_SWAP;
 + coma_mask |= COMA_RGB | COMA_BW;
 + }
 + break;
 + case V4L2_MBUS_FMT_SBGGR8_1X8:
 + dev_dbg(client-dev, pixel format SBGGR8_1X8 (untested)\n);
 + coma_set |= COMA_RAW_RGB | COMA_RGB;
 + coma_mask |= COMA_BW | COMA_BYTE_SWAP | COMA_WORD_SWAP;
 + break;
 + default:
 + dev_err(client-dev, Pixel format not handled: 0x%x\n, code);
 + return -EINVAL;
 + }
 + priv-code = code;
 +
 + if ((code == V4L2_MBUS_FMT_GREY8_1X8) ||
 + (code == V4L2_MBUS_FMT_SBGGR8_1X8)) {

Superfluous parenthesis

 + coml_mask |= COML_ONE_CHANNEL;
 + priv-pclk_max = 400;
 + } else {
 + coml_set |= COML_ONE_CHANNEL;
 + priv-pclk_max = 800;
 + }

coml_mask and coml_set are only set here and only used once below, so, 
dropping initialisation to 0 in variable definitions and just doing

+   if (code == V4L2_MBUS_FMT_GREY8_1X8 ||
+   code == V4L2_MBUS_FMT_SBGGR8_1X8) {
+   coml_mask = COML_ONE_CHANNEL;
+   coml_set = 0;
+   priv-pclk_max = 400;
+   } else {
+   coml_mask = 0;
+   coml_set = COML_ONE_CHANNEL;
+   priv-pclk_max = 800;
+   }

would work too.

 +
 + if (code == V4L2_MBUS_FMT_SBGGR8_1X8)
 + priv-colorspace = V4L2_COLORSPACE_SRGB;
 + else
 + priv-colorspace = V4L2_COLORSPACE_JPEG;
 +
 + /*
 +  * Select register configuration for given resolution.
 +  * To be replaced with a common function that does it, once available.
 +  */
 + ov6650_res_roundup(mf-width, mf-height);
 +
 + switch (mf-width) {
 + case W_QCIF:
 + dev_dbg(client-dev, resolution QCIF\n);
 + priv-qcif = 1;
 + coma_set |= COMA_QCIF;
 + priv-pclk_max /= 2;
 +  

Problem scanning channels with Terratec S7 (USB-DVBS2)

[Lars Fredriksson]

Hi!
 
I have a Terratec S7 (MKII) that I can connect and get it working (almost) with 
my Mythbuntu. The card get's detected, but I have problems scanning after 
channels, both with scan and with MythTV, it only finds one or maybe two 
transponders (there is no problem with dish, my old HVR4000 works great).
I have seen som olde posts about the same problem but no answers on them, and 
as there are no newer posts maybe there is a solution I've missed?
 
I'm running kernel 2.6.32 and latest v4l (I've tried s2-liplianin as well, same 
result), Firmware from Terratecs driverpack.
 
The card is the same as Terratec Skystar USB2.
 
Regards, and thanks for any help, Lars Fredriksson--
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/9] V4L2 FM driver for TI WL127x and WL128x

[x0130808]

From: Raja Mani raja_m...@ti.com

This is third patch set for TI FM driver for TI WiLink chips.
It provides FM Receive and Transmit support for TI WL127x and WL128x chips.
It also extends V4L2 CIDs to support few FM Receive features.

Note:
This patch set re-uses new FM RX CID definitions by Nokia FM driver for
TI WL127x chip. Recent Nokia patch can be found at
http://www.spinics.net/lists/linux-media/msg22484.html.

TI FM driver makes use of TI Shared Transport solution for TI WL chips.
TI Shared Transport driver is available in mainline kernel staging
folder - /drivers/staging/ti-st/.

Raja Mani (9):
  drivers:staging:ti-st: sources for FM common interfaces
  drivers:staging:ti-st: Sources for FM RX
  drivers:staging:ti-st: Sources for FM TX
  drivers:staging:ti-st: Sources for FM V4L2 interfaces
  drivers:staging:ti-st: Sources for FM common header
  drivers:media:video: Adding new CIDs for FM RX ctls
  include:linux:videodev2: Define 2 new CIDs for FM RX ctls
  Documentation:DocBook:v4l: Update the controls.xml for FM driver
  Staging:ti-st: Update Kconfig and Makefile for FM driver

 Documentation/DocBook/v4l/controls.xml |   12 +
 drivers/media/video/v4l2-common.c  |4 +
 drivers/staging/ti-st/Makefile |2 +-
 drivers/staging/ti-st/fm.h |   13 +
 drivers/staging/ti-st/fmdrv.h  |  230 
 drivers/staging/ti-st/fmdrv_common.c   | 2149 
 drivers/staging/ti-st/fmdrv_common.h   |  476 +++
 drivers/staging/ti-st/fmdrv_rx.c   |  927 ++
 drivers/staging/ti-st/fmdrv_rx.h   |   57 +
 drivers/staging/ti-st/fmdrv_tx.c   |  451 +++
 drivers/staging/ti-st/fmdrv_tx.h   |   37 +
 drivers/staging/ti-st/fmdrv_v4l2.c |  731 +++
 drivers/staging/ti-st/fmdrv_v4l2.h |   32 +
 include/linux/videodev2.h  |7 +
 14 files changed, 5127 insertions(+), 1 deletions(-)
 create mode 100644 drivers/staging/ti-st/fm.h
 create mode 100644 drivers/staging/ti-st/fmdrv.h
 create mode 100644 drivers/staging/ti-st/fmdrv_common.c
 create mode 100644 drivers/staging/ti-st/fmdrv_common.h
 create mode 100644 drivers/staging/ti-st/fmdrv_rx.c
 create mode 100644 drivers/staging/ti-st/fmdrv_rx.h
 create mode 100644 drivers/staging/ti-st/fmdrv_tx.c
 create mode 100644 drivers/staging/ti-st/fmdrv_tx.h
 create mode 100644 drivers/staging/ti-st/fmdrv_v4l2.c
 create mode 100644 drivers/staging/ti-st/fmdrv_v4l2.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

[RFC/PATCH 9/9] Staging:ti-st: Update Kconfig and Makefile for

[x0130808]

From: Raja Mani raja_m...@ti.com

Add new menu option in Kconfig and compilation option in Makefile for
TI FM driver.

Signed-off-by: Raja Mani raja_m...@ti.com
Signed-off-by: Pramodh AG pramodh...@ti.com
Signed-off-by: Manjunatha Halli x0130...@ti.com
---
 drivers/staging/ti-st/Kconfig  |8 
 drivers/staging/ti-st/Makefile |2 ++
 2 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/drivers/staging/ti-st/Kconfig b/drivers/staging/ti-st/Kconfig
index 1b264a3..7e48749 100644
--- a/drivers/staging/ti-st/Kconfig
+++ b/drivers/staging/ti-st/Kconfig
@@ -23,4 +23,12 @@ config ST_BT
  This makes use of shared transport line discipline core driver to
  communicate with the BT core of the combo chip.
 
+config ST_FM
+   tristate fm driver for ST
+   depends on VIDEO_DEV
+   select TI_ST
+   help
+ This enables the FM driver for TI BT/FM/GPS combo devices
+ This makes use of shared transport line discipline core driver to
+ communicate with the FM core of the combo chip.
 endmenu
diff --git a/drivers/staging/ti-st/Makefile b/drivers/staging/ti-st/Makefile
index 0167d1d..bd29c83 100644
--- a/drivers/staging/ti-st/Makefile
+++ b/drivers/staging/ti-st/Makefile
@@ -5,3 +5,5 @@
 obj-$(CONFIG_TI_ST)+= st_drv.o
 st_drv-objs:= st_core.o st_kim.o st_ll.o
 obj-$(CONFIG_ST_BT)+= bt_drv.o
+obj-$(CONFIG_ST_FM)+= fm_drv.o
+fm_drv-objs:= fmdrv_common.o fmdrv_rx.o fmdrv_tx.o 
fmdrv_v4l2.o
-- 
1.5.6.3

--
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 4/9] drivers:staging:ti-st: Sources for FM V4L2 interfaces

[x0130808]

From: Raja Mani raja_m...@ti.com

This module interfaces V4L2 subsystem and FM common
module. It registers itself with V4L2 as Radio module.

Signed-off-by: Raja Mani raja_m...@ti.com
Signed-off-by: Pramodh AG pramodh...@ti.com
Signed-off-by: Manjunatha Halli x0130...@ti.com
---
 drivers/staging/ti-st/fmdrv_v4l2.c |  731 
 drivers/staging/ti-st/fmdrv_v4l2.h |   32 ++
 2 files changed, 763 insertions(+), 0 deletions(-)
 create mode 100644 drivers/staging/ti-st/fmdrv_v4l2.c
 create mode 100644 drivers/staging/ti-st/fmdrv_v4l2.h

diff --git a/drivers/staging/ti-st/fmdrv_v4l2.c 
b/drivers/staging/ti-st/fmdrv_v4l2.c
new file mode 100644
index 000..885a211
--- /dev/null
+++ b/drivers/staging/ti-st/fmdrv_v4l2.c
@@ -0,0 +1,731 @@
+/*
+ *  FM Driver for Connectivity chip of Texas Instruments.
+ *  This file provides interfaces to V4L2 subsystem.
+ *
+ *  This module registers with V4L2 subsystem as Radio
+ *  data system interface (/dev/radio). During the registration,
+ *  it will expose two set of function pointers to V4L2 subsystem.
+ *
+ *1) File operation related API (open, close, read, write, poll...etc).
+ *2) Set of V4L2 IOCTL complaint API.
+ *
+ *  Copyright (C) 2010 Texas Instruments
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2 as
+ *  published by the Free Software Foundation.
+ *
+ *  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 fmdrv.h
+#include fmdrv_v4l2.h
+#include fmdrv_common.h
+#include fmdrv_rx.h
+#include fmdrv_tx.h
+
+static struct video_device *gradio_dev;
+static unsigned char radio_disconnected;
+
+/* Query control */
+static struct v4l2_queryctrl fmdrv_v4l2_queryctrl[] = {
+   {
+.id = V4L2_CID_AUDIO_VOLUME,
+.type = V4L2_CTRL_TYPE_INTEGER,
+.name = Volume,
+.minimum = FM_RX_VOLUME_MIN,
+.maximum = FM_RX_VOLUME_MAX,
+.step = 1,
+.default_value = FM_DEFAULT_RX_VOLUME,
+},
+   {
+.id = V4L2_CID_AUDIO_BALANCE,
+.flags = V4L2_CTRL_FLAG_DISABLED,
+},
+   {
+.id = V4L2_CID_AUDIO_BASS,
+.flags = V4L2_CTRL_FLAG_DISABLED,
+},
+   {
+.id = V4L2_CID_AUDIO_TREBLE,
+.flags = V4L2_CTRL_FLAG_DISABLED,
+},
+   {
+.id = V4L2_CID_AUDIO_MUTE,
+.type = V4L2_CTRL_TYPE_BOOLEAN,
+.name = Mute,
+.minimum = 0,
+.maximum = 2,
+.step = 1,
+.default_value = FM_MUTE_OFF,
+},
+   {
+.id = V4L2_CID_AUDIO_LOUDNESS,
+.flags = V4L2_CTRL_FLAG_DISABLED,
+},
+};
+
+/* -- V4L2 RADIO (/dev/radioX) device file operation interfaces --- */
+
+/* Read RX RDS data */
+static ssize_t fm_v4l2_fops_read(struct file *file, char __user * buf,
+   size_t count, loff_t *ppos)
+{
+   unsigned char rds_mode;
+   int ret;
+   struct fmdrv_ops *fmdev;
+
+   fmdev = video_drvdata(file);
+
+   if (!radio_disconnected) {
+   pr_err((fmdrv): FM device is already disconnected\n);
+   return -EIO;
+   }
+
+   /* Turn on RDS mode , if it is disabled */
+   ret = fm_rx_get_rds_mode(fmdev, rds_mode);
+   if (ret  0) {
+   pr_err((fmdrv): Unable to read current rds mode\n);
+   return ret;
+   }
+   if (rds_mode == FM_RDS_DISABLE) {
+   ret = fmc_set_rds_mode(fmdev, FM_RDS_ENABLE);
+   if (ret  0) {
+   pr_err((fmdrv): Failed to enable rds mode\n);
+   return ret;
+   }
+   }
+   /* Copy RDS data from internal buffer to user buffer */
+   ret = fmc_transfer_rds_from_internal_buff(fmdev, file, buf, count);
+   return ret;
+}
+
+/* Write TX RDS data */
+static ssize_t fm_v4l2_fops_write(struct file *file, const char __user * buf,
+   size_t count, loff_t *ppos)
+{
+   struct tx_rds rds;
+   int ret;
+   struct fmdrv_ops *fmdev;
+
+   ret = copy_from_user(rds, buf, sizeof(rds));
+   pr_debug((fmdrv): (%d)type: %d, text %s, af %d\n,
+  ret, rds.text_type, rds.text, rds.af_freq);
+
+   fmdev = video_drvdata(file);
+   fm_tx_set_radio_text(fmdev, rds.text, rds.text_type);
+   fm_tx_set_af(fmdev, rds.af_freq);
+
+   return 0;
+}
+
+static unsigned int fm_v4l2_fops_poll(struct file *file,
+ struct 

[RFC/PATCH 8/9] Documentation:DocBook:v4l: Update the controls.xml

[x0130808]

From: Raja Mani raja_m...@ti.com

Added entries for following 2 new CID's which are added for TI FM driver:
- V4L2_CID_RSSI_THRESHOLD
- V4L2_CID_TUNE_AF

Signed-off-by: Raja Mani raja_m...@ti.com
Signed-off-by: Pramodh AG pramodh...@ti.com
Signed-off-by: Manjunatha Halli x0130...@ti.com
---
 Documentation/DocBook/v4l/controls.xml |   12 
 1 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/Documentation/DocBook/v4l/controls.xml 
b/Documentation/DocBook/v4l/controls.xml
index 8408caa..e074f73 100644
--- a/Documentation/DocBook/v4l/controls.xml
+++ b/Documentation/DocBook/v4l/controls.xml
@@ -132,6 +132,18 @@ consumption state./entry
entryLoudness mode (bass boost)./entry
  /row
  row
+   entryconstantV4L2_CID_RSSI_THRESHOLD/constant/entry
+   entryinteger/entry
+   entrySet RSSI threshold level. Change the default threshold
+level used to select valid frequencies during vidioc_s_hw_freq_seek./entry
+ /row
+ row
+   entryconstantV4L2_CID_TUNE_AF/constant/entry
+   entryinteger/entry
+   entrySet Alternative Frequency mode. Enable or disable
+alternative frequency mode./entry
+ /row
+ row
entryconstantV4L2_CID_BLACK_LEVEL/constant/entry
entryinteger/entry
entryAnother name for brightness (not a synonym of
-- 
1.5.6.3

--
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 7/9] include:linux:videodev2: Define 2 new CIDs for FM RX

[x0130808]

From: Raja Mani raja_m...@ti.com

Extend V4L2 CID list to support
   1) RSSI Threshold
   2) Alternative Frequency

Signed-off-by: Raja Mani raja_m...@ti.com
Signed-off-by: Pramodh AG pramodh...@ti.com
Signed-off-by: Manjunatha Halli x0130...@ti.com
---
 include/linux/videodev2.h |7 +++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index e9d018d..369987b 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -1374,6 +1374,13 @@ enum v4l2_fm_band {
V4L2_FM_BAND_OIRT   = 2
 };
 
+#define V4L2_CID_RSSI_THRESHOLD(V4L2_CID_FM_RX_CLASS_BASE + 2)
+#define V4L2_CID_TUNE_AF   (V4L2_CID_FM_RX_CLASS_BASE + 3)
+enum v4l2_tune_af {
+   V4L2_FM_AF_OFF  = 0,
+   V4L2_FM_AF_ON   = 1
+};
+
 /*
  * T U N I N G
  */
-- 
1.5.6.3

--
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 6/9] drivers:media:video: Adding new CIDs for FM RX ctls

[x0130808]

From: Raja Mani raja_m...@ti.com

Add support for the following new Control IDs (CID)
   V4L2_CID_RSSI_THRESHOLD - RSSI Threshold
   V4L2_CID_TUNE_AF- Alternative Frequency

Signed-off-by: Raja Mani raja_m...@ti.com
Signed-off-by: Pramodh AG pramodh...@ti.com
Signed-off-by: Manjunatha Halli x0130...@ti.com
---
 drivers/media/video/v4l2-common.c |4 
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/drivers/media/video/v4l2-common.c 
b/drivers/media/video/v4l2-common.c
index 4e53b0b..5a8e528 100644
--- a/drivers/media/video/v4l2-common.c
+++ b/drivers/media/video/v4l2-common.c
@@ -520,6 +520,8 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_TUNE_PREEMPHASIS: return Pre-emphasis settings;
case V4L2_CID_TUNE_POWER_LEVEL: return Tune Power Level;
case V4L2_CID_TUNE_ANTENNA_CAPACITOR:   return Tune Antenna Capacitor;
+   case V4L2_CID_RSSI_THRESHOLD:   return RSSI Threshold;
+   case V4L2_CID_TUNE_AF:  return Alternative Frequency;
 
default:
return NULL;
@@ -585,6 +587,8 @@ int v4l2_ctrl_query_fill(struct v4l2_queryctrl *qctrl, s32 
min, s32 max, s32 ste
case V4L2_CID_EXPOSURE_AUTO:
case V4L2_CID_COLORFX:
case V4L2_CID_TUNE_PREEMPHASIS:
+   case V4L2_CID_RSSI_THRESHOLD:
+   case V4L2_CID_TUNE_AF:
qctrl-type = V4L2_CTRL_TYPE_MENU;
step = 1;
break;
-- 
1.5.6.3

--
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 5/9] drivers:staging:ti-st: Sources for FM common header

[x0130808]

From: Raja Mani raja_m...@ti.com

These are common headers used in FM submodules (FM V4L2, FM common, FM Rx,
and FM TX).

Signed-off-by: Raja Mani raja_m...@ti.com
Signed-off-by: Pramodh AG pramodh...@ti.com
Signed-off-by: Manjunatha Halli x0130...@ti.com
---
 drivers/staging/ti-st/fm.h|   13 +++
 drivers/staging/ti-st/fmdrv.h |  230 +
 2 files changed, 243 insertions(+), 0 deletions(-)
 create mode 100644 drivers/staging/ti-st/fm.h
 create mode 100644 drivers/staging/ti-st/fmdrv.h

diff --git a/drivers/staging/ti-st/fm.h b/drivers/staging/ti-st/fm.h
new file mode 100644
index 000..be41453
--- /dev/null
+++ b/drivers/staging/ti-st/fm.h
@@ -0,0 +1,13 @@
+struct fm_event_hdr {
+   unsigned char plen;
+} __attribute__ ((packed));
+
+#define FM_MAX_FRAME_SIZE 0xFF /* TODO: */
+#define FM_EVENT_HDR_SIZE 1/* size of fm_event_hdr */
+#define ST_FM_CH8_PKT 0x8
+
+/* gps stuff */
+struct gps_event_hdr {
+unsigned char opcode;
+unsigned short plen;
+} __attribute__ ((packed));
diff --git a/drivers/staging/ti-st/fmdrv.h b/drivers/staging/ti-st/fmdrv.h
new file mode 100644
index 000..4ca368d
--- /dev/null
+++ b/drivers/staging/ti-st/fmdrv.h
@@ -0,0 +1,230 @@
+/*
+ *  FM Driver for Connectivity chip of Texas Instruments.
+ *
+ *  Common header for all FM driver sub-modules.
+ *
+ *  Copyright (C) 2009 Texas Instruments
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2 as
+ *  published by the Free Software Foundation.
+ *
+ *  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
+ *
+ */
+
+#ifndef _FM_DRV_H
+#define _FM_DRV_H
+
+#include linux/skbuff.h
+#include linux/interrupt.h
+#include sound/core.h
+#include sound/initval.h
+#include linux/timer.h
+#include linux/version.h
+
+#define FM_DRV_VERSION0.01
+/* Should match with FM_DRV_VERSION */
+#define FM_DRV_RADIO_VERSION  KERNEL_VERSION(0, 0, 1)
+#define FM_DRV_NAME   ti_fmdrv
+#define FM_DRV_CARD_SHORT_NAMETI FM Radio
+#define FM_DRV_CARD_LONG_NAME Texas Instruments FM Radio
+
+/* Flag info */
+#define FM_INTTASK_RUNNING0
+#define FM_INTTASK_SCHEDULE_PENDING   1
+#define FM_FIRMWARE_DW_INPROGRESS 2
+#define FM_CORE_READY 3
+#define FM_CORE_TRANSPORT_READY   4
+#define FM_AF_SWITCH_INPROGRESS  5
+#define FM_CORE_TX_XMITING   6
+
+#define FM_DRV_TX_TIMEOUT  (5*HZ)  /* 5 seconds */
+#define FM_DRV_RX_SEEK_TIMEOUT (20*HZ) /* 20 seconds */
+
+#define NO_OF_ENTRIES_IN_ARRAY(array) (sizeof(array) / sizeof(array[0]))
+
+enum {
+   FM_MODE_OFF,
+   FM_MODE_TX,
+   FM_MODE_RX,
+   FM_MODE_ENTRY_MAX
+};
+
+#define FM_RX_RDS_INFO_FIELD_MAX   8   /* 4 Group * 2 Bytes */
+
+/* RX RDS data format */
+struct fm_rdsdata_format {
+   union {
+   struct {
+   unsigned char rdsbuff[FM_RX_RDS_INFO_FIELD_MAX];
+   } groupdatabuff;
+   struct {
+   unsigned short pidata;
+   unsigned char block_b_byte1;
+   unsigned char block_b_byte2;
+   unsigned char block_c_byte1;
+   unsigned char block_c_byte2;
+   unsigned char block_d_byte1;
+   unsigned char block_d_byte2;
+   } groupgeneral;
+   struct {
+   unsigned short pidata;
+   unsigned char block_b_byte1;
+   unsigned char block_b_byte2;
+   unsigned char firstaf;
+   unsigned char secondaf;
+   unsigned char firstpsbyte;
+   unsigned char secondpsbyte;
+   } group0A;
+
+   struct {
+   unsigned short pidata;
+   unsigned char block_b_byte1;
+   unsigned char block_b_byte2;
+   unsigned short pidata2;
+   unsigned char firstpsbyte;
+   unsigned char secondpsbyte;
+   } group0B;
+   } rdsdata;
+};
+
+/* FM region (Europe/US, Japan) info */
+struct region_info {
+   unsigned int channel_spacing;
+   unsigned int bottom_frequency;
+   unsigned int top_frequency;
+   unsigned char region_index;
+};
+
+typedef void (*int_handler_prototype) (void *);
+
+/* FM Interrupt processing related info */
+struct fm_irq {
+   unsigned 

[RFC/PATCH 3/9] drivers:staging:ti-st: Sources for FM TX

[x0130808]

From: Raja Mani raja_m...@ti.com

This has implementation for FM TX functionality.
It communicates with FM V4l2 module and FM common module.

Signed-off-by: Raja Mani raja_m...@ti.com
Signed-off-by: Pramodh AG pramodh...@ti.com
Signed-off-by: Manjunatha Halli x0130...@ti.com
---
 drivers/staging/ti-st/fmdrv_tx.c |  451 ++
 drivers/staging/ti-st/fmdrv_tx.h |   37 +++
 2 files changed, 488 insertions(+), 0 deletions(-)
 create mode 100644 drivers/staging/ti-st/fmdrv_tx.c
 create mode 100644 drivers/staging/ti-st/fmdrv_tx.h

diff --git a/drivers/staging/ti-st/fmdrv_tx.c b/drivers/staging/ti-st/fmdrv_tx.c
new file mode 100644
index 000..2c9f004
--- /dev/null
+++ b/drivers/staging/ti-st/fmdrv_tx.c
@@ -0,0 +1,451 @@
+/*
+ *  FM Driver for Connectivity chip of Texas Instruments.
+ *  This sub-module of FM driver implements FM TX functionality.
+ *
+ *  Copyright (C) 2010 Texas Instruments
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2 as
+ *  published by the Free Software Foundation.
+ *
+ *  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/delay.h
+#include fmdrv.h
+#include fmdrv_common.h
+#include fmdrv_tx.h
+
+int fm_tx_set_stereo_mono(struct fmdrv_ops *fmdev, unsigned short mode)
+{
+   unsigned short payload;
+   int ret = 0;
+
+   if (fmdev-curr_fmmode != FM_MODE_TX)
+   return -EPERM;
+
+   if (fmdev-tx_data.aud_mode == mode)
+   return ret;
+
+   pr_debug(stereo mode: %d\n, mode);
+
+   /* Set Stereo/Mono mode */
+   FM_STORE_LE16_TO_BE16(payload, (1 - mode));
+   ret = fmc_send_cmd(fmdev, MONO_SET, payload, sizeof(payload),
+   fmdev-maintask_completion, NULL, NULL);
+   if (ret  0) {
+   pr_err((fmdrv): Failed to set TX stereo/mono mode - %d\n,
+   ret);
+   return ret;
+   }
+
+   fmdev-tx_data.aud_mode = mode;
+   return ret;
+}
+
+static int __set_rds_text(struct fmdrv_ops *fmdev, unsigned char *rds_text)
+{
+   unsigned short payload;
+   int ret;
+
+   ret = fmc_send_cmd(fmdev, RDS_DATA_SET, rds_text, strlen(rds_text),
+   fmdev-maintask_completion, NULL, NULL);
+   if (ret  0) {
+   pr_err((fmdrv): Failed to set TX RDS data - %d\n, ret);
+   return ret;
+   }
+
+   /* Scroll mode */
+   FM_STORE_LE16_TO_BE16(payload, (unsigned short)0x1);
+   ret = fmc_send_cmd(fmdev, DISPLAY_MODE_SET, payload, sizeof(payload),
+   fmdev-maintask_completion, NULL, NULL);
+   if (ret  0) {
+   pr_err((fmdrv): Failed to set RDS display mode - %d\n, ret);
+   return ret;
+   }
+
+   return 0;
+}
+
+static int __set_rds_data_mode(struct fmdrv_ops *fmdev, unsigned char mode)
+{
+   unsigned short payload;
+   int ret;
+
+   /* Setting unique PI TODO: how unique? */
+   FM_STORE_LE16_TO_BE16(payload, (unsigned short)0xcafe);
+   ret = fmc_send_cmd(fmdev, PI_SET, payload, sizeof(payload),
+   fmdev-maintask_completion, NULL, NULL);
+   if (ret  0) {
+   pr_err((fmdrv): Failed to set PI - %d\n, ret);
+   return ret;
+   }
+
+   /* Set decoder id */
+   FM_STORE_LE16_TO_BE16(payload, (unsigned short)0xa);
+   ret = fmc_send_cmd(fmdev, DI_SET, payload, sizeof(payload),
+   fmdev-maintask_completion, NULL, NULL);
+   if (ret  0) {
+   pr_err((fmdrv): Failed to set DI - %d\n, ret);
+   return ret;
+   }
+
+   /* TODO: RDS_MODE_GET? */
+   return 0;
+}
+
+static int __set_rds_len(struct fmdrv_ops *fmdev, unsigned char type,
+   unsigned short len)
+{
+   unsigned short payload;
+   int ret;
+
+   len |= type  8;
+   FM_STORE_LE16_TO_BE16(payload, len);
+   ret = fmc_send_cmd(fmdev, LENGTH_SET, payload, sizeof(payload),
+   fmdev-maintask_completion, NULL, NULL);
+   if (ret  0) {
+   pr_err((fmdrv): Failed to set RDS data length - %d\n, ret);
+   return ret;
+   }
+
+   /* TODO: LENGTH_GET? */
+   return 0;
+}
+
+int fm_tx_set_rds_mode(struct fmdrv_ops *fmdev, unsigned char rds_en_dis)
+{
+   unsigned short payload;
+   int ret;
+   unsigned char rds_text[] = Zoom2\n;
+
+   if 

[RFC/PATCH 2/9] drivers:staging:ti-st: Sources for FM RX

[x0130808]

From: Raja Mani raja_m...@ti.com

This has implementation for FM RX functionality.
It communicates with FM V4l2 module and FM common module.

Signed-off-by: Raja Mani raja_m...@ti.com
Signed-off-by: Pramodh AG pramodh...@ti.com
Signed-off-by: Manjunatha Halli x0130...@ti.com
---
 drivers/staging/ti-st/fmdrv_rx.c |  927 ++
 drivers/staging/ti-st/fmdrv_rx.h |   57 +++
 2 files changed, 984 insertions(+), 0 deletions(-)
 create mode 100644 drivers/staging/ti-st/fmdrv_rx.c
 create mode 100644 drivers/staging/ti-st/fmdrv_rx.h

diff --git a/drivers/staging/ti-st/fmdrv_rx.c b/drivers/staging/ti-st/fmdrv_rx.c
new file mode 100644
index 000..c5cd033
--- /dev/null
+++ b/drivers/staging/ti-st/fmdrv_rx.c
@@ -0,0 +1,927 @@
+/*
+ *  FM Driver for Connectivity chip of Texas Instruments.
+ *  This sub-module of FM driver implements FM RX functionality.
+ *
+ *  Copyright (C) 2010 Texas Instruments
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2 as
+ *  published by the Free Software Foundation.
+ *
+ *  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 fmdrv.h
+#include fmdrv_common.h
+#include fmdrv_rx.h
+
+void fm_rx_reset_rds_cache(struct fmdrv_ops *fmdev)
+{
+   fmdev-rx.rds.flag = FM_RDS_DISABLE;
+   fmdev-rx.rds.last_block_index = 0;
+   fmdev-rx.rds.wr_index = 0;
+   fmdev-rx.rds.rd_index = 0;
+
+   if (fmdev-rx.af_mode == FM_RX_RDS_AF_SWITCH_MODE_ON)
+   fmdev-irq_info.mask |= FM_LEV_EVENT;
+
+}
+
+void fm_rx_reset_curr_station_info(struct fmdrv_ops *fmdev)
+{
+   fmdev-rx.cur_station_info.picode = FM_NO_PI_CODE;
+   fmdev-rx.cur_station_info.no_of_items_in_afcache = 0;
+   fmdev-rx.cur_station_info.af_list_max = 0;
+}
+
+int fm_rx_set_frequency(struct fmdrv_ops *fmdev, unsigned int freq_to_set)
+{
+   unsigned long timeleft;
+   unsigned short payload, curr_frq, frq_index;
+   unsigned int curr_frq_in_khz;
+   int ret, resp_len;
+
+   if (fmdev-curr_fmmode != FM_MODE_RX) {
+   ret = -EPERM;
+   goto exit;
+   }
+
+   if (freq_to_set  fmdev-rx.region.bottom_frequency ||
+   freq_to_set  fmdev-rx.region.top_frequency) {
+   pr_err((fmdrv): Invalid frequency %d\n, freq_to_set);
+   ret = -EINVAL;
+   goto exit;
+   }
+   /* Set audio enable */
+   FM_STORE_LE16_TO_BE16(payload, FM_RX_FM_AUDIO_ENABLE_I2S_AND_ANALOG);
+   ret = fmc_send_cmd(fmdev, AUDIO_ENABLE_SET, payload, sizeof(payload),
+   fmdev-maintask_completion, NULL, NULL);
+   if (ret  0) {
+   pr_err((fmdrv): Failed to set RX audio enable path - %d\n,
+   ret);
+   return ret;
+   }
+
+   /* Set hilo to automatic selection */
+   FM_STORE_LE16_TO_BE16(payload, FM_RX_IFFREQ_HILO_AUTOMATIC);
+   ret = fmc_send_cmd(fmdev, HILO_SET, payload, sizeof(payload),
+   fmdev-maintask_completion, NULL, NULL);
+   if (ret  0) {
+   pr_err((fmdrv): Failed to set HILO to automatic selection 
+   - %d\n, ret);
+   return ret;
+   }
+
+   /* Calculate frequency index to write */
+   frq_index = (freq_to_set - fmdev-rx.region.bottom_frequency) /
+   fmdev-rx.region.channel_spacing;
+
+   /* Set frequency index */
+   FM_STORE_LE16_TO_BE16(payload, frq_index);
+   ret = fmc_send_cmd(fmdev, FREQ_SET, payload, sizeof(payload),
+   fmdev-maintask_completion, NULL, NULL);
+   if (ret  0) {
+   pr_err((fmdrv): Failed to set frequency index - %d\n, ret);
+   return ret;
+   }
+
+   /* Read flags - just to clear any pending interrupts if we had */
+   ret = fmc_send_cmd(fmdev, FLAG_GET, NULL, 2,
+   fmdev-maintask_completion, NULL, NULL);
+   if (ret  0) {
+   pr_err((fmdrv): Failed to read interrupt flag - %d\n, ret);
+   return ret;
+   }
+
+   /* Enable FR, BL interrupts */
+   fmdev-irq_info.mask |= (FM_FR_EVENT | FM_BL_EVENT);
+   FM_STORE_LE16_TO_BE16(payload, fmdev-irq_info.mask);
+   ret = fmc_send_cmd(fmdev, INT_MASK_SET, payload, sizeof(payload),
+   fmdev-maintask_completion, NULL, NULL);
+   if (ret  0) {
+   pr_err((fmdrv): Failed to set interrupt mask - %d\n, 

[PATCH] ir-core: Fix null dereferences in the protocols sysfs interface

[Brian Rogers]

For some cards, ir_dev-props and ir_dev-raw are both NULL. These cards are
using built-in IR decoding instead of raw, and can't easily be made to switch
protocols.

So upon reading /sys/class/rc/rc?/protocols on such a card, return 'builtin' as
the supported and enabled protocol. Return -EINVAL on any attempts to change
the protocol. And most important of all, don't crash.

Signed-off-by: Brian Rogers br...@xyzw.org
Acked-by: Jarod Wilson ja...@redhat.com
---
 drivers/media/IR/ir-sysfs.c |   17 +++--
 1 files changed, 11 insertions(+), 6 deletions(-)

diff --git a/drivers/media/IR/ir-sysfs.c b/drivers/media/IR/ir-sysfs.c
index 96dafc4..46d4246 100644
--- a/drivers/media/IR/ir-sysfs.c
+++ b/drivers/media/IR/ir-sysfs.c
@@ -67,13 +67,14 @@ static ssize_t show_protocols(struct device *d,
char *tmp = buf;
int i;
 
-   if (ir_dev-props-driver_type == RC_DRIVER_SCANCODE) {
+   if (ir_dev-props  ir_dev-props-driver_type == RC_DRIVER_SCANCODE) {
enabled = ir_dev-rc_tab.ir_type;
allowed = ir_dev-props-allowed_protos;
-   } else {
+   } else if (ir_dev-raw) {
enabled = ir_dev-raw-enabled_protocols;
allowed = ir_raw_get_allowed_protocols();
-   }
+   } else
+   return sprintf(tmp, [builtin]\n);
 
IR_dprintk(1, allowed - 0x%llx, enabled - 0x%llx\n,
   (long long)allowed,
@@ -121,10 +122,14 @@ static ssize_t store_protocols(struct device *d,
int rc, i, count = 0;
unsigned long flags;
 
-   if (ir_dev-props-driver_type == RC_DRIVER_SCANCODE)
+   if (ir_dev-props  ir_dev-props-driver_type == RC_DRIVER_SCANCODE)
type = ir_dev-rc_tab.ir_type;
-   else
+   else if (ir_dev-raw)
type = ir_dev-raw-enabled_protocols;
+   else {
+   IR_dprintk(1, Protocol switching not supported\n);
+   return -EINVAL;
+   }
 
while ((tmp = strsep((char **) data,  \n)) != NULL) {
if (!*tmp)
@@ -185,7 +190,7 @@ static ssize_t store_protocols(struct device *d,
}
}
 
-   if (ir_dev-props-driver_type == RC_DRIVER_SCANCODE) {
+   if (ir_dev-props  ir_dev-props-driver_type == RC_DRIVER_SCANCODE) {
spin_lock_irqsave(ir_dev-rc_tab.lock, flags);
ir_dev-rc_tab.ir_type = type;
spin_unlock_irqrestore(ir_dev-rc_tab.lock, flags);
-- 
1.7.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: [linux-dvb] Asus MyCinema P7131 Dual support

[Dejan Rodiger]

Hi Herman,

here is dmesg output without forcing card=78.
As I see it uses card=112, autodetected

[   16.043345] IR RC6 protocol handler initialized
[   16.173473] IR JVC protocol handler initialized
[   16.236641] IR Sony protocol handler initialized
[   16.433187] lirc_dev: IR Remote Control driver registered, major 250
[   16.572705] IR LIRC bridge handler initialized
[   16.894983] Linux video capture interface: v2.00
[   16.957585] saa7130/34: v4l2 driver version 0.2.16 loaded
[   16.958300] ACPI: PCI Interrupt Link [APC3] enabled at IRQ 18
[   16.958306]   alloc irq_desc for 18 on node 0
[   16.958309]   alloc kstat_irqs on node 0
[   16.958320] saa7134 :01:06.0: PCI INT A - Link[APC3] - GSI 18
(level, low) - IRQ 18
[   16.958327] saa7133[0]: found at :01:06.0, rev: 209, irq: 18,
latency: 32, mmio: 0xfdeff000
[   16.958334] saa7133[0]: subsystem: 1043:4876, board: ASUSTeK P7131
Hybrid [card=112,autodetected]
[   16.958378] saa7133[0]: board init: gpio is 0
[   17.010075] Registered IR keymap rc-asus-pc39
[   17.010197] input: saa7134 IR (ASUSTeK P7131 Hybri as
/devices/pci:00/:00:09.0/:01:06.0/rc/rc0/input4
[   17.010268] rc0: saa7134 IR (ASUSTeK P7131 Hybri as
/devices/pci:00/:00:09.0/:01:06.0/rc/rc0
[   17.190477] saa7133[0]: i2c eeprom 00: 43 10 76 48 54 20 1c 00 43
43 a9 1c 55 d2 b2 92
[   17.190490] saa7133[0]: i2c eeprom 10: ff ff ff 0f ff 20 ff ff ff
ff ff ff ff ff ff ff
[   17.190502] saa7133[0]: i2c eeprom 20: 01 40 01 02 03 01 01 03 08
ff 00 d5 ff ff ff ff
[   17.190513] saa7133[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff
[   17.190524] saa7133[0]: i2c eeprom 40: ff 21 00 c2 96 10 03 32 55
50 ff ff ff ff ff ff
[   17.190534] saa7133[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff
[   17.190545] saa7133[0]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff
[   17.190556] saa7133[0]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff
[   17.190566] saa7133[0]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff
[   17.190577] saa7133[0]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff
[   17.190587] saa7133[0]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff
[   17.190598] saa7133[0]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff
[   17.190609] saa7133[0]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff
[   17.190620] saa7133[0]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff
[   17.190630] saa7133[0]: i2c eeprom e0: ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff
[   17.190641] saa7133[0]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff

[   17.610120] tuner 2-004b: chip found @ 0x96 (saa7133[0])

[   17.780037] tda829x 2-004b: setting tuner address to 61
[   17.940020] tda829x 2-004b: type set to tda8290+75a

[   24.000114] saa7133[0]: registered device video0 [v4l2]
[   24.000150] saa7133[0]: registered device vbi0
[   24.000182] saa7133[0]: registered device radio0
[   24.027730] saa7134 ALSA driver for DMA sound loaded
[   24.027770] saa7133[0]/alsa: saa7133[0] at 0xfdeff000 irq 18
registered as card -2

[   25.900159] DVB: registering new adapter (saa7133[0])
[   25.900165] DVB: registering adapter 0 frontend 0 (Philips
TDA10046H DVB-T)...

[   26.710050] tda1004x: setting up plls for 48MHz sampling clock
[   27.710043] tda1004x: found firmware revision 29 -- ok


--
Dejan Rodiger
M: +385917829076
S: callto://drodiger



On Wed, Sep 22, 2010 at 01:13, hermann pitton hermann-pit...@arcor.de wrote:
 Hi Dejan,

 Am Dienstag, den 21.09.2010, 10:07 +0200 schrieb Dejan Rodiger:
 Hi,

 I am using Ubuntu linux 10.10 with the latest kernel 2.6.35-22-generic
 on x86_64. I have installed nonfree firmware which should support this
 card, but to be sure, can somebody confirm that my TV card is
 supported in Analog or DVB mode?

 sudo lspci -vnn
 01:06.0 Multimedia controller [0480]: Philips Semiconductors
 SAA7131/SAA7133/SAA7135 Video Broadcast Decoder [1131:7133] (rev d1)
         Subsystem: ASUSTeK Computer Inc. My Cinema-P7131 Hybrid
 [1043:4876]
         Flags: bus master, medium devsel, latency 32, IRQ 18
         Memory at fdeff000 (32-bit, non-prefetchable) [size=2K]
         Capabilities: [40] Power Management version 2
         Kernel driver in use: saa7134
         Kernel modules: saa7134

 It says Hybrid, but I put the following in
 the /etc/modprobe.d/saa7134.conf
 options saa7134 card=78 tuner=54


 Thanks
 --
 Dejan Rodiger
 S: callto://drodiger

 don't have time to follow this closely anymore.

 But forcing it to card=78 is plain wrong. It has an early additional LNA
 in confirmed config = 2 status.

 Your card should be auto detected and previously always was, based on
 what we have in saa7134-cards.c and further for it. (saa7134-dvb and
 related tuner/demod stuff)

        }, {
                .vendor       = PCI_VENDOR_ID_PHILIPS,
                .device       = 

Re: Fw: [linux-dvb] DSM-CC question

[Suchita Gupta]

Hi All,

Thanks to everyone for their help.
I am able to build a tree from DSMCC carousel.

I have done only file, dir and srg messages at the time being as I don't 
understand the usage of stream and stream event messages at the moment.
Can anyone please explain these to me and how can they be assembled. 

Thanks,
rs


- Original Message 
From: Peter Evertz l...@pec.homeip.net
To: Simon Liddicott si...@liddicott.com
Cc: Suchita Gupta suchitagu...@yahoo.com; linux-media@vger.kernel.org
Sent: Wed, 15 September, 2010 19:05:43
Subject: Re: Fw: [linux-dvb] DSM-CC question

Or take a look at mhp or dsmcc plugins for vdr. Both not activ 
projects, but both have a dsmcc implementation.

Are you working on a hbbtv solution ?

Simon Liddicott schrieb:
 Have you had a look at the code for redbutton?

 http://redbutton.sourceforge.net/

 Si

 On 14 September 2010 21:32, Suchita Gupta suchitagu...@yahoo.com wrote:
  
 Hi,

 First of all, I am new to this list, so I am not sire if this is right place 
for

 this question.
 If not, please forgive me and point me to right list.

 I am writing a DSMCC decoding implementation to persist it to local 
filesystem.
 I am unable to understand few thiings related to srg

 I know, it represents the top level directory. But how do I get the name of 
this

 directory?
 I can extract the names of subdirs and files using name components but where 
is
 the name of top level directory?

 Also, as far as I understand it, I can't start writing to the local 
filesystem
 until I have acquired the whole carousel.

 Can, anyone please provide me some guidance.

 Thanks in Advance,
 rs




 ___
 linux-dvb users mailing list
 For V4L/DVB development, please use instead linux-media@vger.kernel.org
 linux-...@linuxtv.org
 http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb




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




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

AvertV Hybrid Velor HX Logfile

[Lasse Seebeck]

lah...@lahala:~$ dmesg | grep em28xx
[ 1761.442492] em28xx: New device USB 2860 Device @ 480 Mbps (eb1a:2860, 
interface 0, class 0)
[ 1761.442673] em28xx #0: chip ID is em2860
[ 1761.570422] em28xx #0: i2c eeprom 00: 1a eb 67 95 1a eb 60 28 c0 00 3e 01 6a 
22 00 00
[ 1761.570454] em28xx #0: i2c eeprom 10: 00 00 04 57 4e 03 00 00 60 c0 60 c0 02 
02 02 02
[ 1761.570483] em28xx #0: i2c eeprom 20: 16 00 00 02 f0 10 02 00 4a 00 00 00 5b 
00 00 00
[ 1761.570512] em28xx #0: i2c eeprom 30: 00 00 20 40 20 80 02 20 10 01 02 01 00 
00 00 00
[ 1761.570541] em28xx #0: i2c eeprom 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00
[ 1761.570569] em28xx #0: i2c eeprom 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00
[ 1761.570598] em28xx #0: i2c eeprom 60: 00 00 00 00 00 00 00 00 00 00 22 03 55 
00 53 00
[ 1761.570626] em28xx #0: i2c eeprom 70: 42 00 20 00 32 00 38 00 36 00 30 00 20 
00 44 00
[ 1761.570655] em28xx #0: i2c eeprom 80: 65 00 76 00 69 00 63 00 65 00 00 00 00 
00 00 00
[ 1761.570683] em28xx #0: i2c eeprom 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00
[ 1761.570712] em28xx #0: i2c eeprom a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00
[ 1761.570740] em28xx #0: i2c eeprom b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00
[ 1761.570769] em28xx #0: i2c eeprom c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00
[ 1761.570797] em28xx #0: i2c eeprom d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00
[ 1761.570825] em28xx #0: i2c eeprom e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00
[ 1761.570853] em28xx #0: i2c eeprom f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00
[ 1761.570885] em28xx #0: EEPROM ID= 0x9567eb1a, EEPROM hash = 0x8f597549
[ 1761.570890] em28xx #0: EEPROM info:
[ 1761.570894] em28xx #0:   No audio on board.
[ 1761.570898] em28xx #0:   500mA max power
[ 1761.570905] em28xx #0:   Table at 0x04, strings=0x226a, 0x, 0x
[ 1761.584548] em28xx #0: Identified as Unknown EM2750/28xx video grabber 
(card=1)
[ 1761.599536] em28xx #0: found i2c device @ 0x4a [saa7113h]
[ 1761.616021] em28xx #0: found i2c device @ 0xa0 [eeprom]
[ 1761.623280] em28xx #0: found i2c device @ 0xc2 [tuner (analog)]
[ 1761.635532] em28xx #0: Your board has no unique USB ID and thus need a hint 
to be detected.
[ 1761.635541] em28xx #0: You may try to use card=n insmod option to 
workaround that.
[ 1761.635546] em28xx #0: Please send an email with this log to:
[ 1761.635551] em28xx #0:   V4L Mailing List linux-media@vger.kernel.org
[ 1761.635557] em28xx #0: Board eeprom hash is 0x8f597549
[ 1761.635562] em28xx #0: Board i2c devicelist hash is 0x6bc40080
[ 1761.635567] em28xx #0: Here is a list of valid choices for the card=n 
insmod option:
[ 1761.635574] em28xx #0: card=0 - Unknown EM2800 video grabber
[ 1761.635580] em28xx #0: card=1 - Unknown EM2750/28xx video grabber
[ 1761.635586] em28xx #0: card=2 - Terratec Cinergy 250 USB
[ 1761.635591] em28xx #0: card=3 - Pinnacle PCTV USB 2
[ 1761.635597] em28xx #0: card=4 - Hauppauge WinTV USB 2
[ 1761.635602] em28xx #0: card=5 - MSI VOX USB 2.0
[ 1761.635607] em28xx #0: card=6 - Terratec Cinergy 200 USB
[ 1761.635613] em28xx #0: card=7 - Leadtek Winfast USB II
[ 1761.635619] em28xx #0: card=8 - Kworld USB2800
[ 1761.635624] em28xx #0: card=9 - Pinnacle Dazzle DVC 90/100/101/107 / 
Kaiser Baas Video to DVD maker / Kworld DVD Maker 2
[ 1761.635631] em28xx #0: card=10 - Hauppauge WinTV HVR 900
[ 1761.635637] em28xx #0: card=11 - Terratec Hybrid XS
[ 1761.635642] em28xx #0: card=12 - Kworld PVR TV 2800 RF
[ 1761.635648] em28xx #0: card=13 - Terratec Prodigy XS
[ 1761.635654] em28xx #0: card=14 - SIIG AVTuner-PVR / Pixelview Prolink 
PlayTV USB 2.0
[ 1761.635660] em28xx #0: card=15 - V-Gear PocketTV
[ 1761.635665] em28xx #0: card=16 - Hauppauge WinTV HVR 950
[ 1761.635670] em28xx #0: card=17 - Pinnacle PCTV HD Pro Stick
[ 1761.635676] em28xx #0: card=18 - Hauppauge WinTV HVR 900 (R2)
[ 1761.635682] em28xx #0: card=19 - EM2860/SAA711X Reference Design
[ 1761.635688] em28xx #0: card=20 - AMD ATI TV Wonder HD 600
[ 1761.635693] em28xx #0: card=21 - eMPIA Technology, Inc. GrabBeeX+ Video 
Encoder
[ 1761.635700] em28xx #0: card=22 - EM2710/EM2750/EM2751 webcam grabber
[ 1761.635705] em28xx #0: card=23 - Huaqi DLCW-130
[ 1761.635711] em28xx #0: card=24 - D-Link DUB-T210 TV Tuner
[ 1761.635717] em28xx #0: card=25 - Gadmei UTV310
[ 1761.635722] em28xx #0: card=26 - Hercules Smart TV USB 2.0
[ 1761.635728] em28xx #0: card=27 - Pinnacle PCTV USB 2 (Philips FM1216ME)
[ 1761.635734] em28xx #0: card=28 - Leadtek Winfast USB II Deluxe
[ 1761.635740] em28xx #0: card=29 - NULL
[ 1761.635746] em28xx #0: card=30 - Videology 20K14XUSB USB2.0
[ 1761.635752] em28xx #0: card=31 - Usbgear VD204v9
[ 1761.635757] em28xx #0: card=32 - Supercomp USB 2.0 TV
[ 1761.635763] em28xx #0: card=33 - NULL
[ 1761.635768] em28xx #0: 

Re: [PATCH v2 1/6] SoC Camera: add driver for OMAP1 camera interface

[Janusz Krzysztofik]

Wednesday 22 September 2010 01:23:22 Guennadi Liakhovetski napisał(a):
 On Sat, 11 Sep 2010, Janusz Krzysztofik wrote:
  This is a V4L2 driver for TI OMAP1 SoC camera interface.
 
  Both videobuf-dma versions are supported, contig and sg, selectable with
  a module option. The former uses less processing power, but often fails
  to allocate contignuous buffer memory. The latter is free of this
  problem, but generates tens of DMA interrupts per frame. If contig memory
  allocation ever fails, the driver falls back to sg automatically on next
  open, but still can be switched back to contig manually. Both paths work
  stable for me, even under heavy load, on my OMAP1510 based Amstrad Delta
  videophone, that is the oldest, least powerfull OMAP1 implementation.
 
  The interface generally works in pass-through mode. Since input data byte
  endianess can be swapped, it provides up to two v4l2 pixel formats per
  each of several soc_mbus formats that have their swapped endian
  counterparts.
 
  Boards using this driver can provide it with the followning information:
  - if and what freqency clock is expected by an on-board camera sensor,
  - what is the maximum pixel clock that should be accepted from the
  sensor, - what is the polarity of the sensor provided pixel clock,
  - if the interface GPIO line is connected to a sensor reset/powerdown
  input and what is the input polarity.
 
  Created and tested against linux-2.6.36-rc3 on Amstrad Delta.
 
  Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
  ---
 
  Friday 30 July 2010 13:07:42 Guennadi Liakhovetski wrote:
   So, I think, a very welcome improvement to the driver would be a
   cleaner separation between the two cases. Don't try that much to reuse
   the code as much as possible. Would be much better to have clean
   separation between the two implementations - whether dynamically
   switchable at runtime or at config time - would be best to separate the
   two
   implementations to the point, where each of them becomes understandable
   and maintainable.
 
  Guennadi,
  I've tried to rearrange them spearated, as you requested, but finally
  decided to keep them together, as before, only better documented and
  cleaned up as much as possible. I'm rather satisfied with the result, but
  if you think it is still not enough understandable and maintainable, I'll
  take one more iteration and split both paths.

 Well, I think, I'll move a bit towards the if it breaks - someone gets to
 fix it, or it gets dropped policy, i.e., I'll give you more freedom
 (don't know what's wrong with me today;))

Hi Guennadi,
Thanks!

...
  +#define DMA_FRAME_SHIFT(x) (x ? DMA_FRAME_SHIFT_SG : \
  +   DMA_FRAME_SHIFT_CONTIG)

 Don't you want to compare (x) against CONTIG and you want to put x in
 parenthesis in the DMA_FRAME_SHIFT macro. 

Sure.

 Besides, CONTIG and SG are not 
 good enough names to be defined in a header under include/... Looks like
 you don't need them at all in the header? You only use them in this file,
 so, just move them inside.

Please see my very last comment below.

...
  +static void videobuf_done(struct omap1_cam_dev *pcdev,
  +   enum videobuf_state result)
  +{
  +   struct omap1_cam_buf *buf = pcdev-active;
  +   struct videobuf_buffer *vb;
  +   struct device *dev = pcdev-icd-dev.parent;
  +
  +   if (WARN_ON(!buf)) {
  +   suspend_capture(pcdev);
  +   disable_capture(pcdev);
  +   return;
  +   }
  +
  +   if (result == VIDEOBUF_ERROR)
  +   suspend_capture(pcdev);
  +
  +   vb = buf-vb;
  +   if (waitqueue_active(vb-done)) {
  +   if (!pcdev-ready  result != VIDEOBUF_ERROR)
  +   /*
  +* No next buffer has been entered into the DMA
  +* programming register set on time, so best we can do
  +* is stopping the capture before last DMA block,
  +* whether our CONTIG mode whole buffer or its last
  +* sgbuf in SG mode, gets overwritten by next frame.
  +*/

 Hm, why do you think it's a good idea? This specific buffer completed
 successfully, but you want to fail it just because the next buffer is
 missing? Any specific reason for this? 

Maybe my comment is not clear enough, but the below suspend_capture() doesn't 
indicate any failure on a frame just captured. It only prevents the frame 
from being overwritten by the already autoreinitialized DMA engine, pointing 
back to the same buffer once again.

 Besides, you seem to also be 
 considering the possibility of your -ready == NULL, but the queue
 non-empty, in which case you just take the next buffer from the queue and
 continue with it. Why error out in this case? 

pcdev-ready == NULL means no buffer was available when it was time to put it 
into the DMA programming register set. As a result, a next DMA transfer has 
just been autoreinitialized with the same 

Re: [PATCH v2 2/6] OMAP1: Add support for SoC camera interface

[Janusz Krzysztofik]

Wednesday 22 September 2010 08:53:19 Guennadi Liakhovetski napisał(a):
 That's up to the platform maintainer to review / apply this one, but if
 you like, a couple of nit-picks from me:

Guennadi,
Thanks for also looking at this!

 On Sat, 11 Sep 2010, Janusz Krzysztofik wrote:
  This patch adds support for SoC camera interface to OMAP1 devices.
 
  Created and tested against linux-2.6.36-rc3 on Amstrad Delta.
 
  For successfull compilation, requires a header file provided by PATCH 1/6
  from this series, SoC Camera: add driver for OMAP1 camera interface.
 
  Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
  ---
  v1-v2 changes:
  - no functional changes,
  - refreshed against linux-2.6.36-rc3
 
 
   arch/arm/mach-omap1/devices.c |   43
  ++
   arch/arm/mach-omap1/include/mach/camera.h |8 +
   2 files changed, 51 insertions(+)
 
 
  diff -upr linux-2.6.36-rc3.orig/arch/arm/mach-omap1/devices.c
  linux-2.6.36-rc3/arch/arm/mach-omap1/devices.c
  --- linux-2.6.36-rc3.orig/arch/arm/mach-omap1/devices.c 2010-09-03
  22:29:00.0 +0200
  +++ linux-2.6.36-rc3/arch/arm/mach-omap1/devices.c  2010-09-09
  18:42:30.0 +0200
  @@ -15,6 +15,7 @@
   #include linux/platform_device.h
   #include linux/io.h
   #include linux/spi/spi.h
  +#include linux/dma-mapping.h
 
   #include mach/hardware.h
   #include asm/mach/map.h
  @@ -25,6 +26,7 @@
   #include mach/gpio.h
   #include plat/mmc.h
   #include plat/omap7xx.h
  +#include mach/camera.h

 You might want to try to group headers according to their location, i.e.,
 put mach/... higher - together with mach/gpio.h, also it helps to have
 headers alphabetically ordered.

Yes, I will, thank you.

  
  /*---
 --*/
 
  @@ -191,6 +193,47 @@ static inline void omap_init_spi100k(voi
   }
   #endif
 
  +
  +#define OMAP1_CAMERA_BASE  0xfffb6800
  +
  +static struct resource omap1_camera_resources[] = {
  +   [0] = {
  +   .start  = OMAP1_CAMERA_BASE,
  +   .end= OMAP1_CAMERA_BASE + OMAP1_CAMERA_IOSIZE - 1,
  +   .flags  = IORESOURCE_MEM,
  +   },
  +   [1] = {
  +   .start  = INT_CAMERA,
  +   .flags  = IORESOURCE_IRQ,
  +   },
  +};
  +
  +static u64 omap1_camera_dma_mask = DMA_BIT_MASK(32);
  +
  +static struct platform_device omap1_camera_device = {
  +   .name   = omap1-camera,
  +   .id = 0, /* This is used to put cameras on this interface */
  +   .dev= {
  +   .dma_mask   = omap1_camera_dma_mask,
  +   .coherent_dma_mask  = DMA_BIT_MASK(32),
  +   },
  +   .num_resources  = ARRAY_SIZE(omap1_camera_resources),
  +   .resource   = omap1_camera_resources,
  +};
  +
  +void __init omap1_set_camera_info(struct omap1_cam_platform_data *info)
  +{
  +   struct platform_device *dev = omap1_camera_device;
  +   int ret;
  +
  +   dev-dev.platform_data = info;
  +
  +   ret = platform_device_register(dev);
  +   if (ret)
  +   dev_err(dev-dev, unable to register device: %d\n, ret);
  +}
  +
  +
  
  /*---
 --*/
 
   static inline void omap_init_sti(void) {}
  diff -upr linux-2.6.36-rc3.orig/arch/arm/mach-omap1/include/mach/camera.h
  linux-2.6.36-rc3/arch/arm/mach-omap1/include/mach/camera.h
  ---
  linux-2.6.36-rc3.orig/arch/arm/mach-omap1/include/mach/camera.h 
  2010-09-0
 3 22:34:03.0 +0200
  +++ linux-2.6.36-rc3/arch/arm/mach-omap1/include/mach/camera.h  
  2010-09-09
  18:42:30.0 +0200
  @@ -0,0 +1,8 @@
  +#ifndef __ASM_ARCH_CAMERA_H_
  +#define __ASM_ARCH_CAMERA_H_
  +
  +#include media/omap1_camera.h
  +
  +extern void omap1_set_camera_info(struct omap1_cam_platform_data *);

 function declarations don't need an extern - something I've also been
 doing needlessly for a few years...

Good to know. I'll drop it.

Tony,
Any comments from you before I submit a hopefully final version?

Thanks,
Janusz

  +
  +#endif /* __ASM_ARCH_CAMERA_H_ */

 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: [PATCH v2 3/6] SoC Camera: add driver for OV6650 sensor

[Janusz Krzysztofik]

Wednesday 22 September 2010 11:12:46 Guennadi Liakhovetski napisał(a):
 Ok, just a couple more comments, all looking quite good so far, if we get
 a new version soon enough, we still might manage it for 2.6.37

 On Sat, 11 Sep 2010, Janusz Krzysztofik wrote:

 [snip]

  +/* write a register */
  +static int ov6650_reg_write(struct i2c_client *client, u8 reg, u8 val)
  +{
  +   int ret;
  +   unsigned char data[2] = { reg, val };
  +   struct i2c_msg msg = {
  +   .addr   = client-addr,
  +   .flags  = 0,
  +   .len= 2,
  +   .buf= data,
  +   };
  +
  +   ret = i2c_transfer(client-adapter, msg, 1);
  +   msleep_interruptible(1);

 Why do you want _interruptible here? Firstly it's just 1ms, secondly -
 why?...

My bad. I didn't verified what a real difference between msleep() and 
msleep_interruptible() is, only found that msleep_interruptible(1) makes 
checkpatch.pl more happy than msleep(1), sorry.

What I can be sure is that a short delay is required here, otherwise the 
driver doesn't work correctly. To prevent the checkpatch.pl from complying 
against msleep(1), I think I could just replace it with msleep(20). What do 
you think?

  +
  +   if (ret  0) {
  +   dev_err(client-dev, Failed writing register 0x%02x!\n, reg);
  +   return ret;
  +   }
  +   return 0;
  +}

 ...

  +/* set the format we will capture in */
  +static int ov6650_s_fmt(struct v4l2_subdev *sd,
  +   struct v4l2_mbus_framefmt *mf)
  +{
  +   struct i2c_client *client = sd-priv;
  +   struct soc_camera_device *icd   = client-dev.platform_data;
  +   struct soc_camera_sense *sense = icd-sense;
  +   struct ov6650 *priv = to_ov6650(client);
  +   enum v4l2_mbus_pixelcode code = mf-code;
  +   unsigned long pclk;
  +   u8 coma_set = 0, coma_mask = 0, coml_set = 0, coml_mask = 0;
  +   u8 clkrc, clkrc_div;
  +   int ret;
  +
  +   /* select color matrix configuration for given color encoding */
  +   switch (code) {
  +   case V4L2_MBUS_FMT_GREY8_1X8:
  +   dev_dbg(client-dev, pixel format GREY8_1X8\n);
  +   coma_set |= COMA_BW;
  +   coma_mask |= COMA_RGB | COMA_WORD_SWAP | COMA_BYTE_SWAP;
  +   break;
  +   case V4L2_MBUS_FMT_YUYV8_2X8:
  +   dev_dbg(client-dev, pixel format YUYV8_2X8_LE\n);
  +   coma_set |= COMA_WORD_SWAP;
  +   coma_mask |= COMA_RGB | COMA_BW | COMA_BYTE_SWAP;
  +   break;
  +   case V4L2_MBUS_FMT_YVYU8_2X8:
  +   dev_dbg(client-dev, pixel format YVYU8_2X8_LE (untested)\n);
  +   coma_mask |= COMA_RGB | COMA_BW | COMA_WORD_SWAP |
  +   COMA_BYTE_SWAP;
  +   break;
  +   case V4L2_MBUS_FMT_UYVY8_2X8:
  +   dev_dbg(client-dev, pixel format YUYV8_2X8_BE\n);
  +   if (mf-width == W_CIF) {
  +   coma_set |= COMA_BYTE_SWAP | COMA_WORD_SWAP;
  +   coma_mask |= COMA_RGB | COMA_BW;
  +   } else {
  +   coma_set |= COMA_BYTE_SWAP;
  +   coma_mask |= COMA_RGB | COMA_BW | COMA_WORD_SWAP;
  +   }
  +   break;
  +   case V4L2_MBUS_FMT_VYUY8_2X8:
  +   dev_dbg(client-dev, pixel format YVYU8_2X8_BE (untested)\n);
  +   if (mf-width == W_CIF) {
  +   coma_set |= COMA_BYTE_SWAP;
  +   coma_mask |= COMA_RGB | COMA_BW | COMA_WORD_SWAP;
  +   } else {
  +   coma_set |= COMA_BYTE_SWAP | COMA_WORD_SWAP;
  +   coma_mask |= COMA_RGB | COMA_BW;
  +   }
  +   break;
  +   case V4L2_MBUS_FMT_SBGGR8_1X8:
  +   dev_dbg(client-dev, pixel format SBGGR8_1X8 (untested)\n);
  +   coma_set |= COMA_RAW_RGB | COMA_RGB;
  +   coma_mask |= COMA_BW | COMA_BYTE_SWAP | COMA_WORD_SWAP;
  +   break;
  +   default:
  +   dev_err(client-dev, Pixel format not handled: 0x%x\n, code);
  +   return -EINVAL;
  +   }
  +   priv-code = code;
  +
  +   if ((code == V4L2_MBUS_FMT_GREY8_1X8) ||
  +   (code == V4L2_MBUS_FMT_SBGGR8_1X8)) {

 Superfluous parenthesis

Will be dropped.

  +   coml_mask |= COML_ONE_CHANNEL;
  +   priv-pclk_max = 400;
  +   } else {
  +   coml_set |= COML_ONE_CHANNEL;
  +   priv-pclk_max = 800;
  +   }

 coml_mask and coml_set are only set here and only used once below, so,
 dropping initialisation to 0 in variable definitions and just doing

 + if (code == V4L2_MBUS_FMT_GREY8_1X8 ||
 + code == V4L2_MBUS_FMT_SBGGR8_1X8) {
 + coml_mask = COML_ONE_CHANNEL;
 + coml_set = 0;
 + priv-pclk_max = 400;
 + } else {
 + coml_mask = 0;
 + coml_set = COML_ONE_CHANNEL;
 + priv-pclk_max = 800;
 + }

 would work too.

OK, I'll use your prefered pattern.

  +
  +   if (code == V4L2_MBUS_FMT_SBGGR8_1X8)
  +   priv-colorspace = V4L2_COLORSPACE_SRGB;
  +   

Re: [GIT PATCHES FOR 2.6.37] davinci videobuf fixes

[Mauro Carvalho Chehab]

Em 07-09-2010 06:23, Hans Verkuil escreveu:
 Hi Mauro,
 
 The following changes since commit 50b9d21ae2ac1b85be46f1ee5aa1b5e588622361:
   Jarod Wilson (1):
 V4L/DVB: mceusb: add two new ASUS device IDs
 
 are available in the git repository at:
 
   ssh://linuxtv.org/git/hverkuil/v4l-dvb.git for-2.6.37
 
 Hans Verkuil (1):
   videobuf-dma-sg: set correct size in last sg element

Ok.
 
 Mats Randgaard (5):
   videobuf-core.c: Replaced BUG_ON with WARN_ON

Why? Please provide a description to allow us to understand why this change 
makes sense.
Is there any condition where this would be acceptable?

   vpif_cap/disp: Removed section mismatch warning
   vpif_cap/disp: Replaced kmalloc with kzalloc
   vpif_cap: don't ignore return code of videobuf_poll_stream()

The better would be to provide some description for all patches, but, in this
specific case, they're trivial.

Applied, thanks.

   vpif_cap/disp: Fixed strlcpy NULL pointer bug

Hmm... this one doesn't make sense to me. Instead, you should be sure that
config-card_name (or cap-card) is always filled.

Ok, I've applied 4 of the 6 patches (I've included the patch of the last email
on the above).

Please, provide a better solution for the strlcpy NULL pointer bug, properly
filling the config struct in all cases.

Cheers,
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: [GIT PATCHES FOR 2.6.37] davinci videobuf fixes

[Hans Verkuil]

On Wednesday, September 22, 2010 20:39:03 Mauro Carvalho Chehab wrote:
 Em 07-09-2010 06:23, Hans Verkuil escreveu:
  Hi Mauro,
  
  The following changes since commit 50b9d21ae2ac1b85be46f1ee5aa1b5e588622361:
Jarod Wilson (1):
  V4L/DVB: mceusb: add two new ASUS device IDs
  
  are available in the git repository at:
  
ssh://linuxtv.org/git/hverkuil/v4l-dvb.git for-2.6.37
  
  Hans Verkuil (1):
videobuf-dma-sg: set correct size in last sg element
 
 Ok.
  
  Mats Randgaard (5):
videobuf-core.c: Replaced BUG_ON with WARN_ON
 
 Why? Please provide a description to allow us to understand why this change 
 makes sense.
 Is there any condition where this would be acceptable?

Does it indicate a driver bug? Yes. But it's not a harmful driver bug, i.e. it
will not cause a crash later. So BUG_ON is way overkill. WARN_ON is sufficient.

A bug in the davinci driver actually triggered this BUG_ON for us. Since it's
a BUG_ON you are forced to reboot for no good reason. Note that we are working
on fixing the davinci bug as well.

AFAIK BUG_ON is meant for fatal errors, i.e. continuing will cause crashes 
later.
That's not at all the case here.

Regards,

Hans

vpif_cap/disp: Removed section mismatch warning
vpif_cap/disp: Replaced kmalloc with kzalloc
  vpif_cap: don't ignore return code of videobuf_poll_stream()
 
 The better would be to provide some description for all patches, but, in this
 specific case, they're trivial.
 
 Applied, thanks.
 
vpif_cap/disp: Fixed strlcpy NULL pointer bug
 
 Hmm... this one doesn't make sense to me. Instead, you should be sure that
 config-card_name (or cap-card) is always filled.
 
 Ok, I've applied 4 of the 6 patches (I've included the patch of the last email
 on the above).
 
 Please, provide a better solution for the strlcpy NULL pointer bug, properly
 filling the config struct in all cases.
 
 Cheers,
 Mauro
 

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of Cisco
--
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 FOR 2.6.37] new AF9015 devices

[Mauro Carvalho Chehab]

Em 09-09-2010 18:12, Antti Palosaari escreveu:
 Moikka Mauro!
 This patch series adds support for TerraTec Cinergy T Stick Dual RC and 
 TerraTec Cinergy T Stick RC. Also MxL5007T devices with ref. design IDs 
 should be working. Cinergy T Stick remote is most likely not working since it 
 seems to use different remote as Cinergy T Dual... Stefan could you test and 
 ensure T Stick is working?
 
 and thanks to TerraTec!
 
 t. Antti
 
 
 The following changes since commit c9889354c6d36d6278ed851c74ace02d72efdd59:
 
   V4L/DVB: rc-core: increase repeat time (2010-09-08 13:04:40 -0300)
 
 are available in the git repository at:
   git://linuxtv.org/anttip/media_tree.git af9015
 
 Antti Palosaari (6):
   af9015: simple comment update

Hmm... dvb-usb.h defines it as:
struct dvb_usb_device_description devices[12];

It took me some time to find the current limit ;)

IMO, instead of just comment it as: 
.num_device_descs = 9, /* check max from dvb-usb.h */

The better would be to add a definition at dvb-usb.h header for the max limit, 
and properly pointing it
on your drivers, like:

on dvb-usb.h:

#define MAX_DEVICES_PER_DEV_PROPS   12
...
struct dvb_usb_device_description devices[MAX_DEVICES_PER_DEV_PROPS];

on af9015 (and others):
.num_device_descs = 9, /* max is MAX_DEVICES_PER_DEV_PROPS as defined 
on dvb-usb.h */

I'll apply this patch to avoid breaking your series, but please provide me a 
fix.

   af9015: fix bug introduced by commit 
 490ade7e3f4474f626a8f5d778ead4e599b94fbcas
   af9013: add support for MaxLinear MxL5007T tuner
   af9015: add support for TerraTec Cinergy T Stick Dual RC
   af9015: add remote support for TerraTec Cinergy T Stick Dual RC
   af9015: map TerraTec Cinergy T Stick Dual RC remote to device ID
 
  drivers/media/dvb/dvb-usb/Kconfig |1 +
  drivers/media/dvb/dvb-usb/af9015.c|   50 +--
  drivers/media/dvb/dvb-usb/af9015.h|   63 
 +
  drivers/media/dvb/dvb-usb/dvb-usb-ids.h   |1 +
  drivers/media/dvb/frontends/af9013.c  |1 +
  drivers/media/dvb/frontends/af9013.h  |1 +
  drivers/media/dvb/frontends/af9013_priv.h |5 +-
  7 files changed, 99 insertions(+), 23 deletions(-)
 
 
Cheers,
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

[cron job] v4l-dvb daily build 2.6.26 and up: 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:Wed Sep 22 19:00:11 CEST 2010
path:http://www.linuxtv.org/hg/v4l-dvb
changeset:   15164:1da5fed5c8b2
git master:   3e6dce76d99b328716b43929b9195adfee1de00c
git media-master: 991403c594f666a2ed46297c592c60c3b9f4e1e2
gcc version:  i686-linux-gcc (GCC) 4.4.3
host hardware:x86_64
host os:  2.6.32.5

linux-2.6.32.6-armv5: WARNINGS
linux-2.6.33-armv5: OK
linux-2.6.34-armv5: WARNINGS
linux-2.6.35.3-armv5: WARNINGS
linux-2.6.36-rc2-armv5: ERRORS
linux-2.6.32.6-armv5-davinci: WARNINGS
linux-2.6.33-armv5-davinci: WARNINGS
linux-2.6.34-armv5-davinci: WARNINGS
linux-2.6.35.3-armv5-davinci: WARNINGS
linux-2.6.36-rc2-armv5-davinci: ERRORS
linux-2.6.32.6-armv5-ixp: WARNINGS
linux-2.6.33-armv5-ixp: WARNINGS
linux-2.6.34-armv5-ixp: WARNINGS
linux-2.6.35.3-armv5-ixp: WARNINGS
linux-2.6.36-rc2-armv5-ixp: ERRORS
linux-2.6.32.6-armv5-omap2: WARNINGS
linux-2.6.33-armv5-omap2: WARNINGS
linux-2.6.34-armv5-omap2: WARNINGS
linux-2.6.35.3-armv5-omap2: WARNINGS
linux-2.6.36-rc2-armv5-omap2: ERRORS
linux-2.6.26.8-i686: WARNINGS
linux-2.6.27.44-i686: WARNINGS
linux-2.6.28.10-i686: WARNINGS
linux-2.6.29.1-i686: WARNINGS
linux-2.6.30.10-i686: WARNINGS
linux-2.6.31.12-i686: WARNINGS
linux-2.6.32.6-i686: WARNINGS
linux-2.6.33-i686: WARNINGS
linux-2.6.34-i686: WARNINGS
linux-2.6.35.3-i686: WARNINGS
linux-2.6.36-rc2-i686: ERRORS
linux-2.6.32.6-m32r: WARNINGS
linux-2.6.33-m32r: OK
linux-2.6.34-m32r: WARNINGS
linux-2.6.35.3-m32r: WARNINGS
linux-2.6.36-rc2-m32r: ERRORS
linux-2.6.32.6-mips: WARNINGS
linux-2.6.33-mips: WARNINGS
linux-2.6.34-mips: WARNINGS
linux-2.6.35.3-mips: WARNINGS
linux-2.6.36-rc2-mips: ERRORS
linux-2.6.32.6-powerpc64: WARNINGS
linux-2.6.33-powerpc64: WARNINGS
linux-2.6.34-powerpc64: WARNINGS
linux-2.6.35.3-powerpc64: WARNINGS
linux-2.6.36-rc2-powerpc64: ERRORS
linux-2.6.26.8-x86_64: WARNINGS
linux-2.6.27.44-x86_64: WARNINGS
linux-2.6.28.10-x86_64: WARNINGS
linux-2.6.29.1-x86_64: WARNINGS
linux-2.6.30.10-x86_64: WARNINGS
linux-2.6.31.12-x86_64: WARNINGS
linux-2.6.32.6-x86_64: WARNINGS
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-rc2-x86_64: ERRORS
linux-git-Module.symvers: ERRORS
linux-git-armv5: ERRORS
linux-git-armv5-davinci: ERRORS
linux-git-armv5-ixp: ERRORS
linux-git-armv5-omap2: ERRORS
linux-git-i686: ERRORS
linux-git-m32r: ERRORS
linux-git-mips: ERRORS
linux-git-powerpc64: ERRORS
linux-git-x86_64: ERRORS
spec: ERRORS
spec-git: ERRORS
sparse: ERRORS

Detailed results are available here:

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

Full logs are available here:

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

The V4L-DVB specification failed to build, but the last compiled spec 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

Re: [GIT PATCHES FOR 2.6.37] V4L documentation fixes

[Mauro Carvalho Chehab]

Em 15-09-2010 04:23, Hans Verkuil escreveu:
 The following changes since commit 57fef3eb74a04716a8dd18af0ac510ec4f71bc05:
   Richard Zidlicky (1):
 V4L/DVB: dvb: fix smscore_getbuffer() logic
 
 are available in the git repository at:
 
   ssh://linuxtv.org/git/hverkuil/v4l-dvb.git misc2
 
 Hans Verkuil (6):
   V4L Doc: removed duplicate link

This doesn't seem right. the entry for V4L2-PIX-FMT-BGR666 seems to be 
duplicated.
We should remove the duplication, instead of just dropping the ID.

   V4L Doc: fix DocBook syntax errors.
   V4L Doc: document V4L2_CAP_RDS_OUTPUT capability.
   V4L Doc: correct the documentation for VIDIOC_QUERYMENU.

Applied, thanks.

   V4L Doc: rewrite the Device Naming section

The new text is incomplete, as it assumes only the old non-dynamic device node
creation. Also, some distros actually create /dev/v4l, as recommended. IMHO, we
need to improve this section, proposing a better way to name devices. This may
be an interesting theme for this year's LPC.


   V4L Doc: clarify the V4L spec.

This is a mix of several changes on the same patch. I want to do comments about 
it,
but no time right now to write an email about that. It is a way harder to 
comment
Docbook changes than patches, as the diff output is not user-friendly.
I'll postpone this patch for a better analysis.

I don't want to postpone the DocBook correction patches due to that, so I'm 
applying
the patches I'm ok.

Cheers,
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: [GIT PATCHES FOR 2.6.37] davinci videobuf fixes

[Mauro Carvalho Chehab]

Em 22-09-2010 15:49, Hans Verkuil escreveu:
 On Wednesday, September 22, 2010 20:39:03 Mauro Carvalho Chehab wrote:
 Em 07-09-2010 06:23, Hans Verkuil escreveu:
 Hi Mauro,

 The following changes since commit 50b9d21ae2ac1b85be46f1ee5aa1b5e588622361:
   Jarod Wilson (1):
 V4L/DVB: mceusb: add two new ASUS device IDs

 are available in the git repository at:

   ssh://linuxtv.org/git/hverkuil/v4l-dvb.git for-2.6.37

 Hans Verkuil (1):
   videobuf-dma-sg: set correct size in last sg element

 Ok.

 Mats Randgaard (5):
   videobuf-core.c: Replaced BUG_ON with WARN_ON

 Why? Please provide a description to allow us to understand why this change 
 makes sense.
 Is there any condition where this would be acceptable?
 
 Does it indicate a driver bug? Yes. But it's not a harmful driver bug, i.e. it
 will not cause a crash later. So BUG_ON is way overkill. WARN_ON is 
 sufficient.
 
 A bug in the davinci driver actually triggered this BUG_ON for us. Since it's
 a BUG_ON you are forced to reboot for no good reason. Note that we are working
 on fixing the davinci bug as well.
 
 AFAIK BUG_ON is meant for fatal errors, i.e. continuing will cause crashes 
 later.
 That's not at all the case here.

Ok, please include this description on the patch. I'm fine with it. I was 
afraid that
this could be the default behavior for the davinci driver. The better is to put
this patch in the same series where you'll be also correcting the davinci bug.

 
 Regards,
 
   Hans
 
   vpif_cap/disp: Removed section mismatch warning
   vpif_cap/disp: Replaced kmalloc with kzalloc
 vpif_cap: don't ignore return code of videobuf_poll_stream()

 The better would be to provide some description for all patches, but, in this
 specific case, they're trivial.

 Applied, thanks.

   vpif_cap/disp: Fixed strlcpy NULL pointer bug

 Hmm... this one doesn't make sense to me. Instead, you should be sure that
 config-card_name (or cap-card) is always filled.

 Ok, I've applied 4 of the 6 patches (I've included the patch of the last 
 email
 on the above).

 Please, provide a better solution for the strlcpy NULL pointer bug, properly
 filling the config struct in all cases.

 Cheers,
 Mauro

 

Cheers,
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: [GIT PATCHES FOR 2.6.37] V4L documentation fixes

[Hans Verkuil]

On Wednesday, September 22, 2010 21:42:03 Mauro Carvalho Chehab wrote:
 Em 15-09-2010 04:23, Hans Verkuil escreveu:
  The following changes since commit 57fef3eb74a04716a8dd18af0ac510ec4f71bc05:
Richard Zidlicky (1):
  V4L/DVB: dvb: fix smscore_getbuffer() logic
  
  are available in the git repository at:
  
ssh://linuxtv.org/git/hverkuil/v4l-dvb.git misc2
  
  Hans Verkuil (6):
V4L Doc: removed duplicate link
 
 This doesn't seem right. the entry for V4L2-PIX-FMT-BGR666 seems to be 
 duplicated.
 We should remove the duplication, instead of just dropping the ID.

No, this patch is correct. This section really duplicates the formats due to
confusion about the byte order in memory. But only one of these format tables
should have a valid ID.

See table 2.4 and 2.5 here:

http://www.xs4all.nl/~hverkuil/spec/media.html#packed-rgb

As you can see here there is no BGR666 entry in either table since the docbook
generation has been failing on this docbook error for some time now.

 
V4L Doc: fix DocBook syntax errors.
V4L Doc: document V4L2_CAP_RDS_OUTPUT capability.
V4L Doc: correct the documentation for VIDIOC_QUERYMENU.
 
 Applied, thanks.
 
V4L Doc: rewrite the Device Naming section
 
 The new text is incomplete, as it assumes only the old non-dynamic device node
 creation. Also, some distros actually create /dev/v4l, as recommended. IMHO, 
 we
 need to improve this section, proposing a better way to name devices. This may
 be an interesting theme for this year's LPC.

No, the major is still 81 and the minors are still between 0 and 255. But the 
minor
ranges are gone (unless you turn that on explicitly). So this text is really 
correct
and way more understandable than the old text.

 
V4L Doc: clarify the V4L spec.
 
 This is a mix of several changes on the same patch. I want to do comments 
 about it,
 but no time right now to write an email about that. It is a way harder to 
 comment
 Docbook changes than patches, as the diff output is not user-friendly.
 I'll postpone this patch for a better analysis.

No problem.

Regards,

Hans
 
 I don't want to postpone the DocBook correction patches due to that, so I'm 
 applying
 the patches I'm ok.
 
 Cheers,
 Mauro
 

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of Cisco
--
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 PATCHES FOR 2.6.37] V4L documentation fixes

[Hans Verkuil]

On Wednesday, September 22, 2010 22:06:11 Hans Verkuil wrote:
 On Wednesday, September 22, 2010 21:42:03 Mauro Carvalho Chehab wrote:
  Em 15-09-2010 04:23, Hans Verkuil escreveu:
   The following changes since commit 
   57fef3eb74a04716a8dd18af0ac510ec4f71bc05:
 Richard Zidlicky (1):
   V4L/DVB: dvb: fix smscore_getbuffer() logic
   
   are available in the git repository at:
   
 ssh://linuxtv.org/git/hverkuil/v4l-dvb.git misc2
   
   Hans Verkuil (6):
 V4L Doc: removed duplicate link
  
  This doesn't seem right. the entry for V4L2-PIX-FMT-BGR666 seems to be 
  duplicated.
  We should remove the duplication, instead of just dropping the ID.
 
 No, this patch is correct. This section really duplicates the formats due to
 confusion about the byte order in memory. But only one of these format tables
 should have a valid ID.
 
 See table 2.4 and 2.5 here:
 
 http://www.xs4all.nl/~hverkuil/spec/media.html#packed-rgb
 
 As you can see here there is no BGR666 entry in either table since the docbook
 generation has been failing on this docbook error for some time now.

FYI: for the daily build I make a nochunks version of the docs like this:

make DOCBOOKS=media.xml htmldocs
xmlto html-nochunks -m Documentation/DocBook/stylesheet.xsl -o 
Documentation/DocBook/media Documentation/DocBook/media.xml

The second step finds some docbook bugs that the first step doesn't.

Regards,

Hans

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of Cisco
--
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 PATCHES FOR 2.6.37] V4L documentation fixes

[Mauro Carvalho Chehab]

Em 22-09-2010 17:06, Hans Verkuil escreveu:
 On Wednesday, September 22, 2010 21:42:03 Mauro Carvalho Chehab wrote:
 Em 15-09-2010 04:23, Hans Verkuil escreveu:
 The following changes since commit 57fef3eb74a04716a8dd18af0ac510ec4f71bc05:
   Richard Zidlicky (1):
 V4L/DVB: dvb: fix smscore_getbuffer() logic

 are available in the git repository at:

   ssh://linuxtv.org/git/hverkuil/v4l-dvb.git misc2

 Hans Verkuil (6):
   V4L Doc: removed duplicate link

 This doesn't seem right. the entry for V4L2-PIX-FMT-BGR666 seems to be 
 duplicated.
 We should remove the duplication, instead of just dropping the ID.
 
 No, this patch is correct. This section really duplicates the formats due to
 confusion about the byte order in memory. But only one of these format tables
 should have a valid ID.
 
 See table 2.4 and 2.5 here:
 
 http://www.xs4all.nl/~hverkuil/spec/media.html#packed-rgb
 
 As you can see here there is no BGR666 entry in either table since the docbook
 generation has been failing on this docbook error for some time now.
 

   V4L Doc: fix DocBook syntax errors.
   V4L Doc: document V4L2_CAP_RDS_OUTPUT capability.
   V4L Doc: correct the documentation for VIDIOC_QUERYMENU.

 Applied, thanks.

   V4L Doc: rewrite the Device Naming section

 The new text is incomplete, as it assumes only the old non-dynamic device 
 node
 creation. Also, some distros actually create /dev/v4l, as recommended. IMHO, 
 we
 need to improve this section, proposing a better way to name devices. This 
 may
 be an interesting theme for this year's LPC.
 
 No, the major is still 81 and the minors are still between 0 and 255. But the 
 minor
 ranges are gone (unless you turn that on explicitly). So this text is really 
 correct
 and way more understandable than the old text.

Hmm... are the V4L core artificially limiting minor range to be between 0 and 
255?

 

   V4L Doc: clarify the V4L spec.

 This is a mix of several changes on the same patch. I want to do comments 
 about it,
 but no time right now to write an email about that. It is a way harder to 
 comment
 Docbook changes than patches, as the diff output is not user-friendly.
 I'll postpone this patch for a better analysis.
 
 No problem.
 
 Regards,
 
   Hans
  
 I don't want to postpone the DocBook correction patches due to that, so I'm 
 applying
 the patches I'm ok.

 Cheers,
 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: [GIT PATCHES FOR 2.6.37] Remove v4l2-i2c-drv.h and most of i2c-id.h

[Mauro Carvalho Chehab]

Em 15-09-2010 17:00, Hans Verkuil escreveu:
 Mauro, Jean, Janne,
 
 This patch series finally retires the hackish v4l2-i2c-drv.h. It served 
 honorably,
 but now that the hg repository no longer supports kernels 2.6.26 it is time 
 to
 remove it.
 
 Note that this patch series builds on the vtx-removal patch series.
 
 Several patches at the end remove unused i2c-id.h includes and remove bogus 
 uses
 of the I2C_HW_ defines (as found in i2c-id.h).
 
 After applying this patch series I get the following if I grep for
 I2C_HW_ in the kernel sources:
 
 skip some false positives in drivers/gpu
 drivers/staging/lirc/lirc_i2c.c:if (adap-id == 
 I2C_HW_B_CX2388x)
 drivers/staging/lirc/lirc_i2c.c:if (adap-id == 
 I2C_HW_B_CX2388x) {
 drivers/staging/lirc/lirc_zilog.c:#ifdef I2C_HW_B_HDPVR
 drivers/staging/lirc/lirc_zilog.c:  if (ir-c_rx.adapter-id == 
 I2C_HW_B_HDPVR) {
 drivers/staging/lirc/lirc_zilog.c:#ifdef I2C_HW_B_HDPVR
 drivers/staging/lirc/lirc_zilog.c:  if (ir-c_rx.adapter-id == 
 I2C_HW_B_HDPVR)
 drivers/video/riva/rivafb-i2c.c:chan-adapter.id= 
 I2C_HW_B_RIVA;
 drivers/media/video/ir-kbd-i2c.c:   if (ir-c-adapter-id == 
 I2C_HW_SAA7134  ir-c-addr == 0x30)
 drivers/media/video/ir-kbd-i2c.c:   if (adap-id == 
 I2C_HW_B_CX2388x) {
 drivers/media/video/saa7134/saa7134-i2c.c:  .id= 
 I2C_HW_SAA7134,
 drivers/media/video/cx88/cx88-i2c.c:core-i2c_adap.id = I2C_HW_B_CX2388x;
 drivers/media/video/cx88/cx88-vp3054-i2c.c: vp3054_i2c-adap.id = 
 I2C_HW_B_CX2388x;
 
 Jean, I guess the one in rivafb-i2c.c can just be removed, right?
 
 Janne, the HDPVR checks in lirc no longer work since hdpvr never sets the
 adapter ID (nor should it). This lirc code should be checked. I haven't
 been following the IR changes, but there must be a better way of doing this.
 
 The same is true for the CX2388x and SAA7134 checks. These all relate to the
 IR subsystem.
 
 Once we fixed these remaining users of the i2c-id.h defines, then Jean can
 remove that header together with the adapter's 'id' field.
 
 Regards,
 
   Hans
 
 The following changes since commit 991403c594f666a2ed46297c592c60c3b9f4e1e2:
   Mauro Carvalho Chehab (1):
 V4L/DVB: cx231xx: Avoid an OOPS when card is unknown (card=0)
 
 are available in the git repository at:
 
   ssh://linuxtv.org/git/hverkuil/v4l-dvb.git i2c
 
...
   tvaudio: remove obsolete tda8425 initialization
...

This patch is incomplete. It removes the initialization, but it forgets to 
remove other references.
This is what grep says about tda8425:

drivers/media/video/Kconfig:   tea6320, tea6420, tda8425, ta8874z.
drivers/media/video/tda7432.c: * Which was based on tda8425.c by Greg Alexander 
(c) 1998
drivers/media/video/tda9875.c: * Which was based on tda8425.c by Greg Alexander 
(c) 1998
drivers/media/video/tvaudio.c:/* audio chip descriptions - defines+functions 
for tda8425*/
drivers/media/video/tvaudio.c:#define TDA8425_VL 0x00  /* volume left */
drivers/media/video/tvaudio.c:#define TDA8425_VR 0x01  /* volume right 
*/
drivers/media/video/tvaudio.c:#define TDA8425_BA 0x02  /* bass */
drivers/media/video/tvaudio.c:#define TDA8425_TR 0x03  /* treble */
drivers/media/video/tvaudio.c:#define TDA8425_S1 0x08  /* switch 
functions */
drivers/media/video/tvaudio.c:#define TDA8425_S1_OFF 0xEE  /* audio off 
(mute on) */
drivers/media/video/tvaudio.c:#define TDA8425_S1_CH1 0xCE  /* audio channel 
1 (mute off) - linear stereo mode */
drivers/media/video/tvaudio.c:#define TDA8425_S1_CH2 0xCF  /* audio channel 
2 (mute off) - linear stereo mode */
drivers/media/video/tvaudio.c:#define TDA8425_S1_MU  0x20  /* mute bit */
drivers/media/video/tvaudio.c:#define TDA8425_S1_STEREO  0x18  /* stereo bits */
drivers/media/video/tvaudio.c:#define TDA8425_S1_STEREO_SPATIAL 0x18 /* spatial 
stereo */
drivers/media/video/tvaudio.c:#define TDA8425_S1_STEREO_LINEAR  0x08 /* linear 
stereo */
drivers/media/video/tvaudio.c:#define TDA8425_S1_STEREO_PSEUDO  0x10 /* pseudo 
stereo */
drivers/media/video/tvaudio.c:#define TDA8425_S1_STEREO_MONO0x00 /* forced 
mono */
drivers/media/video/tvaudio.c:#define TDA8425_S1_ML  0x06/* 
language selector */
drivers/media/video/tvaudio.c:#define TDA8425_S1_ML_SOUND_A 0x02 /* sound a 
*/
drivers/media/video/tvaudio.c:#define TDA8425_S1_ML_SOUND_B 0x04 /* sound b 
*/
drivers/media/video/tvaudio.c:#define TDA8425_S1_ML_STEREO  0x06 /* stereo 
*/
drivers/media/video/tvaudio.c:#define TDA8425_S1_IS  0x01/* channel 
selector */
drivers/media/video/tvaudio.c:static int tda8425_shift10(int val) { return (val 
 10) | 0xc0; }
drivers/media/video/tvaudio.c:static int tda8425_shift12(int val) { return (val 
 12) | 0xf0; }
drivers/media/video/tvaudio.c:static int tda8425_initialize(struct CHIPSTATE 
*chip)
drivers/media/video/tvaudio.c:  int 

[GIT PATCHES FOR 2.6.36] Bug fixes for the uvcvideo driver

[Laurent Pinchart]

Hi Mauro,

The following changes since commit 67ac062a5138ed446a821051fddd798a01478f85:

  V4L/DVB: Fix regression for BeholdTV Columbus (2010-08-24 10:39:32 -0300)

are available in the git repository at:
  git://linuxtv.org/pinchartl/uvcvideo.git uvcvideo-stable

Laurent Pinchart (2):
  uvcvideo: Fix support for Medion Akoya All-in-one PC integrated webcam
  uvcvideo: Restrict frame rates for Chicony CNF7129 webcam

 drivers/media/video/uvc/uvc_driver.c |   24 
 drivers/media/video/uvc/uvcvideo.h   |1 +
 2 files changed, 25 insertions(+), 0 deletions(-)

-- 
Regards,

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

Re: [linux-dvb] Asus MyCinema P7131 Dual support

[hermann-pitton]

 

Hi Dejan,

- Original Nachricht 
Von: Dejan Rodiger dejan.rodi...@gmail.com
An:  hermann pitton hermann-pit...@arcor.de
Datum:   22.09.2010 13:20
Betreff: Re: [linux-dvb] Asus MyCinema P7131 Dual support

 Hi Herman,
 
 here is dmesg output without forcing card=78.
 As I see it uses card=112, autodetected
 
 [   16.043345] IR RC6 protocol handler initialized
 [   16.173473] IR JVC protocol handler initialized
 [   16.236641] IR Sony protocol handler initialized
 [   16.433187] lirc_dev: IR Remote Control driver registered, major 250
 [   16.572705] IR LIRC bridge handler initialized
 [   16.894983] Linux video capture interface: v2.00
 [   16.957585] saa7130/34: v4l2 driver version 0.2.16 loaded
 [   16.958300] ACPI: PCI Interrupt Link [APC3] enabled at IRQ 18
 [   16.958306]   alloc irq_desc for 18 on node 0
 [   16.958309]   alloc kstat_irqs on node 0
 [   16.958320] saa7134 :01:06.0: PCI INT A - Link[APC3] - GSI 18
 (level, low) - IRQ 18
 [   16.958327] saa7133[0]: found at :01:06.0, rev: 209, irq: 18,
 latency: 32, mmio: 0xfdeff000
 [   16.958334] saa7133[0]: subsystem: 1043:4876, board: ASUSTeK P7131
 Hybrid [card=112,autodetected]
 [   16.958378] saa7133[0]: board init: gpio is 0
 [   17.010075] Registered IR keymap rc-asus-pc39
 [   17.010197] input: saa7134 IR (ASUSTeK P7131 Hybri as
 /devices/pci:00/:00:09.0/:01:06.0/rc/rc0/input4
 [   17.010268] rc0: saa7134 IR (ASUSTeK P7131 Hybri as
 /devices/pci:00/:00:09.0/:01:06.0/rc/rc0
 [   17.190477] saa7133[0]: i2c eeprom 00: 43 10 76 48 54 20 1c 00 43
 43 a9 1c 55 d2 b2 92
 [   17.190490] saa7133[0]: i2c eeprom 10: ff ff ff 0f ff 20 ff ff ff
 ff ff ff ff ff ff ff
 [   17.190502] saa7133[0]: i2c eeprom 20: 01 40 01 02 03 01 01 03 08
 ff 00 d5 ff ff ff ff
 [   17.190513] saa7133[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff
 ff ff ff ff ff ff ff
 [   17.190524] saa7133[0]: i2c eeprom 40: ff 21 00 c2 96 10 03 32 55
 50 ff ff ff ff ff ff
 [   17.190534] saa7133[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff
 ff ff ff ff ff ff ff
 [   17.190545] saa7133[0]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff
 ff ff ff ff ff ff ff
 [   17.190556] saa7133[0]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff
 ff ff ff ff ff ff ff
 [   17.190566] saa7133[0]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff
 ff ff ff ff ff ff ff
 [   17.190577] saa7133[0]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff
 ff ff ff ff ff ff ff
 [   17.190587] saa7133[0]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff
 ff ff ff ff ff ff ff
 [   17.190598] saa7133[0]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff
 ff ff ff ff ff ff ff
 [   17.190609] saa7133[0]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff
 ff ff ff ff ff ff ff
 [   17.190620] saa7133[0]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff
 ff ff ff ff ff ff ff
 [   17.190630] saa7133[0]: i2c eeprom e0: ff ff ff ff ff ff ff ff ff
 ff ff ff ff ff ff ff
 [   17.190641] saa7133[0]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff
 ff ff ff ff ff ff ff
 
 [   17.610120] tuner 2-004b: chip found @ 0x96 (saa7133[0])
 
 [   17.780037] tda829x 2-004b: setting tuner address to 61
 [   17.940020] tda829x 2-004b: type set to tda8290+75a
 
 [   24.000114] saa7133[0]: registered device video0 [v4l2]
 [   24.000150] saa7133[0]: registered device vbi0
 [   24.000182] saa7133[0]: registered device radio0
 [   24.027730] saa7134 ALSA driver for DMA sound loaded
 [   24.027770] saa7133[0]/alsa: saa7133[0] at 0xfdeff000 irq 18
 registered as card -2
 
 [   25.900159] DVB: registering new adapter (saa7133[0])
 [   25.900165] DVB: registering adapter 0 frontend 0 (Philips
 TDA10046H DVB-T)...
 
 [   26.710050] tda1004x: setting up plls for 48MHz sampling clock
 [   27.710043] tda1004x: found firmware revision 29 -- ok
 
 
 --
 Dejan Rodiger
 M: +385917829076
 S: callto://drodiger
 

all looks fine now.

With auto detection you should have correct LNA support for analog tuning and 
DVB-T.

You need to connect the DVB-T signal to the FM/RF antenna input and the analog 
TV signal
to the cable RF input..

If you plug in the remote receiver, gpio 0x04 will switch to high.

Does this help any further?

What went wrong previously, making you think you might have to force for 
example card = 78 ?

I can revive almost all of the Asus cards on the saa713x driver if needed.

Have fun, hopefully.

Cheers,
Hermann


 
 On Wed, Sep 22, 2010 at 01:13, hermann pitton hermann-pit...@arcor.de
 wrote:
  Hi Dejan,
 
  Am Dienstag, den 21.09.2010, 10:07 +0200 schrieb Dejan Rodiger:
  Hi,
 
  I am using Ubuntu linux 10.10 with the latest kernel 2.6.35-22-generic
  on x86_64. I have installed nonfree firmware which should support this
  card, but to be sure, can somebody confirm that my TV card is
  supported in Analog or DVB mode?
 
  sudo lspci -vnn
  01:06.0 Multimedia controller [0480]: Philips Semiconductors
  SAA7131/SAA7133/SAA7135 Video Broadcast Decoder [1131:7133] (rev d1)
          Subsystem: ASUSTeK Computer Inc. My Cinema-P7131 Hybrid
  [1043:4876]
   

Re: [PATCH v2 1/6] SoC Camera: add driver for OMAP1 camera interface

[hermann pitton]

Am Mittwoch, den 22.09.2010, 08:08 +0200 schrieb Guennadi Liakhovetski:
 On Wed, 22 Sep 2010, hermann pitton wrote:
 
  Am Mittwoch, den 22.09.2010, 01:23 +0200 schrieb Guennadi Liakhovetski:
   On Sat, 11 Sep 2010, Janusz Krzysztofik wrote:
   
This is a V4L2 driver for TI OMAP1 SoC camera interface.
  
  [snip]
  
+
+   } else {
+   dev_warn(dev, %s: unhandled camera interrupt, status 
== 
+   0x%0x\n, __func__, it_status);
   
   Please, don't split strings
  
  sorry for any OT interference.
  
  But, are there any new rules out?
  
  Maybe I missed them.
  
  Either way, the above was forced during the last three years.
  
  Not at all ?
 
 No. Splitting print strings has always been discouraged, because it makes 
 tracking back kernel logs difficult. The reason for this has been the 80 
 character line length limit, which has now been effectively lifted. I'm 
 sure you can find enough links on the internet for any of these topics.
 
 Thanks
 Guennadi
 ---
 Guennadi Liakhovetski, Ph.D.
 Freelance Open-Source Software Developer
 http://www.open-technology.de/

Guennadi,

thanks for the update!

If somebody ever would like to waste time on it, lots of patches and
whole drivers have been forced into this limitations for strings too.

In fact, fixing only a few lines, including the offset, you almost
always did hit it.

I'm pleased to hear now, that this problem never did exist ;))

Cheers,
Hermann







--
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 v2] tm6000+audio

[Dmitri Belimov]

Hi

 Em 20-09-2010 17:07, Dmitri Belimov escreveu:
  Hi 
  
  I rework my last patch for audio and now audio works well. This
  patch can be submited to GIT tree Quality of audio now is good for
  SECAM-DK. For other standard I set some value from datasheet need
  some tests.
  
  1. Fix pcm buffer overflow
  2. Rework pcm buffer fill method
  3. Swap bytes in audio stream
  4. Change some registers value for TM6010
  5. Change pcm buffer size
  --- a/drivers/staging/tm6000/tm6000-stds.c
  +++ b/drivers/staging/tm6000/tm6000-stds.c
  @@ -96,6 +96,7 @@ static struct tm6000_std_tv_settings tv_stds[] = {
   
  {TM6010_REQ07_R04_LUMA_HAGC_CONTROL, 0xdc},
  {TM6010_REQ07_R0D_CHROMA_KILL_LEVEL, 0x07},
  +   {TM6010_REQ08_R05_A_STANDARD_MOD,
  0x21}, /* FIXME */
 
 This didn't seem to work for PAL-M. Probably, the right value for it
 is 0x22, to follow NTSC/M, since both uses the same audio standard.
 
 On some tests, I was able to receive some audio there, at the proper
 rate, with a tm6010-based device. It died when I tried to change the
 channel, so I didn't rear yet the real audio, but I suspect it will
 work on my next tests.
 
 Yet, is being hard to test, as the driver has a some spinlock logic
 broken. I'm enclosing the logs.

Yes. I have some as crash from mplayer and arecord.

 I was able to test only when using a monitor on the same machine. All
 trials of using vnc and X11 export ended by not receiving any audio
 and hanging the machine.
 
 I suspect that we need to fix the spinlock issue, in order to better
 test it.

Who can fix it?

 Cheers,
 Mauro.
 
 [  564.483502] [drm] nouveau :0f:00.0: Allocating FIFO number 1

snip

My dumps:
arecord

[  249.943299] BUG: scheduling while atomic: arecord/3112/0x0004
[  249.943302] Modules linked in: tm6000_alsa(C) xc5000 tuner tm6000(C) 
ir_lirc_codec lirc_dev v4l2_common videodev ir_sony_decoder v4l1_compat 
videobuf_vmalloc ir_jvc_decoder videobuf_core ir_rc6_decoder ir_rc5_decoder 
ir_nec_decoder ir_common ir_core ppdev lp ipv6 dm_snapshot dm_mirror 
dm_region_hash dm_log dm_mod sha1_generic arc4 ecb ppp_mppe ppp_generic slhc 
loop snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_pcm_oss 
snd_mixer_oss snd_pcm snd_seq_dummy snd_seq_oss snd_seq_midi snd_rawmidi 
snd_seq_midi_event snd_seq snd_timer snd_seq_device snd parport_pc processor 
parport soundcore button psmouse snd_page_alloc intel_agp tpm_tis tpm i2c_i801 
agpgart tpm_bios i2c_core rng_core serio_raw pcspkr evdev ext3 jbd mbcache sg 
sr_mod cdrom sd_mod ata_generic ata_piix libata ehci_hcd uhci_hcd scsi_mod 
ide_pci_generic r8169 mii usbcore ide_core nls_base thermal fan thermal_sys 
[last unloaded: scsi_wait_scan]
[  249.943373] Pid: 3112, comm: arecord Tainted: G C  2.6.35-tm6000-01+ 
#1
[  249.943375] Call Trace:
[  249.943383]  [c10289a8] __schedule_bug+0x4d/0x52
[  249.943388]  [c125ccac] schedule+0x85/0x6df
[  249.943392]  [c125ee10] ? _raw_spin_lock_irqsave+0x19/0x33
[  249.943396]  [c103df81] ? lock_timer_base+0x24/0x43
[  249.943399]  [c125d6cb] schedule_timeout+0x1e4/0x204
[  249.943402]  [c103e126] ? process_timeout+0x0/0xf
[  249.943405]  [c125ca7f] wait_for_common+0x9d/0xf3
[  249.943408]  [c102f9ed] ? default_wake_function+0x0/0x12
[  249.943412]  [c125cb5b] wait_for_completion_timeout+0x12/0x14
[  249.943424]  [f8091b0b] usb_start_wait_urb+0x66/0xed [usbcore]
[  249.943433]  [f8091dc5] usb_control_msg+0x115/0x12e [usbcore]
[  249.943437]  [f81872ff] tm6000_read_write_usb+0x1be/0x267 [tm6000]
[  249.943440]  [c1027bcd] ? get_parent_ip+0xb/0x31
[  249.943444]  [f8187472] tm6000_get_reg+0x2a/0x3a [tm6000]
[  249.943447]  [f81da343] snd_tm6000_card_trigger+0x56/0xb2 [tm6000_alsa]
[  249.943453]  [f869b8a1] snd_pcm_do_start+0x21/0x28 [snd_pcm]
[  249.943458]  [f869b7fa] snd_pcm_action_single+0x2a/0x50 [snd_pcm]
[  249.943463]  [f869cce4] snd_pcm_action+0x6d/0x79 [snd_pcm]
[  249.943467]  [f869cdd6] snd_pcm_start+0x19/0x1b [snd_pcm]
[  249.943472]  [f86a2895] snd_pcm_lib_read1+0x7d/0x28b [snd_pcm]
[  249.943477]  [f86a2b4f] snd_pcm_lib_read+0x47/0x55 [snd_pcm]
[  249.943482]  [f86a1105] ? snd_pcm_lib_read_transfer+0x0/0x83 [snd_pcm]
[  249.943487]  [f869f907] snd_pcm_capture_ioctl1+0xa9/0x355 [snd_pcm]
[  249.943492]  [f869fbde] snd_pcm_capture_ioctl+0x2b/0x38 [snd_pcm]
[  249.943497]  [f869fbb3] ? snd_pcm_capture_ioctl+0x0/0x38 [snd_pcm]
[  249.943501]  [c10cab95] vfs_ioctl+0x27/0x8c
[  249.943504]  [c10cb0dc] do_vfs_ioctl+0x439/0x45e
[  249.943508]  [c10bf6e4] ? vfs_write+0x104/0x142
[  249.943511]  [c10cb146] sys_ioctl+0x45/0x5f
[  249.943515]  [c100290c] sysenter_do_call+0x12/0x22

mplayer

[15186.564022] BUG: scheduling while atomic: mplayer/3899/0x0004
[15186.564026] Modules linked in: tm6000_alsa(C) xc5000 tuner tm6000(C) 
ir_lirc_codec lirc_dev v4l2_common videodev ir_sony_decoder v4l1_compat 
videobuf_vmalloc videobuf_core ir_jvc_decoder ir_rc6_decoder ir_rc5_decoder 
ir_nec_decoder ir_common ir_core 

Re: [GIT PATCHES FOR 2.6.37] Remove v4l2-i2c-drv.h and most of i2c-id.h

[Mauro Carvalho Chehab]

Em 15-09-2010 17:00, Hans Verkuil escreveu:
 Mauro, Jean, Janne,

 After applying this patch series I get the following if I grep for
 I2C_HW_ in the kernel sources:
 
 skip some false positives in drivers/gpu
 drivers/staging/lirc/lirc_zilog.c:#ifdef I2C_HW_B_HDPVR
 drivers/staging/lirc/lirc_zilog.c:  if (ir-c_rx.adapter-id == 
 I2C_HW_B_HDPVR) {
 drivers/staging/lirc/lirc_zilog.c:#ifdef I2C_HW_B_HDPVR
 drivers/staging/lirc/lirc_zilog.c:  if (ir-c_rx.adapter-id == 
 I2C_HW_B_HDPVR)

Those are with Janne ;)

 drivers/video/riva/rivafb-i2c.c:chan-adapter.id= 
 I2C_HW_B_RIVA;

No idea about this one.

 drivers/media/video/ir-kbd-i2c.c:   if (ir-c-adapter-id == 
 I2C_HW_SAA7134  ir-c-addr == 0x30)
 drivers/media/video/saa7134/saa7134-i2c.c:  .id= 
 I2C_HW_SAA7134,

Those are easy: just add the polling interval into the platform_data. If zero,
uses the default value. I'll write a patch for it.

 drivers/media/video/ir-kbd-i2c.c:   if (adap-id == 
 I2C_HW_B_CX2388x) {

This is not hard to solve. I' ll write a patch for it.

 drivers/staging/lirc/lirc_i2c.c:if (adap-id == 
 I2C_HW_B_CX2388x)
 drivers/staging/lirc/lirc_i2c.c:if (adap-id == 
 I2C_HW_B_CX2388x) {
 drivers/media/video/cx88/cx88-i2c.c:core-i2c_adap.id = I2C_HW_B_CX2388x;
 drivers/media/video/cx88/cx88-vp3054-i2c.c: vp3054_i2c-adap.id = 
 I2C_HW_B_CX2388x;

We need to solve lirc_i2c.c issues before being able to remove those. As 
lirc_i2c has
the same implementation as ir-kbd-i2c, it is probably easier to just get rid of 
it,
and then remove those two references. Jarod is working on it.

While touching it, I'll move PV951 to bttv driver, and move all IR 
initialization code to 
bttv-input and cx88-input on those two drivers. This will make life easier when 
porting
the code to rc-core, as everything that needs to be changed will be at the same 
file.

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

[PATCH 1/3] V4L/DVB: bttv: Move PV951 IR to the right driver

[Mauro Carvalho Chehab]

Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com

diff --git a/drivers/media/video/bt8xx/bttv-i2c.c 
b/drivers/media/video/bt8xx/bttv-i2c.c
index 407fa61..d502f41 100644
--- a/drivers/media/video/bt8xx/bttv-i2c.c
+++ b/drivers/media/video/bt8xx/bttv-i2c.c
@@ -390,41 +390,3 @@ int __devinit init_bttv_i2c(struct bttv *btv)
 
return btv-i2c_rc;
 }
-
-/* Instantiate the I2C IR receiver device, if present */
-void __devinit init_bttv_i2c_ir(struct bttv *btv)
-{
-   if (0 == btv-i2c_rc) {
-   struct i2c_board_info info;
-   /* The external IR receiver is at i2c address 0x34 (0x35 for
-  reads).  Future Hauppauge cards will have an internal
-  receiver at 0x30 (0x31 for reads).  In theory, both can be
-  fitted, and Hauppauge suggest an external overrides an
-  internal.
-
-  That's why we probe 0x1a (~0x34) first. CB
-   */
-   const unsigned short addr_list[] = {
-   0x1a, 0x18, 0x4b, 0x64, 0x30, 0x71,
-   I2C_CLIENT_END
-   };
-
-   memset(info, 0, sizeof(struct i2c_board_info));
-   strlcpy(info.type, ir_video, I2C_NAME_SIZE);
-   i2c_new_probed_device(btv-c.i2c_adap, info, addr_list);
-   }
-}
-
-int __devexit fini_bttv_i2c(struct bttv *btv)
-{
-   if (0 != btv-i2c_rc)
-   return 0;
-
-   return i2c_del_adapter(btv-c.i2c_adap);
-}
-
-/*
- * Local variables:
- * c-basic-offset: 8
- * End:
- */
diff --git a/drivers/media/video/bt8xx/bttv-input.c 
b/drivers/media/video/bt8xx/bttv-input.c
index f68717a..8c90673 100644
--- a/drivers/media/video/bt8xx/bttv-input.c
+++ b/drivers/media/video/bt8xx/bttv-input.c
@@ -245,6 +245,83 @@ static void bttv_ir_stop(struct bttv *btv)
}
 }
 
+/*
+ * Get_key functions used by I2C remotes
+ */
+
+static int get_key_pv951(struct IR_i2c *ir, u32 *ir_key, u32 *ir_raw)
+{
+   unsigned char b;
+
+   /* poll IR chip */
+   if (1 != i2c_master_recv(ir-c, b, 1)) {
+   dprintk(KERN_INFO DEVNAME : read error\n);
+   return -EIO;
+   }
+
+   /* ignore 0xaa */
+   if (b==0xaa)
+   return 0;
+   dprintk(KERN_INFO DEVNAME : key %02x\n, b);
+
+   *ir_key = b;
+   *ir_raw = b;
+   return 1;
+}
+
+/* Instantiate the I2C IR receiver device, if present */
+void __devinit init_bttv_i2c_ir(struct bttv *btv)
+{
+   const unsigned short addr_list[] = {
+   0x1a, 0x18, 0x64, 0x30, 0x71,
+   I2C_CLIENT_END
+   };
+   struct i2c_board_info info;
+
+   if (0 != btv-i2c_rc)
+   return;
+
+   memset(info, 0, sizeof(struct i2c_board_info));
+   memset(btv-init_data, 0, sizeof(btv-init_data));
+   strlcpy(info.type, ir_video, I2C_NAME_SIZE);
+
+   switch (btv-c.type) {
+   case BTTV_BOARD_PV951:
+   btv-init_data.name = PV951;
+   btv-init_data.get_key = get_key_pv951;
+   btv-init_data.ir_codes = RC_MAP_PV951;
+   btv-init_data.type = IR_TYPE_OTHER;
+   info.addr = 0x4b;
+   break;
+   default:
+   /*
+* The external IR receiver is at i2c address 0x34 (0x35 for
+ * reads).  Future Hauppauge cards will have an internal
+ * receiver at 0x30 (0x31 for reads).  In theory, both can be
+ * fitted, and Hauppauge suggest an external overrides an
+ * internal.
+* That's why we probe 0x1a (~0x34) first. CB
+*/
+
+   i2c_new_probed_device(btv-c.i2c_adap, info, addr_list);
+   return;
+   }
+
+   if (btv-init_data.name)
+   info.platform_data = btv-init_data;
+   i2c_new_device(btv-c.i2c_adap, info);
+
+   return;
+}
+
+int __devexit fini_bttv_i2c(struct bttv *btv)
+{
+   if (0 != btv-i2c_rc)
+   return 0;
+
+   return i2c_del_adapter(btv-c.i2c_adap);
+}
+
 int bttv_input_init(struct bttv *btv)
 {
struct card_ir *ir;
@@ -420,10 +497,3 @@ void bttv_input_fini(struct bttv *btv)
kfree(btv-remote);
btv-remote = NULL;
 }
-
-
-/*
- * Local variables:
- * c-basic-offset: 8
- * End:
- */
diff --git a/drivers/media/video/bt8xx/bttv.h b/drivers/media/video/bt8xx/bttv.h
index 3ec2402..6fd2a8e 100644
--- a/drivers/media/video/bt8xx/bttv.h
+++ b/drivers/media/video/bt8xx/bttv.h
@@ -18,7 +18,6 @@
 #include linux/i2c.h
 #include media/v4l2-device.h
 #include media/ir-common.h
-#include media/ir-kbd-i2c.h
 #include media/i2c-addr.h
 #include media/tuner.h
 
diff --git a/drivers/media/video/bt8xx/bttvp.h 
b/drivers/media/video/bt8xx/bttvp.h
index 62a..d1e26a4 100644
--- a/drivers/media/video/bt8xx/bttvp.h
+++ b/drivers/media/video/bt8xx/bttvp.h
@@ -42,7 +42,7 @@
 #include media/videobuf-dma-sg.h
 #include media/tveeprom.h
 #include 

[PATCH 2/3] V4L/DVB: Remove the usage of I2C_HW_B_CX2388x on ir-kbd-i2c.c

[Mauro Carvalho Chehab]

Move the cx88 specific initialization for Hauppauge XVR remotes
into cx88-input, removing the need for test it inside ir-kbd-i2c.

The reference at cx88 for this symbol, at:

drivers/media/video/cx88/cx88-i2c.c:core-i2c_adap.id = I2C_HW_B_CX2388x;
drivers/media/video/cx88/cx88-vp3054-i2c.c: vp3054_i2c-adap.id = 
I2C_HW_B_CX2388x;

Can't be removed yet, since lirc-i2c still uses it.

Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com

diff --git a/drivers/media/video/cx88/cx88-i2c.c 
b/drivers/media/video/cx88/cx88-i2c.c
index b897f86..f53836b 100644
--- a/drivers/media/video/cx88/cx88-i2c.c
+++ b/drivers/media/video/cx88/cx88-i2c.c
@@ -183,41 +183,3 @@ int cx88_i2c_init(struct cx88_core *core, struct pci_dev 
*pci)
 
return core-i2c_rc;
 }
-
-void cx88_i2c_init_ir(struct cx88_core *core)
-{
-   /* Instantiate the IR receiver device, if present */
-   if (0 == core-i2c_rc) {
-   struct i2c_board_info info;
-   const unsigned short addr_list[] = {
-   0x18, 0x6b, 0x71,
-   I2C_CLIENT_END
-   };
-   const unsigned short *addrp;
-
-   memset(info, 0, sizeof(struct i2c_board_info));
-   strlcpy(info.type, ir_video, I2C_NAME_SIZE);
-   /*
-* We can't call i2c_new_probed_device() because it uses
-* quick writes for probing and at least some R receiver
-* devices only reply to reads.
-*/
-   for (addrp = addr_list; *addrp != I2C_CLIENT_END; addrp++) {
-   if (i2c_smbus_xfer(core-i2c_adap, *addrp, 0,
-  I2C_SMBUS_READ, 0,
-  I2C_SMBUS_QUICK, NULL) = 0) {
-   info.addr = *addrp;
-   i2c_new_device(core-i2c_adap, info);
-   break;
-   }
-   }
-   }
-}
-
-/* --- */
-
-/*
- * Local variables:
- * c-basic-offset: 8
- * End:
- */
diff --git a/drivers/media/video/cx88/cx88-input.c 
b/drivers/media/video/cx88/cx88-input.c
index eccc5e4..d52ce0e 100644
--- a/drivers/media/video/cx88/cx88-input.c
+++ b/drivers/media/video/cx88/cx88-input.c
@@ -609,13 +609,54 @@ void cx88_ir_irq(struct cx88_core *core)
return;
 }
 
+
+void cx88_i2c_init_ir(struct cx88_core *core)
+{
+   struct i2c_board_info info;
+   const unsigned short addr_list[] = {
+   0x18, 0x6b, 0x71,
+   I2C_CLIENT_END
+   };
+   const unsigned short *addrp;
+   /* Instantiate the IR receiver device, if present */
+   if (0 != core-i2c_rc)
+   return;
+
+   memset(info, 0, sizeof(struct i2c_board_info));
+   strlcpy(info.type, ir_video, I2C_NAME_SIZE);
+
+   /*
+* We can't call i2c_new_probed_device() because it uses
+* quick writes for probing and at least some RC receiver
+* devices only reply to reads.
+* Also, Hauppauge XVR needs to be specified, as address 0x71
+* conflicts with another remote type used with saa7134
+*/
+   for (addrp = addr_list; *addrp != I2C_CLIENT_END; addrp++) {
+   info.platform_data = NULL;
+   memset(core-init_data, 0, sizeof(core-init_data));
+
+   if (*addrp == 0x71) {
+   /* Hauppauge XVR */
+   core-init_data.name = cx88 Hauppauge XVR remote;
+   core-init_data.ir_codes = RC_MAP_HAUPPAUGE_NEW;
+   core-init_data.type = IR_TYPE_RC5;
+   core-init_data.internal_get_key_func = 
IR_KBD_GET_KEY_HAUP_XVR;
+
+   info.platform_data = core-init_data;
+   }
+   if (i2c_smbus_xfer(core-i2c_adap, *addrp, 0,
+   I2C_SMBUS_READ, 0,
+   I2C_SMBUS_QUICK, NULL) = 0) {
+   info.addr = *addrp;
+   i2c_new_device(core-i2c_adap, info);
+   break;
+   }
+   }
+}
+
 /* -- */
 
 MODULE_AUTHOR(Gerd Knorr, Pavel Machek, Chris Pascoe);
 MODULE_DESCRIPTION(input driver for cx88 GPIO-based IR remote controls);
 MODULE_LICENSE(GPL);
-/*
- * Local variables:
- * c-basic-offset: 8
- * End:
- */
diff --git a/drivers/media/video/cx88/cx88.h b/drivers/media/video/cx88/cx88.h
index bda9e3e..127118f 100644
--- a/drivers/media/video/cx88/cx88.h
+++ b/drivers/media/video/cx88/cx88.h
@@ -31,9 +31,8 @@
 #include media/videobuf-dma-sg.h
 #include media/v4l2-chip-ident.h
 #include media/cx2341x.h
-#if defined(CONFIG_VIDEO_CX88_DVB) || defined(CONFIG_VIDEO_CX88_DVB_MODULE)
 #include media/videobuf-dvb.h
-#endif
+#include media/ir-kbd-i2c.h
 
 #include 

[PATCH 3/3] V4L/DVB: saa7134: get rid of I2C_HW_SAA7134

[Mauro Carvalho Chehab]

The only reason for keeping I2C_HW_SAA7134 is to allow setting a
per-device polling interval. Just move this info to the platform
data, allowing drivers to change it per device, where needed.

Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com

diff --git a/drivers/media/video/ir-kbd-i2c.c b/drivers/media/video/ir-kbd-i2c.c
index 91b2c88..5a000c6 100644
--- a/drivers/media/video/ir-kbd-i2c.c
+++ b/drivers/media/video/ir-kbd-i2c.c
@@ -259,15 +259,9 @@ static void ir_key_poll(struct IR_i2c *ir)
 static void ir_work(struct work_struct *work)
 {
struct IR_i2c *ir = container_of(work, struct IR_i2c, work.work);
-   int polling_interval = 100;
-
-   /* MSI t...@nywhere Plus requires more frequent polling
-  otherwise it will miss some keypresses */
-   if (ir-c-adapter-id == I2C_HW_SAA7134  ir-c-addr == 0x30)
-   polling_interval = 50;
 
ir_key_poll(ir);
-   schedule_delayed_work(ir-work, msecs_to_jiffies(polling_interval));
+   schedule_delayed_work(ir-work, 
msecs_to_jiffies(ir-polling_interval));
 }
 
 /* --- */
@@ -292,6 +286,7 @@ static int ir_probe(struct i2c_client *client, const struct 
i2c_device_id *id)
 
ir-c = client;
ir-input = input_dev;
+   ir-polling_interval = DEFAULT_POLLING_INTERVAL;
i2c_set_clientdata(client, ir);
 
switch(addr) {
@@ -343,6 +338,9 @@ static int ir_probe(struct i2c_client *client, const struct 
i2c_device_id *id)
if (init_data-type)
ir_type = init_data-type;
 
+   if (init_data-polling_interval)
+   ir-polling_interval = init_data-polling_interval;
+
switch (init_data-internal_get_key_func) {
case IR_KBD_GET_KEY_CUSTOM:
/* The bridge driver provided us its own function */
diff --git a/drivers/media/video/saa7134/saa7134-i2c.c 
b/drivers/media/video/saa7134/saa7134-i2c.c
index da41b6b..2d3f6d2 100644
--- a/drivers/media/video/saa7134/saa7134-i2c.c
+++ b/drivers/media/video/saa7134/saa7134-i2c.c
@@ -328,7 +328,6 @@ static struct i2c_algorithm saa7134_algo = {
 static struct i2c_adapter saa7134_adap_template = {
.owner = THIS_MODULE,
.name  = saa7134,
-   .id= I2C_HW_SAA7134,
.algo  = saa7134_algo,
 };
 
diff --git a/drivers/media/video/saa7134/saa7134-input.c 
b/drivers/media/video/saa7134/saa7134-input.c
index 0b336ca..52a1ee5 100644
--- a/drivers/media/video/saa7134/saa7134-input.c
+++ b/drivers/media/video/saa7134/saa7134-input.c
@@ -959,6 +959,11 @@ void saa7134_probe_i2c_ir(struct saa7134_dev *dev)
dev-init_data.name = MSI t...@nywhere Plus;
dev-init_data.get_key = get_key_msi_tvanywhere_plus;
dev-init_data.ir_codes = RC_MAP_MSI_TVANYWHERE_PLUS;
+   /*
+* MSI t...@nyware Plus requires more frequent polling
+* otherwise it will miss some keypresses
+*/
+   dev-init_data.polling_interval = 50;
info.addr = 0x30;
/* MSI t...@nywhere Plus controller doesn't seem to
   respond to probes unless we read something from
diff --git a/include/media/ir-kbd-i2c.h b/include/media/ir-kbd-i2c.h
index 4102f0d..557c676 100644
--- a/include/media/ir-kbd-i2c.h
+++ b/include/media/ir-kbd-i2c.h
@@ -3,6 +3,8 @@
 
 #include media/ir-common.h
 
+#define DEFAULT_POLLING_INTERVAL   100 /* ms */
+
 struct IR_i2c;
 
 struct IR_i2c {
@@ -15,6 +17,8 @@ struct IR_i2c {
/* Used to avoid fast repeating */
unsigned char  old;
 
+   u32polling_interval; /* in ms */
+
struct delayed_workwork;
char   name[32];
char   phys[32];
@@ -34,8 +38,9 @@ enum ir_kbd_get_key_fn {
 /* Can be passed when instantiating an ir_video i2c device */
 struct IR_i2c_init_data {
char*ir_codes;
-   const char *name;
-   u64  type; /* IR_TYPE_RC5, etc */
+   const char  *name;
+   u64 type; /* IR_TYPE_RC5, etc */
+   u32 polling_interval; /* 0 means 
DEFAULT_POLLING_INTERVAL */
/*
 * Specify either a function pointer or a value indicating one of
 * ir_kbd_i2c's internal get_key functions
-- 
1.7.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

[PATCH 0/3] get rid of i2c_adapter.id on ir-kbd-i2c

[Mauro Carvalho Chehab]

ir-kdb-i2c needs to check what device called it, just because of two
places where this information is used:

1) to fill the structs for Hauppauge XDR remotes on cx88 driver;
2) to set the polling interval for one saa7134 board.

On both cases, the better is to just move the initialization to the
caller driver.

While on it, move PV951 to bttv driver, as only bttv driver defines
a board with this name, and put the RC init code inside bttv-input,
for bttv driver, and on cx88-input, for cx88 driver, in order to
have all RC code together.

This will help when porting the drivers to RC core, as we won't forget
the ir-kbd-i2c case.

Mauro Carvalho Chehab (3):
  V4L/DVB: bttv: Move PV951 IR to the right driver
  V4L/DVB: Remove the usage of I2C_HW_B_CX2388x on ir-kbd-i2c.c
  V4L/DVB: saa7134: get rid of I2C_HW_SAA7134

 drivers/media/video/bt8xx/bttv-i2c.c|   38 
 drivers/media/video/bt8xx/bttv-input.c  |   84 --
 drivers/media/video/bt8xx/bttv.h|1 -
 drivers/media/video/bt8xx/bttvp.h   |   13 +++-
 drivers/media/video/cx88/cx88-i2c.c |   38 
 drivers/media/video/cx88/cx88-input.c   |   51 +++--
 drivers/media/video/cx88/cx88.h |   15 ++---
 drivers/media/video/ir-kbd-i2c.c|   60 ++-
 drivers/media/video/saa7134/saa7134-i2c.c   |1 -
 drivers/media/video/saa7134/saa7134-input.c |5 ++
 include/media/ir-kbd-i2c.h  |   10 ++-
 11 files changed, 155 insertions(+), 161 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: [PATCH v2] tm6000+audio

[Mauro Carvalho Chehab]

Em 23-09-2010 13:45, Dmitri Belimov escreveu:
 Hi
 
 Em 20-09-2010 17:07, Dmitri Belimov escreveu:
 Hi 

 I rework my last patch for audio and now audio works well. This
 patch can be submited to GIT tree Quality of audio now is good for
 SECAM-DK. For other standard I set some value from datasheet need
 some tests.

 1. Fix pcm buffer overflow
 2. Rework pcm buffer fill method
 3. Swap bytes in audio stream
 4. Change some registers value for TM6010
 5. Change pcm buffer size
 --- a/drivers/staging/tm6000/tm6000-stds.c
 +++ b/drivers/staging/tm6000/tm6000-stds.c
 @@ -96,6 +96,7 @@ static struct tm6000_std_tv_settings tv_stds[] = {
  
 {TM6010_REQ07_R04_LUMA_HAGC_CONTROL, 0xdc},
 {TM6010_REQ07_R0D_CHROMA_KILL_LEVEL, 0x07},
 +   {TM6010_REQ08_R05_A_STANDARD_MOD,
 0x21}, /* FIXME */

 This didn't seem to work for PAL-M. Probably, the right value for it
 is 0x22, to follow NTSC/M, since both uses the same audio standard.

 On some tests, I was able to receive some audio there, at the proper
 rate, with a tm6010-based device. It died when I tried to change the
 channel, so I didn't rear yet the real audio, but I suspect it will
 work on my next tests.

 Yet, is being hard to test, as the driver has a some spinlock logic
 broken. I'm enclosing the logs.
 
 Yes. I have some as crash from mplayer and arecord.
 
 I was able to test only when using a monitor on the same machine. All
 trials of using vnc and X11 export ended by not receiving any audio
 and hanging the machine.

 I suspect that we need to fix the spinlock issue, in order to better
 test it.
 
 Who can fix it?

Well, any of us ;)

I did a BKL lock fix series of patches, and hverkuil is improving them.
They'll make easier to avoid problems inside tm6000. We just need to make
sure that we'll hold/release the proper locks at tm6000-alsa, after applying
it at the mainstream.

Cheers,
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: [GIT PATCHES FOR 2.6.37] V4L documentation fixes

[Hans Verkuil]

On Wednesday, September 22, 2010 23:17:08 Mauro Carvalho Chehab wrote:
 Em 22-09-2010 17:06, Hans Verkuil escreveu:
  On Wednesday, September 22, 2010 21:42:03 Mauro Carvalho Chehab wrote:
  Em 15-09-2010 04:23, Hans Verkuil escreveu:
  The following changes since commit 
  57fef3eb74a04716a8dd18af0ac510ec4f71bc05:
Richard Zidlicky (1):
  V4L/DVB: dvb: fix smscore_getbuffer() logic
 
  are available in the git repository at:
 
ssh://linuxtv.org/git/hverkuil/v4l-dvb.git misc2
 
  Hans Verkuil (6):
V4L Doc: removed duplicate link
 
  This doesn't seem right. the entry for V4L2-PIX-FMT-BGR666 seems to be 
  duplicated.
  We should remove the duplication, instead of just dropping the ID.
  
  No, this patch is correct. This section really duplicates the formats due to
  confusion about the byte order in memory. But only one of these format 
  tables
  should have a valid ID.
  
  See table 2.4 and 2.5 here:
  
  http://www.xs4all.nl/~hverkuil/spec/media.html#packed-rgb
  
  As you can see here there is no BGR666 entry in either table since the 
  docbook
  generation has been failing on this docbook error for some time now.
  
 
V4L Doc: fix DocBook syntax errors.
V4L Doc: document V4L2_CAP_RDS_OUTPUT capability.
V4L Doc: correct the documentation for VIDIOC_QUERYMENU.
 
  Applied, thanks.
 
V4L Doc: rewrite the Device Naming section
 
  The new text is incomplete, as it assumes only the old non-dynamic device 
  node
  creation. Also, some distros actually create /dev/v4l, as recommended. 
  IMHO, we
  need to improve this section, proposing a better way to name devices. This 
  may
  be an interesting theme for this year's LPC.
  
  No, the major is still 81 and the minors are still between 0 and 255. But 
  the minor
  ranges are gone (unless you turn that on explicitly). So this text is 
  really correct
  and way more understandable than the old text.
 
 Hmm... are the V4L core artificially limiting minor range to be between 0 and 
 255?

Well, we do need to keep a mapping between minor and video_device (the 
video_device
array in v4l2-dev.c) so we do need a maximum number of devices. Increasing this 
number
is a matter of just increasing the VIDEO_NUM_DEVICES macro.

Since we no longer split up the 256 minors into ranges for each video type 
(video,
vbi, radio) we make full use of all minors. Nothing I've seen comes even close 
to
filling up all those minors.

That said, when we add support for the subdev device nodes we should probably 
at the
same time double the number of reserved minors. Just in case.

Regards,

Hans

 
  
 
V4L Doc: clarify the V4L spec.
 
  This is a mix of several changes on the same patch. I want to do comments 
  about it,
  but no time right now to write an email about that. It is a way harder to 
  comment
  Docbook changes than patches, as the diff output is not user-friendly.
  I'll postpone this patch for a better analysis.
  
  No problem.
  
  Regards,
  
  Hans
   
  I don't want to postpone the DocBook correction patches due to that, so 
  I'm applying
  the patches I'm ok.
 
  Cheers,
  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
 
 

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of Cisco
--
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 PATCHES FOR 2.6.37] Remove v4l2-i2c-drv.h and most of i2c-id.h

[Hans Verkuil]

On Thursday, September 23, 2010 00:15:17 Mauro Carvalho Chehab wrote:
 Em 15-09-2010 17:00, Hans Verkuil escreveu:
  Mauro, Jean, Janne,
  
  This patch series finally retires the hackish v4l2-i2c-drv.h. It served 
  honorably,
  but now that the hg repository no longer supports kernels 2.6.26 it is 
  time to
  remove it.
  
  Note that this patch series builds on the vtx-removal patch series.
  
  Several patches at the end remove unused i2c-id.h includes and remove bogus 
  uses
  of the I2C_HW_ defines (as found in i2c-id.h).
  
  After applying this patch series I get the following if I grep for
  I2C_HW_ in the kernel sources:
  
  skip some false positives in drivers/gpu
  drivers/staging/lirc/lirc_i2c.c:if (adap-id == 
  I2C_HW_B_CX2388x)
  drivers/staging/lirc/lirc_i2c.c:if (adap-id == 
  I2C_HW_B_CX2388x) {
  drivers/staging/lirc/lirc_zilog.c:#ifdef I2C_HW_B_HDPVR
  drivers/staging/lirc/lirc_zilog.c:  if (ir-c_rx.adapter-id == 
  I2C_HW_B_HDPVR) {
  drivers/staging/lirc/lirc_zilog.c:#ifdef I2C_HW_B_HDPVR
  drivers/staging/lirc/lirc_zilog.c:  if (ir-c_rx.adapter-id == 
  I2C_HW_B_HDPVR)
  drivers/video/riva/rivafb-i2c.c:chan-adapter.id= 
  I2C_HW_B_RIVA;
  drivers/media/video/ir-kbd-i2c.c:   if (ir-c-adapter-id == 
  I2C_HW_SAA7134  ir-c-addr == 0x30)
  drivers/media/video/ir-kbd-i2c.c:   if (adap-id == 
  I2C_HW_B_CX2388x) {
  drivers/media/video/saa7134/saa7134-i2c.c:  .id= 
  I2C_HW_SAA7134,
  drivers/media/video/cx88/cx88-i2c.c:core-i2c_adap.id = 
  I2C_HW_B_CX2388x;
  drivers/media/video/cx88/cx88-vp3054-i2c.c: vp3054_i2c-adap.id = 
  I2C_HW_B_CX2388x;
  
  Jean, I guess the one in rivafb-i2c.c can just be removed, right?
  
  Janne, the HDPVR checks in lirc no longer work since hdpvr never sets the
  adapter ID (nor should it). This lirc code should be checked. I haven't
  been following the IR changes, but there must be a better way of doing this.
  
  The same is true for the CX2388x and SAA7134 checks. These all relate to the
  IR subsystem.
  
  Once we fixed these remaining users of the i2c-id.h defines, then Jean can
  remove that header together with the adapter's 'id' field.
  
  Regards,
  
  Hans
  
  The following changes since commit 991403c594f666a2ed46297c592c60c3b9f4e1e2:
Mauro Carvalho Chehab (1):
  V4L/DVB: cx231xx: Avoid an OOPS when card is unknown (card=0)
  
  are available in the git repository at:
  
ssh://linuxtv.org/git/hverkuil/v4l-dvb.git i2c
  
 ...
tvaudio: remove obsolete tda8425 initialization
 ...
 
 This patch is incomplete. It removes the initialization, but it forgets to 
 remove other references.
 This is what grep says about tda8425:

Huh? It's just the initialization function that is bogus. I'm not removing the 
tda8425
from tvaudio. If you look at that function you'll see that it has some special 
code
when used with an out-of-tree riva TV driver that hasn't been maintained since 
6 years
and no longer works with tvaudio after all the i2c core probing changes. So 
it's just
dead code now.

Regards,

Hans

 drivers/media/video/Kconfig: tea6320, tea6420, tda8425, ta8874z.
 drivers/media/video/tda7432.c: * Which was based on tda8425.c by Greg 
 Alexander (c) 1998
 drivers/media/video/tda9875.c: * Which was based on tda8425.c by Greg 
 Alexander (c) 1998
 drivers/media/video/tvaudio.c:/* audio chip descriptions - defines+functions 
 for tda8425*/
 drivers/media/video/tvaudio.c:#define TDA8425_VL 0x00  /* volume left 
 */
 drivers/media/video/tvaudio.c:#define TDA8425_VR 0x01  /* volume 
 right */
 drivers/media/video/tvaudio.c:#define TDA8425_BA 0x02  /* bass */
 drivers/media/video/tvaudio.c:#define TDA8425_TR 0x03  /* treble */
 drivers/media/video/tvaudio.c:#define TDA8425_S1 0x08  /* switch 
 functions */
 drivers/media/video/tvaudio.c:#define TDA8425_S1_OFF 0xEE  /* audio off 
 (mute on) */
 drivers/media/video/tvaudio.c:#define TDA8425_S1_CH1 0xCE  /* audio 
 channel 1 (mute off) - linear stereo mode */
 drivers/media/video/tvaudio.c:#define TDA8425_S1_CH2 0xCF  /* audio 
 channel 2 (mute off) - linear stereo mode */
 drivers/media/video/tvaudio.c:#define TDA8425_S1_MU  0x20  /* mute bit */
 drivers/media/video/tvaudio.c:#define TDA8425_S1_STEREO  0x18  /* stereo bits 
 */
 drivers/media/video/tvaudio.c:#define TDA8425_S1_STEREO_SPATIAL 0x18 /* 
 spatial stereo */
 drivers/media/video/tvaudio.c:#define TDA8425_S1_STEREO_LINEAR  0x08 /* 
 linear stereo */
 drivers/media/video/tvaudio.c:#define TDA8425_S1_STEREO_PSEUDO  0x10 /* 
 pseudo stereo */
 drivers/media/video/tvaudio.c:#define TDA8425_S1_STEREO_MONO0x00 /* 
 forced mono */
 drivers/media/video/tvaudio.c:#define TDA8425_S1_ML  0x06/* 
 language selector */
 drivers/media/video/tvaudio.c:#define TDA8425_S1_ML_SOUND_A 0x02 /* sound 
 a */