date:20091215

On Sun 2009-12-06 12:59:00, Christoph Bartelmus wrote:
 Hi Dmitry,
 
 on 05 Dec 09 at 22:55, Dmitry Torokhov wrote:
 [...]
  I do not believe you are being realistic. Sometimes we just need to say
  that the device is a POS and is just not worth it. Remember, there is
  still lirc hole for the hard core people still using solder to produce
  something out of the spare electronic components that may be made to
  work (never mind that it causes the CPU constantly poll the device, not
  letting it sleep and wasting electricity as a result - just hypotetical
  example here).
 
 The still seems to be is a persistent misconception that the home-brewn  
 receivers need polling or cause heavy CPU load. No they don't. All of them  
 are IRQ based.

I have at least one that needs polling/signal
processing... somewhere. IR LED connected to mic input.

Anyway, clearly hacked-up devices like that are better left for
userland solutions.
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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

[RFC 0/4] V4L2 file handles and event interface


Hi,

Here's the first version of the V4L2 file handle and event interface 
patchset. I posted it as RFC since there are a few issues with the 
contents and I have no assurrances that this even is functional at the 
moment.


The first patch adds the V4L2 file handle support and the rest are for 
V4L2 events.


A few notes on the patches:

- I don't like the locking too much. Perhaps the file handle specific 
lock (events-lock) could be dropped in favour of the lock for 
v4l2_file_handle in video_device.


- Event queue depth is not controlled at the moment.

- (Un)subscribing all events is not supported.

Comments are very welcome.

Cheers,

--
Sakari Ailus
sakari.ai...@maxwell.research.nokia.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

[RFC 3/4] V4L: Events: Support event handling in do_ioctl

Add support for event handling to do_ioctl.

Signed-off-by: Sakari Ailus sakari.ai...@maxwell.research.nokia.com
---
 drivers/media/video/v4l2-ioctl.c |   48 ++
 include/media/v4l2-ioctl.h   |7 +
 2 files changed, 55 insertions(+), 0 deletions(-)

diff --git a/drivers/media/video/v4l2-ioctl.c b/drivers/media/video/v4l2-ioctl.c
index bfc4696..067ab3a 100644
--- a/drivers/media/video/v4l2-ioctl.c
+++ b/drivers/media/video/v4l2-ioctl.c
@@ -1797,7 +1797,55 @@ static long __video_do_ioctl(struct file *file,
}
break;
}
+   case VIDIOC_DQEVENT:
+   {
+   struct v4l2_event *ev = arg;
+
+   if (!ops-vidioc_dqevent)
+   break;
+
+   ret = ops-vidioc_dqevent(file, ev);
+   if (ret  0) {
+   dbgarg(cmd, no pending events?);
+   break;
+   }
+   dbgarg(cmd,
+  count=%d, type=0x%8.8x, sequence=%d, 
+  timestamp=%d.%9.9lu ,
+  ev-count, ev-type, ev-sequence,
+  (int)ev-timestamp.tv_sec, ev-timestamp.tv_nsec);
+   break;
+   }
+   case VIDIOC_SUBSCRIBE_EVENT:
+   {
+   struct v4l2_event_subscription *sub = arg;
 
+   if (!ops-vidioc_subscribe_event)
+   break;
+
+   ret = ops-vidioc_subscribe_event(file, sub);
+   if (ret  0) {
+   dbgarg(cmd, failed, ret=%ld, ret);
+   break;
+   }
+   dbgarg(cmd, type=0x%8.8x, sub-type);
+   break;
+   }
+   case VIDIOC_UNSUBSCRIBE_EVENT:
+   {
+   struct v4l2_event_subscription *sub = arg;
+
+   if (!ops-vidioc_unsubscribe_event)
+   break;
+
+   ret = ops-vidioc_unsubscribe_event(file, sub);
+   if (ret  0) {
+   dbgarg(cmd, failed, ret=%ld, ret);
+   break;
+   }
+   dbgarg(cmd, type=0x%8.8x, sub-type);
+   break;
+   }
default:
{
if (!ops-vidioc_default)
diff --git a/include/media/v4l2-ioctl.h b/include/media/v4l2-ioctl.h
index 7a4529d..77a71cc 100644
--- a/include/media/v4l2-ioctl.h
+++ b/include/media/v4l2-ioctl.h
@@ -239,6 +239,13 @@ struct v4l2_ioctl_ops {
int (*vidioc_enum_frameintervals) (struct file *file, void *fh,
   struct v4l2_frmivalenum *fival);
 
+   int (*vidioc_dqevent)  (struct file *file,
+   struct v4l2_event *ev);
+   int (*vidioc_subscribe_event)  (struct file *file,
+   struct v4l2_event_subscription *sub);
+   int (*vidioc_unsubscribe_event) (struct file *file,
+struct v4l2_event_subscription *sub);
+
/* For other private ioctls */
long (*vidioc_default) (struct file *file, void *fh,
int cmd, void *arg);
-- 
1.5.6.5

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

[RFC 2/4] V4L: Events: Add new ioctls for events

This patch adds a set of new ioctls to the V4L2 API. The ioctls conform to
V4L2 Events RFC version 2.3:

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

Signed-off-by: Sakari Ailus sakari.ai...@maxwell.research.nokia.com
---
 drivers/media/video/v4l2-compat-ioctl32.c |3 +++
 drivers/media/video/v4l2-ioctl.c  |3 +++
 include/linux/videodev2.h |   24 
 3 files changed, 30 insertions(+), 0 deletions(-)

diff --git a/drivers/media/video/v4l2-compat-ioctl32.c 
b/drivers/media/video/v4l2-compat-ioctl32.c
index 997975d..cba704c 100644
--- a/drivers/media/video/v4l2-compat-ioctl32.c
+++ b/drivers/media/video/v4l2-compat-ioctl32.c
@@ -1077,6 +1077,9 @@ long v4l2_compat_ioctl32(struct file *file, unsigned int 
cmd, unsigned long arg)
case VIDIOC_DBG_G_REGISTER:
case VIDIOC_DBG_G_CHIP_IDENT:
case VIDIOC_S_HW_FREQ_SEEK:
+   case VIDIOC_DQEVENT:
+   case VIDIOC_SUBSCRIBE_EVENT:
+   case VIDIOC_UNSUBSCRIBE_EVENT:
ret = do_video_ioctl(file, cmd, arg);
break;
 
diff --git a/drivers/media/video/v4l2-ioctl.c b/drivers/media/video/v4l2-ioctl.c
index 30cc334..bfc4696 100644
--- a/drivers/media/video/v4l2-ioctl.c
+++ b/drivers/media/video/v4l2-ioctl.c
@@ -283,6 +283,9 @@ static const char *v4l2_ioctls[] = {
 
[_IOC_NR(VIDIOC_DBG_G_CHIP_IDENT)] = VIDIOC_DBG_G_CHIP_IDENT,
[_IOC_NR(VIDIOC_S_HW_FREQ_SEEK)]   = VIDIOC_S_HW_FREQ_SEEK,
+   [_IOC_NR(VIDIOC_DQEVENT)]  = VIDIOC_DQEVENT,
+   [_IOC_NR(VIDIOC_SUBSCRIBE_EVENT)]  = VIDIOC_SUBSCRIBE_EVENT,
+   [_IOC_NR(VIDIOC_UNSUBSCRIBE_EVENT)] = VIDIOC_UNSUBSCRIBE_EVENT,
 #endif
 };
 #define V4L2_IOCTLS ARRAY_SIZE(v4l2_ioctls)
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 54af357..397f8eb 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -1536,6 +1536,27 @@ struct v4l2_streamparm {
 };
 
 /*
+ * E V E N T S
+ */
+
+struct v4l2_event {
+   __u32   count;
+   __u32   type;
+   __u32   sequence;
+   struct timespec timestamp;
+   __u32   reserved[8];
+   __u8data[64];
+};
+
+struct v4l2_event_subscription {
+   __u32   type;
+   __u32   reserved[8];
+};
+
+#define V4L2_EVENT_ALL 0
+#define V4L2_EVENT_PRIVATE_START   0x0800
+
+/*
  * A D V A N C E D   D E B U G G I N G
  *
  * NOTE: EXPERIMENTAL API, NEVER RELY ON THIS IN APPLICATIONS!
@@ -1651,6 +1672,9 @@ struct v4l2_dbg_chip_ident {
 #endif
 
 #define VIDIOC_S_HW_FREQ_SEEK   _IOW('V', 82, struct v4l2_hw_freq_seek)
+#define VIDIOC_DQEVENT  _IOR('V', 83, struct v4l2_event)
+#define VIDIOC_SUBSCRIBE_EVENT  _IOW('V', 84, struct v4l2_event_subscription)
+#define VIDIOC_UNSUBSCRIBE_EVENT _IOW('V', 85, struct v4l2_event_subscription)
 /* Reminder: when adding new ioctls please add support for them to
drivers/media/video/v4l2-compat-ioctl32.c as well! */
 
-- 
1.5.6.5

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

[RFC 1/4] V4L: File handles

This patch adds a list of v4l2_file_handle structures to every video_device.
It allows using file handle related information in V4L2. The event interface
is one example of such use.

Signed-off-by: Sakari Ailus sakari.ai...@maxwell.research.nokia.com
---
 drivers/media/video/Makefile   |2 +-
 drivers/media/video/v4l2-dev.c |7 +++-
 drivers/media/video/v4l2-fh.c  |   95 
 include/media/v4l2-dev.h   |4 ++
 include/media/v4l2-fh.h|   45 +++
 5 files changed, 151 insertions(+), 2 deletions(-)
 create mode 100644 drivers/media/video/v4l2-fh.c
 create mode 100644 include/media/v4l2-fh.h

diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index a61e3f3..1947146 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -10,7 +10,7 @@ stkwebcam-objs:=  stk-webcam.o stk-sensor.o
 
 omap2cam-objs  :=  omap24xxcam.o omap24xxcam-dma.o
 
-videodev-objs  :=  v4l2-dev.o v4l2-ioctl.o v4l2-device.o
+videodev-objs  :=  v4l2-dev.o v4l2-ioctl.o v4l2-device.o v4l2-fh.o
 
 # V4L2 core modules
 
diff --git a/drivers/media/video/v4l2-dev.c b/drivers/media/video/v4l2-dev.c
index 7090699..387a302 100644
--- a/drivers/media/video/v4l2-dev.c
+++ b/drivers/media/video/v4l2-dev.c
@@ -283,7 +283,8 @@ static int v4l2_open(struct inode *inode, struct file *filp)
/* and increase the device refcount */
video_get(vdev);
mutex_unlock(videodev_lock);
-   if (vdev-fops-open)
+   ret = v4l2_file_handle_add(vdev, filp);
+   if (!ret  vdev-fops-open)
ret = vdev-fops-open(filp);
 
/* decrease the refcount in case of an error */
@@ -301,6 +302,8 @@ static int v4l2_release(struct inode *inode, struct file 
*filp)
if (vdev-fops-release)
vdev-fops-release(filp);
 
+   v4l2_file_handle_del(vdev, filp);
+
/* decrease the refcount unconditionally since the release()
   return value is ignored. */
video_put(vdev);
@@ -421,6 +424,8 @@ static int __video_register_device(struct video_device 
*vdev, int type, int nr,
if (!vdev-release)
return -EINVAL;
 
+   v4l2_file_handle_init(vdev);
+
/* Part 1: check device type */
switch (type) {
case VFL_TYPE_GRABBER:
diff --git a/drivers/media/video/v4l2-fh.c b/drivers/media/video/v4l2-fh.c
new file mode 100644
index 000..52cb3b3
--- /dev/null
+++ b/drivers/media/video/v4l2-fh.c
@@ -0,0 +1,95 @@
+/*
+ * drivers/media/video/v4l2-fh.c
+ *
+ * V4L2 file handles.
+ *
+ * Copyright (C) 2009 Nokia Corporation.
+ *
+ * Contact: Sakari Ailus sakari.ai...@maxwell.research.nokia.com
+ *
+ * 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 St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ */
+
+#include media/v4l2-dev.h
+#include media/v4l2-fh.h
+
+#include linux/sched.h
+#include linux/vmalloc.h
+
+static struct v4l2_file_handle *__v4l2_file_handle_get(
+   struct video_device *vdev, struct file *filp)
+{
+   struct v4l2_file_handle *fh;
+
+   list_for_each_entry(fh, vdev-fh, list) {
+   if (fh-filp == filp)
+   return fh;
+   }
+
+   return NULL;
+}
+
+struct v4l2_file_handle *v4l2_file_handle_get(struct video_device *vdev,
+ struct file *filp)
+{
+   struct v4l2_file_handle *fh;
+   unsigned long flags;
+
+   spin_lock_irqsave(vdev-fh_lock, flags);
+   fh = __v4l2_file_handle_get(vdev, filp);
+   spin_unlock_irqrestore(vdev-fh_lock, flags);
+
+   return fh;
+}
+EXPORT_SYMBOL_GPL(v4l2_file_handle_get);
+
+int v4l2_file_handle_add(struct video_device *vdev, struct file *filp)
+{
+   struct v4l2_file_handle *fh;
+   unsigned long flags;
+
+   fh = kmalloc(sizeof(*fh), GFP_KERNEL);
+   if (!fh)
+   return -ENOMEM;
+
+   fh-filp = filp;
+
+   spin_lock_irqsave(vdev-fh_lock, flags);
+   list_add(fh-list, vdev-fh);
+   spin_unlock_irqrestore(vdev-fh_lock, flags);
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(v4l2_file_handle_add);
+
+void v4l2_file_handle_del(struct video_device *vdev, struct file *filp)
+{
+   struct v4l2_file_handle *fh = v4l2_file_handle_get(vdev, filp);
+   unsigned long flags;
+
+   spin_lock_irqsave(vdev-fh_lock, flags);
+   list_del(fh-list);
+

[RFC 4/4] V4L: Events: Add backend

Add event handling backend to V4L2. The backend handles event subscription
and delivery to file handles. Event subscriptions are based on file handle.
Events may be delivered to all subscribed file handles on a device
independent of where they originate from.

Signed-off-by: Sakari Ailus sakari.ai...@maxwell.research.nokia.com
---
 drivers/media/video/Makefile |3 +-
 drivers/media/video/v4l2-event.c |  254 ++
 drivers/media/video/v4l2-fh.c|9 ++
 include/media/v4l2-event.h   |   73 +++
 include/media/v4l2-fh.h  |3 +
 5 files changed, 341 insertions(+), 1 deletions(-)
 create mode 100644 drivers/media/video/v4l2-event.c
 create mode 100644 include/media/v4l2-event.h

diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index 1947146..dd6a853 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -10,7 +10,8 @@ stkwebcam-objs:=  stk-webcam.o stk-sensor.o
 
 omap2cam-objs  :=  omap24xxcam.o omap24xxcam-dma.o
 
-videodev-objs  :=  v4l2-dev.o v4l2-ioctl.o v4l2-device.o v4l2-fh.o
+videodev-objs  :=  v4l2-dev.o v4l2-ioctl.o v4l2-device.o v4l2-fh.o \
+   v4l2-event.o
 
 # V4L2 core modules
 
diff --git a/drivers/media/video/v4l2-event.c b/drivers/media/video/v4l2-event.c
new file mode 100644
index 000..91c3acc
--- /dev/null
+++ b/drivers/media/video/v4l2-event.c
@@ -0,0 +1,254 @@
+/*
+ * drivers/media/video/v4l2-event.c
+ *
+ * V4L2 events.
+ *
+ * Copyright (C) 2009 Nokia Corporation.
+ *
+ * Contact: Sakari Ailus sakari.ai...@maxwell.research.nokia.com
+ *
+ * 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 St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ */
+
+#include media/v4l2-dev.h
+#include media/v4l2-event.h
+
+#include linux/sched.h
+
+static struct kmem_cache *event_kmem;
+
+static void v4l2_event_kmem_ctor(void *ptr)
+{
+   struct _v4l2_event *ev = ptr;
+
+   INIT_LIST_HEAD(ev-list);
+}
+
+int v4l2_event_init(struct v4l2_events *events)
+{
+   if (!event_kmem)
+   event_kmem = kmem_cache_create(event_kmem,
+  sizeof(struct _v4l2_event), 0,
+  SLAB_HWCACHE_ALIGN,
+  v4l2_event_kmem_ctor);
+
+   if (!event_kmem)
+   return -ENOMEM;
+
+   init_waitqueue_head(events-wait);
+   spin_lock_init(events-lock);
+
+   INIT_LIST_HEAD(events-available);
+   INIT_LIST_HEAD(events-subscribed);
+
+   return 0;
+};
+EXPORT_SYMBOL_GPL(v4l2_event_init);
+
+void v4l2_event_exit(struct v4l2_events *events)
+{
+   while (!list_empty(events-available)) {
+   struct _v4l2_event *ev;
+
+   ev = list_entry(events-available.next,
+   struct _v4l2_event, list);
+
+   list_del(ev-list);
+
+   kmem_cache_free(event_kmem, ev);
+   }
+
+   while (!list_empty(events-subscribed)) {
+   struct v4l2_subscribed_event *sub;
+
+   sub = list_entry(events-subscribed.next,
+   struct v4l2_subscribed_event, list);
+
+   list_del(sub-list);
+
+   kfree(sub);
+   }
+}
+EXPORT_SYMBOL_GPL(v4l2_event_exit);
+
+int v4l2_event_dequeue(struct v4l2_events *events, struct v4l2_event *event)
+{
+   struct _v4l2_event *ev;
+   int ret = 0;
+   unsigned long flags;
+
+   spin_lock_irqsave(events-lock, flags);
+
+   if (list_empty(events-available)) {
+   ret = -ENOENT;
+   goto out;
+   }
+
+   ev = list_first_entry(events-available, struct _v4l2_event, list);
+   list_del(ev-list);
+
+   ev-event.count = !list_empty(events-available);
+
+   memcpy(event, ev-event, sizeof(ev-event));
+
+   kmem_cache_free(event_kmem, ev);
+
+out:
+
+   spin_unlock_irqrestore(events-lock, flags);
+
+   return ret;
+}
+EXPORT_SYMBOL_GPL(v4l2_event_dequeue);
+
+static struct _v4l2_event *v4l2_event_queue_get(struct v4l2_events *events)
+{
+   return kmem_cache_alloc(event_kmem, GFP_KERNEL | GFP_ATOMIC);
+}
+
+static void v4l2_event_queue_put(struct v4l2_events *events,
+struct _v4l2_event *ev)
+{
+   unsigned long flags;
+
+   spin_lock_irqsave(events-lock, flags);
+
+

Re: High cpu load (dvb_usb_dib0700)

2009-12-15 Thread Markus Suvanto

 Have you tried to load dvb-usb with disable_rc_polling=1 ?

 It may or may not help.

 If it helps it will necessary to have a look at the ir-polling code to see
 whether there is some thing like 'scheduling'.

Yes it helps.
echo 1   /sys/module/dvb_usb/parameters/disable_rc_polling
and my cpu load goes down but remote control don't work anymore.

-Markus
--
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: KWorld DVB-T 210 Fails to work on Linux 2.6.31-r6 x86_64

2009-12-15 Thread Theunis Potgieter

kernel: tda1004x: found firmware revision 20 -- ok

now I'm getting this... strange :-|

I did nothing different. except to retry the module after a while again.
--
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- gspca: added chipset revision sensor

2009-12-15 Thread leandro Costantino

Jean,
let me know , if you need to the test this patch, since i added the
tas1530k long time ago, and still have the webcam :)
Best Regards

On Tue, Dec 15, 2009 at 4:54 AM, Jean-Francois Moine moin...@free.fr wrote:
 On Tue, 15 Dec 2009 03:45:00 +
 Luis Maia lm...@royalhat.org wrote:

 Added extra chipset revision (sensor) to fix camera zc0301 with  ID:
 0ac8:301b .
 Since i own one of this cameras fixed and tested it.

 -

 diff -uNr linux-2.6.32.1/drivers/media/video/gspca/zc3xx.c
 linux-2.6.32.1-patch/drivers/media/video/gspca/zc3xx.c
 --- linux-2.6.32.1/drivers/media/video/gspca/zc3xx.c    2009-12-14
 17:47:25.0 +
 +++ linux-2.6.32.1-patch/drivers/media/video/gspca/zc3xx.c
 2009-12-15 02:42:13.0 +
 @@ -6868,6 +6868,7 @@
      {0x8001, 0x13},
      {0x8000, 0x14},        /* CS2102K */
      {0x8400, 0x15},        /* TAS5130K */
 +    {0xe400, 0x15},
  };

  static int vga_3wr_probe(struct gspca_dev *gspca_dev)
 @@ -7634,7 +7635,7 @@
      {USB_DEVICE(0x0698, 0x2003)},
      {USB_DEVICE(0x0ac8, 0x0301), .driver_info = SENSOR_PAS106},
      {USB_DEVICE(0x0ac8, 0x0302), .driver_info = SENSOR_PAS106},
 -    {USB_DEVICE(0x0ac8, 0x301b)},
 +    {USB_DEVICE(0x0ac8, 0x301b), .driver_info = SENSOR_PB0330},
      {USB_DEVICE(0x0ac8, 0x303b)},
      {USB_DEVICE(0x0ac8, 0x305b), .driver_info =
 SENSOR_TAS5130C_VF0250}, {USB_DEVICE(0x0ac8, 0x307b)},

 Hello Luis,

 I don't understand your patch:
 1) you added 0xe400 in the chipset table giving the sensor tas5130c K
 2) in the device table you say that the 0ac8:301b sensor is a pb0330
   (but this information is not used: the sensor type in .driver_info
   may be only pas106 for sif probe or mc501cb/tas5130_vf0250 for no
   probe.

 What is exactly the sensor of your webcam?

 --
 Ken ar c'hentañ |             ** Breizh ha Linux atav! **
 Jef             |               http://moinejf.free.fr/
 --
 To unsubscribe from this list: send the line unsubscribe linux-media in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

2009-12-15 Thread Mauro Carvalho Chehab

Pavel Machek wrote:
 That is why I think we should go the other way around - introduce the
 core which receivers could plug into and decoder framework and once it
 is ready register lirc-dev as one of the available decoders.

 I've committed already some IR restruct code on my linux-next -git tree:

 http://git.kernel.org/?p=linux/kernel/git/mchehab/linux-next.git

 The code there basically moves the input/evdev registering code and 
 scancode/keycode management code into a separate ir-core module.

 To make my life easy, I've moved the code temporarily into drivers/media/IR.
 This way, it helps me to move V4L specific code outside ir-core and to later
 use it for DVB. After having it done, probably the better is to move it to
 be under /drivers or /drivers/input.
 
 Well, -next is for stuff to be merged into 2.6.34. You are quite an
 optimist.
   Pavel

Well, we need those changes anyway for the in-kernel drivers, and I'm not seeing
on the current patches any reason for not having them for 2.6.34.

I've added all the ir-core patches I did so far at linux-next. This helps people
to review and contribute.

The patches are already working with the in-kernel em28xx driver, allowing to
replace the keycode table and the protocol used by the hardware IR decoder.
I tested here by replacing an RC-5 based IR table (Hauppauge Grey) by a NEC
based IR table (Terratec Cinergy XS remote controller).

The current Remote Controller core module (ir-core) is currently doing:

- Implementation of the existing EVIO[G|S]KEYCODE, expanding/feeing 
memory
dynamically, based on the needed size for scancode/keycode table;

- scancodes can be up to 16 bits currently;

- sysfs is registering /sys/class/irrcv and creating one branch for each
different RC receiver, numbering from irrcv0 to irrcv255;

- one irrcv note is created: current_protocol;

- reading /sys/class/irrcv/irrcv*/current_protocol returns the protocol
currently used by the driver;

- writing to /sys/class/irrcv/irrcv*/current_protocol changes the 
protocol
to a new one, by calling a callback, asking the driver to change the protocol. 
If
the protocol is not support, it returns -EINVAL;

- all V4L drivers are already using ir-core;

- em28xx driver is implementing current_protocol show/store support.

TODO:
1) Port DVB drivers to use ir-core, removing the duplicated (and 
incomplete
  - as table size can't change on DVB's implementation) code that 
exists there;

2) add current_protocol support on other drivers;

3) link the corresponding input/evdev interfaces with 
/sys/class/irrcv/irrcv*;

4) make the keytable.c application aware of the sysfs vars;

