Re: S4 hang with uvcvideo causing Unlink after no-IRQ? Controller is probably using the wrong IRQ.
On 21:26 Fri 06 Mar 2009, Greg KH wrote: On Fri, Mar 06, 2009 at 11:11:22AM -0800, Brandon Philips wrote: Hello- When an UVC device is open and a S4 is attempted the thaw hangs (see the stack below). I don't see what the UVC driver is doing wrong to cause this to happen though. I don't think this is a uvc driver issue, it looks like all you are trying to do is a usb control message when things hang. Indeed. When I was poking at this I tried to supress the control message coming out of the uvcvideo driver after the suspend was issued to see what would happen and the control messages after the resume locked up instead. Eh. SysRq : Show Blocked State taskPC stack pid father bash D 880078524c94 0 1 0 88007bb9fae8 0082 0292 88003747d140 80816f00 80816f00 88007bb9c040 88007bb9c3b8 0292 80630350 88003754d000 880078524c80 Call Trace: [8036d8a8] ? kobject_put+0x47/0x4b [802253a5] ? default_spin_lock_flags+0x17/0x1a [a011ae2b] usb_kill_urb+0x9d/0xbd [usbcore] [80258ca4] ? autoremove_wake_function+0x0/0x38 [a011c3a3] usb_start_wait_urb+0xd9/0x1c2 [usbcore] [a011b52c] ? usb_init_urb+0x22/0x33 [usbcore] [a011c6c8] usb_control_msg+0x114/0x15b [usbcore] [a03433e7] uvc_set_video_ctrl+0x134/0x184 [uvcvideo] [a0343442] uvc_commit_video+0xb/0xd [uvcvideo] [a0343504] uvc_video_resume+0x1e/0x58 [uvcvideo] [a033e112] __uvc_resume+0x99/0xa1 [uvcvideo] [a033e135] uvc_resume+0xb/0xd [uvcvideo] [a011dce6] usb_resume_interface+0xdf/0x165 [usbcore] [a011e1ee] usb_resume_both+0x102/0x128 [usbcore] [a011ed37] usb_external_resume_device+0x33/0x6e [usbcore] [a011ed8d] usb_resume+0x1b/0x1d [usbcore] [a0113178] usb_dev_thaw+0xe/0x10 [usbcore] [803fb100] pm_op+0xa4/0xe5 [803fbd02] device_resume+0x137/0x47b [8026e4e9] hibernation_snapshot+0x1ba/0x1fa [8026e5ec] hibernate+0xc3/0x1a1 [8026d15a] state_store+0x59/0xd8 [8036d69f] kobj_attr_store+0x17/0x19 [8031d04b] sysfs_write_file+0xdf/0x114 [802cc8bd] vfs_write+0xae/0x157 [802cca2a] sys_write+0x47/0x70 [8020c42a] system_call_fastpath+0x16/0x1b That's the control message timing out and trying to reap the urb. Yes. And like I said above it seems that after the suspend any usb_control_msg coming from the driver hangs no matter if it is during the suspend, thaw or resume. But the problem is the khubd is asleep, from your log file: khubd D 0 255 2 880037509d80 0046 88007864ba80 8088fcf8 80816f00 80816f00 8800375b0380 8800375b06f8 80816f00 88007bb9c040 8800375b0380 8800375b06f8 Call Trace: [802253a5] ? default_spin_lock_flags+0x17/0x1a [8025e7a9] refrigerator+0x170/0x1cf [a01187ab] hub_thread+0x1370/0x13bd [usbcore] [8020a7c2] ? __switch_to+0xd4/0x4b3 [80258ca4] ? autoremove_wake_function+0x0/0x38 [a011743b] ? hub_thread+0x0/0x13bd [usbcore] [8025890b] kthread+0x49/0x76 [8020d69a] child_rip+0xa/0x20 [802588c2] ? kthread+0x0/0x76 [8020d690] ? child_rip+0x0/0x20 udevd is also stuck in the refrigerator, which seems wierd as well. a.out is also stuck, is that your test program? Yes, a.out is the test program. 8-) It looks like things die right after this message: ehci_hcd :00:1d.7: Unlink after no-IRQ? Controller is probably using the wrong IRQ. Cheers, Brandon -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] API changes for V4L2_MPEG_SLICED_VBI_FMT_IVTV definitions (Re: [PULL] http://linuxtv.org/hg/~awalls/cx18)
On Saturday 07 March 2009 02:31:41 Andy Walls wrote:
On Fri, 2009-03-06 at 15:41 +0100, Hans Verkuil wrote:
On Friday 06 March 2009 04:39:34 Andy Walls wrote:
Yes, they should be exported to userspace as well, so apps like
MythTV don't have to keep their own copies as well. I'm going to
work on a V4L2 spec change to add structures and defines for the
packets indicated by V4L2_MPEG_STREAM_VBI_FMT_IVTV, and then add it
to some API header. Maybe in linux/include/linux/videodev2.h with all
the other VBI data formats.
Unless someone really disagrees.
These VBI defines should be moved to videodev2.h. In hindsight this
should never have been added to ivtv.h. Originally only ivtv used this,
but now cx18 does as well, and in theory any MPEG encoder device can
use it.
Hans, Mauro, and whoever:
Before I get too far down the road of writing the spec modifications and
perhaps modifying drivers, in the diff below:
1. Are the modifications to the headers acceptable?
2. Are they correct? (I *think* they are.)
Acked-by: Hans Verkuil hverk...@xs4all.nl
Very nice. I was also toying with the idea to rename 'IVTV' in these defines
to something different, but that makes too much of a mess. I think it is
sufficient to add a sentence to the spec along the lines of:
This format was first introduced in the ivtv driver, hence the use of IVTV
in these defines. It is however not limited to the ivtv driver, any MPEG
encoder can use it.
And I think that it also doesn't hurt if some of my explanations from my
earlier email are added to the spec as well. The format looks really weird
if you do not understand the PVR350 (cx23415) limitation.
Regards,
Hans
Regards,
Andy
diff -r 5361470b10f4 linux/include/linux/ivtv.h
--- a/linux/include/linux/ivtv.h Sun Mar 01 21:10:07 2009 -0500
+++ b/linux/include/linux/ivtv.h Fri Mar 06 20:27:20 2009 -0500
@@ -60,10 +60,10 @@
#define IVTV_IOC_DMA_FRAME _IOW ('V', BASE_VIDIOC_PRIVATE+0, struct
ivtv_dma_frame)
-/* These are the VBI types as they appear in the embedded VBI private
packets. */ -#define IVTV_SLICED_TYPE_TELETEXT_B (1)
-#define IVTV_SLICED_TYPE_CAPTION_525(4)
-#define IVTV_SLICED_TYPE_WSS_625(5)
-#define IVTV_SLICED_TYPE_VPS(7)
+/* Deprecated defines: applications should use the defines from
videodev2.h */ +#define IVTV_SLICED_TYPE_TELETEXT_B
V4L2_MPEG_VBI_IVTV_TELETEXT_B +#define IVTV_SLICED_TYPE_CAPTION_525
V4L2_MPEG_VBI_IVTV_CAPTION_525 +#define IVTV_SLICED_TYPE_WSS_625
V4L2_MPEG_VBI_IVTV_WSS_625 +#define IVTV_SLICED_TYPE_VPS
V4L2_MPEG_VBI_IVTV_VPS
#endif /* _LINUX_IVTV_H */
diff -r 5361470b10f4 linux/include/linux/videodev2.h
--- a/linux/include/linux/videodev2.h Sun Mar 01 21:10:07 2009 -0500
+++ b/linux/include/linux/videodev2.h Fri Mar 06 20:27:20 2009 -0500
@@ -1348,6 +1348,53 @@
};
/*
+ * Sliced VBI data inserted into MPEG Streams
+ */
+
+/*
+ * V4L2_MPEG_STREAM_VBI_FMT_IVTV:
+ *
+ * Structure of payload contained in an MPEG 2 Private Stream 1 PES
Packet in an + * MPEG-2 Program Pack that contains
V4L2_MPEG_STREAM_VBI_FMT_IVTV Sliced VBI + * data
+ *
+ * Note, the MPEG-2 Program Pack and Private Stream 1 PES packet header
+ * definitions are not included here. See the MPEG-2 specifications for
details + * on these headers.
+ */
+
+/* Line type IDs */
+#define V4L2_MPEG_VBI_IVTV_TELETEXT_B (1)
+#define V4L2_MPEG_VBI_IVTV_CAPTION_525(4)
+#define V4L2_MPEG_VBI_IVTV_WSS_625(5)
+#define V4L2_MPEG_VBI_IVTV_VPS(7)
+
+struct v4l2_mpeg_vbi_itv0_line {
+ __u8 id;/* One of V4L2_MPEG_VBI_IVTV_* above */
+ __u8 data[42]; /* Sliced VBI data for the line */
+} __attribute__ ((packed));
+
+struct v4l2_mpeg_vbi_itv0 {
+ __u32 linemask[2]; /* Bitmasks of which VBI service lines are present
*/ + struct v4l2_mpeg_vbi_itv0_line line[35];
+} __attribute__ ((packed));
+
+struct v4l2_mpeg_vbi_ITV0 {
+ struct v4l2_mpeg_vbi_itv0_line line[36];
+} __attribute__ ((packed));
+
+#define V4L2_MPEG_VBI_IVTV_MAGIC0itv0
+#define V4L2_MPEG_VBI_IVTV_MAGIC1ITV0
+
+struct v4l2_mpeg_vbi_fmt_ivtv {
+ __u8 magic[4];
+ union {
+ struct v4l2_mpeg_vbi_itv0 itv0;
+ struct v4l2_mpeg_vbi_ITV0 ITV0;
+ };
+} __attribute__ ((packed));
+
+/*
* A G G R E G A T E S T R U C T U R E S
*/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: saa7134 and RDS
On Saturday 07 March 2009 02:55:06 Hans J. Koch wrote: On Thu, Mar 05, 2009 at 05:36:44PM +0100, Hans Verkuil wrote: On Thursday 05 March 2009 13:07:10 Hans Verkuil wrote: Hi Hans I build fresh video4linux with your patch and my config for our cards. In a dmesg i see : found RDS decoder. cat /dev/radio0 give me some slow junk data. Is this RDS data?? Have you any tools for testing RDS? I try build rdsd from Hans J. Koch, but build crashed with: rdshandler.cpp: In member function âvoid std::RDShandler::delete_client(std::RDSclient*)â: rdshandler.cpp:363: error: no matching function for call to âfind(__gnu_cxx::__normal_iteratorstd::RDSclient**, std::vectorstd::RDSclient*, std::allocatorstd::RDSclient* , __gnu_cxx::__normal_iteratorstd::RDSclient**, std::vectorstd::RDSclient*, std::allocatorstd::RDSclient* , std::RDSclient*)â Ah yes, that's right. I had to hack the C++ source to make this compile. I'll see if I can post a patch for this tonight. Attached is the diff that makes rdsd compile on my system. Great, thanks! The problem is, I really haven't got the time for RDS anymore. I simply cannot test your patch and check it in. From your previous contributions I know you as a competent and trustworthy v4l developer and would give you write access to the repository. Interested? Erm, not really. When the API is finalized I want to make some sort of a simple reference utility/library for this and add it to v4l-dvb. To be honest, I think having a daemon just complicates matters unnecessarily. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: saa7134 and RDS
Hi I build rdsd. But can't start. See log: Fri Mar 6 03:44:20 2009 RDS handler initialized. Fri Mar 6 03:44:20 2009 Added source definition: Beholder M6 Exra Fri Mar 6 03:44:20 2009 RDS sources setup OK. Fri Mar 6 03:44:20 2009 Unix domain socket created and listening. Fri Mar 6 03:44:20 2009 TCP/IP socket created and listening. Fri Mar 6 03:44:20 2009 Using V4L2 for Beholder M6 Exra Fri Mar 6 03:44:20 2009 open_sources() failed. Fri Mar 6 03:44:20 2009 rdsd terminating with error code 13 With my best regards, Dmitry. On Saturday 07 March 2009 02:55:06 Hans J. Koch wrote: On Thu, Mar 05, 2009 at 05:36:44PM +0100, Hans Verkuil wrote: On Thursday 05 March 2009 13:07:10 Hans Verkuil wrote: Hi Hans I build fresh video4linux with your patch and my config for our cards. In a dmesg i see : found RDS decoder. cat /dev/radio0 give me some slow junk data. Is this RDS data?? Have you any tools for testing RDS? I try build rdsd from Hans J. Koch, but build crashed with: rdshandler.cpp: In member function âvoid std::RDShandler::delete_client(std::RDSclient*)â: rdshandler.cpp:363: error: no matching function for call to âfind(__gnu_cxx::__normal_iteratorstd::RDSclient**, std::vectorstd::RDSclient*, std::allocatorstd::RDSclient* , __gnu_cxx::__normal_iteratorstd::RDSclient**, std::vectorstd::RDSclient*, std::allocatorstd::RDSclient* , std::RDSclient*)â Ah yes, that's right. I had to hack the C++ source to make this compile. I'll see if I can post a patch for this tonight. Attached is the diff that makes rdsd compile on my system. Great, thanks! The problem is, I really haven't got the time for RDS anymore. I simply cannot test your patch and check it in. From your previous contributions I know you as a competent and trustworthy v4l developer and would give you write access to the repository. Interested? Erm, not really. When the API is finalized I want to make some sort of a simple reference utility/library for this and add it to v4l-dvb. To be honest, I think having a daemon just complicates matters unnecessarily. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: saa7134 and RDS
On Saturday 07 March 2009 10:02:24 Dmitri Belimov wrote: Hi I build rdsd. But can't start. See log: Fri Mar 6 03:44:20 2009 RDS handler initialized. Fri Mar 6 03:44:20 2009 Added source definition: Beholder M6 Exra Fri Mar 6 03:44:20 2009 RDS sources setup OK. Fri Mar 6 03:44:20 2009 Unix domain socket created and listening. Fri Mar 6 03:44:20 2009 TCP/IP socket created and listening. Fri Mar 6 03:44:20 2009 Using V4L2 for Beholder M6 Exra Fri Mar 6 03:44:20 2009 open_sources() failed. Fri Mar 6 03:44:20 2009 rdsd terminating with error code 13 With my best regards, Dmitry. Did you setup the /etc/rdsd.conf file correctly? Here is mine: $ cat /etc/rdsd.conf [global] unix-socket = /var/tmp/rdsd.sock tcpip-port = 4321 logfile = /var/tmp/rdsd.log pidfile = /var/tmp/rdsd.pid console-log = yes file-log = yes loglevel = 5 [source] name = Terratec PCI card path = /dev/radio0 type = radiodev After setting up this file I run 'rdsd'. With rdsquery -f you can set the frequency in khz. Then run rdsquery -t \ rxfre,rxsig,rflags,picode,ptype,pname,locdt,utcdt,rtxt,lrtxt,tmc,aflist -c0 and watch the rds data appear. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] zoran: Drop the lock_norm module parameter
The lock_norm module parameter doesn't look terribly useful. If you
don't want to change the norm, just don't change it. As a matter of
fact, no other v4l driver has such a parameter.
Signed-off-by: Jean Delvare kh...@linux-fr.org
Cc: Trent Piepho xy...@speakeasy.org
Cc: Hans Verkuil hverk...@xs4all.nl
---
linux/Documentation/video4linux/Zoran |3 +--
linux/drivers/media/video/zoran/zoran_driver.c | 20
2 files changed, 1 insertion(+), 22 deletions(-)
--- v4l-dvb-zoran.orig/linux/Documentation/video4linux/Zoran2009-02-20
09:42:36.0 +0100
+++ v4l-dvb-zoran/linux/Documentation/video4linux/Zoran 2009-02-20
09:45:42.0 +0100
@@ -401,8 +401,7 @@ Additional notes for software developers
first set the correct norm. Well, it seems logically correct: TV
standard is more constant for current country than geometry
settings of a variety of TV capture cards which may work in ITU or
- square pixel format. Remember that users now can lock the norm to
- avoid any ambiguity.
+ square pixel format.
--
Please note that lavplay/lavrec are also included in the MJPEG-tools
(http://mjpeg.sf.net/).
--- v4l-dvb-zoran.orig/linux/drivers/media/video/zoran/zoran_driver.c
2009-02-20 09:42:47.0 +0100
+++ v4l-dvb-zoran/linux/drivers/media/video/zoran/zoran_driver.c
2009-02-20 09:45:42.0 +0100
@@ -163,10 +163,6 @@ const struct zoran_format zoran_formats[
};
#define NUM_FORMATS ARRAY_SIZE(zoran_formats)
-static int lock_norm; /* 0 = default 1 = Don't change TV standard (norm) */
-module_param(lock_norm, int, 0644);
-MODULE_PARM_DESC(lock_norm, Prevent norm changes (1 = ignore, 1 = fail));
-
/* small helper function for calculating buffersizes for v4l2
* we calculate the nearest higher power-of-two, which
* will be the recommended buffersize */
@@ -1497,22 +1493,6 @@ zoran_set_norm (struct zoran *zr,
return -EBUSY;
}
- if (lock_norm norm != zr-norm) {
- if (lock_norm 1) {
- dprintk(1,
- KERN_WARNING
- %s: set_norm() - TV standard is locked, can
not switch norm\n,
- ZR_DEVNAME(zr));
- return -EPERM;
- } else {
- dprintk(1,
- KERN_WARNING
- %s: set_norm() - TV standard is locked, norm
was not changed\n,
- ZR_DEVNAME(zr));
- norm = zr-norm;
- }
- }
-
if (!(norm zr-card.norms)) {
dprintk(1,
KERN_ERR %s: set_norm() - unsupported norm %llx\n,
--
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
[PATCH] zoran: Don't frighten users with failed buffer allocation
kmalloc() can fail for large video buffers. By default the kernel
complains loudly about allocation failures, but we don't want to
frighten the user, so ask kmalloc() to keep quiet on such failures.
Signed-off-by: Jean Delvare kh...@linux-fr.org
Cc: Trent Piepho xy...@speakeasy.org
Cc: Hans Verkuil hverk...@xs4all.nl
---
linux/drivers/media/video/zoran/zoran_driver.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- v4l-dvb.orig/linux/drivers/media/video/zoran/zoran_driver.c 2009-03-02
11:19:20.0 +0100
+++ v4l-dvb/linux/drivers/media/video/zoran/zoran_driver.c 2009-03-02
11:19:21.0 +0100
@@ -212,7 +212,8 @@ v4l_fbuffer_alloc (struct file *file)
ZR_DEVNAME(zr), i);
//udelay(20);
- mem = kmalloc(fh-v4l_buffers.buffer_size, GFP_KERNEL);
+ mem = kmalloc(fh-v4l_buffers.buffer_size,
+ GFP_KERNEL | __GFP_NOWARN);
if (!mem) {
dprintk(1,
KERN_ERR
--
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: [PULL] http://udev.netup.ru/hg/v4l-dvb-netup
On 7 марта 2009, Igor M. Liplianin liplia...@tut.by wrote: On Sat, 7 Mar 2009, Igor M. Liplianin wrote: 01/01: stv0900: delete debug messages not related to stv0900 tuning algorythm http://udev.netup.ru/hg/v4l-dvb-netup?cmd=changeset;node=c79e4df8a4c2 BTW, This will conflict with the changeset Hans just posted that fixes the casts in those same dprintk()s. Probably best to drop http://www.linuxtv.org/hg/~hverkuil/v4l-dvb/rev/9d20f27a1f78 -- 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 One way or another it is not very important. But let me explain my poin of view. My first intention was to correct it simply, but after fresh look I realized, that the same information printed many times. Debug was needed for me on earlier stages, when I wanted to have one internal structure per chip, not per demod. I've made it and don't see much sence in debugging it now. Sources is too big already. -- Igor M. Liplianin Microsoft Windows Free Zone - Linux used for all Computing Tasks -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] cx88: Prevent general protection fault on rmmod
When unloading the cx8800 driver I sometimes get a general protection
fault. Analysis revealed a race in cx88_ir_stop(). It can be solved by
using a delayed work instead of a timer for infrared input polling.
Signed-off-by: Jean Delvare kh...@linux-fr.org
---
Thanks to Trent's compatibility patches, we can go without the bunch of
#ifdef's my initial patch had.
linux/drivers/media/video/cx88/cx88-input.c | 27 ---
1 file changed, 8 insertions(+), 19 deletions(-)
--- v4l-dvb.orig/linux/drivers/media/video/cx88/cx88-input.c2009-03-05
10:36:23.0 +0100
+++ v4l-dvb/linux/drivers/media/video/cx88/cx88-input.c 2009-03-06
13:59:56.0 +0100
@@ -49,8 +49,7 @@ struct cx88_IR {
/* poll external decoder */
int polling;
- struct work_struct work;
- struct timer_list timer;
+ struct delayed_work work;
u32 gpio_addr;
u32 last_gpio;
u32 mask_keycode;
@@ -144,13 +143,6 @@ static void cx88_ir_handle_key(struct cx
}
}
-static void ir_timer(unsigned long data)
-{
- struct cx88_IR *ir = (struct cx88_IR *)data;
-
- schedule_work(ir-work);
-}
-
#if LINUX_VERSION_CODE KERNEL_VERSION(2,6,20)
static void cx88_ir_work(void *data)
#else
@@ -160,23 +152,22 @@ static void cx88_ir_work(struct work_str
#if LINUX_VERSION_CODE KERNEL_VERSION(2,6,20)
struct cx88_IR *ir = data;
#else
- struct cx88_IR *ir = container_of(work, struct cx88_IR, work);
+ struct cx88_IR *ir = container_of(work, struct cx88_IR, work.work);
#endif
cx88_ir_handle_key(ir);
- mod_timer(ir-timer, jiffies + msecs_to_jiffies(ir-polling));
+ schedule_delayed_work(ir-work, msecs_to_jiffies(ir-polling));
}
void cx88_ir_start(struct cx88_core *core, struct cx88_IR *ir)
{
if (ir-polling) {
- setup_timer(ir-timer, ir_timer, (unsigned long)ir);
#if LINUX_VERSION_CODE KERNEL_VERSION(2,6,20)
- INIT_WORK(ir-work, cx88_ir_work, ir);
+ INIT_DELAYED_WORK(ir-work, cx88_ir_work, ir);
#else
- INIT_WORK(ir-work, cx88_ir_work);
+ INIT_DELAYED_WORK(ir-work, cx88_ir_work);
#endif
- schedule_work(ir-work);
+ schedule_delayed_work(ir-work, 0);
}
if (ir-sampling) {
core-pci_irqmask |= PCI_INT_IR_SMPINT;
@@ -192,10 +183,8 @@ void cx88_ir_stop(struct cx88_core *core
core-pci_irqmask = ~PCI_INT_IR_SMPINT;
}
- if (ir-polling) {
- del_timer_sync(ir-timer);
- flush_scheduled_work();
- }
+ if (ir-polling)
+ cancel_delayed_work_sync(ir-work);
}
/* -- */
--
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
[PATCH] em28xx: Prevent general protection fault on rmmod
The removal of the timer which polls the infrared input is racy.
Replacing the timer with a delayed work solves the problem.
Signed-off-by: Jean Delvare kh...@linux-fr.org
Cc: Devin Heitmueller devin.heitmuel...@gmail.com
---
linux/drivers/media/video/em28xx/em28xx-input.c | 24 ++-
1 file changed, 7 insertions(+), 17 deletions(-)
--- v4l-dvb.orig/linux/drivers/media/video/em28xx/em28xx-input.c
2009-03-06 13:59:37.0 +0100
+++ v4l-dvb/linux/drivers/media/video/em28xx/em28xx-input.c 2009-03-06
14:02:35.0 +0100
@@ -69,8 +69,7 @@ struct em28xx_IR {
/* poll external decoder */
int polling;
- struct work_struct work;
- struct timer_list timer;
+ struct delayed_work work;
unsigned int last_toggle:1;
unsigned int last_readcount;
unsigned int repeat_interval;
@@ -298,13 +297,6 @@ static void em28xx_ir_handle_key(struct
return;
}
-static void ir_timer(unsigned long data)
-{
- struct em28xx_IR *ir = (struct em28xx_IR *)data;
-
- schedule_work(ir-work);
-}
-
#if LINUX_VERSION_CODE KERNEL_VERSION(2, 6, 20)
static void em28xx_ir_work(void *data)
#else
@@ -314,28 +306,26 @@ static void em28xx_ir_work(struct work_s
#if LINUX_VERSION_CODE KERNEL_VERSION(2, 6, 20)
struct em28xx_IR *ir = data;
#else
- struct em28xx_IR *ir = container_of(work, struct em28xx_IR, work);
+ struct em28xx_IR *ir = container_of(work, struct em28xx_IR, work.work);
#endif
em28xx_ir_handle_key(ir);
- mod_timer(ir-timer, jiffies + msecs_to_jiffies(ir-polling));
+ schedule_delayed_work(ir-work, msecs_to_jiffies(ir-polling));
}
static void em28xx_ir_start(struct em28xx_IR *ir)
{
- setup_timer(ir-timer, ir_timer, (unsigned long)ir);
#if LINUX_VERSION_CODE KERNEL_VERSION(2, 6, 20)
- INIT_WORK(ir-work, em28xx_ir_work, ir);
+ INIT_DELAYED_WORK(ir-work, em28xx_ir_work, ir);
#else
- INIT_WORK(ir-work, em28xx_ir_work);
+ INIT_DELAYED_WORK(ir-work, em28xx_ir_work);
#endif
- schedule_work(ir-work);
+ schedule_delayed_work(ir-work, 0);
}
static void em28xx_ir_stop(struct em28xx_IR *ir)
{
- del_timer_sync(ir-timer);
- flush_scheduled_work();
+ cancel_delayed_work_sync(ir-work);
}
int em28xx_ir_init(struct em28xx *dev)
--
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
[PATCH] ir-kbd-i2c: Prevent general protection fault on rmmod
The removal of the timer which polls the infrared input is racy.
Replacing the timer with a delayed work solves the problem.
Signed-off-by: Jean Delvare kh...@linux-fr.org
---
linux/drivers/media/video/ir-kbd-i2c.c | 22 ++
linux/include/media/ir-kbd-i2c.h |3 +--
2 files changed, 7 insertions(+), 18 deletions(-)
--- v4l-dvb.orig/linux/drivers/media/video/ir-kbd-i2c.c 2009-03-06
13:59:38.0 +0100
+++ v4l-dvb/linux/drivers/media/video/ir-kbd-i2c.c 2009-03-06
14:02:17.0 +0100
@@ -280,12 +280,6 @@ static void ir_key_poll(struct IR_i2c *i
}
}
-static void ir_timer(unsigned long data)
-{
- struct IR_i2c *ir = (struct IR_i2c*)data;
- schedule_work(ir-work);
-}
-
#if LINUX_VERSION_CODE KERNEL_VERSION(2,6,20)
static void ir_work(void *data)
#else
@@ -295,7 +289,7 @@ static void ir_work(struct work_struct *
#if LINUX_VERSION_CODE KERNEL_VERSION(2,6,20)
struct IR_i2c *ir = data;
#else
- struct IR_i2c *ir = container_of(work, struct IR_i2c, work);
+ struct IR_i2c *ir = container_of(work, struct IR_i2c, work.work);
#endif
int polling_interval = 100;
@@ -305,7 +299,7 @@ static void ir_work(struct work_struct *
polling_interval = 50;
ir_key_poll(ir);
- mod_timer(ir-timer, jiffies + msecs_to_jiffies(polling_interval));
+ schedule_delayed_work(ir-work, msecs_to_jiffies(polling_interval));
}
/* --- */
@@ -462,14 +456,11 @@ static int ir_attach(struct i2c_adapter
/* start polling via eventd */
#if LINUX_VERSION_CODE KERNEL_VERSION(2,6,20)
- INIT_WORK(ir-work, ir_work, ir);
+ INIT_DELAYED_WORK(ir-work, ir_work, ir);
#else
- INIT_WORK(ir-work, ir_work);
+ INIT_DELAYED_WORK(ir-work, ir_work);
#endif
- init_timer(ir-timer);
- ir-timer.function = ir_timer;
- ir-timer.data = (unsigned long)ir;
- schedule_work(ir-work);
+ schedule_delayed_work(ir-work, 0);
return 0;
@@ -486,8 +477,7 @@ static int ir_detach(struct i2c_client *
struct IR_i2c *ir = i2c_get_clientdata(client);
/* kill outstanding polls */
- del_timer_sync(ir-timer);
- flush_scheduled_work();
+ cancel_delayed_work_sync(ir-work);
/* unregister devices */
input_unregister_device(ir-input);
--- v4l-dvb.orig/linux/include/media/ir-kbd-i2c.h 2009-03-06
13:59:38.0 +0100
+++ v4l-dvb/linux/include/media/ir-kbd-i2c.h2009-03-06 14:01:47.0
+0100
@@ -14,8 +14,7 @@ struct IR_i2c {
/* Used to avoid fast repeating */
unsigned char old;
- struct work_struct work;
- struct timer_list timer;
+ struct delayed_workwork;
char phys[32];
int(*get_key)(struct IR_i2c*, u32*, u32*);
};
--
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 9/9] omap34xxcam: Add camera driver
Hello, Sakari Ailus
On Thu, 2009-03-05 at 16:09 +0200, Sakari Ailus wrote:
Alexey Klimov wrote:
+static int vidioc_g_fmt_vid_cap(struct file *file, void *fh,
+ struct v4l2_format *f)
+{
+ struct omap34xxcam_fh *ofh = fh;
+ struct omap34xxcam_videodev *vdev = ofh-vdev;
+
+ if (vdev-vdev_sensor == v4l2_int_device_dummy())
+ return -EINVAL;
+
+ mutex_lock(vdev-mutex);
+ f-fmt.pix = vdev-pix;
+ mutex_unlock(vdev-mutex);
H, you are using mutex_lock to lock reading from vdev structure..
Well, i don't if this is right approach. I am used to that mutex_lock is
used to prevent _changing_ of members in structure..
The vdev-mutex is acquired since we want to prevent concurrent access
to vdev-pix. Otherwise it might change while we are reading it, right?
I thought more about this and looks like that i was wrong. You are
right. You are reading structure, and i wasn't able to notice that first
time. Sorry for bothering about this.
snip
+static int omap34xxcam_device_register(struct v4l2_int_device *s)
+{
+ struct omap34xxcam_videodev *vdev = s-u.slave-master-priv;
+ struct omap34xxcam_hw_config hwc;
+ int rval;
+
+ /* We need to check rval just once. The place is here. */
I didn't understand this comment. You doing nothin in next few lines
with int variable rval(which introduced in this function). Is comment
talking about struct v4l2_int_device *s ?
Yes. If the g_priv() succeeds now it will succeed in future, too. This
comes from the platform data through the slave device.
Well, okay. I mean that for me this comment looks ambiguous. Please, if
you don't mind it's better not to use word rval because it creates
confusion with int rval;.
--
Best regards, Klimov Alexey
--
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/9] omap3isp: Add ISP main driver and register definitions
On Thu, 2009-03-05 at 13:34 +0200, Sakari Ailus wrote:
Thanks for the comments, Alexey!
Alexey Klimov wrote:
+static int isp_probe(struct platform_device *pdev)
+{
+ struct isp_device *isp;
+ int ret_err = 0;
+ int i;
+
+ isp = kzalloc(sizeof(*isp), GFP_KERNEL);
+ if (!isp) {
+ dev_err(pdev-dev, could not allocate memory\n);
+ return -ENODEV;
return -ENOMEM; ?
Done.
+ }
+
+ platform_set_drvdata(pdev, isp);
+
+ isp-dev = pdev-dev;
+
+ for (i = 0; i = OMAP3_ISP_IOMEM_CSI2PHY; i++) {
+ struct resource *mem;
+ /* request the mem region for the camera registers */
+ mem = platform_get_resource(pdev, IORESOURCE_MEM, i);
+ if (!mem) {
+ dev_err(isp-dev, no mem resource?\n);
+ return -ENODEV;
Maybe ENODEV is not apropriate here too..
What else it could be? ENOENT comes to mind but I'm not sure it's
significantly better.
ENODEV is okay, sorry.
--
Best regards, Klimov Alexey
--
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 4/5] OMAP3430SDP: Add support for Camera Kit v3
Hello, all On Fri, 2009-03-06 at 10:54 +0900, DongSoo(Nathaniel) Kim wrote: Hi Alexey, On Fri, Mar 6, 2009 at 7:05 AM, Alexey Klimov klimov.li...@gmail.com wrote: Hello, all On Thu, Mar 5, 2009 at 7:42 PM, Curran, Dominic dcur...@ti.com wrote: Hi Kim -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of DongSoo(Nathaniel) Kim Sent: Wednesday, March 04, 2009 8:58 PM To: Aguirre Rodriguez, Sergio Alberto Cc: linux-media@vger.kernel.org; linux-o...@vger.kernel.org; Sakari Ailus; Tuukka.O Toivonen; Hiroshi DOYU; MiaoStanley; Nagalla, Hari; Hiremath, Vaibhav; Lakhani, Amish; Menon, Nishanth Subject: Re: [PATCH 4/5] OMAP3430SDP: Add support for Camera Kit v3 Hi Sergio, On Wed, Mar 4, 2009 at 5:44 AM, Aguirre Rodriguez, Sergio Alberto saagui...@ti.com wrote: + /* turn on analog power */ + twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER, + VAUX_2_8_V, TWL4030_VAUX2_DEDICATED); + twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER, + VAUX_DEV_GRP_P1, TWL4030_VAUX2_DEV_GRP); + + /* out of standby */ + gpio_set_value(MT9P012_STANDBY_GPIO, 0); + udelay(1000); It seems better using msleep rather than udelay for 1000us much. Just to be safe :) How about you? Why is msleep safer than udelay ? I have small guess that he is wondering why you are using big delays with help of udelay(). (It's may be obvious but as we know udelay uses cpu loops to make delay and msleep calls to scheduler) So, msleep is more flexible and softer but if you need precise time or you can't sleep in code you need udelay. Sometimes using udelay is reasonably required. I totally agree with you. But besides the udelay and mdelay accuracy issue, Sergio's power up timing for MT9P012 seems to delay too much. (not for lens controller.) I also have experience using MT9P012 sensor with other ISP, but in case of mine it took 600 to 800 ms for whole power up sequence. But if that delay depends on SDP board and Sergio had no options without making delay for that much, then it explains everything. So I'm saying if there was no other option than making long delay to bring up MT9P012 sensor properly, if I were Sergio I should rather use mdelay than udelay. I agree with you. mdelay is really safer that udelay. From file include/linux/delay.h: * Using udelay() for intervals greater than a few milliseconds can * risk overflow for high loops_per_jiffy (high bogomips) machines. The * mdelay() provides a wrapper to prevent this. For delays greater * than MAX_UDELAY_MS milliseconds, the wrapper is used. Architecture * specific values can be defined in asm-???/delay.h as an override. So, let's Sergio check and decide what he needed! :) Cheers, Nate -- Best regards, Klimov Alexey -- 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
Problem with changeset 10837: causes make all not to build many modules
Mauro, Your latest changeset causes many modules (100 in total!) not to be built anymore when doing make all, i.e. without doing any make xconfig/make gconfig. I think this is related to the config variables for the frontend drivers no longer being defined when DVB_FE_CUSTOMISE=n , so the card drivers cannot depend on them anymore. I've attached a diff between v4l/.config from current revision and parent. Regards, Alain --- v4l-dvb/v4l/.config 2009-03-07 15:22:26.0 +0100 +++ v4l-dvb-tip/v4l/.config 2009-03-07 16:02:55.0 +0100 @@ -1,28 +1,28 @@ CONFIG_MEDIA_TUNER_TDA18271=m CONFIG_USB_DSBR=m -CONFIG_VIDEO_CX88_VP3054=m +# CONFIG_VIDEO_CX88_VP3054 is not set CONFIG_DAB=y CONFIG_DVB_USB=m -CONFIG_DVB_DUMMY_FE=m +# CONFIG_DVB_DUMMY_FE is not set CONFIG_USB_GSPCA_OV534=m CONFIG_USB_STKWEBCAM=m -CONFIG_DVB_S5H1420=m -CONFIG_DVB_CX22700=m +# CONFIG_DVB_S5H1420 is not set +# CONFIG_DVB_CX22700 is not set CONFIG_SOC_CAMERA=m CONFIG_VIDEO_CX88_BLACKBIRD=m CONFIG_USB_VICAM=m CONFIG_VIDEO_USBVISION=m -CONFIG_DVB_SP8870=m -CONFIG_DVB_BUDGET_AV=m +# CONFIG_DVB_SP8870 is not set +# CONFIG_DVB_BUDGET_AV is not set CONFIG_MEDIA_TUNER=m -CONFIG_DVB_TUNER_DIB0070=m +# CONFIG_DVB_TUNER_DIB0070 is not set CONFIG_VIDEO_VPX3220=m CONFIG_MEDIA_TUNER_TDA827X=m CONFIG_USB_GSPCA_SPCA561=m # CONFIG_USB_STV06XX is not set CONFIG_VIDEO_SAA7110=m CONFIG_VIDEO_ZORAN_BUZ=m -CONFIG_DVB_BT8XX=m +# CONFIG_DVB_BT8XX is not set CONFIG_VIDEO_SAA7127=m CONFIG_DVB_USB_AF9005=m CONFIG_USB_GSPCA_PAC7311=m @@ -30,40 +30,40 @@ CONFIG_VIDEO_WM8739=m CONFIG_RADIO_MAESTRO=m CONFIG_VIDEO_CPIA=m -CONFIG_DVB_CX22702=m +# CONFIG_DVB_CX22702 is not set CONFIG_VIDEOBUF_GEN=m -CONFIG_DVB_B2C2_FLEXCOP_PCI=m +# CONFIG_DVB_B2C2_FLEXCOP_PCI is not set CONFIG_RADIO_AZTECH=m CONFIG_VIDEO_BT848=m CONFIG_VIDEO_VIVI=m -CONFIG_DVB_USB_CXUSB=m +# CONFIG_DVB_USB_CXUSB is not set CONFIG_USB_GSPCA_FINEPIX=m CONFIG_SOC_CAMERA_MT9V022=m CONFIG_SND_FM801=m CONFIG_RADIO_SF16FMI=m # CONFIG_VIDEO_HELPER_CHIPS_AUTO is not set -CONFIG_DVB_ISL6405=m +# CONFIG_DVB_ISL6405 is not set CONFIG_DVB_USB_VP702X=m CONFIG_DVB_USB_DEBUG=y CONFIG_MEDIA_TUNER_XC2028=m -CONFIG_DVB_USB_ANYSEE=m +# CONFIG_DVB_USB_ANYSEE is not set CONFIG_VIDEO_BT856=m CONFIG_RADIO_CADET=m CONFIG_USB_M5602=m CONFIG_VIDEO_PVRUSB2_DEBUGIFC=y CONFIG_USB_GSPCA_SONIXJ=m -CONFIG_DVB_USB_DIBUSB_MB_FAULTY=y -CONFIG_DVB_DRX397XD=m +# CONFIG_DVB_USB_DIBUSB_MB_FAULTY is not set +# CONFIG_DVB_DRX397XD is not set CONFIG_VIDEO_CX25840=m CONFIG_VIDEO_VP27SMPX=m -CONFIG_DVB_B2C2_FLEXCOP_USB=m +# CONFIG_DVB_B2C2_FLEXCOP_USB is not set CONFIG_VIDEO_TVP5150=m CONFIG_VIDEO_SAA5246A=m CONFIG_MEDIA_TUNER_SIMPLE=m CONFIG_VIDEO_TEA6415C=m -CONFIG_DVB_OR51211=m +# CONFIG_DVB_OR51211 is not set CONFIG_VIDEO_OVCAMCHIP=m -CONFIG_DVB_AV7110_OSD=y +# CONFIG_DVB_AV7110_OSD is not set CONFIG_VIDEO_ZORAN_LML33=m CONFIG_USB_PWC_INPUT_EVDEV=y CONFIG_SOC_CAMERA_MT9M111=m @@ -72,115 +72,115 @@ CONFIG_SOC_CAMERA_OV772X=m CONFIG_VIDEO_CX88=m CONFIG_VIDEO_W9966=m -CONFIG_DVB_S5H1411=m +# CONFIG_DVB_S5H1411 is not set CONFIG_VIDEO_TCM825X=m CONFIG_USB_S2255=m CONFIG_RADIO_ZOLTRIX=m -CONFIG_DVB_PLL=m -CONFIG_DVB_LGDT330X=m +# CONFIG_DVB_PLL is not set +# CONFIG_DVB_LGDT330X is not set CONFIG_RADIO_TYPHOON_PROC_FS=y -CONFIG_DVB_STB0899=m +# CONFIG_DVB_STB0899 is not set CONFIG_SND_FM801_TEA575X_BOOL=y -CONFIG_DVB_LNBP21=m -CONFIG_DVB_B2C2_FLEXCOP=m +# CONFIG_DVB_LNBP21 is not set +# CONFIG_DVB_B2C2_FLEXCOP is not set CONFIG_USB_GSPCA_SONIXB=m CONFIG_USB_GSPCA_ZC3XX=m -CONFIG_VIDEO_BT848_DVB=y +# CONFIG_VIDEO_BT848_DVB is not set CONFIG_VIDEO_ZORAN_DC10=m CONFIG_DVB_USB_CINERGY_T2=m CONFIG_RADIO_TERRATEC=m CONFIG_VIDEO_KS0127=m -CONFIG_DVB_VES1820=m -CONFIG_VIDEO_PVRUSB2_DVB=y +# CONFIG_DVB_VES1820 is not set +# CONFIG_VIDEO_PVRUSB2_DVB is not set CONFIG_VIDEO_DEV=m CONFIG_VIDEO_SAA717X=m CONFIG_RADIO_TEA5764=m CONFIG_MT9M001_PCA9536_SWITCH=y CONFIG_MEDIA_TUNER_MT20XX=m -CONFIG_VIDEO_CX23885=m +# CONFIG_VIDEO_CX23885 is not set CONFIG_USB_DABUSB=m -CONFIG_DVB_BUDGET=m -CONFIG_DVB_VES1X93=m +# CONFIG_DVB_BUDGET is not set +# CONFIG_DVB_VES1X93 is not set CONFIG_VIDEO_ALLOW_V4L1=y CONFIG_VIDEO_CS5345=m # CONFIG_RADIO_GEMTEK_PROBE is not set CONFIG_USB_GSPCA_SPCA506=m -CONFIG_DVB_ISL6421=m +# CONFIG_DVB_ISL6421 is not set CONFIG_USB_GSPCA_PAC207=m -CONFIG_DVB_NXT6000=m +# CONFIG_DVB_NXT6000 is not set CONFIG_DVB_TTUSB_DEC=m CONFIG_SND_FM801_TEA575X=m -CONFIG_DVB_USB_NOVA_T_USB2=m +# CONFIG_DVB_USB_NOVA_T_USB2 is not set CONFIG_MEDIA_TUNER_XC5000=m CONFIG_RADIO_MAXIRADIO=m -CONFIG_DVB_TDA10048=m +# CONFIG_DVB_TDA10048 is not set CONFIG_MEDIA_TUNER_MXL5005S=m CONFIG_MEDIA_TUNER_TEA5761=m CONFIG_VIDEO_TDA7432=m CONFIG_VIDEOBUF_DMA_SG=m CONFIG_MEDIA_TUNER_MT2266=m -CONFIG_VIDEO_CX18=m -CONFIG_DVB_TDA1004X=m +# CONFIG_VIDEO_CX18 is not set +# CONFIG_DVB_TDA1004X is not set CONFIG_VIDEO_MXB=m -CONFIG_DVB_STV6110=m +# CONFIG_DVB_STV6110 is not set
[PATCH] for the file gspca/mr97310a.c (Resubmit)
Here is a cleaned-up version of the patch to gspca/mr97310a.c
This patch causes all frame headers in the streaming output of MR97310A
cameras, instead of being discarded.
Said frame headers contain information which may be useful in processing
the video output and therefore should be kept and not discarded.
A corresponding patch to the decompression algorithm in
libv4lconvert/mr97310a.c corrects the change in frame offset.
Signed-off-by: Theodore Kilgore kilg...@auburn.edu
--- mr97310a.c.orig 2009-02-18 14:40:03.0 -0600
+++ mr97310a.c 2009-03-06 15:12:14.0 -0600
@@ -29,9 +29,7 @@ MODULE_LICENSE(GPL);
/* specific webcam descriptor */
struct sd {
struct gspca_dev gspca_dev; /* !! must be the first item */
-
u8 sof_read;
- u8 header_read;
};
/* V4L2 controls supported by the driver */
@@ -285,7 +283,6 @@ static void sd_pkt_scan(struct gspca_dev
__u8 *data, /* isoc packet */
int len) /* iso packet length */
{
- struct sd *sd = (struct sd *) gspca_dev;
unsigned char *sof;
sof = pac_find_sof(gspca_dev, data, len);
@@ -300,25 +297,12 @@ static void sd_pkt_scan(struct gspca_dev
n = 0;
frame = gspca_frame_add(gspca_dev, LAST_PACKET, frame,
data, n);
- sd-header_read = 0;
- gspca_frame_add(gspca_dev, FIRST_PACKET, frame, NULL, 0);
+ /* Start next frame. */
+ gspca_frame_add(gspca_dev, FIRST_PACKET, frame,
+ pac_sof_marker, sizeof pac_sof_marker);
len -= sof - data;
data = sof;
}
- if (sd-header_read 7) {
- int needed;
-
- /* skip the rest of the header */
- needed = 7 - sd-header_read;
- if (len = needed) {
- sd-header_read += len;
- return;
- }
- data += needed;
- len -= needed;
- sd-header_read = 7;
- }
-
gspca_frame_add(gspca_dev, INTER_PACKET, frame, data, len);
}
--
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: S4 hang with uvcvideo causing Unlink after no-IRQ? Controller is probably using the wrong IRQ.
On Sat, 7 Mar 2009, Brandon Philips wrote: On 21:26 Fri 06 Mar 2009, Greg KH wrote: On Fri, Mar 06, 2009 at 11:11:22AM -0800, Brandon Philips wrote: Hello- When an UVC device is open and a S4 is attempted the thaw hangs (see the stack below). I don't see what the UVC driver is doing wrong to cause this to happen though. I don't think this is a uvc driver issue, it looks like all you are trying to do is a usb control message when things hang. Indeed. When I was poking at this I tried to supress the control message coming out of the uvcvideo driver after the suspend was issued to see what would happen and the control messages after the resume locked up instead. Eh. Have you tried suspending just the two devices plugged into that EHCI controller instead of suspending the entire system? That would make it a lot easier to carry out testing. It looks like things die right after this message: ehci_hcd :00:1d.7: Unlink after no-IRQ? Controller is probably using the wrong IRQ. It could be that the host controller isn't behaving correctly. But even then, a timer should keep things running. So I don't know why the system hanged. BTW, all those extra debugging messages in your log made it very difficult to read, and they didn't help much in pinpointing the problem. You should remove all of them before doing the next test. Instead you could use usbmon to capture the USB traffic. Alan Stern -- 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:Sat Mar 7 19:00:03 CET 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 10837:6bd427caa0cb gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.22.19-armv5: OK linux-2.6.23.12-armv5: OK linux-2.6.24.7-armv5: OK linux-2.6.25.11-armv5: OK linux-2.6.26-armv5: OK linux-2.6.27-armv5: OK linux-2.6.28-armv5: OK linux-2.6.29-rc7-armv5: OK linux-2.6.27-armv5-ixp: OK linux-2.6.28-armv5-ixp: OK linux-2.6.29-rc7-armv5-ixp: OK linux-2.6.27-armv5-omap2: WARNINGS linux-2.6.28-armv5-omap2: OK linux-2.6.29-rc7-armv5-omap2: OK linux-2.6.22.19-i686: ERRORS linux-2.6.23.12-i686: OK linux-2.6.24.7-i686: OK linux-2.6.25.11-i686: OK linux-2.6.26-i686: OK linux-2.6.27-i686: OK linux-2.6.28-i686: OK linux-2.6.29-rc7-i686: WARNINGS linux-2.6.23.12-m32r: OK linux-2.6.24.7-m32r: OK linux-2.6.25.11-m32r: OK linux-2.6.26-m32r: OK linux-2.6.27-m32r: OK linux-2.6.28-m32r: OK linux-2.6.29-rc7-m32r: OK linux-2.6.26-mips: OK linux-2.6.27-mips: OK linux-2.6.28-mips: OK linux-2.6.29-rc7-mips: WARNINGS linux-2.6.27-powerpc64: WARNINGS linux-2.6.28-powerpc64: WARNINGS linux-2.6.29-rc7-powerpc64: WARNINGS linux-2.6.22.19-x86_64: WARNINGS linux-2.6.23.12-x86_64: WARNINGS linux-2.6.24.7-x86_64: WARNINGS linux-2.6.25.11-x86_64: WARNINGS linux-2.6.26-x86_64: WARNINGS linux-2.6.27-x86_64: WARNINGS linux-2.6.28-x86_64: WARNINGS linux-2.6.29-rc7-x86_64: WARNINGS fw/apps: WARNINGS sparse (linux-2.6.28): ERRORS sparse (linux-2.6.29-rc7): ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.tar.bz2 The V4L2 specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/v4l2.html The DVB API specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/dvbapi.pdf -- 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: Technisat Skystar 2 on Suse Linux 11.1, kernel 2.6.27.19-3.2-default
dvbscan -out channels channels.conf hangs and does not create a channels.conf file vlc dvb:// vlc /dev/dvb/adapter0/dvr0 vlc - recording device - dvb-s ... does not open a video window and does not play anything kaffeine stdin:// /dev/dvb/adapter0/dvr0 ... no module found to handle source mplayer /dev/dvb/adapter0/dvr0 mplayer: could not connect to socket mplayer: No such file or directory Failed to open LIRC support. You will not be able to use your remote control. Playing /dev/dvb/adapter0/dvr0. ...but no window opens How can I play videos? How can I select a channel? How can I stream a channel to disk? have modprobed all recommended kernel modules: lsmod | egrep budget|mt312|b2c2-flexcop mt312 7748 0 budget 12588 0 budget_core 9884 1 budget saa714615980 2 budget,budget_core ttpci_eeprom2020 1 budget_core dvb_core 73144 4 budget,budget_core,stv0299,b2c2_flexcop i2c_core 29916 9 t312,budget,budget_core,ttpci_eeprom,stv0299,i2c_viapro,b2c2_flexcop,cx24123,s5h1420 Patrick Boettcher schrieb: Hi Elmar, On Sat, 7 Mar 2009, Elmar Stellnberger wrote: Following the instructions at http://www.linuxtv.org/wiki/index.php/TechniSat_SkyStar_2_TV_PCI_/_Sky2PC_PCI I have tried to make my Technisat Skystar 2 work. This howto seems to be out of date. The skystar2.ko was removed like 4 years ago. It was replaced by the b2c2-flexcop-drivers. The thing is that suse ships most of the required kernel modules out of the box; iter sunt stv0299 mt312 budget Only skystar2 is missing, so that I have no /dev/video0 and no /dev/dvb/adapter0/video0 as required by all these dvb players. ls /dev/dvb/adapter0/ demux0 dvr0 frontend0 net0 Furthermore this is totally correct. /dev/video0 is provided by analog-video-cards or by full-featured (with a overlay-chip on board) devices. The SkyStar2 is neither of it. Did you try to use Kaffeine or mplayer or (dvb)scan? regards, Patrick. -- Mail: patrick.boettc...@desy.de WWW: http://www.wi-bw.tfh-wildau.de/~pboettch/ -- 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: Technisat Skystar 2 on Suse Linux 11.1, kernel 2.6.27.19-3.2-default
dvbscan -out channels channels.conf hangs and does not create a file named channels.conf xine ... no valid channels.conf found mplayer dvb:// Playing dvb://. CAN'T READ CONFIG FILE /etc/mplayer/channels.conf DVB CONFIGURATION IS EMPTY, exit Failed to open dvb://. kaffeine stdin:// /dev/dvb/adapter0/dvr0 no module find to handle source vlc dvb:// vlc - open device - dvb-s - play - can not open dvb:// ... does not open any video window me-tv ... there are no available dvb tuner devices Patrick Boettcher schrieb: Hi Elmar, On Sat, 7 Mar 2009, Elmar Stellnberger wrote: Following the instructions at http://www.linuxtv.org/wiki/index.php/TechniSat_SkyStar_2_TV_PCI_/_Sky2PC_PCI I have tried to make my Technisat Skystar 2 work. This howto seems to be out of date. The skystar2.ko was removed like 4 years ago. It was replaced by the b2c2-flexcop-drivers. The thing is that suse ships most of the required kernel modules out of the box; iter sunt stv0299 mt312 budget Only skystar2 is missing, so that I have no /dev/video0 and no /dev/dvb/adapter0/video0 as required by all these dvb players. ls /dev/dvb/adapter0/ demux0 dvr0 frontend0 net0 Furthermore this is totally correct. /dev/video0 is provided by analog-video-cards or by full-featured (with a overlay-chip on board) devices. The SkyStar2 is neither of it. Did you try to use Kaffeine or mplayer or (dvb)scan? regards, Patrick. -- Mail: patrick.boettc...@desy.de WWW: http://www.wi-bw.tfh-wildau.de/~pboettch/ -- 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] Conceptronic CTVFMI2 PCI Id
Hi,
My BTTV_BOARD_CONCEPTRONIC_CTVFMI2 card wasn't auto-detected, here's a patch
that adds its PCI id.
lspci -nnv output:
05:06.0 Multimedia video controller [0400]: Brooktree Corporation Bt878 Video
Capture [109e:036e] (rev 11)
05:06.1 Multimedia controller [0480]: Brooktree Corporation Bt878 Audio Capture
[109e:0878] (rev 11)
--
Robert Millan
The DRM opt-in fallacy: Your data belongs to us. We will decide when (and
how) you may access your data; but nobody's threatening your freedom: we
still allow you to remove your data and not access it at all.
diff --git a/drivers/media/video/bt8xx/bttv-cards.c b/drivers/media/video/bt8xx/bttv-cards.c
index d24dcc0..2ddda54 100644
--- a/drivers/media/video/bt8xx/bttv-cards.c
+++ b/drivers/media/video/bt8xx/bttv-cards.c
@@ -289,6 +289,8 @@ static struct CARD {
/* Duplicate PCI ID, reconfigure for this board during the eeprom read.
* { 0x13eb0070, BTTV_BOARD_HAUPPAUGE_IMPACTVCB, Hauppauge ImpactVCB }, */
+ { 0x109e036e, BTTV_BOARD_CONCEPTRONIC_CTVFMI2, Conceptronic CTVFMi v2},
+
/* DVB cards (using pci function .1 for mpeg data xfer) */
{ 0x001c11bd, BTTV_BOARD_PINNACLESAT, Pinnacle PCTV Sat },
{ 0x01010071, BTTV_BOARD_NEBULA_DIGITV, Nebula Electronics DigiTV },
Re: Results of the 'dropping support for kernels 2.6.22' poll
On Saturday 07 March 2009, Trent Piepho wrote: Audio was out of tree. If they had a better system, like v4l-dvb does, they might well still be out of tree. And aren't there some wireless packages that are out of tree? Wireless development is done in tree and then copied to a compat tree that contains just the wireless drivers, stack and compatibility stubs. A year or two back there were some drivers developed out of tree so they could be tested more easily but it became too much of an overhead to work that way. Adam -- 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: Technisat Skystar 2 on Suse Linux 11.1, kernel 2.6.27.19-3.2-default
dvbscan -adapter 0 -frontend 0 -demux 0 /usr/share/dvb/dvb-s/Astra-19.2E Failed to set frontend downloading channel.conf from Astra1 has not brought me force. szap 3sat reading channels from file '/home/elm/.szap/channels.conf' zapping to 20 '3sat': sat 0, frequency = 11954 MHz V, symbolrate 2750, vpid = 0x00d2, apid = 0x00dc sid = 0x using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' status 00 | signal | snr 6b2b | ber | unc fffe | status 00 | signal | snr 7f02 | ber 7e00 | unc fffe | status 01 | signal aa7e | snr 3d47 | ber ffe8 | unc fffe | status 00 | signal | snr 7fc5 | ber fff0 | unc fffe | status 00 | signal | snr 2232 | ber 6ef0 | unc fffe | status 00 | signal | snr 1fdd | ber 0058 | unc fffe | status 00 | signal | snr 19b3 | ber | unc fffe | status 02 | signal | snr 192f | ber | unc fffe | status 00 | signal 0035 | snr 8469 | ber | unc fffe | ... etc. what should that output mean? why does szap not terminate? Patrick Boettcher schrieb: Hi Elmar, On Sat, 7 Mar 2009, Elmar Stellnberger wrote: Following the instructions at http://www.linuxtv.org/wiki/index.php/TechniSat_SkyStar_2_TV_PCI_/_Sky2PC_PCI I have tried to make my Technisat Skystar 2 work. This howto seems to be out of date. The skystar2.ko was removed like 4 years ago. It was replaced by the b2c2-flexcop-drivers. The thing is that suse ships most of the required kernel modules out of the box; iter sunt stv0299 mt312 budget Only skystar2 is missing, so that I have no /dev/video0 and no /dev/dvb/adapter0/video0 as required by all these dvb players. ls /dev/dvb/adapter0/ demux0 dvr0 frontend0 net0 Furthermore this is totally correct. /dev/video0 is provided by analog-video-cards or by full-featured (with a overlay-chip on board) devices. The SkyStar2 is neither of it. Did you try to use Kaffeine or mplayer or (dvb)scan? regards, Patrick. -- Mail: patrick.boettc...@desy.de WWW: http://www.wi-bw.tfh-wildau.de/~pboettch/ -- 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] pxa_camera: Redesign DMA handling
Guennadi Liakhovetski g.liakhovet...@gmx.de writes: Emn, no. Just looked in CodingStyle - haven't found a word about it. So, I think, applies keep consistent with the rest of the file. And, you know, someone might call this a matter of taste, but a line like x = y in a .c file looks unfinished to me, whereas x = y + clearly has a continuation. That's how I learned to break lines at school, at the Uni,... Ok, never mind, in any case, until this is not in CodingStyle, I will nak all attempts to convert the whole driver to the opposite of what it has ATM. So, I'll drop 3/4 and will request amendments to other affected patches, ok? OK, no problem. I'm neither strongly fond of one syntax or the other. I'll amend the other patches while you're working on the review. Cheers. -- Robert -- 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/~dougsland/v4l-dvb
Hi, Am Samstag, den 07.03.2009, 19:06 -0500 schrieb Andy Walls: On Sat, 2009-03-07 at 18:26 -0500, Devin Heitmueller wrote: On Sat, Mar 7, 2009 at 5:45 PM, Douglas Schilling Landgraf dougsl...@gmail.com wrote: Hi Mauro, Please pull from: http://linuxtv.org/hg/~dougsland/v4l-dvb for the following: - v4l2-apps/util: Add rewrite_eeprom tool Modules this script is known to work with: em28xx and saa7134 Thanks, Douglas -- 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 Wow, this script really scares the crap out of me. Actually it appears to be a meta-script. It builds a script of i2c-set commands to reload an eeprom. You then have an opportunity to review the script to reload the EEPROM and then run it. You first have to load the gun, then pull the trigger an shoot yourself in the foot. :) Is this something we *really* need? No. IMO, factory provisionsing is the purview of the manufacturer. Does someone actually have evidence of the Windows drivers reloading the eeproms on these devices if it is, in fact, true that: the eeprom may be erased, due to a bug on a *few eeprom* chipsets that sometimes considers i2c messages to other devices as being for it But I don't have trashed eeprom sitting in front of me, and I don't have to build 256 i2cset commands by hand. :) If so, it needs to have a HUGE WARNING explaining the few cases that it should actually be used, and it should also explicitly block usage against chipsets except for those that have been validated to work. I agree with these. Do you really want to be responsible for the first time some unknowing user runs this against cx88 or some other chipset you never tried it against and it bricks their board? Section 11 of the GPL legally absolves the authors of most, if not all, responsibility NO WARRANTY 11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM AS IS WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. Also, this won't work against newer em28xx chipsets like the em2874 and em2884, which have 16-bit eeproms. And if you corrupt the eeprom on the em2874, you actually *WILL* brick the device (which is why I removed the code that reads the eeprom in the first place). The script should state in big letters that EXPERT knowledge of the device in question is required to reduce the risk. Perhaps reiterating portions of section 11 of the GPL. (But then again, what is the risk of a non-functioning device continuing not to function?). The real risk is running the linux code that trashes the eeprom in the first place. I would look to prevent that code from running, or at least flag the risky condition in the kernel log. Devin Regards, Andy as far I know we never had a report about destroyed eeprom content on the saa7134 driver, but it seems Mauro and Douglas have seen it ? On the saa7134 I won't care that much, since currently we still can force all settings even with an erased eeprom, but if users cause trouble by using the script in a wrong way, their windows drivers won't work anymore and they don't have a chance to fix them except writing back the right eeprom content. In the past the DScaler guys had such a trouble on the cx88xx MSI t...@nywhere Master caused by them and they were badly in need of such a tool. So, in general it is good to have it, but there needs to be that BIG RED WARNING :) 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: [PULL] http://linuxtv.org/hg/~dougsland/v4l-dvb
Hi! Am Samstag, den 07.03.2009, 19:19 -0500 schrieb Andy Walls: On Sat, 2009-03-07 at 19:06 -0500, Andy Walls wrote: On Sat, 2009-03-07 at 18:26 -0500, Devin Heitmueller wrote: On Sat, Mar 7, 2009 at 5:45 PM, Douglas Schilling Landgraf dougsl...@gmail.com wrote: Hi Mauro, Please pull from: http://linuxtv.org/hg/~dougsland/v4l-dvb for the following: - v4l2-apps/util: Add rewrite_eeprom tool Modules this script is known to work with: em28xx and saa7134 Thanks, Douglas -- Wow, this script really scares the crap out of me. Actually it appears to be a meta-script. It builds a script of i2c-set commands to reload an eeprom. You then have an opportunity to review the script to reload the EEPROM and then run it. You first have to load the gun, then pull the trigger an shoot yourself in the foot. :) Is this something we *really* need? No. IMO, factory provisionsing is the purview of the manufacturer. Does someone actually have evidence of the Windows drivers reloading the eeproms on these devices if it is, in fact, true that: the eeprom may be erased, due to a bug on a *few eeprom* chipsets that sometimes considers i2c messages to other devices as being for it But I don't have trashed eeprom sitting in front of me, and I don't have to build 256 i2cset commands by hand. :) Another solution, that may be more complicated for the developer, but simpler for the end user, is a module parameter to select a compiled in eeprom image if the user knows what device he has, but the EEPROM is trashed. A similar option would be to use the kernel firmware loading facility to load in an eeprom firmware image for various devices to use in the driver, if the eeprom is trashed. Neither of those would write the new eeprom data, and hence neither would help the dual-boot Linux/Windows user. Regards, Andy Just receiving this one. Yes, that is the major problem in worst case. 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: [PULL] http://linuxtv.org/hg/~dougsland/v4l-dvb
On Sat, Mar 7, 2009 at 7:06 PM, Andy Walls awa...@radix.net wrote: Actually it appears to be a meta-script. It builds a script of i2c-set commands to reload an eeprom. You then have an opportunity to review the script to reload the EEPROM and then run it. You first have to load the gun, then pull the trigger an shoot yourself in the foot. :) Yeah, this is really not a very good argument. Think of the average user - he reads something on a newsgroup and thinks, Oh, maybe my eeprom is corrupted. And then he blindly runs the three steps above. But he doesn't have the eeprom on his machine, so he copies it from someone else's dmesg output he finds on the Internet, and doesn't realize that the HVR-850 based on the Auvtiek chipset is different than the HVR-850 based on em28xx. Instant eeprom corruption. Do you really want to be responsible for the first time some unknowing user runs this against cx88 or some other chipset you never tried it against and it bricks their board? Section 11 of the GPL legally absolves the authors of most, if not all, responsibility Perhaps responsible wasn't the best word to use as it implies a legal implication. Sure, you're not legally responsible, but you better feel damn responsible if you hand a tool like this to some user who is just trying to make his device work and he trashes it out because he doesn't know what the hell he is doing. The script should state in big letters that EXPERT knowledge of the device in question is required to reduce the risk. Perhaps reiterating portions of section 11 of the GPL. (But then again, what is the risk of a non-functioning device continuing not to function?). To answer your question, consider the definition of non-functioning to an average user. This can mean *anything*. He could be trying to use tvtime to watch a DVB tv source. And he runs this script and breaks a perfectly good piece of hardware. The real risk is running the linux code that trashes the eeprom in the first place. I would look to prevent that code from running, or at least flag the risky condition in the kernel log. I don't doubt that this tool could be useful for a select few developers, but indeed it needs to say something like Don't ever run this tool unless somebody who knows what the hell he is talking about tells you to. Devin -- Devin J. Heitmueller http://www.devinheitmueller.com AIM: devinheitmueller -- 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/~dougsland/v4l-dvb
Hello everyone, First of all, thanks for your comments guys. On Sat, 7 Mar 2009 18:26:05 -0500 Devin Heitmueller devin.heitmuel...@gmail.com wrote: On Sat, Mar 7, 2009 at 5:45 PM, Douglas Schilling Landgraf dougsl...@gmail.com wrote: Hi Mauro, Please pull from: http://linuxtv.org/hg/~dougsland/v4l-dvb for the following: - v4l2-apps/util: Add rewrite_eeprom tool Modules this script is known to work with: em28xx and saa7134 Thanks, Douglas -- 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 Wow, this script really scares the crap out of me. Is this something we *really* need? IMO yes. The first version of this script was created because an em28xx user sent an email to me and Mauro asking *help* since his eeprom was lost and he would like to recover it. A few time later, his board was recovered by [this script] and now his device is working and supported by the upstream driver. If so, it needs to have a HUGE WARNING explaining the few cases that it should actually be used, and it should also explicitly block usage against chipsets except for those that have been validated to work. Well, I have read several good ideas from you and others developers. For now, it's very easy to implement such warning message, no problem from my side. Do you really want to be responsible for the first time some unknowing user runs this against cx88 or some other chipset you never tried it against and it bricks their board? As Andy already sent, it's a *GPL* code. Of course, nobody wants to fell bad because a user replaced his eeprom. We are here because we want to help them. So, let's add such warning message. Also, this won't work against newer em28xx chipsets like the em2874 and em2884, which have 16-bit eeproms. And if you corrupt the eeprom on the em2874, you actually *WILL* brick the device (which is why I removed the code that reads the eeprom in the first place). Ok, I will add a comment to the script for such chipsets since I don't have those here for test now. On the other hand, I have tested with several older em28xx devices replacing a *good* eeprom with *wrong* eeprom and then replaced it again with a good one.. no bad affects, device is working fine like new. *Of course, neither me or Mauro we DO NOT recommend nobody to run this script if it's not really needed (like: erased/wrong eeprom cases).* Thanks, Douglas -- 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/~dougsland/v4l-dvb
Hi, Am Samstag, den 07.03.2009, 23:22 -0300 schrieb Douglas Schilling Landgraf: Hello everyone, First of all, thanks for your comments guys. On Sat, 7 Mar 2009 18:26:05 -0500 Devin Heitmueller devin.heitmuel...@gmail.com wrote: On Sat, Mar 7, 2009 at 5:45 PM, Douglas Schilling Landgraf dougsl...@gmail.com wrote: Hi Mauro, Please pull from: http://linuxtv.org/hg/~dougsland/v4l-dvb for the following: - v4l2-apps/util: Add rewrite_eeprom tool Modules this script is known to work with: em28xx and saa7134 Thanks, Douglas -- 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 Wow, this script really scares the crap out of me. Is this something we *really* need? IMO yes. The first version of this script was created because an em28xx user sent an email to me and Mauro asking *help* since his eeprom was lost and he would like to recover it. A few time later, his board was recovered by [this script] and now his device is working and supported by the upstream driver. If so, it needs to have a HUGE WARNING explaining the few cases that it should actually be used, and it should also explicitly block usage against chipsets except for those that have been validated to work. Well, I have read several good ideas from you and others developers. For now, it's very easy to implement such warning message, no problem from my side. Do you really want to be responsible for the first time some unknowing user runs this against cx88 or some other chipset you never tried it against and it bricks their board? As Andy already sent, it's a *GPL* code. Of course, nobody wants to fell bad because a user replaced his eeprom. We are here because we want to help them. So, let's add such warning message. Also, this won't work against newer em28xx chipsets like the em2874 and em2884, which have 16-bit eeproms. And if you corrupt the eeprom on the em2874, you actually *WILL* brick the device (which is why I removed the code that reads the eeprom in the first place). Ok, I will add a comment to the script for such chipsets since I don't have those here for test now. On the other hand, I have tested with several older em28xx devices replacing a *good* eeprom with *wrong* eeprom and then replaced it again with a good one.. no bad affects, device is working fine like new. *Of course, neither me or Mauro we DO NOT recommend nobody to run this script if it's not really needed (like: erased/wrong eeprom cases).* Thanks, Douglas -- it is even more funny and at least all guys here since a little bit longer do know this very well on the saa713x. Hartmut, under pressure doing the best work on the saa713x after Gerd did quit, was close to disclosure the intended Philips eeprom content. He luckily did not! , since the OEMs did play their own games. Which they were obviously implicitly allowed to do, if they take large amounts of new chips. This is all fine so far, no irony. Since we still don't have an extensive decoding of the eeprom contents, because of such, we can at least find lots of unused bytes shared by all of them. We can potentially use them for our own needs without breaking anything, until someone spits in the soup again. :) 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: Technisat Skystar 2 on Suse Linux 11.1, kernel 2.6.27.19-3.2-default
Hi Elmar, On Sat, 7 Mar 2009, Elmar Stellnberger wrote: dvbscan -adapter 0 -frontend 0 -demux 0 /usr/share/dvb/dvb-s/Astra-19.2E Failed to set frontend I have the same problem with that scan, please use the older one called scan. Are you running the szap below as root, but kaffeine as a normal user ? If so, make sure that you are in the group video. downloading channel.conf from Astra1 has not brought me force. szap 3sat reading channels from file '/home/elm/.szap/channels.conf' zapping to 20 '3sat': sat 0, frequency = 11954 MHz V, symbolrate 2750, vpid = 0x00d2, apid = 0x00dc sid = 0x using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' status 00 | signal | snr 6b2b | ber | unc fffe | status 00 | signal | snr 7f02 | ber 7e00 | unc fffe | status 01 | signal aa7e | snr 3d47 | ber ffe8 | unc fffe | status 00 | signal | snr 7fc5 | ber fff0 | unc fffe | status 00 | signal | snr 2232 | ber 6ef0 | unc fffe | status 00 | signal | snr 1fdd | ber 0058 | unc fffe | status 00 | signal | snr 19b3 | ber | unc fffe | status 02 | signal | snr 192f | ber | unc fffe | status 00 | signal 0035 | snr 8469 | ber | unc fffe | This is the first proof that your device is present and the driver is correctly loaded. Please check the output of the dmesg-program to check for lines starting with b2c2-flexcop. what should that output mean? it means, it can't synchronize the channel on that frequency. This can have a whole bunch of explaination - not necessarily only the driver. why does szap not terminate? It stays in the monitoring loop. Normal. Patrick. -- Mail: patrick.boettc...@desy.de WWW: http://www.wi-bw.tfh-wildau.de/~pboettch/ -- 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: S4 hang with uvcvideo causing Unlink after no-IRQ? Controller is probably using the wrong IRQ.
On 12:37 Sat 07 Mar 2009, Alan Stern wrote: On Sat, 7 Mar 2009, Brandon Philips wrote: On 21:26 Fri 06 Mar 2009, Greg KH wrote: On Fri, Mar 06, 2009 at 11:11:22AM -0800, Brandon Philips wrote: When an UVC device is open and a S4 is attempted the thaw hangs (see the stack below). I don't see what the UVC driver is doing wrong to cause this to happen though. I don't think this is a uvc driver issue, it looks like all you are trying to do is a usb control message when things hang. Indeed. When I was poking at this I tried to supress the control message coming out of the uvcvideo driver after the suspend was issued to see what would happen and the control messages after the resume locked up instead. Eh. Have you tried suspending just the two devices plugged into that EHCI controller instead of suspending the entire system? That would make it a lot easier to carry out testing. I tried to reproduce with s2ram suspend, echo suspend /sys/bus/usb/devices/.../power/level and /sys/power/pm_test levels but none of them reproduced it. So, at this point the only way I can reproduce this is with a full S4. Is there some other method I missed of testing? Thanks, Brandon -- 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
