[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:Fri Sep 25 19:00:03 CEST 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 13041:a798c751f06d 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-armv5: OK linux-2.6.27-armv5-ixp: ERRORS linux-2.6.28-armv5-ixp: ERRORS linux-2.6.29.1-armv5-ixp: ERRORS linux-2.6.30-armv5-ixp: ERRORS linux-2.6.31-armv5-ixp: ERRORS linux-2.6.28-armv5-omap2: OK linux-2.6.29.1-armv5-omap2: OK linux-2.6.30-armv5-omap2: OK linux-2.6.31-armv5-omap2: ERRORS linux-2.6.22.19-i686: ERRORS linux-2.6.23.12-i686: ERRORS linux-2.6.24.7-i686: ERRORS linux-2.6.25.11-i686: ERRORS linux-2.6.26-i686: OK linux-2.6.27-i686: OK linux-2.6.28-i686: OK linux-2.6.29.1-i686: WARNINGS linux-2.6.30-i686: WARNINGS linux-2.6.31-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.1-m32r: OK linux-2.6.30-m32r: OK linux-2.6.31-m32r: OK linux-2.6.30-mips: WARNINGS linux-2.6.31-mips: OK linux-2.6.27-powerpc64: ERRORS linux-2.6.28-powerpc64: ERRORS linux-2.6.29.1-powerpc64: ERRORS linux-2.6.30-powerpc64: ERRORS linux-2.6.31-powerpc64: ERRORS linux-2.6.22.19-x86_64: ERRORS linux-2.6.23.12-x86_64: ERRORS linux-2.6.24.7-x86_64: ERRORS linux-2.6.25.11-x86_64: ERRORS linux-2.6.26-x86_64: OK linux-2.6.27-x86_64: OK linux-2.6.28-x86_64: OK linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30-x86_64: WARNINGS linux-2.6.31-x86_64: WARNINGS sparse (linux-2.6.31): 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: ERRORS linux-2.6.20.21-i686: ERRORS linux-2.6.21.7-i686: ERRORS linux-2.6.16.61-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: ERRORS linux-2.6.19.5-x86_64: ERRORS linux-2.6.20.21-x86_64: ERRORS linux-2.6.21.7-x86_64: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.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: xc2028 sound carrier detection
On Wed, Sep 23, 2009 at 05:27:56PM -0400, Devin Heitmueller wrote: On Wed, Sep 23, 2009 at 3:28 PM, Aleksandr V. Piskunov aleksandr.v.pisku...@gmail.com wrote: Mmm, tested that tuner under windows, it autodetects all 3 sound carrier sub- standards instantly: PAL-BG, PAL-DK, PAL-I. In order to test, I connected ancient Panasonic VCR that has a built-in tuner and can output video to RF-OUT on fixed frequency using PAL standard. Sound carrier frequency can be choosen using hardware switch BG, DK or I. So under windows: tuner produces clear audio in BG, DK and I, hardware switch can be toggled on fly, audio never stops, only a few miliseconds of static on switch. Under linux: audio only works if driver is set to use specific audio carrier sub-standard AND same is selected on PVR. (not to mention extremely unreliable PAL-DK detection by cx25843, only works 50% of times, but thats another issue) Either a more generic firmware exists can be uploaded on xc2028.. or several can be uploaded at once. Any xc2028 gurus out there? It's possible that perhaps the Windows driver is relying on the cx25843 standard detection and then using that to load the appropriate firmware on the 3028. I can confirm though Mauro's assertion that the 3028 does use different firmware depending on the selected audio standard. You might want to try to get a capture of the device under Windows and see what firmware gets loaded. Ok, done a little research, here are results: 1) Best suitable xc2028 firmware for PAL audio is the one that gets chosen for PAL-I, to be more precise its Firmware 69, type: SCODE FW MONO HAS IF (0x60008000), IF = 6.00 MHz With this firmware loaded, tuner seems to pass everything from +5.5 MHz to +6.5Mhz straight to cx25843, resulting automatic detection of BG, I and DK audio. Instant detection on source change, instant playback, same as under windows. Would be great if more people would try v4l2-ctl -s pal-i and give feedback, especially for stereo sources. 2) Extremely unreliable detection of DK was caused by cx25843 trying to guess if 6.5MHz carrier is system DK or system L, special register was set to autodetection which failed half of the times. Will send a patch in a separate mail. -- 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] cx25840 6.5MHz carrier detection fixes
cx25840:
Disable 6.5MHz carrier autodetection for PAL, always assume its DK.
Only try to autodetect 6.5MHz carrier for SECAM if user accepts both
system DK and L.
Signed-off-by: Aleksandr V. Piskunov alexandr.v.pisku...@gmail.com
diff --git a/linux/drivers/media/video/cx25840/cx25840-core.c
b/linux/drivers/media/video/cx25840/cx25840-core.c
--- a/linux/drivers/media/video/cx25840/cx25840-core.c
+++ b/linux/drivers/media/video/cx25840/cx25840-core.c
@@ -647,13 +647,30 @@
}
cx25840_write(client, 0x80b, 0x00);
} else if (std V4L2_STD_PAL) {
- /* Follow tuner change procedure for PAL */
+ /* Autodetect audio standard and audio system */
cx25840_write(client, 0x808, 0xff);
- cx25840_write(client, 0x80b, 0x10);
+ /* Since system PAL-L is pretty much non-existant and
+ not used by any public broadcast network, force
+ 6.5 MHz carrier to be interpreted as System DK,
+ this avoids DK audio detection instability */
+ cx25840_write(client, 0x80b, 0x00);
} else if (std V4L2_STD_SECAM) {
- /* Select autodetect for SECAM */
+ /* Autodetect audio standard and audio system */
cx25840_write(client, 0x808, 0xff);
- cx25840_write(client, 0x80b, 0x10);
+ /* If only one of SECAM-DK / SECAM-L is required, then force
+ 6.5MHz carrier, else autodetect it */
+ if ((std V4L2_STD_SECAM_DK)
+ !(std (V4L2_STD_SECAM_L | V4L2_STD_SECAM_LC))) {
+ /* 6.5 MHz carrier to be interpreted as System DK */
+ cx25840_write(client, 0x80b, 0x00);
+ } else if (!(std V4L2_STD_SECAM_DK)
+ (std (V4L2_STD_SECAM_L | V4L2_STD_SECAM_LC))) {
+ /* 6.5 MHz carrier to be interpreted as System L */
+ cx25840_write(client, 0x80b, 0x08);
+ } else {
+ /* 6.5 MHz carrier to be autodetected */
+ cx25840_write(client, 0x80b, 0x10);
+ }
}
cx25840_and_or(client, 0x810, ~0x01, 0);
--
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: Questions about Terratec Hybrid XS (em2882) [0ccd:005e]
On 25.09.09 20:22, Uros Vampl wrote:
On 25.09.09 13:41, Devin Heitmueller wrote:
Interesting. Have you tried the A/V inputs (as opposed to the tuner)?
That might help us identify whether it's an issue with the xc3028
tuner chip extracting the audio carrier or whether it's something
about the way we are programming the emp202.
Hello,
That was a great idea. Tested with a Playstation2 and audio is ok. It's
just TV input that has a problem. So I guess that means the issue is
with the tuner chip. That's progress. Where do I go from here?
Ok, that's good to hear. What video standard specifically are you
using? I suspect the core issue is that the application is not
properly specifying the video standard, which results in the xc3028
improperly decoding the audio (the xc3028 needs to know exactly what
standard is being used).
I'm from Slovenia, which is a PAL-B country. Tvtime can be set to either
PAL-BG, PAL-DK or PAL-I, makes no difference. MPlayer has a whole bunch
of options (PAL, PAL-BG, etc...), but again none of them make a
difference.
When the app is started, this appears in dmesg:
xc2028 4-0061: Loading firmware for type=BASE F8MHZ (3), id .
(0), id 00ff:
xc2028 4-0061: Loading firmware for type=(0), id 00010007.
xc2028 4-0061: Loading SCODE for type=MONO SCODE HAS_IF_5320 (60008000), id
000f0007.
Alright, success!!!
Since it seems everything for this tuner is set up the same as for the
Hauppauge WinTV HVR 900, I figured let's set things up *exactly* the
same. So, like it's there for the Hauppauge, I added .mts_firmware = 1
to the definition of the hybrid XS em2882. And well, working TV audio!!
dmesg output this time:
xc2028 4-0061: Loading firmware for type=BASE F8MHZ MTS (7), id
.
MTS (4), id 00ff:
xc2028 4-0061: Loading firmware for type=MTS (4), id 00010007.
So now with the attached patch, everything (analog, digital, remote)
works!
Regards,
Uroš
diff -r 29e4ba1a09bc linux/drivers/media/video/em28xx/em28xx-cards.c
--- a/linux/drivers/media/video/em28xx/em28xx-cards.c Sat Sep 19 09:45:22
2009 -0300
+++ b/linux/drivers/media/video/em28xx/em28xx-cards.c Sat Sep 26 00:06:37
2009 +0200
@@ -1441,11 +1441,12 @@
.valid= EM28XX_BOARD_NOT_VALIDATED,
.tuner_type = TUNER_XC2028,
.tuner_gpio = default_tuner_gpio,
+ .mts_firmware = 1,
.decoder = EM28XX_TVP5150,
-#if 0 /* FIXME: add an entry at em28xx-dvb */
.has_dvb = 1,
.dvb_gpio = hauppauge_wintv_hvr_900_digital,
-#endif
+ .ir_codes = ir_codes_terratec_cinergy_xs_table,
+ .xclk = EM28XX_XCLK_FREQUENCY_12MHZ,
.input= { {
.type = EM28XX_VMUX_TELEVISION,
.vmux = TVP5150_COMPOSITE0,
@@ -2119,6 +2120,7 @@
switch (dev-model) {
case EM2880_BOARD_EMPIRE_DUAL_TV:
case EM2880_BOARD_HAUPPAUGE_WINTV_HVR_900:
+ case EM2882_BOARD_TERRATEC_HYBRID_XS:
ctl-demod = XC3028_FE_ZARLINK456;
break;
case EM2880_BOARD_TERRATEC_HYBRID_XS:
diff -r 29e4ba1a09bc linux/drivers/media/video/em28xx/em28xx-dvb.c
--- a/linux/drivers/media/video/em28xx/em28xx-dvb.c Sat Sep 19 09:45:22
2009 -0300
+++ b/linux/drivers/media/video/em28xx/em28xx-dvb.c Sat Sep 26 00:06:37
2009 +0200
@@ -494,6 +494,7 @@
}
break;
case EM2880_BOARD_HAUPPAUGE_WINTV_HVR_900:
+ case EM2882_BOARD_TERRATEC_HYBRID_XS:
case EM2880_BOARD_EMPIRE_DUAL_TV:
dvb-frontend = dvb_attach(zl10353_attach,
em28xx_zl10353_xc3028_no_i2c_gate,
Re: Questions about Terratec Hybrid XS (em2882) [0ccd:005e]
On Fri, Sep 25, 2009 at 6:10 PM, Uros Vampl mobile.leec...@gmail.com wrote: On 25.09.09 20:22, Uros Vampl wrote: On 25.09.09 13:41, Devin Heitmueller wrote: Interesting. Have you tried the A/V inputs (as opposed to the tuner)? That might help us identify whether it's an issue with the xc3028 tuner chip extracting the audio carrier or whether it's something about the way we are programming the emp202. Hello, That was a great idea. Tested with a Playstation2 and audio is ok. It's just TV input that has a problem. So I guess that means the issue is with the tuner chip. That's progress. Where do I go from here? Ok, that's good to hear. What video standard specifically are you using? I suspect the core issue is that the application is not properly specifying the video standard, which results in the xc3028 improperly decoding the audio (the xc3028 needs to know exactly what standard is being used). I'm from Slovenia, which is a PAL-B country. Tvtime can be set to either PAL-BG, PAL-DK or PAL-I, makes no difference. MPlayer has a whole bunch of options (PAL, PAL-BG, etc...), but again none of them make a difference. When the app is started, this appears in dmesg: xc2028 4-0061: Loading firmware for type=BASE F8MHZ (3), id . (0), id 00ff: xc2028 4-0061: Loading firmware for type=(0), id 00010007. xc2028 4-0061: Loading SCODE for type=MONO SCODE HAS_IF_5320 (60008000), id 000f0007. Alright, success!!! Since it seems everything for this tuner is set up the same as for the Hauppauge WinTV HVR 900, I figured let's set things up *exactly* the same. So, like it's there for the Hauppauge, I added .mts_firmware = 1 to the definition of the hybrid XS em2882. And well, working TV audio!! dmesg output this time: xc2028 4-0061: Loading firmware for type=BASE F8MHZ MTS (7), id . MTS (4), id 00ff: xc2028 4-0061: Loading firmware for type=MTS (4), id 00010007. So now with the attached patch, everything (analog, digital, remote) works! Regards, Uroš Excellent! I will check your patch into my current hg tree (http://kernellabs.com/hg/~dheitmueller/misc-fixes2/), which I planned on submitting a PULL for on Monday. Cheers, -- 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