5) add an attribute to uniquely identify a remote controller;

6) write or convert an existing application to load IR tables at 
runtime;

7) get the complete 16-bit scancodes used by V4L drivers;

8) add decoder/lirc_dev glue to ir-core;

9) add lirc_dev module and in-kernel decoders;

10) extend keycode table replacement to support big/variable sized 
scancodes;

11) rename IR-RC;

12) redesign or remove ir-common module. It currently handles in-kernel
keycode tables and a few helper routines for raw pulse/space decode;

13) move drivers/media/IR to a better place;


comments:

Tasks (1) to (6) for sure can happen to 2.6.34, depending on people's 
spare
time for it;

(7) is probably the more complex task, since it requires to re-test all 
in-kernel
supported remote controlle scancode/keycode tables, to get the complete IR 
keycode
and rewrite the getkeycode functions that are currently masking the IR code 
into 7 bits. 
We'll need users help on this task, but this can be done gradually, like I did 
with
two RC keytables on em28xx driver, while preserving the other keytables as-is.

(8) I suggest that this glue will be submitted together with lirc_dev 
patch
series, as the biggest client for it is lirc. In principle, kfifo seems the 
better
interface for lirc_dev - decoders interface. For the decoders - RC core 
interface,
there's an interface already used on V4L drivers, provided by ir-common, using 
evdev
kernel API. This may need some review.

(9) depends on lirc API discusions. My proposal is that people submit 
an RFC
with the lirc API reviewed to the ML's, for people to ack/nack/comment. After 
that, 
re-submit the lirc_dev module integrating it into ir-core and with the reviewed 
API;

(10) depends on EVIO[G|S]KEYCODE discussions we've already started. I 
did a proposal
about it. I'll review, based on the comments and re-submit it;

(11) if none is against renaming IR as RC, I'll do it on a next patch;

(12) depends on having lirc_dev added, for the removal of 
ir-functions.c. With
respect to the

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

On Tue, Dec 15, 2009 at 8:33 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
Pavel Machek wrote:
That is why I think we should go the other way around - introduce the
core which receivers could plug into and decoder framework and once it
is ready register lirc-dev as one of the available decoders.

I've committed already some IR restruct code on my linux-next -git tree:

http://git.kernel.org/?p=linux/kernel/git/mchehab/linux-next.git

The code there basically moves the input/evdev registering code and
scancode/keycode management code into a separate ir-core module.

To make my life easy, I've moved the code temporarily into drivers/media/IR.
This way, it helps me to move V4L specific code outside ir-core and to later
use it for DVB. After having it done, probably the better is to move it to
be under /drivers or /drivers/input.

Well, -next is for stuff to be merged into 2.6.34. You are quite an
optimist.
Pavel

Well, we need those changes anyway for the in-kernel drivers, and I'm not
seeing
on the current patches any reason for not having them for 2.6.34.

I've added all the ir-core patches I did so far at linux-next. This helps
people
to review and contribute.

The patches are already working with the in-kernel em28xx driver, allowing to
replace the keycode table and the protocol used by the hardware IR decoder.
I tested here by replacing an RC-5 based IR table (Hauppauge Grey) by a NEC
based IR table (Terratec Cinergy XS remote controller).

The current Remote Controller core module (ir-core) is currently doing:

- Implementation of the existing EVIO[G|S]KEYCODE, expanding/feeing
memory
dynamically, based on the needed size for scancode/keycode table;

- scancodes can be up to 16 bits currently;

- sysfs is registering /sys/class/irrcv and creating one branch for
each
different RC receiver, numbering from irrcv0 to irrcv255;

- one irrcv note is created: current_protocol;

- reading /sys/class/irrcv/irrcv*/current_protocol returns the protocol
currently used by the driver;

- writing to /sys/class/irrcv/irrcv*/current_protocol changes the
protocol
to a new one, by calling a callback, asking the driver to change the
protocol. If
the protocol is not support, it returns -EINVAL;

- all V4L drivers are already using ir-core;

- em28xx driver is implementing current_protocol show/store support.

TODO:

I'd add a pulse based receiver like a MSMCE to make sure the core API is right.
MSME has transmit hardware too.

What about creating multiple evdev devices with their own keymaps off
from a single receiver? That's a key part of making multi-function
remotes work.

1) Port DVB drivers to use ir-core, removing the duplicated (and
incomplete
- as table size can't change on DVB's implementation) code that
exists there;

2) add current_protocol support on other drivers;

3) link the corresponding input/evdev interfaces with
/sys/class/irrcv/irrcv*;

4) make the keytable.c application aware of the sysfs vars;

5) add an attribute to uniquely identify a remote controller;

6) write or convert an existing application to load IR tables at
runtime;

7) get the complete 16-bit scancodes used by V4L drivers;

8) add decoder/lirc_dev glue to ir-core;

9) add lirc_dev module and in-kernel decoders;

10) extend keycode table replacement to support big/variable sized
scancodes;

11) rename IR-RC;

12) redesign or remove ir-common module. It currently handles in-kernel
keycode tables and a few helper routines for raw pulse/space
decode;

13) move drivers/media/IR to a better place;

comments:

Tasks (1) to (6) for sure can happen to 2.6.34, depending on people's
spare
time for it;

(7) is probably the more complex task, since it requires to re-test
all in-kernel
supported remote controlle scancode/keycode tables, to get the complete IR
keycode
and rewrite the getkeycode functions that are currently masking the IR code
into 7 bits.
We'll need users help on this task, but this can be done gradually, like I
did with
two RC keytables on em28xx driver, while preserving the other keytables as-is.

(8) I suggest that this glue will be submitted together with lirc_dev
patch
series, as the biggest client for it is lirc. In principle, kfifo seems the
better
interface for lirc_dev - decoders interface. For the decoders - RC core
interface,
there's an interface already used on V4L drivers, provided by ir-common,
using evdev
kernel API. This may need some review.

(9) depends on lirc API discusions. My proposal is that people submit
an RFC
with the lirc API reviewed to the ML's, for people to ack/nack/comment. After
that,
re-submit the lirc_dev module

[PATCH] RFC: mx27: Add soc_camera support

2009-12-15 Thread Alan Carvalho de Assis

This is the soc_camera support developed by Sascha Hauer.
I just modified original driver to get it working on recent kernel.

Signed-off-by: Alan Carvalho de Assis acas...@gmail.com
---
 arch/arm/mach-mx2/clock_imx27.c  |2 +-
 arch/arm/mach-mx2/devices.c  |   32 +
 arch/arm/mach-mx2/devices.h  |1 +
 arch/arm/plat-mxc/include/mach/imx_cam.h |   47 ++
 drivers/media/video/Kconfig  |   13 +
 drivers/media/video/Makefile |3 +
 drivers/media/video/mx27_camera.c| 1224 ++
 7 files changed, 1321 insertions(+), 1 deletions(-)
 create mode 100644 arch/arm/plat-mxc/include/mach/imx_cam.h
 create mode 100644 drivers/media/video/mx27_camera.c

diff --git a/arch/arm/mach-mx2/clock_imx27.c b/arch/arm/mach-mx2/clock_imx27.c
index b010bf9..1ad0408 100644
--- a/arch/arm/mach-mx2/clock_imx27.c
+++ b/arch/arm/mach-mx2/clock_imx27.c
@@ -642,7 +642,7 @@ static struct clk_lookup lookups[] = {
_REGISTER_CLOCK(spi_imx.1, NULL, cspi2_clk)
_REGISTER_CLOCK(spi_imx.2, NULL, cspi3_clk)
_REGISTER_CLOCK(imx-fb.0, NULL, lcdc_clk)
-   _REGISTER_CLOCK(NULL, csi, csi_clk)
+   _REGISTER_CLOCK(mx27-camera.0, NULL, csi_clk)
_REGISTER_CLOCK(fsl-usb2-udc, usb, usb_clk)
_REGISTER_CLOCK(fsl-usb2-udc, usb_ahb, usb_clk1)
_REGISTER_CLOCK(mxc-ehci.0, usb, usb_clk)
diff --git a/arch/arm/mach-mx2/devices.c b/arch/arm/mach-mx2/devices.c
index 3d398ce..d47ea55 100644
--- a/arch/arm/mach-mx2/devices.c
+++ b/arch/arm/mach-mx2/devices.c
@@ -31,6 +31,7 @@
 #include linux/init.h
 #include linux/platform_device.h
 #include linux/gpio.h
+#include linux/dma-mapping.h
 
 #include mach/irqs.h
 #include mach/hardware.h
@@ -39,6 +40,37 @@
 
 #include devices.h
 
+#ifdef CONFIG_MACH_MX27
+static struct resource mx27_camera_resources[] = {
+   {
+  .start = CSI_BASE_ADDR,
+  .end = CSI_BASE_ADDR + 0x1f,
+  .flags = IORESOURCE_MEM,
+   }, {
+  .start = EMMA_PRP_BASE_ADDR,
+  .end = EMMA_PRP_BASE_ADDR + 0x1f,
+  .flags = IORESOURCE_MEM,
+   }, {
+  .start = MXC_INT_CSI,
+  .end = MXC_INT_CSI,
+  .flags = IORESOURCE_IRQ,
+   },{
+  .start = MXC_INT_EMMAPRP,
+  .end = MXC_INT_EMMAPRP,
+  .flags = IORESOURCE_IRQ,
+   },
+};
+struct platform_device mx27_camera_device = {
+   .name = mx27-camera,
+   .id = 0,
+   .num_resources = ARRAY_SIZE(mx27_camera_resources),
+   .resource = mx27_camera_resources,
+   .dev = {
+   .coherent_dma_mask = 0x,
+   },
+};
+#endif
+
 /*
  * SPI master controller
  *
diff --git a/arch/arm/mach-mx2/devices.h b/arch/arm/mach-mx2/devices.h
index 97306aa..58ce4dc 100644
--- a/arch/arm/mach-mx2/devices.h
+++ b/arch/arm/mach-mx2/devices.h
@@ -20,6 +20,7 @@ extern struct platform_device mxc_i2c_device1;
 extern struct platform_device mxc_sdhc_device0;
 extern struct platform_device mxc_sdhc_device1;
 extern struct platform_device mxc_otg_udc_device;
+extern struct platform_device mx27_camera_device;
 extern struct platform_device mxc_otg_host;
 extern struct platform_device mxc_usbh1;
 extern struct platform_device mxc_usbh2;
diff --git a/arch/arm/plat-mxc/include/mach/imx_cam.h 
b/arch/arm/plat-mxc/include/mach/imx_cam.h
new file mode 100644
index 000..2d704ae
--- /dev/null
+++ b/arch/arm/plat-mxc/include/mach/imx_cam.h
@@ -0,0 +1,47 @@
+/*
+imx-cam.h - i.MX27 camera driver header file
+
+Copyright (C) 2003, Intel Corporation
+Copyright (C) 2008, Sascha Hauer s.ha...@pengutronix.de
+
+This program is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 2 of the License, or
+(at your option) any later version.
+
+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., 675 Mass Ave, Cambridge, MA 02139, USA.
+*/
+
+#ifndef __ASM_ARCH_CAMERA_H_
+#define __ASM_ARCH_CAMERA_H_
+
+#define MX27_CAMERA_SWAP16 (1  0)
+#define MX27_CAMERA_EXT_VSYNC  (1  1)
+#define MX27_CAMERA_CCIR   (1  2)
+#define MX27_CAMERA_CCIR_INTERLACE (1  3)
+#define MX27_CAMERA_HSYNC_HIGH (1  4)
+#define MX27_CAMERA_GATED_CLOCK(1  5)
+#define MX27_CAMERA_INV_DATA   (1  6)
+#define MX27_CAMERA_PCLK_SAMPLE_RISING (1  7)
+#define MX27_CAMERA_PACK_DIR_MSB   (1  8)
+
+struct mx27_camera_platform_data {
+   int (*init)(struct platform_device *);
+   int

Re: [PATCH] RFC: mx27: Add soc_camera support

2009-12-15 Thread Alan Carvalho de Assis

Please note: I just get it compiling and loaded correctly on the
mainline kernel.

If you have a board powered by i.MX27 and with a camera supported by
soc_camera driver, I will be glad case you can do a try.

On 12/15/09, Alan Carvalho de Assis acas...@gmail.com wrote:
 This is the soc_camera support developed by Sascha Hauer.
 I just modified original driver to get it working on recent kernel.

 Signed-off-by: Alan Carvalho de Assis acas...@gmail.com
 ---
  arch/arm/mach-mx2/clock_imx27.c  |2 +-
  arch/arm/mach-mx2/devices.c  |   32 +
  arch/arm/mach-mx2/devices.h  |1 +
  arch/arm/plat-mxc/include/mach/imx_cam.h |   47 ++
  drivers/media/video/Kconfig  |   13 +
  drivers/media/video/Makefile |3 +
  drivers/media/video/mx27_camera.c| 1224
 ++
  7 files changed, 1321 insertions(+), 1 deletions(-)
  create mode 100644 arch/arm/plat-mxc/include/mach/imx_cam.h
  create mode 100644 drivers/media/video/mx27_camera.c

 diff --git a/arch/arm/mach-mx2/clock_imx27.c
 b/arch/arm/mach-mx2/clock_imx27.c
 index b010bf9..1ad0408 100644
 --- a/arch/arm/mach-mx2/clock_imx27.c
 +++ b/arch/arm/mach-mx2/clock_imx27.c
 @@ -642,7 +642,7 @@ static struct clk_lookup lookups[] = {
   _REGISTER_CLOCK(spi_imx.1, NULL, cspi2_clk)
   _REGISTER_CLOCK(spi_imx.2, NULL, cspi3_clk)
   _REGISTER_CLOCK(imx-fb.0, NULL, lcdc_clk)
 - _REGISTER_CLOCK(NULL, csi, csi_clk)
 + _REGISTER_CLOCK(mx27-camera.0, NULL, csi_clk)
   _REGISTER_CLOCK(fsl-usb2-udc, usb, usb_clk)
   _REGISTER_CLOCK(fsl-usb2-udc, usb_ahb, usb_clk1)
   _REGISTER_CLOCK(mxc-ehci.0, usb, usb_clk)
 diff --git a/arch/arm/mach-mx2/devices.c b/arch/arm/mach-mx2/devices.c
 index 3d398ce..d47ea55 100644
 --- a/arch/arm/mach-mx2/devices.c
 +++ b/arch/arm/mach-mx2/devices.c
 @@ -31,6 +31,7 @@
  #include linux/init.h
  #include linux/platform_device.h
  #include linux/gpio.h
 +#include linux/dma-mapping.h

  #include mach/irqs.h
  #include mach/hardware.h
 @@ -39,6 +40,37 @@

  #include devices.h

 +#ifdef CONFIG_MACH_MX27
 +static struct resource mx27_camera_resources[] = {
 + {
 +.start = CSI_BASE_ADDR,
 +.end = CSI_BASE_ADDR + 0x1f,
 +.flags = IORESOURCE_MEM,
 + }, {
 +.start = EMMA_PRP_BASE_ADDR,
 +.end = EMMA_PRP_BASE_ADDR + 0x1f,
 +.flags = IORESOURCE_MEM,
 + }, {
 +.start = MXC_INT_CSI,
 +.end = MXC_INT_CSI,
 +.flags = IORESOURCE_IRQ,
 + },{
 +.start = MXC_INT_EMMAPRP,
 +.end = MXC_INT_EMMAPRP,
 +.flags = IORESOURCE_IRQ,
 + },
 +};
 +struct platform_device mx27_camera_device = {
 + .name = mx27-camera,
 + .id = 0,
 + .num_resources = ARRAY_SIZE(mx27_camera_resources),
 + .resource = mx27_camera_resources,
 + .dev = {
 + .coherent_dma_mask = 0x,
 + },
 +};
 +#endif
 +
  /*
   * SPI master controller
   *
 diff --git a/arch/arm/mach-mx2/devices.h b/arch/arm/mach-mx2/devices.h
 index 97306aa..58ce4dc 100644
 --- a/arch/arm/mach-mx2/devices.h
 +++ b/arch/arm/mach-mx2/devices.h
 @@ -20,6 +20,7 @@ extern struct platform_device mxc_i2c_device1;
  extern struct platform_device mxc_sdhc_device0;
  extern struct platform_device mxc_sdhc_device1;
  extern struct platform_device mxc_otg_udc_device;
 +extern struct platform_device mx27_camera_device;
  extern struct platform_device mxc_otg_host;
  extern struct platform_device mxc_usbh1;
  extern struct platform_device mxc_usbh2;
 diff --git a/arch/arm/plat-mxc/include/mach/imx_cam.h
 b/arch/arm/plat-mxc/include/mach/imx_cam.h
 new file mode 100644
 index 000..2d704ae
 --- /dev/null
 +++ b/arch/arm/plat-mxc/include/mach/imx_cam.h
 @@ -0,0 +1,47 @@
 +/*
 +imx-cam.h - i.MX27 camera driver header file
 +
 +Copyright (C) 2003, Intel Corporation
 +Copyright (C) 2008, Sascha Hauer s.ha...@pengutronix.de
 +
 +This program is free software; you can redistribute it and/or modify
 +it under the terms of the GNU General Public License as published by
 +the Free Software Foundation; either version 2 of the License, or
 +(at your option) any later version.
 +
 +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., 675 Mass Ave, Cambridge, MA 02139, USA.
 +*/
 +
 +#ifndef __ASM_ARCH_CAMERA_H_
 +#define __ASM_ARCH_CAMERA_H_
 +
 +#define MX27_CAMERA_SWAP16   (1  0)
 +#define MX27_CAMERA_EXT_VSYNC(1  1)
 +#define MX27_CAMERA_CCIR (1  2)
 +#define MX27_CAMERA_CCIR_INTERLACE   (1  3)
 +#define

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

2009-12-15 Thread Mauro Carvalho Chehab

Jon Smirl wrote:
 On Tue, Dec 15, 2009 at 8:33 AM, Mauro Carvalho Chehab
 mche...@redhat.com wrote:
 Pavel Machek wrote:
 That is why I think we should go the other way around - introduce the
 core which receivers could plug into and decoder framework and once it
 is ready register lirc-dev as one of the available decoders.

 I've committed already some IR restruct code on my linux-next -git tree:

 http://git.kernel.org/?p=linux/kernel/git/mchehab/linux-next.git

 The code there basically moves the input/evdev registering code and
 scancode/keycode management code into a separate ir-core module.

 To make my life easy, I've moved the code temporarily into 
 drivers/media/IR.
 This way, it helps me to move V4L specific code outside ir-core and to 
 later
 use it for DVB. After having it done, probably the better is to move it to
 be under /drivers or /drivers/input.
 Well, -next is for stuff to be merged into 2.6.34. You are quite an
 optimist.
   Pavel
 Well, we need those changes anyway for the in-kernel drivers, and I'm not 
 seeing
 on the current patches any reason for not having them for 2.6.34.

 I've added all the ir-core patches I did so far at linux-next. This helps 
 people
 to review and contribute.

 The patches are already working with the in-kernel em28xx driver, allowing to
 replace the keycode table and the protocol used by the hardware IR decoder.
 I tested here by replacing an RC-5 based IR table (Hauppauge Grey) by a NEC
 based IR table (Terratec Cinergy XS remote controller).

 The current Remote Controller core module (ir-core) is currently doing:

- Implementation of the existing EVIO[G|S]KEYCODE, expanding/feeing 
 memory
 dynamically, based on the needed size for scancode/keycode table;

- scancodes can be up to 16 bits currently;

- sysfs is registering /sys/class/irrcv and creating one branch for 
 each
 different RC receiver, numbering from irrcv0 to irrcv255;

- one irrcv note is created: current_protocol;

- reading /sys/class/irrcv/irrcv*/current_protocol returns the 
 protocol
 currently used by the driver;

- writing to /sys/class/irrcv/irrcv*/current_protocol changes the 
 protocol
 to a new one, by calling a callback, asking the driver to change the 
 protocol. If
 the protocol is not support, it returns -EINVAL;

- all V4L drivers are already using ir-core;

- em28xx driver is implementing current_protocol show/store support.

 TODO:
 
 I'd add a pulse based receiver like a MSMCE to make sure the core API is 
 right.
 MSME has transmit hardware too.

Makes sense. This can be done after having the lirc_dev integrated.

 What about creating multiple evdev devices with their own keymaps off
 from a single receiver? That's a key part of making multi-function
 remotes work.

I was sure I missed something at the TODO :)

  
 
1) Port DVB drivers to use ir-core, removing the duplicated (and 
 incomplete
  - as table size can't change on DVB's implementation) code that 
 exists there;

2) add current_protocol support on other drivers;

