Skip to contentSkip to conversation

dvb: make digital side of pcHDTV HD-3000 functional again

PATCH In review Jarod Wilson 6 participants 12 messages Jul 20, 2009 – Jul 22, 2009 Media (V4L/DVB)

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 dvb: make digital side of pcHDTV HD-3000 functional again

The dvb side of the pcHDTV HD-3000 doesn't work since at least 2.6.29. The crux of the problem is this: the HD-3000's device ID matches the modalias for the cx8800 driver, but not the cx8802 driver, which is required to set up the digital side of the card. You can load up cx8802 just fine, but cx88-dvb falls on its face, because the call to cx8802_register_driver() attempts to traverse the cx8802_devlist, which is completely empty. The list is only populated by the cx8802_probe() function, which never gets called for the HD-3000, as its device ID isn't matched by the cx8802 driver, so you wind up getting an -ENODEV return from cx8802_register_driver() back to cx88-dvb, and as a result, no digital side of the card for you.

Long story short, by simply adding a vendor/device/subvendor/subdevice block to cx88-mpeg.c, cx8802_probe() will run, the cx88-2_devlist will get populated, cx8802_register_driver() won't fail, and cx88-dvb can actually load up all the way on this card. Channel scanning is of course currently failing for me still (works fine on several other cards I have handy), but that's another problem for another day...

There might be a Better Way to do this, and I'm open to suggestions and willing to try them out, but this Works For Me.

linux/drivers/media/video/cx88/cx88-mpeg.c +5 -0
diff -r d754a2d5a376 linux/drivers/media/video/cx88/cx88-mpeg.c
@@ -893,6 +893,11 @@
 		.device       = 0x8802,
 		.subvendor    = PCI_ANY_ID,
 		.subdevice    = PCI_ANY_ID,
+	},{	/* pcHDTV HD-3000 */
+		.vendor       = 0x14f1,
+		.device       = 0x8800,
+		.subvendor    = 0x7063,
+		.subdevice    = 0x3000,
 	},{
 		/* --- end of list --- */
 	}
Signature · 2 lines
Jarod Wilson
[email protected]
#1 lore raw
Quoted 9 lines · Jarod Wilson

The dvb side of the pcHDTV HD-3000 doesn't work since at least 2.6.29. The crux of the problem is this: the HD-3000's device ID matches the modalias for the cx8800 driver, but not the cx8802 driver, which is required to set up the digital side of the card. You can load up cx8802 just fine, but cx88-dvb falls on its face, because the call to cx8802_register_driver() attempts to traverse the cx8802_devlist, which is completely empty. The list is only populated by the cx8802_probe() function, which never gets called for the HD-3000, as its device ID isn't matched by the cx8802 driver, so you wind up

This isn't right. The cx8802 has never had anything in its mod alias other than the generic 14f1/8802 vendor/device with wildcards for sub-vendor/device. Which should match the HD-3000 as well as all other cx88 based digital cards. So cx8802_probe() should be called with the existing id table. Something else must be going on. Maybe there is something wrong with your PCI and function 2 isn't showing up? Or it could be that function 2 is disabled in the eeprom. Make sure lspci shows the mpeg function listed:

02:04.2 Multimedia controller: Conexant CX23880/1/2/3 PCI Video and Audio Decoder [MPEG Port] (rev 05)
Subsystem: pcHDTV pcHDTV HD3000 HDTV
Flags: bus master, medium devsel, latency 64, IRQ 18
Memory at c5000000 (32-bit, non-prefetchable) [size=16M]

#2 lore raw
Quoted 20 lines · On Monday 20 July 2009 15:51:27 Trent Piepho wrote:
Quoted 9 lines · Jarod Wilson

The dvb side of the pcHDTV HD-3000 doesn't work since at least 2.6.29. The crux of the problem is this: the HD-3000's device ID matches the modalias for the cx8800 driver, but not the cx8802 driver, which is required to set up the digital side of the card. You can load up cx8802 just fine, but cx88-dvb falls on its face, because the call to cx8802_register_driver() attempts to traverse the cx8802_devlist, which is completely empty. The list is only populated by the cx8802_probe() function, which never gets called for the HD-3000, as its device ID isn't matched by the cx8802 driver, so you wind up

