Terratec Cinergy HTC Stick, drxk: SCU_RESULT_INVPAR
Hi, I'm trying to get my Terratec Cinergy HTC Stick to cooperate with Linux 3.3. It is going to be detected correctly, the requested firmware file dvb-usb-terratec-h5-drxk.fw is the one avaiable on [1]. At the moment, I only can test DVB-C. Which seems to work, from time to time. I can tune to some channels, the most channels are not working. When hitting a non working one, I get something like "drxk: SCU_RESULT_INVPAR while sending cmd 0x0203 with params", as could be seen in the dmesg output. The device seems to be ok, at least with the Windows driver. How can I debug this? Thanks. Steve. [1] http://www.linuxtv.org/downloads/firmware/#7 == dmesg output == [ 82.768242] usb 1-6: new high-speed USB device number 3 using ehci_hcd [ 82.902484] usb 1-6: New USB device found, idVendor=0ccd, idProduct=00b2 [ 82.902502] usb 1-6: New USB device strings: Mfr=2, Product=1, SerialNumber=3 [ 82.902515] usb 1-6: Product: Cinergy_HTC_Stick [ 82.902525] usb 1-6: Manufacturer: TERRATEC [ 82.902535] usb 1-6: SerialNumber: 02?TERRATE [ 83.159089] IR NEC protocol handler initialized [ 83.165677] IR RC5(x) protocol handler initialized [ 83.181250] IR RC6 protocol handler initialized [ 83.199170] em28xx: New device TERRATEC Cinergy_HTC_Stick @ 480 Mbps (0ccd:00b2, interface 0, class 0) [ 83.199182] em28xx: Audio Vendor Class interface 0 found [ 83.199188] em28xx: Video interface 0 found [ 83.199193] em28xx: DVB interface 0 found [ 83.199736] em28xx #0: chip ID is em2884 [ 83.201072] IR JVC protocol handler initialized [ 83.206244] IR Sony protocol handler initialized [ 83.214044] IR SANYO protocol handler initialized [ 83.219177] IR MCE Keyboard/mouse protocol handler initialized [ 83.225775] lirc_dev: IR Remote Control driver registered, major 251 [ 83.228931] IR LIRC bridge handler initialized [ 83.257485] em28xx #0: Identified as Terratec Cinergy HTC Stick (card=82) [ 83.267576] i2c-core: driver [tuner] using legacy suspend method [ 83.267586] i2c-core: driver [tuner] using legacy resume method [ 83.308536] Chip ID is not zero. It is not a TEA5767 [ 83.308568] tuner 14-0060: Tuner -1 found with type(s) Radio TV. [ 83.308591] tuner 14-0060: tuner type not set [ 83.308767] em28xx #0: Config register raw data: 0xbd [ 83.308777] em28xx #0: I2S Audio (5 sample rates) [ 83.308786] em28xx #0: No AC97 audio processor [ 83.336125] em28xx #0: v4l2 driver version 0.1.3 [ 83.336150] tuner 14-0060: tuner type not set [ 83.366997] em28xx #0: V4L2 video device registered as video1 [ 83.367148] usbcore: registered new interface driver em28xx [ 83.387234] em28xx-audio.c: probing for em28xx Audio Vendor Class [ 83.387244] em28xx-audio.c: Copyright (C) 2006 Markus Rechberger [ 83.387251] em28xx-audio.c: Copyright (C) 2007-2011 Mauro Carvalho Chehab [ 83.389287] Em28xx: Initialized (Em28xx Audio Extension) extension [ 84.203927] drxk: status = 0x639260d9 [ 84.203948] drxk: detected a drx-3926k, spin A3, xtal 20.250 MHz [ 85.526425] DRXK driver version 0.9.4300 [ 85.540783] drxk: frontend initialized. [ 87.293767] DVB: registering new adapter (em28xx #0) [ 87.293788] DVB: registering adapter 0 frontend 0 (DRXK DVB-C DVB-T)... [ 87.298706] em28xx #0: Successfully loaded em28xx-dvb [ 87.298737] Em28xx: Initialized (Em28xx dvb Extension) extension [ 223.421599] drxk: SCU_RESULT_INVPAR while sending cmd 0x0203 with params: [ 223.421622] drxk: 02 00 00 00 10 00 05 00 03 02.. [ 237.329309] drxk: SCU_RESULT_INVPAR while sending cmd 0x0203 with params: [ 237.329331] drxk: 02 00 00 00 10 00 05 00 03 02.. [ 299.973528] drxk: SCU_RESULT_INVPAR while sending cmd 0x0203 with params: [ 299.973550] drxk: 02 00 00 00 10 00 05 00 03 02.. [ 428.985300] drxk: SCU_RESULT_INVPAR while sending cmd 0x0203 with params: [ 428.985316] drxk: 02 00 00 00 10 00 05 00 03 02.. [ 485.533707] drxk: SCU_RESULT_INVPAR while sending cmd 0x0203 with params: [ 485.533730] drxk: 02 00 00 00 10 00 05 00 03 02.. [ 496.741663] drxk: SCU_RESULT_INVPAR while sending cmd 0x0203 with params: [ 496.741686] drxk: 02 00 00 00 10 00 05 00 03 02.. [ 639.765595] drxk: SCU_RESULT_INVPAR while sending cmd 0x0203 with params: [ 639.765622] drxk: 02 00 00 00 10 00 05 00 03 02.. -- NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone! Jetzt informieren: http://mobile.1und1.de/?ac=OM.PW.PW003K20328T7073a -- 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
UVC video output problem with 3.3.1 kernel
Hi, I have a UVC video device, which lsusb describes as: 046d:0992 Logitech, Inc. QuickCam Communicate Deluxe With the 3.3.1 kernel, the bottom 3rd of the video window displayed by guvcview is completely black. This happens whenever I select either BGR3 or RGB3 as the video output format. However, YUYV, YU12 and YV12 all display fine. Does anyone else see this, please? Thanks, Chris -- 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
Is xine DVB broken with Linux 3.3.1?
I have just checked the 3.2.14 kernel, and it seems unaffected by this issue. So I'm guessing it was introduced recently in the 3.3 kernel. Cheers, Chris -- 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
Is xine DVB broken with Linux 3.3.1?
Hi, Is anyone else having difficulty watching DVB-T with xine and a 3.3.1 kernel? I have tried the following with several different USB adapters: 1) Plug in the device 2) Launch xine. 3) Select DVB-T channel. and each time, the results are the same. Namely, xine refuses to acknowledge any of my channels. However, if I execute scandvb before running xine then xine suddenly realises that the exact same channels.conf file is OK after all. It looks as if scandvb is initialising a piece of the USB DVB device's internal "state", and xine cannot tune the adapter into any channel until it has. Can anyone else reproduce this, please? Thanks, Chris -- 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: Can't capture fluent video with bt878 card (Osprey 210)
Have you tried TVTime and/or XawTV? Also, you may try "streamer -c /dev/video0 -n pal -s 640x480 -r 2 -t 10 -o image_00.jpeg" to confirm it's really a field order issue. The VLC is tricky. You have to specify the options right to get a good preview or recording. -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media-ow...@vger.kernel.org] On Behalf Of xige Sent: Tuesday, April 03, 2012 7:49 PM To: linux-media@vger.kernel.org Subject: Can't capture fluent video with bt878 card (Osprey 210) Hi, everyone I found a problem with bt878 card under Linux(2.6 ~ 3.x) by v4l2 interface when I got a raw frame, but it looks like combined with wrong field order. In other words, I will received Top Bottom Top Bottom... fields sequences in theory. But now I got random sequence. My test hardware blew: HW: Xeon 5606, 4G, Asus Z8ND6C Core i7 980, 4G, Asus P6T Capture Card: Osprey 210 OS: Ubuntu 10.04 Ubuntu 11.10 SW: VLC 1.0.6 & 1.1.12 Please give me some advice? PS. In attach, that's a video snapshot. English not mine mother tongue, sorry my poor English. -- 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: media_tree daily build: WARNINGS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date:Wed Apr 4 19:00:18 CEST 2012 git hash:296da3cd14db9eb5606924962b2956c9c656dbb0 gcc version: i686-linux-gcc (GCC) 4.6.3 host hardware:x86_64 host os: 3.1-2.slh.1-amd64 linux-git-arm-eabi-exynos: WARNINGS linux-git-arm-eabi-omap: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: WARNINGS linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-i686: WARNINGS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-3.0-i686: WARNINGS linux-3.1-i686: WARNINGS linux-3.2.1-i686: WARNINGS linux-3.3-i686: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS linux-3.0-x86_64: WARNINGS linux-3.1-x86_64: WARNINGS linux-3.2.1-x86_64: WARNINGS linux-3.3-x86_64: WARNINGS apps: WARNINGS spec-git: WARNINGS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 04/11] Show timeouts on I2C transfers.
On Wed, Apr 04, 2012 at 06:43:11PM +0300, Marko Ristola wrote: > I wrote a patch that uses I2C IRQ. > I had a feeling that it worked well (with old single CPU desktop computer): > framerate with HDTV was low, but it was glitchless. > > Do you want to have the patch to be sent for you? Sure, send it if you want to. /* Steinar */ -- Homepage: http://www.sesse.net/ -- 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 04/11] Show timeouts on I2C transfers.
I had a plan to rework I2C handling a lot more,
than log the changes.
I wrote a patch that uses I2C IRQ.
I had a feeling that it worked well (with old single CPU desktop computer):
framerate with HDTV was low, but it was glitchless.
Do you want to have the patch to be sent for you?
I think that I solved in the patch "robust I2C command + exact IRQ response for
that command",
so that those two will not get out of sync.
I tried to rework the patch to make a bit smaller patch,
but I couldn't test the new one: hardware is too broken.
Regards,
Marko
01.04.2012 18:53, Steinar H. Gunderson kirjoitti:
> From: "Steinar H. Gunderson"
>
> On I2C reads and writes, show if we had any timeouts in the debug output.
>
> Signed-off-by: Steinar H. Gunderson
> ---
> drivers/media/dvb/mantis/mantis_i2c.c | 26 --
> 1 file changed, 24 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/dvb/mantis/mantis_i2c.c
> b/drivers/media/dvb/mantis/mantis_i2c.c
> index e779451..ddd1922 100644
> --- a/drivers/media/dvb/mantis/mantis_i2c.c
> +++ b/drivers/media/dvb/mantis/mantis_i2c.c
> @@ -38,6 +38,7 @@
> static int mantis_i2c_read(struct mantis_pci *mantis, const struct i2c_msg
> *msg)
> {
> u32 rxd, i, stat, trials;
> + u32 timeouts = 0;
>
> dprintk(MANTIS_INFO, 0, "%s: Address=[0x%02x] [ ",
> __func__, msg->addr);
> @@ -60,6 +61,9 @@ static int mantis_i2c_read(struct mantis_pci *mantis, const
> struct i2c_msg *msg)
> if (stat & MANTIS_INT_I2CDONE)
> break;
> }
> + if (trials == TRIALS) {
> + ++timeouts;
> + }
>
> dprintk(MANTIS_TMG, 0, "I2CDONE: trials=%d\n", trials);
>
> @@ -69,6 +73,9 @@ static int mantis_i2c_read(struct mantis_pci *mantis, const
> struct i2c_msg *msg)
> if (stat & MANTIS_INT_I2CRACK)
> break;
> }
> + if (trials == TRIALS) {
> + ++timeouts;
> + }
>
> dprintk(MANTIS_TMG, 0, "I2CRACK: trials=%d\n", trials);
>
> @@ -76,7 +83,11 @@ static int mantis_i2c_read(struct mantis_pci *mantis,
> const struct i2c_msg *msg)
> msg->buf[i] = (u8)((rxd >> 8) & 0xFF);
> dprintk(MANTIS_INFO, 0, "%02x ", msg->buf[i]);
> }
> - dprintk(MANTIS_INFO, 0, "]\n");
> + if (timeouts) {
> + dprintk(MANTIS_INFO, 0, "] %d timeouts\n", timeouts);
> + } else {
> + dprintk(MANTIS_INFO, 0, "]\n");
> + }
>
> return 0;
> }
> @@ -85,6 +96,7 @@ static int mantis_i2c_write(struct mantis_pci *mantis,
> const struct i2c_msg *msg
> {
> int i;
> u32 txd = 0, stat, trials;
> + u32 timeouts = 0;
>
> dprintk(MANTIS_INFO, 0, "%s: Address=[0x%02x] [ ",
> __func__, msg->addr);
> @@ -108,6 +120,9 @@ static int mantis_i2c_write(struct mantis_pci *mantis,
> const struct i2c_msg *msg
> if (stat & MANTIS_INT_I2CDONE)
> break;
> }
> + if (trials == TRIALS) {
> + ++timeouts;
> + }
>
> dprintk(MANTIS_TMG, 0, "I2CDONE: trials=%d\n", trials);
>
> @@ -117,10 +132,17 @@ static int mantis_i2c_write(struct mantis_pci *mantis,
> const struct i2c_msg *msg
> if (stat & MANTIS_INT_I2CRACK)
> break;
> }
> + if (trials == TRIALS) {
> + ++timeouts;
> + }
>
> dprintk(MANTIS_TMG, 0, "I2CRACK: trials=%d\n", trials);
> }
> - dprintk(MANTIS_INFO, 0, "]\n");
> + if (timeouts) {
> + dprintk(MANTIS_INFO, 0, "] %d timeouts\n", timeouts);
> + } else {
> + dprintk(MANTIS_INFO, 0, "]\n");
> + }
>
> return 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: [PATCH] af9035: add several new USB IDs
Il 04/04/2012 15:09, Antti Palosaari ha scritto:
> On 04.04.2012 15:40, Gianluca Gennari wrote:
>> Il 04/04/2012 13:59, Antti Palosaari ha scritto:
>>> On 04.04.2012 14:47, Gianluca Gennari wrote:
Add several new USB IDs extracted from the Windows and Linux drivers
published
by the manufacturers (Terratec and AVerMedia).
+[AF9035_07CA_0867] = {
+USB_DEVICE(USB_VID_AVERMEDIA, USB_PID_AVERMEDIA_0867)},
[AF9035_07CA_1867] = {
USB_DEVICE(USB_VID_AVERMEDIA, USB_PID_AVERMEDIA_1867)},
+[AF9035_07CA_3867] = {
+USB_DEVICE(USB_VID_AVERMEDIA, USB_PID_AVERMEDIA_3867)},
[AF9035_07CA_A867] = {
USB_DEVICE(USB_VID_AVERMEDIA, USB_PID_AVERMEDIA_A867)},
+[AF9035_07CA_B867] = {
+USB_DEVICE(USB_VID_AVERMEDIA, USB_PID_AVERMEDIA_B867)},
>>>
>>> It have been common practise to use product names for USB PID
>>> definitions instead of USB ID numbers. I vote to continue that practise.
>>>
>>> Also, I am not very sure if it is wise to add new IDs without any
>>> testing. Likely those are just reference design and will work, but
>>> sometimes there is also some changes done for schematic wiring.
>>> Especially for Avermedia, see hacks needed some AF9015 Avermedia
>>> devices. They have put invalid data to eeprom and thus hacks are needed
>>> for overriding tuner IDs etc.
>>> Not to mention, driver supports also dynamic IDs and even device ID is
>>> missing user can load driver using dynamic ID and report it working or
>>> non-working.
>>>
>>> Anyone else any thoughts about adding IDs without testing ?
>>>
>>> regards
>>> Antti
>>
>> Regarding the USB PID definition naming, there is no problem for me.
>> Actually, some product names were used in the modified versions of your
>> old driver, so I converted them to the format above just for
>> convenience. The only problem is that there are so many variations of
>> the Avermedia sticks that it's hard to give them proper names.
>>
>> Some of this IDs are already tested (if we include the several
>> modifications of your old driver).
>>
>> In particular:
>> AF9035_0CCD_00AA : confirmed working on Ubuntu.it forum with the old
>> driver (don't have the link);
>> AF9035_07CA_0825 : confirmed working on OpenPli forum with the old
>> driver (see link above);
>>
>> Others comes from the official Windows drivers so they should be just
>> little variations of the retail products:
>> AF9035_07CA_A825, AF9035_07CA_0835, AF9035_07CA_3867.
>>
>> This IDs are can be the more problematic:
>> AF9035_15A4_1000, AF9035_15A4_1002, AF9035_15A4_1003,
>> AF9035_07CA_A333, AF9035_07CA_0337, AF9035_07CA_F337
>> since there is little or no information about this products.
>>
>> Anyway, this patch can be a reference for users willing to test the new
>> driver.
>
> I mean those definitions that goes to common file named: dvb-usb-ids.h.
> Those are named as a USB_PID__
>
> PIDs inside af9035.c (enum af9035_id_entry) are used only for generating
> table index. Before it was used plain index numbers but that causes in
> past few times problems when people added new device IDs between then
> the table. Meaning of that enum is only keep index in order
> automatically - and it is just fine as it is short unique name as
> currently AF9035__.
>
> Add those IDs you know working and sent patch. Lets add more IDs when
> those are confirmed to work. And as I said I added dynamic ID support
> for that driver, so even there is no USB ID defined inside driver, it
> can be still used without compiling whole Kernel.
>
> regards
> Antti
>
Ok, roger.
As soon as the new driver is merged into the media_build tree, we should
start getting feedback anyway, so let's wait.
Regards,
Gianluca
--
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/5] tda18218: fix IF frequency for 7MHz bandwidth channels
On 04.04.2012 16:15, Gianluca Gennari wrote:
Il 03/04/2012 12:19, Antti Palosaari ha scritto:
On 03.04.2012 03:44, Gianluca Gennari wrote:
Il 03/04/2012 00:40, Antti Palosaari ha scritto:
On 03.04.2012 00:25, Gianluca Gennari wrote:
This is necessary to tune VHF channels with the AVerMedia A835 stick.
Signed-off-by: Gianluca Gennari
---
drivers/media/common/tuners/tda18218.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/media/common/tuners/tda18218.c
b/drivers/media/common/tuners/tda18218.c
index dfb3a83..b079696 100644
--- a/drivers/media/common/tuners/tda18218.c
+++ b/drivers/media/common/tuners/tda18218.c
@@ -144,7 +144,7 @@ static int tda18218_set_params(struct dvb_frontend
*fe)
priv->if_frequency = 300;
} else if (bw<= 700) {
LP_Fc = 1;
-priv->if_frequency = 350;
+priv->if_frequency = 400;
} else {
LP_Fc = 2;
priv->if_frequency = 400;
Kwaak, I will not apply that until I have done background checking. That
driver is used only by AF9015 currently. And I did that driver as
reverse-engineering and thus there is some things guessed. I have only 8
MHz wide signal, thus I never tested 7 and 6 MHz. Have no DVB-T
modulator either... Maybe some AF9015 user can confirm? Is there any
AF9015& TDA18218 bug reports seen in discussion forums...
A friend has a AF9015+TDA18218 stick and told me that it works fine with
the patch (including VHF), but to be safe I will ask him to double check
with the current media_build tree, with and without the patch. In the
worst case, we can add a new parameter (or an array of parameters) for
the IF frequency to struct tda18218_config.
Public short datasheet [1], page 16, says default IFs are BW=8 MHz IF=4
MHz, BW=7 MHz IF=3.5 MHz, BW=6 MHz IF=3 MHz. I suspect it still locks in
some cases even IF is off-by 0.5 MHz for BW 7 and 8 but performance is
reduced. So there is now something wrong, likely bug in the tda18218
driver.
Could someone send me Windows sniff from success tune to 7 MHz BW channel?
[1] http://www.nxp.com/documents/data_sheet/TDA18218HN.pdf
Hi Antti,
I did some testing with the A835 and the findings are interesting. With
the old tda18218 driver the af9015 sticks required IF=3.5MHz to tune VHF
channels, while the A835 required IF=4MHz.
With the current driver, both the af9015 and the A835 are much more
tolerant to IF frequency variations.
In particular, the A835 is capable to successfully tune UHF channels
with IF in the range [3.5,5.5] MHz, and VHF channels with IF in the
range [3.0,6.5] MHz, inclusive.
IF frequency is frequency used between tuner and demodulator. Thus it
should be same for the tuner, it is sender Tx, and for demodulator which
receives it. As you can guess it is like radio channel, it will work if
it is a little bit wrong but performance will be reduced.
IF frequency is generally more tuner characteristic than demodulator. I
mean it is likely tuner decides which is optimal IF for signal tuner is
transferring to demod. Earlier we used configuration option for both
tuner and demod to set IF. But as the fact is tuner must know it always
we added new tuner callback .get_if_frequency() demodulator can ask used
IF from the tuner.
Recently I converted AF9013 driver to use that .get_if_frequency(). I
think at that point I may have introduced some bug.
And one point to mention, it is sometimes used a little bit different
IFs that are tuner defaults. It is somehow device design specific, for
maximum performance device engineers will ran some test to find out
optimal IF which gives best performance. One reason could be example
there is RF noise peak (RF spurs) just in used IF which reduces
performance => lets shift default IF a little bit for maximum performance.
I don't know if this may be considered the symptom of a bug, but for
sure the patch I posted is useless with the current driver.
If you are still interested in a USB sniff of the Windows driver, just
let me know.
I have used old SniffUSB2.0
http://www.pcausa.com/Utilities/UsbSnoop/
Works fine with Windows XP. Sniff is welcome.
regards
Antti
--
http://palosaari.fi/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/5] tda18218: fix IF frequency for 7MHz bandwidth channels
Il 03/04/2012 12:19, Antti Palosaari ha scritto:
> On 03.04.2012 03:44, Gianluca Gennari wrote:
>> Il 03/04/2012 00:40, Antti Palosaari ha scritto:
>>> On 03.04.2012 00:25, Gianluca Gennari wrote:
This is necessary to tune VHF channels with the AVerMedia A835 stick.
Signed-off-by: Gianluca Gennari
---
drivers/media/common/tuners/tda18218.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/media/common/tuners/tda18218.c
b/drivers/media/common/tuners/tda18218.c
index dfb3a83..b079696 100644
--- a/drivers/media/common/tuners/tda18218.c
+++ b/drivers/media/common/tuners/tda18218.c
@@ -144,7 +144,7 @@ static int tda18218_set_params(struct dvb_frontend
*fe)
priv->if_frequency = 300;
} else if (bw<= 700) {
LP_Fc = 1;
-priv->if_frequency = 350;
+priv->if_frequency = 400;
} else {
LP_Fc = 2;
priv->if_frequency = 400;
>>>
>>> Kwaak, I will not apply that until I have done background checking. That
>>> driver is used only by AF9015 currently. And I did that driver as
>>> reverse-engineering and thus there is some things guessed. I have only 8
>>> MHz wide signal, thus I never tested 7 and 6 MHz. Have no DVB-T
>>> modulator either... Maybe some AF9015 user can confirm? Is there any
>>> AF9015& TDA18218 bug reports seen in discussion forums...
>>
>> A friend has a AF9015+TDA18218 stick and told me that it works fine with
>> the patch (including VHF), but to be safe I will ask him to double check
>> with the current media_build tree, with and without the patch. In the
>> worst case, we can add a new parameter (or an array of parameters) for
>> the IF frequency to struct tda18218_config.
>
> Public short datasheet [1], page 16, says default IFs are BW=8 MHz IF=4
> MHz, BW=7 MHz IF=3.5 MHz, BW=6 MHz IF=3 MHz. I suspect it still locks in
> some cases even IF is off-by 0.5 MHz for BW 7 and 8 but performance is
> reduced. So there is now something wrong, likely bug in the tda18218
> driver.
>
> Could someone send me Windows sniff from success tune to 7 MHz BW channel?
>
> [1] http://www.nxp.com/documents/data_sheet/TDA18218HN.pdf
Hi Antti,
I did some testing with the A835 and the findings are interesting. With
the old tda18218 driver the af9015 sticks required IF=3.5MHz to tune VHF
channels, while the A835 required IF=4MHz.
With the current driver, both the af9015 and the A835 are much more
tolerant to IF frequency variations.
In particular, the A835 is capable to successfully tune UHF channels
with IF in the range [3.5,5.5] MHz, and VHF channels with IF in the
range [3.0,6.5] MHz, inclusive.
I don't know if this may be considered the symptom of a bug, but for
sure the patch I posted is useless with the current driver.
If you are still interested in a USB sniff of the Windows driver, just
let me know.
Best regards,
Gianluca
--
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] af9035: add several new USB IDs
On 04.04.2012 15:40, Gianluca Gennari wrote:
Il 04/04/2012 13:59, Antti Palosaari ha scritto:
On 04.04.2012 14:47, Gianluca Gennari wrote:
Add several new USB IDs extracted from the Windows and Linux drivers
published
by the manufacturers (Terratec and AVerMedia).
+[AF9035_07CA_0867] = {
+USB_DEVICE(USB_VID_AVERMEDIA, USB_PID_AVERMEDIA_0867)},
[AF9035_07CA_1867] = {
USB_DEVICE(USB_VID_AVERMEDIA, USB_PID_AVERMEDIA_1867)},
+[AF9035_07CA_3867] = {
+USB_DEVICE(USB_VID_AVERMEDIA, USB_PID_AVERMEDIA_3867)},
[AF9035_07CA_A867] = {
USB_DEVICE(USB_VID_AVERMEDIA, USB_PID_AVERMEDIA_A867)},
+[AF9035_07CA_B867] = {
+USB_DEVICE(USB_VID_AVERMEDIA, USB_PID_AVERMEDIA_B867)},
It have been common practise to use product names for USB PID
definitions instead of USB ID numbers. I vote to continue that practise.
Also, I am not very sure if it is wise to add new IDs without any
testing. Likely those are just reference design and will work, but
sometimes there is also some changes done for schematic wiring.
Especially for Avermedia, see hacks needed some AF9015 Avermedia
devices. They have put invalid data to eeprom and thus hacks are needed
for overriding tuner IDs etc.
Not to mention, driver supports also dynamic IDs and even device ID is
missing user can load driver using dynamic ID and report it working or
non-working.
Anyone else any thoughts about adding IDs without testing ?
regards
Antti
Regarding the USB PID definition naming, there is no problem for me.
Actually, some product names were used in the modified versions of your
old driver, so I converted them to the format above just for
convenience. The only problem is that there are so many variations of
the Avermedia sticks that it's hard to give them proper names.
Some of this IDs are already tested (if we include the several
modifications of your old driver).
In particular:
AF9035_0CCD_00AA : confirmed working on Ubuntu.it forum with the old
driver (don't have the link);
AF9035_07CA_0825 : confirmed working on OpenPli forum with the old
driver (see link above);
Others comes from the official Windows drivers so they should be just
little variations of the retail products:
AF9035_07CA_A825, AF9035_07CA_0835, AF9035_07CA_3867.
This IDs are can be the more problematic:
AF9035_15A4_1000, AF9035_15A4_1002, AF9035_15A4_1003,
AF9035_07CA_A333, AF9035_07CA_0337, AF9035_07CA_F337
since there is little or no information about this products.
Anyway, this patch can be a reference for users willing to test the new
driver.
I mean those definitions that goes to common file named: dvb-usb-ids.h.
Those are named as a USB_PID__
PIDs inside af9035.c (enum af9035_id_entry) are used only for generating
table index. Before it was used plain index numbers but that causes in
past few times problems when people added new device IDs between then
the table. Meaning of that enum is only keep index in order
automatically - and it is just fine as it is short unique name as
currently AF9035__.
Add those IDs you know working and sent patch. Lets add more IDs when
those are confirmed to work. And as I said I added dynamic ID support
for that driver, so even there is no USB ID defined inside driver, it
can be still used without compiling whole Kernel.
regards
Antti
--
http://palosaari.fi/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] af9035: add several new USB IDs
Il 04/04/2012 13:59, Antti Palosaari ha scritto:
> On 04.04.2012 14:47, Gianluca Gennari wrote:
>> Add several new USB IDs extracted from the Windows and Linux drivers
>> published
>> by the manufacturers (Terratec and AVerMedia).
>> +[AF9035_07CA_0867] = {
>> +USB_DEVICE(USB_VID_AVERMEDIA, USB_PID_AVERMEDIA_0867)},
>> [AF9035_07CA_1867] = {
>> USB_DEVICE(USB_VID_AVERMEDIA, USB_PID_AVERMEDIA_1867)},
>> +[AF9035_07CA_3867] = {
>> +USB_DEVICE(USB_VID_AVERMEDIA, USB_PID_AVERMEDIA_3867)},
>> [AF9035_07CA_A867] = {
>> USB_DEVICE(USB_VID_AVERMEDIA, USB_PID_AVERMEDIA_A867)},
>> +[AF9035_07CA_B867] = {
>> +USB_DEVICE(USB_VID_AVERMEDIA, USB_PID_AVERMEDIA_B867)},
>
> It have been common practise to use product names for USB PID
> definitions instead of USB ID numbers. I vote to continue that practise.
>
> Also, I am not very sure if it is wise to add new IDs without any
> testing. Likely those are just reference design and will work, but
> sometimes there is also some changes done for schematic wiring.
> Especially for Avermedia, see hacks needed some AF9015 Avermedia
> devices. They have put invalid data to eeprom and thus hacks are needed
> for overriding tuner IDs etc.
> Not to mention, driver supports also dynamic IDs and even device ID is
> missing user can load driver using dynamic ID and report it working or
> non-working.
>
> Anyone else any thoughts about adding IDs without testing ?
>
> regards
> Antti
Regarding the USB PID definition naming, there is no problem for me.
Actually, some product names were used in the modified versions of your
old driver, so I converted them to the format above just for
convenience. The only problem is that there are so many variations of
the Avermedia sticks that it's hard to give them proper names.
Some of this IDs are already tested (if we include the several
modifications of your old driver).
In particular:
AF9035_0CCD_00AA : confirmed working on Ubuntu.it forum with the old
driver (don't have the link);
AF9035_07CA_0825 : confirmed working on OpenPli forum with the old
driver (see link above);
Others comes from the official Windows drivers so they should be just
little variations of the retail products:
AF9035_07CA_A825, AF9035_07CA_0835, AF9035_07CA_3867.
This IDs are can be the more problematic:
AF9035_15A4_1000, AF9035_15A4_1002, AF9035_15A4_1003,
AF9035_07CA_A333, AF9035_07CA_0337, AF9035_07CA_F337
since there is little or no information about this products.
Anyway, this patch can be a reference for users willing to test the new
driver.
Regards,
Gianluca
--
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] af9035: add several new USB IDs
Hi Antti,
On 04/04/2012 02:59 PM, Antti Palosaari wrote:
On 04.04.2012 14:47, Gianluca Gennari wrote:
Add several new USB IDs extracted from the Windows and Linux drivers
published
by the manufacturers (Terratec and AVerMedia).
+ [AF9035_07CA_0867] = {
+ USB_DEVICE(USB_VID_AVERMEDIA, USB_PID_AVERMEDIA_0867)},
[AF9035_07CA_1867] = {
USB_DEVICE(USB_VID_AVERMEDIA, USB_PID_AVERMEDIA_1867)},
+ [AF9035_07CA_3867] = {
+ USB_DEVICE(USB_VID_AVERMEDIA, USB_PID_AVERMEDIA_3867)},
[AF9035_07CA_A867] = {
USB_DEVICE(USB_VID_AVERMEDIA, USB_PID_AVERMEDIA_A867)},
+ [AF9035_07CA_B867] = {
+ USB_DEVICE(USB_VID_AVERMEDIA, USB_PID_AVERMEDIA_B867)},
It have been common practise to use product names for USB PID
definitions instead of USB ID numbers. I vote to continue that practise.
Also, I am not very sure if it is wise to add new IDs without any
testing. Likely those are just reference design and will work, but
sometimes there is also some changes done for schematic wiring.
Especially for Avermedia, see hacks needed some AF9015 Avermedia
devices. They have put invalid data to eeprom and thus hacks are needed
for overriding tuner IDs etc.
Not to mention, driver supports also dynamic IDs and even device ID is
missing user can load driver using dynamic ID and report it working or
non-working.
Anyone else any thoughts about adding IDs without testing ?
In my experience, it's not always workable out-of-the-box (for the
reasons you mentioned).
IMO it would be better either them adding as long as they're been
tested, or at least to add comments when untested but likely to work.
Br,
David
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
Re: [PATCH] af9035: add several new USB IDs
On 04.04.2012 14:47, Gianluca Gennari wrote:
Add several new USB IDs extracted from the Windows and Linux drivers published
by the manufacturers (Terratec and AVerMedia).
+ [AF9035_07CA_0867] = {
+ USB_DEVICE(USB_VID_AVERMEDIA, USB_PID_AVERMEDIA_0867)},
[AF9035_07CA_1867] = {
USB_DEVICE(USB_VID_AVERMEDIA, USB_PID_AVERMEDIA_1867)},
+ [AF9035_07CA_3867] = {
+ USB_DEVICE(USB_VID_AVERMEDIA, USB_PID_AVERMEDIA_3867)},
[AF9035_07CA_A867] = {
USB_DEVICE(USB_VID_AVERMEDIA, USB_PID_AVERMEDIA_A867)},
+ [AF9035_07CA_B867] = {
+ USB_DEVICE(USB_VID_AVERMEDIA, USB_PID_AVERMEDIA_B867)},
It have been common practise to use product names for USB PID
definitions instead of USB ID numbers. I vote to continue that practise.
Also, I am not very sure if it is wise to add new IDs without any
testing. Likely those are just reference design and will work, but
sometimes there is also some changes done for schematic wiring.
Especially for Avermedia, see hacks needed some AF9015 Avermedia
devices. They have put invalid data to eeprom and thus hacks are needed
for overriding tuner IDs etc.
Not to mention, driver supports also dynamic IDs and even device ID is
missing user can load driver using dynamic ID and report it working or
non-working.
Anyone else any thoughts about adding IDs without testing ?
regards
Antti
--
http://palosaari.fi/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] af9035: add several new USB IDs
Add several new USB IDs extracted from the Windows and Linux drivers published
by the manufacturers (Terratec and AVerMedia).
Terratec Cinergy T Stick rev. 2 (tua9001):
http://linux.terratec.de/tv_en.html
AVerMedia AverTV TwinStar A825 (2 x mxl5007t):
http://www.avermedia.com/Support/DownloadCount.aspx?FDFId=3145
AVerMedia A835 (tda18218):
http://www.avermedia.com/Support/DownloadCount.aspx?FDFId=4528
Afatech Sticks and AVerMedia A867 (mxl5007t):
http://www.avermedia.com/Support/DownloadCount.aspx?FDFId=5172
http://www.avermedia.com/Support/DownloadCount.aspx?FDFId=5171
http://www.avermedia.com/Support/DownloadCount.aspx?FDFId=4591 (Linux driver)
The AVerMedia A825 is a dual tuner stick that was reported as fully working
on the OpenPli forum, using a modified version of the old af9035 driver:
http://openpli.org/forums/topic/22295-is-the-avertv-twinstar-a825-dvb-t-usb-twin-tuner-supported-by-the-newest-openpli/page__view__findpost__p__254634
so I think it should work also on the new driver version, at least in
single-tuner mode.
Signed-off-by: Gianluca Gennari
---
drivers/media/dvb/dvb-usb/af9035.c | 60 +-
drivers/media/dvb/dvb-usb/dvb-usb-ids.h | 15 +++-
2 files changed, 72 insertions(+), 3 deletions(-)
diff --git a/drivers/media/dvb/dvb-usb/af9035.c
b/drivers/media/dvb/dvb-usb/af9035.c
index 26b4ead..e2107cd 100644
--- a/drivers/media/dvb/dvb-usb/af9035.c
+++ b/drivers/media/dvb/dvb-usb/af9035.c
@@ -821,29 +821,68 @@ err:
enum af9035_id_entry {
AF9035_0CCD_0093,
+ AF9035_0CCD_00AA,
AF9035_15A4_9035,
+ AF9035_15A4_1000,
AF9035_15A4_1001,
+ AF9035_15A4_1002,
+ AF9035_15A4_1003,
+ AF9035_07CA_0825,
+ AF9035_07CA_A825,
+ AF9035_07CA_0835,
AF9035_07CA_A835,
AF9035_07CA_B835,
+ AF9035_07CA_A333,
+ AF9035_07CA_0337,
+ AF9035_07CA_F337,
+ AF9035_07CA_0867,
AF9035_07CA_1867,
+ AF9035_07CA_3867,
AF9035_07CA_A867,
+ AF9035_07CA_B867,
};
static struct usb_device_id af9035_id[] = {
[AF9035_0CCD_0093] = {
USB_DEVICE(USB_VID_TERRATEC, USB_PID_TERRATEC_CINERGY_T_STICK)},
+ [AF9035_0CCD_00AA] = {
+ USB_DEVICE(USB_VID_TERRATEC,
USB_PID_TERRATEC_CINERGY_T_STICK_2)},
[AF9035_15A4_9035] = {
USB_DEVICE(USB_VID_AFATECH, USB_PID_AFATECH_AF9035)},
- [AF9035_15A4_1001] = {
+ [AF9035_15A4_1000] = {
USB_DEVICE(USB_VID_AFATECH, USB_PID_AFATECH_AF9035_2)},
+ [AF9035_15A4_1001] = {
+ USB_DEVICE(USB_VID_AFATECH, USB_PID_AFATECH_AF9035_3)},
+ [AF9035_15A4_1002] = {
+ USB_DEVICE(USB_VID_AFATECH, USB_PID_AFATECH_AF9035_4)},
+ [AF9035_15A4_1003] = {
+ USB_DEVICE(USB_VID_AFATECH, USB_PID_AFATECH_AF9035_5)},
+ [AF9035_07CA_0825] = {
+ USB_DEVICE(USB_VID_AVERMEDIA, USB_PID_AVERMEDIA_0825)},
+ [AF9035_07CA_A825] = {
+ USB_DEVICE(USB_VID_AVERMEDIA, USB_PID_AVERMEDIA_A825)},
+ [AF9035_07CA_0835] = {
+ USB_DEVICE(USB_VID_AVERMEDIA, USB_PID_AVERMEDIA_0835)},
[AF9035_07CA_A835] = {
USB_DEVICE(USB_VID_AVERMEDIA, USB_PID_AVERMEDIA_A835)},
[AF9035_07CA_B835] = {
USB_DEVICE(USB_VID_AVERMEDIA, USB_PID_AVERMEDIA_B835)},
+ [AF9035_07CA_A333] = {
+ USB_DEVICE(USB_VID_AVERMEDIA, USB_PID_AVERMEDIA_A333)},
+ [AF9035_07CA_0337] = {
+ USB_DEVICE(USB_VID_AVERMEDIA, USB_PID_AVERMEDIA_0337)},
+ [AF9035_07CA_F337] = {
+ USB_DEVICE(USB_VID_AVERMEDIA, USB_PID_AVERMEDIA_F337)},
+ [AF9035_07CA_0867] = {
+ USB_DEVICE(USB_VID_AVERMEDIA, USB_PID_AVERMEDIA_0867)},
[AF9035_07CA_1867] = {
USB_DEVICE(USB_VID_AVERMEDIA, USB_PID_AVERMEDIA_1867)},
+ [AF9035_07CA_3867] = {
+ USB_DEVICE(USB_VID_AVERMEDIA, USB_PID_AVERMEDIA_3867)},
[AF9035_07CA_A867] = {
USB_DEVICE(USB_VID_AVERMEDIA, USB_PID_AVERMEDIA_A867)},
+ [AF9035_07CA_B867] = {
+ USB_DEVICE(USB_VID_AVERMEDIA, USB_PID_AVERMEDIA_B867)},
{},
};
@@ -886,30 +925,47 @@ static struct dvb_usb_device_properties
af9035_properties[] = {
.i2c_algo = &af9035_i2c_algo,
- .num_device_descs = 4,
+ .num_device_descs = 5,
.devices = {
{
.name = "TerraTec Cinergy T Stick",
.cold_ids = {
&af9035_id[AF9035_0CCD_0093],
+ &af9035_id[AF9035_0CCD_00AA],
},
}, {
.name = "Afatech Technologies DVB-T stick",
.cold_ids = {
&af9035_id[AF9035_15A4_9