3) link the corresponding input/evdev interfaces with 
 /sys/class/irrcv/irrcv*;

4) make the keytable.c application aware of the sysfs vars;

5) add an attribute to uniquely identify a remote controller;

6) write or convert an existing application to load IR tables at 
 runtime;

7) get the complete 16-bit scancodes used by V4L drivers;

8) add decoder/lirc_dev glue to ir-core;

9) add lirc_dev module and in-kernel decoders;

10) extend keycode table replacement to support big/variable sized 
 scancodes;

11) rename IR-RC;

12) redesign or remove ir-common module. It currently handles 
 in-kernel
keycode tables and a few helper routines for raw pulse/space 
 decode;

13) move drivers/media/IR to a better place;


So, we have also at the todo list:

14) add pulse based drivers;

15) make in-kernel pulse-based devices to use lirc_dev;

16) add an API to dynamically create evdev interfaces for scancode 
filtering;


 comments:

Tasks (1) to (6) for sure can happen to 2.6.34, depending on people's 
 spare
 time for it;

(7) is probably the more complex task, since it requires to re-test 
 all in-kernel
 supported remote controlle scancode/keycode tables, to get the complete IR 
 keycode
 and rewrite the getkeycode functions that are currently masking the IR code 
 into 7 bits.
 We'll need users help on this task, but this can be done gradually, like I 
 did with
 two RC keytables on em28xx driver, while preserving the other keytables 
 as-is.

(8) I suggest that this glue will be submitted together with lirc_dev 
 patch
 series, as the biggest client for it is lirc. In principle, kfifo seems the 
 better
 interface for lirc_dev - decoders interface.

Re: PATCH- gspca: added chipset revision sensor

2009-12-15 Thread Luis Maia


Jean-Francois Moine wrote:

On Tue, 15 Dec 2009 03:45:00 +
Luis Maia lm...@royalhat.org wrote:

  
Added extra chipset revision (sensor) to fix camera zc0301 with  ID: 
0ac8:301b .

Since i own one of this cameras fixed and tested it.



  

-

diff -uNr linux-2.6.32.1/drivers/media/video/gspca/zc3xx.c 
linux-2.6.32.1-patch/drivers/media/video/gspca/zc3xx.c
--- linux-2.6.32.1/drivers/media/video/gspca/zc3xx.c2009-12-14 
17:47:25.0 +

+++ linux-2.6.32.1-patch/drivers/media/video/gspca/zc3xx.c
2009-12-15 02:42:13.0 +
@@ -6868,6 +6868,7 @@
 {0x8001, 0x13},
 {0x8000, 0x14},/* CS2102K */
 {0x8400, 0x15},/* TAS5130K */
+{0xe400, 0x15},
 };
 
 static int vga_3wr_probe(struct gspca_dev *gspca_dev)

@@ -7634,7 +7635,7 @@
 {USB_DEVICE(0x0698, 0x2003)},
 {USB_DEVICE(0x0ac8, 0x0301), .driver_info = SENSOR_PAS106},
 {USB_DEVICE(0x0ac8, 0x0302), .driver_info = SENSOR_PAS106},
-{USB_DEVICE(0x0ac8, 0x301b)},
+{USB_DEVICE(0x0ac8, 0x301b), .driver_info = SENSOR_PB0330},
 {USB_DEVICE(0x0ac8, 0x303b)},
 {USB_DEVICE(0x0ac8, 0x305b), .driver_info =
SENSOR_TAS5130C_VF0250}, {USB_DEVICE(0x0ac8, 0x307b)},



Hello Luis,

I don't understand your patch:
1) you added 0xe400 in the chipset table giving the sensor tas5130c K
2) in the device table you say that the 0ac8:301b sensor is a pb0330
   (but this information is not used: the sensor type in .driver_info
   may be only pas106 for sif probe or mc501cb/tas5130_vf0250 for no
   probe.

What is exactly the sensor of your webcam?

  


Sensor for my webcam is tas5130K, sorry my bad .i forgot to remove the line 
from .driver_info and didn't noticed.
Thus correct information is on the device table.
I bought a pack of webcams from the same suplier with same model for friends, 
i'm waiting for feedback from the patch.


--
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] isl6421.c - added tone control and temporary diseqc overcurrent

2009-12-15 Thread HoP

Hi Mauro,

I have finally found some time for reworking our patch
with regards of notes I got in disscussion.

BTW, I learnt that sending patch for review to original
authors is right thing (tm), so I have added Oliver,
as isl6421.c author, Patrick as flexcop author, Gerd
as cx88/saa7134 author (I hope I found correct persons,
if no please ignore posting).

Regards

/Honza

---

isl6421.c - added tone control and temporary diseqc overcurrent

Signed-off-by: Jan Petrous jpetr...@gmail.com
Signed-off-by: Ales Jurik aju...@quick.cz


isl6421-v2.patch
Description: Binary data

[PATCH - v3 4/4] DaVinci - vpfe-capture-converting ccdc drivers to platform driver

From: Muralidharan Karicheri m-kariche...@ti.com

This combines the two patches sent earlier to change the clock configuration
and converting ccdc drivers to platform drivers. This has updated comments
against v2 of these patches. Two new clocks master and slave are defined 
for ccdc driver
as per comments from Kevin Hilman.

This adds platform code for ccdc driver on DM355 and DM6446.

Reviewed-by: Vaibhav Hiremath hvaib...@ti.com
Reviewed-by: Kevin Hilman khil...@deeprootsystems.com

Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
Applies to linux-davinci tree
 arch/arm/mach-davinci/dm355.c  |   41 ---
 arch/arm/mach-davinci/dm644x.c |   20 ++-
 2 files changed, 48 insertions(+), 13 deletions(-)

diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
index 2244e8c..a9ea761 100644
--- a/arch/arm/mach-davinci/dm355.c
+++ b/arch/arm/mach-davinci/dm355.c
@@ -378,6 +378,8 @@ static struct davinci_clk dm355_clks[] = {
CLK(NULL, timer3, timer3_clk),
CLK(NULL, rto, rto_clk),
CLK(NULL, usb, usb_clk),
+   CLK(dm355_ccdc, master, vpss_master_clk),
+   CLK(dm355_ccdc, slave, vpss_slave_clk),
CLK(NULL, NULL, NULL),
 };
 
@@ -665,6 +667,17 @@ static struct platform_device dm355_asp1_device = {
.resource   = dm355_asp1_resources,
 };
 
