Re: Order of dvb devices
Manu Abraham wrote: On Sat, Jan 16, 2010 at 3:00 AM, Oliver Endriss o.endr...@gmx.de wrote: Devin Heitmueller wrote: On Thu, Jan 14, 2010 at 11:01 AM, Andreas Besse be...@motama.com wrote: yes if there are different drivers I already observed the behaviour that the ordering gets flipped after reboot. But if I assume, that there is only *one* driver that is loaded (e.g. budget_av) for all dvb cards in the system, how is the ordering of these devices determined? How does the driver search for available dvb cards? The driver does not 'search' for a card. The driver registers the ids of all supported cards with the pci subsystem of the kernel. When the pci subsystem detects a new card, it calls the 'probe' routine of the driver (for example saa7146_init_one for saa7146-based cards). So the ordering is determined by the pci subsystem. I believe your assumption is incorrect. I believe the enumeration order is not deterministic even for multiple instances of the same driver. It is not uncommon to hear mythtv users complain that I have two PVR-150 cards installed in my PC and the order sometimes get reversed on reboot. Afaik the indeterministic behaviour is caused by udev, not by the kernel. We never had these problems before udev was introduced. True, the ordering is not exactly the same everytime. One will need to provide PCI Bus related info also to a practical udev configuration to get things sorted out in a sane way, rather than anything else. with PCI Bus related info you mean the KERNELS parameter which is reported by udevinfo? udevinfo -a -p $(udevinfo -q path -n /dev/dvb/adapter0/frontend0) [...] looking at parent device '/devices/pci:00/:00:1e.0/:08:00.0': KERNELS==:08:00.0 SUBSYSTEMS==pci does this KERNELS parameter always match the Slot-Id of lspci -vmm ? Slot: 08:00.0 Class: Multimedia controller Vendor: Philips Semiconductors Device: SAA7146 SVendor:Technotrend Systemtechnik GmbH SDevice:S2-3200 Rev:01 is it right that the Slot-Id is deterministic for PCI/PCIe based systems? -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://udev.netup.ru/hg/v4l-dvb-aospan-22fix
Abylai Ospan wrote: On Sat, 2010-01-16 at 11:18 -0200, Mauro Carvalho Chehab wrote: Abylai Ospan wrote: Mauro, Please pulll change: http://udev.netup.ru/cgi-bin/hgwebdir.cgi/v4l-dvb-aospan-22fix/rev/fc3e44f30da3 22-kHz set_tone fix for NetUP Dual DVB-S2-CI card. 22kHz logic controlled by demod. This patch modified after discussion with Oliver. This version is acceptable for both side ... Thanks. Your site seems to be down: abort: error: No route to host Please send me a pull request when the site returns. Please try again. Should work. Thanks. Patch is ok. Signed-off-by: Oliver Endriss o.endr...@gmx.de Oliver -- VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/ 4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/ Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/ -- 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: Do any drivers access the cx25840 module in an atomic context?
On Monday 18 January 2010 06:19:28 Andy Walls wrote: Hi, I am going to add locking to the cx25840 module register reads and writes because I now have a case where a workqueue, a userpace, and/or the cx25840 firmware loading workqueue could contend for access to the CX2584x or equivalent device. I have identiifed the following drivers that actually use this module: cx231xx, pvrusb2, ivtv, cx23885 Now here's where I need help, since I don't understand the USB stuff too well and there's a lot of code to audit: Do any of these modules call the cx25840 routines with either: a. call the cx25840 module subdev functions with a spinlock held ? or b. call the cx25840 module subdev functions from an interrupt context: i.e. a hard irq or tasklet ? or c. bypass the normal cx25840_read/write calls with direct I2C access to the client address of 0x44 (0x88 1) ? Any definitive confirmation anyone can give on any of these drivers would be helpful and would save me some time. For ivtv: a. no b. no c. no BTW: b should never happen. i2c reads/writes are very slow and so it is a very bad idea to do that in interrupt context. Since there is some low-level locking in the i2c stack as well I think it will probably not even work correctly if called from interrupt context. Note that AFAIK the i2c stack will already serialize i2c commands for you. So are you sure you need to serialize access on the higher levels as well? Firmware load should be already serialized in the bridge driver. That leaves a possible call to cx25840_reset() which can trigger a fw load at any time, but I believe that can be removed as well since it is only used by the IR reset code which is obsolete. At least in ivtv I have never seen any issues with cx25840 and atomic contexts. Regards, Hans For the cx23885 driver I think these are the answers: a. probably not b. probably not c. yes but I have to double check. I can probably audit the ivtv driver on my own. I understand it's structure, but it's a big driver and will take time to check, if no one knows off hand. The pvrusb2 and cx231xx will be a little harder for me. They aren't terribly large, but I don't understand USB device interrupt contexts. TIA. Regards, Andy -- 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: Order of dvb devices
On Mon, Jan 18, 2010 at 12:58 PM, Andreas Besse be...@motama.com wrote: Manu Abraham wrote: On Sat, Jan 16, 2010 at 3:00 AM, Oliver Endriss o.endr...@gmx.de wrote: Devin Heitmueller wrote: On Thu, Jan 14, 2010 at 11:01 AM, Andreas Besse be...@motama.com wrote: yes if there are different drivers I already observed the behaviour that the ordering gets flipped after reboot. But if I assume, that there is only *one* driver that is loaded (e.g. budget_av) for all dvb cards in the system, how is the ordering of these devices determined? How does the driver search for available dvb cards? The driver does not 'search' for a card. The driver registers the ids of all supported cards with the pci subsystem of the kernel. When the pci subsystem detects a new card, it calls the 'probe' routine of the driver (for example saa7146_init_one for saa7146-based cards). So the ordering is determined by the pci subsystem. I believe your assumption is incorrect. I believe the enumeration order is not deterministic even for multiple instances of the same driver. It is not uncommon to hear mythtv users complain that I have two PVR-150 cards installed in my PC and the order sometimes get reversed on reboot. Afaik the indeterministic behaviour is caused by udev, not by the kernel. We never had these problems before udev was introduced. True, the ordering is not exactly the same everytime. One will need to provide PCI Bus related info also to a practical udev configuration to get things sorted out in a sane way, rather than anything else. with PCI Bus related info you mean the KERNELS parameter which is reported by udevinfo? udevinfo -a -p $(udevinfo -q path -n /dev/dvb/adapter0/frontend0) [...] looking at parent device '/devices/pci:00/:00:1e.0/:08:00.0': KERNELS==:08:00.0 SUBSYSTEMS==pci does this KERNELS parameter always match the Slot-Id of lspci -vmm ? Slot: 08:00.0 Class: Multimedia controller Vendor: Philips Semiconductors Device: SAA7146 SVendor: Technotrend Systemtechnik GmbH SDevice: S2-3200 Rev: 01 is it right that the Slot-Id is deterministic for PCI/PCIe based systems? Slot can also change, since slots are behind a specific bridge which could be susceptible to events such as hotplug. Also things such as PCI reordering and things like that tend to muck up things even more.Things such as DVB_ADAPTER number are also pointless and useless. You can see an example how to handle it in a bit practical manner: http://www.wlug.org.nz/UDev Regards, Manu -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] s2-liplianin Technotrend TT-Connect S-2400
On Mon, Jan 18, 2010 at 2:33 PM, Harald Milz h...@seneca.muc.de wrote: Hi, I am trying to use a S-2400 for Hotbird in addition to 2 S2-3650's pointing at Astra. For the 3650's I need to use s2-liplianin because the box is not yet supported by my stock OpenSUSE 11.1 (update) kernel. The 3650's work fine so far. I have no luck with the 2400, though. Attached is the syslog excerpt - maybe someone can see what is wrong here. The driver code is s2-liplianin-head from last Saturday. Shortcut question: Do I want to get another 3650 / 3600? I had no luck with a quad monoblock LNB either... I think the ttusb2 driver from http://linuxtv.org/hg/v4l-dvb would work with regards to the S-2400. Regards, Manu -- 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
T-Mobile web'n'walk Box multimedia
Hi, recently I bought this nice litte web'n'walk Box multimedia from T-Mobile (for about 40 euro), a USB device that works as a UMTS-Modem and DVB-T-Receiver at once. It turned out, that it actually is a Huawei E510 and uses a DiBcom DIB9080HA chip. Is there a chance to get it to work with Linux ? Regards, Mat -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser -- 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 v2 1/7] V4L: File handles
Hi Sakari,
I should have reviewed this weeks ago, but better late than never...
On Tue, 22 Dec 2009, Sakari Ailus wrote:
This patch adds a list of v4l2_fh structures to every video_device.
It allows using file handle related information in V4L2. The event interface
is one example of such use.
Video device drivers should use the v4l2_fh pointer as their
file-private_data.
Signed-off-by: Sakari Ailus sakari.ai...@maxwell.research.nokia.com
---
drivers/media/video/Makefile |2 +-
drivers/media/video/v4l2-dev.c |2 +
drivers/media/video/v4l2-fh.c | 57
include/media/v4l2-dev.h |4 +++
include/media/v4l2-fh.h| 41
5 files changed, 105 insertions(+), 1 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..15b2ac8 100644
--- a/drivers/media/video/v4l2-dev.c
+++ b/drivers/media/video/v4l2-dev.c
@@ -421,6 +421,8 @@ static int __video_register_device(struct video_device
*vdev, int type, int nr,
if (!vdev-release)
return -EINVAL;
+ v4l2_fh_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..406e4ac
--- /dev/null
+++ b/drivers/media/video/v4l2-fh.c
@@ -0,0 +1,57 @@
+/*
+ * 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
Weird includes. I would expect to see only spinlock.h and list.h to be included
here.
Regards,
Hans
+
+int v4l2_fh_add(struct video_device *vdev, struct v4l2_fh *fh)
+{
+ unsigned long flags;
+
+ 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_fh_add);
+
+void v4l2_fh_del(struct video_device *vdev, struct v4l2_fh *fh)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(vdev-fh_lock, flags);
+ list_del(fh-list);
+ spin_unlock_irqrestore(vdev-fh_lock, flags);
+}
+EXPORT_SYMBOL_GPL(v4l2_fh_del);
+
+void v4l2_fh_init(struct video_device *vdev)
+{
+ spin_lock_init(vdev-fh_lock);
+ INIT_LIST_HEAD(vdev-fh);
+}
diff --git a/include/media/v4l2-dev.h b/include/media/v4l2-dev.h
index 2dee938..8eac93d 100644
--- a/include/media/v4l2-dev.h
+++ b/include/media/v4l2-dev.h
@@ -16,6 +16,8 @@
#include linux/mutex.h
#include linux/videodev2.h
+#include media/v4l2-fh.h
+
#define VIDEO_MAJOR 81
#define VFL_TYPE_GRABBER0
@@ -77,6 +79,8 @@ struct video_device
/* attribute to differentiate multiple indices on one physical device */
int index;
+ spinlock_t fh_lock; /* Lock for file handle list */
+ struct list_head fh;/* File handle list */
int debug; /* Activates debug level*/
/* Video standard vars */
diff --git a/include/media/v4l2-fh.h b/include/media/v4l2-fh.h
new file mode 100644
index 000..1efa916
--- /dev/null
+++ b/include/media/v4l2-fh.h
@@ -0,0 +1,41 @@
+/*
+ * include/media/v4l2-fh.h
+ *
+ * V4L2 file handle.
+ *
+ * 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
Re: [PATCH 1/2, RFC] gspca: add input support for interrupt endpoints
Hi,
Thanks for your continued work on this. I'm afraid I found
one thing which needs fixing (can be fixed with
a separate patch after merging, but that is up to
Jean-Francois).
See my comments inline.
On 01/17/2010 02:08 PM, Németh Márton wrote:
From: Márton Némethnm...@freemail.hu
Add support functions for interrupt endpoint based input handling.
Signed-off-by: Márton Némethnm...@freemail.hu
---
diff -r 875c200a19dc linux/drivers/media/video/gspca/gspca.c
--- a/linux/drivers/media/video/gspca/gspca.c Sun Jan 17 07:58:51 2010 +0100
+++ b/linux/drivers/media/video/gspca/gspca.c Sun Jan 17 13:47:44 2010 +0100
@@ -3,6 +3,9 @@
*
* Copyright (C) 2008-2009 Jean-Francois Moine (http://moinejf.free.fr)
*
+ * Camera button input handling by Márton Németh
+ * Copyright (C) 2009-2010 Márton Némethnm...@freemail.hu
+ *
* 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
@@ -41,6 +44,9 @@
#include gspca.h
+#includelinux/input.h
+#includelinux/usb/input.h
+
/* global values */
#define DEF_NURBS 3 /* default number of URBs */
#if DEF_NURBS MAX_NURBS
@@ -112,6 +118,167 @@
.close = gspca_vm_close,
};
+/*
+ * Input and interrupt endpoint handling functions
+ */
+#ifdef CONFIG_INPUT
+#if LINUX_VERSION_CODE KERNEL_VERSION(2, 6, 19)
+static void int_irq(struct urb *urb, struct pt_regs *regs)
+#else
+static void int_irq(struct urb *urb)
+#endif
+{
+ struct gspca_dev *gspca_dev = (struct gspca_dev *) urb-context;
+ int ret;
+
+ if (urb-status == 0) {
+ if (gspca_dev-sd_desc-int_pkt_scan(gspca_dev,
+ urb-transfer_buffer, urb-actual_length) 0) {
+ PDEBUG(D_ERR, Unknown packet received);
+ }
+
+ ret = usb_submit_urb(urb, GFP_ATOMIC);
+ if (ret 0)
+ PDEBUG(D_ERR, Resubmit URB failed with error %i, ret);
+ }
+}
+
If the status is not 0 you should print an error message, and
reset the status and still resubmit the urb, if you don't resubmit
on error, after one single usb glitch, the button will stop working.
+static int gspca_input_connect(struct gspca_dev *dev)
+{
+ struct input_dev *input_dev;
+ int err = 0;
+
+ dev-input_dev = NULL;
+ if (dev-sd_desc-int_pkt_scan) {
+ input_dev = input_allocate_device();
+ if (!input_dev)
+ return -ENOMEM;
+
+ usb_make_path(dev-dev, dev-phys, sizeof(dev-phys));
+ strlcat(dev-phys, /input0, sizeof(dev-phys));
+
+ input_dev-name = dev-sd_desc-name;
+ input_dev-phys = dev-phys;
+
+ usb_to_input_id(dev-dev,input_dev-id);
+
+ input_dev-evbit[0] = BIT_MASK(EV_KEY);
+ input_dev-keybit[BIT_WORD(KEY_CAMERA)] = BIT_MASK(KEY_CAMERA);
+ input_dev-dev.parent =dev-dev-dev;
+
+ err = input_register_device(input_dev);
+ if (err) {
+ PDEBUG(D_ERR, Input device registration failed
+ with error %i, err);
+ input_dev-dev.parent = NULL;
+ input_free_device(input_dev);
+ } else {
+ dev-input_dev = input_dev;
+ }
+ } else
+ err = -EINVAL;
+
+ return err;
+}
+
+static int alloc_and_submit_int_urb(struct gspca_dev *gspca_dev,
+ struct usb_endpoint_descriptor *ep)
+{
+ unsigned int buffer_len;
+ int interval;
+ struct urb *urb;
+ struct usb_device *dev;
+ void *buffer = NULL;
+ int ret = -EINVAL;
+
+ buffer_len = ep-wMaxPacketSize;
+ interval = ep-bInterval;
+ PDEBUG(D_PROBE, found int in endpoint: 0x%x,
+ buffer_len=%u, interval=%u,
+ ep-bEndpointAddress, buffer_len, interval);
+
+ dev = gspca_dev-dev;
+
+ urb = usb_alloc_urb(0, GFP_KERNEL);
+ if (!urb) {
+ ret = -ENOMEM;
+ goto error;
+ }
+
+ buffer = usb_buffer_alloc(dev, ep-wMaxPacketSize,
+ GFP_KERNEL,urb-transfer_dma);
+ if (!buffer) {
+ ret = -ENOMEM;
+ goto error_buffer;
+ }
+ usb_fill_int_urb(urb, dev,
+ usb_rcvintpipe(dev, ep-bEndpointAddress),
+ buffer, buffer_len,
+ int_irq, (void *)gspca_dev, interval);
+ gspca_dev-int_urb = urb;
+ ret = usb_submit_urb(urb, GFP_KERNEL);
+ if (ret 0) {
+ PDEBUG(D_ERR, submit URB failed with error %i, ret);
+ goto error_submit;
+ }
+ return ret;
+
+error_submit:
+ usb_buffer_free(dev,
+
Re: [RFC v2 4/7] V4L: Events: Add backend
Hi Sakari,
The code looks good, but I'm not so sure about the use of kmem_cache_*. It
seems serious overkill to me.
Most of the time there will only be a handful of event messages pending. So
setting up a kmem_cache for this seems unnecessary to me.
A much better way to ensure fast event reporting IMHO would be to keep a list
of empty event messages rather than destroying an event after it is dequeued.
So you have two queues per filehandle: pending and empty; initially both are
empty. When a new event has to be queued the code checks if there are events
available for reuse in the empty queue, and if not a new event struct is
allocated and added to the pending queue.
When userspace dequeues the event the kernel will not destroy the event struct
but requeue it in the empty queue for reuse. This is also an ideal place to
check for queue overflowing (which is definitely needed).
In general allocating memory is a slow operation, so not freeing that memory
will speed up things. Drivers might even preallocate a certain number of events
in the empty queue if the last drop of performance is needed.
But right now I don't think there is any need for that.
Regards,
Hans
On Tue, 22 Dec 2009, Sakari Ailus wrote:
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-dev.c | 21 +++-
drivers/media/video/v4l2-event.c | 254 ++
drivers/media/video/v4l2-fh.c|4 +
include/media/v4l2-event.h | 65 ++
include/media/v4l2-fh.h |3 +
6 files changed, 346 insertions(+), 4 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-dev.c b/drivers/media/video/v4l2-dev.c
index 15b2ac8..6d25297 100644
--- a/drivers/media/video/v4l2-dev.c
+++ b/drivers/media/video/v4l2-dev.c
@@ -613,22 +613,36 @@ static int __init videodev_init(void)
dev_t dev = MKDEV(VIDEO_MAJOR, 0);
int ret;
+ ret = v4l2_event_init();
+ if (ret 0) {
+ printk(KERN_WARNING videodev: unable to initialise events\n);
+ return ret;
+ }
+
printk(KERN_INFO Linux video capture interface: v2.00\n);
ret = register_chrdev_region(dev, VIDEO_NUM_DEVICES, VIDEO_NAME);
if (ret 0) {
printk(KERN_WARNING videodev: unable to get major %d\n,
VIDEO_MAJOR);
- return ret;
+ goto out_register_chrdev_region;
}
ret = class_register(video_class);
if (ret 0) {
- unregister_chrdev_region(dev, VIDEO_NUM_DEVICES);
printk(KERN_WARNING video_dev: class_register failed\n);
- return -EIO;
+ ret = -EIO;
+ goto out_class_register;
}
return 0;
+
+out_class_register:
+ unregister_chrdev_region(dev, VIDEO_NUM_DEVICES);
+
+out_register_chrdev_region:
+ v4l2_event_exit();
+
+ return ret;
}
static void __exit videodev_exit(void)
@@ -637,6 +651,7 @@ static void __exit videodev_exit(void)
class_unregister(video_class);
unregister_chrdev_region(dev, VIDEO_NUM_DEVICES);
+ v4l2_event_exit();
}
module_init(videodev_init)
diff --git a/drivers/media/video/v4l2-event.c b/drivers/media/video/v4l2-event.c
new file mode 100644
index 000..9fc0c81
--- /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
Re: [RFC v2 6/7] V4L: Events: Sequence numbers
Hi Sakari,
Some more review comments:
On Tue, 22 Dec 2009, Sakari Ailus wrote:
Add sequence numbers to events.
Signed-off-by: Sakari Ailus sakari.ai...@maxwell.research.nokia.com
---
drivers/media/video/v4l2-event.c |8
include/media/v4l2-event.h |1 +
2 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/v4l2-event.c b/drivers/media/video/v4l2-event.c
index 72fdf7f..cc2bf57 100644
--- a/drivers/media/video/v4l2-event.c
+++ b/drivers/media/video/v4l2-event.c
@@ -58,6 +58,7 @@ void v4l2_event_init_fh(struct v4l2_fh *fh)
INIT_LIST_HEAD(events-subscribed);
atomic_set(events-navailable, 0);
+ events-sequence = 0;
Why not make this atomic_t as well?
}
EXPORT_SYMBOL_GPL(v4l2_event_init_fh);
@@ -158,10 +159,16 @@ void v4l2_event_queue(struct video_device *vdev, struct
v4l2_event *ev)
list_for_each_entry(fh, vdev-fh, list) {
struct _v4l2_event *_ev;
+ u32 sequence;
if (!v4l2_event_subscribed(fh, ev-type))
continue;
+ spin_lock(fh-events.lock);
+ sequence = fh-events.sequence;
+ fh-events.sequence++;
+ spin_unlock(fh-events.lock);
Then you can use atomic_inc_return() here.
+
if (atomic_read(fh-events.navailable) = V4L2_MAX_EVENTS)
continue;
@@ -172,6 +179,7 @@ void v4l2_event_queue(struct video_device *vdev, struct
v4l2_event *ev)
_ev-event = *ev;
spin_lock(fh-events.lock);
+ _ev-event.sequence = sequence;
list_add_tail(_ev-list, fh-events.available);
spin_unlock(fh-events.lock);
diff --git a/include/media/v4l2-event.h b/include/media/v4l2-event.h
index 69305c6..5a778d4 100644
--- a/include/media/v4l2-event.h
+++ b/include/media/v4l2-event.h
@@ -44,6 +44,7 @@ struct v4l2_events {
spinlock_t lock; /* Protect everything here. */
struct list_headavailable;
atomic_tnavailable;
+ u32 sequence;
wait_queue_head_t wait;
struct list_headsubscribed; /* Subscribed events. */
};
--
1.5.6.5
Regards,
Hans
--
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 v2 5/7] V4L: Events: Limit event queue length
Hi Sakari,
More comments:
On Tue, 22 Dec 2009, Sakari Ailus wrote:
Limit event queue length to V4L2_MAX_EVENTS. If the queue is full any
further events will be dropped.
This patch also updates the count field properly, setting it to exactly to
number of further available events.
Signed-off-by: Sakari Ailus sakari.ai...@maxwell.research.nokia.com
---
drivers/media/video/v4l2-event.c | 10 +-
include/media/v4l2-event.h |5 +
2 files changed, 14 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/v4l2-event.c b/drivers/media/video/v4l2-event.c
index 9fc0c81..72fdf7f 100644
--- a/drivers/media/video/v4l2-event.c
+++ b/drivers/media/video/v4l2-event.c
@@ -56,6 +56,8 @@ void v4l2_event_init_fh(struct v4l2_fh *fh)
INIT_LIST_HEAD(events-available);
INIT_LIST_HEAD(events-subscribed);
+
+ atomic_set(events-navailable, 0);
}
EXPORT_SYMBOL_GPL(v4l2_event_init_fh);
@@ -103,7 +105,8 @@ int v4l2_event_dequeue(struct v4l2_fh *fh, struct
v4l2_event *event)
ev = list_first_entry(events-available, struct _v4l2_event, list);
list_del(ev-list);
- ev-event.count = !list_empty(events-available);
+ atomic_dec(events-navailable);
+ ev-event.count = atomic_read(events-navailable);
Combine these two lines to atomic_dec_return().
spin_unlock_irqrestore(events-lock, flags);
@@ -159,6 +162,9 @@ void v4l2_event_queue(struct video_device *vdev, struct
v4l2_event *ev)
if (!v4l2_event_subscribed(fh, ev-type))
continue;
+ if (atomic_read(fh-events.navailable) = V4L2_MAX_EVENTS)
+ continue;
+
_ev = kmem_cache_alloc(event_kmem, GFP_ATOMIC);
if (!_ev)
continue;
@@ -169,6 +175,8 @@ void v4l2_event_queue(struct video_device *vdev, struct
v4l2_event *ev)
list_add_tail(_ev-list, fh-events.available);
spin_unlock(fh-events.lock);
+ atomic_inc(fh-events.navailable);
+
wake_up_all(fh-events.wait);
}
diff --git a/include/media/v4l2-event.h b/include/media/v4l2-event.h
index b11de92..69305c6 100644
--- a/include/media/v4l2-event.h
+++ b/include/media/v4l2-event.h
@@ -28,6 +28,10 @@
#include linux/types.h
#include linux/videodev2.h
+#include asm/atomic.h
+
+#define V4L2_MAX_EVENTS1024 /* Ought to be enough for
everyone. */
I think this should be programmable by the driver. Most drivers do not use
events at all, so by default it should be 0 or perhaps it can check whether
the ioctl callback structure contains the event ioctls and set it to 0 or
some initial default value.
And you want this to be controlled on a per-filehandle basis even. If I look
at ivtv, then most of the device nodes will not have events, only a few will
support events. And for one device node type I know that there will only be
a single event when stopping the streaming, while another device node type
will get an event each frame.
So being able to adjust the event queue dynamically will give more control
and prevent unnecessary waste of memory resources.
Regards,
Hans
+
struct v4l2_fh;
struct video_device;
@@ -39,6 +43,7 @@ struct _v4l2_event {
struct v4l2_events {
spinlock_t lock; /* Protect everything here. */
struct list_headavailable;
+ atomic_tnavailable;
wait_queue_head_t wait;
struct list_headsubscribed; /* Subscribed events. */
};
--
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
Re: [RFC v2 0/7] V4L2 file handles and event interface
Hi Sakari, Some notes on this as well (and that concludes my review): On Tue, 22 Dec 2009, Sakari Ailus wrote: Hi, Here's the second version of the V4L2 file handle and event interface patchset. Still RFC since I'd like to get more feedback on it. The first patch adds the V4L2 file handle support and the rest are for V4L2 events. The patchset works with the OMAP 3 ISP driver. Patches for OMAP 3 ISP are not part of this patchset but are available in Gitorious (branch is called events): git://gitorious.org/omap3camera/mainline.git event The major change since the last one v4l2_fh structure is now part of driver's own file handle. It's used as file-private_data as well. I did this based on Hans Verkuil's suggestion. Sequence numbers and event queue length limitation is there as well. There are countless of smaller changes, too. 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? - Poll. The V4L2 specifiction says: When the application did not call VIDIOC_QBUF or VIDIOC_STREAMON yet the poll() function succeeds, but sets the POLLERR flag in the revents field. The current events for OMAP 3 ISP are related to streaming but not all might be in future. For example there might be some radio or DVB related events. I know for sure that we will have to be able to handle events when not streaming. E.g. events that tell when a HDMI connector was plugged in or when the EDID was read will need to arrive whether streaming is on or off. - Sequence numbers are local to file handles. That is how it should be. - Subscribing V4L2_EVENT_ALL causes any other events to be unsubscribed. - If V4L2_EVENT_ALL has been subscribed, unsubscribing any one of the events leads to V4L2_EVENT_ALL to be unsubscribed. This problem would be difficult to work around since this would require the event system to be aware of the driver private events as well. Good point. Perhaps attempting to unsubscribe a single event when EVENT_ALL has been subscribed should result in an error? I.e., you can only unsubscribe ALL when you subscribed to ALL in the first place. Regards, Hans - If events are missed, the sequence number is incremented in any case. This way the user space knows events have been missed. Comments would be very, 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
Re: Order of dvb devices
Manu Abraham wrote:
On Mon, Jan 18, 2010 at 12:58 PM, Andreas Besse be...@motama.com wrote:
Manu Abraham wrote:
On Sat, Jan 16, 2010 at 3:00 AM, Oliver Endriss o.endr...@gmx.de wrote:
Devin Heitmueller wrote:
On Thu, Jan 14, 2010 at 11:01 AM, Andreas Besse be...@motama.com wrote:
yes if there are different drivers I already observed the behaviour that
the ordering gets flipped after reboot.
But if I assume, that there is only *one* driver that is loaded (e.g.
budget_av) for all dvb cards in the system, how is the ordering of these
devices determined? How does the driver search for available dvb cards?
The driver does not 'search' for a card. The driver registers the ids of
all supported cards with the pci subsystem of the kernel.
When the pci subsystem detects a new card, it calls the 'probe' routine
of the driver (for example saa7146_init_one for saa7146-based cards).
So the ordering is determined by the pci subsystem.
I believe your assumption is incorrect. I believe the enumeration
order is not deterministic even for multiple instances of the same
driver. It is not uncommon to hear mythtv users complain that I have
two PVR-150 cards installed in my PC and the order sometimes get
reversed on reboot.
Afaik the indeterministic behaviour is caused by udev, not by the
kernel. We never had these problems before udev was introduced.
True, the ordering is not exactly the same everytime. One will need to
provide PCI Bus related info also to a practical udev configuration to
get things sorted out in a sane way, rather than anything else.
with PCI Bus related info you mean the KERNELS parameter which is
reported by udevinfo?
udevinfo -a -p $(udevinfo -q path -n /dev/dvb/adapter0/frontend0)
[...]
looking at parent device '/devices/pci:00/:00:1e.0/:08:00.0':
KERNELS==:08:00.0
SUBSYSTEMS==pci
does this KERNELS parameter always match the Slot-Id of lspci -vmm ?
Slot: 08:00.0
Class: Multimedia controller
Vendor: Philips Semiconductors
Device: SAA7146
SVendor:Technotrend Systemtechnik GmbH
SDevice:S2-3200
Rev:01
is it right that the Slot-Id is deterministic for PCI/PCIe based systems?
Slot can also change, since slots are behind a specific bridge which
could be susceptible to events such as hotplug. Also things such as
PCI reordering and things like that tend to muck up things even
more.Things such as DVB_ADAPTER number are also pointless and useless.
You can see an example how to handle it in a bit practical manner:
http://www.wlug.org.nz/UDev
thanks for your explanation.
thank for your answer.
if no hotplug (removing or adding PCI/PCie cards) is involved, is the
PCI Slot-ID then fixed?
does the KERNELS parameter of the following udev rule not change after
boot if no hotplug is involved?
SUBSYSTEM==dvb, ATTRS{vendor}==0x18c3, ATTRS{device}==0x0720,
KERNELS==:01:00.0,
PROGRAM=/bin/sh -c 'K=%k; K=$${K#dvb}; printf dvb/adapter0/%%s
$${K#*.}', SYMLINK+=%c
--
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: CI USB
HoP a écrit : I don't know the details into the USB device, but each of those CAM's have bandwidth limits on them and they vary from one CAM to the other. Also, there is a limit on the number of simultaneous PID's that which you can decrypt. Some allow only 1 PID, some allow 3. Those are the basic CAM's for home usage.The most expensive CAM's allow a maximum of 24 PID's. But You, of course, ment number of descramblers not PIDS because it is evident that getting TV service descrambled, you need as minimum 2 PIDS for A/V. Anyway, it is very good note. Users, in general, don't know about it. /Honza Just a quick note here: you might want to post to the mythtv ML and the VDR one also (probably others but I dont know them off hand) and see how people feel about this. My guess is that quite a few potential users are on these ML, and the CI threads are recurrent there because of good dvb-s cards but without CI support. A usb-CI or equivalent HW + good drivers would allow people to pick the dvb-s(2) cards without worrying about CI support. HTH Bye Manu -- 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: How to use saa7134 gpio via gpio-sysfs?
Gentlemen, I may be able to assist here. Specifically what information/photographs are you looking for? Regards, William Tate RTD Embedded Technologies, Inc. -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media-ow...@vger.kernel.org] On Behalf Of hermann pitton Sent: Sunday, January 17, 2010 6:02 PM To: Trent Piepho Cc: Gordon Smith; linux-media@vger.kernel.org Subject: Re: How to use saa7134 gpio via gpio-sysfs? [snip] Damned, seems the opto-isolated I/Os might be in question. For the RTD stuff we don't have any high resolution photographs or anything else ... Gordon, we should wait for, if RTD and Philips/NXP do have a agreement on such. I doubt it, given how it came in. Else, you can of course still do what you ever want on that driver. Cheers, Hermann -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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: em28xx driver - xc3028 tuner - readreg error
2009/12/22 Valerio Bontempi valerio.bonte...@gmail.com:
2009/12/22 Devin Heitmueller dheitmuel...@kernellabs.com:
On Tue, Dec 22, 2009 at 10:11 AM, Valerio Bontempi
valerio.bonte...@gmail.com wrote:
Before the update, v4l-dvb driver worked fine, and now it doesn't work
even if I remove the updated packages.
Checking for kernel modules conflict, I found only the modules
installed by v4l-dvb sources.
#find /lib/modules/`uname -r` -name 'em28xx*' | xargs -i ls -l {}
totale 236
-rw-r--r-- 1 root root 21464 22 dic 16:03
/lib/modules/2.6.31.5-0.1-desktop/kernel/drivers/media/video/em28xx/em28xx-alsa.ko
-rw-r--r-- 1 root root 26176 22 dic 16:03
/lib/modules/2.6.31.5-0.1-desktop/kernel/drivers/media/video/em28xx/em28xx-dvb.ko
-rw-r--r-- 1 root root 184936 22 dic 16:03
/lib/modules/2.6.31.5-0.1-desktop/kernel/drivers/media/video/em28xx/em28xx.ko
My guess is that these files were provided by your distro through a
kernel update (and in 2.6.31 this board is known to have problems
which have been fixed in the latest v4l-dvb tree).
I would suggest the following going into your v4l-dvb tree and doing
the following:
make distclean make make install reboot
And see if the problem clears up.
Devin
--
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
This is just I have done after removing the update packages (all
related to v4l libs and tools, none related to opensuse kernel), but
with no luck
However I have just tried what you suggested, but the problem hasn't
been cleared up
[ 7.276755] em28xx: New device TerraTec Electronic GmbH Cinergy T
USB XS @ 480 Mbps (0ccd:0043, interface 0, class 0)
[ 7.276993] em28xx #0: chip ID is em2870
[ 7.310070] vc032x: Sensor ID 7673 (16)
[ 7.310075] vc032x: Find Sensor OV7670
[ 7.310187] gspca: /dev/video0 created
[ 7.310224] usbcore: registered new interface driver vc032x
[ 7.310228] vc032x: registered
[ 7.394941] em28xx #0: i2c eeprom 00: 1a eb 67 95 cd 0c 43 00 c0 12
5c 00 9e 24 6a 34
[ 7.394956] em28xx #0: i2c eeprom 10: 00 00 06 57 02 0c 00 00 00 00
00 00 00 00 00 00
[ 7.394967] em28xx #0: i2c eeprom 20: 44 00 00 00 f0 10 01 00 00 00
00 00 5b 00 00 00
[ 7.394977] em28xx #0: i2c eeprom 30: 00 00 20 40 20 80 02 20 01 01
00 00 00 00 00 00
[ 7.394988] em28xx #0: i2c eeprom 40: 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00
[ 7.394998] em28xx #0: i2c eeprom 50: 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00
[ 7.395008] em28xx #0: i2c eeprom 60: 00 00 00 00 00 00 00 00 00 00
34 03 54 00 65 00
[ 7.395021] em28xx #0: i2c eeprom 70: 72 00 72 00 61 00 54 00 65 00
63 00 20 00 45 00
[ 7.395032] em28xx #0: i2c eeprom 80: 6c 00 65 00 63 00 74 00 72 00
6f 00 6e 00 69 00
[ 7.395042] em28xx #0: i2c eeprom 90: 63 00 20 00 47 00 6d 00 62 00
48 00 00 00 24 03
[ 7.395052] em28xx #0: i2c eeprom a0: 43 00 69 00 6e 00 65 00 72 00
67 00 79 00 20 00
[ 7.395063] em28xx #0: i2c eeprom b0: 54 00 20 00 55 00 53 00 42 00
20 00 58 00 53 00
[ 7.395074] em28xx #0: i2c eeprom c0: 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00
[ 7.395084] em28xx #0: i2c eeprom d0: 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00
[ 7.395094] em28xx #0: i2c eeprom e0: 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00
[ 7.395104] em28xx #0: i2c eeprom f0: 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00
[ 7.395116] em28xx #0: EEPROM ID= 0x9567eb1a, EEPROM hash = 0xbfdf1b96
[ 7.395119] em28xx #0: EEPROM info:
[ 7.395120] em28xx #0: No audio on board.
[ 7.395122] em28xx #0: 500mA max power
[ 7.395125] em28xx #0: Table at 0x06, strings=0x249e, 0x346a, 0x
[ 7.395813] em28xx #0: Identified as Terratec Cinergy T XS (card=43)
[ 7.395816] em28xx #0:
[ 7.395816]
[ 7.395830] em28xx #0: The support for this board weren't valid yet.
[ 7.395838] em28xx #0: Please send a report of having this working
[ 7.395845] em28xx #0: not to V4L mailing list (and/or to other addresses)
[ 7.395846]
[ 7.412090] forcedeth :00:0a.0: ifname eth0, PHY OUI 0x1374 @
0, addr 00:1a:92:34:d4:d7
[ 7.412096] forcedeth :00:0a.0: highdma csum gbit lnktim desc-v3
[ 7.412275] k8temp :00:18.3: Temperature readouts might be
wrong - check erratum #141
[ 7.414043] EDAC amd64: This node reports that Memory ECC is
currently disabled.
[ 7.414048] EDAC amd64: bit 0x40 in register F3x44 of the
MISC_CONTROL device (:00:18.3) should be enabled
[ 7.414051] EDAC amd64: WARNING: ECC is NOT currently enabled by
the BIOS. Module will NOT be loaded.
[ 7.414053] Either Enable ECC in the BIOS, or use the
'ecc_enable_override' parameter.
[ 7.414055] Might be a BIOS bug, if BIOS says ECC is enabled
[ 7.414056] Use of the override can cause unknown side effects.
[ 7.414073] amd64_edac: probe of :00:18.2 failed with error -22
[ 7.501404] usbcore: registered new interface driver snd-usb-audio
Re: em28xx driver - xc3028 tuner - readreg error
On Mon, Jan 18, 2010 at 10:01 AM, Valerio Bontempi valerio.bonte...@gmail.com wrote: Hi all, I am still having problem using v4l-dvb drivers with Terratec Cinergy T USB XS. As reported in first mail, I am using the last version of v4l-dvb drivers with few lines adjustment in order to make this driver to enable dvb for my dvb only device (this because official v4l-dvb driver actually doesn't support my device at all) I have cleaned my distro (openSuse 11.2 x86-64) about all the v4l modules provided by distro's repositories, and I compiled modified v4l-dvb source. So acutally I am using a cleaned version of v4l-dvb. But the [ 1483.314420] zl10353_read_register: readreg error (reg=127, ret==-19) [ 1483.315166] mt352_read_register: readreg error (reg=127, ret==-19) error isn't solved yet. Could it be related to the firmware I am using? No, this has nothing to do with firmware. It is probably an issue where the gpio configuration is wrong and the demod is being held in reset (hence it won't respond to i2c commands). The 0ccd:0043 is on my todo list of devices to work on (they sent me a sample board), although it's not the highest priority on my list given how old it is. Cheers, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Terratec Cinergy Hybrid XE (TM6010 Mediachip)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Davin, I have a question. How are loaded the base firmware into xc3028, in once or in a split ? It's importent for TM6010, the USB-Analyzer said that it load it in once and then send a quitting reqeuest. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJLVH6/AAoJEDX/lZlmjdJlA/0H/jkn4I3kELEWPeDDYJvv/+Z0 LsSLzmDJmQ0WgASjtJQ2QZvsDeuCsbzV9mTHGvI0dOGtOLqcBuMX58ZFTerZodrG b/KdwZa2OV0MWXc+5hf2+3wEC1icfMATKiwsT3gLdvP9En4MtUP8ImaXFWwW7ekL aH5TD666nGewj4+Ef5eVY0G+FypqzNcs4F04uY5ydBaVDh5XTONhXPaLz/R5JF0K ivKT4WL7n8A7bq8iAn6SoMJRV/RbEpGF40m4aApVDd+JdizFIH7xrTGQ4waQO6IN mplAcxIhq6bEHhwZRfbbnTNMTWUVPShqqqxC5Z0TxCiUR0RH6JdXagQtw/1/UX0= =Qqmr -END PGP SIGNATURE- -- 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: Terratec Cinergy Hybrid XE (TM6010 Mediachip)
On Mon, Jan 18, 2010 at 10:31 AM, Stefan Ringel stefan.rin...@arcor.de wrote: I have a question. How are loaded the base firmware into xc3028, in once or in a split ? It's importent for TM6010, the USB-Analyzer said that it load it in once and then send a quitting reqeuest. In most drivers, the xc3028 firmware gets broken down and sent in 64 byte chunks. The size of the chunks is controlled by the max_len field in the xc2028_ctrl structure. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Info
On Mon, Jan 18, 2010 at 11:03 AM, Adriano Gigante adrig...@yahoo.it wrote: Hi Devin, The 0ccd:0043 is on my todo list of devices to work on (they sent me a sample board), although it's not the highest priority on my list given how old it is. Did they sent you also a 0ccd:0072 card (Terratec Cinergy Hybrid T USB XS FM)? Adri Terratec sent me two boards: 0ccd:0072 and 0ccd:0043. I've actually been working with a user on the #linuxtv irc channel who is in the process of getting the 0ccd:0072 board to work (username Prahal). He's making great progress, but if he gets stuck I will find some cycles to work through whatever problem he finds. Cheers, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] Asking
On Mon, Jan 18, 2010 at 11:11 AM, Ismo Kuhmonen ismo...@gmail.com wrote: Hi Why my Pinnacle DVB-T 73€ USB not working? Are you running the current v4l-dvb tree? Support for the 73e was introduced into the v4l-dvb tree on September 2nd, so the changes probably haven't gotten into whatever distribution you are using yet. See http://linuxtv.org/repo for instructions on installing the latest v4l-dvb code. Cheers, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Info
Hi Devin, The 0ccd:0043 is on my todo list of devices to work on (they sent me a sample board), although it's not the highest priority on my list given how old it is. Did they sent you also a 0ccd:0072 card (Terratec Cinergy Hybrid T USB XS FM)? Adri -- 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: Info
On Mon, Jan 18, 2010 at 5:17 PM, Devin Heitmueller dheitmuel...@kernellabs.com wrote: On Mon, Jan 18, 2010 at 11:03 AM, Adriano Gigante adrig...@yahoo.it wrote: Hi Devin, The 0ccd:0043 is on my todo list of devices to work on (they sent me a sample board), although it's not the highest priority on my list given how old it is. Did they sent you also a 0ccd:0072 card (Terratec Cinergy Hybrid T USB XS FM)? Adri Terratec sent me two boards: 0ccd:0072 and 0ccd:0043. I've actually been working with a user on the #linuxtv irc channel who is in the process of getting the 0ccd:0072 board to work (username Prahal). He's making great progress, but if he gets stuck I will find some cycles to work through whatever problem he finds. Just fyi there's a hardware bug with the 0072/terratec hybrid xs fm (cx25843 - xc5000): http://img91.imageshack.us/i/0004qf8.png/ http://img104.imageshack.us/i/0009cp4.png/ nothing that can be fixed with the driver. 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: Info
Hello Markus, On Mon, Jan 18, 2010 at 11:29 AM, Markus Rechberger mrechber...@gmail.com wrote: Just fyi there's a hardware bug with the 0072/terratec hybrid xs fm (cx25843 - xc5000): http://img91.imageshack.us/i/0004qf8.png/ http://img104.imageshack.us/i/0009cp4.png/ nothing that can be fixed with the driver. Interesting. If it cannot be fixed with the driver, how does the Windows driver work then? Is this some sort of premature hardware failure that occurs (after which point it is irreversible)? Thanks for taking the time to point this out though, since I could totally imagine banging my head against the wall for quite a while once I saw this. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Do any drivers access the cx25840 module in an atomic context?
On Mon, 2010-01-18 at 11:16 +0100, Hans Verkuil wrote: On Monday 18 January 2010 06:19:28 Andy Walls wrote: Hi, I am going to add locking to the cx25840 module register reads and writes because I now have a case where a workqueue, a userpace, and/or the cx25840 firmware loading workqueue could contend for access to the CX2584x or equivalent device. I have identiifed the following drivers that actually use this module: cx231xx, pvrusb2, ivtv, cx23885 Now here's where I need help, since I don't understand the USB stuff too well and there's a lot of code to audit: Do any of these modules call the cx25840 routines with either: a. call the cx25840 module subdev functions with a spinlock held ? or b. call the cx25840 module subdev functions from an interrupt context: i.e. a hard irq or tasklet ? or c. bypass the normal cx25840_read/write calls with direct I2C access to the client address of 0x44 (0x88 1) ? Any definitive confirmation anyone can give on any of these drivers would be helpful and would save me some time. For ivtv: a. no b. no c. no Thanks. I thought so, but wasn't sure. BTW: b should never happen. i2c reads/writes are very slow and so it is a very bad idea to do that in interrupt context. Yeah. I just found that out. :P Since there is some low-level locking in the i2c stack as well I think it will probably not even work correctly if called from interrupt context. Well it can work, but I don't think what the i2c stack does in such cases is reliable. The i2c subsystem will call in_atomic() and in_interrupt() to find out if it can sleep or not (it turns out this is unreliable with PREEMPT disabled) and then calls mutex_trylock(). Obtaining a mutex with mutex_trylock() in an interrupt context isn't allowed AFAICT as it at breaks lockdep's ownership tracking of mutexes. If the i2c stack doesn't get the *adapter* mutex lock in the perceived atomic context, the i2c transfer fails with -EAGAIN. I'm hoping nothing accesses the cx25840 routines from an atomic context, but hope is usually not a good basis for a plan. ;) Note that AFAIK the i2c stack will already serialize i2c commands for you. So are you sure you need to serialize access on the higher levels as well? The i2c stack serializes the adapter accesses. The problem is that if there is contention for a particular client, and an i2c read transaction is broken up into 2 distinct transfers, like it is in the cx25840 module (i2c_master_send() of register address followed by a separate i2c_master_recv()), then the individiual i2c transfers in these transactions can get interleaved. I don't know why the cx25840 module did things this way, but the ability to do a cx25840 device register read in a single i2c_trasnfer() transaction with a repeated start is contingent on the underlying master implementation. I'll have to audit the underlying drivers to check if their master implementations support that. If they can, then I can combine the i2c_master_send() and i2c_master_recv() into a single i2c_transfer(). Otherwise a lock is actually needed in the cx25840_read() routines, even without the question of atomic context. Firmware load should be already serialized in the bridge driver. That leaves a possible call to cx25840_reset() which can trigger a fw load at any time, but I believe that can be removed as well since it is only used by the IR reset code which is obsolete. Yes, you're right. So, with the CX2388[578] devices, the only real contention I then need to deal with would be between a file operation (e.g. ioctl) indcued I2C transaction in a process context, contending with an IR interrupt induced I2C transaction running in a workqueue context. I really just don't want to break any existing drivers, while ensuring reliable operation of the device handled by the cx25840 module, and allowing maximum concurrency to the device. Right now the cx25840 module cannot ensure reliability. Ensuring no register manipulation requests are coming in from an atomic context makes solving that reliability problem easier, hence my question. I can always just reduce the problem scope by doing locking in the cx25840 module for only CX2388[578] devices. Then I would only need to audit the cx23885 driver. At least in ivtv I have never seen any issues with cx25840 and atomic contexts. Well, if one ever does call the cx25840_read() in an atomic context, if there is no contention for the I2C adapter at that time, the I2C transfers should succeed. If there is contention in this atomic context, the transaction silently fails, returning 0 as the value read from the register. I have learned this from recent experience. :P ivtv serializes all ioctl calls, and open/read/write/close calls from user space are unlikely to be concurrent with ioctls. I didn't check if ivtv manipulates the cx25840 from a workqueue context; I suspect it doesn't. Also if ivtv never
Re: Do any drivers access the cx25840 module in an atomic context?
On Monday 18 January 2010 17:52:43 Andy Walls wrote: On Mon, 2010-01-18 at 11:16 +0100, Hans Verkuil wrote: On Monday 18 January 2010 06:19:28 Andy Walls wrote: Hi, I am going to add locking to the cx25840 module register reads and writes because I now have a case where a workqueue, a userpace, and/or the cx25840 firmware loading workqueue could contend for access to the CX2584x or equivalent device. I have identiifed the following drivers that actually use this module: cx231xx, pvrusb2, ivtv, cx23885 Now here's where I need help, since I don't understand the USB stuff too well and there's a lot of code to audit: Do any of these modules call the cx25840 routines with either: a. call the cx25840 module subdev functions with a spinlock held ? or b. call the cx25840 module subdev functions from an interrupt context: i.e. a hard irq or tasklet ? or c. bypass the normal cx25840_read/write calls with direct I2C access to the client address of 0x44 (0x88 1) ? Any definitive confirmation anyone can give on any of these drivers would be helpful and would save me some time. For ivtv: a. no b. no c. no Thanks. I thought so, but wasn't sure. BTW: b should never happen. i2c reads/writes are very slow and so it is a very bad idea to do that in interrupt context. Yeah. I just found that out. :P Since there is some low-level locking in the i2c stack as well I think it will probably not even work correctly if called from interrupt context. Well it can work, but I don't think what the i2c stack does in such cases is reliable. The i2c subsystem will call in_atomic() and in_interrupt() to find out if it can sleep or not (it turns out this is unreliable with PREEMPT disabled) and then calls mutex_trylock(). Obtaining a mutex with mutex_trylock() in an interrupt context isn't allowed AFAICT as it at breaks lockdep's ownership tracking of mutexes. If the i2c stack doesn't get the *adapter* mutex lock in the perceived atomic context, the i2c transfer fails with -EAGAIN. I'm hoping nothing accesses the cx25840 routines from an atomic context, but hope is usually not a good basis for a plan. ;) Note that AFAIK the i2c stack will already serialize i2c commands for you. So are you sure you need to serialize access on the higher levels as well? The i2c stack serializes the adapter accesses. The problem is that if there is contention for a particular client, and an i2c read transaction is broken up into 2 distinct transfers, like it is in the cx25840 module (i2c_master_send() of register address followed by a separate i2c_master_recv()), then the individiual i2c transfers in these transactions can get interleaved. I don't know why the cx25840 module did things this way, but the ability to do a cx25840 device register read in a single i2c_trasnfer() transaction with a repeated start is contingent on the underlying master implementation. I'll have to audit the underlying drivers to check if their master implementations support that. If they can, then I can combine the i2c_master_send() and i2c_master_recv() into a single i2c_transfer(). Otherwise a lock is actually needed in the cx25840_read() routines, even without the question of atomic context. Ah, I hadn't realized that it was split up. If it can be merged into a single i2c_transfer, then that would certainly help things. Firmware load should be already serialized in the bridge driver. That leaves a possible call to cx25840_reset() which can trigger a fw load at any time, but I believe that can be removed as well since it is only used by the IR reset code which is obsolete. Yes, you're right. So, with the CX2388[578] devices, the only real contention I then need to deal with would be between a file operation (e.g. ioctl) indcued I2C transaction in a process context, contending with an IR interrupt induced I2C transaction running in a workqueue context. I really wonder if any locking is needed provided the read and write commands can be done atomically in the i2c layer. The only reason why that might be necessary is if there are multiple reads or writes that must be done in order without other reads/writes being mixed in. From memory the only place where that is needed is during the firmware load. Of course, this is from memory only, so I might well be wrong. I really just don't want to break any existing drivers, while ensuring reliable operation of the device handled by the cx25840 module, and allowing maximum concurrency to the device. Right now the cx25840 module cannot ensure reliability. Ensuring no register manipulation requests are coming in from an atomic context makes solving that reliability problem easier, hence my question. I can always just reduce the problem scope by doing locking in the cx25840 module for only CX2388[578] devices. Then I would only need to
Re: Info
On Mon, Jan 18, 2010 at 5:36 PM, Devin Heitmueller dheitmuel...@kernellabs.com wrote: Hello Markus, On Mon, Jan 18, 2010 at 11:29 AM, Markus Rechberger mrechber...@gmail.com wrote: Just fyi there's a hardware bug with the 0072/terratec hybrid xs fm (cx25843 - xc5000): http://img91.imageshack.us/i/0004qf8.png/ http://img104.imageshack.us/i/0009cp4.png/ nothing that can be fixed with the driver. Interesting. If it cannot be fixed with the driver, how does the Windows driver work then? Is this some sort of premature hardware failure that occurs (after which point it is irreversible)? conexant cx25843 - xceive xc5000 failure (as what I've heard conexant laid off people in that area years ago while xceive (see their driver changelog if you have access to it) tried to fix it with their firmware but didn't succeed), it also happens with windows. Those screenshots are taken from a videoclip it was of course a big problem for business customers (almost all of them happily switched away from it) This is the same retail hardware as everyone else uses out there. XS FM is not being sold anymore. I only know one company in Ireland still sticking with it, also in terms of videoquality I'd avoid that combination. Markus Thanks for taking the time to point this out though, since I could totally imagine banging my head against the wall for quite a while once I saw this. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Info
Il 01/18/2010 06:33 PM, Markus Rechberger ha scritto: On Mon, Jan 18, 2010 at 5:36 PM, Devin Heitmueller dheitmuel...@kernellabs.com wrote: Hello Markus, On Mon, Jan 18, 2010 at 11:29 AM, Markus Rechberger mrechber...@gmail.com wrote: Just fyi there's a hardware bug with the 0072/terratec hybrid xs fm (cx25843 - xc5000): http://img91.imageshack.us/i/0004qf8.png/ http://img104.imageshack.us/i/0009cp4.png/ nothing that can be fixed with the driver. Interesting. If it cannot be fixed with the driver, how does the Windows driver work then? Is this some sort of premature hardware failure that occurs (after which point it is irreversible)? conexant cx25843 - xceive xc5000 failure (as what I've heard conexant laid off people in that area years ago while xceive (see their driver changelog if you have access to it) tried to fix it with their firmware but didn't succeed), it also happens with windows. Those screenshots are taken from a videoclip it was of course a big problem for business customers (almost all of them happily switched away from it) This is the same retail hardware as everyone else uses out there. XS FM is not being sold anymore. I only know one company in Ireland still sticking with it, also in terms of videoquality I'd avoid that combination. Markus Thanks for taking the time to point this out though, since I could totally imagine banging my head against the wall for quite a while once I saw this. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Hi Markus, thanks for the info, i didn't know of this hardware problem, i have this usb stick and at the moment all works normally, now i know when it will be time to replace it :) -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Terratec Cinergy HT Express analog tv, fm and digital radio
Anyone any info on support state for this card? Thanks. -- 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: Info
On Mon, Jan 18, 2010 at 7:50 PM, fogna fogn...@gmail.com wrote: Il 01/18/2010 06:33 PM, Markus Rechberger ha scritto: On Mon, Jan 18, 2010 at 5:36 PM, Devin Heitmueller dheitmuel...@kernellabs.com wrote: Hello Markus, On Mon, Jan 18, 2010 at 11:29 AM, Markus Rechberger mrechber...@gmail.com wrote: Just fyi there's a hardware bug with the 0072/terratec hybrid xs fm (cx25843 - xc5000): http://img91.imageshack.us/i/0004qf8.png/ http://img104.imageshack.us/i/0009cp4.png/ nothing that can be fixed with the driver. Interesting. If it cannot be fixed with the driver, how does the Windows driver work then? Is this some sort of premature hardware failure that occurs (after which point it is irreversible)? conexant cx25843 - xceive xc5000 failure (as what I've heard conexant laid off people in that area years ago while xceive (see their driver changelog if you have access to it) tried to fix it with their firmware but didn't succeed), it also happens with windows. Those screenshots are taken from a videoclip it was of course a big problem for business customers (almost all of them happily switched away from it) This is the same retail hardware as everyone else uses out there. XS FM is not being sold anymore. I only know one company in Ireland still sticking with it, also in terms of videoquality I'd avoid that combination. Markus Thanks for taking the time to point this out though, since I could totally imagine banging my head against the wall for quite a while once I saw this. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Hi Markus, thanks for the info, i didn't know of this hardware problem, i have this usb stick and at the moment all works normally, now i know when it will be time to replace it :) it happens sporadically sometimes 1 time/5 minutes sometimes 1 time/10 minutes. I think in windows it sometimes drops frames it also happens there and can be seen with VLC maybe some codecs also compensate it a little bit. There's no generic rule about this the xc5000 overdrives the videodecoder (it's not empia related issue actually moreover conexant/xceive) 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: [PATCH] Compro S350 GPIO change
On Mon, 2010-01-18 at 09:52 +0200, Theunis Potgieter wrote: 2010/1/17 JD Louw jd.l...@mweb.co.za: Hi, This patch enables LNB power on newer revision d1 Compro S350 and S300 DVB-S cards. While I don't have these cards to test with I'm confident that this works. See http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/7471 and http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/14296 and new windows driver as reference. Signed-off-by: JD Louw jd.l...@mweb.co.za diff -r 59e746a1c5d1 linux/drivers/media/video/saa7134/saa7134-cards.c --- a/linux/drivers/media/video/saa7134/saa7134-cards.c Wed Dec 30 09:10:33 2009 -0200 +++ b/linux/drivers/media/video/saa7134/saa7134-cards.c Sun Jan 17 14:51:07 2010 +0200 @@ -7037,8 +7037,8 @@ int saa7134_board_init1(struct saa7134_d break; case SAA7134_BOARD_VIDEOMATE_S350: dev-has_remote = SAA7134_REMOTE_GPIO; - saa_andorl(SAA7134_GPIO_GPMODE0 2, 0x8000, 0x8000); - saa_andorl(SAA7134_GPIO_GPSTATUS0 2, 0x8000, 0x8000); + saa_andorl(SAA7134_GPIO_GPMODE0 2, 0xC000, 0xC000); + saa_andorl(SAA7134_GPIO_GPSTATUS0 2, 0xC000, 0xC000); break; } return 0; -- Hi Jan, This does not fix the problem where the card is suppose to suspend and the Voltage drops to 0V? Do you still require the windows registry reference for this part? Hi, No, the aim of the patch is just to get the basic driver support for all S300/S350 revisions. A windows regspy capture on a d1 revision card may still be useful in double checking the GPIO values, but I already know which GPIO controls LNB voltage: GPIO15 = modulator reset GPIO14 = LNB power -- 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 1/2, RFC] gspca: add input support for interrupt endpoints
Hans de Goede wrote:
Hi,
Thanks for your continued work on this. I'm afraid I found
one thing which needs fixing (can be fixed with
a separate patch after merging, but that is up to
Jean-Francois).
See my comments inline.
Thanks for the feedback, I hope the quality of the software increases
during this review phase.
On 01/17/2010 02:08 PM, Németh Márton wrote:
[snip]
+#ifdef CONFIG_INPUT
+#if LINUX_VERSION_CODE KERNEL_VERSION(2, 6, 19)
+static void int_irq(struct urb *urb, struct pt_regs *regs)
+#else
+static void int_irq(struct urb *urb)
+#endif
+{
+struct gspca_dev *gspca_dev = (struct gspca_dev *) urb-context;
+int ret;
+
+if (urb-status == 0) {
+if (gspca_dev-sd_desc-int_pkt_scan(gspca_dev,
+urb-transfer_buffer, urb-actual_length) 0) {
+PDEBUG(D_ERR, Unknown packet received);
+}
+
+ret = usb_submit_urb(urb, GFP_ATOMIC);
+if (ret 0)
+PDEBUG(D_ERR, Resubmit URB failed with error %i, ret);
+}
+}
+
If the status is not 0 you should print an error message, and
reset the status and still resubmit the urb, if you don't resubmit
on error, after one single usb glitch, the button will stop working.
I rewrote this function, see the following patch version.
[snip]
@@ -2137,6 +2308,11 @@
usb_set_intfdata(intf, gspca_dev);
PDEBUG(D_PROBE, %s created, video_device_node_name(gspca_dev-vdev));
+
+ret = gspca_input_connect(gspca_dev);
+if (0= ret)
+ret = gspca_input_create_urb(gspca_dev);
+
I don't like this reverse psychology if. Why not just write:
if (ret == 0) ?
I changed this line to if (ret == 0).
When I use a not-equal relation I try to put the smaller value on the left
hand side and the bigger one to the right hand side. In this case a range
which is expressed in mathematical notation like 10 a = 16 can be written
in C like (10 a) (a = 16).
But it is a different question what people like and what not, so I've changed
that line.
Otherwise it looks good.
Thanks.
I'm looking forward to receive more comments on the new version of this patch.
Regars,
Márton Németh
--
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 1/2, RFC] gspca: add input support for interrupt endpoints
From: Márton Németh nm...@freemail.hu
Add support functions for interrupt endpoint based input handling.
Signed-off-by: Márton Németh nm...@freemail.hu
---
diff -r 875c200a19dc linux/drivers/media/video/gspca/gspca.c
--- a/linux/drivers/media/video/gspca/gspca.c Sun Jan 17 07:58:51 2010 +0100
+++ b/linux/drivers/media/video/gspca/gspca.c Mon Jan 18 20:43:55 2010 +0100
@@ -3,6 +3,9 @@
*
* Copyright (C) 2008-2009 Jean-Francois Moine (http://moinejf.free.fr)
*
+ * Camera button input handling by Márton Németh
+ * Copyright (C) 2009-2010 Márton Németh nm...@freemail.hu
+ *
* 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
@@ -41,6 +44,9 @@
#include gspca.h
+#include linux/input.h
+#include linux/usb/input.h
+
/* global values */
#define DEF_NURBS 3/* default number of URBs */
#if DEF_NURBS MAX_NURBS
@@ -112,6 +118,186 @@
.close = gspca_vm_close,
};
+/*
+ * Input and interrupt endpoint handling functions
+ */
+#ifdef CONFIG_INPUT
+#if LINUX_VERSION_CODE KERNEL_VERSION(2, 6, 19)
+static void int_irq(struct urb *urb, struct pt_regs *regs)
+#else
+static void int_irq(struct urb *urb)
+#endif
+{
+ struct gspca_dev *gspca_dev = (struct gspca_dev *) urb-context;
+ int ret;
+
+ ret = urb-status;
+ switch (ret) {
+ case 0:
+ if (gspca_dev-sd_desc-int_pkt_scan(gspca_dev,
+ urb-transfer_buffer, urb-actual_length) 0) {
+ PDEBUG(D_ERR, Unknown packet received);
+ }
+ break;
+
+ case -ENOENT:
+ case -ECONNRESET:
+ case -ENODEV:
+ case -ESHUTDOWN:
+ /* Stop is requested either by software or hardware is gone,
+* keep the ret value non-zero and don't resubmit later.
+*/
+ break;
+
+ default:
+ PDEBUG(D_ERR, URB error %i, resubmitting, urb-status);
+ urb-status = 0;
+ ret = 0;
+ }
+
+ if (ret == 0) {
+ ret = usb_submit_urb(urb, GFP_ATOMIC);
+ if (ret 0)
+ PDEBUG(D_ERR, Resubmit URB failed with error %i, ret);
+ }
+}
+
+static int gspca_input_connect(struct gspca_dev *dev)
+{
+ struct input_dev *input_dev;
+ int err = 0;
+
+ dev-input_dev = NULL;
+ if (dev-sd_desc-int_pkt_scan) {
+ input_dev = input_allocate_device();
+ if (!input_dev)
+ return -ENOMEM;
+
+ usb_make_path(dev-dev, dev-phys, sizeof(dev-phys));
+ strlcat(dev-phys, /input0, sizeof(dev-phys));
+
+ input_dev-name = dev-sd_desc-name;
+ input_dev-phys = dev-phys;
+
+ usb_to_input_id(dev-dev, input_dev-id);
+
+ input_dev-evbit[0] = BIT_MASK(EV_KEY);
+ input_dev-keybit[BIT_WORD(KEY_CAMERA)] = BIT_MASK(KEY_CAMERA);
+ input_dev-dev.parent = dev-dev-dev;
+
+ err = input_register_device(input_dev);
+ if (err) {
+ PDEBUG(D_ERR, Input device registration failed
+ with error %i, err);
+ input_dev-dev.parent = NULL;
+ input_free_device(input_dev);
+ } else {
+ dev-input_dev = input_dev;
+ }
+ } else
+ err = -EINVAL;
+
+ return err;
+}
+
+static int alloc_and_submit_int_urb(struct gspca_dev *gspca_dev,
+ struct usb_endpoint_descriptor *ep)
+{
+ unsigned int buffer_len;
+ int interval;
+ struct urb *urb;
+ struct usb_device *dev;
+ void *buffer = NULL;
+ int ret = -EINVAL;
+
+ buffer_len = ep-wMaxPacketSize;
+ interval = ep-bInterval;
+ PDEBUG(D_PROBE, found int in endpoint: 0x%x,
+ buffer_len=%u, interval=%u,
+ ep-bEndpointAddress, buffer_len, interval);
+
+ dev = gspca_dev-dev;
+
+ urb = usb_alloc_urb(0, GFP_KERNEL);
+ if (!urb) {
+ ret = -ENOMEM;
+ goto error;
+ }
+
+ buffer = usb_buffer_alloc(dev, ep-wMaxPacketSize,
+ GFP_KERNEL, urb-transfer_dma);
+ if (!buffer) {
+ ret = -ENOMEM;
+ goto error_buffer;
+ }
+ usb_fill_int_urb(urb, dev,
+ usb_rcvintpipe(dev, ep-bEndpointAddress),
+ buffer, buffer_len,
+ int_irq, (void *)gspca_dev, interval);
+ gspca_dev-int_urb = urb;
+ ret = usb_submit_urb(urb, GFP_KERNEL);
+ if (ret 0) {
+ PDEBUG(D_ERR, submit URB failed with error %i, ret);
+ goto error_submit;
+ }
+ return ret;
+
+error_submit:
Re: Do any drivers access the cx25840 module in an atomic context?
On Mon, 2010-01-18 at 14:18 -0600, Mike Isely wrote: On Mon, 18 Jan 2010, Andy Walls wrote: Any definitive confirmation anyone can give on any of these drivers would be helpful and would save me some time. Mike, Great! Thank you for the answers. If you would indulge one more (compound) question: Looking at the I2C master implementation in pvrusb2, it looks like it would be OK for me to combine the i2c_master_write() and i2c_master_read() in cx25840_read() into a single 2 msg i2c_transfer() without the pvrusb2 driver having a problem. a. Is that correct? b. Is there a limit on the combined payload, such that a the cx25840_read4() would not work as a combined i2c_transfer() ? Regards, Andy -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Need testers: cx23885 IR Rx for TeVii S470 and HVR-1250
On 18 января 2010 07:36:52 Andy Walls wrote: On Sat, 2010-01-16 at 20:26 -0500, Andy Walls wrote: On Sat, 2010-01-16 at 23:56 +0200, Igor M. Liplianin wrote: On 16 января 2010 21:55:52 Andy Walls wrote: I have checked in more changes to http://linuxtv.org/hg/~awalls/cx23885-ir2 Please test again using these module parameters: modprobe cx25840 ir_debug=2 debug=2 modprobe cx23885 ir_input_debug=2 irq_debug=7 debug=7 I have removed the spurious interrupt handling code - it was bogus. The real problems are: 1. performing AV Core i2c transactions from an IRQ context is bad 2. the cx25840 module needs locking to prevent i2c transaction contention during the AV Core register reads and writes. I have implemented and checked in a change for #1. Now the AV_CORE interrupt gets disabled and a work handler is scheduled to deal with the IR controller on the AV core. When the work handler is done, it will re-enable the AV_CORE interrupt. I have not implmented a change for #2 yet. I have not added locking to protect cx25840_read() and cx25840_write() functions. This will take time to get right. You may test these latest changes if you want, but I won't be surprised if things don't work on occasion. It is very same behaviour here. A lot of interrupts without purpose. I have tested IR loopback with my HVR-1250 and things are fine for me, but I have no video interrupts coming in either. I wonder what is the difference. Regards, Andy OK. I think I finally have guessed what is going on: 1. The cx23885_irq_handler is called for the AV_CORE when something else in the cx23885 or cx25840 module is accessing that I2C bus. 2. The I2C bus adapter mutex in the i2c_subsystem stays locked so the cx23885_irq_handler() and cx25840_irq_handler() cannot read the AV core registers since the I2C subsystem returns -EINVAL and 0 for the data. 3. The interrupt handler keeps getting called because it never clears the interrupt condition in the AV Core. I think I have to do some work in the cx25840 module and the cx23885 module to handle locking of the AV Core I2C client and I2C bus 3. BR Igor -- 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: Do any drivers access the cx25840 module in an atomic context?
On Mon, 18 Jan 2010, Andy Walls wrote: On Mon, 2010-01-18 at 14:18 -0600, Mike Isely wrote: On Mon, 18 Jan 2010, Andy Walls wrote: Any definitive confirmation anyone can give on any of these drivers would be helpful and would save me some time. Mike, Great! Thank you for the answers. You're welcome. If you would indulge one more (compound) question: Looking at the I2C master implementation in pvrusb2, it looks like it would be OK for me to combine the i2c_master_write() and i2c_master_read() in cx25840_read() into a single 2 msg i2c_transfer() without the pvrusb2 driver having a problem. a. Is that correct? Yes, that is correct. b. Is there a limit on the combined payload, such that a the cx25840_read4() would not work as a combined i2c_transfer() ? There is an overall limit on the size of the I2C transfer. This is due to the underlying firmware on pvrusb2-support devices. Essentially the entire outgoing transfer plus a few bytes of overhead has to fit inside a single 64 byte URB. This also limits the atomic read size to roughly 64 bytes as well (the URB size on the returned data). You should be able to reliably write up to 48 bytes at a time, perhaps even a little more. This issue caused a problem for the cx25840 module a few years back when it used to do firmware downloads with large (e.g. 1024 byte or larger) single I2C transfers. Hans told me then it was that large because it allowed the ivtv driver to run more efficiently, but we cut it back to 48 bytes since it triggered problems with I2C adapters (e.g. pvrusb2) which could not handle such larger transfers at all. The pvrusb2 driver's I2C adapter is really just a proxy for the I2C implementation in the device at the far end of the USB cable. So it works at a higher level than one might normally expect - it operates at the transfer level, no bit-banging. The communications protocol required by the hardware limits the I2C transfers to be either a write of some size, or an atomic write followed by a read of various sizes. The pvrusb2 implementation looks at the incoming transfers and tries to map them as best it can over what the device protocol allows. Generally this means that if it is possible it will do the right thing. In the specific case you mentioned above, the result should in fact be exactly what you need. (I'm saying that without having looked at that area of code for quite a while, but it's what I remember being in my head when I did that part..) -Mike -- Mike Isely isely @ isely (dot) net PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: How to use saa7134 gpio via gpio-sysfs?
Hi, Am Montag, den 18.01.2010, 09:13 -0500 schrieb William Tate: Gentlemen, I may be able to assist here. Specifically what information/photographs are you looking for? Regards, William Tate RTD Embedded Technologies, Inc. Gordon, please explain, why you would like to have access to some of the saa713x gpios on that device from userspace. Unknown to me previously, it seems RTD already provides software for their customers to use the digital I/Os, but restricted to owners of such devices. For an example of how to use VFG73xx digital I/O, please see the Software Product SWP-700010065 “Linux Software (VFG73xx)” available from the RTD web site William, is there a desire to have such gpio access from userspace on your side? Trent kindly outlined some details. Please give us some brief explanations in that case. Thanks for offering your help. Hermann -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media-ow...@vger.kernel.org] On Behalf Of hermann pitton Sent: Sunday, January 17, 2010 6:02 PM To: Trent Piepho Cc: Gordon Smith; linux-media@vger.kernel.org Subject: Re: How to use saa7134 gpio via gpio-sysfs? [snip] Damned, seems the opto-isolated I/Os might be in question. For the RTD stuff we don't have any high resolution photographs or anything else ... Gordon, we should wait for, if RTD and Philips/NXP do have a agreement on such. I doubt it, given how it came in. Else, you can of course still do what you ever want on that driver. Cheers, Hermann -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RE: How to use saa7134 gpio via gpio-sysfs?
Hello, Am Montag, den 18.01.2010, 18:11 -0500 schrieb Will Tate: I'm not sure why access in userspace would be required. I checked the schematic today and all the GPIO pins are used to communicate with the SAA6752HS on board for compression. We do not bring the GPIO off the board anywhere. thank you very much. I was still expecting that and did not get Gordon's point, but must admit to have been totally unaware about the DI/O features. RTD did all the hardware implementations themselves. Very nice job that time. Gordon and I have spoken previously about the RTD software for digital I/O breaking with the migration of pcf8574 driver to the pcf857x. So, perhaps he intended to use GPIO until I can fix the digital I/O software. Ah, good to know. BTW, we had the mpeg encoder broken unnoticed for some kernels, but due to fixes by Dmitri Belimov and extensions by Hans Verkuil, we are much better on it these days. Enjoy. Always let us know, if we can do anything or at least make it public for those interested to work on it. Thanks, Hermann On Jan 18, 2010 5:43 PM, hermann pitton hermann-pit...@arcor.de wrote: Hi, Am Montag, den 18.01.2010, 09:13 -0500 schrieb William Tate: Gentlemen, I may be able to assist here. Specifically what information/photographs are you l... Gordon, please explain, why you would like to have access to some of the saa713x gpios on that device from userspace. Unknown to me previously, it seems RTD already provides software for their customers to use the digital I/Os, but restricted to owners of such devices. For an example of how to use VFG73xx digital I/O, please see the Software Product SWP-700010065 “Linux Software (VFG73xx)” available from the RTD web site William, is there a desire to have such gpio access from userspace on your side? Trent kindly outlined some details. Please give us some brief explanations in that case. Thanks for offering your help. Hermann -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL] http://kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-3
Hello Mauro, Please PULL from http://kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-3 for the following: cx18-alsa: Fix the rates definition and move some buffer freeing code. cx18: address possible passing of NULL to snd_card_free cx18-alsa: codingstyle cleanup cx18-alsa: codingstyle cleanup cx18: codingstyle fixes cx18-alsa: codingstyle fixes cx18-alsa: fix codingstyle issue cx18-alsa: fix memory leak in error condition cx18-alsa: remove a couple of warnings cx18-alsa: name alsa device after the actual card cx18: cleanup cx18-alsa debug logging cx18: rework cx18-alsa module loading to support automatic loading cx18-alsa: remove unneeded debug line cx18: export more symbols required by cx18-alsa cx18: add cx18-alsa module to Makefile cx18: overhaul ALSA PCM device handling so it works cx18: export a couple of symbols so they can be shared with cx18-alsa cx18: make it so cx18-alsa-main.c compiles cx18: rename cx18-alsa.c cx18-alsa: Add non-working cx18-alsa-pcm.[ch] files to avoid data loss cx18-alsa: Initial non-working cx18-alsa files This tree is the same as hvr-1600-alsa-2 except I rebased it off of the v4l-dvb tip, fixing the merge conflict with Andy's cx18-stream changes. Cheers, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Need testers: cx23885 IR Rx for TeVii S470 and HVR-1250
On Tue, 2010-01-19 at 00:25 +0200, Igor M. Liplianin wrote:
On 18 января 2010 07:36:52 Andy Walls wrote:
On Sat, 2010-01-16 at 20:26 -0500, Andy Walls wrote:
On Sat, 2010-01-16 at 23:56 +0200, Igor M. Liplianin wrote:
On 16 января 2010 21:55:52 Andy Walls wrote:
I have checked in more changes to
http://linuxtv.org/hg/~awalls/cx23885-ir2
Please test again using these module parameters:
modprobe cx25840 ir_debug=2 debug=2
modprobe cx23885 ir_input_debug=2 irq_debug=7 debug=7
I have removed the spurious interrupt handling code - it was bogus. The
real problems are:
1. performing AV Core i2c transactions from an IRQ context is bad
2. the cx25840 module needs locking to prevent i2c transaction
contention during the AV Core register reads and writes.
I have implemented and checked in a change for #1. Now the AV_CORE
interrupt gets disabled and a work handler is scheduled to deal with the
IR controller on the AV core. When the work handler is done, it will
re-enable the AV_CORE interrupt.
I have not implmented a change for #2 yet. I have not added locking to
protect cx25840_read() and cx25840_write() functions. This will take
time to get right.
I have now fixed the cx25840 module.
I also added a log function for v4l2-ctl -d /dev/video0 --log-status
to log the status of the IR controller.
You may test these latest changes if you want, but I won't be surprised
if things don't work on occasion.
It is very same behaviour here. A lot of interrupts without purpose.
:(
I have tested IR loopback with my HVR-1250 and things are fine for me,
but I have no video interrupts coming in either.
I wonder what is the difference.
a. I set up the IR transmit pin for the HVR-1250 but not the S470 in
cx23885-cards.c:cx23885_ir_init()
b. I set the transmitter invert_level for the Tx pin (a no-op for the
cx23885 IR controller) at the bottom of
cx23885-input.c:cx23885_input_ir_start() for the HVR-1250, but not the
S470.
c. For testing, I add an analog device video node to the HVR1250 for a
debug and test:
diff -r 9128ef95c5a7 -r 1ce2344226c1
linux/drivers/media/video/cx23885/cx23885-cards.c
--- a/linux/drivers/media/video/cx23885/cx23885-cards.c Sat Jan 09 13:58:18
2010 -0500
+++ b/linux/drivers/media/video/cx23885/cx23885-cards.c Sat Jan 09 14:31:30
2010 -0500
@@ -104,6 +104,8 @@
},
[CX23885_BOARD_HAUPPAUGE_HVR1250] = {
.name = Hauppauge WinTV-HVR1250,
+ .tuner_type = TUNER_ABSENT,
+ .porta = CX23885_ANALOG_VIDEO,
.portc = CX23885_MPEG_DVB,
.input = {{
.type = CX23885_VMUX_TELEVISION,
d. The script of commands I use for testing the HVR-1250 IR Rx with the
IR Tx in hardware loopback is:
#make unload; make unload
#make install
#modprobe cx25840 ir_debug=2 debug=2
#modprobe cx23885 ir_input_debug=2 irq_debug=7 debug=7
#v4l2-ctl -d /dev/video0 --log-status
# Get pin ctrl setting
v4l2-dbg -d /dev/video0 -c 0x44 -g 0x123
# disable tx fifo
v4l2-dbg -d /dev/video0 -c 0x44 -s 0x200 0x4c
# disable tx fifo svc req
v4l2-dbg -d /dev/video0 -c 0x44 -s 0x214 0x20
# disable tx, enable loopback
v4l2-dbg -d /dev/video0 -c 0x44 -s 0x201 0x21
#v4l2-ctl -d /dev/video0 --log-status
# set tx clk div
v4l2-dbg -d /dev/video0 -c 0x44 -s 0x204 1 0
#enable tx fifo
v4l2-dbg -d /dev/video0 -c 0x44 -s 0x200 0xcc
# store test pulse data
v4l2-dbg -d /dev/video0 -c 0x44 -s 0x23c 0xff 0x7f 0x1 0x0
v4l2-dbg -d /dev/video0 -c 0x44 -s 0x23c 0xff 0x5f 0x0 0x0
v4l2-dbg -d /dev/video0 -c 0x44 -s 0x23c 0xff 0x7f 0x1 0x0
v4l2-dbg -d /dev/video0 -c 0x44 -s 0x23c 0xff 0x5f 0x0 0x0
v4l2-dbg -d /dev/video0 -c 0x44 -s 0x23c 0xff 0x7f 0x1 0x0
v4l2-dbg -d /dev/video0 -c 0x44 -s 0x23c 0xff 0x5f 0x0 0x0
v4l2-dbg -d /dev/video0 -c 0x44 -s 0x23c 0xff 0x7f 0x1 0x0
v4l2-dbg -d /dev/video0 -c 0x44 -s 0x23c 0xff 0x5f 0x0 0x0
#v4l2-ctl -d /dev/video0 --log-status
#enable tx
v4l2-dbg -d /dev/video0 -c 0x44 -s 0x201 0x23
#v4l2-ctl -d /dev/video0 --log-status
e. My HVR-1250 doesn't have actual external IR Rx hardware, so I can
only test with loopback.
If my latest changes don't work, I'll probably have to order a CX23885
card with the hardware for actual IR Rx. Maybe I'll get a TeVii S470
and buy a satellite dish. ;)
Thanks again for all your test efforts.
Regards,
Andy
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL] http://kernellabs.com/hg/~dheitmueller/xc3028-regression
Hello Mauro, Please PULL from http://kernellabs.com/hg/~dheitmueller/xc3028-regression for the following: xc3028: fix regression in firmware loading time This is a fix for a regression you introduced into the tuner-xc2028 driver in rev 12824. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] git tree repositories
On Tuesday 19 January 2010 06:34:18 Mauro Carvalho Chehab wrote: Hi, Today, a step to the future was given, in order to help developers to better do their work: the addition of -git support at linuxtv.org server. This is one idea that is being recurrent along the last years: to start using -git as our primary resource for managing the patches at the development[1]. At the beginning, the usage CVS for of a SCM (Source Code Management) were choosen on V4L/DVB. Both of the original V4L and DVB trees were developed with the help of cvs. On that time, upstream Linux kernel used to have another tree (BitKeeper). In 2005, both V4L and DVB trees got merged into one cvs repository, and we've discussed about what would be the better SCM solution. We've discussed more about using svn, hg and git. On that time, both hg and git were new technologies, based on the concept of a distributed SCM, where you don't need to go to the server every time you're doing a command at the SCM. Yet, Mercurial were more stable and used, while -git were giving his first steps[2], being used almost only by the Linux Kernel, and several distros didn't use to package it. Git objects were stored uncompressed, generating very large trees. Also, -git tools were complex to use, and some porcelain packages were needed, in order to be used by a normal user. So, the decision was made to use mercurial. However, as time goes by, -git got much more eyes than any other SCM, having all their weakness solved, and being developed really fast. Also, it got adopted by several other projects, due to its capability and its number of features. Technically speaking, -git is currently the most advanced distributed open-source SCM application I know. Yet, Mercurial has been doing a very good job maintaining the V4L/DVB trees, and, except for a few points, it does the job. However, the entire Linux Kernel development happens around -git. Even the ones that were adopting other tools (like -alsa, that used to have also Mercurial repositories) migrated to -git. Despite all technical advantages, the rationale for the migration is quite simple: converting patches between different repositories and SCM tools cause development and merge delays, may cause patch mangling and eats lot of the time for people that are part of the process. Also, every time a patch needs to touch on files outside the incomplete tree used at the subsystem, an workaround need to be done, in order to avoid troubles and to be able to send the patch upstream. So, it is simpler to just use -git. Due to all the above reasons, I took some time to add -git support at linuxtv servers. Both http and git methods to retrieve trees were enabled. The new trees will be available at: http://linuxtv.org/git/ The merge tree, where all submitted patches will be merged, before sending upstream is: http://linuxtv.org/git?p=v4l-dvb.git;a=summary This tree is basically a clone of Linus tree, so it runs the latest development kernel. It is also (almost) in sync with our -hg tree (needing just a few adjustments). The above tree will never be rebased, so it should be safe to use it for development. I'll basically merge there all patches I receive. It is OK to submit patches against -hg, since I can still run my old conversion stripts to convert them to -git. However, as the conversion script is not fast (it takes between 15-30 secs to convert a single patch to -git, since it needs to re-generate the entire tree with v4l/scripts/gentree.pl, for ever patch), I kindly ask you to prefer submit me patches directly to -git. With respect to the -hg tree with the out-of-tree building system, We really want to keep having a way to allow running the drivers with kernels other than the latest -rc one, for both development and testing. As you all know, the number of drivers and the average number of merges per day is being increasing, among with more complexity on some drivers that also touches arch and other files outside drivers/media tree. Due to that, lots of my current time is devoted to keep -hg and -git in sync, distracting me from my develoment and maintanership tasks to do it. So, I simply don't have more time to keep maintaining both -hg and -git. Due to that, I'm delegating the task of keeping -hg in sync with upstream and backporting patches to run on older kernels to another person: Douglas has offered his help to keep the tree synchronized with the -git tree, and to add backport support. He already started doing that, fixing some incompatibility troubles between some drivers and older kernels. Mauro, I just wanted to thank you for doing all the hard work in moving to git! And a big 'thank you' to Douglas as well for taking over hg maintenance! I do have one proposal: parts of our hg tree are independent of git:
