| Message ID | 200907201020.47581.jarod@redhat.com (mailing list archive) |
|---|---|
| State | Accepted |
| Headers | show |
On Mon, 20 Jul 2009, Jarod Wilson wrote: > 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] -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Monday 20 July 2009 15:51:27 Trent Piepho wrote: > On Mon, 20 Jul 2009, Jarod Wilson wrote: > > 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] 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!
> 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).
On Tuesday 21 July 2009 10:23:53 Steven Toth wrote: > > 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). 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.
On Tue, 21 Jul 2009 21:35:47 -0400 Jarod Wilson <jarod@redhat.com> 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
On Tue, 21 Jul 2009, Jarod Wilson wrote: > On Tuesday 21 July 2009 10:23:53 Steven Toth wrote: > > > 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). > > 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. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, 2009-07-21 at 23:51 -0700, Trent Piepho wrote: > On Tue, 21 Jul 2009, Jarod Wilson wrote: > > On Tuesday 21 July 2009 10:23:53 Steven Toth wrote: > > > > 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). > > > > 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. 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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 7/21/09 9:48 PM, Bob Hepple wrote: > On Tue, 21 Jul 2009 21:35:47 -0400 > Jarod Wilson<jarod@redhat.com> 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. My guess is that the eeprom was trashed.
On Wed, Jul 22, 2009 at 11:54 AM, Steven Toth<stoth@kernellabs.com> wrote: > On 7/21/09 9:48 PM, Bob Hepple wrote: >> >> On Tue, 21 Jul 2009 21:35:47 -0400 >> Jarod Wilson<jarod@redhat.com> Â 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. > > 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
On Wednesday 22 July 2009 02:51:12 Trent Piepho wrote: > On Tue, 21 Jul 2009, Jarod Wilson wrote: > > On Tuesday 21 July 2009 10:23:53 Steven Toth wrote: > > > > 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). > > > > 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. 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*... :)
On Wednesday 22 July 2009 13:59:00 Jarod Wilson wrote: > On Wednesday 22 July 2009 02:51:12 Trent Piepho wrote: > > On Tue, 21 Jul 2009, Jarod Wilson 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), 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. > > 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.
diff -r d754a2d5a376 linux/drivers/media/video/cx88/cx88-mpeg.c --- a/linux/drivers/media/video/cx88/cx88-mpeg.c Wed Jul 15 07:28:02 2009 -0300 +++ b/linux/drivers/media/video/cx88/cx88-mpeg.c Sat Jul 18 02:07:37 2009 -0400 @@ -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 --- */ }
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. Signed-off-by: Jarod Wilson <jarod@redhat.com>