+static void dm355_ccdc_setup_pinmux(void)
+{
+   davinci_cfg_reg(DM355_VIN_PCLK);
+   davinci_cfg_reg(DM355_VIN_CAM_WEN);
+   davinci_cfg_reg(DM355_VIN_CAM_VD);
+   davinci_cfg_reg(DM355_VIN_CAM_HD);
+   davinci_cfg_reg(DM355_VIN_YIN_EN);
+   davinci_cfg_reg(DM355_VIN_CINL_EN);
+   davinci_cfg_reg(DM355_VIN_CINH_EN);
+}
+
 static struct resource dm355_vpss_resources[] = {
{
/* VPSS BL Base address */
@@ -701,6 +714,10 @@ static struct resource vpfe_resources[] = {
.end= IRQ_VDINT1,
.flags  = IORESOURCE_IRQ,
},
+};
+
+static u64 vpfe_capture_dma_mask = DMA_BIT_MASK(32);
+static struct resource dm355_ccdc_resource[] = {
/* CCDC Base address */
{
.flags  = IORESOURCE_MEM,
@@ -708,8 +725,18 @@ static struct resource vpfe_resources[] = {
.end= 0x01c70600 + 0x1ff,
},
 };
+static struct platform_device dm355_ccdc_dev = {
+   .name   = dm355_ccdc,
+   .id = -1,
+   .num_resources  = ARRAY_SIZE(dm355_ccdc_resource),
+   .resource   = dm355_ccdc_resource,
+   .dev = {
+   .dma_mask   = vpfe_capture_dma_mask,
+   .coherent_dma_mask  = DMA_BIT_MASK(32),
+   .platform_data  = dm355_ccdc_setup_pinmux,
+   },
+};
 
-static u64 vpfe_capture_dma_mask = DMA_BIT_MASK(32);
 static struct platform_device vpfe_capture_dev = {
.name   = CAPTURE_DRV_NAME,
.id = -1,
@@ -860,17 +887,7 @@ static int __init dm355_init_devices(void)
davinci_cfg_reg(DM355_INT_EDMA_CC);
platform_device_register(dm355_edma_device);
platform_device_register(dm355_vpss_device);
-   /*
-* setup Mux configuration for vpfe input and register
-* vpfe capture platform device
-*/
-   davinci_cfg_reg(DM355_VIN_PCLK);
-   davinci_cfg_reg(DM355_VIN_CAM_WEN);
-   davinci_cfg_reg(DM355_VIN_CAM_VD);
-   davinci_cfg_reg(DM355_VIN_CAM_HD);
-   davinci_cfg_reg(DM355_VIN_YIN_EN);
-   davinci_cfg_reg(DM355_VIN_CINL_EN);
-   davinci_cfg_reg(DM355_VIN_CINH_EN);
+   platform_device_register(dm355_ccdc_dev);
platform_device_register(vpfe_capture_dev);
 
return 0;
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index e65e29e..e5f1ee9 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -315,6 +315,8 @@ struct davinci_clk dm644x_clks[] = {
CLK(NULL, timer0, timer0_clk),
CLK(NULL, timer1, timer1_clk),
CLK(watchdog, NULL, timer2_clk),
+   CLK(dm644x_ccdc, master, vpss_master_clk),
+   CLK(dm644x_ccdc, slave, vpss_slave_clk),
CLK(NULL, NULL, NULL),
 };
 
@@ -612,6 +614,11 @@ static struct resource vpfe_resources[] = {
.end= IRQ_VDINT1,
.flags  = IORESOURCE_IRQ,
},
+};
+
+static u64 vpfe_capture_dma_mask = DMA_BIT_MASK(32);
+static struct resource dm644x_ccdc_resource[] = {
+   /* CCDC Base address */
{
.start  = 0x01c70400,
.end= 0x01c70400 + 0xff,
@@ -619,7 +626,17 @@ static struct resource vpfe_resources[] = {
},
 };
 
-static u64 vpfe_capture_dma_mask = DMA_BIT_MASK(32);
+static struct platform_device dm644x_ccdc_dev = {
+   .name   = dm644x_ccdc,
+   .id = -1,
+   .num_resources  = ARRAY_SIZE(dm644x_ccdc_resource),
+   .resource

[PATCH - v3 3/4] V4L - vpfe capture - convert dm644x ccdc module to a platform driver

From: Muralidharan Karicheri m-kariche...@ti.com

Updated based on Kevin's comments on clock configuration.
The ccdc now uses a generic name for clocks. master and slave. On individual 
platforms
these clocks will inherit from the platform specific clock. This will allow 
re-use of
the driver for the same IP across different SoCs.

Following are the changes done:-
1) clocks are configured using generic clock names
2) converting the driver to a platform driver
3) cleanup - consolidate all static variables inside a structure, 
ccdc_cfg

Reviewed-by: Kevin Hilman khil...@deeprootsystems.com
Reviewed-by: Vaibhav Hiremath hvaib...@ti.com

Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
Applies to linux-next branch of v4l-dvb
 drivers/media/video/davinci/dm644x_ccdc.c |  360 ++---
 1 files changed, 224 insertions(+), 136 deletions(-)

diff --git a/drivers/media/video/davinci/dm644x_ccdc.c 
b/drivers/media/video/davinci/dm644x_ccdc.c
index d5fa193..1cb308b 100644
--- a/drivers/media/video/davinci/dm644x_ccdc.c
+++ b/drivers/media/video/davinci/dm644x_ccdc.c
@@ -37,8 +37,11 @@
 #include linux/platform_device.h
 #include linux/uaccess.h
 #include linux/videodev2.h
+#include linux/clk.h
+
 #include media/davinci/dm644x_ccdc.h
 #include media/davinci/vpss.h
+
 #include dm644x_ccdc_regs.h
 #include ccdc_hw_device.h
 
@@ -46,32 +49,44 @@ MODULE_LICENSE(GPL);
 MODULE_DESCRIPTION(CCDC Driver for DM6446);
 MODULE_AUTHOR(Texas Instruments);
 
-static struct device *dev;
-
-/* Object for CCDC raw mode */
-static struct ccdc_params_raw ccdc_hw_params_raw = {
-   .pix_fmt = CCDC_PIXFMT_RAW,
-   .frm_fmt = CCDC_FRMFMT_PROGRESSIVE,
-   .win = CCDC_WIN_VGA,
-   .fid_pol = VPFE_PINPOL_POSITIVE,
-   .vd_pol = VPFE_PINPOL_POSITIVE,
-   .hd_pol = VPFE_PINPOL_POSITIVE,
-   .config_params = {
-   .data_sz = CCDC_DATA_10BITS,
+static struct ccdc_oper_config {
+   struct device *dev;
+   /* CCDC interface type */
+   enum vpfe_hw_if_type if_type;
+   /* Raw Bayer configuration */
+   struct ccdc_params_raw bayer;
+   /* YCbCr configuration */
+   struct ccdc_params_ycbcr ycbcr;
+   /* Master clock */
+   struct clk *mclk;
+   /* slave clock */
+   struct clk *sclk;
+   /* ccdc base address */
+   void __iomem *base_addr;
+} ccdc_cfg = {
+   /* Raw configurations */
+   .bayer = {
+   .pix_fmt = CCDC_PIXFMT_RAW,
+   .frm_fmt = CCDC_FRMFMT_PROGRESSIVE,
+   .win = CCDC_WIN_VGA,
+   .fid_pol = VPFE_PINPOL_POSITIVE,
+   .vd_pol = VPFE_PINPOL_POSITIVE,
+   .hd_pol = VPFE_PINPOL_POSITIVE,
+   .config_params = {
+   .data_sz = CCDC_DATA_10BITS,
+   },
+   },
+   .ycbcr = {
+   .pix_fmt = CCDC_PIXFMT_YCBCR_8BIT,
+   .frm_fmt = CCDC_FRMFMT_INTERLACED,
+   .win = CCDC_WIN_PAL,
+   .fid_pol = VPFE_PINPOL_POSITIVE,
+   .vd_pol = VPFE_PINPOL_POSITIVE,
+   .hd_pol = VPFE_PINPOL_POSITIVE,
+   .bt656_enable = 1,
+   .pix_order = CCDC_PIXORDER_CBYCRY,
+   .buf_type = CCDC_BUFTYPE_FLD_INTERLEAVED
},
-};
-
-/* Object for CCDC ycbcr mode */
-static struct ccdc_params_ycbcr ccdc_hw_params_ycbcr = {
-   .pix_fmt = CCDC_PIXFMT_YCBCR_8BIT,
-   .frm_fmt = CCDC_FRMFMT_INTERLACED,
-   .win = CCDC_WIN_PAL,
-   .fid_pol = VPFE_PINPOL_POSITIVE,
-   .vd_pol = VPFE_PINPOL_POSITIVE,
-   .hd_pol = VPFE_PINPOL_POSITIVE,
-   .bt656_enable = 1,
-   .pix_order = CCDC_PIXORDER_CBYCRY,
-   .buf_type = CCDC_BUFTYPE_FLD_INTERLEAVED
 };
 
 #define CCDC_MAX_RAW_YUV_FORMATS   2
@@ -84,25 +99,15 @@ static u32 ccdc_raw_bayer_pix_formats[] =
 static u32 ccdc_raw_yuv_pix_formats[] =
{V4L2_PIX_FMT_UYVY, V4L2_PIX_FMT_YUYV};
 
-static void *__iomem ccdc_base_addr;
-static int ccdc_addr_size;
-static enum vpfe_hw_if_type ccdc_if_type;
-
 /* register access routines */
 static inline u32 regr(u32 offset)
 {
-   return __raw_readl(ccdc_base_addr + offset);
+   return __raw_readl(ccdc_cfg.base_addr + offset);
 }
 
 static inline void regw(u32 val, u32 offset)
 {
-   __raw_writel(val, ccdc_base_addr + offset);
-}
-
-static void ccdc_set_ccdc_base(void *addr, int size)
-{
-   ccdc_base_addr = addr;
-   ccdc_addr_size = size;
+   __raw_writel(val, ccdc_cfg.base_addr + offset);
 }
 
 static void ccdc_enable(int flag)
@@ -132,7 +137,7 @@ void ccdc_setwin(struct v4l2_rect *image_win,
int vert_start, vert_nr_lines;
int val = 0, mid_img = 0;
 
-   dev_dbg(dev, \nStarting ccdc_setwin...);
+   dev_dbg(ccdc_cfg.dev, \nStarting ccdc_setwin...);
/*
 * ppc - per pixel count. indicates how many pixels per cell
 * output to SDRAM. example, for ycbcr, it is one y and one c, so 2.
@@ -171,7 +176,7

[PATCH - v3 2/4] V4L - vpfe capture - convert dm355 ccdc driver to a platform driver

From: Muralidharan Karicheri m-kariche...@ti.com

Updated based on Kevin's comments on clock configuration.
The ccdc now uses a generic name for clocks. master and slave. On 
individual platforms
these clocks will inherit from the platform specific clock. This will allow 
re-use of
the driver for the same IP across different SoCs.

Following are the changes done:-
1) clocks are configured using generic clock names
2) converting the driver to a platform driver
3) cleanup - consolidate all static variables inside a structure, 
ccdc_cfg

Reviewed-by: Kevin Hilman khil...@deeprootsystems.com
Reviewed-by: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
Applies to linux-next branch of v4l-dvb
 drivers/media/video/davinci/dm355_ccdc.c |  409 +++---
 1 files changed, 256 insertions(+), 153 deletions(-)

diff --git a/drivers/media/video/davinci/dm355_ccdc.c 
b/drivers/media/video/davinci/dm355_ccdc.c
index 3143900..6f7100d 100644
--- a/drivers/media/video/davinci/dm355_ccdc.c
+++ b/drivers/media/video/davinci/dm355_ccdc.c
@@ -37,8 +37,11 @@
 #include linux/platform_device.h
 #include linux/uaccess.h
 #include linux/videodev2.h
+#include linux/clk.h
+
 #include media/davinci/dm355_ccdc.h
 #include media/davinci/vpss.h
+
 #include dm355_ccdc_regs.h
 #include ccdc_hw_device.h
 
@@ -46,67 +49,75 @@ MODULE_LICENSE(GPL);
 MODULE_DESCRIPTION(CCDC Driver for DM355);
 MODULE_AUTHOR(Texas Instruments);
 
-static struct device *dev;
-
-/* Object for CCDC raw mode */
-static struct ccdc_params_raw ccdc_hw_params_raw = {
-   .pix_fmt = CCDC_PIXFMT_RAW,
-   .frm_fmt = CCDC_FRMFMT_PROGRESSIVE,
-   .win = CCDC_WIN_VGA,
-   .fid_pol = VPFE_PINPOL_POSITIVE,
-   .vd_pol = VPFE_PINPOL_POSITIVE,
-   .hd_pol = VPFE_PINPOL_POSITIVE,
-   .gain = {
-   .r_ye = 256,
-   .gb_g = 256,
-   .gr_cy = 256,
-   .b_mg = 256
-   },
-   .config_params = {
-   .datasft = 2,
-   .data_sz = CCDC_DATA_10BITS,
-   .mfilt1 = CCDC_NO_MEDIAN_FILTER1,
-   .mfilt2 = CCDC_NO_MEDIAN_FILTER2,
-   .alaw = {
-   .gama_wd = 2,
+static struct ccdc_oper_config {
+   struct device *dev;
+   /* CCDC interface type */
+   enum vpfe_hw_if_type if_type;
+   /* Raw Bayer configuration */
+   struct ccdc_params_raw bayer;
+   /* YCbCr configuration */
+   struct ccdc_params_ycbcr ycbcr;
+   /* Master clock */
+   struct clk *mclk;
+   /* slave clock */
+   struct clk *sclk;
+   /* ccdc base address */
+   void __iomem *base_addr;
+} ccdc_cfg = {
+   /* Raw configurations */
+   .bayer = {
+   .pix_fmt = CCDC_PIXFMT_RAW,
+   .frm_fmt = CCDC_FRMFMT_PROGRESSIVE,
+   .win = CCDC_WIN_VGA,
+   .fid_pol = VPFE_PINPOL_POSITIVE,
+   .vd_pol = VPFE_PINPOL_POSITIVE,
+   .hd_pol = VPFE_PINPOL_POSITIVE,
+   .gain = {
+   .r_ye = 256,
+   .gb_g = 256,
+   .gr_cy = 256,
+   .b_mg = 256
},
-   .blk_clamp = {
-   .sample_pixel = 1,
-   .dc_sub = 25
-   },
-   .col_pat_field0 = {
-   .olop = CCDC_GREEN_BLUE,
-   .olep = CCDC_BLUE,
-   .elop = CCDC_RED,
-   .elep = CCDC_GREEN_RED
-   },
-   .col_pat_field1 = {
-   .olop = CCDC_GREEN_BLUE,
-   .olep = CCDC_BLUE,
-   .elop = CCDC_RED,
-   .elep = CCDC_GREEN_RED
+   .config_params = {
+   .datasft = 2,
+   .mfilt1 = CCDC_NO_MEDIAN_FILTER1,
+   .mfilt2 = CCDC_NO_MEDIAN_FILTER2,
+   .alaw = {
+   .gama_wd = 2,
+   },
+   .blk_clamp = {
+   .sample_pixel = 1,
+   .dc_sub = 25
+   },
+   .col_pat_field0 = {
+   .olop = CCDC_GREEN_BLUE,
+   .olep = CCDC_BLUE,
+   .elop = CCDC_RED,
+   .elep = CCDC_GREEN_RED
+   },
+   .col_pat_field1 = {
+   .olop = CCDC_GREEN_BLUE,
+   .olep = CCDC_BLUE,
+   .elop = CCDC_RED,
+   .elep = CCDC_GREEN_RED
+   },
},
},
+   /* YCbCr configuration */
+   .ycbcr = {
+   .win = CCDC_WIN_PAL,
+

[PATCH - v3 1/4] V4L - vpfe_capture - remove clock and ccdc resource handling

From: Muralidharan Karicheri m-kariche...@ti.com

This combines the two patches sent earlier to change the clock configuration
and converting ccdc drivers to platform drivers. This has updated comments
against v1 of these patches.

In this patch, the clock configuration is moved to ccdc driver since clocks
are configured for ccdc. Also adding proper error codes for ccdc register
function and removing the ccdc memory resource handling.

Reviewed-by: Vaibhav Hiremath hvaib...@ti.com
Reviewed-by: Kevin Hilman khil...@deeprootsystems.com

Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
Applies to linux-next branch of v4l-dvb
 drivers/media/video/davinci/vpfe_capture.c |  134 +++
 1 files changed, 15 insertions(+), 119 deletions(-)

diff --git a/drivers/media/video/davinci/vpfe_capture.c 
b/drivers/media/video/davinci/vpfe_capture.c
index 8dc9030..5c98d0c 100644
--- a/drivers/media/video/davinci/vpfe_capture.c
+++ b/drivers/media/video/davinci/vpfe_capture.c
@@ -108,9 +108,6 @@ struct ccdc_config {
int vpfe_probed;
/* name of ccdc device */
char name[32];
-   /* for storing mem maps for CCDC */
-   int ccdc_addr_size;
-   void *__iomem ccdc_addr;
 };
 
 /* data structures */
@@ -230,7 +227,6 @@ int vpfe_register_ccdc_device(struct ccdc_hw_device *dev)
BUG_ON(!dev-hw_ops.set_image_window);
BUG_ON(!dev-hw_ops.get_image_window);
BUG_ON(!dev-hw_ops.get_line_length);
-   BUG_ON(!dev-hw_ops.setfbaddr);
BUG_ON(!dev-hw_ops.getfid);
 
mutex_lock(ccdc_lock);
@@ -241,25 +237,23 @@ int vpfe_register_ccdc_device(struct ccdc_hw_device *dev)
 * walk through it during vpfe probe
 */
printk(KERN_ERR vpfe capture not initialized\n);
-   ret = -1;
+   ret = -EFAULT;
goto unlock;
}
 
if (strcmp(dev-name, ccdc_cfg-name)) {
/* ignore this ccdc */
-   ret = -1;
+   ret = -EINVAL;
goto unlock;
}
 
if (ccdc_dev) {
printk(KERN_ERR ccdc already registered\n);
-   ret = -1;
+   ret = -EINVAL;
goto unlock;
}
 
ccdc_dev = dev;
-   dev-hw_ops.set_ccdc_base(ccdc_cfg-ccdc_addr,
- ccdc_cfg-ccdc_addr_size);
 unlock:
mutex_unlock(ccdc_lock);
return ret;
@@ -1787,61 +1781,6 @@ static struct vpfe_device *vpfe_initialize(void)
return vpfe_dev;
 }
 
-static void vpfe_disable_clock(struct vpfe_device *vpfe_dev)
-{
-   struct vpfe_config *vpfe_cfg = vpfe_dev-cfg;
-
-   clk_disable(vpfe_cfg-vpssclk);
-   clk_put(vpfe_cfg-vpssclk);
-   clk_disable(vpfe_cfg-slaveclk);
-   clk_put(vpfe_cfg-slaveclk);
-   v4l2_info(vpfe_dev-pdev-driver,
-vpfe vpss master  slave clocks disabled\n);
-}
-
-static int vpfe_enable_clock(struct vpfe_device *vpfe_dev)
-{
-   struct vpfe_config *vpfe_cfg = vpfe_dev-cfg;
-   int ret = -ENOENT;
-
-   vpfe_cfg-vpssclk = clk_get(vpfe_dev-pdev, vpss_master);
-   if (NULL == vpfe_cfg-vpssclk) {
-   v4l2_err(vpfe_dev-pdev-driver, No clock defined for
-vpss_master\n);
-   return ret;
-   }
-
-   if (clk_enable(vpfe_cfg-vpssclk)) {
-   v4l2_err(vpfe_dev-pdev-driver,
-   vpfe vpss master clock not enabled\n);
-   goto out;
-   }
-   v4l2_info(vpfe_dev-pdev-driver,
-vpfe vpss master clock enabled\n);
-
-   vpfe_cfg-slaveclk = clk_get(vpfe_dev-pdev, vpss_slave);
-   if (NULL == vpfe_cfg-slaveclk) {
-   v4l2_err(vpfe_dev-pdev-driver,
-   No clock defined for vpss slave\n);
-   goto out;
-   }
-
-   if (clk_enable(vpfe_cfg-slaveclk)) {
-   v4l2_err(vpfe_dev-pdev-driver,
-vpfe vpss slave clock not enabled\n);
-   goto out;
-   }
-   v4l2_info(vpfe_dev-pdev-driver, vpfe vpss slave clock enabled\n);
-   return 0;
-out:
-   if (vpfe_cfg-vpssclk)
-   clk_put(vpfe_cfg-vpssclk);
-   if (vpfe_cfg-slaveclk)
-   clk_put(vpfe_cfg-slaveclk);
-
-   return -1;
-}
-
 /*
  * vpfe_probe : This function creates device entries by register
  * itself to the V4L2 driver and initializes fields of each
@@ -1871,7 +1810,7 @@ static __init int vpfe_probe(struct platform_device *pdev)
 
if (NULL == pdev-dev.platform_data) {
v4l2_err(pdev-dev.driver, Unable to get vpfe config\n);
-   ret = -ENOENT;
+   ret = -ENODEV;
goto probe_free_dev_mem;
}
 
@@ -1885,18 +1824,13 @@ static __init int vpfe_probe(struct platform_device 
*pdev)
goto probe_free_dev_mem;
}
 
-   /* enable vpss clocks */
-   ret =

Re: PATCH- gspca: added chipset revision sensor

2009-12-15 Thread Jean-Francois Moine

On Tue, 15 Dec 2009 10:25:29 -0300
leandro Costantino lcostant...@gmail.com wrote:

 Jean,
 let me know , if you need to the test this patch, since i added the
 tas1530k long time ago, and still have the webcam :)
 Best Regards
 
 On Tue, Dec 15, 2009 at 4:54 AM, Jean-Francois Moine
 moin...@free.fr wrote:
  On Tue, 15 Dec 2009 03:45:00 +
  Luis Maia lm...@royalhat.org wrote:
 
  Added extra chipset revision (sensor) to fix camera zc0301 with
   ID: 0ac8:301b .
  Since i own one of this cameras fixed and tested it.
 
  -
 
  diff -uNr linux-2.6.32.1/drivers/media/video/gspca/zc3xx.c
  linux-2.6.32.1-patch/drivers/media/video/gspca/zc3xx.c
  --- linux-2.6.32.1/drivers/media/video/gspca/zc3xx.c    2009-12-14
  17:47:25.0 +
  +++ linux-2.6.32.1-patch/drivers/media/video/gspca/zc3xx.c
  2009-12-15 02:42:13.0 +
  @@ -6868,6 +6868,7 @@
       {0x8001, 0x13},
       {0x8000, 0x14},        /* CS2102K */
       {0x8400, 0x15},        /* TAS5130K */
  +    {0xe400, 0x15},
   };
 
   static int vga_3wr_probe(struct gspca_dev *gspca_dev)
  @@ -7634,7 +7635,7 @@
       {USB_DEVICE(0x0698, 0x2003)},
       {USB_DEVICE(0x0ac8, 0x0301), .driver_info = SENSOR_PAS106},
       {USB_DEVICE(0x0ac8, 0x0302), .driver_info = SENSOR_PAS106},
  -    {USB_DEVICE(0x0ac8, 0x301b)},
  +    {USB_DEVICE(0x0ac8, 0x301b), .driver_info = SENSOR_PB0330},
       {USB_DEVICE(0x0ac8, 0x303b)},
       {USB_DEVICE(0x0ac8, 0x305b), .driver_info =
  SENSOR_TAS5130C_VF0250}, {USB_DEVICE(0x0ac8, 0x307b)},

Hello Luis and Leandro,

Thanks for the patch. Luis said his sensor is the tas5130K, so the 2nd
part of the patch is useless. But, maybe, Leandro, have you heard about
other chipset revision IDs?

Best regards.

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

FW: [PATCH - v3 1/4] V4L - vpfe_capture - remove clock and ccdc resource handling

2009-12-15 Thread Karicheri, Muralidharan

Hans,

This has gone through multiple revisions after review and If you don't
have any comments against this series, could you merge this to your -hg
tree? DM365 patch series is dependent on this one. So if you can merge
this one ASAP, it will be great. 

Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-kariche...@ti.com

-Original Message-
From: Karicheri, Muralidharan
Sent: Tuesday, December 15, 2009 11:38 AM
To: linux-media@vger.kernel.org; hverk...@xs4all.nl;
khil...@deeprootsystems.com
Cc: davinci-linux-open-sou...@linux.davincidsp.com; Karicheri, Muralidharan
Subject: [PATCH - v3 1/4] V4L - vpfe_capture - remove clock and ccdc
resource handling

From: Muralidharan Karicheri m-kariche...@ti.com

This combines the two patches sent earlier to change the clock
configuration
and converting ccdc drivers to platform drivers. This has updated comments
against v1 of these patches.

In this patch, the clock configuration is moved to ccdc driver since clocks
are configured for ccdc. Also adding proper error codes for ccdc register
function and removing the ccdc memory resource handling.

Reviewed-by: Vaibhav Hiremath hvaib...@ti.com
Reviewed-by: Kevin Hilman khil...@deeprootsystems.com

Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
Applies to linux-next branch of v4l-dvb
 drivers/media/video/davinci/vpfe_capture.c |  134 +++-
---
 1 files changed, 15 insertions(+), 119 deletions(-)

diff --git a/drivers/media/video/davinci/vpfe_capture.c
b/drivers/media/video/davinci/vpfe_capture.c
index 8dc9030..5c98d0c 100644
--- a/drivers/media/video/davinci/vpfe_capture.c
+++ b/drivers/media/video/davinci/vpfe_capture.c
@@ -108,9 +108,6 @@ struct ccdc_config {
   int vpfe_probed;
   /* name of ccdc device */
   char name[32];
-  /* for storing mem maps for CCDC */
-  int ccdc_addr_size;
-  void *__iomem ccdc_addr;
 };

 /* data structures */
@@ -230,7 +227,6 @@ int vpfe_register_ccdc_device(struct ccdc_hw_device
*dev)
   BUG_ON(!dev-hw_ops.set_image_window);
   BUG_ON(!dev-hw_ops.get_image_window);
   BUG_ON(!dev-hw_ops.get_line_length);
-  BUG_ON(!dev-hw_ops.setfbaddr);
   BUG_ON(!dev-hw_ops.getfid);

   mutex_lock(ccdc_lock);
@@ -241,25 +237,23 @@ int vpfe_register_ccdc_device(struct ccdc_hw_device
*dev)
* walk through it during vpfe probe
*/
   printk(KERN_ERR vpfe capture not initialized\n);
-  ret = -1;
+  ret = -EFAULT;
   goto unlock;
   }

   if (strcmp(dev-name, ccdc_cfg-name)) {
   /* ignore this ccdc */
-  ret = -1;
+  ret = -EINVAL;
   goto unlock;
   }

   if (ccdc_dev) {
   printk(KERN_ERR ccdc already registered\n);
-  ret = -1;
+  ret = -EINVAL;
   goto unlock;
   }

   ccdc_dev = dev;
-  dev-hw_ops.set_ccdc_base(ccdc_cfg-ccdc_addr,
-ccdc_cfg-ccdc_addr_size);
 unlock:
   mutex_unlock(ccdc_lock);
   return ret;
@@ -1787,61 +1781,6 @@ static struct vpfe_device *vpfe_initialize(void)
   return vpfe_dev;
 }

-static void vpfe_disable_clock(struct vpfe_device *vpfe_dev)
-{
-  struct vpfe_config *vpfe_cfg = vpfe_dev-cfg;
-
-  clk_disable(vpfe_cfg-vpssclk);
-  clk_put(vpfe_cfg-vpssclk);
-  clk_disable(vpfe_cfg-slaveclk);
-  clk_put(vpfe_cfg-slaveclk);
-  v4l2_info(vpfe_dev-pdev-driver,
-   vpfe vpss master  slave clocks disabled\n);
-}
-
-static int vpfe_enable_clock(struct vpfe_device *vpfe_dev)
-{
-  struct vpfe_config *vpfe_cfg = vpfe_dev-cfg;
-  int ret = -ENOENT;
-
-  vpfe_cfg-vpssclk = clk_get(vpfe_dev-pdev, vpss_master);
-  if (NULL == vpfe_cfg-vpssclk) {
-  v4l2_err(vpfe_dev-pdev-driver, No clock defined for
-   vpss_master\n);
-  return ret;
-  }
-
-  if (clk_enable(vpfe_cfg-vpssclk)) {
-  v4l2_err(vpfe_dev-pdev-driver,
-  vpfe vpss master clock not enabled\n);
-  goto out;
-  }
-  v4l2_info(vpfe_dev-pdev-driver,
-   vpfe vpss master clock enabled\n);
-
-  vpfe_cfg-slaveclk = clk_get(vpfe_dev-pdev, vpss_slave);
-  if (NULL == vpfe_cfg-slaveclk) {
-  v4l2_err(vpfe_dev-pdev-driver,
-  No clock defined for vpss slave\n);
-  goto out;
-  }
-
-  if (clk_enable(vpfe_cfg-slaveclk)) {
-  v4l2_err(vpfe_dev-pdev-driver,
-   vpfe vpss slave clock not enabled\n);
-  goto out;
-  }
-  v4l2_info(vpfe_dev-pdev-driver, vpfe vpss slave clock enabled\n);
-  return 0;
-out:
-  if (vpfe_cfg-vpssclk)
-  clk_put(vpfe_cfg-vpssclk);
-  if (vpfe_cfg-slaveclk)
-  clk_put(vpfe_cfg-slaveclk);
-
-  return -1;
-}
-
 /*
  *

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

Hi Mauro,

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

- v4l: vpfe_capture: remove clock and ccdc resource handling
- v4l: vpfe capture: convert dm355 ccdc driver to a platform driver
- v4l: vpfe capture: convert dm644x ccdc module to a platform driver

And after these three patches are pulled in, then this arch patch should also be
merged for git:

http://patchwork.kernel.org/patch/67669/

Thanks,

Hans

diffstat:
p dm355_ccdc.c   |  413 
+++--
 dm644x_ccdc.c  |  362 +++--
 vpfe_capture.c |  134 ++
 3 files changed, 498 insertions(+), 411 deletions(-)


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

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

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:Tue Dec 15 19:00:05 CET 2009
path:http://www.linuxtv.org/hg/v4l-dvb
changeset:   13698:79fc32bba0a0
gcc version: gcc (GCC) 4.3.1
hardware:x86_64
host os: 2.6.26

linux-2.6.30-armv5: OK
linux-2.6.31-armv5: OK
linux-2.6.32-armv5: OK
linux-2.6.32-armv5-davinci: OK
linux-2.6.30-armv5-ixp: OK
linux-2.6.31-armv5-ixp: OK
linux-2.6.32-armv5-ixp: OK
linux-2.6.30-armv5-omap2: OK
linux-2.6.31-armv5-omap2: OK
linux-2.6.32-armv5-omap2: OK
linux-2.6.22.19-i686: ERRORS
linux-2.6.23.12-i686: ERRORS
linux-2.6.24.7-i686: ERRORS
linux-2.6.25.11-i686: ERRORS
linux-2.6.26-i686: WARNINGS
linux-2.6.27-i686: ERRORS
linux-2.6.28-i686: ERRORS
linux-2.6.29.1-i686: ERRORS
linux-2.6.30-i686: ERRORS
linux-2.6.31-i686: ERRORS
linux-2.6.32-i686: ERRORS
linux-2.6.30-m32r: OK
linux-2.6.31-m32r: OK
linux-2.6.32-m32r: OK
linux-2.6.30-mips: WARNINGS
linux-2.6.31-mips: OK
linux-2.6.32-mips: OK
linux-2.6.30-powerpc64: WARNINGS
linux-2.6.31-powerpc64: OK
linux-2.6.32-powerpc64: WARNINGS
linux-2.6.22.19-x86_64: ERRORS
linux-2.6.23.12-x86_64: ERRORS
linux-2.6.24.7-x86_64: ERRORS
linux-2.6.25.11-x86_64: ERRORS
linux-2.6.26-x86_64: WARNINGS
linux-2.6.27-x86_64: OK
linux-2.6.28-x86_64: OK
linux-2.6.29.1-x86_64: WARNINGS
linux-2.6.30-x86_64: OK
linux-2.6.31-x86_64: WARNINGS
linux-2.6.32-x86_64: WARNINGS
spec: OK
sparse (linux-2.6.32): ERRORS
linux-2.6.16.61-i686: ERRORS
linux-2.6.17.14-i686: ERRORS
linux-2.6.18.8-i686: ERRORS
linux-2.6.19.5-i686: ERRORS
linux-2.6.20.21-i686: ERRORS
linux-2.6.21.7-i686: ERRORS
linux-2.6.16.61-x86_64: ERRORS
linux-2.6.17.14-x86_64: ERRORS
linux-2.6.18.8-x86_64: ERRORS
linux-2.6.19.5-x86_64: ERRORS
linux-2.6.20.21-x86_64: ERRORS
linux-2.6.21.7-x86_64: ERRORS

Detailed results are available here:

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

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Tuesday.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 0/4 v11] Support for TVP7002 in DM365

2009-12-15 Thread Santiago Nunez-Corrales


Hi Hans,


I know you'be been busy and in the road lately. Just checking if you had 
the chance to review this version of the code.


Regards,

Hans Verkuil wrote:

On Tuesday 08 December 2009 01:44:43 Santiago Nunez-Corrales wrote:
  

Hans,


Hi. Have you had a chance to look at this version of the driver?



Sorry, no. I hope to have some time on Thursday. I'm abroad for business at
the moment and unfortunately that leaves me with little time for reviewing.

This is not just true for this driver, but also for the dm365 series that was
posted recently. And possibly others that I missed :-(

Regards,

Hans

  

Regards,


Santiago.

Santiago Nunez-Corrales wrote:


This series of patches provide support for the TVP7002 decoder in DM365.

Support includes:

* Inclusion of the chip in v4l2 definitions
* Definition of TVP7002 specific data structures
* Kconfig and Makefile support

This series corrects many issued pointed out by Snehaprabha Narnakaje,
Muralidharan Karicheri, Vaibhav Hiremath and Hans Verkuil and solves
testing problems.  Tested on DM365 TI EVM with resolutions 720p,
10...@60, 576P and 480P with video capture application and video
output in 480P, 576P, 720P and 1080I. This driver depends upon
board-dm365-evm.c and vpfe_capture.c to be ready for complete
integration. Uses the new V4L2 DV API sent by Muralidharan Karicheri.
Removed shadow register values. Removed unnecesary power down and up
of the device (tests work fine). Improved readability.


  

--
Santiago Nunez-Corrales, Eng.
RidgeRun Engineering, LLC

Guayabos, Curridabat
San Jose, Costa Rica
+(506) 2271 1487
+(506) 8313 0536
http://www.ridgerun.com







--
Santiago Nunez-Corrales, Eng.
RidgeRun Engineering, LLC

Guayabos, Curridabat
San Jose, Costa Rica
+(506) 2271 1487
+(506) 8313 0536
http://www.ridgerun.com


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

Re: no locking on dvb-s2 22000 2/3 8PSK transponder on Astra 19.2E with tt s2-3200

2009-12-15 Thread Newsy Paper

yes, this transponder is working again at blog.ors.at they say that they 
updated the modulator. It is working now again but driver still has this bug, 
so it's interesting what the update of the modulator changed exactly.

regards

Newsy

--- Oleg Roitburd oroitb...@gmail.com schrieb am Mo, 14.12.2009:

 Von: Oleg Roitburd oroitb...@gmail.com
 Betreff: Re: no locking on dvb-s2 22000 2/3 8PSK transponder on Astra 19.2E  
 with tt s2-3200
 An: Newsy Paper newspaperman_germ...@yahoo.com
 CC: linux-media@vger.kernel.org
 Datum: Montag, 14. Dezember 2009, 13:07
 2009/12/9 Newsy Paper newspaperman_germ...@yahoo.com:
  Hi,
 
  no matter if I use Igors or Manus driver, there's no
 lock on 11303 h 22000 2/3 8psk. Other users at vdr-portal
 report same problem.
 
  The strange thing is that all other transponders that
 use 22000 2/3 8psk do work but this transponder doesn't. It
 worked fine until december 3rd when uplink moved to Vienna.
 I think they changed a parameter like rolloff or inversion
 and the dvb-s2 part of stb6100 is buggy.
 
 It works again. Very strange.
 
 $ sudo ./scan-s2 -x -2 -O S19.2E ORF.ini
 API major 5, minor 0
 scanning ORF.ini
 using '/dev/dvb/adapter0/frontend0' and
 '/dev/dvb/adapter0/demux0'
 initial transponder DVB-S2 11303000 H 2200 2/3 35 8PSK
 -- Using DVB-S2
  tune to: 11303:hC23M5O35S1:S19.2E:22000:
 DVB-S IF freq is 1553000
  parse_section, section number 0 out of 0...!
 service_id = 0x0
 service_id = 0x132F
 pmt_pid = 0x6B
 service_id = 0x1330
 pmt_pid = 0x6C
 service_id = 0x1331
 pmt_pid = 0x6D
  parse_section, section number 0 out of 0...!
   VIDEO     : PID 0x0DFF
   AUDIO     : PID 0x0E00
   AUDIO     : PID 0x0E01
   AC3       : PID 0x0E03
   TELETEXT  : PID 0x0E04
  parse_section, section number 0 out of 0...!
   CA ID     : PID 0x0D05
   CA ID     : PID 0x1702
   CA ID     : PID 0x1833
   CA ID     : PID 0x0648
   CA ID     : PID 0x0D95
   CA ID     : PID 0x09C4
   VIDEO     : PID 0x0B68
   AUDIO     : PID 0x0B69
   AC3       : PID 0x0B6B
   AUDIO     : PID 0x0B6A
   TELETEXT  : PID 0x0B6D
  parse_section, section number 0 out of 0...!
   CA ID     : PID 0x0D05
   CA ID     : PID 0x1702
   CA ID     : PID 0x1833
   CA ID     : PID 0x0648
   CA ID     : PID 0x0D95
   CA ID     : PID 0x09C4
   VIDEO     : PID 0x0780
   AUDIO     : PID 0x0781
   AC3       : PID 0x0783
   AUDIO     : PID 0x0782
   TELETEXT  : PID 0x0785
  parse_section, section number 0 out of 0...!
 0x03EF 0x132F: pmt_pid 0x006B ORF -- ORF1 HD (running,
 scrambled)
 0x03EF 0x1330: pmt_pid 0x006C ORF -- ORF2 HD (running,
 scrambled)
 0x03EF 0x1331: pmt_pid 0x006D ServusTV -- Servus TV HD
 (running)
  parse_section, section number 0 out of 0...!
 dumping lists (3 services)
 ORF1
 HD;ORF:11303:hC23M5O35S1:S19.2E:22000:1920:1921=ger,1922=ENG;1923=ger:1925:D05,1702,1833,648,D95,9C4:4911:1:1007:0
 ORF2
 HD;ORF:11303:hC23M5O35S1:S19.2E:22000:2920:2921=ger,2922=ENG;2923=ger:2925:D05,1702,1833,648,D95,9C4:4912:1:1007:0
 Servus TV
 HD;ServusTV:11303:hC23M5O35S1:S19.2E:22000:3583:3584=ger,3585=eng;3587=ger:3588:0:4913:1:1007:0
 
 Regards
 
 Oleg Roitburd
 

__
Do You Yahoo!?
Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen 
Massenmails. 
http://mail.yahoo.com 
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

Hi!

   (11) if none is against renaming IR as RC, I'll do it on a next patch;

Call it irc -- infrared remote control. Bluetooth remote controls will
have very different characteristics.

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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: [RFC] What are the goals for the architecture of an in-kernel IR system?

On Tue 2009-12-15 15:14:02, Jon Smirl wrote:
 On Tue, Dec 15, 2009 at 2:58 PM, Pavel Machek pa...@ucw.cz wrote:
  Hi!
 
        (11) if none is against renaming IR as RC, I'll do it on a next 
  patch;
 
  Call it irc -- infrared remote control. Bluetooth remote controls will
  have very different characteristics.
 
 How are they different after the scancode is extracted from the
 network packet? The scancode still needs to be passed to the input
 system, go through a keymap, and end up on an evdev device.
 
 I would expect the code for extracting the scancode to live in the
 networking stack, but after it is recovered the networking code would
 use the same API as IR to submit it to input.

For one thing,  bluetooth (etc) has concept of devices (and reliable
transfer). If you have two same bluetooth remotes, you can tell them
apart, unlike IR.

So yes, keymapping is the same, but that's pretty much it. Decoding
will not be the same (IR is special), etc...
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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: [RFC] What are the goals for the architecture of an in-kernel IR system?

On Tue, Dec 15, 2009 at 3:19 PM, Pavel Machek pa...@ucw.cz wrote:
 On Tue 2009-12-15 15:14:02, Jon Smirl wrote:
 On Tue, Dec 15, 2009 at 2:58 PM, Pavel Machek pa...@ucw.cz wrote:
  Hi!
 
        (11) if none is against renaming IR as RC, I'll do it on a next 
  patch;
 
  Call it irc -- infrared remote control. Bluetooth remote controls will
  have very different characteristics.

 How are they different after the scancode is extracted from the
 network packet? The scancode still needs to be passed to the input
 system, go through a keymap, and end up on an evdev device.

 I would expect the code for extracting the scancode to live in the
 networking stack, but after it is recovered the networking code would
 use the same API as IR to submit it to input.

 For one thing,  bluetooth (etc) has concept of devices (and reliable
 transfer). If you have two same bluetooth remotes, you can tell them
 apart, unlike IR.

IR has the same concept of devices. That's what those codes you enter
into a universal remote do - they set the device.

There are three classes of remotes..
Fixed function - the device is hardwired
Universal - you can change the device
Multi-function - a universal that can be multiple devices - TV, cable,
audio, etc

If you set two Bluetooth remotes both to the same device you can't
tell them apart either.
Two identical fixed function remotes can be distinguished and they
shouldn't be distinguishable.

To distinguish between universal remotes just change the device being emulated.



 So yes, keymapping is the same, but that's pretty much it. Decoding
 will not be the same (IR is special), etc...
                                                                        Pavel

 --
 (english) http://www.livejournal.com/~pavelmachek
 (cesky, pictures) 
 http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html




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

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

On Tue 2009-12-15 15:29:51, Jon Smirl wrote:
 On Tue, Dec 15, 2009 at 3:19 PM, Pavel Machek pa...@ucw.cz wrote:
  On Tue 2009-12-15 15:14:02, Jon Smirl wrote:
  On Tue, Dec 15, 2009 at 2:58 PM, Pavel Machek pa...@ucw.cz wrote:
   Hi!
  
         (11) if none is against renaming IR as RC, I'll do it on a next 
   patch;
  
   Call it irc -- infrared remote control. Bluetooth remote controls will
   have very different characteristics.
 
  How are they different after the scancode is extracted from the
  network packet? The scancode still needs to be passed to the input
  system, go through a keymap, and end up on an evdev device.
 
  I would expect the code for extracting the scancode to live in the
  networking stack, but after it is recovered the networking code would
  use the same API as IR to submit it to input.
 
  For one thing,  bluetooth (etc) has concept of devices (and reliable
  transfer). If you have two same bluetooth remotes, you can tell them
  apart, unlike IR.
 
 IR has the same concept of devices. That's what those codes you enter
 into a universal remote do - they set the device.

They set the device _model_.

 There are three classes of remotes..
 Fixed function - the device is hardwired
 Universal - you can change the device
 Multi-function - a universal that can be multiple devices - TV, cable,
 audio, etc
 
 If you set two Bluetooth remotes both to the same device you can't
 tell them apart either.

Untrue. Like ethernets and wifis, bluetooth devices have unique
addresses. Communication is bidirectional.

Imagine wifi connected bluetooth. It is very different from infrared.

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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: [RFC] What are the goals for the architecture of an in-kernel IR system?

On Tue, Dec 15, 2009 at 3:33 PM, Pavel Machek pa...@ucw.cz wrote:
 On Tue 2009-12-15 15:29:51, Jon Smirl wrote:
 On Tue, Dec 15, 2009 at 3:19 PM, Pavel Machek pa...@ucw.cz wrote:
  On Tue 2009-12-15 15:14:02, Jon Smirl wrote:
  On Tue, Dec 15, 2009 at 2:58 PM, Pavel Machek pa...@ucw.cz wrote:
   Hi!
  
         (11) if none is against renaming IR as RC, I'll do it on a next 
   patch;
  
   Call it irc -- infrared remote control. Bluetooth remote controls will
   have very different characteristics.
 
  How are they different after the scancode is extracted from the
  network packet? The scancode still needs to be passed to the input
  system, go through a keymap, and end up on an evdev device.
 
  I would expect the code for extracting the scancode to live in the
  networking stack, but after it is recovered the networking code would
  use the same API as IR to submit it to input.
 
  For one thing,  bluetooth (etc) has concept of devices (and reliable
  transfer). If you have two same bluetooth remotes, you can tell them
  apart, unlike IR.

 IR has the same concept of devices. That's what those codes you enter
 into a universal remote do - they set the device.

 They set the device _model_.

 There are three classes of remotes..
 Fixed function - the device is hardwired
 Universal - you can change the device
 Multi-function - a universal that can be multiple devices - TV, cable,
 audio, etc

 If you set two Bluetooth remotes both to the same device you can't
 tell them apart either.

 Untrue. Like ethernets and wifis, bluetooth devices have unique
 addresses. Communication is bidirectional.

I agree with that, but the 802.15.4 remote control software I've
worked with ignores the MAC address. You set your remote to send codes
for a specific device.  The mac address of the remote is ignored so
that any remote can control the device.  You don't need to pair
802.15.4 remotes like Bluetooth devices need to be paired.

I haven't played around with a Bluetooth remote. Nothing I own can
send the signals.  How can a Bluetooth remote control multiple devices
in the same room if it needs to be paired?

If it doesn't use this API, how does a Bluetooth remote turn a button
press into a Linux keycode on an evdev device?



 Imagine wifi connected bluetooth. It is very different from infrared.

 --
 (english) http://www.livejournal.com/~pavelmachek
 (cesky, pictures) 
 http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html




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

Re: [PATCH 3/4 v11] TVP7002 driver for DM365

Hi Santiago,

Some quick review comments:

On Monday 30 November 2009 16:51:53 santiago.nu...@ridgerun.com wrote:
 From: Santiago Nunez-Corrales santiago.nu...@ridgerun.com
 
 This patch provides the implementation of the TVP7002 decoder
 driver for DM365. Implemented using the V4L2 DV presets API.
 Removed shadow register values. Testing shows that the device
 needs not to be powered down and up for correct behaviour.
 Improved readability.
 
 Signed-off-by: Santiago Nunez-Corrales santiago.nu...@ridgerun.com
 ---
  drivers/media/video/tvp7002.c | 1227 
 +
  1 files changed, 1227 insertions(+), 0 deletions(-)
  create mode 100644 drivers/media/video/tvp7002.c
 
 diff --git a/drivers/media/video/tvp7002.c b/drivers/media/video/tvp7002.c
 new file mode 100644
 index 000..9ed7b89
 --- /dev/null
 +++ b/drivers/media/video/tvp7002.c
 @@ -0,0 +1,1227 @@
 +/* Texas Instruments Triple 8-/10-BIT 165-/110-MSPS Video and Graphics
 + * Digitizer with Horizontal PLL registers
 + *
 + * Copyright (C) 2009 Texas Instruments Inc
 + * Author: Santiago Nunez-Corrales santiago.nu...@ridgerun.com
 + *
 + * This code is partially based upon the TVP5150 driver
 + * written by Mauro Carvalho Chehab (mche...@infradead.org),
 + * the TVP514x driver written by Vaibhav Hiremath hvaib...@ti.com
 + * and the TVP7002 driver in the TI LSP 2.10.00.14. Revisions by
 + * Muralidharan Karicheri and Snehaprabha Narnakaje (TI).
 + *
 + * This program is free software; you can redistribute it and/or modify
 + * it under the terms of the GNU General Public License as published by
 + * the Free Software Foundation; either version 2 of the License, or
 + * (at your option) any later version.
 + *
 + * 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., 675 Mass Ave, Cambridge, MA 02139, USA.
 + */
 +#include linux/delay.h
 +#include linux/i2c.h
 +#include linux/videodev2.h
 +#include media/tvp7002.h
 +#include media/v4l2-device.h
 +#include media/v4l2-chip-ident.h
 +#include tvp7002_reg.h
 +
 +MODULE_DESCRIPTION(TI TVP7002 Video and Graphics Digitizer driver);
 +MODULE_AUTHOR(Santiago Nunez-Corrales santiago.nu...@ridgerun.com);
 +MODULE_LICENSE(GPL);
 +
 +/* Module Name */
 +#define TVP7002_MODULE_NAME  tvp7002
 +
 +/* I2C retry attempts */
 +#define I2C_RETRY_COUNT  (5)
 +
 +/* End of registers */
 +#define TVP7002_EOR  0x5c
 +
 +/* Read write definition for registers */
 +#define TVP7002_READ 0
 +#define TVP7002_WRITE1
 +#define TVP7002_RESERVED 2
 +
 +/* Interlaced vs progressive mask and shift */
 +#define TVP7002_IP_SHIFT 5
 +#define TVP7002_INPR_MASK(0x01  TVP7002_IP_SHIFT)
 +
 +/* Shift for CPL and LPF registers */
 +#define TVP7002_CL_SHIFT 8
 +#define TVP7002_CL_MASK  0x0f
 +
 +/* Debug functions */
 +static int debug;
 +module_param(debug, bool, 0644);
 +MODULE_PARM_DESC(debug, Debug level (0-2));
 +
 +/* Structure for register values */
 +struct i2c_reg_value {
 + u8 reg;
 + u8 value;
 + u8 type;
 +};
 +
 +/*
 + * Register default values (according to tvp7002 datasheet)
 + * In the case of read-only registers, the value (0xff) is
 + * never written. R/W functionality is controlled by the
 + * writable bit in the register struct definition.
 + */
 +static const struct i2c_reg_value tvp7002_init_default[] = {
 + { TVP7002_CHIP_REV, 0xff, TVP7002_READ },
 + { TVP7002_HPLL_FDBK_DIV_MSBS, 0x67, TVP7002_WRITE },
 + { TVP7002_HPLL_FDBK_DIV_LSBS, 0x20, TVP7002_WRITE },
 + { TVP7002_HPLL_CRTL, 0xa0, TVP7002_WRITE },
 + { TVP7002_HPLL_PHASE_SEL, 0x80, TVP7002_WRITE },
 + { TVP7002_CLAMP_START, 0x32, TVP7002_WRITE },
 + { TVP7002_CLAMP_W, 0x20, TVP7002_WRITE },
 + { TVP7002_HSYNC_OUT_W, 0x60, TVP7002_WRITE },
 + { TVP7002_B_FINE_GAIN, 0x00, TVP7002_WRITE },
 + { TVP7002_G_FINE_GAIN, 0x00, TVP7002_WRITE },
 + { TVP7002_R_FINE_GAIN, 0x00, TVP7002_WRITE },
 + { TVP7002_B_FINE_OFF_MSBS, 0x80, TVP7002_WRITE },
 + { TVP7002_G_FINE_OFF_MSBS, 0x80, TVP7002_WRITE },
 + { TVP7002_R_FINE_OFF_MSBS, 0x80, TVP7002_WRITE },
 + { TVP7002_SYNC_CTL_1, 0x20, TVP7002_WRITE },
 + { TVP7002_HPLL_AND_CLAMP_CTL, 0x2e, TVP7002_WRITE },
 + { TVP7002_SYNC_ON_G_THRS, 0x5d, TVP7002_WRITE },
 + { TVP7002_SYNC_SEPARATOR_THRS, 0x47, TVP7002_WRITE },
 + { TVP7002_HPLL_PRE_COAST, 0x00, TVP7002_WRITE },
 + { TVP7002_HPLL_POST_COAST, 0x00, TVP7002_WRITE },
 + { TVP7002_SYNC_DETECT_STAT, 0xff, TVP7002_READ },
 + { TVP7002_OUT_FORMATTER, 0x47, TVP7002_WRITE },
 + { TVP7002_MISC_CTL_1, 0x01, TVP7002_WRITE },
 +

[PATCH] lgdt3305: make one-bit bitfields unsigned

2009-12-15 Thread Németh Márton

From: Márton Németh nm...@freemail.hu

Make one-bit bitfields unsigned which will remove the following
sparse warning messages (see make C=1):
 * lgdt3305.h:57:21: error: dubious one-bit signed bitfield
 * lgdt3305.h:60:26: error: dubious one-bit signed bitfield
 * lgdt3305.h:63:19: error: dubious one-bit signed bitfield

Signed-off-by: Márton Németh nm...@freemail.hu
---
diff -r ba8d6bf077aa linux/drivers/media/dvb/frontends/lgdt3305.h
--- a/linux/drivers/media/dvb/frontends/lgdt3305.h  Tue Dec 15 17:40:44 
2009 +0100
+++ b/linux/drivers/media/dvb/frontends/lgdt3305.h  Tue Dec 15 21:47:53 
2009 +0100
@@ -54,13 +54,13 @@
u16 usref_qam256; /* default: 0x2a80 */

/* disable i2c repeater - 0:repeater enabled 1:repeater disabled */
-   int deny_i2c_rptr:1;
+   unsigned int deny_i2c_rptr:1;

/* spectral inversion - 0:disabled 1:enabled */
-   int spectral_inversion:1;
+   unsigned int spectral_inversion:1;

/* use RF AGC loop - 0:disabled 1:enabled */
-   int rf_agc_loop:1;
+   unsigned int rf_agc_loop:1;

enum lgdt3305_mpeg_mode mpeg_mode;
enum lgdt3305_tp_clock_edge tpclk_edge;
--
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 2/4 v11] Definitions for TVP7002 in DM365

On Monday 30 November 2009 16:51:38 santiago.nu...@ridgerun.com wrote:
 From: Santiago Nunez-Corrales santiago.nu...@ridgerun.com
 
 This patch provides the required definitions for the TVP7002 driver
 in DM365.
 
 Signed-off-by: Santiago Nunez-Corrales santiago.nu...@ridgerun.com
 ---
  drivers/media/video/tvp7002_reg.h |  150 
 +
  include/media/tvp7002.h   |   57 ++
  2 files changed, 207 insertions(+), 0 deletions(-)
  create mode 100644 drivers/media/video/tvp7002_reg.h
  create mode 100644 include/media/tvp7002.h
 
 diff --git a/drivers/media/video/tvp7002_reg.h 
 b/drivers/media/video/tvp7002_reg.h
 new file mode 100644
 index 000..0e34ca9
 --- /dev/null
 +++ b/drivers/media/video/tvp7002_reg.h
 @@ -0,0 +1,150 @@
 +/* Texas Instruments Triple 8-/10-BIT 165-/110-MSPS Video and Graphics
 + * Digitizer with Horizontal PLL registers
 + *
 + * Copyright (C) 2009 Texas Instruments Inc
 + * Author: Santiago Nunez-Corrales santiago.nu...@ridgerun.com
 + *
 + * This code is partially based upon the TVP5150 driver
 + * written by Mauro Carvalho Chehab (mche...@infradead.org),
 + * the TVP514x driver written by Vaibhav Hiremath hvaib...@ti.com
 + * and the TVP7002 driver in the TI LSP 2.10.00.14
 + *
 + * This program is free software; you can redistribute it and/or modify
 + * it under the terms of the GNU General Public License as published by
 + * the Free Software Foundation; either version 2 of the License, or
 + * (at your option) any later version.
 + *
 + * 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., 675 Mass Ave, Cambridge, MA 02139, USA.
 + */
 +
 +/* Naming conventions
 + * --
 + *
 + * FDBK:  Feedback
 + * DIV:   Divider
 + * CTL:   Control
 + * SEL:   Select
 + * IN:Input
 + * OUT:   Output
 + * R: Red
 + * G: Green
 + * B: Blue
 + * OFF:   Offset
 + * THRS:  Threshold
 + * DGTL:  Digital
 + * LVL:   Level
 + * PWR:   Power
 + * MVIS:  Macrovision
 + * W: Width
 + * H: Height
 + * ALGN:  Alignment
 + * CLK:   Clocks
 + * TOL:   Tolerance
 + * BWTH:  Bandwidth
 + * COEF:  Coefficient
 + * STAT:  Status
 + * AUTO:  Automatic
 + * FLD:   Field
 + * L:  Line
 + */
 +
 +#define TVP7002_CHIP_REV 0x00
 +#define TVP7002_HPLL_FDBK_DIV_MSBS   0x01
 +#define TVP7002_HPLL_FDBK_DIV_LSBS   0x02
 +#define TVP7002_HPLL_CRTL0x03
 +#define TVP7002_HPLL_PHASE_SEL   0x04
 +#define TVP7002_CLAMP_START  0x05
 +#define TVP7002_CLAMP_W  0x06
 +#define TVP7002_HSYNC_OUT_W  0x07
 +#define TVP7002_B_FINE_GAIN  0x08
 +#define TVP7002_G_FINE_GAIN  0x09
 +#define TVP7002_R_FINE_GAIN  0x0a
 +#define TVP7002_B_FINE_OFF_MSBS  0x0b
 +#define TVP7002_G_FINE_OFF_MSBS 0x0c
 +#define TVP7002_R_FINE_OFF_MSBS 0x0d
 +#define TVP7002_SYNC_CTL_1   0x0e
 +#define TVP7002_HPLL_AND_CLAMP_CTL   0x0f
 +#define TVP7002_SYNC_ON_G_THRS   0x10
 +#define TVP7002_SYNC_SEPARATOR_THRS  0x11
 +#define TVP7002_HPLL_PRE_COAST   0x12
 +#define TVP7002_HPLL_POST_COAST  0x13
 +#define TVP7002_SYNC_DETECT_STAT 0x14
 +#define TVP7002_OUT_FORMATTER0x15
 +#define TVP7002_MISC_CTL_1   0x16
 +#define TVP7002_MISC_CTL_2  0x17
 +#define TVP7002_MISC_CTL_3  0x18
 +#define TVP7002_IN_MUX_SEL_1 0x19
 +#define TVP7002_IN_MUX_SEL_20x1a
 +#define TVP7002_B_AND_G_COARSE_GAIN  0x1b
 +#define TVP7002_R_COARSE_GAIN0x1c
 +#define TVP7002_FINE_OFF_LSBS0x1d
 +#define TVP7002_B_COARSE_OFF 0x1e
 +#define TVP7002_G_COARSE_OFF0x1f
 +#define TVP7002_R_COARSE_OFF0x20
 +#define TVP7002_HSOUT_OUT_START  0x21
 +#define TVP7002_MISC_CTL_4   0x22
 +#define TVP7002_B_DGTL_ALC_OUT_LSBS  0x23
 +#define TVP7002_G_DGTL_ALC_OUT_LSBS 0x24
 +#define TVP7002_R_DGTL_ALC_OUT_LSBS 0x25
 +#define TVP7002_AUTO_LVL_CTL_ENABLE  0x26
 +#define TVP7002_DGTL_ALC_OUT_MSBS0x27
 +#define TVP7002_AUTO_LVL_CTL_FILTER  0x28
 +/* Reserved 0x29*/
 +#define TVP7002_FINE_CLAMP_CTL   0x2a
 +#define TVP7002_PWR_CTL  0x2b
 +#define TVP7002_ADC_SETUP0x2c
 +#define TVP7002_COARSE_CLAMP_CTL 0x2d
 +#define TVP7002_SOG_CLAMP0x2e
 +#define TVP7002_RGB_COARSE_CLAMP_CTL 0x2f
 +#define TVP7002_SOG_COARSE_CLAMP_CTL 0x30
 +#define TVP7002_ALC_PLACEMENT0x31
 +/* Reserved 0x32 */
 +/* Reserved 0x33 */
 +#define TVP7002_MVIS_STRIPPER_W  0x34

Re: [PATCH 0/4 v11] Support for TVP7002 in DM365

On Tuesday 15 December 2009 20:24:19 Santiago Nunez-Corrales wrote:
 Hi Hans,
 
 
 I know you'be been busy and in the road lately. Just checking if you had 
 the chance to review this version of the code.

Done!

Regards,

Hans

 
 Regards,
 
 Hans Verkuil wrote:
  On Tuesday 08 December 2009 01:44:43 Santiago Nunez-Corrales wrote:

  Hans,
 
 
  Hi. Have you had a chance to look at this version of the driver?
  
 
  Sorry, no. I hope to have some time on Thursday. I'm abroad for business at
  the moment and unfortunately that leaves me with little time for reviewing.
 
  This is not just true for this driver, but also for the dm365 series that 
  was
  posted recently. And possibly others that I missed :-(
 
  Regards,
 
  Hans
 

  Regards,
 
 
  Santiago.
 
  Santiago Nunez-Corrales wrote:
  
  This series of patches provide support for the TVP7002 decoder in DM365.
 
  Support includes:
 
  * Inclusion of the chip in v4l2 definitions
  * Definition of TVP7002 specific data structures
  * Kconfig and Makefile support
 
  This series corrects many issued pointed out by Snehaprabha Narnakaje,
  Muralidharan Karicheri, Vaibhav Hiremath and Hans Verkuil and solves
  testing problems.  Tested on DM365 TI EVM with resolutions 720p,
  10...@60, 576P and 480P with video capture application and video
  output in 480P, 576P, 720P and 1080I. This driver depends upon
  board-dm365-evm.c and vpfe_capture.c to be ready for complete
  integration. Uses the new V4L2 DV API sent by Muralidharan Karicheri.
  Removed shadow register values. Removed unnecesary power down and up
  of the device (tests work fine). Improved readability.
 
 

 
  Guayabos, Curridabat
  San Jose, Costa Rica
  +(506) 2271 1487
  +(506) 8313 0536
  http://www.ridgerun.com
 
 
 
  
 
 
 

-- 
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 - v1 4/6] V4L - vpfe_capture bug fix and enhancements

On Thursday 10 December 2009 18:00:29 m-kariche...@ti.com wrote:
 From: Muralidharan Karicheri m-kariche...@ti.com
 
 Added a experimental IOCTL, to read the CCDC parameters.
 Default handler was not getting the original pointer from the core.
 So a wrapper function added to handle the default handler properly.
 Also fixed a bug in the probe() in the linux-next tree
 
 Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
 ---
  drivers/media/video/davinci/vpfe_capture.c |  119 
 +---
  include/media/davinci/vpfe_capture.h   |   12 ++-
  2 files changed, 81 insertions(+), 50 deletions(-)
 
 diff --git a/drivers/media/video/davinci/vpfe_capture.c 
 b/drivers/media/video/davinci/vpfe_capture.c
 index 091750e..8c6d856 100644
 --- a/drivers/media/video/davinci/vpfe_capture.c
 +++ b/drivers/media/video/davinci/vpfe_capture.c
 @@ -759,12 +759,83 @@ static unsigned int vpfe_poll(struct file *file, 
 poll_table *wait)
   return 0;
  }
  
 +static long vpfe_param_handler(struct file *file, void *priv,
 + int cmd, void *param)
 +{
 + struct vpfe_device *vpfe_dev = video_drvdata(file);
 + int ret = 0;
 +
 + v4l2_dbg(1, debug, vpfe_dev-v4l2_dev, vpfe_param_handler\n);
 +
 + if (NULL == param) {
 + v4l2_dbg(1, debug, vpfe_dev-v4l2_dev,
 + Invalid user ptr\n);

Shouldn't there be an error return here? It looks weird.

 + }
 +
 + if (vpfe_dev-started) {
 + /* only allowed if streaming is not started */
 + v4l2_err(vpfe_dev-v4l2_dev, device already started\n);
 + return -EBUSY;
 + }
 +
 +
 + switch (cmd) {
 + case VPFE_CMD_S_CCDC_RAW_PARAMS:
 + v4l2_warn(vpfe_dev-v4l2_dev,
 +   VPFE_CMD_S_CCDC_RAW_PARAMS: experimental ioctl\n);
 + ret = mutex_lock_interruptible(vpfe_dev-lock);
 + if (ret)
 + return ret;
 + ret = ccdc_dev-hw_ops.set_params(param);
 + if (ret) {
 + v4l2_dbg(1, debug, vpfe_dev-v4l2_dev,
 + Error in setting parameters in CCDC\n);
 + goto unlock_out;
 + }
 +
 + if (vpfe_get_ccdc_image_format(vpfe_dev, vpfe_dev-fmt)  0) {
 + v4l2_err(vpfe_dev-v4l2_dev,
 + Invalid image format at CCDC\n);
 + ret = -EINVAL;
 + }
 +unlock_out:
 + mutex_unlock(vpfe_dev-lock);
 + break;
 + case VPFE_CMD_G_CCDC_RAW_PARAMS:
 + v4l2_warn(vpfe_dev-v4l2_dev,
 +   VPFE_CMD_G_CCDC_RAW_PARAMS: experimental ioctl\n);
 + if (!ccdc_dev-hw_ops.get_params) {
 + ret = -EINVAL;
 + break;
 + }
 + ret = ccdc_dev-hw_ops.get_params(param);
 + if (ret) {
 + v4l2_dbg(1, debug, vpfe_dev-v4l2_dev,
 + Error in getting parameters from CCDC\n);
 + }
 + break;
 +
 + default:
 + ret = -EINVAL;

Please add a break statement here.

 + }
 + return ret;
 +}
 +
 +static long vpfe_ioctl(struct file *file, unsigned int cmd, unsigned long 
 arg)
 +{
 + if (cmd == VPFE_CMD_S_CCDC_RAW_PARAMS ||
 + cmd == VPFE_CMD_G_CCDC_RAW_PARAMS)
 + return vpfe_param_handler(file, file-private_data, cmd,
 +  (void *)arg);
 + return video_ioctl2(file, cmd, arg);
 +}
 +
  /* vpfe capture driver file operations */
  static const struct v4l2_file_operations vpfe_fops = {
   .owner = THIS_MODULE,
   .open = vpfe_open,
   .release = vpfe_release,
 - .unlocked_ioctl = video_ioctl2,
 + .unlocked_ioctl = vpfe_ioctl,
   .mmap = vpfe_mmap,
   .poll = vpfe_poll
  };
 @@ -1682,50 +1753,6 @@ unlock_out:
   return ret;
  }
  
 -
 -static long vpfe_param_handler(struct file *file, void *priv,
 - int cmd, void *param)
 -{
 - struct vpfe_device *vpfe_dev = video_drvdata(file);
 - int ret = 0;
 -
 - v4l2_dbg(1, debug, vpfe_dev-v4l2_dev, vpfe_param_handler\n);
 -
 - if (vpfe_dev-started) {
 - /* only allowed if streaming is not started */
 - v4l2_err(vpfe_dev-v4l2_dev, device already started\n);
 - return -EBUSY;
 - }
 -
 - ret = mutex_lock_interruptible(vpfe_dev-lock);
 - if (ret)
 - return ret;
 -
 - switch (cmd) {
 - case VPFE_CMD_S_CCDC_RAW_PARAMS:
 - v4l2_warn(vpfe_dev-v4l2_dev,
 -   VPFE_CMD_S_CCDC_RAW_PARAMS: experimental ioctl\n);
 - ret = ccdc_dev-hw_ops.set_params(param);
 - if (ret) {
 - v4l2_err(vpfe_dev-v4l2_dev,
 - Error in setting parameters in CCDC\n);
 - goto unlock_out;
 - }
 - if

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

On Tue 2009-12-15 15:45:14, Jon Smirl wrote:
 On Tue, Dec 15, 2009 at 3:33 PM, Pavel Machek pa...@ucw.cz wrote:
  On Tue 2009-12-15 15:29:51, Jon Smirl wrote:
  On Tue, Dec 15, 2009 at 3:19 PM, Pavel Machek pa...@ucw.cz wrote:
   On Tue 2009-12-15 15:14:02, Jon Smirl wrote:
   On Tue, Dec 15, 2009 at 2:58 PM, Pavel Machek pa...@ucw.cz wrote:
Hi!
   
      (11) if none is against renaming IR as RC, I'll do it on a 
next patch;
   
Call it irc -- infrared remote control. Bluetooth remote controls will
have very different characteristics.
  
   How are they different after the scancode is extracted from the
   network packet? The scancode still needs to be passed to the input
   system, go through a keymap, and end up on an evdev device.
  
   I would expect the code for extracting the scancode to live in the
   networking stack, but after it is recovered the networking code would
   use the same API as IR to submit it to input.
  
   For one thing,  bluetooth (etc) has concept of devices (and reliable
   transfer). If you have two same bluetooth remotes, you can tell them
   apart, unlike IR.
 
  IR has the same concept of devices. That's what those codes you enter
  into a universal remote do - they set the device.
 
  They set the device _model_.
 
  There are three classes of remotes..
  Fixed function - the device is hardwired
  Universal - you can change the device
  Multi-function - a universal that can be multiple devices - TV, cable,
  audio, etc
 
  If you set two Bluetooth remotes both to the same device you can't
  tell them apart either.
 
  Untrue. Like ethernets and wifis, bluetooth devices have unique
  addresses. Communication is bidirectional.
 
 I agree with that, but the 802.15.4 remote control software I've
 worked with ignores the MAC address. You set your remote to send codes
 for a specific device.  The mac address of the remote is ignored so
 that any remote can control the device.  You don't need to pair
 802.15.4 remotes like Bluetooth devices need to be paired.
 
 I haven't played around with a Bluetooth remote. Nothing I own can
 send the signals.  How can a Bluetooth remote control multiple devices
 in the same room if it needs to be paired?

I'd guess that bluetooth remote would be very similar to bluetooth
keyboard, and present itself in a very similar way.

I still believe infrared is different -- it is essentially light with
very little protocol above. 
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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: uvcvideo Logitech patch

2009-12-15 Thread Ondrej Zary

On Tuesday 15 December 2009 20:03:36 Mitar wrote:
 Hi!

 I have Logitech QuickCam Pro 9000 webcam and I had the same problems
 described here:

 http://patchwork.kernel.org/patch/52261/

 I have applied the patch and it did not help. But it helped when I
 increased UVC_CTRL_CONTROL_TIMEOUT to 1000 and
 UVC_CTRL_STREAMING_TIMEOUT 5000. So 300 and 3000 values were not enough.
 I do not know if it was really necessary to increase
 UVC_CTRL_CONTROL_TIMEOUT or if it would be enough something between 3000
 and 5000 for UVC_CTRL_STREAMING_TIMEOUT as I did not have more time to
 test it.

 So maybe 5000 would be a good default for UVC_CTRL_STREAMING_TIMEOUT?

 I have been doing this on 2.6.30 amd64 system.

 Just to let you know. And thanks for the patch.


 Mitar

[Added UVC mailing lists to CC]


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

Re: [PATCH - v1 4/6] V4L - vpfe_capture bug fix and enhancements

Note that the other patches from this series are fine as far as I am concerned.

One general note: I always have difficulties with constructions like this:

 + val = (bc-horz.win_count_calc 
 + ISIF_HORZ_BC_WIN_COUNT_MASK) |
 + ((!!bc-horz.base_win_sel_calc) 
 + ISIF_HORZ_BC_WIN_SEL_SHIFT) |
 + ((!!bc-horz.clamp_pix_limit) 
 + ISIF_HORZ_BC_PIX_LIMIT_SHIFT) |
 + ((bc-horz.win_h_sz_calc 
 + ISIF_HORZ_BC_WIN_H_SIZE_MASK) 
 + ISIF_HORZ_BC_WIN_H_SIZE_SHIFT) |
 + ((bc-horz.win_v_sz_calc 
 + ISIF_HORZ_BC_WIN_V_SIZE_MASK) 
 + ISIF_HORZ_BC_WIN_V_SIZE_SHIFT);

It's just about impossible for me to parse. And some of the patches in this
series are full of such constructs.

Unfortunately, I do not have a magic bullet solution. In some cases I suspect
that a static inline function can help.

In other cases it might help to split it up in smaller parts. For example:

u32 tmp;

val = bc-horz.win_count_calc 
ISIF_HORZ_BC_WIN_COUNT_MASK;
val |= !!bc-horz.base_win_sel_calc 
ISIF_HORZ_BC_WIN_SEL_SHIFT;
val |= !!bc-horz.clamp_pix_limit 
ISIF_HORZ_BC_PIX_LIMIT_SHIFT;
tmp = bc-horz.win_h_sz_calc 
ISIF_HORZ_BC_WIN_H_SIZE_MASK;
val |= tmp  ISIF_HORZ_BC_WIN_H_SIZE_SHIFT;
tmp = bc-horz.win_v_sz_calc 
ISIF_HORZ_BC_WIN_V_SIZE_MASK;
val |= tmp  ISIF_HORZ_BC_WIN_V_SIZE_SHIFT;

Of course, in this particular piece of code from the function 
isif_config_bclamp()
I am also wondering why bc-horz.win_h_sz_calc and bc-horz.win_v_sz_calc need 
to
be ANDed anyway. I would expect that to happen when these values are set. But I
did not look at this in-depth, so I may well have missed some subtlety here.

It would be interesting to know if people know of good ways of making awkward
code like this more elegant (or at least less awkward).

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: [RFC] What are the goals for the architecture of an in-kernel IR system?

On Tue, Dec 15, 2009 at 3:45 PM, Jon Smirl jonsm...@gmail.com wrote:
 On Tue, Dec 15, 2009 at 3:33 PM, Pavel Machek pa...@ucw.cz wrote:
 Untrue. Like ethernets and wifis, bluetooth devices have unique
 addresses. Communication is bidirectional.

I read a little about how Bluetooth remotes work. Correct me if I get
things wrong

They create pairings between the remote and the device. Each of these
pairings is assigned a device type. Multiple devices in the same room
are handled by the remote remembering the pairings and sending
directed packets instead of broadcast. That lets you have two TVs in
the same room.

Bluetooth devices need to advertise what profiles they support. So on
the Linux box you'd run a command to load the Bluetooth profile for
TV. This command would create an evdev subdevice, load the Bluetooth
keymap for TV, and tell the networking stack to advertise TV support.
Next you initiate the pairing from the Bluetooth remote and pick the
Linux box. This causes a pairing established exchange which tells the
Linux box to make the pairing persistent.

I believe the Bluetooth remote profile is handled in user space by the
BlueZ stack. BlueZ should be aware of the remote pairings. When it
decodes a button press it would need to inject the scancode into the
correct evdev subdevice. Evdev would translate it in the keymap and
create the keyevent. This is the same mechanism LIRC is using.


At a more general level we're missing a way for something like Myth to
declare that it is a DVR device. Myth should load, say I'm a DVR, and
then the remote control subsystem should automatically create a
Bluetooth DVR profile, load an IR profile for Motorola DVR on a
universal remote if the box has Bluetooth, IR or 802.15.4.

The whole concept of a remote control subsystem seems like it needs
more design work done. We keep coming up with big areas that no one
has thought about.

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

Re: [PATCH] lgdt3305: make one-bit bitfields unsigned

2009-12-15 Thread Michael Krufky

Thanks -- I'll push this in through the lgdt3305 repository... I'll send 
in a pull request to Mauro shortly.


-Mike

Németh Márton wrote:

From: Márton Németh nm...@freemail.hu

Make one-bit bitfields unsigned which will remove the following
sparse warning messages (see make C=1):
 * lgdt3305.h:57:21: error: dubious one-bit signed bitfield
 * lgdt3305.h:60:26: error: dubious one-bit signed bitfield
 * lgdt3305.h:63:19: error: dubious one-bit signed bitfield

Signed-off-by: Márton Németh nm...@freemail.hu
---
diff -r ba8d6bf077aa linux/drivers/media/dvb/frontends/lgdt3305.h
--- a/linux/drivers/media/dvb/frontends/lgdt3305.h  Tue Dec 15 17:40:44 
2009 +0100
+++ b/linux/drivers/media/dvb/frontends/lgdt3305.h  Tue Dec 15 21:47:53 
2009 +0100
@@ -54,13 +54,13 @@
u16 usref_qam256; /* default: 0x2a80 */

/* disable i2c repeater - 0:repeater enabled 1:repeater disabled */
-   int deny_i2c_rptr:1;
+   unsigned int deny_i2c_rptr:1;

/* spectral inversion - 0:disabled 1:enabled */
-   int spectral_inversion:1;
+   unsigned int spectral_inversion:1;

/* use RF AGC loop - 0:disabled 1:enabled */
-   int rf_agc_loop:1;
+   unsigned int rf_agc_loop:1;

enum lgdt3305_mpeg_mode mpeg_mode;
enum lgdt3305_tp_clock_edge tpclk_edge;
  


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

[PULL] http://kernellabs.com/hg/~mkrufky/lgdt3305

2009-12-15 Thread Michael Krufky

Mauro,

Please pull from:

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

for the following:

- lgdt3305: make one-bit bitfields unsigned

 lgdt3305.h |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

Thanks,

Mike

2009/12/15 Michael Krufky mkru...@linuxtv.org:
 Thanks -- I'll push this in through the lgdt3305 repository... I'll send in
 a pull request to Mauro shortly.

 -Mike

 Németh Márton wrote:

 From: Márton Németh nm...@freemail.hu

 Make one-bit bitfields unsigned which will remove the following
 sparse warning messages (see make C=1):
  * lgdt3305.h:57:21: error: dubious one-bit signed bitfield
  * lgdt3305.h:60:26: error: dubious one-bit signed bitfield
  * lgdt3305.h:63:19: error: dubious one-bit signed bitfield

 Signed-off-by: Márton Németh nm...@freemail.hu
 ---
 diff -r ba8d6bf077aa linux/drivers/media/dvb/frontends/lgdt3305.h
 --- a/linux/drivers/media/dvb/frontends/lgdt3305.h      Tue Dec 15
 17:40:44 2009 +0100
 +++ b/linux/drivers/media/dvb/frontends/lgdt3305.h      Tue Dec 15
 21:47:53 2009 +0100
 @@ -54,13 +54,13 @@
        u16 usref_qam256; /* default: 0x2a80 */

        /* disable i2c repeater - 0:repeater enabled 1:repeater disabled */
 -       int deny_i2c_rptr:1;
 +       unsigned int deny_i2c_rptr:1;

        /* spectral inversion - 0:disabled 1:enabled */
 -       int spectral_inversion:1;
 +       unsigned int spectral_inversion:1;

        /* use RF AGC loop - 0:disabled 1:enabled */
 -       int rf_agc_loop:1;
 +       unsigned int rf_agc_loop:1;

        enum lgdt3305_mpeg_mode mpeg_mode;
        enum lgdt3305_tp_clock_edge tpclk_edge;



--
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- gspca: added chipset revision sensor

2009-12-15 Thread Luis Maia

I found an email that discussed the similar problem that my camera had, 
showing up just a black screen, it's dated but  i think maybe it wasn't 
fully solved because there's no answer.


http://osdir.com/ml/drivers.spca50x.devel/2006-11/msg00036.html

Note the : /  /Vimicro/zc3xx.h: [zcxx_probeSensor:307] sensor 3w Vga 
??? 0xC400


/Do you know if this was solved?!
Because i suspect that maybe there are more 0x?400 revision of the chipset.
Btw, if this is a pattern could we consider to mask the bits in retword 
(retword = 0x0FFF)?

Because looking at the current table it seems to make more sense.

Best regards,
Luis Maia.
Jean-Francois Moine wrote:

On Tue, 15 Dec 2009 10:25:29 -0300
leandro Costantino lcostant...@gmail.com wrote:

  

Jean,
let me know , if you need to the test this patch, since i added the
tas1530k long time ago, and still have the webcam :)
Best Regards

On Tue, Dec 15, 2009 at 4:54 AM, Jean-Francois Moine
moin...@free.fr wrote:


On Tue, 15 Dec 2009 03:45:00 +
Luis Maia lm...@royalhat.org wrote:

  

Added extra chipset revision (sensor) to fix camera zc0301 with
 ID: 0ac8:301b .
Since i own one of this cameras fixed and tested it.

-


diff -uNr linux-2.6.32.1/drivers/media/video/gspca/zc3xx.c
linux-2.6.32.1-patch/drivers/media/video/gspca/zc3xx.c
--- linux-2.6.32.1/drivers/media/video/gspca/zc3xx.c2009-12-14
17:47:25.0 +
+++ linux-2.6.32.1-patch/drivers/media/video/gspca/zc3xx.c
2009-12-15 02:42:13.0 +
@@ -6868,6 +6868,7 @@
 {0x8001, 0x13},
 {0x8000, 0x14},/* CS2102K */
 {0x8400, 0x15},/* TAS5130K */
+{0xe400, 0x15},
 };

 static int vga_3wr_probe(struct gspca_dev *gspca_dev)
@@ -7634,7 +7635,7 @@
 {USB_DEVICE(0x0698, 0x2003)},
 {USB_DEVICE(0x0ac8, 0x0301), .driver_info = SENSOR_PAS106},
 {USB_DEVICE(0x0ac8, 0x0302), .driver_info = SENSOR_PAS106},
-{USB_DEVICE(0x0ac8, 0x301b)},
+{USB_DEVICE(0x0ac8, 0x301b), .driver_info = SENSOR_PB0330},
 {USB_DEVICE(0x0ac8, 0x303b)},
 {USB_DEVICE(0x0ac8, 0x305b), .driver_info =
SENSOR_TAS5130C_VF0250}, {USB_DEVICE(0x0ac8, 0x307b)},



Hello Luis and Leandro,

Thanks for the patch. Luis said his sensor is the tas5130K, so the 2nd
part of the patch is useless. But, maybe, Leandro, have you heard about
other chipset revision IDs?

Best regards.

  


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

RE: [PATCH - v1 4/6] V4L - vpfe_capture bug fix and enhancements

2009-12-15 Thread Karicheri, Muralidharan

Hans,

I remember there was a comment against an earlier patch that asks
for combining such statements since it makes the function appear
as big. Not sure who had made that comment. That is the reason you
find code like this in this patch. It was initially done with multiple
OR statements to construct the value to be written to the register as you 
stated below as 

val = bc-horz.win_count_calc 
   ISIF_HORZ_BC_WIN_COUNT_MASK;
val |= !!bc-horz.base_win_sel_calc 
   ISIF_HORZ_BC_WIN_SEL_SHIFT;

I have checked few other drivers such as bt819.c ir-kbd-i2c.c,
mt9m111.c etc, where similar statements are found, but they have used hardcoded 
values masks which makes it appears less complex. But I 
like to reduce magic numbers as much possible in the code.

I think what I can do is to  combine maximum of 2 such expressions in a 
statement which might make it less complex to read. Such as 

val = (bc-horz.win_count_calc 
ISIF_HORZ_BC_WIN_COUNT_MASK) |
((!!bc-horz.base_win_sel_calc) 
ISIF_HORZ_BC_WIN_SEL_SHIFT);

val |= (!!bc-horz.clamp_pix_limit) 
 ISIF_HORZ_BC_PIX_LIMIT_SHIFT) |
 ((bc-horz.win_h_sz_calc 
 ISIF_HORZ_BC_WIN_H_SIZE_MASK) 
 ISIF_HORZ_BC_WIN_H_SIZE_SHIFT);
val |= ((bc-horz.win_v_sz_calc 
 ISIF_HORZ_BC_WIN_V_SIZE_MASK) 
 ISIF_HORZ_BC_WIN_V_SIZE_SHIFT);

Also to make the line fits in 80 characters, I will consider reducing
the number of characters in #define names such as

val = (bc-horz.win_count_calc  HZ_BC_WIN_CNT_MASK) |
((!!bc-horz.base_win_sel_calc)  HZ_BC_WIN_SEL_SHIFT) |
(!!bc-horz.clamp_pix_limit)  HZ_BC_PIX_LIMIT_SHIFT);

