Re: Driver crash on kernel 2.6.32.7. Interaction between cx8800 (DVB-S) and USB HVR Hauppauge 950q
On Tue, 2010-02-09 at 22:12 -0500, Devin Heitmueller wrote: On Tue, Feb 9, 2010 at 10:05 PM, Richard Lemieux rlem...@cooptel.qc.ca wrote: Andy, This is a great answer! Thanks very much. When I get into this situation again I will know what to look for. A possible reason why I got into this problem in the first place is that I tried many combinations of parameters with mplayer and azap in order to learn how to use the USB tuner in both the ATSC and the NTSC mode. I will look back in the terminal history to see if I can find anything. I think the key to figuring out the bug at this point is you finding a sequence where you can reliably reproduce the oops. If we have that, then I can start giving you some code to try which we can see if it addresses the problem. Also the verbose output of udevadm monitor (see man udevadm) would help us get a feeling for the timing relationships for the firmware requests. For example, I would start by giving you a fix which results in us not calling the firmware release if the request_firmware() call failed, but it wouldn't be much help if you could not definitively tell me if the problem is fixed. Definitely. Also, given the slow loading due to a chip I2C limitation, Richard, you may just want to increase your firmware loading timeout: $ su - root Password: # cat /sys/class/firmware/timeout 10 # echo 90 /sys/class/firmware/timeout # cat /sys/class/firmware/timeout 90 And see if the problem goes away. Again having some sort of steps to reliably reproduce the oops would be helpful in determining the efficacy of such a work around. Regards, Andy Devin -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 4/7] V4L: Events: Support event handling in do_ioctl
Add support for event handling to do_ioctl.
Signed-off-by: Sakari Ailus sakari.ai...@maxwell.research.nokia.com
---
drivers/media/video/Makefile |2 +-
drivers/media/video/v4l2-ioctl.c | 49 ++
include/media/v4l2-ioctl.h |5
3 files changed, 55 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index b888ad1..68253d6 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -11,7 +11,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 v4l2-subdev.o \
- v4l2-fh.o
+ v4l2-fh.o v4l2-event.o
# V4L2 core modules
diff --git a/drivers/media/video/v4l2-ioctl.c b/drivers/media/video/v4l2-ioctl.c
index bfc4696..e0b9401 100644
--- a/drivers/media/video/v4l2-ioctl.c
+++ b/drivers/media/video/v4l2-ioctl.c
@@ -25,6 +25,7 @@
#endif
#include media/v4l2-common.h
#include media/v4l2-ioctl.h
+#include media/v4l2-event.h
#include media/v4l2-chip-ident.h
#define dbgarg(cmd, fmt, arg...) \
@@ -1797,7 +1798,55 @@ static long __video_do_ioctl(struct file *file,
}
break;
}
+ case VIDIOC_DQEVENT:
+ {
+ struct v4l2_event *ev = arg;
+
+ if (!ops-vidioc_subscribe_event)
+ break;
+
+ ret = v4l2_event_dequeue(fh, ev);
+ if (ret 0) {
+ dbgarg(cmd, no pending events?);
+ break;
+ }
+ dbgarg(cmd,
+ count=%d, type=0x%8.8x, sequence=%d,
+ timestamp=%lu.%9.9lu ,
+ ev-count, ev-type, ev-sequence,
+ ev-timestamp.tv_sec, ev-timestamp.tv_nsec);
+ break;
+ }
+ case VIDIOC_SUBSCRIBE_EVENT:
+ {
+ struct v4l2_event_subscription *sub = arg;
+ if (!ops-vidioc_subscribe_event)
+ break;
+
+ ret = ops-vidioc_subscribe_event(fh, sub);
+ if (ret 0) {
+ dbgarg(cmd, failed, ret=%ld, ret);
+ break;
+ }
+ dbgarg(cmd, type=0x%8.8x, sub-type);
+ break;
+ }
+ case VIDIOC_UNSUBSCRIBE_EVENT:
+ {
+ struct v4l2_event_subscription *sub = arg;
+
+ if (!ops-vidioc_subscribe_event)
+ break;
+
+ ret = v4l2_event_unsubscribe(fh, sub);
+ if (ret 0) {
+ dbgarg(cmd, failed, ret=%ld, ret);
+ break;
+ }
+ dbgarg(cmd, type=0x%8.8x, sub-type);
+ break;
+ }
default:
{
if (!ops-vidioc_default)
diff --git a/include/media/v4l2-ioctl.h b/include/media/v4l2-ioctl.h
index 7a4529d..ed3fff5 100644
--- a/include/media/v4l2-ioctl.h
+++ b/include/media/v4l2-ioctl.h
@@ -21,6 +21,8 @@
#include linux/videodev2.h
#endif
+struct v4l2_fh;
+
struct v4l2_ioctl_ops {
/* ioctl callbacks */
@@ -239,6 +241,9 @@ struct v4l2_ioctl_ops {
int (*vidioc_enum_frameintervals) (struct file *file, void *fh,
struct v4l2_frmivalenum *fival);
+ int (*vidioc_subscribe_event) (struct v4l2_fh *fh,
+ struct v4l2_event_subscription *sub);
+
/* For other private ioctls */
long (*vidioc_default) (struct file *file, void *fh,
int cmd, void *arg);
--
1.5.6.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 1/7] V4L: File handles
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 |3 +-
drivers/media/video/v4l2-dev.c |2 +
drivers/media/video/v4l2-fh.c | 65
include/media/v4l2-dev.h |6
include/media/v4l2-fh.h| 47 +
5 files changed, 122 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 6e75647..b888ad1 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-subdev.o
+videodev-objs := v4l2-dev.o v4l2-ioctl.o v4l2-device.o v4l2-subdev.o \
+ v4l2-fh.o
# V4L2 core modules
diff --git a/drivers/media/video/v4l2-dev.c b/drivers/media/video/v4l2-dev.c
index 13a899d..c24c832 100644
--- a/drivers/media/video/v4l2-dev.c
+++ b/drivers/media/video/v4l2-dev.c
@@ -423,6 +423,8 @@ static int __video_register_device(struct video_device
*vdev, int type, int nr,
if (!vdev-release)
return -EINVAL;
+ v4l2_fhs_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..3c1cea2
--- /dev/null
+++ b/drivers/media/video/v4l2-fh.c
@@ -0,0 +1,65 @@
+/*
+ * 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
+
+void v4l2_fh_init(struct v4l2_fh *fh, struct video_device *vdev)
+{
+ fh-vdev = vdev;
+}
+EXPORT_SYMBOL_GPL(v4l2_fh_init);
+
+void v4l2_fh_add(struct v4l2_fh *fh)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(fh-vdev-fh_lock, flags);
+ list_add(fh-list, fh-vdev-fh_list);
+ spin_unlock_irqrestore(fh-vdev-fh_lock, flags);
+}
+EXPORT_SYMBOL_GPL(v4l2_fh_add);
+
+void v4l2_fh_del(struct v4l2_fh *fh)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(fh-vdev-fh_lock, flags);
+ list_del(fh-list);
+ spin_unlock_irqrestore(fh-vdev-fh_lock, flags);
+}
+EXPORT_SYMBOL_GPL(v4l2_fh_del);
+
+void v4l2_fh_exit(struct v4l2_fh *fh)
+{
+ BUG_ON(fh-vdev == NULL);
+ fh-vdev = NULL;
+}
+EXPORT_SYMBOL_GPL(v4l2_fh_exit);
+
+void v4l2_fhs_init(struct video_device *vdev)
+{
+ spin_lock_init(vdev-fh_lock);
+ INIT_LIST_HEAD(vdev-fh_list);
+}
diff --git a/include/media/v4l2-dev.h b/include/media/v4l2-dev.h
index 26d4e79..ee3a0c9 100644
--- a/include/media/v4l2-dev.h
+++ b/include/media/v4l2-dev.h
@@ -18,6 +18,8 @@
#include media/media-entity.h
+#include media/v4l2-fh.h
+
#define VIDEO_MAJOR81
#define VFL_TYPE_GRABBER 0
@@ -82,6 +84,10 @@ struct video_device
/* attribute to differentiate multiple indices on one physical device */
int index;
+ /* V4L2 file handles */
+ spinlock_t fh_lock; /* Lock for all v4l2_fhs */
+ struct list_headfh_list; /* List of struct v4l2_fh */
+
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..2e88031
--- /dev/null
+++ b/include/media/v4l2-fh.h
@@ -0,0 +1,47 @@
+/*
+ * 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.
+ *
+
[PATCH v4 6/7] V4L: Events: Sequence numbers
Add sequence numbers to events.
Signed-off-by: Sakari Ailus sakari.ai...@maxwell.research.nokia.com
---
drivers/media/video/v4l2-event.c | 16 +---
include/media/v4l2-event.h |1 +
2 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/drivers/media/video/v4l2-event.c b/drivers/media/video/v4l2-event.c
index bbdc149..0af0de5 100644
--- a/drivers/media/video/v4l2-event.c
+++ b/drivers/media/video/v4l2-event.c
@@ -95,6 +95,7 @@ int v4l2_event_init(struct v4l2_fh *fh, unsigned int n,
unsigned int max_alloc)
fh-events-navailable = 0;
fh-events-max_alloc = max_alloc;
+ fh-events-sequence = -1;
ret = v4l2_event_alloc(fh, n);
if (ret 0)
@@ -175,15 +176,24 @@ void v4l2_event_queue(struct video_device *vdev, struct
v4l2_event *ev)
list_for_each_entry(fh, vdev-fh_list, list) {
struct v4l2_events *events = fh-events;
struct v4l2_kevent *kev;
+ u32 sequence;
- /* Do we have any free events and are we subscribed? */
- if (list_empty(events-free) ||
- !__v4l2_event_subscribed(fh, ev-type))
+ /* Are we subscribed? */
+ if (!__v4l2_event_subscribed(fh, ev-type))
+ continue;
+
+ /* Increase event sequence number on fh. */
+ events-sequence++;
+ sequence = events-sequence;
+
+ /* Do we have any free events? */
+ if (list_empty(events-free))
continue;
/* Take one and fill it. */
kev = list_first_entry(events-free, struct v4l2_kevent, list);
kev-event = *ev;
+ kev-event.sequence = sequence;
list_move_tail(kev-list, events-available);
events-navailable++;
diff --git a/include/media/v4l2-event.h b/include/media/v4l2-event.h
index 671c8f7..5760597 100644
--- a/include/media/v4l2-event.h
+++ b/include/media/v4l2-event.h
@@ -50,6 +50,7 @@ struct v4l2_events {
unsigned intnavailable;
unsigned intmax_alloc; /* Never allocate more. */
struct list_headfree; /* Events ready for use */
+ u32 sequence;
};
int v4l2_event_alloc(struct v4l2_fh *fh, unsigned int n);
--
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
[PATCH v4 3/7] V4L: Events: Add backend
Add event handling backend to V4L2. The backend handles event subscription
and delivery to file handles. Event subscriptions are based on file handle.
Events may be delivered to all subscribed file handles on a device
independent of where they originate from.
Signed-off-by: Sakari Ailus sakari.ai...@maxwell.research.nokia.com
---
drivers/media/video/v4l2-event.c | 261 ++
drivers/media/video/v4l2-fh.c|4 +
include/media/v4l2-event.h | 64 +
include/media/v4l2-fh.h |2 +
4 files changed, 331 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/v4l2-event.c
create mode 100644 include/media/v4l2-event.h
diff --git a/drivers/media/video/v4l2-event.c b/drivers/media/video/v4l2-event.c
new file mode 100644
index 000..d13c1e9
--- /dev/null
+++ b/drivers/media/video/v4l2-event.c
@@ -0,0 +1,261 @@
+/*
+ * drivers/media/video/v4l2-event.c
+ *
+ * V4L2 events.
+ *
+ * Copyright (C) 2009 Nokia Corporation.
+ *
+ * Contact: Sakari Ailus sakari.ai...@maxwell.research.nokia.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ */
+
+#include media/v4l2-dev.h
+#include media/v4l2-event.h
+
+#include linux/sched.h
+
+/* In error case, return number of events *not* allocated. */
+int v4l2_event_alloc(struct v4l2_fh *fh, unsigned int n)
+{
+ struct v4l2_events *events = fh-events;
+ unsigned long flags;
+
+ for (; n 0; n--) {
+ struct v4l2_kevent *kev;
+
+ kev = kzalloc(sizeof(*kev), GFP_KERNEL);
+ if (kev == NULL)
+ return -ENOMEM;
+
+ spin_lock_irqsave(fh-vdev-fh_lock, flags);
+ list_add_tail(kev-list, events-free);
+ spin_unlock_irqrestore(fh-vdev-fh_lock, flags);
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(v4l2_event_alloc);
+
+#define list_kfree(list, type, member) \
+ while (!list_empty(list)) { \
+ type *hi; \
+ hi = list_first_entry(list, type, member); \
+ list_del(hi-member); \
+ kfree(hi); \
+ }
+
+void v4l2_event_exit(struct v4l2_fh *fh)
+{
+ struct v4l2_events *events = fh-events;
+
+ if (!events)
+ return;
+
+ list_kfree(events-free, struct v4l2_kevent, list);
+ list_kfree(events-available, struct v4l2_kevent, list);
+ list_kfree(events-subscribed, struct v4l2_subscribed_event, list);
+
+ kfree(events);
+ fh-events = NULL;
+}
+EXPORT_SYMBOL_GPL(v4l2_event_exit);
+
+int v4l2_event_init(struct v4l2_fh *fh, unsigned int n)
+{
+ int ret;
+
+ fh-events = kzalloc(sizeof(*fh-events), GFP_KERNEL);
+ if (fh-events == NULL)
+ return -ENOMEM;
+
+ init_waitqueue_head(fh-events-wait);
+
+ INIT_LIST_HEAD(fh-events-free);
+ INIT_LIST_HEAD(fh-events-available);
+ INIT_LIST_HEAD(fh-events-subscribed);
+
+ ret = v4l2_event_alloc(fh, n);
+ if (ret 0)
+ v4l2_event_exit(fh);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(v4l2_event_init);
+
+int v4l2_event_dequeue(struct v4l2_fh *fh, struct v4l2_event *event)
+{
+ struct v4l2_events *events = fh-events;
+ struct v4l2_kevent *kev;
+ unsigned long flags;
+
+ spin_lock_irqsave(fh-vdev-fh_lock, flags);
+
+ if (list_empty(events-available)) {
+ spin_unlock_irqrestore(fh-vdev-fh_lock, flags);
+ return -ENOENT;
+ }
+
+ kev = list_first_entry(events-available, struct v4l2_kevent, list);
+ list_move(kev-list, events-free);
+
+ kev-event.count = !list_empty(events-available);
+
+ *event = kev-event;
+
+ spin_unlock_irqrestore(fh-vdev-fh_lock, flags);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(v4l2_event_dequeue);
+
+static struct v4l2_subscribed_event *__v4l2_event_subscribed(
+ struct v4l2_fh *fh, u32 type)
+{
+ struct v4l2_events *events = fh-events;
+ struct v4l2_subscribed_event *sev;
+
+ list_for_each_entry(sev, events-subscribed, list) {
+ if (sev-type == type)
+ return sev;
+ }
+
+ return NULL;
+}
+
+struct v4l2_subscribed_event
[PATCH v4 2/7] V4L: Events: Add new ioctls for events
This patch adds a set of new ioctls to the V4L2 API. The ioctls conform to
V4L2 Events RFC version 2.3:
URL:http://www.spinics.net/lists/linux-media/msg12033.html
Signed-off-by: Sakari Ailus sakari.ai...@maxwell.research.nokia.com
---
drivers/media/video/v4l2-compat-ioctl32.c |3 +++
drivers/media/video/v4l2-ioctl.c |3 +++
include/linux/videodev2.h | 23 +++
3 files changed, 29 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/v4l2-compat-ioctl32.c
b/drivers/media/video/v4l2-compat-ioctl32.c
index 997975d..cba704c 100644
--- a/drivers/media/video/v4l2-compat-ioctl32.c
+++ b/drivers/media/video/v4l2-compat-ioctl32.c
@@ -1077,6 +1077,9 @@ long v4l2_compat_ioctl32(struct file *file, unsigned int
cmd, unsigned long arg)
case VIDIOC_DBG_G_REGISTER:
case VIDIOC_DBG_G_CHIP_IDENT:
case VIDIOC_S_HW_FREQ_SEEK:
+ case VIDIOC_DQEVENT:
+ case VIDIOC_SUBSCRIBE_EVENT:
+ case VIDIOC_UNSUBSCRIBE_EVENT:
ret = do_video_ioctl(file, cmd, arg);
break;
diff --git a/drivers/media/video/v4l2-ioctl.c b/drivers/media/video/v4l2-ioctl.c
index 30cc334..bfc4696 100644
--- a/drivers/media/video/v4l2-ioctl.c
+++ b/drivers/media/video/v4l2-ioctl.c
@@ -283,6 +283,9 @@ static const char *v4l2_ioctls[] = {
[_IOC_NR(VIDIOC_DBG_G_CHIP_IDENT)] = VIDIOC_DBG_G_CHIP_IDENT,
[_IOC_NR(VIDIOC_S_HW_FREQ_SEEK)] = VIDIOC_S_HW_FREQ_SEEK,
+ [_IOC_NR(VIDIOC_DQEVENT)] = VIDIOC_DQEVENT,
+ [_IOC_NR(VIDIOC_SUBSCRIBE_EVENT)] = VIDIOC_SUBSCRIBE_EVENT,
+ [_IOC_NR(VIDIOC_UNSUBSCRIBE_EVENT)] = VIDIOC_UNSUBSCRIBE_EVENT,
#endif
};
#define V4L2_IOCTLS ARRAY_SIZE(v4l2_ioctls)
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 54af357..a19ae89 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -1536,6 +1536,26 @@ struct v4l2_streamparm {
};
/*
+ * E V E N T S
+ */
+
+struct v4l2_event {
+ __u32 count;
+ __u32 type;
+ __u32 sequence;
+ struct timespec timestamp;
+ __u32 reserved[9];
+ __u8data[64];
+};
+
+struct v4l2_event_subscription {
+ __u32 type;
+ __u32 reserved[7];
+};
+
+#define V4L2_EVENT_PRIVATE_START 0x0800
+
+/*
* A D V A N C E D D E B U G G I N G
*
* NOTE: EXPERIMENTAL API, NEVER RELY ON THIS IN APPLICATIONS!
@@ -1651,6 +1671,9 @@ struct v4l2_dbg_chip_ident {
#endif
#define VIDIOC_S_HW_FREQ_SEEK _IOW('V', 82, struct v4l2_hw_freq_seek)
+#define VIDIOC_DQEVENT _IOR('V', 83, struct v4l2_event)
+#define VIDIOC_SUBSCRIBE_EVENT _IOW('V', 84, struct v4l2_event_subscription)
+#define VIDIOC_UNSUBSCRIBE_EVENT _IOW('V', 85, struct v4l2_event_subscription)
/* Reminder: when adding new ioctls please add support for them to
drivers/media/video/v4l2-compat-ioctl32.c as well! */
--
1.5.6.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 7/7] V4L: Events: Support all events
Add support for subscribing all events with a special id V4L2_EVENT_ALL. If
V4L2_EVENT_ALL is subscribed, no other events may be subscribed. Otherwise
V4L2_EVENT_ALL is considered just as any other event.
Signed-off-by: Sakari Ailus sakari.ai...@maxwell.research.nokia.com
---
drivers/media/video/v4l2-event.c | 13 -
include/linux/videodev2.h|1 +
2 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/v4l2-event.c b/drivers/media/video/v4l2-event.c
index 0af0de5..68b3cf4 100644
--- a/drivers/media/video/v4l2-event.c
+++ b/drivers/media/video/v4l2-event.c
@@ -139,6 +139,14 @@ static struct v4l2_subscribed_event
*__v4l2_event_subscribed(
struct v4l2_events *events = fh-events;
struct v4l2_subscribed_event *sev;
+ if (list_empty(events-subscribed))
+ return NULL;
+
+ sev = list_entry(events-subscribed.next,
+struct v4l2_subscribed_event, list);
+ if (sev-type == V4L2_EVENT_ALL)
+ return sev;
+
list_for_each_entry(sev, events-subscribed, list) {
if (sev-type == type)
return sev;
@@ -222,6 +230,8 @@ int v4l2_event_subscribe(struct v4l2_fh *fh,
/* Allow subscribing to valid events only. */
if (sub-type V4L2_EVENT_PRIVATE_START)
switch (sub-type) {
+ case V4L2_EVENT_ALL:
+ break;
default:
return -EINVAL;
}
@@ -262,7 +272,8 @@ int v4l2_event_unsubscribe(struct v4l2_fh *fh,
sev = __v4l2_event_subscribed(fh, sub-type);
- if (sev == NULL) {
+ if (sev == NULL ||
+ (sub-type != V4L2_EVENT_ALL sev-type == V4L2_EVENT_ALL)) {
spin_unlock_irqrestore(fh-vdev-fh_lock, flags);
return -EINVAL;
}
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index a19ae89..9ae9a1c 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -1553,6 +1553,7 @@ struct v4l2_event_subscription {
__u32 reserved[7];
};
+#define V4L2_EVENT_ALL 0
#define V4L2_EVENT_PRIVATE_START 0x0800
/*
--
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
[PATCH v4 5/7] V4L: Events: Count event queue length
Update the count field properly by 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 | 29 +
include/media/v4l2-event.h |6 +-
2 files changed, 22 insertions(+), 13 deletions(-)
diff --git a/drivers/media/video/v4l2-event.c b/drivers/media/video/v4l2-event.c
index d13c1e9..bbdc149 100644
--- a/drivers/media/video/v4l2-event.c
+++ b/drivers/media/video/v4l2-event.c
@@ -41,7 +41,13 @@ int v4l2_event_alloc(struct v4l2_fh *fh, unsigned int n)
return -ENOMEM;
spin_lock_irqsave(fh-vdev-fh_lock, flags);
+ if (events-max_alloc == 0) {
+ spin_unlock_irqrestore(fh-vdev-fh_lock, flags);
+ kfree(kev);
+ return -ENOMEM;
+ }
list_add_tail(kev-list, events-free);
+ events-max_alloc--;
spin_unlock_irqrestore(fh-vdev-fh_lock, flags);
}
@@ -73,7 +79,7 @@ void v4l2_event_exit(struct v4l2_fh *fh)
}
EXPORT_SYMBOL_GPL(v4l2_event_exit);
-int v4l2_event_init(struct v4l2_fh *fh, unsigned int n)
+int v4l2_event_init(struct v4l2_fh *fh, unsigned int n, unsigned int max_alloc)
{
int ret;
@@ -87,6 +93,9 @@ int v4l2_event_init(struct v4l2_fh *fh, unsigned int n)
INIT_LIST_HEAD(fh-events-available);
INIT_LIST_HEAD(fh-events-subscribed);
+ fh-events-navailable = 0;
+ fh-events-max_alloc = max_alloc;
+
ret = v4l2_event_alloc(fh, n);
if (ret 0)
v4l2_event_exit(fh);
@@ -108,11 +117,13 @@ int v4l2_event_dequeue(struct v4l2_fh *fh, struct
v4l2_event *event)
return -ENOENT;
}
+ WARN_ON(events-navailable == 0);
+
kev = list_first_entry(events-available, struct v4l2_kevent, list);
list_move(kev-list, events-free);
+ events-navailable--;
- kev-event.count = !list_empty(events-available);
-
+ kev-event.count = events-navailable;
*event = kev-event;
spin_unlock_irqrestore(fh-vdev-fh_lock, flags);
@@ -175,6 +186,8 @@ void v4l2_event_queue(struct video_device *vdev, struct
v4l2_event *ev)
kev-event = *ev;
list_move_tail(kev-list, events-available);
+ events-navailable++;
+
wake_up_all(events-wait);
}
@@ -184,15 +197,7 @@ EXPORT_SYMBOL_GPL(v4l2_event_queue);
int v4l2_event_pending(struct v4l2_fh *fh)
{
- struct v4l2_events *events = fh-events;
- unsigned long flags;
- int ret;
-
- spin_lock_irqsave(fh-vdev-fh_lock, flags);
- ret = !list_empty(events-available);
- spin_unlock_irqrestore(fh-vdev-fh_lock, flags);
-
- return ret;
+ return fh-events-navailable;
}
EXPORT_SYMBOL_GPL(v4l2_event_pending);
diff --git a/include/media/v4l2-event.h b/include/media/v4l2-event.h
index 580c9d4..671c8f7 100644
--- a/include/media/v4l2-event.h
+++ b/include/media/v4l2-event.h
@@ -28,6 +28,8 @@
#include linux/types.h
#include linux/videodev2.h
+#include asm/atomic.h
+
struct v4l2_fh;
struct video_device;
@@ -45,11 +47,13 @@ struct v4l2_events {
wait_queue_head_t wait;
struct list_headsubscribed; /* Subscribed events */
struct list_headavailable; /* Dequeueable event */
+ unsigned intnavailable;
+ unsigned intmax_alloc; /* Never allocate more. */
struct list_headfree; /* Events ready for use */
};
int v4l2_event_alloc(struct v4l2_fh *fh, unsigned int n);
-int v4l2_event_init(struct v4l2_fh *fh, unsigned int n);
+int v4l2_event_init(struct v4l2_fh *fh, unsigned int n, unsigned int
max_alloc);
void v4l2_event_exit(struct v4l2_fh *fh);
int v4l2_event_dequeue(struct v4l2_fh *fh, struct v4l2_event *event);
struct v4l2_subscribed_event *v4l2_event_subscribed(
--
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: Driver crash on kernel 2.6.32.7. Interaction between cx8800 (DVB-S) and USB HVR Hauppauge 950q
On Tue, 2010-02-09 at 22:12 -0500, Devin Heitmueller wrote:
On Tue, Feb 9, 2010 at 10:05 PM, Richard Lemieux rlem...@cooptel.qc.ca
wrote:
Andy,
This is a great answer! Thanks very much. When I get into this situation
again
I will know what to look for.
A possible reason why I got into this problem in the first place is that I
tried
many combinations of parameters with mplayer and azap in order to learn how
to use the USB tuner in both the ATSC and the NTSC mode. I will look back
in the terminal history to see if I can find anything.
I think the key to figuring out the bug at this point is you finding a
sequence where you can reliably reproduce the oops. If we have that,
then I can start giving you some code to try which we can see if it
addresses the problem.
For example, I would start by giving you a fix which results in us not
calling the firmware release if the request_firmware() call failed,
but it wouldn't be much help if you could not definitively tell me if
the problem is fixed.
For the oops analysis here:
http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/15954
I will also note that the file scope fw_lock mutex is rather
inconsistently used in
linux/drivers/base/fw_class.c:firmware_loading_store(). (I guess for
not wanting to consume the timeout interval with sleeping?)
The mutex protects case 1:, but all other cases appear to be only
protected by atomic status bit checks that can fall through to
fw_load_abort() which complete()'s the fw_priv-completion.
Also not that in the _request_firmware() this sequence is the only place
a once good fw_priv-fw pointer is set to NULL:
mutex_lock(fw_lock);
if (!fw_priv-fw-size || test_bit(FW_STATUS_ABORT, fw_priv-status)) {
retval = -ENOENT;
release_firmware(fw_priv-fw);
*firmware_p = NULL;
}
fw_priv-fw = NULL; --- The only place it is set to
NULL
mutex_unlock(fw_lock);
So if the timeout timer fires at nearly the same time as udev coming in
and say I'm done loading without holding the mutex, one can run into
the Ooops. Not only that, I think the above code can leak memory under
some circumstances when the if clause is not satisfied.
I think this really is a firmware_class.c issue. I think the just
right firmware loading timeouts and the particular computer system
responsiveness, make this Ooops possible. However, I'm amazed that a
single person has tripped it more than once.
Revising the locking in linux/drivers/base/firmware_class.c should fix
the problem.
I don't believe this comment in the code now:
/* fw_lock could be moved to 'struct firmware_priv' but since it is just
* guarding for corner cases a global lock should be OK */
static DEFINE_MUTEX(fw_lock);
struct firmware_priv {
char *fw_id;
...
And since f_priv is dynamically created and destroyed by
request_firmware() I see no harm in
1. moving the mutex into struct firmware_priv
2. just always just grabbing an almost never contended mutex
3. getting rid of the file scope fw_lock.
except grabbing a mutex() while the timeout timer is running during
loading, means one *could* sleep for a while consuming the timeout
interval.
Or am I out to lunch?
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: [PATCH 6/12] tm6000: tuner reset timeing optimation
Am 08.02.2010 12:23, schrieb Mauro Carvalho Chehab:
stefan.rin...@arcor.de wrote:
From: Stefan Ringel stefan.rin...@arcor.de
Signed-off-by: Stefan Ringel stefan.rin...@arcor.de
---
drivers/staging/tm6000/tm6000-cards.c | 11 +++
1 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/tm6000/tm6000-cards.c
b/drivers/staging/tm6000/tm6000-cards.c
index 1167b01..5cf5d58 100644
--- a/drivers/staging/tm6000/tm6000-cards.c
+++ b/drivers/staging/tm6000/tm6000-cards.c
@@ -271,11 +271,14 @@ static int tm6000_tuner_callback(void *ptr, int
component, int command, int arg)
switch (arg) {
case 0:
tm6000_set_reg (dev, REQ_03_SET_GET_MCU_PIN,
+dev-tuner_reset_gpio, 0x01);
+msleep(60);
+tm6000_set_reg (dev, REQ_03_SET_GET_MCU_PIN,
dev-tuner_reset_gpio, 0x00);
-msleep(130);
+msleep(75);
tm6000_set_reg (dev, REQ_03_SET_GET_MCU_PIN,
dev-tuner_reset_gpio, 0x01);
-msleep(130);
+msleep(60);
break;
case 1:
tm6000_set_reg (dev, REQ_04_EN_DISABLE_MCU_INT,
@@ -288,10 +291,10 @@ static int tm6000_tuner_callback(void *ptr, int
component, int command, int arg)
TM6000_GPIO_CLK, 0);
if (rc0)
return rc;
-msleep(100);
+msleep(10);
rc=tm6000_set_reg (dev, REQ_03_SET_GET_MCU_PIN,
TM6000_GPIO_CLK, 1);
-msleep(100);
+msleep(10);
break;
}
}
This sequence and the timeouts are board-specific. Please add a
switch(dev-model) and
test for your specific board, since your sequence will break for example
10moons, where
you really need a longer delay to work.
What for tuner modell have you, xc2028, xc3028 or xc3028L ? I have
xc3028L, And it can reset faster. I'm adding a switch(dev-modell).
--
Stefan Ringel stefan.rin...@arcor.de
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/12] tm6000: tuner reset timeing optimation
Stefan Ringel wrote:
Am 08.02.2010 12:23, schrieb Mauro Carvalho Chehab:
stefan.rin...@arcor.de wrote:
From: Stefan Ringel stefan.rin...@arcor.de
Signed-off-by: Stefan Ringel stefan.rin...@arcor.de
---
drivers/staging/tm6000/tm6000-cards.c | 11 +++
1 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/tm6000/tm6000-cards.c
b/drivers/staging/tm6000/tm6000-cards.c
index 1167b01..5cf5d58 100644
--- a/drivers/staging/tm6000/tm6000-cards.c
+++ b/drivers/staging/tm6000/tm6000-cards.c
@@ -271,11 +271,14 @@ static int tm6000_tuner_callback(void *ptr, int
component, int command, int arg)
switch (arg) {
case 0:
tm6000_set_reg (dev, REQ_03_SET_GET_MCU_PIN,
+ dev-tuner_reset_gpio, 0x01);
+ msleep(60);
+ tm6000_set_reg (dev, REQ_03_SET_GET_MCU_PIN,
dev-tuner_reset_gpio, 0x00);
- msleep(130);
+ msleep(75);
tm6000_set_reg (dev, REQ_03_SET_GET_MCU_PIN,
dev-tuner_reset_gpio, 0x01);
- msleep(130);
+ msleep(60);
break;
case 1:
tm6000_set_reg (dev, REQ_04_EN_DISABLE_MCU_INT,
@@ -288,10 +291,10 @@ static int tm6000_tuner_callback(void *ptr, int
component, int command, int arg)
TM6000_GPIO_CLK, 0);
if (rc0)
return rc;
- msleep(100);
+ msleep(10);
rc=tm6000_set_reg (dev, REQ_03_SET_GET_MCU_PIN,
TM6000_GPIO_CLK, 1);
- msleep(100);
+ msleep(10);
break;
}
}
This sequence and the timeouts are board-specific. Please add a
switch(dev-model) and
test for your specific board, since your sequence will break for example
10moons, where
you really need a longer delay to work.
What for tuner modell have you, xc2028, xc3028 or xc3028L ? I have
xc3028L, And it can reset faster. I'm adding a switch(dev-modell).
I have one device with each of the above, but the one with xc3028 stopped
working when
I tried to replace the tm6000revA by a tm6000revD.
The newest one has tm6010/xc3028L. I suspect that it supports a faster reset,
but I
don't remember the exact timings measured based on the m$ driver. the 10moons
has
a xc2028 and a tm5600, and it hangs if commands are sent too fast to the device.
--
Cheers,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] saa7134: Fix IR support of some ASUS TV-FM 7135 variants
W dniu 03.02.2010 00:32, hermann pitton pisze: Hi Jean, Mauro and all, Am Dienstag, den 02.02.2010, 08:54 +0100 schrieb Jean Delvare: Hi Hermann, On Tue, 02 Feb 2010 02:47:53 +0100, hermann pitton wrote: Hi Jean, Am Montag, den 01.02.2010, 10:56 +0100 schrieb Jean Delvare: Hi Hermann, On Mon, 01 Feb 2010 02:16:35 +0100, hermann pitton wrote: For now, I only faked a P7131 Dual with a broken IR receiver on a 2.6.29 with recent, you can see that gpio 0x4 doesn't go high, but your patch should enable the remote on that P7131 analog only. I'm not sure why you had to fake anything? What I'd like to know is simply if my first patch had any negative effect on other cards. because I simply don't have that Asus My Cinema analog only in question. To recap, you previously announced a patch, tested by Daro, claiming to get the remote up under auto detection for that device and I told you having some doubts on it. My first patch was not actually tested by Daro. What he tested was loading the driver with card=146. At first I thought it was equivalent, but since then I have realized it wasn't. That's the reason why the Tested-by: was turned into a mere Cc: on my second and third patches. Mauro prefers to have a fix for that single card in need for now. Since nobody else cares, For now, see above, I can confirm that your last patch for that single device should work to get IR up with auto detection in delay after we change the card such late with eeprom detection. The meaning of that byte in use here is unknown to me, we should avoid such as much we can! It can turn out to be only some pseudo service. If your call for testers on your previous attempt, really reaches some for some reason, I'm with you, but for now I have to keep the car operable within all such snow. That I understand. What I don't understand is: if you have a SAA7134-based card, why don't you test my second patch (the one moving the call to saa7134_input_init1 to saa7134_hwinit2) on it, without faking anything? This would be a first, useful data point. sorry, the snow fall did not stop and we will need trucks next day to get it out of town. No place left. I did not reread any single line of code until now, but told you that Roman has tested a equivalent patch on his P7131_ANALOG already and I can confirm that it also had no side effects on a FlyVideo3000 card=2. For now, I would at least need some time to see, if input_init can be decoupled from all other hardware init, what you seem to suggest, and looking closer to Mauro's concerns. Thought you are asking for some test with a i2c remote next to confirm your analysis there. No such card in any machine currently, but can be done. Cheers, Hermann Hi All, If some tests on my machine could be helpfull just let me know. Best regards Darek -- 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] saa7134: Fix IR support of some ASUS TV-FM 7135 variants
Hi Daro, On Wed, 10 Feb 2010 17:38:18 +0100, Daro wrote: If some tests on my machine could be helpfull just let me know. Definitely. If you could please test both patches I sent (first one on 2010-01-27, second one on 2010-01-30, both should be in your mailbox) and confirm that they both work for you (so you no longer need to pass card=146 to the driver), that would be great. Mauro doesn't seem to be willing to apply the first patch, but for future reference I would still be interested to know if it would work at least in your case. The second patch is what Mauro is likely to apply, so it would be good to make sure it fixes your problem before actually applying it. Thanks! -- Jean Delvare -- 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] saa7134: Fix IR support of some ASUS TV-FM 7135 variants
Hi Mauro, On Tue, 02 Feb 2010 17:09:05 -0200, Mauro Carvalho Chehab wrote: From: Jean Delvare kh...@linux-fr.org Subject: saa7134: Fix IR support of some ASUS TV-FM 7135 variants Some variants of the ASUS TV-FM 7135 are handled as the ASUSTeK P7131 Analog (card=146). However, by the time we find out, some card-specific initialization is missed. In particular, the fact that the IR is GPIO-based. Set it when we change the card type, and run saa7134_input_init1(). Signed-off-by: Jean Delvare kh...@linux-fr.org Cc: Daro ghost-ri...@aster.pl Cc: Roman Kellner muzu...@gmx.net --- linux/drivers/media/video/saa7134/saa7134-cards.c |5 + 1 file changed, 5 insertions(+) --- v4l-dvb.orig/linux/drivers/media/video/saa7134/saa7134-cards.c 2010-01-30 10:56:50.0 +0100 +++ v4l-dvb/linux/drivers/media/video/saa7134/saa7134-cards.c 2010-01-30 11:52:18.0 +0100 @@ -7299,6 +7299,11 @@ int saa7134_board_init2(struct saa7134_d printk(KERN_INFO %s: P7131 analog only, using entry of %s\n, dev-name, saa7134_boards[dev-board].name); + + /* IR init has already happened for other cards, so +* we have to catch up. */ + dev-has_remote = SAA7134_REMOTE_GPIO; + saa7134_input_init1(dev); } break; case SAA7134_BOARD_HAUPPAUGE_HVR1150: This version of your patch makes sense to me. This logic will only apply for board SAA7134_BOARD_ASUSTeK_P7131_ANALOG, so, provided that someone with this board test it, I'm OK with it. Had Roman or Daro already test it? Not yet, but Daro just volunteered to do so... let's give him/her some time to proceed. -- Jean Delvare -- 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 5/12] tm6000: update init table and sequence for tm6010
Am 08.02.2010 12:21, schrieb Mauro Carvalho Chehab: At the above, you're just trying to reproduce whatever the original driver does, instead of relying on the i2c drivers. At the Linux drivers, we don't just send random i2c sequences in the middle of the setup. Instead, we let each i2c driver to do the initialization they need to do. If you take a look on each call, for example: tm6000_read_write_usb (dev, 0x40, 0x10, 0xf332, 0x, buf, 2); The first value determines the USB direction: 0x40 is write; 0xc0 is read; The second value is the request. Both 0x0e (REQ_14) and 0x10 (REQ_16) are used for i2c. From the past experiences, REQ_16 works better when the size is 1, where REQ_14 works better for bigger sizes. The third value gives the first byte of a write message and the i2c address. The lower 8 bits is the i2c address. The above sequence is playing with several different i2c devices, at addresses 0x10, 0x32, 0xc0 and 0x1f. Most of the calls there are read (0xc0). I don't know any device that requires a read for it to work. I suspect that the above code is just probing to check what i2c devices are found at the board. The writes are to a device at address 0x32 (in i2c 8 bit notation - or 0x19 at i2c 7bit notation). I suspect that the probe sequence noticed something at the address 0x32 and is sending some init sequence for it. As this is not the tuner nor the demod, you don't need those setup for your device to work. Also, this address is not typical for eeprom. Without taking a look at the hardware, we can only guess what's there. My guess is that it is for some i2c-based remote controller chip. We don't need this for now. After having the rest working, we may need to return on it when patching ir-kbd.i2c. The i2c address 0x32 isn't ir, but I think it sets the power or so. Ir has vendor requests. see tm6000_regs.h . The i2c addresses 0x10 and 0xc0 cannot say what this is (check i2c address space or so). and the i2c address 0x1f is the read address from demodulator. -- Stefan Ringel stefan.rin...@arcor.de -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/12] tm6000: update init table and sequence for tm6010
Stefan Ringel wrote: Am 08.02.2010 12:21, schrieb Mauro Carvalho Chehab: At the above, you're just trying to reproduce whatever the original driver does, instead of relying on the i2c drivers. At the Linux drivers, we don't just send random i2c sequences in the middle of the setup. Instead, we let each i2c driver to do the initialization they need to do. If you take a look on each call, for example: tm6000_read_write_usb (dev, 0x40, 0x10, 0xf332, 0x, buf, 2); The first value determines the USB direction: 0x40 is write; 0xc0 is read; The second value is the request. Both 0x0e (REQ_14) and 0x10 (REQ_16) are used for i2c. From the past experiences, REQ_16 works better when the size is 1, where REQ_14 works better for bigger sizes. The third value gives the first byte of a write message and the i2c address. The lower 8 bits is the i2c address. The above sequence is playing with several different i2c devices, at addresses 0x10, 0x32, 0xc0 and 0x1f. Most of the calls there are read (0xc0). I don't know any device that requires a read for it to work. I suspect that the above code is just probing to check what i2c devices are found at the board. The writes are to a device at address 0x32 (in i2c 8 bit notation - or 0x19 at i2c 7bit notation). I suspect that the probe sequence noticed something at the address 0x32 and is sending some init sequence for it. As this is not the tuner nor the demod, you don't need those setup for your device to work. Also, this address is not typical for eeprom. Without taking a look at the hardware, we can only guess what's there. My guess is that it is for some i2c-based remote controller chip. We don't need this for now. After having the rest working, we may need to return on it when patching ir-kbd.i2c. The i2c address 0x32 isn't ir, but I think it sets the power or so. Ir has vendor requests. see tm6000_regs.h . The way IR works depend on vendor's decision. Even having some URB messages dedicated to IR, someone may use instead an i2c chip. If 0x32 is not IR, then maybe it might be an audio demod. The only way to know for sure is to open a device that answers to this address and see what chips are inside. The i2c addresses 0x10 and 0xc0 cannot say what this is (check i2c address space or so). and the i2c address 0x1f is the read address from demodulator. 0xc0 is for sure tuner. Allmost 100% of the tuners in the market (including xc3028) can use 0xc0. All it is needed to change is to send 5V or GND to certain pins at the tuner, chip in order to define what address will be used. Yet, all projects I've seen so far with xc3028 use 0xc2. 0x10 can be used by some AM/FM radio chips with RDS. Anyway, I'm almost sure that your board doesn't have any of those chips. If you're in doubt, then you'll need to open your device and look what chips are inside, seeking for datasheets or other info for the other i2c chips you might find. -- Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] linuxtv.org server move Wed, 10 Feb 2pm CET
On Mon, Feb 08, 2010 at 11:51:14PM +0100, Johannes Stezenbach wrote: the linuxtv.org server is going to be moved to a new location on Wednesday, around 2pm CET (UTC+1:00). As you might have noticed, that point in time came and went and nothing happened. Next try tomorrow, around the same time. Johannes -- 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] saa7134: Fix IR support of some ASUS TV-FM 7135 variants
Hi Mauro, Sorry for the late answer. I'm tracking so many things in parallel... On Tue, 02 Feb 2010 09:50:11 -0200, Mauro Carvalho Chehab wrote: The init1 code has 107 boards listed: SAA7134_BOARD_10MOONSTVMASTER3 SAA7134_BOARD_ADS_DUO_CARDBUS_PTV331 SAA7134_BOARD_ASUST SAA7134_BOARD_AVACSSMARTTV SAA7134_BOARD_AVERMEDIA_305 SAA7134_BOARD_AVERMEDIA_307 SAA7134_BOARD_AVERMEDIA_777 SAA7134_BOARD_AVERMEDIA_A169_B SAA7134_BOARD_AVERMEDIA_A16AR SAA7134_BOARD_AVERMEDIA_A16D SAA7134_BOARD_AVERMEDIA_A700_HYBRID SAA7134_BOARD_AVERMEDIA_A700_PRO SAA7134_BOARD_AVERMEDIA_CARDBUS SAA7134_BOARD_AVERMEDIA_CARDBUS_501 SAA7134_BOARD_AVERMEDIA_CARDBUS_506 SAA7134_BOARD_AVERMEDIA_GO_007_FM SAA7134_BOARD_AVERMEDIA_GO_007_FM_PLUS SAA7134_BOARD_AVERMEDIA_M102 SAA7134_BOARD_AVERMEDIA_M103 SAA7134_BOARD_AVERMEDIA_M115 SAA7134_BOARD_AVERMEDIA_M135A SAA7134_BOARD_AVERMEDIA_STUDIO_305 SAA7134_BOARD_AVERMEDIA_STUDIO_307 SAA7134_BOARD_AVERMEDIA_STUDIO_505 SAA7134_BOARD_AVERMEDIA_STUDIO_507 SAA7134_BOARD_BEHOLD_401 SAA7134_BOARD_BEHOLD_403 SAA7134_BOARD_BEHOLD_403FM SAA7134_BOARD_BEHOLD_405 SAA7134_BOARD_BEHOLD_405FM SAA7134_BOARD_BEHOLD_407 SAA7134_BOARD_BEHOLD_407FM SAA7134_BOARD_BEHOLD_409 SAA7134_BOARD_BEHOLD_409FM SAA7134_BOARD_BEHOLD_505FM SAA7134_BOARD_BEHOLD_505RDS_MK3 SAA7134_BOARD_BEHOLD_505RDS_MK5 SAA7134_BOARD_BEHOLD_507_9FM SAA7134_BOARD_BEHOLD_507RDS_MK3 SAA7134_BOARD_BEHOLD_507RDS_MK5 SAA7134_BOARD_BEHOLD_607FM_MK3 SAA7134_BOARD_BEHOLD_607FM_MK5 SAA7134_BOARD_BEHOLD_607RDS_MK3 SAA7134_BOARD_BEHOLD_607RDS_MK5 SAA7134_BOARD_BEHOLD_609FM_MK3 SAA7134_BOARD_BEHOLD_609FM_MK5 SAA7134_BOARD_BEHOLD_609RDS_MK3 SAA7134_BOARD_BEHOLD_609RDS_MK5 SAA7134_BOARD_BEHOLD_COLUMBUS_TVFM SAA7134_BOARD_BEHOLD_H6 SAA7134_BOARD_BEHOLD_M6 SAA7134_BOARD_BEHOLD_M63 SAA7134_BOARD_BEHOLD_M6_EXTRA SAA7134_BOARD_BEHOLD_X7 SAA7134_BOARD_CINERGY400 SAA7134_BOARD_CINERGY400_CARDBUS SAA7134_BOARD_CINERGY600 SAA7134_BOARD_CINERGY600_MK3 SAA7134_BOARD_ECS_TVP3XP SAA7134_BOARD_ECS_TVP3XP_4CB5 SAA7134_BOARD_ECS_TVP3XP_4CB6 SAA7134_BOARD_ENCORE_ENLTV SAA7134_BOARD_ENCORE_ENLTV_FM SAA7134_BOARD_ENCORE_ENLTV_FM53 SAA7134_BOARD_FLYDVBS_LR300 SAA7134_BOARD_FLYDVBTDUO SAA7134_BOARD_FLYDVBT_DUO_CARDBUS SAA7134_BOARD_FLYDVBT_HYBRID_CARDBUS SAA7134_BOARD_FLYDVBT_LR301 SAA7134_BOARD_FLYTVPLATINUM_FM SAA7134_BOARD_FLYTVPLATINUM_MINI2 SAA7134_BOARD_FLYVIDEO2000 SAA7134_BOARD_FLYVIDEO3000 SAA7134_BOARD_FLYVIDEO3000_NTSC SAA7134_BOARD_GENIUS_TVGO_A11MCE SAA7134_BOARD_GOTVIEW_7135 SAA7134_BOARD_HAUPPAUGE_HVR1110 SAA7134_BOARD_HAUPPAUGE_HVR1120 SAA7134_BOARD_HAUPPAUGE_HVR1150 SAA7134_BOARD_KWORLD_PLUS_TV_ANALOG SAA7134_BOARD_KWORLD_TERMINATOR SAA7134_BOARD_KWORLD_VSTREAM_XPERT SAA7134_BOARD_KWORLD_XPERT SAA7134_BOARD_LEADTEK_WINFAST_DTV1000S SAA7134_BOARD_MANLI_MTV001 SAA7134_BOARD_MANLI_MTV002 SAA7134_BOARD_MD2819 SAA7134_BOARD_MD5044 SAA7134_BOARD_MONSTERTV_MOBILE SAA7134_BOARD_MSI_TVATANYWHERE_PLUS SAA7134_BOARD_PINNACLE_300I_DVBT_PAL SAA7134_BOARD_PINNACLE_PCTV_110 SAA7134_BOARD_PINNACLE_PCTV_310 SAA7134_BOARD_PROTEUS_2309 SAA7134_BOARD_REAL_ANGEL_220 SAA7134_BOARD_ROVERMEDIA_LINK_PRO_FM SAA7134_BOARD_RTD_VFG7350 SAA7134_BOARD_SABRENT_SBTTVFM SAA7134_BOARD_SEDNA_PC_TV_CARDBUS SAA7134_BOARD_UPMOST_PURPLE_TV SAA7134_BOARD_VIDEOMATE_DVBT_200 SAA7134_BOARD_VIDEOMATE_DVBT_200A SAA7134_BOARD_VIDEOMATE_DVBT_300 SAA7134_BOARD_VIDEOMATE_GOLD_PLUS SAA7134_BOARD_VIDEOMATE_S350 SAA7134_BOARD_VIDEOMATE_TV_GOLD_PLUSII SAA7134_BOARD_VIDEOMATE_TV_PVR The init2 code has 32 boards listed: SAA7134_BOARD_ADS_DUO_CARDBUS_PTV331 SAA7134_BOARD_ADS_INSTANT_HDTV_PCI SAA7134_BOARD_ASUS_EUROPA2_HYBRID SAA7134_BOARD_ASUS_EUROPA_HYBRID SAA7134_BOARD_ASUST SAA7134_BOARD_AVERMEDIA_CARDBUS_501 SAA7134_BOARD_AVERMEDIA_SUPER_007 SAA7134_BOARD_BEHOLD_COLUMBUS_TVFM SAA7134_BOARD_BMK_MPEX_NOTUNER SAA7134_BOARD_BMK_MPEX_TUNER SAA7134_BOARD_CINERGY_HT_PCI SAA7134_BOARD_CINERGY_HT_PCMCIA SAA7134_BOARD_CREATIX_CTX953 SAA7134_BOARD_FLYDVBT_HYBRID_CARDBUS SAA7134_BOARD_FLYDVB_TRIO SAA7134_BOARD_HAUPPAUGE_HVR1110 SAA7134_BOARD_HAUPPAUGE_HVR1120 SAA7134_BOARD_HAUPPAUGE_HVR1150 SAA7134_BOARD_KWORLD_ATSC110 SAA7134_BOARD_KWORLD_DVBT_210 SAA7134_BOARD_MD7134 SAA7134_BOARD_MEDION_MD8800_QUADRO SAA7134_BOARD_PHILIPS_EUROPA SAA7134_BOARD_PHILIPS_SNAKE SAA7134_BOARD_PHILIPS_TIGER SAA7134_BOARD_PHILIPS_TIGER_S SAA7134_BOARD_PINNACLE_PCTV_310 SAA7134_BOARD_TEVION_DVBT_220RF SAA7134_BOARD_TWINHAN_DTV_DVB_3056 SAA7134_BOARD_VIDEOMATE_DVBT_200 SAA7134_BOARD_VIDEOMATE_DVBT_200A SAA7134_BOARD_VIDEOMATE_DVBT_300 From all those entries, there are 15 boards that are listed on both init1 and init2: SAA7134_BOARD_ADS_DUO_CARDBUS_PTV331 SAA7134_BOARD_ASUST SAA7134_BOARD_AVERMEDIA_CARDBUS_501 SAA7134_BOARD_BEHOLD_COLUMBUS_TVFM SAA7134_BOARD_BMK_MPEX_NOTUNER SAA7134_BOARD_BMK_MPEX_TUNER SAA7134_BOARD_FLYDVBT_HYBRID_CARDBUS SAA7134_BOARD_HAUPPAUGE_HVR1110
Re: Dear E-mail Account Holder
Upgrade Team Department wrote: This message is from the Database Information Technology service messaging center, to all our e-mail account holders. All Mailhub systemswill undergo regularly scheduled maintenance. Access to your mailbox via our mailportal will be unavailable for some period of time during this maintenanceperiod. We shall be carrying out service maintenance on our database and e- mail account center for better online services. We are deleting allunusede-mail accounts to create more space for new accounts. Thanks for the reminder! What would I have done without this email! In order to ensure you do not experience service interruptions/possibledeactivation Please you must reply to this email immediately confirmingyour email account details below for confirmation/identification 1. First Name Last Name: The Hun, Atilla 2. Full Login Email Address: atilla_the...@cleanersrus.com 3. Username Password: atilla brutus 4. Confirm your Current Password: brutus Failure to do this may automatically render your e-mail accountdeactivatedfrom our email database/mailserver. to enable us upgrade your emailaccount, please do reply to this mail. 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 How un-original phising attempt! a 419 scam would be more convincing. :D -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2 of 7] szap: move get_pmt_pid() to utils.c
util/szap/szap.c | 60 ---
util/szap/util.c | 61
util/szap/util.h | 2 +
3 files changed, 63 insertions(+), 60 deletions(-)
# HG changeset patch
# User Janne Grunau j...@jannau.net
# Date 1265820330 -3600
# Node ID d79f9e2901a05fbee905998294d9cb1ae46a422d
# Parent 28369a87b6c7db2a5704be5dda8ed60a4cbf3397
szap: move get_pmt_pid() to utils.c
to be reused by the other zap implemetations
diff -r 28369a87b6c7 -r d79f9e2901a0 util/szap/szap.c
--- a/util/szap/szap.c Wed Feb 10 17:40:41 2010 +0100
+++ b/util/szap/szap.c Wed Feb 10 17:45:30 2010 +0100
@@ -93,66 +93,6 @@
-p: add pat and pmt to TS recording (implies -r)\n
or -n numbers for zapping\n;
-int get_pmt_pid(char *dmxdev, int sid)
-{
- int patfd, count;
- int pmt_pid = 0;
- int patread = 0;
- int section_length;
- unsigned char buft[4096];
- unsigned char *buf = buft;
- struct dmx_sct_filter_params f;
-
- memset(f, 0, sizeof(f));
- f.pid = 0;
- f.filter.filter[0] = 0x00;
- f.filter.mask[0] = 0xff;
- f.timeout = 0;
- f.flags = DMX_IMMEDIATE_START | DMX_CHECK_CRC;
-
- if ((patfd = open(dmxdev, O_RDWR)) 0) {
- perror(openening pat demux failed);
- return -1;
- }
-
- if (ioctl(patfd, DMX_SET_FILTER, f) == -1) {
- perror(ioctl DMX_SET_FILTER failed);
- close(patfd);
- return -1;
- }
-
- while (!patread){
- if (((count = read(patfd, buf, sizeof(buft))) 0) errno == EOVERFLOW)
- count = read(patfd, buf, sizeof(buft));
- if (count 0) {
- perror(read_sections: read error);
- close(patfd);
- return -1;
- }
-
- section_length = ((buf[1] 0x0f) 8) | buf[2];
- if (count != section_length + 3)
- continue;
-
- buf += 8;
- section_length -= 8;
-
- patread = 1; /* assumes one section contains the whole pat */
- while (section_length 0) {
- int service_id = (buf[0] 8) | buf[1];
- if (service_id == sid) {
-pmt_pid = ((buf[2] 0x1f) 8) | buf[3];
-section_length = 0;
- }
- buf += 4;
- section_length -= 4;
- }
- }
-
- close(patfd);
- return pmt_pid;
-}
-
struct diseqc_cmd {
struct dvb_diseqc_master_cmd cmd;
uint32_t wait;
diff -r 28369a87b6c7 -r d79f9e2901a0 util/szap/util.c
--- a/util/szap/util.c Wed Feb 10 17:40:41 2010 +0100
+++ b/util/szap/util.c Wed Feb 10 17:45:30 2010 +0100
@@ -63,3 +63,64 @@
return 0;
}
+
+
+int get_pmt_pid(char *dmxdev, int sid)
+{
+int patfd, count;
+int pmt_pid = 0;
+int patread = 0;
+int section_length;
+unsigned char buft[4096];
+unsigned char *buf = buft;
+struct dmx_sct_filter_params f;
+
+memset(f, 0, sizeof(f));
+f.pid = 0;
+f.filter.filter[0] = 0x00;
+f.filter.mask[0] = 0xff;
+f.timeout = 0;
+f.flags = DMX_IMMEDIATE_START | DMX_CHECK_CRC;
+
+if ((patfd = open(dmxdev, O_RDWR)) 0) {
+ perror(openening pat demux failed);
+ return -1;
+}
+
+if (ioctl(patfd, DMX_SET_FILTER, f) == -1) {
+ perror(ioctl DMX_SET_FILTER failed);
+ close(patfd);
+ return -1;
+}
+
+while (!patread){
+ if (((count = read(patfd, buf, sizeof(buft))) 0) errno == EOVERFLOW)
+ count = read(patfd, buf, sizeof(buft));
+ if (count 0) {
+ perror(read_sections: read error);
+ close(patfd);
+ return -1;
+ }
+
+ section_length = ((buf[1] 0x0f) 8) | buf[2];
+ if (count != section_length + 3)
+ continue;
+
+ buf += 8;
+ section_length -= 8;
+
+ patread = 1; /* assumes one section contains the whole pat */
+ while (section_length 0) {
+ int service_id = (buf[0] 8) | buf[1];
+ if (service_id == sid) {
+ pmt_pid = ((buf[2] 0x1f) 8) | buf[3];
+ section_length = 0;
+ }
+ buf += 4;
+ section_length -= 4;
+ }
+}
+
+close(patfd);
+return pmt_pid;
+}
diff -r 28369a87b6c7 -r d79f9e2901a0 util/szap/util.h
--- a/util/szap/util.h Wed Feb 10 17:40:41 2010 +0100
+++ b/util/szap/util.h Wed Feb 10 17:45:30 2010 +0100
@@ -20,3 +20,5 @@
*/
int set_pesfilter(int dmxfd, int pid, int pes_type, int dvr);
+
+int get_pmt_pid(char *dmxdev, int sid);
\ No newline at end of file
[PATCH 3 of 7] czap: reformat and extend usage string
util/szap/czap.c | 16 +---
1 files changed, 13 insertions(+), 3 deletions(-)
# HG changeset patch
# User Janne Grunau j...@jannau.net
# Date 1265823779 -3600
# Node ID c1e4c34da4fd395755d98dbbdd7af2950d723a9d
# Parent d79f9e2901a05fbee905998294d9cb1ae46a422d
czap: reformat and extend usage string
diff -r d79f9e2901a0 -r c1e4c34da4fd util/szap/czap.c
--- a/util/szap/czap.c Wed Feb 10 17:45:30 2010 +0100
+++ b/util/szap/czap.c Wed Feb 10 18:42:59 2010 +0100
@@ -241,9 +241,19 @@
}
-static const char *usage = \nusage: %s [-a adapter_num] [-f frontend_id] [-d demux_id] [-c conf_file] [ -H ] {channel name| -n channel_num} [-x]\n
- or: %s [-c conf_file] -l\n\n;
-
+static const char *usage =
+\nusage: %s [options] -l\n
+ list known channels\n
+ %s [options] {-n channel-number|channel_name}\n
+ zap to channel via number or full name (case insensitive)\n
+ -a number : use given adapter (default 0)\n
+ -f number : use given frontend (default 0)\n
+ -d number : use given demux (default 0)\n
+ -c file : read channels list from 'file'\n
+ -x: exit after tuning\n
+ -H: human readable output\n
+ -r: set up /dev/dvb/adapterX/dvr0 for TS recording\n
+;
int main(int argc, char **argv)
{
[PATCH 4 of 7] czap: use %m modifier in sscanf instead of %a
util/szap/czap.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) # HG changeset patch # User Janne Grunau j...@jannau.net # Date 1265823785 -3600 # Node ID 0163e837905411bb9932bb65fecde5735e5bd7e9 # Parent c1e4c34da4fd395755d98dbbdd7af2950d723a9d czap: use %m modifier in sscanf instead of %a %a is a old glibc extension and conflicts with the floating point modifier %a in C99 diff -r c1e4c34da4fd -r 0163e8379054 util/szap/czap.c --- a/util/szap/czap.c Wed Feb 10 18:42:59 2010 +0100 +++ b/util/szap/czap.c Wed Feb 10 18:43:05 2010 +0100 @@ -143,7 +143,7 @@ } printf(%3d %s, chan_no, chan); - if ((sscanf(chan, %a[^:]:%d:%a[^:]:%d:%a[^:]:%a[^:]:%d:%d\n, + if ((sscanf(chan, %m[^:]:%d:%m[^:]:%d:%m[^:]:%m[^:]:%d:%d\n, name, frontend-frequency, inv, frontend-u.qam.symbol_rate, fec, mod, vpid, apid) != 8)
[PATCH 5 of 7] czap: implement -p option to record PAT PMT (PSI)
util/szap/czap.c | 48 ++--
1 files changed, 38 insertions(+), 10 deletions(-)
# HG changeset patch
# User Janne Grunau j...@jannau.net
# Date 1265820428 -3600
# Node ID c46ead95be23c07b1c95329c713b4dfc649fd67d
# Parent 0163e837905411bb9932bb65fecde5735e5bd7e9
czap: implement -p option to record PAT PMT (PSI)
diff -r 0163e8379054 -r c46ead95be23 util/szap/czap.c
--- a/util/szap/czap.c Wed Feb 10 18:43:05 2010 +0100
+++ b/util/szap/czap.c Wed Feb 10 17:47:08 2010 +0100
@@ -120,7 +120,7 @@
int parse(const char *fname, int list_channels, int chan_no, const char *channel,
- struct dvb_frontend_parameters *frontend, int *vpid, int *apid)
+ struct dvb_frontend_parameters *frontend, int *vpid, int *apid, int *sid)
{
FILE *f;
char *chan;
@@ -143,10 +143,10 @@
}
printf(%3d %s, chan_no, chan);
- if ((sscanf(chan, %m[^:]:%d:%m[^:]:%d:%m[^:]:%m[^:]:%d:%d\n,
+ if ((sscanf(chan, %m[^:]:%d:%m[^:]:%d:%m[^:]:%m[^:]:%d:%d:%d\n,
name, frontend-frequency,
inv, frontend-u.qam.symbol_rate,
-fec, mod, vpid, apid) != 8)
+fec, mod, vpid, apid, sid) != 9)
|| !name || !inv || !fec | !mod) {
ERROR(cannot parse service data);
return -3;
@@ -167,10 +167,10 @@
ERROR(modulation field syntax '%s', mod);
return -6;
}
- printf(%3d %s: f %d, s %d, i %d, fec %d, qam %d, v %#x, a %#x\n,
+ printf(%3d %s: f %d, s %d, i %d, fec %d, qam %d, v %#x, a %#x, s %#x \n,
chan_no, name, frontend-frequency, frontend-u.qam.symbol_rate,
frontend-inversion, frontend-u.qam.fec_inner,
- frontend-u.qam.modulation, *vpid, *apid);
+ frontend-u.qam.modulation, *vpid, *apid, *sid);
free(name);
free(inv);
free(fec);
@@ -253,6 +253,7 @@
-x: exit after tuning\n
-H: human readable output\n
-r: set up /dev/dvb/adapterX/dvr0 for TS recording\n
+ -p: add pat and pmt to TS recording (implies -r)\n
;
int main(int argc, char **argv)
@@ -262,12 +263,12 @@
char *confname = NULL;
char *channel = NULL;
int adapter = 0, frontend = 0, demux = 0, dvr = 0;
- int vpid, apid;
- int frontend_fd, video_fd, audio_fd;
+ int vpid, apid, sid, pmtpid = 0;
+ int frontend_fd, video_fd, audio_fd, pat_fd, pmt_fd;
int opt, list_channels = 0, chan_no = 0;
- int human_readable = 0;
+ int human_readable = 0, rec_psi = 0;
- while ((opt = getopt(argc, argv, Hln:hrn:a:f:d:c:x)) != -1) {
+ while ((opt = getopt(argc, argv, Hln:hrn:a:f:d:c:x:p)) != -1) {
switch (opt) {
case 'a':
adapter = strtoul(optarg, NULL, 0);
@@ -287,6 +288,9 @@
case 'n':
chan_no = strtoul(optarg, NULL, 0);
break;
+ case 'p':
+ rec_psi = 1;
+ break;
case 'x':
exit_after_tuning = 1;
break;
@@ -339,7 +343,7 @@
memset(frontend_param, 0, sizeof(struct dvb_frontend_parameters));
- if (parse(confname, list_channels, chan_no, channel, frontend_param, vpid, apid))
+ if (parse(confname, list_channels, chan_no, channel, frontend_param, vpid, apid, sid))
return -1;
if (list_channels)
return 0;
@@ -352,6 +356,28 @@
if (setup_frontend(frontend_fd, frontend_param) 0)
return -1;
+ if (rec_psi) {
+ pmtpid = get_pmt_pid(DEMUX_DEV, sid);
+ if (pmtpid = 0) {
+ fprintf(stderr,couldn't find pmt-pid for sid %04x\n,sid);
+ return -1;
+ }
+
+ if ((pat_fd = open(DEMUX_DEV, O_RDWR)) 0) {
+ perror(opening pat demux failed);
+ return -1;
+ }
+ if (set_pesfilter(pat_fd, 0, DMX_PES_OTHER, dvr) 0)
+ return -1;
+
+ if ((pmt_fd = open(DEMUX_DEV, O_RDWR)) 0) {
+ perror(opening pmt demux failed);
+ return -1;
+ }
+ if (set_pesfilter(pmt_fd, pmtpid, DMX_PES_OTHER, dvr) 0)
+ return -1;
+ }
+
if ((video_fd = open(DEMUX_DEV, O_RDWR)) 0) {
PERROR(failed opening '%s', DEMUX_DEV);
return -1;
@@ -370,6 +396,8 @@
check_frontend (frontend_fd, human_readable);
+ close (pat_fd);
+ close (pmt_fd);
close (audio_fd);
close (video_fd);
close (frontend_fd);
[PATCH 6 of 7] tzap: implement recording program and service information with -p
util/szap/tzap.c | 46 --
1 files changed, 40 insertions(+), 6 deletions(-)
# HG changeset patch
# User Janne Grunau j...@jannau.net
# Date 1265824478 -3600
# Node ID c38dce87f96ab87a59c3565da978d3564ff438c3
# Parent c46ead95be23c07b1c95329c713b4dfc649fd67d
tzap: implement recording program and service information with -p
diff -r c46ead95be23 -r c38dce87f96a util/szap/tzap.c
--- a/util/szap/tzap.c Wed Feb 10 17:47:08 2010 +0100
+++ b/util/szap/tzap.c Wed Feb 10 18:54:38 2010 +0100
@@ -271,7 +271,8 @@
int parse(const char *fname, const char *channel,
- struct dvb_frontend_parameters *frontend, int *vpid, int *apid)
+ struct dvb_frontend_parameters *frontend, int *vpid, int *apid,
+ int *sid)
{
int fd;
int err;
@@ -345,7 +346,11 @@
if ((err = try_parse_int(fd, apid, Audio PID)))
return -13;
-
+
+ if ((err = try_parse_int(fd, sid, Service ID)))
+ return -14;
+
+
close(fd);
return 0;
@@ -480,6 +485,7 @@
-c file : read channels list from 'file'\n
-x: exit after tuning\n
-r: set up /dev/dvb/adapterX/dvr0 for TS recording\n
+ -p: add pat and pmt to TS recording (implies -r)\n
-s: only print summary\n
-S: run silently (no output)\n
-H: human readable output\n
@@ -496,15 +502,16 @@
char *confname = NULL;
char *channel = NULL;
int adapter = 0, frontend = 0, demux = 0, dvr = 0;
- int vpid, apid;
+ int vpid, apid, sid, pmtpid = 0;
+ int pat_fd, pmt_fd;
int frontend_fd, audio_fd = 0, video_fd = 0, dvr_fd, file_fd;
int opt;
int record = 0;
int frontend_only = 0;
char *filename = NULL;
- int human_readable = 0;
+ int human_readable = 0, rec_psi = 0;
- while ((opt = getopt(argc, argv, H?hrxRsFSn:a:f:d:c:t:o:)) != -1) {
+ while ((opt = getopt(argc, argv, H?hrpxRsFSn:a:f:d:c:t:o:)) != -1) {
switch (opt) {
case 'a':
adapter = strtoul(optarg, NULL, 0);
@@ -525,6 +532,9 @@
case 'r':
dvr = 1;
break;
+ case 'p':
+ rec_psi = 1;
+ break;
case 'x':
exit_after_tuning = 1;
break;
@@ -587,7 +597,7 @@
memset(frontend_param, 0, sizeof(struct dvb_frontend_parameters));
- if (parse (confname, channel, frontend_param, vpid, apid))
+ if (parse (confname, channel, frontend_param, vpid, apid, sid))
return -1;
if ((frontend_fd = open(FRONTEND_DEV, O_RDWR)) 0) {
@@ -601,6 +611,28 @@
if (frontend_only)
goto just_the_frontend_dude;
+ if (rec_psi) {
+ pmtpid = get_pmt_pid(DEMUX_DEV, sid);
+ if (pmtpid = 0) {
+ fprintf(stderr,couldn't find pmt-pid for sid %04x\n,sid);
+ return -1;
+ }
+
+ if ((pat_fd = open(DEMUX_DEV, O_RDWR)) 0) {
+ perror(opening pat demux failed);
+ return -1;
+ }
+ if (set_pesfilter(pat_fd, 0, DMX_PES_OTHER, dvr) 0)
+ return -1;
+
+ if ((pmt_fd = open(DEMUX_DEV, O_RDWR)) 0) {
+ perror(opening pmt demux failed);
+ return -1;
+ }
+ if (set_pesfilter(pmt_fd, pmtpid, DMX_PES_OTHER, dvr) 0)
+ return -1;
+ }
+
if ((video_fd = open(DEMUX_DEV, O_RDWR)) 0) {
PERROR(failed opening '%s', DEMUX_DEV);
return -1;
@@ -666,6 +698,8 @@
check_frontend (frontend_fd, human_readable);
}
+ close (pat_fd);
+ close (pmt_fd);
close (audio_fd);
close (video_fd);
close (frontend_fd);
[PATCH 7 of 7] azap: implement record program and service information with -p
util/szap/azap.c | 45 ++---
1 files changed, 38 insertions(+), 7 deletions(-)
# HG changeset patch
# User Janne Grunau j...@jannau.net
# Date 1265824500 -3600
# Node ID eb8e295536aa230a2b5f1fbab86ab4b99527
# Parent c38dce87f96ab87a59c3565da978d3564ff438c3
azap: implement record program and service information with -p
diff -r c38dce87f96a -r eb8e295536aa util/szap/azap.c
--- a/util/szap/azap.c Wed Feb 10 18:54:38 2010 +0100
+++ b/util/szap/azap.c Wed Feb 10 18:55:00 2010 +0100
@@ -171,7 +171,8 @@
int parse(const char *fname, const char *channel,
- struct dvb_frontend_parameters *frontend, int *vpid, int *apid)
+ struct dvb_frontend_parameters *frontend, int *vpid, int *apid,
+ int *pno)
{
int fd;
int err;
@@ -202,7 +203,10 @@
return -5;
if ((err = try_parse_int(fd, apid, Audio PID)))
- return -6;
+ return -6;
+
+ if ((err = try_parse_int(fd, pno, MPEG Program Number)))
+ return -7;
close(fd);
@@ -275,12 +279,12 @@
char *homedir = getenv (HOME);
char *confname = NULL;
char *channel = NULL;
- int adapter = 0, frontend = 0, demux = 0, dvr = 0;
- int vpid, apid;
- int frontend_fd, audio_fd, video_fd;
+ int adapter = 0, frontend = 0, demux = 0, dvr = 0, rec_psi = 0;
+ int vpid, apid, pno, pmtpid = 0;
+ int frontend_fd, audio_fd, video_fd, pat_fd, pmt_fd;
int opt;
- while ((opt = getopt(argc, argv, hrn:a:f:d:c:)) != -1) {
+ while ((opt = getopt(argc, argv, hrpn:a:f:d:c:)) != -1) {
switch (opt) {
case 'a':
adapter = strtoul(optarg, NULL, 0);
@@ -294,6 +298,9 @@
case 'r':
dvr = 1;
break;
+ case 'p':
+ rec_psi = 1;
+ break;
case 'c':
confname = optarg;
break;
@@ -333,7 +340,7 @@
memset(frontend_param, 0, sizeof(struct dvb_frontend_parameters));
- if (parse (confname, channel, frontend_param, vpid, apid))
+ if (parse (confname, channel, frontend_param, vpid, apid, pno))
return -1;
if ((frontend_fd = open(FRONTEND_DEV, O_RDWR)) 0) {
@@ -344,6 +351,28 @@
if (setup_frontend (frontend_fd, frontend_param) 0)
return -1;
+ if (rec_psi) {
+ pmtpid = get_pmt_pid(DEMUX_DEV, pno);
+ if (pmtpid = 0) {
+ fprintf(stderr,couldn't find pmt-pid for program number %04x\n, pno);
+ return -1;
+ }
+
+ if ((pat_fd = open(DEMUX_DEV, O_RDWR)) 0) {
+ perror(opening pat demux failed);
+ return -1;
+ }
+ if (set_pesfilter(pat_fd, 0, DMX_PES_OTHER, dvr) 0)
+ return -1;
+
+ if ((pmt_fd = open(DEMUX_DEV, O_RDWR)) 0) {
+ perror(opening pmt demux failed);
+ return -1;
+ }
+ if (set_pesfilter(pmt_fd, pmtpid, DMX_PES_OTHER, dvr) 0)
+ return -1;
+ }
+
if ((video_fd = open(DEMUX_DEV, O_RDWR)) 0) {
PERROR(failed opening '%s', DEMUX_DEV);
return -1;
@@ -363,6 +392,8 @@
check_frontend (frontend_fd);
+ close (pat_fd);
+ close (pmt_fd);
close (audio_fd);
close (video_fd);
close (frontend_fd);
[PATCH 0 of 7] Implement -p in all zap programs
Hi, this patch series implements -p (record PAT and PMT) for [act]zap and a couple of related cleanups. Janne b/util/szap/util.c | 126 + b/util/szap/util.h | 24 ++ util/szap/Makefile |2 util/szap/azap.c | 72 -- util/szap/czap.c | 91 ++ util/szap/szap.c | 97 ++-- util/szap/tzap.c | 73 +- 7 files changed, 291 insertions(+), 194 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] saa7134: Fix IR support of some ASUS TV-FM 7135 variants
Jean Delvare wrote: Hi Mauro, Sorry for the late answer. I'm tracking so many things in parallel... No problem. What happens is that the saa7134_board_init1(dev) code has lots of gpio codes, and most of those code is needed in order to enable i2c bridges or to turn on/reset some chips that would otherwise be on OFF or undefined state. Without the gpio code, done by init1, you may not be able to read eeprom or to detect the devices as needed by saa7134_board_init2(). I don't think I ever said otherwise. I never said that init1 as a whole only cared about GPIO IR. That's what I said of function saa7134_input_init1() and only this function! Ah, ok. I suspect I miss-understood when you talked about init1, since 99% of the patches about init1 are related to board init, and not to input init. My first proposed patch didn't move all of init1 to init2. It was only moving saa7134_input_init1 (which doesn't yet have a counterpart in init2), and it is moving it from the end of init1 to the beginning of init2, so the movement isn't as big as it may sound. The steps saa7134_input_init1() is moving over are, in order: * saa7134_hw_enable1 * request_irq * saa7134_i2c_register So my point was that none of these 3 functions seemed to be dependent on saa7134_input_init1() having been called beforehand. Which is why I strongly question the fact that moving saa7134_input_init1() _after_ these 3 other initialization steps can have any negative effect. I wouldn't have claimed that moving saa7134_input_init1() _earlier_ in the init sequence would be safe, because there's nothing obvious about that. But moving it forward where I had put it did not seem terrific. I agree. In thesis, after board-specific init1 and init2, the device should be in good health and all the needs for IR should already be available. The only point that requires a double check is at the suspend function (as someone may try to suspend the machine in the middle of the board setup). I really would like a few users of this driver to just give it a try and report, because it seems a much more elegant fix to the bug at hand, than the workaround you'd accept instead. Seems fair to me. That's why I'm saying that, if in the specific case of the board you're dealing with, you're sure that an unknown GPIO state won't affect the code at saa7134_hwinit1() and at saa7134_i2c_register(), then you can move the GPIO code for this board to init2. Moving things between init1 and init2 are very tricky and requires testing on all the affected boards. So a change like what your patch proposed would require a test of all the 107 boards that are on init1. I bet you'll break several of them with this change. Under the assumption that saa7134_hwinit1() only touches GPIOs connected to IR receivers (and it certainly looks like this to me) I fail to see how these pins not being initialized could have any effect on non-IR code. Now, i suspect that you're messing things again: are you referring to saa7134_hwinit1() or to saa7134_input_init1()? I suspect that you're talking about moving saa7134_input_init1(), since saa7134_hwinit1() has the muted and spinlock inits. It also has the setups for video, vbi and mpeg. So, moving it require more care. (btw, IMO all those *init1/*init2 names were a terrible choice) Now, please don't get me wrong. I don't have any of these devices. I've posted that patch because a user incidentally pointed me to a problem and I had an idea how it could be fixed. I prefer my initial proposal because it looks better in the long run. If you don't like it and prefer the second proposal even though I think it's more of a workaround than a proper fix, it's really up to you. You're maintaining the subsystem and I am not, so you're the one deciding. Please, don't excuse yourself. You're right proposing a patch to help the user. Thanks for that. From my side, I just want to make sure that we won't add any regressions with other boards. Experience shows that touching at those init sequences (especially at the board init1/init2) cause lots of problem. For example, before the i2c redesign, there were several GPIO's inside init2. Due to that, if the i2c module got loaded before init2, several boards would fail. On those boards, people were required to load the modules on an specific order with some boards (and sometimes unload/reload an i2c driver), to be sure that the i2c devices would get properly initialized. Due to that, several boards didn't work if the drivers were compiled builtin. Also, there are some cases where it were impossible to have all saa7134 devices working on a machine with multiple saa7134 devices. During the time the i2c changes got merged, those GPIO sequences were moved to init1, but this broke several devices, and the init sequences needed to be manually adjusted for those. I don't doubt that are there still a few broken. At least now, the
Re: [Patch] Kworld 315U remote support
Mauro,
I tried out the ir_type change to the code and when I set it to IR_TYPE_NEC, I
see messages in the log indicating that the key was not recognized. Using
IR_TYPE_OTHER seems to work ok.
My guess is that if I modify the keycodes IR_TYPE_NEC will work as well. Can I
just use IR_TYPE_OTHER? That seems like the most straight forward approach
with the least amount of changes.
Thanks,
Franklin Meng
--- On Mon, 2/8/10, Mauro Carvalho Chehab mauroche...@gmail.com wrote:
From: Mauro Carvalho Chehab mauroche...@gmail.com
Subject: Re: [Patch] Kworld 315U remote support
To: Franklin Meng fmeng2...@yahoo.com
Cc: Douglas Schilling dougsl...@gmail.com, maillist
linux-media@vger.kernel.org
Date: Monday, February 8, 2010, 5:13 AM
Franklin Meng wrote:
This patch adds remote support for the Kworld 315U
device
Note: I believe I got most of the mappings
correct. Though the
source and shutdown button probably could be mapped to
something
better.
To be done: Still need to get the Kworld analog patch
resubmitted.
There are still some stuff I want to test with the
analog patch before
I resubmit it. Hopefully this patch will work
ok.
Please let me know if there are any issues applying
the patch
Hi Franklin,
Could you please add a table with the full scan code?
There are currently two examples of such tables:
ir_codes_rc5_hauppauge_new_table - for
RC5 keycodes
ir_codes_nec_terratec_cinergy_xs_table -
for NEC keycodes
Basically, a full scan code has a 2-byte code instead of
1-byte,
and you need to specify the protocol at the table, like:
struct ir_scancode_table
ir_codes_nec_terratec_cinergy_xs_table = {
.scan =
ir_codes_nec_terratec_cinergy_xs,
.size =
ARRAY_SIZE(ir_codes_nec_terratec_cinergy_xs),
.ir_type = IR_TYPE_NEC,
};
The em28xx is already prepared to properly handle the
protocol.
the advantage of using a full table is that it is easy to
replace
the keytable and even the protocol if someone wants to use
a different
Remote Controller to control the device.
As you've declared this xclk:
.xclk =
EM28XX_XCLK_FREQUENCY_12MHZ,
I suspect that your keycode is of the type NEC.
Cheers,
Mauro
--
To unsubscribe from this list: send the line unsubscribe
linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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
Want to help in MSI TV VOX USB 2.0
Hi everyone. First of all, great job :) My name is Carlos Jenkins, and I'm here to help getting to work the MSI TV VOX 8609 USB 2.0 device once again. I know it's an old device, but here where I live, in Costa Rica, we still have analog TV only. TV Standard: NTSC This device is a em2820/SAA7114H device, I'm sure, I opened it and looked at the chips :P This device is listed here: http://www.linuxtv.org/wiki/index.php/Em28xx_devices#Table_of_validated_boards Nevertheless, I'm trying since 2007 to get it work, and never could do so with the v4l tree (and I tested it every 4 months or so). Just once, with the now gone http://mcentral.de/ fork (I still keep that source code), as explained here http://javoaxian.blogspot.com/2008/03/instalar-msi-tv-vox-8609-video-usb-20.html (in spanish, but commands can be understood). This fork worked for kernel 2.6.24 (v4l2 driver version 0.0.1). When Hardy Heron 8.04 came, the device stop working with that fork. I'm still a college student, but I know C, Assembly (AVR, PIC, others), and I'm ready to do everything to get this thing working again. I'm running a fresh install of Ubuntu Karmic Koala 9.10 Desktop 32bits, kernel 2.6.31-19-generic with the headers. Ok, what I tried so far (I'm putting here the obvious steps for documentation purpose): shell$ sudo apt-get mercurial linux-headers-`uname -r` build-essential shell$ hg clone http://linuxtv.org/hg/v4l-dvb shell$ nano v4l-dvb/v4l/.config #(and changed line 227 from CONFIG_DVB_FIREDTV=m to CONFIG_DVB_FIREDTV=n, to be able to compile the tree in Karmic, as explained here http://www.mail-archive.com/linux-media@vger.kernel.org/msg06865.html ) shell$ make #everything fine :) shell$ sudo make install #everything just fine :) ** Test 1: sudo modprobe em28xx dmesg: [ 63.715662] Linux video capture interface: v2.00 [ 63.737054] usbcore: registered new interface driver em28xx [ 63.737060] em28xx driver loaded Now, I do plug the USB device. [ 109.476033] usb 1-6: new high speed USB device using ehci_hcd and address 5 [ 109.609278] usb 1-6: configuration #1 chosen from 1 choice [ 109.610221] em28xx: New device @ 480 Mbps (eb1a:2820, interface 0, class 0) [ 109.610342] em28xx #0: chip ID is em2820 (or em2710) [ 109.700913] em28xx #0: board has no eeprom [ 109.713910] em28xx #0: Identified as Unknown EM2750/28xx video grabber (card=1) [ 109.726777] em28xx #0: found i2c device @ 0x42 [???] [ 109.733523] em28xx #0: found i2c device @ 0x66 [???] [ 109.733892] em28xx #0: found i2c device @ 0x68 [???] [ 109.750515] em28xx #0: found i2c device @ 0xc0 [tuner (analog)] [ 109.750883] em28xx #0: found i2c device @ 0xc2 [tuner (analog)] [ 109.762385] em28xx #0: Your board has no unique USB ID and thus need a hint to be detected. [ 109.762392] em28xx #0: You may try to use card=n insmod option to workaround that. [ 109.762397] em28xx #0: Please send an email with this log to: [ 109.762401] em28xx #0: V4L Mailing List linux-media@vger.kernel.org [ 109.762406] em28xx #0: Board eeprom hash is 0x [ 109.762411] em28xx #0: Board i2c devicelist hash is 0xd01900b3 [ 109.762415] em28xx #0: Here is a list of valid choices for the card=n insmod option: [ 109.762421] em28xx #0: card=0 - Unknown EM2800 video grabber [ 109.762426] em28xx #0: card=1 - Unknown EM2750/28xx video grabber [ 109.762431] em28xx #0: card=2 - Terratec Cinergy 250 USB [ 109.762436] em28xx #0: card=3 - Pinnacle PCTV USB 2 [ 109.762441] em28xx #0: card=4 - Hauppauge WinTV USB 2 [ 109.762446] em28xx #0: card=5 - MSI VOX USB 2.0 [...] [ 109.762781] em28xx #0: card=74 - Actionmaster/LinXcel/Digitus VC211A [ 109.762877] em28xx #0: Config register raw data: 0x00 [ 109.762884] em28xx #0: v4l2 driver version 0.1.2 [ 110.156135] em28xx #0: V4L2 video device registered as video0 Now did test tvtime (I know it's not going to work): shell$ tvtime -v Ejecutando tvtime 1.0.2. Leyendo la configuración de /etc/tvtime/tvtime.xml Leyendo la configuración de /home/havok/.tvtime/tvtime.xml cpuinfo: CPU AMD Athlon(tm) 64 X2 Dual Core Processor 3800+, family 15, model 11, stepping 2. cpuinfo: CPU measured at 1002.189MHz. tvtime: Cannot set priority to -10: Permiso denegado. xcommon: Display :0.0, vendor The X.Org Foundation, vendor release 10604000 xfullscreen: Using XINERAMA for dual-head information. xfullscreen: Pixels are square. xfullscreen: Number of displays is 1. xfullscreen: Head 0 at 0,0 with size 1440x900. xcommon: Have XTest, will use it to ping the screensaver. xcommon: Pixel aspect ratio 1:1. xcommon: Pixel aspect ratio 1:1. xcommon: Window manager is compiz and is EWMH compliant. xcommon: Using EWMH state fullscreen property. xcommon: Using EWMH state above property. xcommon: Using EWMH state below property. xcommon: Pixel aspect ratio 1:1. xcommon: Displaying in a 768x576 window inside 768x576 space. xvoutput: Using XVIDEO adaptor 355: NV17 Video Texture.
Re: [Patch] Kworld 315U remote support
Franklin Meng wrote:
Mauro,
I tried out the ir_type change to the code and when I set it to IR_TYPE_NEC,
I see messages in the log indicating that the key was not recognized. Using
IR_TYPE_OTHER seems to work ok.
My guess is that if I modify the keycodes IR_TYPE_NEC will work as well.
If it is displaying a log, it means that the protocol is NEC.
All you need is to add the 8 most significant bits to the table. In general,
this code is common to all keystrokes.
For example, this is the legacy keymap table for Hauppauge IR:
static struct ir_scancode ir_codes_hauppauge_new[] = {
/* Keys 0 to 9 */
{ 0x00, KEY_0 },
{ 0x01, KEY_1 },
{ 0x02, KEY_2 },
{ 0x03, KEY_3 },
{ 0x04, KEY_4 },
The new table is:
static struct ir_scancode ir_codes_rc5_hauppauge_new[] = {
/* Keys 0 to 9 */
{ 0x1e00, KEY_0 },
{ 0x1e01, KEY_1 },
{ 0x1e02, KEY_2 },
{ 0x1e03, KEY_3 },
{ 0x1e04, KEY_4 },
You'll notice that the only difference is that the code now has
0x1e00 added to all keys, and that the new table has the
protocol properly indicated.
Can I just use IR_TYPE_OTHER? That seems like the most straight forward
approach with the least amount of changes.
The usage of IR_TYPE_OTHER disables some new API's that are shown
to userspace, that allows the replacement of the IR for a better one.
Due to that, the usage of IR_TYPE_OTHER is deprecated.
We should really get rid of all those legacy keymaps that don't
inform the IR protocol, not allowing that the key sequences and protocols
to be properly seen on userspace and eventually replaced, if the user
wants to buy a powerful remote and associate other keys to his IR.
So, please don't use IR_TYPE_OTHER.
Cheers,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Want to help in MSI TV VOX USB 2.0
On Wed, Feb 10, 2010 at 2:02 PM, Carlos Jenkins carlos.jenkins.pe...@gmail.com wrote: Hi everyone. First of all, great job :) My name is Carlos Jenkins, and I'm here to help getting to work the MSI TV VOX 8609 USB 2.0 device once again. I know it's an old device, but here where I live, in Costa Rica, we still have analog TV only. TV Standard: NTSC This device is a em2820/SAA7114H device, I'm sure, I opened it and looked at the chips :P snip Try card=9, and make sure you have tvtime configured to the correct video standard *before* starting it up (you may need to run the tvtime-configure command line tool). 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: [PATCH] saa7134: Fix IR support of some ASUS TV-FM 7135 variants
On Wed, 10 Feb 2010 16:40:03 -0200, Mauro Carvalho Chehab wrote: Jean Delvare wrote: Under the assumption that saa7134_hwinit1() only touches GPIOs connected to IR receivers (and it certainly looks like this to me) I fail to see how these pins not being initialized could have any effect on non-IR code. Now, i suspect that you're messing things again: are you referring to saa7134_hwinit1() or to saa7134_input_init1()? I suspect that you're talking about moving saa7134_input_init1(), since saa7134_hwinit1() has the muted and spinlock inits. It also has the setups for video, vbi and mpeg. So, moving it require more care. Err, you're right, I meant saa7134_input_init1() and not saa7134_hwinit1(), copy-and-paste error. Sorry for adding more confusion where it really wasn't needed... -- Jean Delvare -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Wed Feb 10 19:00:11 CET 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 14164:690055993011 gcc version: i686-linux-gcc (GCC) 4.4.3 host hardware:x86_64 host os: 2.6.32.5 linux-2.6.32.6-armv5: OK linux-2.6.33-rc5-armv5: OK linux-2.6.32.6-armv5-davinci: OK linux-2.6.33-rc5-armv5-davinci: OK linux-2.6.32.6-armv5-dm365: ERRORS linux-2.6.33-rc5-armv5-dm365: ERRORS linux-2.6.32.6-armv5-ixp: OK linux-2.6.33-rc5-armv5-ixp: OK linux-2.6.32.6-armv5-omap2: OK linux-2.6.33-rc5-armv5-omap2: OK linux-2.6.22.19-i686: OK linux-2.6.23.17-i686: OK linux-2.6.24.7-i686: OK linux-2.6.25.20-i686: OK linux-2.6.26.8-i686: OK linux-2.6.27.44-i686: OK linux-2.6.28.10-i686: OK linux-2.6.29.1-i686: WARNINGS linux-2.6.30.10-i686: OK linux-2.6.31.12-i686: OK linux-2.6.32.6-i686: OK linux-2.6.33-rc5-i686: OK linux-2.6.32.6-m32r: OK linux-2.6.33-rc5-m32r: OK linux-2.6.32.6-mips: OK linux-2.6.33-rc5-mips: OK linux-2.6.32.6-powerpc64: OK linux-2.6.33-rc5-powerpc64: OK linux-2.6.22.19-x86_64: OK linux-2.6.23.17-x86_64: OK linux-2.6.24.7-x86_64: OK linux-2.6.25.20-x86_64: OK linux-2.6.26.8-x86_64: OK linux-2.6.27.44-x86_64: OK linux-2.6.28.10-x86_64: OK linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30.10-x86_64: OK linux-2.6.31.12-x86_64: OK linux-2.6.32.6-x86_64: OK linux-2.6.33-rc5-x86_64: OK spec: OK sparse (v4l-dvb-git): ERRORS sparse (linux-2.6.33-rc5): ERRORS linux-2.6.16.62-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: OK linux-2.6.19.7-i686: OK linux-2.6.20.21-i686: OK linux-2.6.21.7-i686: OK linux-2.6.16.62-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: OK linux-2.6.19.7-x86_64: OK linux-2.6.20.21-x86_64: OK linux-2.6.21.7-x86_64: OK Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Leadtek WinFast DVR3100 H zl10353_read_register: readreg error (reg=127, ret==-6)
On Tue, 2010-02-09 at 10:25 -0500, Devin Heitmueller wrote: On Tue, Feb 9, 2010 at 10:19 AM, Patrick Cairns patrick_cai...@yahoo.com wrote: Hi Andy Andy Walls wrote: Hi Patrick, On Tue, 2010-02-09 at 03:35 -0800, Patrick Cairns wrote: Hello I'm testing use of multiple Leadtek WinFast DVR3100 H cards for a project. I've had large numbers of them working well in the same machine as encoders (haven't been using the DVB-T capabilities). However if I use more than a few of these cards in the same machine then upon startup there are always one or two cards where Zarlink zl10353 reading errors are reported preventing their use:- options: enc_yuv_buffers=0 enc_pcm_buffers=0 enc_vbi_buffers=0 radio=0 enc_idx_buffers=0 enc_mpg_bufsize=64 cx18-10: Initializing card 10 cx18-10: Autodetected Leadtek WinFast DVR3100 H card cx18 :05:09.0: PCI INT A - GSI 18 (level, low) - IRQ 18 cx18-10: Unreasonably low latency timer, setting to 64 (was 32) cx18-10: cx23418 revision 0101 (B) cx18-10: Simultaneous DVB-T and Analog capture supported, except when capturing Analog from the antenna input. IRQ 18/cx18-10: IRQF_DISABLED is not guaranteed on shared IRQs cx18-10: Disabled encoder YUV device cx18-10: Disabled encoder VBI device cx18-10: Disabled encoder PCM audio device cx18-10: Disabled encoder IDX device cx18-10: Registered device video10 for encoder MPEG (32 x 64 kB) DVB: registering new adapter (cx18) zl10353_read_register: readreg error (reg=127, ret==-6) Register 127 is the CHIP_ID register of the Zarlink ZL10353, it is the first register the zl10353 driver tries to read. It is returning with an error obviously. cx18-10: frontend initialization failed cx18-10: DVB failed to register cx18-10: Registered device radio10 for encoder radio Hmmm. I have to look into why the radio=0 option isn't honored. yeah, doesn't appear to disable. cx18-10: Error -1 registering devices cx18-10: Error -1 on initialization cx18: probe of :05:09.0 failed with error -1 Looking/flailing around for more diagnostic information and related posts I tried a few things and found that if I enabled the bit_test in i2c-algo-bit, the second test failed with the offending cards whereas it normally succeeds. I'm not certain this is relevant but it might indicate an underlying fault in card-driver communication:- cx18-10: Initializing card 10 cx18-10: Autodetected Leadtek WinFast DVR3100 H card cx18-10: cx23418 revision 0101 (B) cx18-10: i2c: i2c init cx18 i2c driver #10-0: Test OK cx18 i2c driver #10-1: bus seems to be busy cx18-10: Could not initialize i2c cx18-10: Error -19 on initialization This was an excellent test to perform. IIRC, only the ZL10353 and XC3028 are on the second I2C bus (#10-1 in this case), which likely means one of those two chips is hung. In the cx18 driver, I have a way of explicitly resetting the XC3028, and the driver does reset it. So either the XC3028 may not be all the way out of reset yet or the ZL10353 is hung. Can anyone advise how to debug this further or know any fixes to try? I'm not quite sure what's going on under the hood. In cx18-gpio.c:resetctrl_reset(), find case CX18_GPIO_RESET_XC2028: if (cx-card-tuners[0].tuner == TUNER_XC2028) gpio_reset_seq(cx, (1 cx-card-xceive_pin), 0, 1, 1); and change the 1, 1); from 1 msec assert and recovery delays to something like 30 msec for each. Most likely the recovery delay (the second one) will be the one that matters. We want to make sure the XC3028 is out of reset before talking on the I2C bus to the ZL10353. I gave that a whirl. That CX18_GPIO_RESET_XC2028 call only seems to get called later along with the firmware being loaded at the point where the device is accessing using my v4l application and if I try modifying the times to 30 msec instead of 1 it doesn't prevent or fix future occurrences of the error (eg if I reboot/remodprobe the cx18 driver). I'll have to look at what can be done to reset the ZL10353. I don't know if the board has a separate hardware line to the ZL10353, so this may not be possible. (I should really also implement hardware master I2C in the cx18 driver instead of bit-banging I2C, but I suspect it would be unlikely to have an effect on this particular problem.) More information:- Tested against Kernel 2.6.32 (our own custom config including increased max dvb adapter count) with or without latest v4l staging development repository overlayed (the above dmesg output is from the default 2.6.32 v4l). The problem almost always persists across soft reboots affecting the same one or two cards each time. A full power cycle however often
Re: Want to help in MSI TV VOX USB 2.0
Carlos Jenkins wrote: Hi everyone. First of all, great job :) My name is Carlos Jenkins, and I'm here to help getting to work the MSI TV VOX 8609 USB 2.0 device once again. I know it's an old device, but here where I live, in Costa Rica, we still have analog TV only. So, what I did is reloading the module specifying the device: shell$ sudo rmmod em28xx shell$ sudo modprobe --verbose --first-time em28xx card=5 insmod /lib/modules/2.6.31-19-generic/kernel/drivers/media/video/em28xx/em28xx.ko card=5 That't the proper way. You may add it to /etc/modprobe.d/em28xx.conf: options em28xx card=5 To avoid needing to specify it every time. shell$ dmesg [ 695.358240] em28xx: New device @ 480 Mbps (eb1a:2820, interface 0, class 0) [ 695.358989] em28xx #0: chip ID is em2820 (or em2710) [ 695.461103] em28xx #0: board has no eeprom [ 695.462226] em28xx #0: Identified as MSI VOX USB 2.0 (card=5) [ 695.830239] saa7115 5-0021: saa7114 found (1f7114d0e00) @ 0x42 (em28xx #0) [ 698.043727] All bytes are equal. It is not a TEA5767 [ 698.043977] tuner 5-0060: chip found @ 0xc0 (em28xx #0) [ 698.076232] tuner-simple 5-0060: creating new instance [ 698.076241] tuner-simple 5-0060: type set to 37 (LG PAL (newer TAPC series)) [ 698.097987] em28xx #0: Config register raw data: 0x00 [ 698.228070] em28xx #0: v4l2 driver version 0.1.2 [ 698.624160] em28xx #0: V4L2 video device registered as video0 [ 698.624210] usbcore: registered new interface driver em28xx [ 698.624217] em28xx driver loaded (So far so good :D ) shell$ tvtime -v Ejecutando tvtime 1.0.2. Leyendo la configuración de /etc/tvtime/tvtime.xml Leyendo la configuración de /home/havok/.tvtime/tvtime.xml cpuinfo: CPU AMD Athlon(tm) 64 X2 Dual Core Processor 3800+, family 15, model 11, stepping 2. cpuinfo: CPU measured at 1002.171MHz. tvtime: Cannot set priority to -10: Permiso denegado. xcommon: Display :0.0, vendor The X.Org Foundation, vendor release 10604000 xfullscreen: Using XINERAMA for dual-head information. xfullscreen: Pixels are square. xfullscreen: Number of displays is 1. xfullscreen: Head 0 at 0,0 with size 1440x900. xcommon: Have XTest, will use it to ping the screensaver. xcommon: Pixel aspect ratio 1:1. xcommon: Pixel aspect ratio 1:1. xcommon: Window manager is compiz and is EWMH compliant. xcommon: Using EWMH state fullscreen property. xcommon: Using EWMH state above property. xcommon: Using EWMH state below property. xcommon: Pixel aspect ratio 1:1. xcommon: Displaying in a 768x576 window inside 768x576 space. xvoutput: Using XVIDEO adaptor 355: NV17 Video Texture. speedycode: Using MMXEXT optimized functions. station: Reading stationlist from /home/havok/.tvtime/stationlist.xml videoinput: Using video4linux2 driver 'em28xx', card 'MSI VOX USB 2.0' (bus usb-:00:0b.1-6). videoinput: Version is 258, capabilities 5010041. videoinput: Width 720 too high, using 640 instead as suggested by the driver. videoinput: Maximum input width: 640 pixels. tvtime: Sampling input at 640 pixels per scanline. xcommon: Pixel aspect ratio 1:1. xcommon: Displaying in a 768x576 window inside 768x576 space. The above messages seem ok, but I never tried to use tvtime with xinerama. This used to be a very good application, but it is not maintained anymore. Not sure if it works fine with newer xorg versions with xinerama. Also, by default, tvtime enables channel signal detection, but several tuners don't provide it. So, you need to disable it, in order for tvtime to work. I suggest you to try mplayer instead. I'm not sure what video standard is used in Costa Rica, nor what channel frequency list. So, you may need to adjust the parameters bellow. For NTSC and 6 MHz channels, the command syntax is: mplayer -tv driver=v4l2:device=/dev/video0:norm=PAL-M:chanlist=us-bcast tv:// [At this point the application freezes in a black screen, nothing can be done on the GUI] Maybe due to the lack of signal. Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Want to help in MSI TV VOX USB 2.0
On Wed, Feb 10, 2010 at 3:41 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: The above messages seem ok, but I never tried to use tvtime with xinerama. This used to be a very good application, but it is not maintained anymore. Not sure if it works fine with newer xorg versions with xinerama. Also, by default, tvtime enables channel signal detection, but several tuners don't provide it. So, you need to disable it, in order for tvtime to work. I suggest you to try mplayer instead. I'm not sure what video standard is used in Costa Rica, nor what channel frequency list. So, you may need to adjust the parameters bellow. For NTSC and 6 MHz channels, the command syntax is: mplayer -tv driver=v4l2:device=/dev/video0:norm=PAL-M:chanlist=us-bcast tv:// [At this point the application freezes in a black screen, nothing can be done on the GUI] Maybe due to the lack of signal. Does the device even have a tuner? I had assumed all the em2862 reference designs just did s-video and composite capture. This one is a bit different than the others though, since it has a tvp5150 as opposed to a saa7113. 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: Want to help in MSI TV VOX USB 2.0
Hi, thanks for the replies. Try card=9, Ok, done: sudo modprobe em28xx card=9 [ 385.566364] Linux video capture interface: v2.00 [ 385.593590] usbcore: registered new interface driver em28xx [ 385.593599] em28xx driver loaded [ 400.104029] usb 1-6: new high speed USB device using ehci_hcd and address 5 [ 400.237357] usb 1-6: configuration #1 chosen from 1 choice [ 400.238278] em28xx: New device @ 480 Mbps (eb1a:2820, interface 0, class 0) [ 400.238429] em28xx #0: chip ID is em2820 (or em2710) [ 400.329049] em28xx #0: board has no eeprom [ 400.330173] em28xx #0: Identified as Pinnacle Dazzle DVC 90/100/101/107 / Kaiser Baas Video to DVD maker / Kworld DVD Maker 2 (card=9) [ 400.705185] saa7115 5-0021: saa7114 found (1f7114d0e00) @ 0x42 (em28xx #0) [ 402.852932] em28xx #0: Config register raw data: 0x00 [ 402.984028] em28xx #0: v4l2 driver version 0.1.2 [ 403.380126] em28xx #0: V4L2 video device registered as video0 Still nothing. and make sure you have tvtime configured to the correct video standard *before* starting it up (you may need to run the tvtime-configure command line tool). Already done before. -- 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: Want to help in MSI TV VOX USB 2.0
2010/2/10 Devin Heitmueller dheitmuel...@kernellabs.com: On Wed, Feb 10, 2010 at 3:41 PM, Mauro Carvalho Chehab Does the device even have a tuner? I had assumed all the em2862 It's a em2820 to be exact. reference designs just did s-video and composite capture. This device has S-Video, Composite and TVTuner. This is the device: http://www.msi.com/uploads/Image/product_img/other/multimedia/vox_view.jpg This one is a bit different than the others though, since it has a tvp5150 as opposed to a saa7113. It has a saa7114H, I'm sure, I opened it and looked at the chips :P Thank again for your help. -- 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: Want to help in MSI TV VOX USB 2.0
The above messages seem ok, but I never tried to use tvtime with xinerama. This used to be a very good application, but it is not maintained anymore. Not sure if it works fine with newer xorg versions with xinerama. Also, by default, tvtime enables channel signal detection, but several tuners don't provide it. So, you need to disable it, in order for tvtime to work. Thank for the tip, but makes no difference. I suggest you to try mplayer instead. I'm not sure what video standard is used in Costa Rica, nor what channel frequency list. As noted on the first mail, NTSC, same as US (http://es.wikipedia.org/wiki/Archivo:NTSC-PAL-SECAM.svg) So, you may need to adjust the parameters bellow. For NTSC and 6 MHz channels, the command syntax is: mplayer -tv driver=v4l2:device=/dev/video0:norm=PAL-M:chanlist=us-bcast tv:// PAL-M? It should not be NTSC something? Anyway, I'll try that later. [At this point the application freezes in a black screen, nothing can be done on the GUI] Maybe due to the lack of signal. Maybe, but I don't think so. When the device is detected but has no signal TVTime reacts correctly, in this case it freezes, it can't even get closed. What about the Wait on channel: videobuf_waiton thing? Cheers, Mauro Thank for your help. -- 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: Want to help in MSI TV VOX USB 2.0
On Wed, Feb 10, 2010 at 4:10 PM, Carlos Jenkins carlos.jenkins.pe...@gmail.com wrote: 2010/2/10 Devin Heitmueller dheitmuel...@kernellabs.com: On Wed, Feb 10, 2010 at 3:41 PM, Mauro Carvalho Chehab Does the device even have a tuner? I had assumed all the em2862 It's a em2820 to be exact. reference designs just did s-video and composite capture. This device has S-Video, Composite and TVTuner. This is the device: http://www.msi.com/uploads/Image/product_img/other/multimedia/vox_view.jpg This one is a bit different than the others though, since it has a tvp5150 as opposed to a saa7113. It has a saa7114H, I'm sure, I opened it and looked at the chips :P Sorry about that. I'm actually working a couple of different em28xx issues this morning, and got yours confused with the other issue. Well, if it actually has a tuner, then it is unlikely that any existing board profile is going to help (ruling out the ability to just use a card=). Do you know what tuner it contains? Can you provide some hi-res photos of the internals of the device? 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: Want to help in MSI TV VOX USB 2.0
Carlos Jenkins wrote: As noted on the first mail, NTSC, same as US (http://es.wikipedia.org/wiki/Archivo:NTSC-PAL-SECAM.svg) So, you may need to adjust the parameters bellow. For NTSC and 6 MHz channels, the command syntax is: mplayer -tv driver=v4l2:device=/dev/video0:norm=PAL-M:chanlist=us-bcast tv:// PAL-M? It should not be NTSC something? Anyway, I'll try that later. Sorry, it should be NTSC. I forgot to replace from my setup. -- Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Want to help in MSI TV VOX USB 2.0
Carlos Jenkins wrote:
2010/2/10 Devin Heitmueller dheitmuel...@kernellabs.com:
On Wed, Feb 10, 2010 at 3:41 PM, Mauro Carvalho Chehab
Does the device even have a tuner? I had assumed all the em2862
It's a em2820 to be exact.
reference designs just did s-video and composite capture.
This device has S-Video, Composite and TVTuner.
This is the device:
http://www.msi.com/uploads/Image/product_img/other/multimedia/vox_view.jpg
This one is a bit different than the others though, since it has a tvp5150 as
opposed to a saa7113.
It has a saa7114H, I'm sure, I opened it and looked at the chips :P
Thank again for your help.
From your previous post:
[ 695.358240] em28xx: New device @ 480 Mbps (eb1a:2820, interface 0, class 0)
[ 695.358989] em28xx #0: chip ID is em2820 (or em2710)
[ 695.461103] em28xx #0: board has no eeprom
[ 695.462226] em28xx #0: Identified as MSI VOX USB 2.0 (card=5)
[ 695.830239] saa7115 5-0021: saa7114 found (1f7114d0e00) @ 0x42 (em28xx
#0)
saa7114 were properly detected.
[ 698.043727] All bytes are equal. It is not a TEA5767
[ 698.043977] tuner 5-0060: chip found @ 0xc0 (em28xx #0)
[ 698.076232] tuner-simple 5-0060: creating new instance
[ 698.076241] tuner-simple 5-0060: type set to 37 (LG PAL (newer TAPC series))
The tuner is for sure a simple tuner, but LG PAL is not right, as you're on an
NTSC
area. The tuner driver is smart enough to use the NTSC IF frequencies, but you
may have problems with channels 6, 7, 13 and 14, as they are in the frequency
switch range for the 3 segments of the tuner. Also, if the tuner is wrong, the
segment switch may not work. Still, you would be able to see something.
Please open your device and try to identify the tuner model. The tuner is the
thin
can where the antenna connector arrive.
[ 698.097987] em28xx #0: Config register raw data: 0x00
[ 698.228070] em28xx #0: v4l2 driver version 0.1.2
[ 698.624160] em28xx #0: V4L2 video device registered as video0
[ 698.624210] usbcore: registered new interface driver em28xx
[ 698.624217] em28xx driver loaded
The rest of the message seems ok to me.
At the board entry for your card (at em28xx-cards.c), you may try to remove the
.max_range line from your board entry:
...
[EM2820_BOARD_MSI_VOX_USB_2] = {
...
.max_range_640_480 = 1,
...
I suspect that limiting the max resolution to 640x480 is only needed for em2800
devices.
This doesn't explain why it is not working, but i remember that tvtime doesn't
like to work with certain resolutions.
You should really test it with mplayer and send us the results.
--
Cheers,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fwd: Re: FM radio problem with HVR1120
Hi, ftape-jlc wrote: Hello, I didn't received any message about radio on HVR1120. I just want to know if the use /dev/radio0 is deprecated in v4l2 today. In the mails, I only read messages about video or TV. No, it is not deprecated. Did one user of the mailing list have tested actual v4l2 on /dev/radio0 ? Yes. It works with several devices. Maybe there's a bug at the radio entry for your board. The problem is to listen radio. With Linux, the command used is /usr/bin/radio -c /dev/radio0 in association with sox -t ossdsp -r 32000 -c 2 /dev/dsp1 -t ossdsp /dev/dsp to listen the sound. The result is an unstable frecuency. The station is not tuned. Stereo is permanently switching to mono. The 91.5MHz station is mixed permanently with other stations. This probably means that the GPIO setup for your board is wrong for radio. Only someone with a HVR1120 could fix it, since the GPIO's are board-specific. The better is if you could try to do it. It is not hard. Please take a look at: http://linuxtv.org/wiki/index.php/GPIO_pins You'll need to run the regspy.exe utility (part of Dscaler package), and check how the original driver sets the GPIO registers. Then edit them on your board entry, at saa78134-cards.c, recompile the driver and test. The better is to use the out-of-tree mercuiral tree: http://linuxtv.org/hg/v4l-dvb since it allows you to recompile and test without needing to replace your kernel. Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] em28xx: add Dikom DK300 hybrid USB tuner
andrea.amoros...@gmail.com wrote: I had to fix small merging conflicts. +.valid= EM28XX_BOARD_NOT_VALIDATED, Also, you tested the board, so, I'm removing the .valid tag. Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Want to help in MSI TV VOX USB 2.0
Carlos Jenkins wrote: Hi :) Thank again for the replies. Well, if it actually has a tuner, then it is unlikely that any existing board profile is going to help (ruling out the ability to just use a card=). Profile 5 is for this same card. Do you know what tuner it contains? Can you provide some hi-res photos of the internals of the device? Yes, I can :) http://www.cjenkins.net/files/msivoxusb2.0.png The tuner is LG/Innotek TALN-H200T. From Documentation/video4linux/CARDLIST.tuner: tuner=25 - LG PAL_I+FM (TAPC-I001D) tuner=26 - LG PAL_I (TAPC-I701D) tuner=27 - LG NTSC+FM (TPI8NSR01F) tuner=28 - LG PAL_BG+FM (TPI8PSB01D) tuner=29 - LG PAL_BG (TPI8PSB11D) tuner=37 - LG PAL (newer TAPC series) tuner=39 - LG NTSC (newer TAPC series) tuner=47 - LG NTSC (TAPE series) tuner=64 - LG TDVS-H06xF tuner=66 - LG TALN series Probably, tuner=66 will work better. So, you'll need to probe your card with modprobe em28xx card=5 tuner=66 Note: Mauro I'll test everything you said later and I'll post the result here. Ok. -- Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linuxtv-commits] [hg:v4l-dvb] af9015: backported to kernel 2.6.22
Terve,
Short question, would it be easier to add GOLDEN_RATIO_PRIME_32 to
compat.h ?
regards
Antti
On 02/07/2010 03:50 AM, Patch from Douglas Schilling Landgraf wrote:
The patch number 14160 was added via Douglas Schilling
Landgrafdougsl...@redhat.com
to http://linuxtv.org/hg/v4l-dvb master development tree.
Kernel patches in this development tree may be modified to be backward
compatible with older kernels. Compatibility modifications will be
removed before inclusion into the mainstream Kernel
If anyone has any objections, please let us know by sending a message to:
Linux Media Mailing Listlinux-media@vger.kernel.org
--
From: Douglas Schilling Landgrafdougsl...@redhat.com
af9015: backported to kernel 2.6.22
backport for hash - kernel 2.6.22
Priority: normal
Signed-off-by: Douglas Schilling Landgrafdougsl...@redhat.com
---
linux/drivers/media/dvb/dvb-usb/af9015.c | 37 +++
1 file changed, 37 insertions(+)
diff -r 7d09c32065a4 -r 8c0dbfae05ff linux/drivers/media/dvb/dvb-usb/af9015.c
--- a/linux/drivers/media/dvb/dvb-usb/af9015.c Fri Feb 05 16:18:29 2010 -0200
+++ b/linux/drivers/media/dvb/dvb-usb/af9015.c Sat Feb 06 23:44:20 2010 -0200
@@ -20,9 +20,11 @@
*Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
*
*/
+#if LINUX_VERSION_CODE= KERNEL_VERSION(2, 6, 22)
#includelinux/hash.h
+#endif
#include af9015.h
#include af9013.h
#include mt2060.h
@@ -558,15 +560,37 @@
return ret;
}
+#if LINUX_VERSION_CODE KERNEL_VERSION(2, 6, 22)
+static int af9015_eeprom_dump(struct dvb_usb_device *d)
+#else
/* hash (and dump) eeprom */
static int af9015_eeprom_hash(struct usb_device *udev)
+#endif
{
+#if LINUX_VERSION_CODE KERNEL_VERSION(2, 6, 22)
+ u8 reg, val;
+#else
static const unsigned int eeprom_size = 256;
unsigned int reg;
int ret;
u8 val, *eeprom;
struct req_t req = {READ_I2C, AF9015_I2C_EEPROM, 0, 0, 1, 1,val};
+#endif
+#if LINUX_VERSION_CODE KERNEL_VERSION(2, 6, 22)
+ for (reg = 0; ; reg++) {
+ if (reg % 16 == 0) {
+ if (reg)
+ deb_info(KERN_CONT \n);
+ deb_info(KERN_DEBUG %02x:, reg);
+ }
+ if (af9015_read_reg_i2c(d, AF9015_I2C_EEPROM, reg,val) == 0)
+ deb_info(KERN_CONT %02x, val);
+ else
+ deb_info(KERN_CONT --);
+ if (reg == 0xff)
+ break;
+#else
eeprom = kmalloc(eeprom_size, GFP_KERNEL);
if (eeprom == NULL)
return -ENOMEM;
@@ -577,8 +601,13 @@
if (ret)
goto free;
eeprom[reg] = val;
+#endif
}
+#if LINUX_VERSION_CODE KERNEL_VERSION(2, 6, 22)
+ deb_info(KERN_CONT \n);
+ return 0;
+#else
if (dvb_usb_af9015_debug 0x01)
print_hex_dump_bytes(, DUMP_PREFIX_OFFSET, eeprom,
eeprom_size);
@@ -597,6 +626,7 @@
free:
kfree(eeprom);
return ret;
+#endif
}
static int af9015_download_ir_table(struct dvb_usb_device *d)
@@ -873,10 +903,12 @@
if (ret)
goto error;
+#if LINUX_VERSION_CODE= KERNEL_VERSION(2, 6, 22)
ret = af9015_eeprom_hash(udev);
if (ret)
goto error;
+#endif
deb_info(%s: IR mode:%d\n, __func__, val);
for (i = 0; i af9015_properties_count; i++) {
if (val == AF9015_IR_MODE_DISABLED) {
@@ -1129,6 +1161,11 @@
deb_info(%s: init I2C\n, __func__);
ret = af9015_i2c_init(adap-dev);
+#if LINUX_VERSION_CODE KERNEL_VERSION(2, 6, 22)
+ ret = af9015_eeprom_dump(adap-dev);
+ if (ret)
+ return ret;
+#endif
} else {
/* select I2C adapter */
i2c_adap =state-i2c_adap;
---
Patch is available at:
http://linuxtv.org/hg/v4l-dvb/rev/8c0dbfae05fff3ee3ddacb0c9f1799b6f1815c2b
___
linuxtv-commits mailing list
linuxtv-comm...@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linuxtv-commits
--
http://palosaari.fi/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL] http://linuxtv.org/hg/~anttip/af9015/
Mauro, Please pull from http://linuxtv.org/hg/~anttip/af9015/ for the following: af9015: support for DigitalNow TinyTwin v2 af9015: support for Leadtek WinFast DTV2000DS af9015: A-Link DTU(m) remote autodetection af9015: MYGICTV U718 remote autodetection regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://linuxtv.org/hg/~anttip/af9015/
One patch more... On 02/11/2010 02:13 AM, Antti Palosaari wrote: Mauro, Please pull from http://linuxtv.org/hg/~anttip/af9015/ for the following: af901x: inform NXP TDA18218 tuner as know but not supported af9015: support for DigitalNow TinyTwin v2 af9015: support for Leadtek WinFast DTV2000DS af9015: A-Link DTU(m) remote autodetection af9015: MYGICTV U718 remote autodetection regards Antti Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] dvb-core: fix initialization of feeds list in demux filter (Was: Videotext application crashes the kernel due to DVB-demux patch)
Am Dienstag, den 09.02.2010, 09:38 +0100 schrieb Chicken Shack: Am Dienstag, den 09.02.2010, 01:53 +0100 schrieb hermann pitton: Am Montag, den 08.02.2010, 08:14 -0800 schrieb Linus Torvalds: On Mon, 8 Feb 2010, Chicken Shack wrote: This is a SCANDAL, not fun! This is SCANDALOUS! I agree that this whole thread has been totally inappropriate from beginning to end. The initial problem was, how to find such software producing that oops at all. Pure crap! Because, as I stated already, you are too lazy to read the context. Proofs: 1. http://www.spinics.net/lists/linux-media/msg15182.html This guy was compeletely ignored, although he announced a kernel bug / security risk. Neither is he banned somewhere, nor are there other ifs or whatevers to justify just ignoring him. Also the utmost insane Torvalds-scapegoat-theory dowes not work here at all. This guy reported a problem, and noone except me listened: Period! 2. http://www.spinics.net/lists/linux-media/msg15356.html This one the bums here could not ignore at all, because the noise around was already so loud that ignoring was no longer possible. MOST IMPORTANT: NONE of them had my overworked version. And I do not know to which one they were referring to. There is one at: 1. http://pluto.blackbone-ev.de/v1/AleVT%20mit%20DVB-T.html and there is one at: 2. http://packages.debian.org/sid/alevt BOTH are DVB compatible. So with both YOU CAN identify the kernel security risk / the oops. So as long as you do not know the facts, better shut up and stay quiet, stupid! There's no need to comment your spit-licking that follows. Everyone knows who you moron are by evaluating your stupid rant, the sum of self-invented lies. CS For the record. Uwe is right, the bug is already at the above link pluto.blackbone-ev.de coming with its own headers. It is for sure not in any Fedora and he asked only for DVB-S testers, IIRC. I'm sorry to have tested anything at all in such a crappy way ... 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: Fwd: Re: FM radio problem with HVR1120
Hi, Am Mittwoch, den 10.02.2010, 20:28 -0200 schrieb Mauro Carvalho Chehab: Hi, ftape-jlc wrote: Hello, I didn't received any message about radio on HVR1120. I just want to know if the use /dev/radio0 is deprecated in v4l2 today. In the mails, I only read messages about video or TV. No, it is not deprecated. Did one user of the mailing list have tested actual v4l2 on /dev/radio0 ? Yes. It works with several devices. Maybe there's a bug at the radio entry for your board. The problem is to listen radio. With Linux, the command used is /usr/bin/radio -c /dev/radio0 in association with sox -t ossdsp -r 32000 -c 2 /dev/dsp1 -t ossdsp /dev/dsp to listen the sound. The result is an unstable frecuency. The station is not tuned. Stereo is permanently switching to mono. The 91.5MHz station is mixed permanently with other stations. This probably means that the GPIO setup for your board is wrong for radio. Only someone with a HVR1120 could fix it, since the GPIO's are board-specific. The better is if you could try to do it. It is not hard. Please take a look at: http://linuxtv.org/wiki/index.php/GPIO_pins You'll need to run the regspy.exe utility (part of Dscaler package), and check how the original driver sets the GPIO registers. Then edit them on your board entry, at saa78134-cards.c, recompile the driver and test. The better is to use the out-of-tree mercuiral tree: http://linuxtv.org/hg/v4l-dvb since it allows you to recompile and test without needing to replace your kernel. Mauro, without looking at anything, everything above 1110 can have the newer tuners and analog demods and on the radio is ongoing work. We need to ask Mike for the latest status or try to look it up. I doubt you come further with the regspy stuff. 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
[PATCH] cxusb: Select all required frontend and tuner modules
cxusb uses the atbm8830 and lgs8gxx (not lgs8gl5) frontends and the max2165 tuner, so it needs to select them. Signed-off-by: Ben Hutchings b...@decadent.org.uk Cc: sta...@kernel.org --- drivers/media/dvb/dvb-usb/Kconfig |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/drivers/media/dvb/dvb-usb/Kconfig b/drivers/media/dvb/dvb-usb/Kconfig index 1b24989..465295b 100644 --- a/drivers/media/dvb/dvb-usb/Kconfig +++ b/drivers/media/dvb/dvb-usb/Kconfig @@ -112,11 +112,13 @@ config DVB_USB_CXUSB select DVB_MT352 if !DVB_FE_CUSTOMISE select DVB_ZL10353 if !DVB_FE_CUSTOMISE select DVB_DIB7000P if !DVB_FE_CUSTOMISE - select DVB_LGS8GL5 if !DVB_FE_CUSTOMISE select DVB_TUNER_DIB0070 if !DVB_FE_CUSTOMISE + select DVB_ATBM8830 if !DVB_FE_CUSTOMISE + select DVB_LGS8GXX if !DVB_FE_CUSTOMISE select MEDIA_TUNER_SIMPLE if !MEDIA_TUNER_CUSTOMISE select MEDIA_TUNER_XC2028 if !MEDIA_TUNER_CUSTOMISE select MEDIA_TUNER_MXL5005S if !MEDIA_TUNER_CUSTOMISE + select MEDIA_TUNER_MAX2165 if !MEDIA_TUNER_CUSTOMISE help Say Y here to support the Conexant USB2.0 hybrid reference design. Currently, only DVB and ATSC modes are supported, analog mode -- 1.6.6 -- 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/1] DVB: ngene, fix memset parameters
Jiri Slaby wrote:
Switch second and third memset parameter to stamp the length buffer bytes
by 0xff's, not 255 bytes by low 8 bits of Length.
Signed-off-by: Jiri Slaby jsl...@suse.cz
Cc: Matthias Benesch two...@freenet.de
Cc: Ralph Metzler r...@metzlerbros.de
Cc: Oliver Endriss o.endr...@gmx.de
Cc: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/dvb/ngene/ngene-core.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/media/dvb/ngene/ngene-core.c
b/drivers/media/dvb/ngene/ngene-core.c
index cb5982e..0150dfe 100644
--- a/drivers/media/dvb/ngene/ngene-core.c
+++ b/drivers/media/dvb/ngene/ngene-core.c
@@ -564,7 +564,7 @@ static void FillTSBuffer(void *Buffer, int Length, u32
Flags)
{
u32 *ptr = Buffer;
- memset(Buffer, Length, 0xff);
+ memset(Buffer, 0xff, Length);
while (Length 0) {
if (Flags DF_SWAP32)
*ptr = 0x471FFF10;
--
1.6.6.1
Acked-by: Oliver Endriss o.endr...@gmx.de
CU
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
[Patch/Resend] Kworld 315U remote support
This patch adds remote support for the Kworld 315U device
I have added the change for the IR_TYPE_NEC that Mauro suggested.
Note: I believe I got most of the mappings correct. Though the
source and shutdown button probably could be mapped to something
better.
To be done: Still need to get the Kworld analog patch resubmitted.
There are still some stuff I want to test with the analog patch before
I resubmit it. Hopefully this patch will work ok.
Please let me know if there are any issues applying the patch
Signed-off-by: Franklin Meng fmeng2...@yahoo.com
diff -r 28f5eca12bb0 linux/drivers/media/IR/ir-keymaps.c
--- a/linux/drivers/media/IR/ir-keymaps.c Sat Feb 06 23:49:31 2010 -0200
+++ b/linux/drivers/media/IR/ir-keymaps.c Wed Feb 10 21:43:49 2010 -0800
@@ -3501,3 +3501,53 @@
.size = ARRAY_SIZE(ir_codes_winfast_usbii_deluxe),
};
EXPORT_SYMBOL_GPL(ir_codes_winfast_usbii_deluxe_table);
+
+/* Kworld 315U
+*/
+static struct ir_scancode ir_codes_kworld_315u[] = {
+ { 0x6143, KEY_POWER },
+ { 0x6101, KEY_TUNER }, /* source */
+ { 0x610b, KEY_ZOOM },
+ { 0x6103, KEY_POWER2 }, /* shutdown */
+
+ { 0x6104, KEY_1 },
+ { 0x6108, KEY_2 },
+ { 0x6102, KEY_3 },
+ { 0x6109, KEY_CHANNELUP },
+
+ { 0x610f, KEY_4 },
+ { 0x6105, KEY_5 },
+ { 0x6106, KEY_6 },
+ { 0x6107, KEY_CHANNELDOWN },
+
+ { 0x610c, KEY_7 },
+ { 0x610d, KEY_8 },
+ { 0x610a, KEY_9 },
+ { 0x610e, KEY_VOLUMEUP },
+
+ { 0x6110, KEY_LAST },
+ { 0x6111, KEY_0 },
+ { 0x6112, KEY_ENTER },
+ { 0x6113, KEY_VOLUMEDOWN },
+
+ { 0x6114, KEY_RECORD },
+ { 0x6115, KEY_STOP },
+ { 0x6116, KEY_PLAY },
+ { 0x6117, KEY_MUTE },
+
+ { 0x6118, KEY_UP },
+ { 0x6119, KEY_DOWN },
+ { 0x611a, KEY_LEFT },
+ { 0x611b, KEY_RIGHT },
+
+ { 0x611c, KEY_RED },
+ { 0x611d, KEY_GREEN },
+ { 0x611e, KEY_YELLOW },
+ { 0x611f, KEY_BLUE },
+};
+struct ir_scancode_table ir_codes_kworld_315u_table = {
+ .scan = ir_codes_kworld_315u,
+ .size = ARRAY_SIZE(ir_codes_kworld_315u),
+ .ir_type = IR_TYPE_NEC,
+};
+EXPORT_SYMBOL_GPL(ir_codes_kworld_315u_table);
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] remove the country code for analog tv and radio
video :
use the V4L2_STD macros to select the proper audio setting.
radio :
add preemphasis ctr.
test it by the command:
v4l2-ctl -d /dev/radio0 --set-ctrl=pre_emphasis_settings=1
Signed-off-by: Huang Shijie shij...@gmail.com
---
drivers/media/video/tlg2300/pd-common.h |4 +-
drivers/media/video/tlg2300/pd-main.c | 36 --
drivers/media/video/tlg2300/pd-radio.c | 107 +--
drivers/media/video/tlg2300/pd-video.c | 59 +++--
4 files changed, 128 insertions(+), 78 deletions(-)
diff --git a/drivers/media/video/tlg2300/pd-common.h
b/drivers/media/video/tlg2300/pd-common.h
index 619fd00..ae9cb6c 100644
--- a/drivers/media/video/tlg2300/pd-common.h
+++ b/drivers/media/video/tlg2300/pd-common.h
@@ -118,6 +118,7 @@ struct radio_data {
__u32 fm_freq;
int users;
unsigned intis_radio_streaming;
+ int pre_emphasis;
struct video_device *fm_dev;
};
@@ -185,7 +186,6 @@ struct poseidon {
struct pd_dvb_adapter dvb_data; /* DVB */
u32 state;
- int country_code;
struct file *file_for_stream; /* the active stream*/
#ifdef CONFIG_PM
@@ -240,7 +240,6 @@ struct video_device *vdev_init(struct poseidon *, struct
video_device *);
int send_set_req(struct poseidon*, u8, s32, s32*);
int send_get_req(struct poseidon*, u8, s32, void*, s32*, s32);
s32 set_tuner_mode(struct poseidon*, unsigned char);
-enum tlg__analog_audio_standard get_audio_std(s32, s32);
/* bulk urb alloc/free */
int alloc_bulk_urbs_generic(struct urb **urb_array, int num,
@@ -252,7 +251,6 @@ void free_all_urb_generic(struct urb **urb_array, int num);
/* misc */
void poseidon_delete(struct kref *kref);
void destroy_video_device(struct video_device **v_dev);
-extern int country_code;
extern int debug_mode;
void set_debug_mode(struct video_device *vfd, int debug_mode);
diff --git a/drivers/media/video/tlg2300/pd-main.c
b/drivers/media/video/tlg2300/pd-main.c
index 6df9380..fdcc500 100644
--- a/drivers/media/video/tlg2300/pd-main.c
+++ b/drivers/media/video/tlg2300/pd-main.c
@@ -189,41 +189,6 @@ int set_tuner_mode(struct poseidon *pd, unsigned char mode)
return 0;
}
-enum tlg__analog_audio_standard get_audio_std(s32 mode, s32 country_code)
-{
- s32 nicam[] = {27, 32, 33, 34, 36, 44, 45, 46, 47, 48, 64,
- 65, 86, 351, 352, 353, 354, 358, 372, 852, 972};
- s32 btsc[] = {1, 52, 54, 55, 886};
- s32 eiaj[] = {81};
- s32 i;
-
- if (mode == TLG_MODE_FM_RADIO) {
- if (country_code == 1)
- return TLG_TUNE_ASTD_FM_US;
- else
- return TLG_TUNE_ASTD_FM_EUR;
- } else if (mode == TLG_MODE_ANALOG_TV_UNCOMP) {
- for (i = 0; i sizeof(nicam) / sizeof(s32); i++) {
- if (country_code == nicam[i])
- return TLG_TUNE_ASTD_NICAM;
- }
-
- for (i = 0; i sizeof(btsc) / sizeof(s32); i++) {
- if (country_code == btsc[i])
- return TLG_TUNE_ASTD_BTSC;
- }
-
- for (i = 0; i sizeof(eiaj) / sizeof(s32); i++) {
- if (country_code == eiaj[i])
- return TLG_TUNE_ASTD_EIAJ;
- }
-
- return TLG_TUNE_ASTD_A2;
- } else {
- return TLG_TUNE_ASTD_NONE;
- }
-}
-
void poseidon_delete(struct kref *kref)
{
struct poseidon *pd = container_of(kref, struct poseidon, kref);
@@ -462,7 +427,6 @@ static int poseidon_probe(struct usb_interface *interface,
struct device *dev = interface-dev;
logpm(pd);
- pd-country_code = 86;
mutex_init(pd-lock);
/* register v4l2 device */
diff --git a/drivers/media/video/tlg2300/pd-radio.c
b/drivers/media/video/tlg2300/pd-radio.c
index bdbb0c1..755766b 100644
--- a/drivers/media/video/tlg2300/pd-radio.c
+++ b/drivers/media/video/tlg2300/pd-radio.c
@@ -22,9 +22,16 @@ static int poseidon_fm_open(struct file *filp);
#define TUNER_FREQ_MIN_FM 7600
#define TUNER_FREQ_MAX_FM 10800
+#define MAX_PREEMPHASIS (V4L2_PREEMPHASIS_75_uS + 1)
+static int preemphasis[MAX_PREEMPHASIS] = {
+ TLG_TUNE_ASTD_NONE, /* V4L2_PREEMPHASIS_DISABLED */
+ TLG_TUNE_ASTD_FM_EUR, /* V4L2_PREEMPHASIS_50_uS*/
+ TLG_TUNE_ASTD_FM_US, /* V4L2_PREEMPHASIS_75_uS*/
+};
+
static int poseidon_check_mode_radio(struct poseidon *p)
{
- int ret, radiomode;
+ int ret;
u32 status;
set_current_state(TASK_INTERRUPTIBLE);
@@ -38,8 +45,8 @@ static int poseidon_check_mode_radio(struct poseidon *p)
goto out;
ret = send_set_req(p, SGNL_SRC_SEL,
[PATCH 2/2] modify the document
remove the the country code section. Signed-off-by: Huang Shijie shij...@gmail.com --- Documentation/video4linux/README.tlg2300 | 198 + 1 files changed, 7 insertions(+), 191 deletions(-) diff --git a/Documentation/video4linux/README.tlg2300 b/Documentation/video4linux/README.tlg2300 index 82417db..416ccb9 100644 --- a/Documentation/video4linux/README.tlg2300 +++ b/Documentation/video4linux/README.tlg2300 @@ -37,195 +37,11 @@ TESTED APPLICATIONS: --- KNOWN PROBLEMS: +about preemphasis: + You can set the preemphasis for radio by the following command: + #v4l2-ctl -d /dev/radio0 --set-ctrl=pre_emphasis_settings=1 + + pre_emphasis_settings=1 means that you select the 50us. If you want + to select the 75us, please use pre_emphasis_settings=2 + -country code - - The firmware of the chip needs the country code to determine - the stardards of video and audio when it runs for analog TV or radio. - The DVB-T does not need the country code. - - So you must set the country-code correctly. The V4L2 does not have - the interface,the driver has to provide a parameter `country_code'. - - You could set the coutry code in two ways, take USA as example - (The USA's country code is 1): - - [1] add the following line in /etc/modprobe.conf before you insert the - card into USB hub's port : - poseidon country_code=1 - - [2] You can also modify the parameter at runtime (before you run the - application such as VLC) - #echo 1 /sys/module/poseidon/parameter/country_code - - The known country codes show below: - country code : country - 93 Afghanistan - 355 Albania - 213 Algeria - 684 American Samoa - 376 Andorra - 244 Angola - 54 Argentina - 374 Armenia - 61 Australia - 43 Austria - 994 Azerbaijan - 973 Bahrain - 880 Bangladesh - 375 Belarus - 32 Belgium - 501 Belize - 229 Benin - 591 Bolivia - 387 Bosnia and Herzegovina - 267 Botswana - 55 Brazil - 673 Brunei Darussalam - 359 Bulgalia - 226 Burkina Faso - 257 Burundi - 237 Cameroon - 1 Canada - 236 Central African Republic - 235 Chad - 56 Chile - 86 China - 57 Colombia - 242 Congo - 243 Congo, Dem. Rep. of - 506 Costa Rica - 385 Croatia - 53 Cuba or Guantanamo Bay - 357 Cyprus - 420 Czech Republic - 45 Denmark - 246 Diego Garcia - 253 Djibouti - 593 Ecuador - 20 Egypt - 503 El Salvador - 240 Equatorial Guinea - 372 Estonia - 251 Ethiopia - 358 Finland - 33 France - 594 French Guiana - 689 French Polynesia - 241 Gabonese Republic - 220 Gambia - 995 Georgia - 49 Germany - 233 Ghana - 350 Gibraltar - 30 Greece - 299 Greenland - 671 Guam - 502 Guatemala - 592 Guyana - 509 Haiti - 504 Honduras - 852 Hong Kong SAR, China - 36 Hungary - 354 Iceland - 91 India - 98 Iran - 964 Iraq - 353 Ireland - 972 Israel - 39 Italy or Vatican City - 225 Ivory Coast - 81 Japan - 962 Jordan - 7 Kazakhstan or Kyrgyzstan - 254 Kenya - 686 Kiribati - 965 Kuwait - 856 Laos - 371 Latvia - 961 Lebanon - 266 Lesotho - 231 Liberia - 218 Libya - 41 Liechtenstein or Switzerland - 370 Lithuania - 352 Luxembourg - 853 Macau SAR, China - 261 Madagascar - 60 Malaysia - 960 Maldives -
