[PATCH v2 0/10] V4L2 patches for Intel Moorestown Camera Imaging Drivers

[Zhang, Xiaolin]

Hi, 

Here is the second version of V4L2 camera sensors and ISP driver patch set to 
support the Intel Moorestown camera imaging subsystem. 

The Camera Imaging interface (CI) in Moorestown is responsible for still image 
and video capture which can handle demosaicing, color synthesis, filtering, 
image enhancement, etc functionalities with a integrated JPEG encode. 
Intel Moorestown platform can support either a single camera or dual cameras. 
If a platform with dual camera will have one low resolution camera on the same 
side as this display for video conference and a high resolution camera on the 
opposite side the display for high quality still image capture.

The driver framework is updated to the v4l2 sub-dev and video buffer framework, 
in this set of driver patches, I will submit the 10 patches to enable the 
camera subsystem with the device drivers for ISP HW and 4 cameras module (two 
SoCs: 1.3MP - Omnivision 9665, 2MP - Omnivison 2650 and two RAWs: 5MP - 
Omnivision 5630, 5MP - Samsong s5k4e1).

1. Intel Moorestown ISP driver - header files.
2. Intel Moorestown ISP driver - V4L2 implementation including hardware 
component functionality  
3. Intel Moorestown flash sub-dev driver
4. Intel Moorestown 2MP camera (ov2650) sensor subdev driver.
5. Intel Moorestown 1.3MP camera (ov9665) sensor subdev driver.
6. Intel Moorestown 5MP camera (ov5630) sensor subdev driver.
7. Intel Moorestown 5MP camera (ov5630) lens subdev driver.
8. Intel Moorestown 5MP camera (s5k4e1) sensor subdev driver.
9. Intel Moorestown 5MP camera (s5k4e1) lens subdev driver
10. make/kconfig files change to enable camera drivers for intel Moorestown 
platform.

Please review them and comments are welcome as always. 

Regards,

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

[PATCH v2 3/10] V4L2 patches for Intel Moorestown Camera Imaging Drivers

[Zhang, Xiaolin]

From 1fd72af8366c3cfb04520bbee7252a1991c878ba Mon Sep 17 00:00:00 2001
From: Xiaolin Zhang xiaolin.zh...@intel.com
Date: Sun, 28 Mar 2010 13:57:52 +0800
Subject: [PATCH 03/10] This patch is the flash subdev driver for intel 
moorestown camera imaging.

Signed-off-by: Xiaolin Zhang xiaolin.zh...@intel.com
---
 drivers/media/video/mrstci/mrstflash/Kconfig |9 ++
 drivers/media/video/mrstci/mrstflash/Makefile|3 +
 drivers/media/video/mrstci/mrstflash/mrstflash.c |  150 ++
 3 files changed, 162 insertions(+), 0 deletions(-)
 create mode 100644 drivers/media/video/mrstci/mrstflash/Kconfig
 create mode 100644 drivers/media/video/mrstci/mrstflash/Makefile
 create mode 100644 drivers/media/video/mrstci/mrstflash/mrstflash.c

diff --git a/drivers/media/video/mrstci/mrstflash/Kconfig 
b/drivers/media/video/mrstci/mrstflash/Kconfig
new file mode 100644
index 000..72099c5
--- /dev/null
+++ b/drivers/media/video/mrstci/mrstflash/Kconfig
@@ -0,0 +1,9 @@
+config VIDEO_MRST_FLASH
+   tristate Moorestown flash
+   depends on I2C  VIDEO_MRST_ISP
+
+   ---help---
+ Say Y here if your platform support moorestown flash.
+
+ To compile this driver as a module, choose M here: the
+ module will be called mrstov2650.ko.
diff --git a/drivers/media/video/mrstci/mrstflash/Makefile 
b/drivers/media/video/mrstci/mrstflash/Makefile
new file mode 100644
index 000..068f638
--- /dev/null
+++ b/drivers/media/video/mrstci/mrstflash/Makefile
@@ -0,0 +1,3 @@
+obj-$(CONFIG_VIDEO_MRST_FLASH)  += mrstflash.o
+
+EXTRA_CFLAGS   +=  -I$(src)/../include
diff --git a/drivers/media/video/mrstci/mrstflash/mrstflash.c 
b/drivers/media/video/mrstci/mrstflash/mrstflash.c
new file mode 100644
index 000..89ceddc
--- /dev/null
+++ b/drivers/media/video/mrstci/mrstflash/mrstflash.c
@@ -0,0 +1,150 @@
+/*
+ * Support for Moorestown Langwell Camera Imaging camera flash.
+ *
+ * Copyright (c) 2009 Intel Corporation. All Rights Reserved.
+ *
+ * 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., 51 Franklin Street, Fifth Floor, Boston, MA
+ * 02110-1301, USA.
+ *
+ *
+ * Xiaolin Zhang xiaolin.zh...@intel.com
+ */
+
+#include linux/module.h
+#include linux/types.h
+#include linux/kernel.h
+#include linux/mm.h
+#include linux/string.h
+#include linux/errno.h
+#include linux/init.h
+#include linux/kmod.h
+#include linux/device.h
+#include linux/delay.h
+#include linux/fs.h
+#include linux/init.h
+#include linux/slab.h
+#include linux/delay.h
+#include linux/i2c.h
+#include linux/gpio.h
+#include linux/videodev2.h
+#include media/v4l2-device.h
+#include media/v4l2-chip-ident.h
+#include media/v4l2-i2c-drv.h
+
+static int debug;
+module_param(debug, bool, 0644);
+MODULE_PARM_DESC(debug, Debug level (0-1));
+
+MODULE_AUTHOR(Xiaolin Zhang xiaolin.zh...@intel.com);
+MODULE_DESCRIPTION(A low-level driver for mrst flash);
+MODULE_LICENSE(GPL);
+
+static int flash_g_chip_ident(struct v4l2_subdev *sd,
+   struct v4l2_dbg_chip_ident *chip)
+{
+   struct i2c_client *client = v4l2_get_subdevdata(sd);
+
+   #define V4L2_IDENT_MRST_FLASH 8248
+   return v4l2_chip_ident_i2c_client(client, chip,
+ V4L2_IDENT_MRST_FLASH, 0);
+}
+
+static const struct v4l2_subdev_core_ops flash_core_ops = {
+   .g_chip_ident = flash_g_chip_ident,
+};
+static const struct v4l2_subdev_ops flash_ops = {
+   .core = flash_core_ops,
+};
+
+static int flash_detect(struct i2c_client *client)
+{
+   struct i2c_adapter *adapter = client-adapter;
+   u8 pid;
+
+   if (!i2c_check_functionality(adapter, I2C_FUNC_SMBUS_BYTE_DATA))
+   return -ENODEV;
+
+   if (adapter-nr != 0)
+   return -ENODEV;
+
+   pid = i2c_smbus_read_byte_data(client, 0x10);
+   if (pid == 0x18) {
+   printk(KERN_ERR camera flash device found\n);
+   v4l_dbg(1, debug, client, found camera flash device);
+   } else {
+   printk(KERN_ERR no camera flash device found\n);
+   return -ENODEV;
+   }
+
+   return 0;
+}
+
+static int flash_probe(struct i2c_client *client,
+   const struct i2c_device_id *id)
+{
+   u8 pid, ver;
+   int ret = -1;
+   struct v4l2_subdev *sd;
+
+   v4l_info(client, chip found @ 0x%x (%s)\n,
+   client-addr  1, client-adapter-name);
+
+   sd = 

[PATCH v2 5/10] V4L2 patches for Intel Moorestown Camera Imaging Drivers

[Zhang, Xiaolin]

From 51bb9c1b42f8c92a5b01cdd24141ac1117a4c076 Mon Sep 17 00:00:00 2001
From: Xiaolin Zhang xiaolin.zh...@intel.com
Date: Sun, 28 Mar 2010 14:03:26 +0800
Subject: [PATCH 05/10] this patch is the 1.3mp camera (ov9665) sensor subdev 
driver fro interl moorestown camera imaging.

Signed-off-by: Xiaolin Zhang xiaolin.zh...@intel.com
---
 drivers/media/video/mrstci/mrstov9665/Kconfig  |9 +
 drivers/media/video/mrstci/mrstov9665/Makefile |3 +
 drivers/media/video/mrstci/mrstov9665/mrstov9665.c |  710 
 drivers/media/video/mrstci/mrstov9665/ov9665.h |  253 +++
 4 files changed, 975 insertions(+), 0 deletions(-)
 create mode 100644 drivers/media/video/mrstci/mrstov9665/Kconfig
 create mode 100644 drivers/media/video/mrstci/mrstov9665/Makefile
 create mode 100644 drivers/media/video/mrstci/mrstov9665/mrstov9665.c
 create mode 100644 drivers/media/video/mrstci/mrstov9665/ov9665.h

diff --git a/drivers/media/video/mrstci/mrstov9665/Kconfig 
b/drivers/media/video/mrstci/mrstov9665/Kconfig
new file mode 100644
index 000..ba9b692
--- /dev/null
+++ b/drivers/media/video/mrstci/mrstov9665/Kconfig
@@ -0,0 +1,9 @@
+config VIDEO_MRST_OV9665
+   tristate Moorestown OV9665 SoC Sensor
+   depends on I2C  VIDEO_MRST_ISP
+
+   ---help---
+ Say Y here if your platform support OV9665 SoC Sensor.
+
+ To compile this driver as a module, choose M here: the
+ module will be called mrstov9665.ko.
diff --git a/drivers/media/video/mrstci/mrstov9665/Makefile 
b/drivers/media/video/mrstci/mrstov9665/Makefile
new file mode 100644
index 000..871b6bf
--- /dev/null
+++ b/drivers/media/video/mrstci/mrstov9665/Makefile
@@ -0,0 +1,3 @@
+obj-$(CONFIG_VIDEO_MRST_OV9665) += mrstov9665.o
+
+EXTRA_CFLAGS   +=  -I$(src)/../include
diff --git a/drivers/media/video/mrstci/mrstov9665/mrstov9665.c 
b/drivers/media/video/mrstci/mrstov9665/mrstov9665.c
new file mode 100644
index 000..042f699
--- /dev/null
+++ b/drivers/media/video/mrstci/mrstov9665/mrstov9665.c
@@ -0,0 +1,710 @@
+/*
+ * Support for Moorestown Langwell Camera Imaging ISP subsystem.
+ *
+ * Copyright (c) 2009 Intel Corporation. All Rights Reserved.
+ *
+ * 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., 51 Franklin Street, Fifth Floor, Boston, MA
+ * 02110-1301, USA.
+ *
+ *
+ * Xiaolin Zhang xiaolin.zh...@intel.com
+ */
+
+#include linux/module.h
+#include linux/types.h
+#include linux/kernel.h
+#include linux/mm.h
+#include linux/string.h
+#include linux/errno.h
+#include linux/init.h
+#include linux/kmod.h
+#include linux/device.h
+#include linux/delay.h
+#include linux/fs.h
+#include linux/init.h
+#include linux/slab.h
+#include linux/delay.h
+#include linux/i2c.h
+#include linux/gpio.h
+#include linux/videodev2.h
+
+#include media/v4l2-device.h
+#include media/v4l2-chip-ident.h
+#include media/v4l2-i2c-drv.h
+
+#include ci_sensor_common.h
+#include ov9665.h
+
+static int mrstov9665_debug;
+module_param(mrstov9665_debug, int, 0644);
+MODULE_PARM_DESC(mrstov9665_debug, Debug level (0-1));
+
+#define dprintk(level, fmt, arg...) do {   \
+   if (mrstov9665_debug = level)  \
+   printk(KERN_DEBUG mrst...@%s:  fmt \n, \
+  __func__, ## arg); } \
+   while (0)
+
+#define eprintk(fmt, arg...)   \
+   printk(KERN_ERR mrst...@%s: line %d:  fmt \n,   \
+  __func__, __LINE__, ## arg);
+
+#define DBG_entering   dprintk(2, entering);
+#define DBG_leavingdprintk(2, leaving);
+#define DBG_line   dprintk(2,  line: %d, __LINE__);
+
+static inline struct ci_sensor_config *to_sensor_config(struct v4l2_subdev *sd)
+{
+   return container_of(sd, struct ci_sensor_config, sd);
+}
+
+static struct ov9665_format_struct {
+   __u8 *desc;
+   __u32 pixelformat;
+   struct regval_list *regs;
+} ov9665_formats[] = {
+   {
+   .desc   = YUYV 4:2:2,
+   .pixelformat= SENSOR_MODE_BT601,
+   .regs   = NULL,
+   },
+};
+#define N_OV9665_FMTS ARRAY_SIZE(ov9665_formats)
+
+static struct ov9665_res_struct {
+   __u8 *desc;
+   int res;
+   int width;
+   int height;
+   int fps;
+   bool used;
+   struct regval_list *regs;
+} ov9665_res[] = {
+   {
+   .desc   = SXGA,
+   .res= SENSOR_RES_SXGA,
+   

[PATCH v2 6/10] V4L2 patches for Intel Moorestown Camera Imaging Drivers

[Zhang, Xiaolin]

From 9b6d236769ebd30005c0160538df56f940b159b1 Mon Sep 17 00:00:00 2001
From: Xiaolin Zhang xiaolin.zh...@intel.com
Date: Sun, 28 Mar 2010 14:08:04 +0800
Subject: [PATCH 06/10] this patch is the 5mp camera (ov5630) sensor subdev 
driver for intel moorestown imaging.

Signed-off-by: Xiaolin Zhang xiaolin.zh...@intel.com
---
 drivers/media/video/mrstci/mrstov5630/Kconfig  |9 +
 drivers/media/video/mrstci/mrstov5630/Makefile |4 +
 drivers/media/video/mrstci/mrstov5630/ov5630.c |  832 
 drivers/media/video/mrstci/mrstov5630/ov5630.h |  635 ++
 4 files changed, 1480 insertions(+), 0 deletions(-)
 create mode 100644 drivers/media/video/mrstci/mrstov5630/Kconfig
 create mode 100644 drivers/media/video/mrstci/mrstov5630/Makefile
 create mode 100644 drivers/media/video/mrstci/mrstov5630/ov5630.c
 create mode 100644 drivers/media/video/mrstci/mrstov5630/ov5630.h

diff --git a/drivers/media/video/mrstci/mrstov5630/Kconfig 
b/drivers/media/video/mrstci/mrstov5630/Kconfig
new file mode 100644
index 000..a28ddc2
--- /dev/null
+++ b/drivers/media/video/mrstci/mrstov5630/Kconfig
@@ -0,0 +1,9 @@
+config VIDEO_MRST_OV5630
+   tristate Moorestown OV5630 RAW Sensor
+   depends on I2C  VIDEO_MRST_ISP
+
+   ---help---
+ Say Y here if your platform support OV5630 RAW Sensor.
+
+ To compile this driver as a module, choose M here: the
+ module will be called mrstov2650.ko.
diff --git a/drivers/media/video/mrstci/mrstov5630/Makefile 
b/drivers/media/video/mrstci/mrstov5630/Makefile
new file mode 100644
index 000..c67abff
--- /dev/null
+++ b/drivers/media/video/mrstci/mrstov5630/Makefile
@@ -0,0 +1,4 @@
+mrstov5630-objs= ov5630.o
+obj-$(CONFIG_VIDEO_MRST_OV5630) += mrstov5630.o
+
+EXTRA_CFLAGS   +=  -I$(src)/../include
diff --git a/drivers/media/video/mrstci/mrstov5630/ov5630.c 
b/drivers/media/video/mrstci/mrstov5630/ov5630.c
new file mode 100644
index 000..bf91e0b
--- /dev/null
+++ b/drivers/media/video/mrstci/mrstov5630/ov5630.c
@@ -0,0 +1,832 @@
+/*
+ * Support for Moorestown Langwell Camera Imaging ISP subsystem.
+ *
+ * Copyright (c) 2009 Intel Corporation. All Rights Reserved.
+ *
+ * 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., 51 Franklin Street, Fifth Floor, Boston, MA
+ * 02110-1301, USA.
+ *
+ *
+ * Xiaolin Zhang xiaolin.zh...@intel.com
+ */
+
+#include linux/module.h
+#include linux/types.h
+#include linux/kernel.h
+#include linux/mm.h
+#include linux/string.h
+#include linux/errno.h
+#include linux/init.h
+#include linux/kmod.h
+#include linux/device.h
+#include linux/delay.h
+#include linux/fs.h
+#include linux/init.h
+#include linux/slab.h
+#include linux/delay.h
+#include linux/i2c.h
+#include linux/gpio.h
+
+#include media/v4l2-device.h
+#include media/v4l2-chip-ident.h
+#include media/v4l2-i2c-drv.h
+
+#include ci_sensor_common.h
+#include ov5630.h
+
+static int mrstov5630_debug;
+module_param(mrstov5630_debug, int, 0644);
+MODULE_PARM_DESC(mrstov5630_debug, Debug level (0-1));
+
+#define dprintk(level, fmt, arg...) do {   \
+   if (mrstov5630_debug = level)  \
+   printk(KERN_DEBUG mrst...@%s:  fmt \n,  \
+  __func__, ## arg); } \
+   while (0)
+
+#define eprintk(fmt, arg...)   \
+   printk(KERN_ERR mrst...@%s: line %d:  fmt \n,   \
+  __func__, __LINE__, ## arg);
+
+#define DBG_entering   dprintk(2, entering);
+#define DBG_leavingdprintk(2, leaving);
+#define DBG_line   dprintk(2,  line: %d, __LINE__);
+
+static inline struct ci_sensor_config *to_sensor_config(struct v4l2_subdev *sd)
+{
+   return container_of(sd, struct ci_sensor_config, sd);
+}
+
+static struct ov5630_format_struct {
+   __u8 *desc;
+   __u32 pixelformat;
+   struct regval_list *regs;
+} ov5630_formats[] = {
+   {
+   .desc   = Raw RGB Bayer,
+   .pixelformat= SENSOR_MODE_BAYER,
+   .regs   = NULL,
+   },
+};
+#define N_OV5630_FMTS ARRAY_SIZE(ov5630_formats)
+
+static struct ov5630_res_struct {
+   __u8 *desc;
+   int res;
+   int width;
+   int height;
+   int fps;
+   bool used;
+   struct regval_list *regs;
+} ov5630_res[] = {
+   {
+   .desc   = QSXGA_PLUS4,
+   .res= SENSOR_RES_QXGA_PLUS,
+   

[PATCH v2 4/10] V4L2 patches for Intel Moorestown Camera Imaging Drivers

[Zhang, Xiaolin]

From f09b86fb073db95eaeefb1e9ffb4e448e6359bd3 Mon Sep 17 00:00:00 2001
From: Xiaolin Zhang xiaolin.zh...@intel.com
Date: Sun, 28 Mar 2010 14:01:01 +0800
Subject: [PATCH 04/10] this patch is 2mp camera (ov2650) sensor subdev driver 
for intel moorestown camera imaging.

Signed-off-by: Xiaolin Zhang xiaolin.zh...@intel.com
---
 drivers/media/video/mrstci/mrstov2650/Kconfig  |9 +
 drivers/media/video/mrstci/mrstov2650/Makefile |3 +
 drivers/media/video/mrstci/mrstov2650/mrstov2650.c |  772 
 drivers/media/video/mrstci/mrstov2650/ov2650.h |  717 ++
 4 files changed, 1501 insertions(+), 0 deletions(-)
 create mode 100644 drivers/media/video/mrstci/mrstov2650/Kconfig
 create mode 100644 drivers/media/video/mrstci/mrstov2650/Makefile
 create mode 100644 drivers/media/video/mrstci/mrstov2650/mrstov2650.c
 create mode 100644 drivers/media/video/mrstci/mrstov2650/ov2650.h

diff --git a/drivers/media/video/mrstci/mrstov2650/Kconfig 
b/drivers/media/video/mrstci/mrstov2650/Kconfig
new file mode 100644
index 000..d39d894
--- /dev/null
+++ b/drivers/media/video/mrstci/mrstov2650/Kconfig
@@ -0,0 +1,9 @@
+config VIDEO_MRST_OV2650
+   tristate Moorestown OV2650 SoC Sensor
+   depends on I2C  VIDEO_MRST_ISP
+
+   ---help---
+ Say Y here if your platform support OV2650 SoC Sensor.
+
+ To compile this driver as a module, choose M here: the
+ module will be called mrstov2650.ko.
diff --git a/drivers/media/video/mrstci/mrstov2650/Makefile 
b/drivers/media/video/mrstci/mrstov2650/Makefile
new file mode 100644
index 000..fb16d57
--- /dev/null
+++ b/drivers/media/video/mrstci/mrstov2650/Makefile
@@ -0,0 +1,3 @@
+obj-$(CONFIG_VIDEO_MRST_OV2650) += mrstov2650.o
+
+EXTRA_CFLAGS   +=  -I$(src)/../include
\ No newline at end of file
diff --git a/drivers/media/video/mrstci/mrstov2650/mrstov2650.c 
b/drivers/media/video/mrstci/mrstov2650/mrstov2650.c
new file mode 100644
index 000..84aee57
--- /dev/null
+++ b/drivers/media/video/mrstci/mrstov2650/mrstov2650.c
@@ -0,0 +1,772 @@
+/*
+ * Support for Moorestown Langwell Camera Imaging ISP subsystem.
+ *
+ * Copyright (c) 2009 Intel Corporation. All Rights Reserved.
+ *
+ * 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., 51 Franklin Street, Fifth Floor, Boston, MA
+ * 02110-1301, USA.
+ *
+ *
+ * Xiaolin Zhang xiaolin.zh...@intel.com
+ */
+
+#include linux/module.h
+#include linux/types.h
+#include linux/kernel.h
+#include linux/mm.h
+#include linux/string.h
+#include linux/errno.h
+#include linux/init.h
+#include linux/kmod.h
+#include linux/device.h
+#include linux/delay.h
+#include linux/fs.h
+#include linux/init.h
+#include linux/slab.h
+#include linux/delay.h
+#include linux/i2c.h
+#include linux/gpio.h
+#include linux/videodev2.h
+#include media/v4l2-device.h
+#include media/v4l2-chip-ident.h
+#include media/v4l2-i2c-drv.h
+
+#include ci_sensor_common.h
+#include ov2650.h
+
+static int mrstov2650_debug;
+module_param(mrstov2650_debug, int, 0644);
+MODULE_PARM_DESC(mrstov2650_debug, Debug level (0-1));
+
+#define dprintk(level, fmt, arg...) do {   \
+   if (mrstov2650_debug = level)  \
+   printk(KERN_DEBUG mrst...@%s:  fmt \n, \
+  __func__, ## arg); } \
+   while (0)
+
+#define eprintk(fmt, arg...)   \
+   printk(KERN_ERR mrst...@%s: line %d:  fmt \n,   \
+  __func__, __LINE__, ## arg);
+
+#define DBG_entering   dprintk(2, entering);
+#define DBG_leavingdprintk(2, leaving);
+#define DBG_line   dprintk(2,  line: %d, __LINE__);
+
+static inline struct ci_sensor_config *to_sensor_config(struct v4l2_subdev *sd)
+{
+   return container_of(sd, struct ci_sensor_config, sd);
+}
+
+static struct ov2650_format_struct {
+   __u8 *desc;
+   __u32 pixelformat;
+   struct regval_list *regs;
+} ov2650_formats[] = {
+   {
+   .desc   = YUYV 4:2:2,
+   .pixelformat= SENSOR_MODE_BT601,
+   .regs   = NULL,
+   },
+};
+#define N_OV2650_FMTS ARRAY_SIZE(ov2650_formats)
+
+static struct ov2650_res_struct {
+   __u8 *desc;
+   int res;
+   int width;
+   int height;
+   int fps;
+   bool used;
+   struct regval_list *regs;
+} ov2650_res[] = {
+   {
+   .desc   = UXGA,
+   .res= 

[PATCH v2 7/10] V4L2 patches for Intel Moorestown Camera Imaging Drivers

[Zhang, Xiaolin]

From ffd8b7e0f07391e9d44bd0c93390362fca0e6a2f Mon Sep 17 00:00:00 2001
From: Xiaolin Zhang xiaolin.zh...@intel.com
Date: Sun, 28 Mar 2010 14:12:41 +0800
Subject: [PATCH 07/10] this patch is the 5mp camera (ov5630) sensor lens subdev 
driver for intel moorestown camera imaging.

Signed-off-by: Xiaolin Zhang xiaolin.zh...@intel.com
---
 .../media/video/mrstci/mrstov5630_motor/Kconfig|9 +
 .../media/video/mrstci/mrstov5630_motor/Makefile   |3 +
 .../mrstci/mrstov5630_motor/mrstov5630_motor.c |  373 
 .../video/mrstci/mrstov5630_motor/ov5630_motor.h   |   89 +
 4 files changed, 474 insertions(+), 0 deletions(-)
 create mode 100644 drivers/media/video/mrstci/mrstov5630_motor/Kconfig
 create mode 100644 drivers/media/video/mrstci/mrstov5630_motor/Makefile
 create mode 100644 
drivers/media/video/mrstci/mrstov5630_motor/mrstov5630_motor.c
 create mode 100644 drivers/media/video/mrstci/mrstov5630_motor/ov5630_motor.h

diff --git a/drivers/media/video/mrstci/mrstov5630_motor/Kconfig 
b/drivers/media/video/mrstci/mrstov5630_motor/Kconfig
new file mode 100644
index 000..b6dcf62
--- /dev/null
+++ b/drivers/media/video/mrstci/mrstov5630_motor/Kconfig
@@ -0,0 +1,9 @@
+config VIDEO_MRST_OV5630_MOTOR
+   tristate Moorestown OV5630 motor
+   depends on I2C  VIDEO_MRST_ISP  VIDEO_MRST_OV5630
+
+   ---help---
+ Say Y here if your platform support OV5630 motor
+
+ To compile this driver as a module, choose M here: the
+ module will be called mrstov2650.ko.
diff --git a/drivers/media/video/mrstci/mrstov5630_motor/Makefile 
b/drivers/media/video/mrstci/mrstov5630_motor/Makefile
new file mode 100644
index 000..056b2a6
--- /dev/null
+++ b/drivers/media/video/mrstci/mrstov5630_motor/Makefile
@@ -0,0 +1,3 @@
+obj-$(CONFIG_VIDEO_MRST_OV2650) += mrstov5630_motor.o
+
+EXTRA_CFLAGS   +=  -I$(src)/../include
diff --git a/drivers/media/video/mrstci/mrstov5630_motor/mrstov5630_motor.c 
b/drivers/media/video/mrstci/mrstov5630_motor/mrstov5630_motor.c
new file mode 100644
index 000..ef26985
--- /dev/null
+++ b/drivers/media/video/mrstci/mrstov5630_motor/mrstov5630_motor.c
@@ -0,0 +1,373 @@
+/*
+ * Support for Moorestown Langwell Camera Imaging ISP subsystem.
+ *
+ * Copyright (c) 2009 Intel Corporation. All Rights Reserved.
+ *
+ * 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., 51 Franklin Street, Fifth Floor, Boston, MA
+ * 02110-1301, USA.
+ *
+ *
+ * Xiaolin Zhang xiaolin.zh...@intel.com
+ */
+
+#include linux/module.h
+#include linux/types.h
+#include linux/kernel.h
+#include linux/mm.h
+#include linux/string.h
+#include linux/errno.h
+#include linux/init.h
+#include linux/kmod.h
+#include linux/device.h
+#include linux/delay.h
+#include linux/fs.h
+#include linux/init.h
+#include linux/slab.h
+#include linux/delay.h
+#include linux/i2c.h
+#include linux/gpio.h
+
+#include media/v4l2-device.h
+#include media/v4l2-chip-ident.h
+#include media/v4l2-i2c-drv.h
+
+#include ov5630_motor.h
+
+static int mrstov5630_motor_debug;
+module_param(mrstov5630_motor_debug, int, 0644);
+MODULE_PARM_DESC(mrstov5630_motor_debug, Debug level (0-1));
+
+#define dprintk(level, fmt, arg...) do {   \
+   if (mrstov5630_motor_debug = level)\
+   printk(KERN_DEBUG mrst...@%s:  fmt \n, \
+  __func__, ## arg); } \
+   while (0)
+
+#define eprintk(fmt, arg...)   \
+   printk(KERN_ERR mrst...@%s: line %d:  fmt \n,   \
+  __func__, __LINE__, ## arg);
+
+#define DBG_entering   dprintk(2, entering);
+#define DBG_leavingdprintk(2, leaving);
+#define DBG_line   dprintk(2,  line: %d, __LINE__);
+
+static inline struct ov5630_motor *to_motor_config(struct v4l2_subdev *sd)
+{
+   return container_of(sd, struct ov5630_motor, sd);
+}
+
+static int motor_read(struct i2c_client *c, u16 *reg)
+{
+   int ret;
+   struct i2c_msg msg;
+   u8 msgbuf[2];
+
+   msgbuf[0] = 0;
+   msgbuf[1] = 0;
+
+   memset(msg, 0, sizeof(msg));
+   msg.addr = c-addr;
+   msg.buf = msgbuf;
+   msg.len = 2;
+   msg.flags = I2C_M_RD;
+
+   ret = i2c_transfer(c-adapter, msg, 1);
+   *reg = (msgbuf[0]  8 | msgbuf[1]);
+
+   ret = (ret == 1) ? 0 : -1;
+   return ret;
+}
+
+static int motor_write(struct i2c_client *c, u16 reg)
+{
+   int ret;
+   struct i2c_msg msg;
+   u8 

[PATCH v2 8/10] V4L2 patches for Intel Moorestown Camera Imaging Drivers

[Zhang, Xiaolin]

From 7ecf6eb90a22901c6550a2392967d911c611690c Mon Sep 17 00:00:00 2001
From: Xiaolin Zhang xiaolin.zh...@intel.com
Date: Sun, 28 Mar 2010 14:14:29 +0800
Subject: [PATCH 08/10] this patch is the 5mp camera (s5k4e1) sensor subdev 
driver for intel moorestown camera imaging.

Signed-off-by: Xiaolin Zhang xiaolin.zh...@intel.com
---
 drivers/media/video/mrstci/mrsts5k4e1/Kconfig  |9 +
 drivers/media/video/mrstci/mrsts5k4e1/Makefile |3 +
 drivers/media/video/mrstci/mrsts5k4e1/mrsts5k4e1.c |  861 
 drivers/media/video/mrstci/mrsts5k4e1/mrsts5k4e1.h |  573 +
 4 files changed, 1446 insertions(+), 0 deletions(-)
 create mode 100644 drivers/media/video/mrstci/mrsts5k4e1/Kconfig
 create mode 100644 drivers/media/video/mrstci/mrsts5k4e1/Makefile
 create mode 100644 drivers/media/video/mrstci/mrsts5k4e1/mrsts5k4e1.c
 create mode 100644 drivers/media/video/mrstci/mrsts5k4e1/mrsts5k4e1.h

diff --git a/drivers/media/video/mrstci/mrsts5k4e1/Kconfig 
b/drivers/media/video/mrstci/mrsts5k4e1/Kconfig
new file mode 100644
index 000..7dee787
--- /dev/null
+++ b/drivers/media/video/mrstci/mrsts5k4e1/Kconfig
@@ -0,0 +1,9 @@
+config VIDEO_MRST_S5K4E1
+   tristate Moorestown s5k4e1 RAW Sensor
+   depends on I2C  VIDEO_MRST_ISP
+
+   ---help---
+ Say Y here if your platform support s5k4e1 RAW Sensor.
+
+ To compile this driver as a module, choose M here: the
+ module will be called mrstov2650.ko.
diff --git a/drivers/media/video/mrstci/mrsts5k4e1/Makefile 
b/drivers/media/video/mrstci/mrsts5k4e1/Makefile
new file mode 100644
index 000..8733fa8
--- /dev/null
+++ b/drivers/media/video/mrstci/mrsts5k4e1/Makefile
@@ -0,0 +1,3 @@
+obj-$(CONFIG_VIDEO_MRST_S5K4E1) += mrsts5k4e1.o
+
+EXTRA_CFLAGS   +=  -I$(src)/../include
diff --git a/drivers/media/video/mrstci/mrsts5k4e1/mrsts5k4e1.c 
b/drivers/media/video/mrstci/mrsts5k4e1/mrsts5k4e1.c
new file mode 100644
index 000..1c31872
--- /dev/null
+++ b/drivers/media/video/mrstci/mrsts5k4e1/mrsts5k4e1.c
@@ -0,0 +1,861 @@
+/*
+ * Support for Moorestown Langwell Camera Imaging ISP subsystem.
+ *
+ * Copyright (c) 2009 Intel Corporation. All Rights Reserved.
+ *
+ * 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., 51 Franklin Street, Fifth Floor, Boston, MA
+ * 02110-1301, USA.
+ *
+ *
+ * Xiaolin Zhang xiaolin.zh...@intel.com
+ */
+
+#include linux/module.h
+#include linux/types.h
+#include linux/kernel.h
+#include linux/mm.h
+#include linux/string.h
+#include linux/errno.h
+#include linux/init.h
+#include linux/kmod.h
+#include linux/device.h
+#include linux/delay.h
+#include linux/fs.h
+#include linux/init.h
+#include linux/slab.h
+#include linux/delay.h
+#include linux/i2c.h
+#include linux/gpio.h
+
+#include media/v4l2-device.h
+#include media/v4l2-chip-ident.h
+#include media/v4l2-i2c-drv.h
+
+#include ci_sensor_common.h
+#include mrsts5k4e1.h
+
+static int s5k4e1_debug;
+module_param(s5k4e1_debug, int, 0644);
+MODULE_PARM_DESC(s5k4e1_debug, Debug level (0-1));
+
+#define dprintk(level, fmt, arg...) \
+   do { \
+   if (s5k4e1_debug = level) \
+   printk(KERN_DEBUG mrst...@%s:  fmt \n, \
+  __func__, ## arg);\
+   } while (0)
+
+#define eprintk(fmt, arg...)   \
+   printk(KERN_ERR mrst...@%s: fmt \n, \
+  __func__, ## arg);
+
+#define DBG_entering   dprintk(1, entering);
+#define DBG_leavingdprintk(1, leaving);
+#define DBG_line   dprintk(1,  line: %d, __LINE__);
+
+static inline struct ci_sensor_config *to_sensor_config(struct v4l2_subdev *sd)
+{
+   return container_of(sd, struct ci_sensor_config, sd);
+}
+
+static struct s5k4e1_format_struct {
+   __u8 *desc;
+   __u32 pixelformat;
+   struct regval_list *regs;
+} s5k4e1_formats[] = {
+   {
+   .desc   = Raw RGB Bayer,
+   .pixelformat= SENSOR_MODE_MIPI,
+   .regs   = NULL,
+   },
+};
+#define N_S5K4E1_FMTS ARRAY_SIZE(s5k4e1_formats)
+
+static struct s5k4e1_res_struct {
+   __u8 *desc;
+   int res;
+   int width;
+   int height;
+   int fps;
+   bool used;
+   struct regval_list *regs;
+} s5k4e1_res[] = {
+   {
+   .desc   = QSXGA_PLUS4,
+   .res= SENSOR_RES_QXGA_PLUS,
+   .width  = 2592,
+   .height = 1944,
+

[PATCH v2 10/10] V4L2 patches for Intel Moorestown Camera Imaging Drivers

[Zhang, Xiaolin]

From 166299cfa17bb5e16613eff962cce841d2c15f0f Mon Sep 17 00:00:00 2001
From: Xiaolin Zhang xiaolin.zh...@intel.com
Date: Sun, 28 Mar 2010 14:19:12 +0800
Subject: [PATCH 10/10] this patch is the make/kconfig files changes to enable 
the camera drivers for
 intel moorestown platform.

Signed-off-by: Xiaolin Zhang xiaolin.zh...@intel.com
---
 drivers/media/video/Kconfig |1 +
 drivers/media/video/Makefile|9 +
 drivers/media/video/mrstci/Kconfig  |   26 ++
 drivers/media/video/mrstci/Makefile |8 
 4 files changed, 44 insertions(+), 0 deletions(-)
 create mode 100644 drivers/media/video/mrstci/Kconfig
 create mode 100644 drivers/media/video/mrstci/Makefile

diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index dcf9fa9..1b3726f 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -954,4 +954,5 @@ config USB_S2255
  This driver can be compiled as a module, called s2255drv.
 
 endif # V4L_USB_DRIVERS
+source drivers/media/video/mrstci/Kconfig
 endif # VIDEO_CAPTURE_DRIVERS
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index 9f2e321..6a4b5ff 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -160,6 +160,15 @@ obj-$(CONFIG_USB_VIDEO_CLASS)  += uvc/
 
 obj-$(CONFIG_VIDEO_IR_I2C)  += ir-kbd-i2c.o
 
+obj-$(CONFIG_VIDEO_MRST_OV2650) += mrstci/mrstov2650/
+obj-$(CONFIG_VIDEO_MRST_OV5630) += mrstci/mrstov5630/
+obj-$(CONFIG_VIDEO_MRST_OV5630_MOTOR) += mrstci/mrstov5630_motor/
+obj-$(CONFIG_VIDEO_MRST_S5K4E1) += mrstci/mrsts5k4e1/
+obj-$(CONFIG_VIDEO_MRST_S5K4E1_MOTOR) += mrstci/mrsts5k4e1_motor/
+obj-$(CONFIG_VIDEO_MRST_OV9665) += mrstci/mrstov9665/
+obj-$(CONFIG_VIDEO_MRST_FLASH) += mrstci/mrstflash/
+obj-$(CONFIG_VIDEO_MRST_ISP) += mrstci/mrstisp/
+
 EXTRA_CFLAGS += -Idrivers/media/dvb/dvb-core
 EXTRA_CFLAGS += -Idrivers/media/dvb/frontends
 EXTRA_CFLAGS += -Idrivers/media/common/tuners
diff --git a/drivers/media/video/mrstci/Kconfig 
b/drivers/media/video/mrstci/Kconfig
new file mode 100644
index 000..9ac7065
--- /dev/null
+++ b/drivers/media/video/mrstci/Kconfig
@@ -0,0 +1,26 @@
+menuconfig VIDEO_MRSTCI
+bool Moorestown Langwell Camera Imaging Subsystem support
+depends on VIDEO_V4L2
+default y
+
+---help---
+   Say Y here to enable selecting the Intel Moorestown Langwell Camera 
Imaging Subsystem for webcams.
+
+if VIDEO_MRSTCI  VIDEO_V4L2
+
+source drivers/media/video/mrstci/mrstisp/Kconfig
+
+source drivers/media/video/mrstci/mrstov5630/Kconfig
+source drivers/media/video/mrstci/mrstov5630_motor/Kconfig
+
+source drivers/media/video/mrstci/mrsts5k4e1/Kconfig
+source drivers/media/video/mrstci/mrsts5k4e1_motor/Kconfig
+
+source drivers/media/video/mrstci/mrstflash/Kconfig
+
+source drivers/media/video/mrstci/mrstov2650/Kconfig
+
+source drivers/media/video/mrstci/mrstov9665/Kconfig
+
+endif # VIDEO_MRSTCI
+
diff --git a/drivers/media/video/mrstci/Makefile 
b/drivers/media/video/mrstci/Makefile
new file mode 100644
index 000..9d3449e
--- /dev/null
+++ b/drivers/media/video/mrstci/Makefile
@@ -0,0 +1,8 @@
+obj-$(CONFIG_VIDEO_MRST_OV2650) += mrstov2650/
+obj-$(CONFIG_VIDEO_MRST_OV9665) += mrstov9665/
+obj-$(CONFIG_VIDEO_MRST_OV5630) += mrstov5630/
+obj-$(CONFIG_VIDEO_MRST_OV5630_MOTOR) += mrstov5630_motor/
+obj-$(CONFIG_VIDEO_MRST_S5K4E1) += mrsts5k4e1/
+obj-$(CONFIG_VIDEO_MRST_S5K4E1_MOTOR) += mrsts5k4e1_motor/
+obj-$(CONFIG_VIDEO_MRST_FLASH) += mrstflash/
+obj-$(CONFIG_VIDEO_MRST_ISP) += mrstisp/
-- 
1.6.3.2

--
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 0/10] V4L2 patches for Intel Moorestown Camera Imaging Drivers

[Hans Verkuil]

Hi Xiaolin!

Here are a few comments based on a first read-through.

First of all, patch 2/10 did not seem to make it to the list for some reason.
Because of that I'm deferring reviewing patches 1/10 and (of course) 2/10.

The other patches for the i2c devices all have the same problems, so I will
only review one and you can apply the comments made there to all the others.

A general comment I have is that I think there is too much debugging code.
Creating good debug code is an art. In my experience things like DBG_entering
and DBG_leaving just clutter the code and are pretty useless once the initial
implementation phase is finished. The trick is to have just enough debug or
logging available so that you can deduce the path taken by the driver.

What I found to be very useful as well is to implement VIDIOC_LOG_STATUS to
get a full status overview of the various (sub)devices at a given moment.

On Sunday 28 March 2010 09:46:35 Zhang, Xiaolin wrote:
 Hi, 
 
 Here is the second version of V4L2 camera sensors and ISP driver patch set to 
 support the Intel Moorestown camera imaging subsystem. 
 
 The Camera Imaging interface (CI) in Moorestown is responsible for still 
 image and video capture which can handle demosaicing, color synthesis, 
 filtering, image enhancement, etc functionalities with a integrated JPEG 
 encode. 
 Intel Moorestown platform can support either a single camera or dual cameras. 
 If a platform with dual camera will have one low resolution camera on the 
 same side as this display for video conference and a high resolution camera 
 on the opposite side the display for high quality still image capture.
 
 The driver framework is updated to the v4l2 sub-dev and video buffer 
 framework, in this set of driver patches, I will submit the 10 patches to 
 enable the camera subsystem with the device drivers for ISP HW and 4 cameras 
 module (two SoCs: 1.3MP - Omnivision 9665, 2MP - Omnivison 2650 and two RAWs: 
 5MP - Omnivision 5630, 5MP - Samsong s5k4e1).
 
 1. Intel Moorestown ISP driver - header files.

Just a single comment on these files here: I see new PIXFMT defines in a
Moorestown-specific header: just add these to videodev2.h.

Regards,

Hans

 2. Intel Moorestown ISP driver - V4L2 implementation including hardware 
 component functionality  
 3. Intel Moorestown flash sub-dev driver
 4. Intel Moorestown 2MP camera (ov2650) sensor subdev driver.
 5. Intel Moorestown 1.3MP camera (ov9665) sensor subdev driver.
 6. Intel Moorestown 5MP camera (ov5630) sensor subdev driver.
 7. Intel Moorestown 5MP camera (ov5630) lens subdev driver.
 8. Intel Moorestown 5MP camera (s5k4e1) sensor subdev driver.
 9. Intel Moorestown 5MP camera (s5k4e1) lens subdev driver
 10. make/kconfig files change to enable camera drivers for intel Moorestown 
 platform.
 
 Please review them and comments are welcome as always. 
 
 Regards,
 
 Xiaolin
 xiaolin.zh...@intel.com
 --
 To unsubscribe from this list: send the line unsubscribe linux-media in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 
 

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

Re: [PATCH v2 3/10] V4L2 patches for Intel Moorestown Camera Imaging Drivers

[Hans Verkuil]

Hi Xiaolin!

I found a small memory leak in this flash driver:

On Sunday 28 March 2010 09:47:21 Zhang, Xiaolin wrote:
 +static int flash_remove(struct i2c_client *client)
 +{
 + struct v4l2_subdev *sd = i2c_get_clientdata(client);
 +
 + v4l2_device_unregister_subdev(sd);

Missing kfree(sd).

 +
 + return 0;
 +}

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

Re: [PATCH v2 4/10] V4L2 patches for Intel Moorestown Camera Imaging Drivers

[Hans Verkuil]

Hi Xiaolin!

The comments I make here also apply to all the other subdev drivers you posted.

On Sunday 28 March 2010 09:47:28 Zhang, Xiaolin wrote:
 From f09b86fb073db95eaeefb1e9ffb4e448e6359bd3 Mon Sep 17 00:00:00 2001
 From: Xiaolin Zhang xiaolin.zh...@intel.com
 Date: Sun, 28 Mar 2010 14:01:01 +0800
 Subject: [PATCH 04/10] this patch is 2mp camera (ov2650) sensor subdev driver 
 for intel moorestown camera imaging.
 
 Signed-off-by: Xiaolin Zhang xiaolin.zh...@intel.com
 ---
  drivers/media/video/mrstci/mrstov2650/Kconfig  |9 +
  drivers/media/video/mrstci/mrstov2650/Makefile |3 +
  drivers/media/video/mrstci/mrstov2650/mrstov2650.c |  772 
 
  drivers/media/video/mrstci/mrstov2650/ov2650.h |  717 ++
  4 files changed, 1501 insertions(+), 0 deletions(-)
  create mode 100644 drivers/media/video/mrstci/mrstov2650/Kconfig
  create mode 100644 drivers/media/video/mrstci/mrstov2650/Makefile
  create mode 100644 drivers/media/video/mrstci/mrstov2650/mrstov2650.c
  create mode 100644 drivers/media/video/mrstci/mrstov2650/ov2650.h
 
 diff --git a/drivers/media/video/mrstci/mrstov2650/Kconfig 
 b/drivers/media/video/mrstci/mrstov2650/Kconfig
 new file mode 100644
 index 000..d39d894
 --- /dev/null
 +++ b/drivers/media/video/mrstci/mrstov2650/Kconfig
 @@ -0,0 +1,9 @@
 +config VIDEO_MRST_OV2650
 +   tristate Moorestown OV2650 SoC Sensor
 +   depends on I2C  VIDEO_MRST_ISP

These i2c devices are not an integral part of Moorestown, are they? These are
i2c devices that can also be found in other products. So they should not depend
on Moorestown and the drivers should be placed in drivers/media/video and any
references to Moorestown should be removed.

 +
 +   ---help---
 + Say Y here if your platform support OV2650 SoC Sensor.
 +
 + To compile this driver as a module, choose M here: the
 + module will be called mrstov2650.ko.
 diff --git a/drivers/media/video/mrstci/mrstov2650/Makefile 
 b/drivers/media/video/mrstci/mrstov2650/Makefile
 new file mode 100644
 index 000..fb16d57
 --- /dev/null
 +++ b/drivers/media/video/mrstci/mrstov2650/Makefile
 @@ -0,0 +1,3 @@
 +obj-$(CONFIG_VIDEO_MRST_OV2650) += mrstov2650.o
 +
 +EXTRA_CFLAGS   +=  -I$(src)/../include
 \ No newline at end of file
 diff --git a/drivers/media/video/mrstci/mrstov2650/mrstov2650.c 
 b/drivers/media/video/mrstci/mrstov2650/mrstov2650.c
 new file mode 100644
 index 000..84aee57
 --- /dev/null
 +++ b/drivers/media/video/mrstci/mrstov2650/mrstov2650.c
 @@ -0,0 +1,772 @@
 +/*
 + * Support for Moorestown Langwell Camera Imaging ISP subsystem.
 + *
 + * Copyright (c) 2009 Intel Corporation. All Rights Reserved.
 + *
 + * 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., 51 Franklin Street, Fifth Floor, Boston, MA
 + * 02110-1301, USA.
 + *
 + *
 + * Xiaolin Zhang xiaolin.zh...@intel.com
 + */
 +
 +#include linux/module.h
 +#include linux/types.h
 +#include linux/kernel.h
 +#include linux/mm.h
 +#include linux/string.h
 +#include linux/errno.h
 +#include linux/init.h
 +#include linux/kmod.h
 +#include linux/device.h
 +#include linux/delay.h
 +#include linux/fs.h
 +#include linux/init.h
 +#include linux/slab.h
 +#include linux/delay.h
 +#include linux/i2c.h
 +#include linux/gpio.h

Please prune this list of includes. Things like delay, gpio, slab, fs and
no doubt more are not needed.

 +#include linux/videodev2.h
 +#include media/v4l2-device.h
 +#include media/v4l2-chip-ident.h
 +#include media/v4l2-i2c-drv.h

Don't use this header! It is for backwards compatibility of older i2c drivers
and should not be used with modern drivers. See for example tvp514x.c on how
to implement this without using v4l2-i2c-drv.h.

 +
 +#include ci_sensor_common.h
 +#include ov2650.h
 +
 +static int mrstov2650_debug;
 +module_param(mrstov2650_debug, int, 0644);
 +MODULE_PARM_DESC(mrstov2650_debug, Debug level (0-1));
 +
 +#define dprintk(level, fmt, arg...) do {   \
 +   if (mrstov2650_debug = level)  \
 +   printk(KERN_DEBUG mrst...@%s:  fmt \n, \
 +  __func__, ## arg); } \
 +   while (0)
 +
 +#define eprintk(fmt, arg...)   \
 +   printk(KERN_ERR mrst...@%s: line %d:  fmt \n,   \
 +  __func__, __LINE__, ## arg);
 +
 +#define DBG_entering   dprintk(2, entering);
 +#define DBG_leavingdprintk(2, leaving);

[GIT PATCHES FOR 2.6.35] saa7134 empress improvements

[Hans Verkuil]

The following changes since commit 942ab4762505a51a7a433a7608ba5d3eed6e4f8b:
  Jean Delvare (1):
V4L/DVB: saa7134: Fix IR support of some ASUS TV-FM 7135 variants

are available in the git repository at:

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

Hans Verkuil (2):
  saa7134/saa6752hs: improve saa6752hs initialization sequence
  saa7134-empress: enable the saa6752hs at the right places

 drivers/media/video/saa7134/saa6752hs.c   |   21 +++--
 drivers/media/video/saa7134/saa7134-core.c|   18 +--
 drivers/media/video/saa7134/saa7134-empress.c |   39 -
 include/media/saa6752hs.h |   15 ++
 4 files changed, 61 insertions(+), 32 deletions(-)

Tested with the Behold TV M6 card.

These changes will make it easier for Dmitri to implement support for the
new uPD61151 encoder.

There are still ugly bits in this code. For example, there is really no
reason why the MPEG video device node cannot be opened multiple times.

Regards,

Hans

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

What would be a good time to move subdev drivers to a subdev directory?

[Hans Verkuil]

Hi Mauro,

Currently drivers/media/video is a mix of subdev drivers and bridge/platform
drivers. I think it would be good to create a drivers/media/subdev directory
where subdev drivers can go.

We discussed in the past whether we should have categories for audio subdevs,
video subdevs, etc. but I think that will cause problems, especially with
future multifunction devices.

What is your opinion on this, and what would be a good time to start moving
drivers?

Regards,

Hans

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

Hauppauge WinTV HVR-900H

[George Tellalov]

Hello linux-media,

I've recently bought an HVR-900H usb hybrid tuner (marketed as 900-without-h)
and discovered that it's been unsupported for a while now. Nevertheless
some work is being done there:
http://www.mail-archive.com/linux-media@vger.kernel.org/msg16498.html
I've tried the patch (with linux 2.6.32) and I got as far as the firmware
being uploaded, but when I tried playing some TV it crashed the kernel.
I'm willing to help speeding up the driver development, so I was wondering if
there's anything I can start with (like testing). Hopefully I'll be able to do
some development later on, but I've got a lot of reading ahead before this could
happen.

Oh, yes - the device id is 2040:6600.

Regards
George
--
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] video/au0828: off by one bug

[Dan Carpenter]

The AUVI_INPUT(tmp) macro uses tmp as an index of an array with
AU0828_MAX_INPUT elements.

Signed-off-by: Dan Carpenter erro...@gmail.com

diff --git a/drivers/media/video/au0828/au0828-video.c 
b/drivers/media/video/au0828/au0828-video.c
index dc67bc4..19a5773 100644
--- a/drivers/media/video/au0828/au0828-video.c
+++ b/drivers/media/video/au0828/au0828-video.c
@@ -1104,7 +1104,7 @@ static int vidioc_enum_input(struct file *file, void 
*priv,
 
tmp = input-index;
 
-   if (tmp  AU0828_MAX_INPUT)
+   if (tmp = AU0828_MAX_INPUT)
return -EINVAL;
if (AUVI_INPUT(tmp).type == 0)
return -EINVAL;
--
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] video/s255drv: cleanup. remove uneeded NULL check

[Dan Carpenter]

dev can never be NULL there so there is no need to check it.
Also I made a couple of white space changes to the declaration of dev.

This eliminates a smatch warning about checking for NULL after a
dereference.

Signed-off-by: Dan Carpenter erro...@gmail.com

diff --git a/drivers/media/video/s2255drv.c b/drivers/media/video/s2255drv.c
index fb742f1..e70af5d 100644
--- a/drivers/media/video/s2255drv.c
+++ b/drivers/media/video/s2255drv.c
@@ -2582,8 +2582,9 @@ error:
 /* disconnect routine. when board is removed physically or with rmmod */
 static void s2255_disconnect(struct usb_interface *interface)
 {
-   struct s2255_dev *dev = NULL;
+   struct s2255_dev *dev;
int i;
+
dprintk(1, s2255: disconnect interface %p\n, interface);
dev = usb_get_intfdata(interface);
 
@@ -2602,11 +2603,9 @@ static void s2255_disconnect(struct usb_interface 
*interface)
usb_set_intfdata(interface, NULL);
mutex_unlock(dev-open_lock);
 
-   if (dev) {
-   kref_put(dev-kref, s2255_destroy);
-   dprintk(1, s2255drv: disconnect\n);
-   dev_info(interface-dev, s2255usb now disconnected\n);
-   }
+   kref_put(dev-kref, s2255_destroy);
+   dprintk(1, s2255drv: disconnect\n);
+   dev_info(interface-dev, s2255usb now disconnected\n);
 }
 
 static struct usb_driver s2255_driver = {
--
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] video/cx231xx: cleanup. remove unneed null checks

[Dan Carpenter]

dev is never NULL here so there is no need to check.

Signed-off-by: Dan Carpenter erro...@gmail.com

diff --git a/drivers/media/video/cx231xx/cx231xx-core.c 
b/drivers/media/video/cx231xx/cx231xx-core.c
index 4a60dfb..866fb12 100644
--- a/drivers/media/video/cx231xx/cx231xx-core.c
+++ b/drivers/media/video/cx231xx/cx231xx-core.c
@@ -95,10 +95,9 @@ int cx231xx_register_extension(struct cx231xx_ops *ops)
mutex_lock(cx231xx_devlist_mutex);
mutex_lock(cx231xx_extension_devlist_lock);
list_add_tail(ops-next, cx231xx_extension_devlist);
-   list_for_each_entry(dev, cx231xx_devlist, devlist) {
-   if (dev)
-   ops-init(dev);
-   }
+   list_for_each_entry(dev, cx231xx_devlist, devlist)
+   ops-init(dev);
+
printk(KERN_INFO DRIVER_NAME : %s initialized\n, ops-name);
mutex_unlock(cx231xx_extension_devlist_lock);
mutex_unlock(cx231xx_devlist_mutex);
@@ -111,10 +110,8 @@ void cx231xx_unregister_extension(struct cx231xx_ops *ops)
struct cx231xx *dev = NULL;
 
mutex_lock(cx231xx_devlist_mutex);
-   list_for_each_entry(dev, cx231xx_devlist, devlist) {
-   if (dev)
-   ops-fini(dev);
-   }
+   list_for_each_entry(dev, cx231xx_devlist, devlist)
+   ops-fini(dev);
 
mutex_lock(cx231xx_extension_devlist_lock);
printk(KERN_INFO DRIVER_NAME : %s removed\n, ops-name);
--
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 0/10] V4L2 patches for Intel Moorestown Camera Imaging Drivers

[Zhang, Xiaolin]

Hi Hans,

Thank you comment. I will try to figure out why patch 2/10 is missing. maybe it 
is a little bit large. I will split it two more patches and resubmit again.

BRs
Xiaolin

-Original Message-
From: Hans Verkuil [mailto:hverk...@xs4all.nl] 
Sent: Sunday, March 28, 2010 4:31 PM
To: Zhang, Xiaolin
Cc: linux-media@vger.kernel.org; Zhu, Daniel; Yu, Jinlu; Wang, Wen W; Huang, 
Kai; Hu, Gang A; Ba, Zheng
Subject: Re: [PATCH v2 0/10] V4L2 patches for Intel Moorestown Camera Imaging 
Drivers

Hi Xiaolin!

Here are a few comments based on a first read-through.

First of all, patch 2/10 did not seem to make it to the list for some reason.
Because of that I'm deferring reviewing patches 1/10 and (of course) 2/10.

The other patches for the i2c devices all have the same problems, so I will
only review one and you can apply the comments made there to all the others.

A general comment I have is that I think there is too much debugging code.
Creating good debug code is an art. In my experience things like DBG_entering
and DBG_leaving just clutter the code and are pretty useless once the initial
implementation phase is finished. The trick is to have just enough debug or
logging available so that you can deduce the path taken by the driver.

What I found to be very useful as well is to implement VIDIOC_LOG_STATUS to
get a full status overview of the various (sub)devices at a given moment.

On Sunday 28 March 2010 09:46:35 Zhang, Xiaolin wrote:
 Hi, 
 
 Here is the second version of V4L2 camera sensors and ISP driver patch set to 
 support the Intel Moorestown camera imaging subsystem. 
 
 The Camera Imaging interface (CI) in Moorestown is responsible for still 
 image and video capture which can handle demosaicing, color synthesis, 
 filtering, image enhancement, etc functionalities with a integrated JPEG 
 encode. 
 Intel Moorestown platform can support either a single camera or dual cameras. 
 If a platform with dual camera will have one low resolution camera on the 
 same side as this display for video conference and a high resolution camera 
 on the opposite side the display for high quality still image capture.
 
 The driver framework is updated to the v4l2 sub-dev and video buffer 
 framework, in this set of driver patches, I will submit the 10 patches to 
 enable the camera subsystem with the device drivers for ISP HW and 4 cameras 
 module (two SoCs: 1.3MP - Omnivision 9665, 2MP - Omnivison 2650 and two RAWs: 
 5MP - Omnivision 5630, 5MP - Samsong s5k4e1).
 
 1. Intel Moorestown ISP driver - header files.

Just a single comment on these files here: I see new PIXFMT defines in a
Moorestown-specific header: just add these to videodev2.h.

Regards,

Hans

 2. Intel Moorestown ISP driver - V4L2 implementation including hardware 
 component functionality  
 3. Intel Moorestown flash sub-dev driver
 4. Intel Moorestown 2MP camera (ov2650) sensor subdev driver.
 5. Intel Moorestown 1.3MP camera (ov9665) sensor subdev driver.
 6. Intel Moorestown 5MP camera (ov5630) sensor subdev driver.
 7. Intel Moorestown 5MP camera (ov5630) lens subdev driver.
 8. Intel Moorestown 5MP camera (s5k4e1) sensor subdev driver.
 9. Intel Moorestown 5MP camera (s5k4e1) lens subdev driver
 10. make/kconfig files change to enable camera drivers for intel Moorestown 
 platform.
 
 Please review them and comments are welcome as always. 
 
 Regards,
 
 Xiaolin
 xiaolin.zh...@intel.com
 --
 To unsubscribe from this list: send the line unsubscribe linux-media in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 
 

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

[patch] video/zc0301: improve error handling

[Dan Carpenter]

Return an error if the controller is not found.

Signed-off-by: Dan Carpenter erro...@gmail.com

diff --git a/drivers/media/video/zc0301/zc0301_core.c 
b/drivers/media/video/zc0301/zc0301_core.c
index e44e4b5..bb51cfb 100644
--- a/drivers/media/video/zc0301/zc0301_core.c
+++ b/drivers/media/video/zc0301/zc0301_core.c
@@ -1153,7 +1153,7 @@ zc0301_vidioc_s_ctrl(struct zc0301_device* cam, void 
__user * arg)
if (copy_from_user(ctrl, arg, sizeof(ctrl)))
return -EFAULT;
 
-   for (i = 0; i  ARRAY_SIZE(s-qctrl); i++)
+   for (i = 0; i  ARRAY_SIZE(s-qctrl); i++) {
if (ctrl.id == s-qctrl[i].id) {
if (s-qctrl[i].flags  V4L2_CTRL_FLAG_DISABLED)
return -EINVAL;
@@ -1163,7 +1163,9 @@ zc0301_vidioc_s_ctrl(struct zc0301_device* cam, void 
__user * arg)
ctrl.value -= ctrl.value % s-qctrl[i].step;
break;
}
-
+   }
+   if (i == ARRAY_SIZE(s-qctrl))
+   return -EINVAL;
if ((err = s-set_ctrl(cam, ctrl)))
return err;
 
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[patch] video/et61x251: improve error handling

[Dan Carpenter]

The original code doesn't handle the situation where the controller is
not found.

Signed-off-by: Dan Carpenter erro...@gmail.com

diff --git a/drivers/media/video/et61x251/et61x251_core.c 
b/drivers/media/video/et61x251/et61x251_core.c
index e6c23d5..a5cfc76 100644
--- a/drivers/media/video/et61x251/et61x251_core.c
+++ b/drivers/media/video/et61x251/et61x251_core.c
@@ -1713,7 +1713,7 @@ et61x251_vidioc_s_ctrl(struct et61x251_device* cam, void 
__user * arg)
if (copy_from_user(ctrl, arg, sizeof(ctrl)))
return -EFAULT;
 
-   for (i = 0; i  ARRAY_SIZE(s-qctrl); i++)
+   for (i = 0; i  ARRAY_SIZE(s-qctrl); i++) {
if (ctrl.id == s-qctrl[i].id) {
if (s-qctrl[i].flags  V4L2_CTRL_FLAG_DISABLED)
return -EINVAL;
@@ -1723,7 +1723,9 @@ et61x251_vidioc_s_ctrl(struct et61x251_device* cam, void 
__user * arg)
ctrl.value -= ctrl.value % s-qctrl[i].step;
break;
}
-
+   }
+   if (i == ARRAY_SIZE(s-qctrl))
+   return -EINVAL;
if ((err = s-set_ctrl(cam, ctrl)))
return err;
 
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[patch] video/sn9c102: improve error handling

[Dan Carpenter]

Return an error if the controller is not found.

Signed-off-by: Dan Carpenter erro...@gmail.com

diff --git a/drivers/media/video/sn9c102/sn9c102_core.c 
b/drivers/media/video/sn9c102/sn9c102_core.c
index cbf8087..28e19da 100644
--- a/drivers/media/video/sn9c102/sn9c102_core.c
+++ b/drivers/media/video/sn9c102/sn9c102_core.c
@@ -2295,7 +2295,7 @@ sn9c102_vidioc_s_ctrl(struct sn9c102_device* cam, void 
__user * arg)
if (copy_from_user(ctrl, arg, sizeof(ctrl)))
return -EFAULT;
 
-   for (i = 0; i  ARRAY_SIZE(s-qctrl); i++)
+   for (i = 0; i  ARRAY_SIZE(s-qctrl); i++) {
if (ctrl.id == s-qctrl[i].id) {
if (s-qctrl[i].flags  V4L2_CTRL_FLAG_DISABLED)
return -EINVAL;
@@ -2305,7 +2305,9 @@ sn9c102_vidioc_s_ctrl(struct sn9c102_device* cam, void 
__user * arg)
ctrl.value -= ctrl.value % s-qctrl[i].step;
break;
}
-
+   }
+   if (i == ARRAY_SIZE(s-qctrl))
+   return -EINVAL;
if ((err = s-set_ctrl(cam, ctrl)))
return err;
 
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Hauppauge WinTV HVR-900H

[George Tellalov]

On Sun, Mar 28, 2010 at 01:51:17PM +0200, Stefan Ringel wrote:
  
 In what for mode, analog or dvb-t?
 

The test? It was in analog mode using tvtime.

P.S. Sorry for the double reply, I forgot to reply to the list as well.
--
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

Aw: Re: Hauppauge WinTV HVR-900H

[Stefan Ringel]

 


- Original Nachricht 
Von: George Tellalov gtella...@bigfoot.com
An:  Stefan Ringel stefan.rin...@arcor.de
Datum:   28.03.2010 14:07
Betreff: Re: Hauppauge WinTV HVR-900H

 On Sun, Mar 28, 2010 at 01:51:17PM +0200, Stefan Ringel wrote:
   
  In what for mode, analog or dvb-t?
  
 
 The test? It was in analog mode using tvtime.
 

And the dmsg log (with debug info), so we can see what wrong is. What for 
options have you set in the .config file?


Stefan Ringel stefan.rin...@arcor.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: Re: Hauppauge WinTV HVR-900H

[George Tellalov]

On Sun, Mar 28, 2010 at 02:12:10PM +0200, Stefan Ringel wrote:
  
 
 And the dmsg log (with debug info), so we can see what wrong is. What for 
 options have you set in the .config file?
 

Okay, I'm on my way to produce that log, but it will take a while. I'll have
to recompile the driver and the kernel because the original compile I did was
quite hacky.
--
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 RFC v2] DVB: add dvb_generic_nonseekable_open, dvb_generic_unlocked_ioctl, use in firedtv

[Stefan Richter]

In order to remove Big Kernel Lock usages from the DVB subsystem,
we need to
  - provide .llseek file operations that do not grab the BKL (unlike
fs/read_write.c::default_llseek) or mark files as not seekable,
  - provide .unlocked_ioctl file operations.

Add two dvb_generic_ file operations for file interfaces which are not
seekable and, respectively, do not require the BKL in their ioctl
handlers.

Use them in one driver of which I am sure of that these are applicable.
(Affected code paths in firedtv-ci were not runtime-tested since I don't
have a CAM, but the frontend ioctls were of course runtime-tested.)

Notes:

  - The dvb-core internal dvb_usercopy() API is changed to match
.unlocked_ioctl() prototypes.

  - I suspect that all dvb_generic_open() users really want
nonseekable_open --- then we should simply change dvb_generic_open()
instead of adding dvb_generic_nonseekable_open() --- but I haven't
checked other users of dvb_generic_open whether they require
.llssek mehods other than fs/read_write.c::no_llseek.
Applies to:
drivers/media/dvb/ttpci/av7110.c
drivers/media/dvb/ttpci/av7110_av.c
drivers/media/dvb/ttpci/av7110_ca.c
drivers/media/dvb/dvb-core/dvb_net.c
drivers/media/dvb/dvb-core/dvb_frontend.c
drivers/media/dvb/dvb-core/dvb_ca_en50221.c

  - To be done by those who know the code:  Check all users of
struct dvb_device.kernel_ioctl whether they really need the BKL.
Convert to .unlocked_ioctl and remove .kernel_ioctl and the
temporarily introduced dvbdev.c::legacy_usercopy().
Applies to:
drivers/media/dvb/ttpci/av7110.c
drivers/media/dvb/ttpci/av7110_av.c
drivers/media/dvb/ttpci/av7110_ca.c
drivers/media/dvb/dvb-core/dvb_frontend.c

Signed-off-by: Stefan Richter stef...@s5r6.in-berlin.de
---

Update:  Split dvb_usercopy into one that follows the .unlocked_ioctl
prototype form and another one that preserves the old form.

 drivers/media/dvb/dvb-core/dmxdev.c |   10 -
 drivers/media/dvb/dvb-core/dvb_ca_en50221.c |6 
 drivers/media/dvb/dvb-core/dvb_net.c|5 
 drivers/media/dvb/dvb-core/dvbdev.c |  190 +---
 drivers/media/dvb/dvb-core/dvbdev.h |   23 +-
 drivers/media/dvb/firewire/firedtv-ci.c |9 
 6 files changed, 148 insertions(+), 95 deletions(-)

Index: b/drivers/media/dvb/dvb-core/dmxdev.c
===
--- a/drivers/media/dvb/dvb-core/dmxdev.c
+++ b/drivers/media/dvb/dvb-core/dmxdev.c
@@ -963,8 +963,7 @@ dvb_demux_read(struct file *file, char _
return ret;
 }
 
-static int dvb_demux_do_ioctl(struct inode *inode, struct file *file,
- unsigned int cmd, void *parg)
+static long dvb_demux_do_ioctl(struct file *file, unsigned int cmd, void *parg)
 {
struct dmxdev_filter *dmxdevfilter = file-private_data;
struct dmxdev *dmxdev = dmxdevfilter-dev;
@@ -1087,7 +1086,7 @@ static int dvb_demux_do_ioctl(struct ino
 static int dvb_demux_ioctl(struct inode *inode, struct file *file,
   unsigned int cmd, unsigned long arg)
 {
-   return dvb_usercopy(inode, file, cmd, arg, dvb_demux_do_ioctl);
+   return dvb_usercopy(file, cmd, arg, dvb_demux_do_ioctl);
 }
 
 static unsigned int dvb_demux_poll(struct file *file, poll_table *wait)
@@ -1152,8 +1151,7 @@ static struct dvb_device dvbdev_demux = 
.fops = dvb_demux_fops
 };
 
-static int dvb_dvr_do_ioctl(struct inode *inode, struct file *file,
-   unsigned int cmd, void *parg)
+static long dvb_dvr_do_ioctl(struct file *file, unsigned int cmd, void *parg)
 {
struct dvb_device *dvbdev = file-private_data;
struct dmxdev *dmxdev = dvbdev-priv;
@@ -1179,7 +1177,7 @@ static int dvb_dvr_do_ioctl(struct inode
 static int dvb_dvr_ioctl(struct inode *inode, struct file *file,
 unsigned int cmd, unsigned long arg)
 {
-   return dvb_usercopy(inode, file, cmd, arg, dvb_dvr_do_ioctl);
+   return dvb_usercopy(file, cmd, arg, dvb_dvr_do_ioctl);
 }
 
 static unsigned int dvb_dvr_poll(struct file *file, poll_table *wait)
Index: b/drivers/media/dvb/dvb-core/dvb_ca_en50221.c
===
--- a/drivers/media/dvb/dvb-core/dvb_ca_en50221.c
+++ b/drivers/media/dvb/dvb-core/dvb_ca_en50221.c
@@ -1181,8 +1181,8 @@ static int dvb_ca_en50221_thread(void *d
  *
  * @return 0 on success, 0 on error.
  */
-static int dvb_ca_en50221_io_do_ioctl(struct inode *inode, struct file *file,
- unsigned int cmd, void *parg)
+static long dvb_ca_en50221_io_do_ioctl(struct file *file,
+  unsigned int cmd, void *parg)
 {
struct dvb_device *dvbdev = file-private_data;
struct dvb_ca_private *ca = dvbdev-priv;
@@ -1258,7 +1258,7 @@ static int dvb_ca_en50221_io_do_ioctl(st
 static int 

Re: [patch] video/sn9c102: improve error handling

[Dan Carpenter]

On Sun, Mar 28, 2010 at 05:09:48PM +0200, Christophe JAILLET wrote:
 Hi,
 
 this patch seems incomplete.
 
 You had an opening { wityhout the corresponding }.

It must be an issue with the mail server on your end. :/ 

Here is a url you can download it from.
http://lkml.org/lkml/2010/3/28/43

Unfortunately, lkml.org puts some white space on the end of diffs.
Patch complains but it still applies them fine.

regards,
dan carpenter


--
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: What would be a good time to move subdev drivers to a subdev directory?

[Mauro Carvalho Chehab]

Hans Verkuil wrote:
 Hi Mauro,
 
 Currently drivers/media/video is a mix of subdev drivers and bridge/platform
 drivers. I think it would be good to create a drivers/media/subdev directory
 where subdev drivers can go.
 
 We discussed in the past whether we should have categories for audio subdevs,
 video subdevs, etc. but I think that will cause problems, especially with
 future multifunction devices.

Due to the discussions we had on the last time, I'm not so sure that such move
would be good: There are some cases where the division of a subdev is more a
matter of a logical organization than a physical device division. for example,
cx231xx is just one chip, but, as it has internally the same functionalities as
a cx2584x, the cx2584x is a subdev used by the driver. There are other similar
examples on other IC's and SoC.

I remember that Oliver argued on that time that the better would be to reduce 
the
number of subdirs, instead of increasing. On that discussions, I got convinced 
that he was right, but maybe we have some new reasons to create a subdev dir.

So, let's get some feedback from developers about this again. Whatever decided,
we should clearly document the used criteria, to avoid having drivers misplaced.

Ah, as we're talking about drivers directory, I'm intending to move the Remote
Controller common code to another place, likely drivers/input/rc or drivers/rc.
The idea is to use this subsystem for pure input devices as well. By keeping it
at drivers/media, it will be missplaced.

 What is your opinion on this, and what would be a good time to start moving
 drivers?

If we're doing this change, I prefer to generate the patch by the end of a
merge window, after merging from everybody else and being sure that trivial 
patches
also got merged.

Comments?

-- 

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

[GIT PATCHES FOR 2.6.35] videobuf refactoring

[Hans Verkuil]

The following changes since commit 975b06b6c01ba2da4d26a7ba6ea783d5f670aa7d:
  Jonathan Corbet (1):
V4L/DVB: ov7670: silence some compiler warnings

are available in the git repository at:

  git://linuxtv.org/hverkuil/v4l-dvb-videobuf.git videobuf

Hans Verkuil (8):
  v4l videobuf: remove unused mmap callback.
  v4l videobuf: remove mmap_free callback
  v4l videobuf: remove unused is_mmapped field
  v4l videobuf: use struct videobuf_buffer * instead of void * for 
videobuf_alloc
  v4l videobuf: rename .vmalloc to .vaddr
  v4l videobuf: rename videobuf_queue_to_vmalloc to videobuf_queue_to_vaddr
  v4l videobuf: add videobuf_buffer *buf as argument to mmap_mapper
  v4l videobuf: move video_copy_to_user and copy_stream to core.

 drivers/media/video/videobuf-core.c   |   95 +++-
 drivers/media/video/videobuf-dma-contig.c |  109 +++
 drivers/media/video/videobuf-dma-sg.c |  139 -
 drivers/media/video/videobuf-dvb.c|2 +-
 drivers/media/video/videobuf-vmalloc.c|  104 ++
 include/media/videobuf-core.h |   29 ++-
 6 files changed, 137 insertions(+), 341 deletions(-)

Tested with cx88-blackbird, bttv, saa7134-empress, dvb-ttpci, vivi.
The tests were done with userptr, mmap and read().

There is a lot more that needs to be done, but this is a good start.

Regards,

Hans

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

Re: What would be a good time to move subdev drivers to a subdev directory?

[Hans Verkuil]

On Sunday 28 March 2010 17:38:31 Mauro Carvalho Chehab wrote:
 Hans Verkuil wrote:
  Hi Mauro,
  
  Currently drivers/media/video is a mix of subdev drivers and bridge/platform
  drivers. I think it would be good to create a drivers/media/subdev directory
  where subdev drivers can go.
  
  We discussed in the past whether we should have categories for audio 
  subdevs,
  video subdevs, etc. but I think that will cause problems, especially with
  future multifunction devices.
 
 Due to the discussions we had on the last time, I'm not so sure that such move
 would be good: There are some cases where the division of a subdev is more a
 matter of a logical organization than a physical device division. for example,
 cx231xx is just one chip, but, as it has internally the same functionalities 
 as
 a cx2584x, the cx2584x is a subdev used by the driver. There are other similar
 examples on other IC's and SoC.

I should have mentioned why I think it is a good idea to split it: right now it
is not clear in media/video what the bridge drivers are and what the subdev
drivers are.

Note that integrated subdev drivers that are tightly coupled to a bridge or
platform driver should stay with that driver (in practice these will always
be in a driver-specific subdirectory), but subdevs that can be used stand-alone
should (I think) be moved to their own 'subdev' subdirectory.

It also makes no sense to me to mix bridge drivers and subdev drivers in one
directory. They are simply different types of driver.

I don't care whether they are moved to media/subdev or media/video/subdev. The
latter is probably easier.
 
 I remember that Oliver argued on that time that the better would be to reduce 
 the
 number of subdirs, instead of increasing. On that discussions, I got 
 convinced 
 that he was right, but maybe we have some new reasons to create a subdev dir.
 
 So, let's get some feedback from developers about this again. Whatever 
 decided,
 we should clearly document the used criteria, to avoid having drivers 
 misplaced.

1) Reusable subdev drivers go into the subdev directory.
2) Subdev drivers that are tightly coupled to a bridge or platform driver go
into the subdirectory containing that bridge or platform driver.

Rule 1 applies to roughly 50 subdev drivers.

I wonder if for rule 2 we should require that subdev drivers would go into a
bridge driver/subdev directory. It would help in keeping track of what is 
what,
but this may be overkill.
 
 Ah, as we're talking about drivers directory, I'm intending to move the Remote
 Controller common code to another place, likely drivers/input/rc or 
 drivers/rc.
 The idea is to use this subsystem for pure input devices as well. By keeping 
 it
 at drivers/media, it will be missplaced.

Makes sense.

 
  What is your opinion on this, and what would be a good time to start moving
  drivers?
 
 If we're doing this change, I prefer to generate the patch by the end of a
 merge window, after merging from everybody else and being sure that trivial 
 patches
 also got merged.

OK, makes sense.
 
 Comments?

Regards,

Hans

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

Aw: Re: Re: Hauppauge WinTV HVR-900H

[Stefan Ringel]

 


- Original Nachricht 
Von: George Tellalov gtella...@bigfoot.com
An:  Stefan Ringel stefan.rin...@arcor.de
Datum:   28.03.2010 17:37
Betreff: Re: Re: Hauppauge WinTV HVR-900H

 On Sun, Mar 28, 2010 at 02:12:10PM +0200, Stefan Ringel wrote:
   
  
  
  - Original Nachricht 
  Von: George Tellalov gtella...@bigfoot.com
  An:  Stefan Ringel stefan.rin...@arcor.de
  Datum:   28.03.2010 14:07
  Betreff: Re: Hauppauge WinTV HVR-900H
  
   On Sun, Mar 28, 2010 at 01:51:17PM +0200, Stefan Ringel wrote:
 
In what for mode, analog or dvb-t?

   
   The test? It was in analog mode using tvtime.
   
  
  And the dmsg log (with debug info), so we can see what wrong is. What for
 options have you set in the .config file?
  
 
 Okay the same result with 2.6.33. I'm attaching my .config and dmesg's
 output.
 I also have debug=9 output but I'm not sure if it's appropriate to attach
 it
 here. Maybe I should gzip it?
 

I said debug, but I see no debug info for tm6000 is it modprobe tm6000 debug=1 
debug_i2c=3. From what havew you debug activated? Have you a crash dump in the 
dmesg log? Can tvtime crash, and if tvtime crashed, then send it to tvtime 
project (ask Devin Heitmueller). 

Stefan Ringel stefan.rin...@arcor.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: Re: Re: Hauppauge WinTV HVR-900H

[George Tellalov]

 
 I said debug, but I see no debug info for tm6000 is it modprobe tm6000 
 debug=1 debug_i2c=3. From what havew you debug activated? Have you a crash 
 dump in the dmesg log? Can tvtime crash, and if tvtime crashed, then send it 
 to tvtime project (ask Devin Heitmueller). 
 

Sorry that was only with debug=1. Also I didn't make myself clear about the
crash - it's a kernel crash (oops) not tvtime crash. I'm attaching a new debug
run togther with the oops message. The oops message might have typos because I
had to type it myself (no serial console on this pc).
I'm also unable to do a dvbscan are you interested in the debug output of the
scan?


oops.txt.gz
Description: Binary data

Re: Hauppauge WinTV HVR-900H

[Stefan Ringel]

Am 28.03.2010 17:37, schrieb George Tellalov:
 On Sun, Mar 28, 2010 at 02:12:10PM +0200, Stefan Ringel wrote:
   
  


 - Original Nachricht 
 Von: George Tellalov gtella...@bigfoot.com
 An:  Stefan Ringel stefan.rin...@arcor.de
 Datum:   28.03.2010 14:07
 Betreff: Re: Hauppauge WinTV HVR-900H

 
 On Sun, Mar 28, 2010 at 01:51:17PM +0200, Stefan Ringel wrote:
   
  
 In what for mode, analog or dvb-t?

 
 The test? It was in analog mode using tvtime.

   
 And the dmsg log (with debug info), so we can see what wrong is. What for 
 options have you set in the .config file?

 
 Okay the same result with 2.6.33. I'm attaching my .config and dmesg's output.
 I also have debug=9 output but I'm not sure if it's appropriate to attach it
 here. Maybe I should gzip it?
   

I have also this bug (v4l2 in tm6000)! It can go any time to find and
bugfix it. Please, test the dvb mode, what I think works and resend test
result.

Stefan Ringel

-- 
Stefan Ringel stefan.rin...@arcor.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: Hauppauge WinTV HVR-900H

[Stefan Ringel]

Am 28.03.2010 19:57, schrieb George Tellalov:
 I said debug, but I see no debug info for tm6000 is it modprobe tm6000 
 debug=1 debug_i2c=3. From what havew you debug activated? Have you a crash 
 dump in the dmesg log? Can tvtime crash, and if tvtime crashed, then send it 
 to tvtime project (ask Devin Heitmueller). 

 
 Sorry that was only with debug=1. Also I didn't make myself clear about the
 crash - it's a kernel crash (oops) not tvtime crash. I'm attaching a new debug
 run togther with the oops message. The oops message might have typos because I
 had to type it myself (no serial console on this pc).
 I'm also unable to do a dvbscan are you interested in the debug output of the
 scan?
   
No,  say works, if dvb work. Not more.

-- 
Stefan Ringel stefan.rin...@arcor.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

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

[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:Sun Mar 28 19:00:15 CEST 2010
path:http://www.linuxtv.org/hg/v4l-dvb
changeset:   14536:a539e5b68945
git master:   f6760aa024199cfbce564311dc4bc4d47b6fb349
git media-master: 8c69c6ed6c74c94fa7ad6fa24eda452e4b212d81
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: OK
linux-2.6.33-armv5: OK
linux-2.6.34-rc1-armv5: OK
linux-2.6.32.6-armv5-davinci: WARNINGS
linux-2.6.33-armv5-davinci: WARNINGS
linux-2.6.34-rc1-armv5-davinci: WARNINGS
linux-2.6.32.6-armv5-ixp: WARNINGS
linux-2.6.33-armv5-ixp: WARNINGS
linux-2.6.34-rc1-armv5-ixp: WARNINGS
linux-2.6.32.6-armv5-omap2: WARNINGS
linux-2.6.33-armv5-omap2: WARNINGS
linux-2.6.34-rc1-armv5-omap2: WARNINGS
linux-2.6.22.19-i686: WARNINGS
linux-2.6.23.17-i686: WARNINGS
linux-2.6.24.7-i686: WARNINGS
linux-2.6.25.20-i686: WARNINGS
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-rc1-i686: WARNINGS
linux-2.6.32.6-m32r: OK
linux-2.6.33-m32r: OK
linux-2.6.34-rc1-m32r: OK
linux-2.6.32.6-mips: WARNINGS
linux-2.6.33-mips: WARNINGS
linux-2.6.34-rc1-mips: WARNINGS
linux-2.6.32.6-powerpc64: WARNINGS
linux-2.6.33-powerpc64: WARNINGS
linux-2.6.34-rc1-powerpc64: WARNINGS
linux-2.6.22.19-x86_64: WARNINGS
linux-2.6.23.17-x86_64: WARNINGS
linux-2.6.24.7-x86_64: WARNINGS
linux-2.6.25.20-x86_64: WARNINGS
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-rc1-x86_64: WARNINGS
linux-git-armv5: OK
linux-git-armv5-davinci: OK
linux-git-armv5-ixp: OK
linux-git-armv5-omap2: OK
linux-git-i686: WARNINGS
linux-git-m32r: OK
linux-git-mips: OK
linux-git-powerpc64: WARNINGS
linux-git-x86_64: WARNINGS
spec: ERRORS
spec-git: OK
sparse: ERRORS
linux-2.6.16.62-i686: WARNINGS
linux-2.6.17.14-i686: WARNINGS
linux-2.6.18.8-i686: WARNINGS
linux-2.6.19.7-i686: WARNINGS
linux-2.6.20.21-i686: WARNINGS
linux-2.6.21.7-i686: WARNINGS
linux-2.6.16.62-x86_64: WARNINGS
linux-2.6.17.14-x86_64: WARNINGS
linux-2.6.18.8-x86_64: WARNINGS
linux-2.6.19.7-x86_64: WARNINGS
linux-2.6.20.21-x86_64: WARNINGS
linux-2.6.21.7-x86_64: WARNINGS

Detailed results are available here:

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

Full logs are available here:

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

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

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

Re: [PATCH] V4L/DVB: mx1-camera: compile fix

[Guennadi Liakhovetski]

On Sat, 27 Mar 2010, Uwe Kleine-König wrote:

 This fixes a regression of
 
   7d58289 (mx1: prefix SOC specific defines with MX1_ and deprecate old 
 names)
 
 Signed-off-by: Uwe Kleine-König u.kleine-koe...@pengutronix.de

Sascha, I need your ack to pull this via my tree.

Thanks
Guennadi

 ---
  arch/arm/plat-mxc/include/mach/dma-mx1-mx2.h |8 +++-
  drivers/media/video/mx1_camera.c |8 +++-
  2 files changed, 10 insertions(+), 6 deletions(-)
 
 Hello,
 
 changed since last post:
 
  - put offset in the definition of MX1_DMA_REG in parenthesis
  - describe register definitions now moved to dma-mx1-mx2.h with the full
register names and order by address.
 
 Thanks
 Uwe
 
 diff --git a/arch/arm/plat-mxc/include/mach/dma-mx1-mx2.h 
 b/arch/arm/plat-mxc/include/mach/dma-mx1-mx2.h
 index 07be8ad..4b63b05 100644
 --- a/arch/arm/plat-mxc/include/mach/dma-mx1-mx2.h
 +++ b/arch/arm/plat-mxc/include/mach/dma-mx1-mx2.h
 @@ -31,7 +31,13 @@
  #define DMA_MODE_WRITE   1
  #define DMA_MODE_MASK1
  
 -#define DMA_BASE IO_ADDRESS(DMA_BASE_ADDR)
 +#define MX1_DMA_REG(offset)  MX1_IO_ADDRESS(MX1_DMA_BASE_ADDR + (offset))
 +
 +/* DMA Interrupt Mask Register */
 +#define MX1_DMA_DIMR MX1_DMA_REG(0x08)
 +
 +/* Channel Control Register */
 +#define MX1_DMA_CCR(x)   MX1_DMA_REG(0x8c + ((x)  6))
  
  #define IMX_DMA_MEMSIZE_32   (0  4)
  #define IMX_DMA_MEMSIZE_8(1  4)
 diff --git a/drivers/media/video/mx1_camera.c 
 b/drivers/media/video/mx1_camera.c
 index c167cc3..aa81acd 100644
 --- a/drivers/media/video/mx1_camera.c
 +++ b/drivers/media/video/mx1_camera.c
 @@ -48,8 +48,6 @@
  /*
   * CSI registers
   */
 -#define DMA_CCR(x)   (0x8c + ((x)  6)) /* Control Registers */
 -#define DMA_DIMR 0x08/* Interrupt mask Register */
  #define CSICR1   0x00/* CSI Control Register 
 1 */
  #define CSISR0x08/* CSI Status Register 
 */
  #define CSIRXR   0x10/* CSI RxFIFO Register 
 */
 @@ -783,7 +781,7 @@ static int __init mx1_camera_probe(struct platform_device 
 *pdev)
  pcdev);
  
   imx_dma_config_channel(pcdev-dma_chan, IMX_DMA_TYPE_FIFO,
 -IMX_DMA_MEMSIZE_32, DMA_REQ_CSI_R, 0);
 +IMX_DMA_MEMSIZE_32, MX1_DMA_REQ_CSI_R, 0);
   /* burst length : 16 words = 64 bytes */
   imx_dma_config_burstlen(pcdev-dma_chan, 0);
  
 @@ -797,8 +795,8 @@ static int __init mx1_camera_probe(struct platform_device 
 *pdev)
   set_fiq_handler(mx1_camera_sof_fiq_start, mx1_camera_sof_fiq_end -
  mx1_camera_sof_fiq_start);
  
 - regs.ARM_r8 = DMA_BASE + DMA_DIMR;
 - regs.ARM_r9 = DMA_BASE + DMA_CCR(pcdev-dma_chan);
 + regs.ARM_r8 = (long)MX1_DMA_DIMR;
 + regs.ARM_r9 = (long)MX1_DMA_CCR(pcdev-dma_chan);
   regs.ARM_r10 = (long)pcdev-base + CSICR1;
   regs.ARM_fp = (long)pcdev-base + CSISR;
   regs.ARM_sp = 1  pcdev-dma_chan;
 -- 
 1.7.0
 

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

[PATCH] drivers/media/IR - improve keytable code

[David Härdeman]

The attached patch rewrites much of the keytable code in
drivers/media/IR/ir-keytable.c.

(applies to http://git.linuxtv.org/mchehab/ir.git)

The scancodes are now inserted into the array in sorted
order which allows for a binary search on lookup.

The code has also been shrunk by about 150 lines.

In addition it fixes the following bugs:

Any use of ir_seek_table() was racy.

ir_dev-driver_name is leaked between ir_input_register() and
ir_input_unregister().

ir_setkeycode() unconditionally does clear_bit() on dev-keybit
when removing a mapping, but there might be another mapping with
a different scancode and the same keycode.

Signed-off-by: David Härdeman da...@hardeman.nu
---
 drivers/media/IR/ir-keymaps.c  |2 +
 drivers/media/IR/ir-keytable.c |  516 ++-
 include/media/ir-core.h|4 +-
 3 files changed, 190 insertions(+), 332 deletions(-)

diff --git a/drivers/media/IR/ir-keymaps.c b/drivers/media/IR/ir-keymaps.c
index 55e7acd..bae8522 100644
--- a/drivers/media/IR/ir-keymaps.c
+++ b/drivers/media/IR/ir-keymaps.c
@@ -39,6 +39,8 @@
 struct ir_scancode_table tabname ## _table = { \
.scan = tabname,\
.size = ARRAY_SIZE(tabname),\
+   .len = ARRAY_SIZE(tabname), \
+   .alloc = 0, \
.ir_type = type,\
.name = #irname,\
 }; \
diff --git a/drivers/media/IR/ir-keytable.c b/drivers/media/IR/ir-keytable.c
index ad41af0..cd51bab 100644
--- a/drivers/media/IR/ir-keytable.c
+++ b/drivers/media/IR/ir-keytable.c
@@ -16,344 +16,216 @@
 #include linux/input.h
 #include media/ir-common.h
 
-#define IR_TAB_MIN_SIZE32
-#define IR_TAB_MAX_SIZE1024
+#define IR_TAB_MIN_SIZE1024
+#define IR_TAB_MAX_SIZE8192
 
 /**
- * ir_seek_table() - returns the element order on the table
- * @rc_tab:the ir_scancode_table with the keymap to be used
- * @scancode:  the scancode that we're seeking
+ * ir_resize_table() - resizes a scancode table if necessary
+ * @rc_tab:the ir_scancode_table to resize
+ * @return:zero on success or a negative error code
  *
- * This routine is used by the input routines when a key is pressed at the
- * IR. The scancode is received and needs to be converted into a keycode.
- * If the key is not found, it returns KEY_UNKNOWN. Otherwise, returns the
- * corresponding keycode from the table.
+ * This routine will shrink the ir_scancode_table if it has lots of
+ * unused entries and grow it if it is full.
  */
-static int ir_seek_table(struct ir_scancode_table *rc_tab, u32 scancode)
+static int ir_resize_table(struct ir_scancode_table *rc_tab)
 {
-   int rc;
-   unsigned long flags;
-   struct ir_scancode *keymap = rc_tab-scan;
+   unsigned int oldalloc = rc_tab-alloc;
+   unsigned int newalloc = oldalloc;
+   struct ir_scancode *oldscan = rc_tab-scan;
+   struct ir_scancode *newscan;
+
+   if (rc_tab-size == rc_tab-len) {
+   /* All entries in use - grow keytable */
+   if (rc_tab-alloc = IR_TAB_MAX_SIZE)
+   return -ENOMEM;
 
-   spin_lock_irqsave(rc_tab-lock, flags);
+   if (oldalloc == 0)
+   newalloc = IR_TAB_MIN_SIZE;
+   else
+   newalloc *= 2;
+   IR_dprintk(1, Growing table to %u bytes\n, newalloc);
+   }
 
-   /* FIXME: replace it by a binary search */
+   if ((rc_tab-len * 3  rc_tab-size)  (oldalloc  IR_TAB_MIN_SIZE)) {
+   /* Less than 1/3 of entries in use - shrink keytable */
+   newalloc /= 2;
+   IR_dprintk(1, Shrinking table to %u bytes\n, newalloc);
+   }
 
-   for (rc = 0; rc  rc_tab-size; rc++)
-   if (keymap[rc].scancode == scancode)
-   goto exit;
+   if (newalloc == oldalloc)
+   return 0;
 
-   /* Not found */
-   rc = -EINVAL;
+   newscan = kmalloc(newalloc, GFP_ATOMIC);
+   if (!newscan) {
+   IR_dprintk(1, Failed to kmalloc %u bytes\n, newalloc);
+   return -ENOMEM;
+   }
 
-exit:
-   spin_unlock_irqrestore(rc_tab-lock, flags);
-   return rc;
+   memcpy(newscan, rc_tab-scan, rc_tab-len * sizeof(struct ir_scancode));
+   rc_tab-scan = newscan;
+   rc_tab-alloc = newalloc;
+   rc_tab-size = rc_tab-alloc / sizeof(struct ir_scancode);
+   kfree(oldscan);
+   return 0;
 }
 
 /**
- * ir_roundup_tablesize() - gets an optimum value for the table size
- * @n_elems:   minimum number of entries to store keycodes
- *
- * This routine is used to choose the keycode table size.
+ * ir_do_setkeycode() - internal function to set a keycode in the

Re: What would be a good time to move subdev drivers to a subdev directory?

[Andy Walls]

On Sun, 2010-03-28 at 18:03 +0200, Hans Verkuil wrote:
 On Sunday 28 March 2010 17:38:31 Mauro Carvalho Chehab wrote:
  Hans Verkuil wrote:

  So, let's get some feedback from developers about this again. Whatever 
  decided,
  we should clearly document the used criteria, to avoid having drivers 
  misplaced.
 
 1) Reusable subdev drivers go into the subdev directory.

OK by me.

I will note the cx25840 module is used stand-alone and by the cx23885
and cx231xx drivers as an integrated A/V core.  However the integrated
core is internally I2C connected so it's fairly loosely coupled.  I
don't see a problem with the cx25840 module being pushed into a subdev
directory.


 2) Subdev drivers that are tightly coupled to a bridge or platform driver go
 into the subdirectory containing that bridge or platform driver.

Ack.


 Rule 1 applies to roughly 50 subdev drivers.
 
 I wonder if for rule 2 we should require that subdev drivers would go into a
 bridge driver/subdev directory. It would help in keeping track of what is 
 what,
 but this may be overkill.

NAK.  That is overkill.



BTW, here are some exceptional cases to ponder:

Where does the cx2341x module go?  It is common code used by ivtv, cx18,
and cx23885 (and probably cx88), but it is not a subdevice.  

Also some code in cx23885/cx23888-ir.c could be broken out and shared
between the cx25840, cx18, and cx231xx modules since it is the same IR
hardware (mostly), but connected to the bridge chip differently.  Where
would that go?

Regards,
Andy

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

Re: [RFC] What are the goals for the architecture of an in-kernel IR system?

[Mauro Carvalho Chehab]

Dmitry Torokhov wrote:
 On Fri, Mar 26, 2010 at 11:40:41AM -0300, Mauro Carvalho Chehab wrote:
 David Härdeman wrote:
 On Thu, Mar 25, 2010 at 11:42:33AM -0300, Mauro Carvalho Chehab wrote:
10) extend keycode table replacement to support big/variable 
sized scancodes;
 Pending.

 The current limit here is the scancode ioctl's are defined as:

 #define EVIOCGKEYCODE   _IOR('E', 0x04, int[2]) /* 
 get keycode */
 #define EVIOCSKEYCODE   _IOW('E', 0x04, int[2]) /* 
 set keycode */

 As int size is 32 bits, and we must pass both 64 (or even bigger) 
 scancodes, associated
 with a keycode, there's not enough bits there for IR.

 The better approach seems to create an struct with an arbitrary long size, 
 like:

 struct keycode_table_entry {
unsigned keycode;
char scancode[32];  /* 32 is just an arbitrary long array - maybe 
 shorter */
int len;
 }

 and re-define the ioctls. For example we might be doing:

 #define EVIOCGKEYCODEBIG   _IOR('E', 0x04, struct 
 keycode_table_entry)
 #define EVIOCSKEYCODEBIG   _IOW('E', 0x04, struct 
 keycode_table_entry)
 #define EVIOCLEARKEYCODEBIG_IOR('E', 0x04, void)

 Provided that the size for struct keycode_table_entry is different, _IO 
 will generate
 a different magic number for those.

 Or, instead of using 0x04, just use another sequential number at the 'E' 
 namespace.

 An specific function to clear the table is needed with big scancode space,
 as already discussed.

 I'd suggest:

 struct keycode_table_entry {
 unsigned keycode;
 unsigned index;
 unsigned len;
 char scancode[];
 };

 Use index in EVIOCGKEYCODEBIG to look up a keycode (all other fields are 
 ignored), that way no special function to clear the table is necessary, 
 instead you do a loop with:

 EVIOCGKEYCODEBIG (with index 0)
 EVIOCSKEYCODEBIG (with the returned struct from EVIOCGKEYCODEBIG and
   keycode = KEY_RESERVED)

 until EVIOCGKEYCODEBIG returns an error.
 Makes sense.
 
 Yes, I think so too. Just need a nice way to handle transition, I'd
 like in the end to have drivers implement only the improved methods and
 map legacy methods in evdev.

See the attached RFC barely tested patch. 

On this patch, I'm using the following definitions for the ioctl:

struct keycode_table_entry {
__u32 keycode;  /* e.g. KEY_A */
__u32 index;/* Index for the given scan/key table */
__u32 len;  /* Lenght of the scancode */
__u32 reserved[2];  /* Reserved for future usage */
char *scancode; /* scancode, in machine-endian */
};

#define EVIOCGKEYCODEBIG_IOR('E', 0x04, struct keycode_table_entry) /* 
get keycode */
#define EVIOCSKEYCODEBIG_IOW('E', 0x04, struct keycode_table_entry) /* 
set keycode */


I tried to do the compat backport on a nice way, on both directions, e. g.:

1) an userspace app using EVIO[CS]GKEYCODEBIG to work with a legacy driver.
2) a driver implementing the new methods to accept the legacy EVIO[CS]GKEYCODE;

For the test of (1), I implemented the following clear keytable code:

struct keycode_table_entry  kt;
uint32_tscancode, i;

memset(kt, 0, sizeof(kt));
kt.len = sizeof(scancode);
kt.scancode = (char *)scancode;

for (i = 0; rc == 0; i++) {
kt.index = i;
kt.keycode = KEY_RESERVED;
rc = ioctl(fd, EVIOCSKEYCODEBIG, kt);
}
fprintf(stderr, Cleaned %i keycode(s)\n, i - 1);

It worked properly. I didn't test (2) yet.

The read keytable would also be trivial. However, there are some troubles when
implementing the code to add/replace a value at the table, in a way that it
would allow the legacy drivers to work:

- With a real CODEBIG support, the index number will be different than the
scancode number. So, let's say that this is the driver table:

index   scancode keycode

0   0x1e00   KEY_0
1   0x1e01   KEY_1
2   0x1e02   KEY_2
3   0x1e03   KEY_3
4   0x1e04   KEY_4
5   0x1e05   KEY_5
6   0x1e06   KEY_6
7   0x1e07   KEY_7
8   0x1e08   KEY_8
9   0x1e09   KEY_9

Let's suppose that the user wants to overwrite the entry 5, attributing a new 
scancode/keycode
to entry 5 (for example, associating 0x1e0a with KEY-A).

A valid EVIOCSKEYCODEBIG call to change this code would be:

kt-index = 5;
*(uint32_t *)kt-scancode = 0x1e0a;
*(uint32_t *)kt-keycode = KEY_A;
rc = ioctl(fd, EVIOCSKEYCODEBIG, kt);

With EVIOCSKEYCODE, this requires two separate operations:

int codes[2];
code[0] = 0x1e05;
code[1] = KEY_RESERVED;
rc = ioctl(fd, EVIOCSKEYCODE, codes];

code[0] = 0x1e0a;
code[1] = KEY_A;
rc = ioctl(fd, EVIOCSKEYCODE, codes];


In the case of EVIOCSKEYCODEBIG call, the driver will need to:

1) 

Re: [RFC] What are the goals for the architecture of an in-kernel IR system?

[Mauro Carvalho Chehab]

Mauro Carvalho Chehab wrote:
 Dmitry Torokhov wrote:
 On Fri, Mar 26, 2010 at 11:40:41AM -0300, Mauro Carvalho Chehab wrote:
 David Härdeman wrote:
 On Thu, Mar 25, 2010 at 11:42:33AM -0300, Mauro Carvalho Chehab wrote:
10) extend keycode table replacement to support big/variable 
sized scancodes;
 Pending.

 The current limit here is the scancode ioctl's are defined as:

 #define EVIOCGKEYCODE   _IOR('E', 0x04, int[2]) 
 /* get keycode */
 #define EVIOCSKEYCODE   _IOW('E', 0x04, int[2]) 
 /* set keycode */

 As int size is 32 bits, and we must pass both 64 (or even bigger) 
 scancodes, associated
 with a keycode, there's not enough bits there for IR.

 The better approach seems to create an struct with an arbitrary long 
 size, like:

 struct keycode_table_entry {
   unsigned keycode;
   char scancode[32];  /* 32 is just an arbitrary long array - maybe 
 shorter */
   int len;
 }

 and re-define the ioctls. For example we might be doing:

 #define EVIOCGKEYCODEBIG   _IOR('E', 0x04, struct 
 keycode_table_entry)
 #define EVIOCSKEYCODEBIG   _IOW('E', 0x04, struct 
 keycode_table_entry)
 #define EVIOCLEARKEYCODEBIG_IOR('E', 0x04, void)

 Provided that the size for struct keycode_table_entry is different, _IO 
 will generate
 a different magic number for those.

 Or, instead of using 0x04, just use another sequential number at the 'E' 
 namespace.

 An specific function to clear the table is needed with big scancode space,
 as already discussed.

 I'd suggest:

 struct keycode_table_entry {
unsigned keycode;
unsigned index;
unsigned len;
char scancode[];
 };

 Use index in EVIOCGKEYCODEBIG to look up a keycode (all other fields are 
 ignored), that way no special function to clear the table is necessary, 
 instead you do a loop with:

 EVIOCGKEYCODEBIG (with index 0)
 EVIOCSKEYCODEBIG (with the returned struct from EVIOCGKEYCODEBIG and
  keycode = KEY_RESERVED)

 until EVIOCGKEYCODEBIG returns an error.
 Makes sense.
 Yes, I think so too. Just need a nice way to handle transition, I'd
 like in the end to have drivers implement only the improved methods and
 map legacy methods in evdev.
 
 See the attached RFC barely tested patch. 
 
 On this patch, I'm using the following definitions for the ioctl:
 
 struct keycode_table_entry {
   __u32 keycode;  /* e.g. KEY_A */
   __u32 index;/* Index for the given scan/key table */
   __u32 len;  /* Lenght of the scancode */
   __u32 reserved[2];  /* Reserved for future usage */
   char *scancode; /* scancode, in machine-endian */
 };
 
 #define EVIOCGKEYCODEBIG  _IOR('E', 0x04, struct keycode_table_entry) /* 
 get keycode */
 #define EVIOCSKEYCODEBIG  _IOW('E', 0x04, struct keycode_table_entry) /* 
 set keycode */
 
 
 I tried to do the compat backport on a nice way, on both directions, e. g.:
 
 1) an userspace app using EVIO[CS]GKEYCODEBIG to work with a legacy driver.
 2) a driver implementing the new methods to accept the legacy 
 EVIO[CS]GKEYCODE;
 
 For the test of (1), I implemented the following clear keytable code:
 
   struct keycode_table_entry  kt;
 uint32_tscancode, i;
 
 memset(kt, 0, sizeof(kt));
 kt.len = sizeof(scancode);
 kt.scancode = (char *)scancode;
 
 for (i = 0; rc == 0; i++) {
   kt.index = i;
   kt.keycode = KEY_RESERVED;
 rc = ioctl(fd, EVIOCSKEYCODEBIG, kt);
 }
 fprintf(stderr, Cleaned %i keycode(s)\n, i - 1);
 
 It worked properly. I didn't test (2) yet.
 
 The read keytable would also be trivial. However, there are some troubles when
 implementing the code to add/replace a value at the table, in a way that it
 would allow the legacy drivers to work:
 
 - With a real CODEBIG support, the index number will be different than the
 scancode number. So, let's say that this is the driver table:
 
 index scancode keycode
 
 0 0x1e00   KEY_0
 1 0x1e01   KEY_1
 2 0x1e02   KEY_2
 3 0x1e03   KEY_3
 4 0x1e04   KEY_4
 5 0x1e05   KEY_5
 6 0x1e06   KEY_6
 7 0x1e07   KEY_7
 8 0x1e08   KEY_8
 9 0x1e09   KEY_9
 
 Let's suppose that the user wants to overwrite the entry 5, attributing a new 
 scancode/keycode
 to entry 5 (for example, associating 0x1e0a with KEY-A).
 
 A valid EVIOCSKEYCODEBIG call to change this code would be:
 
   kt-index = 5;
   *(uint32_t *)kt-scancode = 0x1e0a;
   *(uint32_t *)kt-keycode = KEY_A;
   rc = ioctl(fd, EVIOCSKEYCODEBIG, kt);
 
 With EVIOCSKEYCODE, this requires two separate operations:
 
   int codes[2];
   code[0] = 0x1e05;
   code[1] = KEY_RESERVED;
   rc = ioctl(fd, EVIOCSKEYCODE, codes];
 
   code[0] = 0x1e0a;
   code[1] = KEY_A;
   rc = ioctl(fd, EVIOCSKEYCODE, codes];
 
 
 In the case of 

MPEG2 encoder uPD61151 next...

[Dmitri Belimov]

Hi All.

I have more questions now.

Our card has DVB-T zl10353. Befor start encoder need set its out to Z-state. 
How to I can do it?
This is my last big problem.

Startup step by step:

Call zarlink to set Z-state of a bus.
Configure TS port of the saa7134 to PARALLEL_PS and config other regs
Configure DMA of a TS
Prepare settings for uPD61151 encoder
Enable MPEG out of the uPD61151 by GPIO pin of the saa7134
Start DMA and TS
Start encoder

Stop step by step:

Stop encoder
Stop DMA and TS
Disable  MPEG out by GPIO pin of the saa7134

Zarlink and encoder connected to same bus and has different TS config.
I need know who want use TS: zarlink or encoder. Now to I can do it?

 Um, what is the 'Z state' of a bus?  

Write special value to command register of the zl10353. The chip disconnect
internal bus from output bus. This bus used for send MPEG TS data from zl10353 
to saa7134.
uPD61151 and zl10353 connected to the same bus. At one time only one chip can
send MPEG TS data to the saa7134. When DVB-T mode zl10353 send date, uPD61151 
disconnected from a bus.
When MPEG2 encode mode, uPD61151 send date, zl10353 disconnected from a bus.

With my best regards, Dmitry.
--
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