Let me know if you don't agree.


Of course, in this particular piece of code from the function
isif_config_bclamp()
I am also wondering why bc-horz.win_h_sz_calc and bc-horz.win_v_sz_calc
need to
be ANDed anyway. I would expect that to happen when these values are set.
But I
did not look at this in-depth, so I may well have missed some subtlety here.

Yes, isif_config_bclamp() set values in the register.


It would be interesting to know if people know of good ways of making
awkward
code like this more elegant (or at least less awkward).

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: [RESEND] Re: DViCO FusionHDTV DVB-T Dual Digital 4 (rev 1) tuning regression

2009-12-15 Thread Robert Lowery

Mauro,

I've split the revert2.diff that I sent you previously to fix the tuning
regression on my DViCO Dual Digital 4 (rev 1) into three separate patches
that will hopefully allow you to review more easily.

The first two patches revert their respective changesets and nothing else,
fixing the issue for me.
12167:966ce12c444d tuner-xc2028: Fix 7 MHz DVB-T
11918:e6a8672631a0 tuner-xc2028: Fix offset frequencies for DVB @ 6MHz

The third patch does what I believe is the obvious equivalent fix to
e6a8672631a0 but without the cleanup that breaks tuning on my card.

Please review and merge

Signed-off-by: Robert Lowery rglow...@exemail.com.au