This isn't right. The cx8802 has never had anything in its mod alias other than the generic 14f1/8802 vendor/device with wildcards for sub-vendor/device. Which should match the HD-3000 as well as all other cx88 based digital cards. So cx8802_probe() should be called with the existing id table. Something else must be going on. Maybe there is something wrong with your PCI and function 2 isn't showing up? Or it could be that function 2 is disabled in the eeprom. Make sure lspci shows the mpeg function listed:

Quoted 4 lines

02:04.2 Multimedia controller: Conexant CX23880/1/2/3 PCI Video and Audio Decoder [MPEG Port] (rev 05)
Subsystem: pcHDTV pcHDTV HD3000 HDTV
Flags: bus master, medium devsel, latency 64, IRQ 18
Memory at c5000000 (32-bit, non-prefetchable) [size=16M]

Hrm, okay, I'll double-check that... If its not there, perhaps the card isn't quite seated correctly. Or the machine is bunk. Or the card has gone belly up. Amusing that it works as much as it does though, if any of the above is the case...

Thanks for the info!

Signature · 2 lines
Jarod Wilson
[email protected]
#3 lore raw
Quoted 7 lines

Hrm, okay, I'll double-check that... If its not there, perhaps the card isn't quite seated correctly. Or the machine is bunk. Or the card has gone belly up. Amusing that it works as much as it does though, if any of the above is the case...

Thanks for the info!

Jrod,

Yeah. If the pci enable bit for the transport engine is not enabled (thus showing up as pci device 8802) then I'm going to be surprised if the risc engine runs up at all (or runs perfectly).

I've seen issue like this in the past with various cx88 boards and it invariable turn out to be a corrupt eeprom or a badly seated PCI card.

or, no eeprom at all (unlikely on this board).

Signature · 2 lines
Steven Toth - Kernel Labs
http://www.kernellabs.com
#4 lore raw
Quoted 10 lines · On Tuesday 21 July 2009 10:23:53 Steven Toth wrote:
Quoted 7 lines

Hrm, okay, I'll double-check that... If its not there, perhaps the card isn't quite seated correctly. Or the machine is bunk. Or the card has gone belly up. Amusing that it works as much as it does though, if any of the above is the case...

Thanks for the info!

Jrod,

Quoted 8 lines

Yeah. If the pci enable bit for the transport engine is not enabled (thus showing up as pci device 8802) then I'm going to be surprised if the risc engine runs up at all (or runs perfectly).

I've seen issue like this in the past with various cx88 boards and it invariable turn out to be a corrupt eeprom or a badly seated PCI card.

or, no eeprom at all (unlikely on this board).

So its either I have *two* machines with bad, but only slightly bad, and in the same way, PCI slots which seem to work fine with any other card I have (uh, unlikely), or my HD-3000 has gone belly up on me in some subtle way. The cx8802 part never shows up under lspci on either machine I've tried it in. Suck.

Signature · 2 lines
Jarod Wilson
[email protected]
#5 lore raw
Quoted 3 lines · On Tue, 21 Jul 2009 21:35:47 -0400 Jarod Wilson <[email protected]> wrote:

So its either I have *two* machines with bad, but only slightly bad, and in the same way, PCI slots which seem to work fine with any other card I have (uh, unlikely),

... not unlikely if the two machines are similar - many motherboards have borked PCI slots in one way or another - design faults or idiosyncratic interpretation of the PCI standard. I've seen it with HP, Compaq, Digital m/bs just to name big names, smaller mfrs also get it wrong. Sometimes just using another slot helps. Sometimes you need to try a totally different motherboard.

Maybe wrong to 'blame' the m/b mfr - it could just as easily be an out-of-spec or creatively interpreted PCI standard on the card.

Cheers

Bob

Signature · 2 lines
Bob Hepple <[email protected]>
ph: 07-5584-5908 Fx: 07-5575-9550
#6 lore raw
Quoted 14 lines · Bob Hepple
Quoted 3 lines · On Tue, 21 Jul 2009 21:35:47 -0400 Jarod Wilson<[email protected]> wrote:

So its either I have *two* machines with bad, but only slightly bad, and in the same way, PCI slots which seem to work fine with any other card I have (uh, unlikely),

... not unlikely if the two machines are similar - many motherboards have borked PCI slots in one way or another - design faults or idiosyncratic interpretation of the PCI standard. I've seen it with HP, Compaq, Digital m/bs just to name big names, smaller mfrs also get it wrong. Sometimes just using another slot helps. Sometimes you need to try a totally different motherboard.

Quoted 2 lines

Maybe wrong to 'blame' the m/b mfr - it could just as easily be an out-of-spec or creatively interpreted PCI standard on the card.

My guess is that the eeprom was trashed.

Signature · 2 lines
Steven Toth - Kernel Labs
http://www.kernellabs.com
#7 lore raw
Quoted 16 lines · Steven Toth
Quoted 15 lines · Bob Hepple
Quoted 3 lines · On Tue, 21 Jul 2009 21:35:47 -0400 Jarod Wilson<[email protected]>  wrote:

So its either I have *two* machines with bad, but only slightly bad, and in the same way, PCI slots which seem to work fine with any other card I have (uh, unlikely),

... not unlikely if the two machines are similar - many motherboards have borked PCI slots in one way or another - design faults or idiosyncratic interpretation of the PCI standard.  I've seen it with HP, Compaq, Digital m/bs just to name big names, smaller mfrs also get it wrong. Sometimes just using another slot helps. Sometimes you need to try a totally different motherboard.

Quoted 4 lines
Quoted 2 lines

Maybe wrong to 'blame' the m/b mfr - it could just as easily be an out-of-spec or creatively interpreted PCI standard on the card.

My guess is that the eeprom was trashed.

I hate to be the one to make this observation, but since this card is specifically targeted at the Linux market, has anyone considered reaching out to the vendor to ask for help?

If their card really is broken in current kernels, I would think a company that specializes in selling Linux tuner products would be interested in such.

Devin

Signature · 2 lines
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
#8 lore raw
In reply to Jarod Wilson
Quoted 18 lines · Jarod Wilson
Quoted 17 lines · On Tuesday 21 July 2009 10:23:53 Steven Toth wrote:
Quoted 7 lines

Hrm, okay, I'll double-check that... If its not there, perhaps the card isn't quite seated correctly. Or the machine is bunk. Or the card has gone belly up. Amusing that it works as much as it does though, if any of the above is the case...

Thanks for the info!

Jrod,

Yeah. If the pci enable bit for the transport engine is not enabled (thus showing up as pci device 8802) then I'm going to be surprised if the risc engine runs up at all (or runs perfectly).

I've seen issue like this in the past with various cx88 boards and it invariable turn out to be a corrupt eeprom or a badly seated PCI card.

Quoted 7 lines
Quoted 1 line

or, no eeprom at all (unlikely on this board).

So its either I have *two* machines with bad, but only slightly bad, and in the same way, PCI slots which seem to work fine with any other card I have (uh, unlikely), or my HD-3000 has gone belly up on me in some subtle way. The cx8802 part never shows up under lspci on either machine I've tried it in. Suck.

Check your eeprom, it could be set incorrectly.

"i2cdump -f 0 0x50" will show the contents if the HD-3000 has i2c bus 0. i2cdump with no arguments will tell you what each bus is.

The first 12 bytes should look something like this:
00: 06 ff ff ff 63 70 00 30 e0 01 40 ff 00 00 00 00 ?...cp.0??@.....

The first byte should have bit 0x04 set to enable mpeg.

#9 lore raw
Quoted 29 lines · Trent Piepho
Quoted 18 lines · Jarod Wilson
Quoted 17 lines · On Tuesday 21 July 2009 10:23:53 Steven Toth wrote:
Quoted 7 lines

Hrm, okay, I'll double-check that... If its not there, perhaps the card isn't quite seated correctly. Or the machine is bunk. Or the card has gone belly up. Amusing that it works as much as it does though, if any of the above is the case...

Thanks for the info!

Jrod,

Yeah. If the pci enable bit for the transport engine is not enabled (thus showing up as pci device 8802) then I'm going to be surprised if the risc engine runs up at all (or runs perfectly).

I've seen issue like this in the past with various cx88 boards and it invariable turn out to be a corrupt eeprom or a badly seated PCI card.

Quoted 7 lines
Quoted 1 line

or, no eeprom at all (unlikely on this board).

So its either I have *two* machines with bad, but only slightly bad, and in the same way, PCI slots which seem to work fine with any other card I have (uh, unlikely), or my HD-3000 has gone belly up on me in some subtle way. The cx8802 part never shows up under lspci on either machine I've tried it in. Suck.

Check your eeprom, it could be set incorrectly.

Quoted 7 lines

"i2cdump -f 0 0x50" will show the contents if the HD-3000 has i2c bus 0. i2cdump with no arguments will tell you what each bus is.

