RE: Bah! How do I change channels?
Hi, Am Samstag, den 27.06.2009, 22:36 -0400 schrieb George Adams: > A final wrapup (and again, thanks all of you - I'm indebted to you for your > help): > > after booting: > > > v4l2-ctl -F > Frequency: 9076 (567.25 MHz) > > > ivtv-tune -c 3 > /dev/video0: 61.250 MHz > > v4l2-ctl -F > Frequency: 980 (61.25 MHz) > > > v4l2-ctl -f 61.25 > Frequency set to 980 (61.25 MHz) > > v4l2-ctl -F > Frequency: 980 (61.25 MHz) > > > v4lctl setchannel 3 > > v4l2-ctl -F > Frequency: 0 (0.00 MHz) > > Conclusion: I'll stick with ivtv-tune or v4l2-ctl and ignore the misbehaving > v4lctl > > Hermann: Thanks, but I think you're mistaking the v4lctl "setstation" command > (which relies on .xawtv) and the "setchannel" command (which does not, at > least according to the man page.) I can for sure tell, that, if I rename/remove my .xawtv, "setchannel" does not work anymore and I see exactly what you reported initially. That can be looked up in the code and it also should not matter that I have a dual install of xawtv-3.95 and 4x since both start to exist. Cheers, Hermann > > > > > Subject: RE: Bah! How do I change channels? > > From: hermann-pit...@arcor.de > > To: g_adam...@hotmail.com > > CC: dheitmuel...@kernellabs.com; awa...@radix.net; > > video4linux-l...@redhat.com; linux-media@vger.kernel.org > > Date: Sun, 28 Jun 2009 03:39:05 +0200 > > > > Hi, > > > > Am Samstag, den 27.06.2009, 00:25 -0400 schrieb George Adams: > >> Thanks again to both of you for your help. I gave the no_poweroff flag a > >> try, but didn't see any difference. I also tried a "setchannel 3" during > >> the middle of the encoding session, and also saw no change. > > > > hm, I'm late on the party, but for Gerd's v4lctl try to RTFM. > > > > The "setchannel" options reads from .xawtv. > > > > For me it still works, but issues with tda827x silicon tuners are known > > walking the ioctls. > > > > Cheers, > > Hermann > > > > > >> But I think I've found the problem: > >> > >>> v4lctl setnorm NTSC; v4lctl setfreqtab us-bcast; v4lctl -v 1 setchannel 3 > >> vid-open: trying: v4l2-old... > >> vid-open: failed: v4l2-old > >> vid-open: trying: v4l2... > >> v4l2: open > >> v4l2: device info: > >> em28xx 0.1.1 / Pinnacle PCTV HD Pro Stick @ usb-:00:1a.7-1 > >> vid-open: ok: v4l2 > >> freq: reading /usr/share/xawtv/Index.map > >> v4l2: tuner cap: > >> v4l2: tuner rxs: > >> v4l2: tuner cur: MONO > >> cmd: "setchannel" "3" > >> v4l2: freq: 0.000 > >> v4l2: close > >> > >> > >> What? freq: 0.000 ? After finding the ivtv package and compiling its > >> utils, I confirm it with this: > >> > >>> v4l2-ctl -F > >> Frequency: 0 (0.00 MHz) > >> > >>> ivtv-tune -c 3 > >> /dev/video0: 61.250 MHz > >> > >>> v4l2-ctl -F > >> Frequency: 980 (61.25 MHz) > >> > >>> v4lctl setchannel 3 > >> > >>> v4l2-ctl -F > >> Frequency: 0 (0.00 MHz) > >> > >> > >> So mysteriously, it seems like v4lctl is just plain not working. And > >> ivtv-tune, on the other hand, is working just fine. After I do that and > >> start Helix Producer, I see channel 3 just like I had hoped. > >> > >> (strangely, v4lctl can do other things fine, like change the norm from > >> NTSC to PAL. It just can't change the channel.) > >> > >> So, sorry that it went off in rabbit trails of the device powering down > >> and so forth. I wonder what happened to my v4lctl program, though? xawtv > >> itself (running in X) seems to work fine when I tell it to change the > >> channel... > >> > >> > >> > >> > >> > >> > >>> Date: Fri, 26 Jun 2009 09:42:06 -0400 > >>> Subject: Re: Bah! How do I change channels? > >>> From: dheitmuel...@kernellabs.com > >>> To: awa...@radix.net > >>> CC: g_adam...@hotmail.com; video4linux-l...@redhat.com; > >>> linux-media@vger.kernel.org > >>> > >>> On Fri, Jun 26, 2009 at 7:50 AM, Andy Walls wrote: > I use either v4l2-ctl or ivtv-tune > > $ ivtv-tune -d /dev/video0 -t us-bcast -c 3 > /dev/video0: 61.250 MHz > > $ v4l2-ctl -d /dev/video0 -f 61.250 > Frequency set to 980 (61.25 MHz) > > > Regards, > Andy > >>> > >>> Hello Andy, > >>> > >>> I had sent George some email off-list with basically the same > >>> commands. I think what might be happening here is the tuner gets > >>> powered down when not in use, so I think it might be powered down > >>> between the v4l-ctl command and the running of the other application. > >>> > >>> I have sent him a series of commands to try where he modprobes the > >>> xc3028 driver with "no_poweroff=1", and we will see if that starts > >>> working. > >>> > >>> 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: Bah! How do I change channels?
A final wrapup (and again, thanks all of you - I'm indebted to you for your help): after booting: > v4l2-ctl -F Frequency: 9076 (567.25 MHz) > ivtv-tune -c 3 /dev/video0: 61.250 MHz > v4l2-ctl -F Frequency: 980 (61.25 MHz) > v4l2-ctl -f 61.25 Frequency set to 980 (61.25 MHz) > v4l2-ctl -F Frequency: 980 (61.25 MHz) > v4lctl setchannel 3 > v4l2-ctl -F Frequency: 0 (0.00 MHz) Conclusion: I'll stick with ivtv-tune or v4l2-ctl and ignore the misbehaving v4lctl Hermann: Thanks, but I think you're mistaking the v4lctl "setstation" command (which relies on .xawtv) and the "setchannel" command (which does not, at least according to the man page.) > Subject: RE: Bah! How do I change channels? > From: hermann-pit...@arcor.de > To: g_adam...@hotmail.com > CC: dheitmuel...@kernellabs.com; awa...@radix.net; > video4linux-l...@redhat.com; linux-media@vger.kernel.org > Date: Sun, 28 Jun 2009 03:39:05 +0200 > > Hi, > > Am Samstag, den 27.06.2009, 00:25 -0400 schrieb George Adams: >> Thanks again to both of you for your help. I gave the no_poweroff flag a >> try, but didn't see any difference. I also tried a "setchannel 3" during the >> middle of the encoding session, and also saw no change. > > hm, I'm late on the party, but for Gerd's v4lctl try to RTFM. > > The "setchannel" options reads from .xawtv. > > For me it still works, but issues with tda827x silicon tuners are known > walking the ioctls. > > Cheers, > Hermann > > >> But I think I've found the problem: >> >>> v4lctl setnorm NTSC; v4lctl setfreqtab us-bcast; v4lctl -v 1 setchannel 3 >> vid-open: trying: v4l2-old... >> vid-open: failed: v4l2-old >> vid-open: trying: v4l2... >> v4l2: open >> v4l2: device info: >> em28xx 0.1.1 / Pinnacle PCTV HD Pro Stick @ usb-:00:1a.7-1 >> vid-open: ok: v4l2 >> freq: reading /usr/share/xawtv/Index.map >> v4l2: tuner cap: >> v4l2: tuner rxs: >> v4l2: tuner cur: MONO >> cmd: "setchannel" "3" >> v4l2: freq: 0.000 >> v4l2: close >> >> >> What? freq: 0.000 ? After finding the ivtv package and compiling its utils, >> I confirm it with this: >> >>> v4l2-ctl -F >> Frequency: 0 (0.00 MHz) >> >>> ivtv-tune -c 3 >> /dev/video0: 61.250 MHz >> >>> v4l2-ctl -F >> Frequency: 980 (61.25 MHz) >> >>> v4lctl setchannel 3 >> >>> v4l2-ctl -F >> Frequency: 0 (0.00 MHz) >> >> >> So mysteriously, it seems like v4lctl is just plain not working. And >> ivtv-tune, on the other hand, is working just fine. After I do that and >> start Helix Producer, I see channel 3 just like I had hoped. >> >> (strangely, v4lctl can do other things fine, like change the norm from NTSC >> to PAL. It just can't change the channel.) >> >> So, sorry that it went off in rabbit trails of the device powering down and >> so forth. I wonder what happened to my v4lctl program, though? xawtv itself >> (running in X) seems to work fine when I tell it to change the channel... >> >> >> >> >> >> >>> Date: Fri, 26 Jun 2009 09:42:06 -0400 >>> Subject: Re: Bah! How do I change channels? >>> From: dheitmuel...@kernellabs.com >>> To: awa...@radix.net >>> CC: g_adam...@hotmail.com; video4linux-l...@redhat.com; >>> linux-media@vger.kernel.org >>> >>> On Fri, Jun 26, 2009 at 7:50 AM, Andy Walls wrote: I use either v4l2-ctl or ivtv-tune $ ivtv-tune -d /dev/video0 -t us-bcast -c 3 /dev/video0: 61.250 MHz $ v4l2-ctl -d /dev/video0 -f 61.250 Frequency set to 980 (61.25 MHz) Regards, Andy >>> >>> Hello Andy, >>> >>> I had sent George some email off-list with basically the same >>> commands. I think what might be happening here is the tuner gets >>> powered down when not in use, so I think it might be powered down >>> between the v4l-ctl command and the running of the other application. >>> >>> I have sent him a series of commands to try where he modprobes the >>> xc3028 driver with "no_poweroff=1", and we will see if that starts >>> working. >>> >>> Devin >>> >>> -- >>> Devin J. Heitmueller - Kernel Labs >>> http://www.kernellabs.com > > _ Windows Live™ SkyDrive™: Get 25 GB of free online storage. http://windowslive.com/online/skydrive?ocid=TXT_TAGLM_WL_SD_25GB_062009-- 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: Bah! How do I change channels?
Hi, Am Samstag, den 27.06.2009, 00:25 -0400 schrieb George Adams: > Thanks again to both of you for your help. I gave the no_poweroff flag a > try, but didn't see any difference. I also tried a "setchannel 3" during the > middle of the encoding session, and also saw no change. hm, I'm late on the party, but for Gerd's v4lctl try to RTFM. The "setchannel" options reads from .xawtv. For me it still works, but issues with tda827x silicon tuners are known walking the ioctls. Cheers, Hermann > But I think I've found the problem: > > > v4lctl setnorm NTSC; v4lctl setfreqtab us-bcast; v4lctl -v 1 setchannel 3 > vid-open: trying: v4l2-old... > vid-open: failed: v4l2-old > vid-open: trying: v4l2... > v4l2: open > v4l2: device info: > em28xx 0.1.1 / Pinnacle PCTV HD Pro Stick @ usb-:00:1a.7-1 > vid-open: ok: v4l2 > freq: reading /usr/share/xawtv/Index.map > v4l2: tuner cap: > v4l2: tuner rxs: > v4l2: tuner cur: MONO > cmd: "setchannel" "3" > v4l2: freq: 0.000 > v4l2: close > > > What? freq: 0.000 ? After finding the ivtv package and compiling its utils, > I confirm it with this: > > > v4l2-ctl -F > Frequency: 0 (0.00 MHz) > > > ivtv-tune -c 3 > /dev/video0: 61.250 MHz > > > v4l2-ctl -F > Frequency: 980 (61.25 MHz) > > > v4lctl setchannel 3 > > > v4l2-ctl -F > Frequency: 0 (0.00 MHz) > > > So mysteriously, it seems like v4lctl is just plain not working. And > ivtv-tune, on the other hand, is working just fine. After I do that and > start Helix Producer, I see channel 3 just like I had hoped. > > (strangely, v4lctl can do other things fine, like change the norm from NTSC > to PAL. It just can't change the channel.) > > So, sorry that it went off in rabbit trails of the device powering down and > so forth. I wonder what happened to my v4lctl program, though? xawtv itself > (running in X) seems to work fine when I tell it to change the channel... > > > > > > > > Date: Fri, 26 Jun 2009 09:42:06 -0400 > > Subject: Re: Bah! How do I change channels? > > From: dheitmuel...@kernellabs.com > > To: awa...@radix.net > > CC: g_adam...@hotmail.com; video4linux-l...@redhat.com; > > linux-media@vger.kernel.org > > > > On Fri, Jun 26, 2009 at 7:50 AM, Andy Walls wrote: > >> I use either v4l2-ctl or ivtv-tune > >> > >> $ ivtv-tune -d /dev/video0 -t us-bcast -c 3 > >> /dev/video0: 61.250 MHz > >> > >> $ v4l2-ctl -d /dev/video0 -f 61.250 > >> Frequency set to 980 (61.25 MHz) > >> > >> > >> Regards, > >> Andy > > > > Hello Andy, > > > > I had sent George some email off-list with basically the same > > commands. I think what might be happening here is the tuner gets > > powered down when not in use, so I think it might be powered down > > between the v4l-ctl command and the running of the other application. > > > > I have sent him a series of commands to try where he modprobes the > > xc3028 driver with "no_poweroff=1", and we will see if that starts > > working. > > > > 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: Bah! How do I change channels?
On Sat, Jun 27, 2009 at 8:17 PM, Andy Walls wrote: > Oh, I'm not against power management. But state is lost - somethings > that's fixable with a lot of work apparently. I was thinking maybe the > V4L2 spec could change. > > I was also pondering maybe the final close() shouldn't be the trigger > for powering devices down. How about the final close() + 30 seconds? > Or the final close() + some user set interval. It seems like scheduling > delayed work to do something like that should be easy enough. That > would require a spec change about state being only preserved until power > management powered the thing down and probably an additional ioctl() > added to set the powerdown delay. The driver could probably default > delay to some interval that would be good for most users. > > I don't know. Just ideas... On the DVB side, there actually is a modprobe parameter for dvb_frontend that allows you to defer putting the device to sleep (defaults to zero seconds). It would be a little trickier to do this in v4l because of the differences in the in-kernel threading (dvb has a dedicated thread for controlling the device). Also, it's globally defined, which is good from a consistency standpoint but annoying in cases where some devices really should defer sleep for some period. For example, the HVR-950q's i2c implementation is *really* slow (8 seconds to load the xc5000 firmware). If I had been able to control the delay on a per-device basis in the board definition I could have set it to sleep after 10 seconds by default, which would have helped in cases like the Kaffeine channel scanner which continuously closes/opens the frontend as it scans. Anyway, it's good to discuss this issue, since I hadn't really considered the implications of the power management until George's email. I'm just not sure what the best approach is at this point and will have to give it some more thought. 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: Bah! How do I change channels?
On Sat, 2009-06-27 at 17:57 -0400, Robert Krakora wrote: > Andy: > > I too care about the environment. I am trying to find some extra time > to figure out if my KWorld 330U USB TV devices are actually going into > low power mode or not. I would say not as they get really hot, so I > unplug them when I am not using them. I told Devin I would work on > this and I have an accurate analog amp meter, but I got very busy at > work and at home with the kids. However, I don't believe that the > answer is to disable power management as some of these parts get so > hot that leaving them in a powered state and tuned to a channel will > probably damage the device. Remember, these are silicon tuners, not > the old discrete tuners that have way more surface area to dissipate > heat. Oh, I'm not against power management. But state is lost - somethings that's fixable with a lot of work apparently. I was thinking maybe the V4L2 spec could change. I was also pondering maybe the final close() shouldn't be the trigger for powering devices down. How about the final close() + 30 seconds? Or the final close() + some user set interval. It seems like scheduling delayed work to do something like that should be easy enough. That would require a spec change about state being only preserved until power management powered the thing down and probably an additional ioctl() added to set the powerdown delay. The driver could probably default delay to some interval that would be good for most users. I don't know. Just ideas... 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: Bah! How do I change channels?
On Sat, Jun 27, 2009 at 12:25 AM, George Adams wrote: > > Thanks again to both of you for your help. I gave the no_poweroff flag a > try, but didn't see any difference. I also tried a "setchannel 3" during the > middle of the encoding session, and also saw no change. > > But I think I've found the problem: > >> v4lctl setnorm NTSC; v4lctl setfreqtab us-bcast; v4lctl -v 1 setchannel 3 > vid-open: trying: v4l2-old... > vid-open: failed: v4l2-old > vid-open: trying: v4l2... > v4l2: open > v4l2: device info: > em28xx 0.1.1 / Pinnacle PCTV HD Pro Stick @ usb-:00:1a.7-1 > vid-open: ok: v4l2 > freq: reading /usr/share/xawtv/Index.map > v4l2: tuner cap: > v4l2: tuner rxs: > v4l2: tuner cur: MONO > cmd: "setchannel" "3" > v4l2: freq: 0.000 > v4l2: close > > > What? freq: 0.000 ? After finding the ivtv package and compiling its utils, > I confirm it with this: > >> v4l2-ctl -F > Frequency: 0 (0.00 MHz) > >> ivtv-tune -c 3 > /dev/video0: 61.250 MHz > >> v4l2-ctl -F > Frequency: 980 (61.25 MHz) > >> v4lctl setchannel 3 > >> v4l2-ctl -F > Frequency: 0 (0.00 MHz) > > > So mysteriously, it seems like v4lctl is just plain not working. And > ivtv-tune, on the other hand, is working just fine. After I do that and > start Helix Producer, I see channel 3 just like I had hoped. > > (strangely, v4lctl can do other things fine, like change the norm from NTSC > to PAL. It just can't change the channel.) > > So, sorry that it went off in rabbit trails of the device powering down and > so forth. I wonder what happened to my v4lctl program, though? xawtv itself > (running in X) seems to work fine when I tell it to change the channel... > > > > > > >> Date: Fri, 26 Jun 2009 09:42:06 -0400 >> Subject: Re: Bah! How do I change channels? >> From: dheitmuel...@kernellabs.com >> To: awa...@radix.net >> CC: g_adam...@hotmail.com; video4linux-l...@redhat.com; >> linux-media@vger.kernel.org >> >> On Fri, Jun 26, 2009 at 7:50 AM, Andy Walls wrote: >>> I use either v4l2-ctl or ivtv-tune >>> >>> $ ivtv-tune -d /dev/video0 -t us-bcast -c 3 >>> /dev/video0: 61.250 MHz >>> >>> $ v4l2-ctl -d /dev/video0 -f 61.250 >>> Frequency set to 980 (61.25 MHz) >>> >>> >>> Regards, >>> Andy >> >> Hello Andy, >> >> I had sent George some email off-list with basically the same >> commands. I think what might be happening here is the tuner gets >> powered down when not in use, so I think it might be powered down >> between the v4l-ctl command and the running of the other application. >> >> I have sent him a series of commands to try where he modprobes the >> xc3028 driver with "no_poweroff=1", and we will see if that starts >> working. >> >> Devin >> >> -- >> Devin J. Heitmueller - Kernel Labs >> http://www.kernellabs.com > _ > Lauren found her dream laptop. Find the PC that’s right for you. > http://www.microsoft.com/windows/choosepc/?ocid=ftp_val_wl_290 > > -- > video4linux-list mailing list > Unsubscribe mailto:video4linux-list-requ...@redhat.com?subject=unsubscribe > https://www.redhat.com/mailman/listinfo/video4linux-list > > George: Try 'v4l2-ctl -d /dev/video0 -f 61.250' to tune to broadcast channel 3 per one of Devin's e-mails to you. I do not know why setchannel is not working for you. I use both ivtv-tune v4l2-ctl and both do work and v4l2-ctl should work in this instance for you. I always open my USB TV device via mplayer not specifiying a channel and then use ivtv-tune executed by a script that is run by an application to tune channels. I happened to notice that if I closed mplayer and used ivtv-tune to tune to another channel and then open my USB TV device, it would be tuned to that channel. Andy: I too care about the environment. I am trying to find some extra time to figure out if my KWorld 330U USB TV devices are actually going into low power mode or not. I would say not as they get really hot, so I unplug them when I am not using them. I told Devin I would work on this and I have an accurate analog amp meter, but I got very busy at work and at home with the kids. However, I don't believe that the answer is to disable power management as some of these parts get so hot that leaving them in a powered state and tuned to a channel will probably damage the device. Remember, these are silicon tuners, not the old discrete tuners that have way more surface area to dissipate heat. Devin: Great job answering questions as usual. ;-) Best Regards, -- Rob Krakora Senior Software Engineer MessageNet Systems 101 East Carmel Dr. Suite 105 Carmel, IN 46032 (317)566-1677 Ext. 206 (317)663-0808 Fax -- 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: Yuan EC372S: dib7000p_i2c_enumeration failed
Hi Antti... no idea... I think I saw similar errors when the reset GPIO of the tuner was not on the correct position in some cards... but I'm not sure. Frankly with this card I doubt it never worked, since it was only confirmed by one person... so perhaps that GPIO missplacement is possible or even worse... I can't help much... Albert En/na Antti Palosaari ha escrit: moikka! I just got USB-ExpressCard converter and tested one of my old sticks. Here is result. Any idea? dib0700: stk7700P2_frontend_attach: dib7000p_i2c_enumeration failed. Cannot continue regards Antti -- 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 Jun 27 19:00:02 CEST 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 12133:05e6c5c9bcb4 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.1-armv5: OK linux-2.6.30-armv5: OK linux-2.6.31-rc1-armv5: ERRORS linux-2.6.27-armv5-ixp: WARNINGS linux-2.6.28-armv5-ixp: WARNINGS linux-2.6.29.1-armv5-ixp: WARNINGS linux-2.6.30-armv5-ixp: WARNINGS linux-2.6.31-rc1-armv5-ixp: ERRORS linux-2.6.28-armv5-omap2: WARNINGS linux-2.6.29.1-armv5-omap2: WARNINGS linux-2.6.30-armv5-omap2: WARNINGS linux-2.6.31-rc1-armv5-omap2: ERRORS linux-2.6.22.19-i686: WARNINGS linux-2.6.23.12-i686: WARNINGS linux-2.6.24.7-i686: WARNINGS linux-2.6.25.11-i686: WARNINGS linux-2.6.26-i686: WARNINGS linux-2.6.27-i686: WARNINGS linux-2.6.28-i686: WARNINGS linux-2.6.29.1-i686: WARNINGS linux-2.6.30-i686: WARNINGS linux-2.6.31-rc1-i686: ERRORS 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.1-m32r: OK linux-2.6.30-m32r: OK linux-2.6.31-rc1-m32r: ERRORS linux-2.6.30-mips: WARNINGS linux-2.6.31-rc1-mips: ERRORS linux-2.6.27-powerpc64: WARNINGS linux-2.6.28-powerpc64: WARNINGS linux-2.6.29.1-powerpc64: WARNINGS linux-2.6.30-powerpc64: WARNINGS linux-2.6.31-rc1-powerpc64: ERRORS 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: OK linux-2.6.27-x86_64: OK linux-2.6.28-x86_64: OK linux-2.6.29.1-x86_64: OK linux-2.6.30-x86_64: WARNINGS linux-2.6.31-rc1-x86_64: ERRORS sparse (linux-2.6.30): OK sparse (linux-2.6.31-rc1): OK linux-2.6.16.61-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: ERRORS linux-2.6.19.5-i686: WARNINGS linux-2.6.20.21-i686: WARNINGS linux-2.6.21.7-i686: WARNINGS linux-2.6.16.61-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: ERRORS linux-2.6.19.5-x86_64: WARNINGS linux-2.6.20.21-x86_64: WARNINGS linux-2.6.21.7-x86_64: WARNINGS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.tar.bz2 The V4L2 specification failed to build, but the last compiled spec 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: [PATCH 3/3 - v0] davinci: platform changes to support vpfe camera capture
> > --- a/arch/arm/mach-davinci/board-dm355-evm.c
> > +++ b/arch/arm/mach-davinci/board-dm355-evm.c
> > @@ -136,10 +136,66 @@ static void dm355evm_mmcsd_gpios(unsigned gpio)
> > dm355evm_mmc_gpios = gpio;
> > }
> >
> > -static struct tvp514x_platform_data tvp5146_pdata = {
> > - .clk_polarity = 0,
> > - .hs_polarity = 1,
> > - .vs_polarity = 1
Clearly this patch is against neither mainline nor the
current DaVinci GIT tree... I suggest reissuing against
mainline, now that it's got most DM355 stuff.
> > +/*
> > + * MSP430 supports RTC, card detection, input from IR remote, and
> > + * a bit more. It triggers interrupts on GPIO(7) from pressing
> > + * buttons on the IR remote, and for card detect switches.
> > + */
> > +static struct i2c_client *dm355evm_msp;
> > +
> > +static int dm355evm_msp_probe(struct i2c_client *client,
> > + const struct i2c_device_id *id)
> > +{
> > + dm355evm_msp = client;
> > + return 0;
> > +}
> > +
> > +static int dm355evm_msp_remove(struct i2c_client *client)
> > +{
> > + dm355evm_msp = NULL;
> > + return 0;
> > +}
> > +
> > +static const struct i2c_device_id dm355evm_msp_ids[] = {
> > + { "dm355evm_msp", 0, },
> > + { /* end of list */ },
> > +};
Needless to say: NAK on all this. There is already a
drivers/mfd/dm355evm_msp.c managing this device. You
shouldn't have video code crap all over it.
It currently sets up for TVP5146 based capture iff that
driver is configured (else the external imager); and
exports the NTSC/nPAL switch setting as a GPIO that's
also visible in sysfs.
I suggest the first revision of this VPFE stuff use
the existing setup. A later patch could add some
support for runtime reconfiguration.
- Dave
> > +
> > +static struct i2c_driver dm355evm_msp_driver = {
> > + .driver.name= "dm355evm_msp",
> > + .id_table = dm355evm_msp_ids,
> > + .probe = dm355evm_msp_probe,
> > + .remove = dm355evm_msp_remove,
> > +};
> > +
--
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] w_scan: allow frontend and demux selection
I found a problem with w_scan. With the following system
(2x HVR-4000):
/dev/dvb/adapter0/frontend0 : DVB-S/S2
/dev/dvb/adapter0/frontend1 : DVB-T
/dev/dvb/adapter1/frontend0 : DVB-S/S2
/dev/dvb/adapter1/frontend1 : DVB-T
there is no way to do a (DVB-T) scan on adapter1/frontend1 because
1)the automatic selector will always choose adapter0/frontend1
and
2)the -a option (manual adapter) always forces frontend = 0.
Here's a patch for w_scan which allows one to precisely choose
which frontend is scanned by adding options to specify frontend (-n)
and demux (-d), to be used with the existing adapter (-a) option.
Hans
Signed-off-by: Hans Werner
--- scan.c.orig 2009-06-26 23:56:15.0 +0100
+++ scan.c 2009-06-27 15:33:43.0 +0100
@@ -2418,7 +2418,9 @@
" 6 = VDR-1.6.x (default)\n"
" 7 = VDR-1.7.x\n"
".Device..\n"
- " -a Nuse device /dev/dvb/adapterN/ [default: auto detect]\n"
+ " -a Ause adapter A /dev/dvb/adapterA/frontend0 [default:
auto detect]\n"
+ " -n N(with -a ) use frontend N /dev/dvb/adapterA/frontendN
[default: auto detect]\n"
+ " -d D(with -a ) use demux D/dev/dvb/adapterA/demuxD
[default: auto detect]\n"
" -F use long filter timeout\n"
" -t Ntuning timeout\n"
" 1 = fastest [default]\n"
@@ -2520,11 +2522,17 @@
flags.version = version;
start_time = time(NULL);
- while ((opt = getopt(argc, argv,
"a:c:e:f:hi:kl:o:p:qr:s:t:vxA:D:E:FHI:O:PQ:R:S:T:VX")) != -1) {
+ while ((opt = getopt(argc, argv,
"a:n:d:c:e:f:hi:kl:o:p:qr:s:t:vxA:D:E:FHI:O:PQ:R:S:T:VX")) != -1) {
switch (opt) {
case 'a': //adapter
adapter = strtoul(optarg, NULL, 0);
break;
+ case 'n': //frontend
+ frontend = strtoul(optarg, NULL, 0);
+ break;
+ case 'd': //demux
+ demux = strtoul(optarg, NULL, 0);
+ break;
case 'c': //country setting
country=strdup(optarg);
if (0 == strcasecmp(country, "?")) {
--
Release early, release often.
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
--
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: v4l2_int_device vs v4l2_subdev?
On Friday 26 June 2009 16:43:52 Aguirre Rodriguez, Sergio Alberto wrote: > > > But in user space there is nothing changed having access to > > > device and control them. > > > As you know, subdev and int-device is all about how to bind > > > interface(or host?) and device and make them communicated each other. > > > But using subdev device driver with int-device supporting interface > > > (or host) device driver? it won't make any communication. > > > So if you are running out of time with your project, you'd better use > > > old driver of TVP. Like TVP driver in kernel 2.6.28 I suppose. But if > > > you have enough time and wanna be challenging, try to convert > > > in-device based omap3 camera interface driver to subdev supporting > > > one. > > > > Someone's got to do this. v4l2_subdev is the future and it has many > > advantages over the older interfaces. The ability to be able to use the > > same i2c driver in anything from USB webcams to PCI capture cards to > > omap/davinci embedded platforms is very powerful. > > Hi, > > We have already this framework migration planned, but we haven't been > able to do it, because we are still solving stability issues on the driver. > > I beg for your patience, and i hope i can get my hands on this pretty soon. > > I'll be updating my tree when i have something. Sorry, I was a bit harsh there. It was not aimed at you, Sergio, but at others who read this. I just want to make sure that everyone is aware of this new framework and how important it is to migrate to this framework. Moving to a new framework can be a very time consuming process, but I think it is very important to try and get this finished as soon as possible. With the inclusion of the omap and davinci drivers in the kernel I'm sure a lot of new sensor and video drivers will start popping up. And if they are written as subdev drivers from the start, then that will make inclusion in the kernel much easier. Since sensors especially are also used in combination with other SoCs and webcams it will be very useful indeed to have fully reusable sensor drivers. It's an very active period for the v4l-dvb subsystem with a lot of new drivers and new functionality so any design decisions taken will be with us for a long time. The extra time spent now on moving to v4l2_subdev and thinking on how to design new APIs for new functionality is well worth it. I consider this a critical time for the v4l subsystem in particular: once all drivers use v4l2_subdev we will have a very powerful foundation to build on. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3 - v0] davinci: platform changes to support vpfe camera capture
On Saturday 27 June 2009 00:05:48 m-kariche...@ti.com wrote:
> From: Muralidharan Karicheri
>
> Following are the changes:-
> 1) moved i2c board specific part to sub device configuration
> structure so that sub device can be loaded from vpfe capture
> using the new v4l2_i2c_new_subdev_board() api
> 2) adding mt9t031 sub device configuration information for
> DM355 as part of camera capture support to vpfe capture
> 3) adding support to setup raw data path and i2c switch
> when capturing from mt9t031
>
> NOTE: Depends on v3 version of vpfe capture driver patch
>
> Mandatory Reviewers: Kevin Hilman
> Mandatory Reviewers: Hans Verkuil
>
> Signed-off-by: Muralidharan Karicheri
> ---
> Applies to DaVinci GIT Tree
>
> arch/arm/mach-davinci/board-dm355-evm.c | 208
> --
> arch/arm/mach-davinci/board-dm644x-evm.c | 24 ++--
> 2 files changed, 210 insertions(+), 22 deletions(-)
>
> diff --git a/arch/arm/mach-davinci/board-dm355-evm.c
> b/arch/arm/mach-davinci/board-dm355-evm.c
> index 513be53..a781ca2 100644
> --- a/arch/arm/mach-davinci/board-dm355-evm.c
> +++ b/arch/arm/mach-davinci/board-dm355-evm.c
> @@ -136,10 +136,66 @@ static void dm355evm_mmcsd_gpios(unsigned gpio)
> dm355evm_mmc_gpios = gpio;
> }
>
> -static struct tvp514x_platform_data tvp5146_pdata = {
> - .clk_polarity = 0,
> - .hs_polarity = 1,
> - .vs_polarity = 1
> +/*
> + * MSP430 supports RTC, card detection, input from IR remote, and
> + * a bit more. It triggers interrupts on GPIO(7) from pressing
> + * buttons on the IR remote, and for card detect switches.
> + */
> +static struct i2c_client *dm355evm_msp;
> +
> +static int dm355evm_msp_probe(struct i2c_client *client,
> + const struct i2c_device_id *id)
> +{
> + dm355evm_msp = client;
> + return 0;
> +}
> +
> +static int dm355evm_msp_remove(struct i2c_client *client)
> +{
> + dm355evm_msp = NULL;
> + return 0;
> +}
> +
> +static const struct i2c_device_id dm355evm_msp_ids[] = {
> + { "dm355evm_msp", 0, },
> + { /* end of list */ },
> +};
> +
> +static struct i2c_driver dm355evm_msp_driver = {
> + .driver.name= "dm355evm_msp",
> + .id_table = dm355evm_msp_ids,
> + .probe = dm355evm_msp_probe,
> + .remove = dm355evm_msp_remove,
> +};
> +
> +#define PCA9543A_I2C_ADDR (0x73)
> +
> +static struct i2c_client *pca9543a;
> +
> +static int pca9543a_probe(struct i2c_client *client,
> + const struct i2c_device_id *id)
> +{
> + pca9543a = client;
> + return 0;
> +}
> +
> +static int pca9543a_remove(struct i2c_client *client)
> +{
> + pca9543a = NULL;
> + return 0;
> +}
> +
> +static const struct i2c_device_id pca9543a_ids[] = {
> + { "PCA9543A", 0, },
> + { /* end of list */ },
> +};
> +
> +/* This is for i2c driver for the MT9T031 header i2c switch */
> +static struct i2c_driver pca9543a_driver = {
> + .driver.name= "PCA9543A",
> + .id_table = pca9543a_ids,
> + .probe = pca9543a_probe,
> + .remove = pca9543a_remove,
> };
>
> static struct i2c_board_info dm355evm_i2c_info[] = {
> @@ -147,13 +203,22 @@ static struct i2c_board_info dm355evm_i2c_info[] = {
> .platform_data = dm355evm_mmcsd_gpios,
> },
> {
> - I2C_BOARD_INFO("tvp5146", 0x5d),
> - .platform_data = &tvp5146_pdata,
> + I2C_BOARD_INFO("PCA9543A", 0x73),
> },
> /* { plus irq }, */
> /* { I2C_BOARD_INFO("tlv320aic3x", 0x1b), }, */
> };
>
> +/* have_sensor() - Check if we have support for sensor interface */
> +static inline int have_sensor(void)
> +{
> +#ifdef CONFIG_SOC_CAMERA_MT9T031
> + return 1;
> +#else
> + return 0;
> +#endif
> +}
> +
> static void __init evm_init_i2c(void)
> {
> davinci_init_i2c(&i2c_pdata);
> @@ -161,9 +226,12 @@ static void __init evm_init_i2c(void)
> gpio_request(5, "dm355evm_msp");
> gpio_direction_input(5);
> dm355evm_i2c_info[0].irq = gpio_to_irq(5);
> -
> + i2c_add_driver(&dm355evm_msp_driver);
> + if (have_sensor())
> + i2c_add_driver(&pca9543a_driver);
> i2c_register_board_info(1, dm355evm_i2c_info,
> ARRAY_SIZE(dm355evm_i2c_info));
> +
> }
>
> static struct resource dm355evm_dm9000_rsrc[] = {
> @@ -190,6 +258,104 @@ static struct platform_device dm355evm_dm9000 = {
> .num_resources = ARRAY_SIZE(dm355evm_dm9000_rsrc),
> };
>
> +/**
> + * dm355evm_enable_raw_data_path() - Enable/Disable raw data path
> + * @en: enable/disbale flag
> + */
> +static int dm355evm_enable_raw_data_path(int en)
> +{
> + static char txbuf[2] = { 8, 0x80 };
> + int status;
> + struct i2c_msg msg = {
> + .flags = 0,
> + .len = 2,
> + .buf = (void __force *)txbuf,
> + };
> +
> + if (!en)
> + txbuf[
Re: [PATCH 2/3 - v0] V4L: ccdc driver - adding support for camera capture
On Saturday 27 June 2009 00:05:10 m-kariche...@ti.com wrote: > From: Muralidharan Karicheri > > Following updates to ccdc driver :- > 1) Adding support for camera capture using mt9t031 > 2) Changed default resolution for ycbcr capture to NTSC to match > with tvp514x driver. > 3) Returns proper error code from ccdc_init (comments against previous > patch > version v3) > > Mandatory Reviewers: Hans Verkuil > > Signed-off-by: Muralidharan Karicheri > --- > Applies to v4l-dvb repository > > drivers/media/video/davinci/dm355_ccdc.c | 21 + > drivers/media/video/davinci/dm644x_ccdc.c | 13 + > include/media/davinci/dm355_ccdc.h|2 +- > include/media/davinci/dm644x_ccdc.h |2 +- > 4 files changed, 24 insertions(+), 14 deletions(-) > Looks OK. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom -- 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/3 - v0] V4L: vpfe capture driver - adding support for camera capture
On Saturday 27 June 2009 00:04:45 m-kariche...@ti.com wrote:
> From: Muralidharan Karicheri
>
> Re-sending adding Hans to CC
>
> Following updates to vpfe capture driver :-
> 1) Adding support for camera capture using mt9t031 driver
> (A patch for mt9t031 is already sent for review)
> 2) Use v4l2_i2c_new_subdev_board() for loading sub devices
> 3) Fixed a bug in s_input and g_input handler
> 4) removed g_std() since it is already taken care by
> v4l2 framework based on current_norm
> 5) return proper error code from ccdc register function
>
> Mandatory Reviewers: Hans Verkuil
>
> NOTE: Requires support for v4l2_i2c_new_subdev_board() which was recently
> added to v4l2 framework by Hans Verkuil.
>
> Signed-off-by: Muralidharan Karicheri
> ---
> Applies to v4l-dvb repository
>
> drivers/media/video/davinci/vpfe_capture.c | 356
>
> include/media/davinci/vpfe_capture.h | 16 ++
> 2 files changed, 271 insertions(+), 101 deletions(-)
>
> diff --git a/drivers/media/video/davinci/vpfe_capture.c
> b/drivers/media/video/davinci/vpfe_capture.c
> index a4cbe2a..414a7b4 100644
> --- a/drivers/media/video/davinci/vpfe_capture.c
> +++ b/drivers/media/video/davinci/vpfe_capture.c
> @@ -59,7 +59,6 @@
> *TODO list
> * - Support multiple REQBUF after open
> * - Support for de-allocating buffers through REQBUF
> - * - Support for Raw Bayer RGB capture
> * - Support for chaining Image Processor
> * - Support for static allocation of buffers
> * - Support for USERPTR IO
> @@ -74,18 +73,29 @@
> #include
> #include
> #include
> -#include
> -#include
> #include "ccdc_hw_device.h"
>
> static int debug;
> static u32 numbuffers = 3;
> static u32 bufsize = (720 * 576 * 2);
> +static int interface;
>
> +module_param(interface, bool, S_IRUGO);
> module_param(numbuffers, uint, S_IRUGO);
> module_param(bufsize, uint, S_IRUGO);
> -module_param(debug, int, 0644);
> -
> +module_param(debug, bool, 0644);
> +
> +/**
> + * VPFE capture can be used for capturing video such as from TVP5146 or
> TVP7002
> + * and for capture raw bayer data from camera sensors such as MT9T031. At
> this
> + * point there is problem in co-existence of mt9t031 and tvp5146 due to i2c
> + * address collision. So set the variable below from bootargs to do either
> video
> + * capture or camera capture.
> + * interface = 0 - video capture (from TVP514x or such),
> + * interface = 1 - Camera capture (from MT9T031 or such)
> + * Re-visit this when we fix the co-existence issue
> + */
> +MODULE_PARM_DESC(interface, "interface 0-1 (default:0)");
> MODULE_PARM_DESC(numbuffers, "buffer count (default:3)");
> MODULE_PARM_DESC(bufsize, "buffer size in bytes (default:720 x 576 x 2)");
> MODULE_PARM_DESC(debug, "Debug level 0-1");
> @@ -145,6 +155,7 @@ static const struct vpfe_pixel_format vpfe_pix_fmts[] = {
> .pixelformat = V4L2_PIX_FMT_SBGGR8,
> },
> .bpp = 1,
> + .subdev_pix_fmt = V4L2_PIX_FMT_SGRBG10,
> },
> {
> .fmtdesc = {
> @@ -154,6 +165,7 @@ static const struct vpfe_pixel_format vpfe_pix_fmts[] = {
> .pixelformat = V4L2_PIX_FMT_SBGGR16,
> },
> .bpp = 2,
> + .subdev_pix_fmt = V4L2_PIX_FMT_SGRBG10,
> },
> {
> .fmtdesc = {
> @@ -163,6 +175,7 @@ static const struct vpfe_pixel_format vpfe_pix_fmts[] = {
> .pixelformat = V4L2_PIX_FMT_SGRBG10DPCM8,
> },
> .bpp = 1,
> + .subdev_pix_fmt = V4L2_PIX_FMT_SGRBG10,
> },
> {
> .fmtdesc = {
> @@ -172,6 +185,7 @@ static const struct vpfe_pixel_format vpfe_pix_fmts[] = {
> .pixelformat = V4L2_PIX_FMT_UYVY,
> },
> .bpp = 2,
> + .subdev_pix_fmt = V4L2_PIX_FMT_UYVY,
> },
> {
> .fmtdesc = {
> @@ -181,6 +195,7 @@ static const struct vpfe_pixel_format vpfe_pix_fmts[] = {
> .pixelformat = V4L2_PIX_FMT_YUYV,
> },
> .bpp = 2,
> + .subdev_pix_fmt = V4L2_PIX_FMT_UYVY,
> },
> {
> .fmtdesc = {
> @@ -190,12 +205,15 @@ static const struct vpfe_pixel_format vpfe_pix_fmts[] =
> {
> .pixelformat = V4L2_PIX_FMT_NV12,
> },
> .bpp = 1,
> + .subdev_pix_fmt = V4L2_PIX_FMT_UYVY,
> },
> };
>
> -/*
> - * vpfe_lookup_pix_format()
> - * lookup an entry in the vpfe pix format table based on pix_format
> +/**
> + * vpfe_lookup_pix_format() - lookup an entry in the vpfe pix format table
> + * @pix_format: v4l pix format
> + * This function lookup an entry in the vpfe pix format table based on
> + * pix_format
> */
> static const struct vpfe_pixel_format *vpfe_lookup_p
Re: [linux-dvb] Support for Compro VideoMate S350 - Testing Results
On 27 June 2009 12:09:20 O&M Ugarcina wrote: > Hello Igor , > > I want to thank you for making those patches available . I have been > able to patch the latest HG pull and to compile and install the drivers > . I decided to install the whole lot as it was a bit hard to workout > just the ko's responsible for the S350 . After installing the card I > have this from dmesg : > > saa7130/34: v4l2 driver version 0.2.15 loaded > saa7134 :04:01.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22 > saa7130[0]: found at :04:01.0, rev: 1, irq: 22, latency: 64, mmio: > 0xfeaffc00 > saa7130[0]: subsystem: 185b:c900, board: Compro VideoMate S350/S300 > [card=169,autodetected] > saa7130[0]: board init: gpio is 843f00 > input: saa7134 IR (Compro VideoMate S3 as > /devices/pci:00/:00:1e.0/:04:01.0/input/input5 > iTCO_vendor_support: vendor-support=0 > iTCO_wdt: Intel TCO WatchDog Timer Driver v1.03 (30-Apr-2008) > iTCO_wdt: Found a ICH8 or ICH8R TCO device (Version=2, TCOBASE=0x0860) > iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0) > parport_pc 00:0b: reported by Plug and Play ACPI > parport0: PC-style at 0x378 (0x778), irq 7 [PCSPP,TRISTATE,EPP] > saa7130[0]: i2c eeprom 00: 5b 18 00 c9 54 20 1c 00 43 43 a9 1c 55 d2 b2 92 > saa7130[0]: i2c eeprom 10: 00 ff 86 0f ff 20 ff ff ff ff ff ff ff ff ff ff > saa7130[0]: i2c eeprom 20: 01 40 01 02 02 01 03 01 08 ff 00 87 ff ff ff ff > saa7130[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > saa7130[0]: i2c eeprom 40: ff d6 00 c0 86 1c 02 01 02 ff ff ff ff ff ff ff > saa7130[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff cb > saa7130[0]: i2c eeprom 60: 30 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > saa7130[0]: i2c eeprom 70: 00 00 00 10 03 9c ff ff ff ff ff ff ff ff ff ff > saa7130[0]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > saa7130[0]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > saa7130[0]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > saa7130[0]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > saa7130[0]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > saa7130[0]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > saa7130[0]: i2c eeprom e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > saa7130[0]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > saa7130[0]: registered device video0 [v4l2] > saa7130[0]: registered device vbi0 > i801_smbus :00:1f.3: enabling device (0001 -> 0003) > i801_smbus :00:1f.3: PCI INT C -> GSI 18 (level, low) -> IRQ 18 > ACPI: I/O resource :00:1f.3 [0x400-0x41f] conflicts with ACPI region > SMRG [0x400-0x40f] > ACPI: Device needs an ACPI driver > ppdev: user-space parallel port driver > dvb_init() allocating 1 frontend > HDA Intel :00:1b.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22 > HDA Intel :00:1b.0: setting latency timer to 64 > cx88/0: cx2388x v4l2 driver version 0.0.7 loaded > cx88/2: cx2388x MPEG-TS Driver Manager version 0.0.7 loaded > DVB: registering new adapter (saa7130[0]) > DVB: registering adapter 0 frontend 0 (Zarlink ZL10313 DVB-S). > > > I was able to tune into my favourite satellite with mythtv with no > problems . I also was able to tune to another satellite using the mythtv > configuration for 4 way diseqc . So 4 way diseqc works fine for me . > Picture is satble and very good , sound also is ok . I will just run it > now to see how the system stability is over a longer period of time . > > One small issue I have noticed : and that is in mythtv the signal > strength indicator shows very low with S350 now . Before I was getting > with TT1500S around 79 to 89% while now with S350 I see about 18% for > the same channel . It is not about more or less sensitivity, it is about how to represent :( I have positive reports about Compro S350 in russian also. http://forum.free-x.de/wbb/index.php?page=Thread&threadID=474 I will try to push :) > > Best Regards > > Milorad Best Regards Igor -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] Support for Compro VideoMate S350 - Testing Results
Hello Igor , I want to thank you for making those patches available . I have been able to patch the latest HG pull and to compile and install the drivers . I decided to install the whole lot as it was a bit hard to workout just the ko's responsible for the S350 . After installing the card I have this from dmesg : saa7130/34: v4l2 driver version 0.2.15 loaded saa7134 :04:01.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22 saa7130[0]: found at :04:01.0, rev: 1, irq: 22, latency: 64, mmio: 0xfeaffc00 saa7130[0]: subsystem: 185b:c900, board: Compro VideoMate S350/S300 [card=169,autodetected] saa7130[0]: board init: gpio is 843f00 input: saa7134 IR (Compro VideoMate S3 as /devices/pci:00/:00:1e.0/:04:01.0/input/input5 iTCO_vendor_support: vendor-support=0 iTCO_wdt: Intel TCO WatchDog Timer Driver v1.03 (30-Apr-2008) iTCO_wdt: Found a ICH8 or ICH8R TCO device (Version=2, TCOBASE=0x0860) iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0) parport_pc 00:0b: reported by Plug and Play ACPI parport0: PC-style at 0x378 (0x778), irq 7 [PCSPP,TRISTATE,EPP] saa7130[0]: i2c eeprom 00: 5b 18 00 c9 54 20 1c 00 43 43 a9 1c 55 d2 b2 92 saa7130[0]: i2c eeprom 10: 00 ff 86 0f ff 20 ff ff ff ff ff ff ff ff ff ff saa7130[0]: i2c eeprom 20: 01 40 01 02 02 01 03 01 08 ff 00 87 ff ff ff ff saa7130[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7130[0]: i2c eeprom 40: ff d6 00 c0 86 1c 02 01 02 ff ff ff ff ff ff ff saa7130[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff cb saa7130[0]: i2c eeprom 60: 30 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7130[0]: i2c eeprom 70: 00 00 00 10 03 9c ff ff ff ff ff ff ff ff ff ff saa7130[0]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7130[0]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7130[0]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7130[0]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7130[0]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7130[0]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7130[0]: i2c eeprom e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7130[0]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7130[0]: registered device video0 [v4l2] saa7130[0]: registered device vbi0 i801_smbus :00:1f.3: enabling device (0001 -> 0003) i801_smbus :00:1f.3: PCI INT C -> GSI 18 (level, low) -> IRQ 18 ACPI: I/O resource :00:1f.3 [0x400-0x41f] conflicts with ACPI region SMRG [0x400-0x40f] ACPI: Device needs an ACPI driver ppdev: user-space parallel port driver dvb_init() allocating 1 frontend HDA Intel :00:1b.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22 HDA Intel :00:1b.0: setting latency timer to 64 cx88/0: cx2388x v4l2 driver version 0.0.7 loaded cx88/2: cx2388x MPEG-TS Driver Manager version 0.0.7 loaded DVB: registering new adapter (saa7130[0]) DVB: registering adapter 0 frontend 0 (Zarlink ZL10313 DVB-S). I was able to tune into my favourite satellite with mythtv with no problems . I also was able to tune to another satellite using the mythtv configuration for 4 way diseqc . So 4 way diseqc works fine for me . Picture is satble and very good , sound also is ok . I will just run it now to see how the system stability is over a longer period of time . One small issue I have noticed : and that is in mythtv the signal strength indicator shows very low with S350 now . Before I was getting with TT1500S around 79 to 89% while now with S350 I see about 18% for the same channel . Best Regards Milorad -- 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://udev.netup.ru/hg/v4l-dvb-aospan
Mauro, Please pulll changes: 1. correct init values in cnt_storage for TS continuity check: http://udev.netup.ru/cgi-bin/hgwebdir.cgi/v4l-dvb-aospan/rev/f753dd0f27c9 2. Show speed of transport stream in Kbit/sec: http://udev.netup.ru/cgi-bin/hgwebdir.cgi/v4l-dvb-aospan/rev/91923e3471ac for example, data obtained from DVB-S2 transponder from Eutelsat W4: Jun 27 12:06:01 udev TS speed 58608 Kbits/sec Jun 27 12:06:03 udev TS speed 58422 Kbits/sec Jun 27 12:06:04 udev TS speed 58608 Kbits/sec for DVB-S1 transponder from the same satellite: Jun 27 12:07:00 udev TS speed 37108 Kbits/sec Jun 27 12:07:02 udev TS speed 37089 Kbits/sec Jun 27 12:07:04 udev TS speed 37202 Kbits/sec this feature can be enabled using following command: "echo 1 > /sys/module/dvb_core/parameters/dvb_demux_speedcheck" and disabled by following command: "echo 0 > /sys/module/dvb_core/parameters/dvb_demux_speedcheck" -- Abylai Ospan NetUP Inc. smime.p7s Description: S/MIME cryptographic signature