Thanks

-Rob


01_revert_966ce12c444d.diff
Description: /


02_revert_e6a8672631a0.diff
Description: /


03_refix_e6a8672631a0.diff
Description: /

USB MAssage Storage drivers

2009-12-15 Thread Gopala Gottumukkala

My target is not recognizing the USB massage storage. I am working the
2.6.32 Davinci kernel

Any suggestion and ideas.

- gg


--
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: uvcvideo kernel panic when using libv4l

2009-12-15 Thread Laurent Pinchart

Hi Leandro and Pablo,

could you please try the following patch ? It closes a race window that I
believe could be at the core of your kernel panic.

diff -r c1f376eae978 linux/drivers/media/video/uvc/uvc_queue.c
--- a/linux/drivers/media/video/uvc/uvc_queue.c Sat Dec 12 18:57:17 2009 +0100
+++ b/linux/drivers/media/video/uvc/uvc_queue.c Wed Dec 16 01:10:21 2009 +0100
@@ -59,7 +59,7 @@
  *returns immediately.
  *
  *When the buffer is full, the completion handler removes it from the irq
- *queue, marks it as ready (UVC_BUF_STATE_DONE) and wakes its wait queue.
+ *queue, marks it as ready (UVC_BUF_STATE_READY) and wakes its wait queue.
  *At that point, any process waiting on the buffer will be woken up. If a
  *process tries to dequeue a buffer after it has been marked ready, the
  *dequeing will succeed immediately.