The first 12 bytes should look something like this:
00: 06 ff ff ff 63 70 00 30 e0 01 40 ff 00 00 00 00 ?...cp.0??@.....

The first byte should have bit 0x04 set to enable mpeg.

Trent,

Does the i2c-dev module need to be loaded for the above to work?

Jarod,

If your eeprom looks good you might want to try rebooting your machine with a "pci=nommconf" kernel command line argument.

My hypothesis being that it's harder for something to muck with the PCI config space registers of the CX2388x whne they aren't mapped into memory.

Regards,
Andy

#10 lore raw
In reply to Trent Piepho
Quoted 29 lines · On Wednesday 22 July 2009 02:51:12 Trent Piepho wrote:
Quoted 18 lines · Jarod Wilson
Quoted 17 lines · On Tuesday 21 July 2009 10:23:53 Steven Toth wrote:
Quoted 7 lines

Hrm, okay, I'll double-check that... If its not there, perhaps the card isn't quite seated correctly. Or the machine is bunk. Or the card has gone belly up. Amusing that it works as much as it does though, if any of the above is the case...

Thanks for the info!

Jrod,

Yeah. If the pci enable bit for the transport engine is not enabled (thus showing up as pci device 8802) then I'm going to be surprised if the risc engine runs up at all (or runs perfectly).

I've seen issue like this in the past with various cx88 boards and it invariable turn out to be a corrupt eeprom or a badly seated PCI card.

Quoted 7 lines
Quoted 1 line

or, no eeprom at all (unlikely on this board).

So its either I have *two* machines with bad, but only slightly bad, and in the same way, PCI slots which seem to work fine with any other card I have (uh, unlikely), or my HD-3000 has gone belly up on me in some subtle way. The cx8802 part never shows up under lspci on either machine I've tried it in. Suck.

Check your eeprom, it could be set incorrectly.

Quoted 8 lines

"i2cdump -f 0 0x50" will show the contents if the HD-3000 has i2c bus 0. i2cdump with no arguments will tell you what each bus is.

The first 12 bytes should look something like this:
00: 06 ff ff ff 63 70 00 30 e0 01 40 ff 00 00 00 00 ?...cp.0??@.....

The first byte should have bit 0x04 set to enable mpeg.

So here's what was in my eeprom:

00: 00 00 00 00 63 70 00 30 e0 01 40 ff 00 00 00 00 ....cp.0??@.....

Sooo... For funsies, I figured out how to use i2cset, and made it match your example. After rebooting, I have the cx8802 device showing up again. Cool! Now to see if it actually *works*... :)

Signature · 2 lines
Jarod Wilson
[email protected]
#11 lore raw
Quoted 2 lines · On Wednesday 22 July 2009 13:59:00 Jarod Wilson wrote:
Quoted 1 line · On Wednesday 22 July 2009 02:51:12 Trent Piepho wrote:

On Tue, 21 Jul 2009, Jarod Wilson wrote:

...

Quoted 17 lines
Quoted 8 lines
Quoted 5 lines

So its either I have *two* machines with bad, but only slightly bad, and in the same way, PCI slots which seem to work fine with any other card I have (uh, unlikely), or my HD-3000 has gone belly up on me in some subtle way. The cx8802 part never shows up under lspci on either machine I've tried it in. Suck.

Check your eeprom, it could be set incorrectly.

Quoted 8 lines

"i2cdump -f 0 0x50" will show the contents if the HD-3000 has i2c bus 0. i2cdump with no arguments will tell you what each bus is.

The first 12 bytes should look something like this:
00: 06 ff ff ff 63 70 00 30 e0 01 40 ff 00 00 00 00 ?...cp.0??@.....

The first byte should have bit 0x04 set to enable mpeg.

Quoted 7 lines

So here's what was in my eeprom:

00: 00 00 00 00 63 70 00 30 e0 01 40 ff 00 00 00 00 ....cp.0??@.....

Sooo... For funsies, I figured out how to use i2cset, and made it match your example. After rebooting, I have the cx8802 device showing up again. Cool! Now to see if it actually *works*... :)

Yup, seems to work, just did an OTA scan w/o a problem, azap gets a lock, signal and snr, dvbtraffic, and video coming off it look sane.

Now the question I have is how the hell did the eeprom get hosed over in the first place?...

In any case, thanks much! Happy to have it back in working order.

Signature · 2 lines
Jarod Wilson
[email protected]