@@ -196,11 +196,12 @@
 
switch (buf-state) {
case UVC_BUF_STATE_ERROR:
-   case UVC_BUF_STATE_DONE:
+   case UVC_BUF_STATE_READY:
v4l2_buf-flags |= V4L2_BUF_FLAG_DONE;
break;
case UVC_BUF_STATE_QUEUED:
case UVC_BUF_STATE_ACTIVE:
+   case UVC_BUF_STATE_DONE:
v4l2_buf-flags |= V4L2_BUF_FLAG_QUEUED;
break;
case UVC_BUF_STATE_IDLE:
@@ -341,13 +342,14 @@
uvc_trace(UVC_TRACE_CAPTURE, [W] Corrupted data 
(transmission error).\n);
ret = -EIO;
-   case UVC_BUF_STATE_DONE:
+   case UVC_BUF_STATE_READY:
buf-state = UVC_BUF_STATE_IDLE;
break;
 
case UVC_BUF_STATE_IDLE:
case UVC_BUF_STATE_QUEUED:
case UVC_BUF_STATE_ACTIVE:
+   case UVC_BUF_STATE_DONE:
default:
uvc_trace(UVC_TRACE_CAPTURE, [E] Invalid buffer state %u 
(driver bug?).\n, buf-state);
@@ -383,7 +385,7 @@
buf = list_first_entry(queue-mainqueue, struct uvc_buffer, stream);
 
poll_wait(file, buf-wait, wait);
-   if (buf-state == UVC_BUF_STATE_DONE ||
+   if (buf-state == UVC_BUF_STATE_READY ||
buf-state == UVC_BUF_STATE_ERROR)
mask |= POLLIN | POLLRDNORM;
 
@@ -489,6 +491,7 @@
 
spin_lock_irqsave(queue-irqlock, flags);
list_del(buf-queue);
+   buf-state = UVC_BUF_STATE_READY;
if (!list_empty(queue-irqqueue))
nextbuf = list_first_entry(queue-irqqueue, struct uvc_buffer,
   queue);
diff -r c1f376eae978 linux/drivers/media/video/uvc/uvc_video.c
--- a/linux/drivers/media/video/uvc/uvc_video.c Sat Dec 12 18:57:17 2009 +0100
+++ b/linux/drivers/media/video/uvc/uvc_video.c Wed Dec 16 01:10:21 2009 +0100
@@ -578,8 +578,7 @@
uvc_video_decode_end(stream, buf, mem,
urb-iso_frame_desc[i].actual_length);
 
-   if (buf-state == UVC_BUF_STATE_DONE ||
-   buf-state == UVC_BUF_STATE_ERROR)
+   if (buf-state == UVC_BUF_STATE_DONE)
buf = uvc_queue_next_buffer(stream-queue, buf);
}
 }
@@ -637,8 +636,7 @@
if (!stream-bulk.skip_payload  buf != NULL) {
uvc_video_decode_end(stream, buf, stream-bulk.header,
stream-bulk.payload_size);
-   if (buf-state == UVC_BUF_STATE_DONE ||
-   buf-state == UVC_BUF_STATE_ERROR)
+   if (buf-state == UVC_BUF_STATE_DONE)
buf = uvc_queue_next_buffer(stream-queue,
buf);
}
diff -r c1f376eae978 linux/drivers/media/video/uvc/uvcvideo.h
--- a/linux/drivers/media/video/uvc/uvcvideo.h  Sat Dec 12 18:57:17 2009 +0100
+++ b/linux/drivers/media/video/uvc/uvcvideo.h  Wed Dec 16 01:10:21 2009 +0100
@@ -370,7 +370,8 @@
UVC_BUF_STATE_QUEUED= 1,
UVC_BUF_STATE_ACTIVE= 2,
UVC_BUF_STATE_DONE  = 3,
-   UVC_BUF_STATE_ERROR = 4,
+   UVC_BUF_STATE_READY = 4,
+   UVC_BUF_STATE_ERROR = 5,
 };
 
 struct uvc_buffer {

-- 
Regards,

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

[PATCH v3] isl6421.c - added tone control and temporary diseqc overcurrent

2009-12-15 Thread HoP

Hi Mauro,

2009/12/15 Mauro Carvalho Chehab mche...@redhat.com:
[snip]


 I'm still missing a driver or a board entry that requires those
 changes. Could you please send it together with this patch series?


We are using it in our project. Currently we are in very early
stage of it. We still have some serious issue, what not allows
us sending such code for mainlining.

Anyway, I don't think it can block accepting current patchset.
Isl6421 driver is already in tree, we only want to add some
features, which can be or can not be interesting for others.

I believe extending of usability of current drivers is correct
way.

 Also, you forgot to send your Signed-off-By. This is required for
 patch submission.


 Regards

 /Honza

 ---

 isl6421.c - added tone control and temporary diseqc overcurrent

 Please, always send patches in-lined. makes easier for commenting.


OK.

 diff -r 79fc32bba0a0 linux/drivers/media/dvb/b2c2/flexcop-fe-tuner.c
 --- a/linux/drivers/media/dvb/b2c2/flexcop-fe-tuner.c Mon Dec 14 17:43:13 
 2009 -0200
 +++ b/linux/drivers/media/dvb/b2c2/flexcop-fe-tuner.c Tue Dec 15 16:36:14 
 2009 +0100
 @@ -302,6 +302,12 @@ static struct itd1000_config skystar2_re
   .i2c_address = 0x61,
  };

 +static struct isl6421_config skystar2_rev2_7_isl6421_config = {
 + .i2c_address = 0x08,
 + .override_set = 0x01,
 + .override_clear = 0x01,
 +};
 +
  static int skystar2_rev27_attach(struct flexcop_device *fc,
   struct i2c_adapter *i2c)
  {
 @@ -325,7 +331,7 @@ static int skystar2_rev27_attach(struct
   /* enable no_base_addr - no repeated start when reading */
   fc-fc_i2c_adap[2].no_base_addr = 1;
   if (!dvb_attach(isl6421_attach, fc-fe, fc-fc_i2c_adap[2].i2c_adap,
 - 0x08, 1, 1)) {
 + skystar2_rev2_7_isl6421_config)) {
   err(ISL6421 could NOT be attached);
   goto fail_isl;
   }
 @@ -368,6 +374,12 @@ static const struct cx24113_config skyst
   .xtal_khz = 10111,
  };

 +static struct isl6421_config skystar2_rev2_8_isl6421_config = {
 + .i2c_address = 0x08,

 + .override_set = 0x00,
 + .override_clear = 0x00,

 Please, do not set any static value to zero. Kernel module support already
 does that, and this will just add uneeded stuff into BSS.


Done.

 +};
 +
  static int skystar2_rev28_attach(struct flexcop_device *fc,
   struct i2c_adapter *i2c)
  {
 @@ -391,7 +403,7 @@ static int skystar2_rev28_attach(struct

   fc-fc_i2c_adap[2].no_base_addr = 1;
   if (!dvb_attach(isl6421_attach, fc-fe, fc-fc_i2c_adap[2].i2c_adap,
 - 0x08, 0, 0)) {
 + skystar2_rev2_8_isl6421_config)) {
   err(ISL6421 could NOT be attached);
   fc-fc_i2c_adap[2].no_base_addr = 0;
   return 0;
 diff -r 79fc32bba0a0 linux/drivers/media/dvb/frontends/isl6421.c
 --- a/linux/drivers/media/dvb/frontends/isl6421.c Mon Dec 14 17:43:13 
 2009 -0200
 +++ b/linux/drivers/media/dvb/frontends/isl6421.c Tue Dec 15 16:36:14 
 2009 +0100
 @@ -3,6 +3,9 @@
   *
   * Copyright (C) 2006 Andrew de Quincey
   * Copyright (C) 2006 Oliver Endriss
 + * Copyright (C) 2009 Ales Jurik and Jan Petrous (added optional 22k tone
 + *support and temporary diseqc overcurrent enable until
 + *next command - set voltage or tone)
   *
   * This program is free software; you can redistribute it and/or
   * modify it under the terms of the GNU General Public License
 @@ -36,37 +39,88 @@
  #include isl6421.h

  struct isl6421 {
 - u8  config;
 - u8  override_or;
 - u8  override_and;
 - struct i2c_adapter  *i2c;
 - u8  i2c_addr;
 + const struct isl6421_config *config;
 + u8  reg1;

 reg1 seems a very bad name. Based on the datasheet, maybe
 you could call it as sys_config or sys_reg_config.


Renamed to sys_reg.

 +
 + struct i2c_adapter *i2c;
 +
 + int (*diseqc_send_master_cmd_orig)(struct dvb_frontend *fe,
 + struct dvb_diseqc_master_cmd *cmd);
  };

  static int isl6421_set_voltage(struct dvb_frontend *fe, fe_sec_voltage_t 
 voltage)
  {
   struct isl6421 *isl6421 = (struct isl6421 *) fe-sec_priv;
 - struct i2c_msg msg = {  .addr = isl6421-i2c_addr, .flags = 0,
 - .buf = isl6421-config,
 - .len = sizeof(isl6421-config) };
 + struct i2c_msg msg = {  .addr = isl6421-config-i2c_addr, .flags = 0,
 + .buf = isl6421-reg1,
 + .len = sizeof(isl6421-reg1) };

 - isl6421-config = ~(ISL6421_VSEL1 | ISL6421_EN1);
 + isl6421-reg1 = ~(ISL6421_VSEL1 | ISL6421_EN1);

   switch(voltage) {
   case SEC_VOLTAGE_OFF:
   break;
   case SEC_VOLTAGE_13:
 - isl6421-config |= ISL6421_EN1;
 +

Re: PATCH- gspca: added chipset revision sensor

2009-12-15 Thread leandro Costantino

Actually, i have not heard of other chipset's revision about task1530k
since 2008 (http://article.gmane.org/gmane.linux.drivers.spca50x.devel/2826
)
But it's possible that , there will be many others cam using that.

Luis, in fact there seem's to be a pattern against revision  chipset
id - sensor, but actually, i cannot assure that there'nt an
exception. Jean, should decide on that :)

pd: Jean, I am waiting for the user that was doing the patch for the
t613 against a new sensor...  :)

Best Regards
On Wed, Dec 16, 2009 at 1:34 AM, Luis Maia lm...@royalhat.org wrote:
 I found an email that discussed the similar problem that my camera had,
 showing up just a black screen, it's dated but  i think maybe it wasn't
 fully solved because there's no answer.

 http://osdir.com/ml/drivers.spca50x.devel/2006-11/msg00036.html

 Note the : /  /Vimicro/zc3xx.h: [zcxx_probeSensor:307] sensor 3w Vga ???
 0xC400

 /Do you know if this was solved?!
 Because i suspect that maybe there are more 0x?400 revision of the chipset.
 Btw, if this is a pattern could we consider to mask the bits in retword
 (retword = 0x0FFF)?
 Because looking at the current table it seems to make more sense.

 Best regards,
 Luis Maia.
 Jean-Francois Moine wrote:

 On Tue, 15 Dec 2009 10:25:29 -0300
 leandro Costantino lcostant...@gmail.com wrote:



 Jean,
 let me know , if you need to the test this patch, since i added the
 tas1530k long time ago, and still have the webcam :)
 Best Regards

 On Tue, Dec 15, 2009 at 4:54 AM, Jean-Francois Moine
 moin...@free.fr wrote:


 On Tue, 15 Dec 2009 03:45:00 +
 Luis Maia lm...@royalhat.org wrote:



 Added extra chipset revision (sensor) to fix camera zc0301 with
  ID: 0ac8:301b .
 Since i own one of this cameras fixed and tested it.
        -

 diff -uNr linux-2.6.32.1/drivers/media/video/gspca/zc3xx.c
 linux-2.6.32.1-patch/drivers/media/video/gspca/zc3xx.c
 --- linux-2.6.32.1/drivers/media/video/gspca/zc3xx.c    2009-12-14
 17:47:25.0 +
 +++ linux-2.6.32.1-patch/drivers/media/video/gspca/zc3xx.c
 2009-12-15 02:42:13.0 +
 @@ -6868,6 +6868,7 @@
     {0x8001, 0x13},
     {0x8000, 0x14},        /* CS2102K */
     {0x8400, 0x15},        /* TAS5130K */
 +    {0xe400, 0x15},
  };

  static int vga_3wr_probe(struct gspca_dev *gspca_dev)
 @@ -7634,7 +7635,7 @@
     {USB_DEVICE(0x0698, 0x2003)},
     {USB_DEVICE(0x0ac8, 0x0301), .driver_info = SENSOR_PAS106},
     {USB_DEVICE(0x0ac8, 0x0302), .driver_info = SENSOR_PAS106},
 -    {USB_DEVICE(0x0ac8, 0x301b)},
 +    {USB_DEVICE(0x0ac8, 0x301b), .driver_info = SENSOR_PB0330},
     {USB_DEVICE(0x0ac8, 0x303b)},
     {USB_DEVICE(0x0ac8, 0x305b), .driver_info =
 SENSOR_TAS5130C_VF0250}, {USB_DEVICE(0x0ac8, 0x307b)},


 Hello Luis and Leandro,

 Thanks for the patch. Luis said his sensor is the tas5130K, so the 2nd
 part of the patch is useless. But, maybe, Leandro, have you heard about
 other chipset revision IDs?

 Best regards.




--
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: Success for Compro E650F analog television and alsa sound.

2009-12-15 Thread Igor M. Liplianin

On 7 декабря 2009 18:04:14 Steven Toth wrote:
 On Sun, Dec 6, 2009 at 9:00 PM, Igor M. Liplianin liplia...@me.by wrote:
  Hi Steve
 
  I'm able to watch now analog television with Compro E650F.
  I rich this by merging your cx23885-alsa tree and adding some
  modifications for Compro card definition.
  Actually, I take it from Mygica definition, only tuner type and DVB port
  is different. Tested with Tvtime.
 
  tvtime | arecord -D hw:2,0 -r 32000 -c 2 -f S16_LE | aplay -
 
  My tv card is third for alsa, so parameter -D for arecord is hw:2,0.
  SECAM works well also.
  I didn't test component input, though it present in my card.

 Thanks Igor, I'll merge this into the cx23885-alsa tree in the next
 couple of days.

 Regards,
Tested Television and Composite inputs.

{
.type   = CX23885_VMUX_TELEVISION,
.vmux   = CX25840_COMPOSITE2,
}, {
.type   = CX23885_VMUX_COMPOSITE1,
.vmux   = CX25840_COMPOSITE1,
}
The card also have Svideo and Component inputs.
I will try to test them later.
-- 
Igor M. Liplianin
Microsoft Windows Free Zone - Linux used for all Computing Tasks
--
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: uvcvideo kernel panic when using libv4l

2009-12-15 Thread Pablo Baena

With that patch, libv4l throws an error at some point, no crashes so far though:

libv4l2: error dequeuing buf: Invalid argument
read error 22, Invalid argument

On Tue, Dec 15, 2009 at 9:12 PM, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
 Hi Leandro and Pablo,

 could you please try the following patch ? It closes a race window that I
 believe could be at the core of your kernel panic.

 diff -r c1f376eae978 linux/drivers/media/video/uvc/uvc_queue.c
 --- a/linux/drivers/media/video/uvc/uvc_queue.c Sat Dec 12 18:57:17 2009 +0100
 +++ b/linux/drivers/media/video/uvc/uvc_queue.c Wed Dec 16 01:10:21 2009 +0100
 @@ -59,7 +59,7 @@
  *    returns immediately.
  *
  *    When the buffer is full, the completion handler removes it from the irq
 - *    queue, marks it as ready (UVC_BUF_STATE_DONE) and wakes its wait queue.
 + *    queue, marks it as ready (UVC_BUF_STATE_READY) and wakes its wait 
 queue.
  *    At that point, any process waiting on the buffer will be woken up. If a
  *    process tries to dequeue a buffer after it has been marked ready, the
  *    dequeing will succeed immediately.
 @@ -196,11 +196,12 @@

        switch (buf-state) {
        case UVC_BUF_STATE_ERROR:
 -       case UVC_BUF_STATE_DONE:
 +       case UVC_BUF_STATE_READY:
                v4l2_buf-flags |= V4L2_BUF_FLAG_DONE;
                break;
        case UVC_BUF_STATE_QUEUED:
        case UVC_BUF_STATE_ACTIVE:
 +       case UVC_BUF_STATE_DONE:
                v4l2_buf-flags |= V4L2_BUF_FLAG_QUEUED;
                break;
        case UVC_BUF_STATE_IDLE:
 @@ -341,13 +342,14 @@
                uvc_trace(UVC_TRACE_CAPTURE, [W] Corrupted data 
                        (transmission error).\n);
                ret = -EIO;
 -       case UVC_BUF_STATE_DONE:
 +       case UVC_BUF_STATE_READY:
                buf-state = UVC_BUF_STATE_IDLE;
                break;

        case UVC_BUF_STATE_IDLE:
        case UVC_BUF_STATE_QUEUED:
        case UVC_BUF_STATE_ACTIVE:
 +       case UVC_BUF_STATE_DONE:
        default:
                uvc_trace(UVC_TRACE_CAPTURE, [E] Invalid buffer state %u 
                        (driver bug?).\n, buf-state);
 @@ -383,7 +385,7 @@
        buf = list_first_entry(queue-mainqueue, struct uvc_buffer, stream);

        poll_wait(file, buf-wait, wait);
 -       if (buf-state == UVC_BUF_STATE_DONE ||
 +       if (buf-state == UVC_BUF_STATE_READY ||
            buf-state == UVC_BUF_STATE_ERROR)
                mask |= POLLIN | POLLRDNORM;

 @@ -489,6 +491,7 @@

        spin_lock_irqsave(queue-irqlock, flags);
        list_del(buf-queue);
 +       buf-state = UVC_BUF_STATE_READY;
        if (!list_empty(queue-irqqueue))
                nextbuf = list_first_entry(queue-irqqueue, struct uvc_buffer,
                                           queue);
 diff -r c1f376eae978 linux/drivers/media/video/uvc/uvc_video.c
 --- a/linux/drivers/media/video/uvc/uvc_video.c Sat Dec 12 18:57:17 2009 +0100
 +++ b/linux/drivers/media/video/uvc/uvc_video.c Wed Dec 16 01:10:21 2009 +0100
 @@ -578,8 +578,7 @@
                uvc_video_decode_end(stream, buf, mem,
                        urb-iso_frame_desc[i].actual_length);

 -               if (buf-state == UVC_BUF_STATE_DONE ||
 -                   buf-state == UVC_BUF_STATE_ERROR)
 +               if (buf-state == UVC_BUF_STATE_DONE)
                        buf = uvc_queue_next_buffer(stream-queue, buf);
        }
  }
 @@ -637,8 +636,7 @@
                if (!stream-bulk.skip_payload  buf != NULL) {
                        uvc_video_decode_end(stream, buf, stream-bulk.header,
                                stream-bulk.payload_size);
 -                       if (buf-state == UVC_BUF_STATE_DONE ||
 -                           buf-state == UVC_BUF_STATE_ERROR)
 +                       if (buf-state == UVC_BUF_STATE_DONE)
                                buf = uvc_queue_next_buffer(stream-queue,
                                                            buf);
                }
 diff -r c1f376eae978 linux/drivers/media/video/uvc/uvcvideo.h
 --- a/linux/drivers/media/video/uvc/uvcvideo.h  Sat Dec 12 18:57:17 2009 +0100
 +++ b/linux/drivers/media/video/uvc/uvcvideo.h  Wed Dec 16 01:10:21 2009 +0100
 @@ -370,7 +370,8 @@
        UVC_BUF_STATE_QUEUED    = 1,
        UVC_BUF_STATE_ACTIVE    = 2,
        UVC_BUF_STATE_DONE      = 3,
 -       UVC_BUF_STATE_ERROR     = 4,
 +       UVC_BUF_STATE_READY     = 4,
 +       UVC_BUF_STATE_ERROR     = 5,
  };

  struct uvc_buffer {

 --
 Regards,

 Laurent Pinchart




-- 
Not possessing the gift of reflection, a dog does not know that he
does not know, and does not understand that he understands nothing;
we, on the other hand, are aware of both. If we behave otherwise, it
is from stupidity, or else from self-deception, to preserve our peace
of mind.
--
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: USB MAssage Storage drivers

2009-12-15 Thread Philby John

On Tue, 2009-12-15 at 18:46 -0500, Gopala Gottumukkala wrote:
 My target is not recognizing the USB massage storage. I am working the
 2.6.32 Davinci kernel
 
 Any suggestion and ideas.

ahah, this information isn't enough. Your Vendor/Product ID for this
device is compared in a lookup a table. If no match is found, your
device probably won't be detected as mass storage. You could check in
the unusual_devs.h to see if your device is included there, if your
device is relatively new you could submit a Vendor/Product ID to the USB
dev list for inclusion.


Regards,
Philby






--
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: High cpu load (dvb_usb_dib0700)

2009-12-15 Thread Jan Korbel


Hello.

Patrick Boettcher wrote:

Have you tried to load dvb-usb with disable_rc_polling=1 ?

It may or may not help.

If it helps it will necessary to have a look at the ir-polling code to 
see whether there is some thing like 'scheduling'.


regards,


It helps :) Thanks.

J.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [PATCH - v1 4/6] V4L - vpfe_capture bug fix and enhancements