On Tuesday 23 August 2005 12:08 am, Michael Krufky wrote: > Mac Michaels wrote: > >2) Chip is being held in the reset state by a GPIO pin. > > A likely candidate. In order for the chip to respond > > the hardware reset pin 27 must be pulled high to a "1". > > You need to figure out where pin 27 of the lgdt3303 > > chip is connected to the bt88xx chip. That will be a > > difficult since the lgdt3303 chip is inside the tuner's > > metal box. My first guess would be gpio[0] just like > > all the other FusionHDTV cards. Note that there is also > > some reset code in cx88-dvb.c. It must leave the > > appropriate GPIO pin set to a 1. > > Finding the reset line wasn't so bad.... Now I have the > frontend loaded, and I can get a lock, but no ts yet. I > can't scan for channels either. > > This is (very short) atscscan output: > >>> tune to: 111025000:QAM_256 > >>> tuning status == 0x01 > >>> tuning status == 0x03 > >>> tuning status == 0x03 > >>> tuning status == 0x07 > >>> tuning status == 0x00 > >>> tuning status == 0x0f > >>> tuning status == 0x07 > >>> tuning status == 0x03 > >>> tuning status == 0x01 > >>> tuning status == 0x00 > > WARNING: >>> tuning failed!!! > > >>> tune to: 111025000:QAM_256 (tuning failed) > > [snip] > > >>> tune to: 711000000:QAM_256 > >>> tuning status == 0x01 > >>> tuning status == 0x1f > > WARNING: filter timeout pid 0x0000 > WARNING: filter timeout pid 0x1ffb > > >>> tune to: 717000000:QAM_256 > >>> tuning status == 0x1f > > WARNING: filter timeout pid 0x0000 > WARNING: filter timeout pid 0x1ffb > > >>> tune to: 723000000:QAM_256 > >>> tuning status == 0x1f > > WARNING: filter timeout pid 0x0000 > WARNING: filter timeout pid 0x1ffb It looks like you are locking on to a signal. My guess is that you need to do something to get the data transferred from the lgdt3303 chip to the PCI bus. There is a function in the CX23880x chip that does this for the Gold cards. The cx8802 part of the driver deals with this data transfer. This uses the MPEG interface. It moves the data from the MPEG data line(s) to the application via the PCI bus. I don't know how that is handled with the bt88xx stuff. If it uses the parallel interface change: .serial_mpeg = 0, or remove the line altogether. > Take a look at dmesg, for some reason, when I have bttv > compiled with dvb enabled for this card, the tda9887 chip > doesn't always get autodetected. However, when I don't > set .has_dvb =1 (bttv-cards.c, line ~2410), tda9887 > always shows up: Was the analog driver loaded? The tda9887 chip is not used by the digital driver. The digital driver attempts to make it quiet, but does not use it. It it is not found it does not matter. > Linux video capture interface: v1.00 > bttv: driver version 0.9.16 loaded > bttv: using 8 buffers with 2080k (520 pages) each for > capture bttv: Bt8xx card found (0). > ACPI: PCI Interrupt 0000:02:07.0[A] -> GSI 19 (level, > low) -> IRQ 19 bttv0: Bt878 (rev 17) at 0000:02:07.0, > irq: 19, latency: 64, mmio: 0xec200000 > bttv0: detected: DVICO FusionHDTV 5 Lite [card=135], PCI > subsystem ID is 18ac:d500 > bttv0: using: DVICO FusionHDTV 5 Lite > [card=135,autodetected] bttv0: gpio: en=00000000, > out=00000000 in=00ffffff [init] tuner 4-0061: chip found > @ 0xc2 (bt878 #0 [sw]) > bttv0: using tuner=64 > tuner 4-0061: type set to 64 (LG TDVS-H062F/TUA6034) > bttv0: registered device video0 > bttv0: registered device vbi0 > bttv0: add subdevice "dvb0" > bt878: AUDIO driver version 0.0.0 loaded > bt878: Bt878 AUDIO function found (0). > ACPI: PCI Interrupt 0000:02:07.1[A] -> GSI 19 (level, > low) -> IRQ 19 bt878(0): Bt878 (rev 17) at 02:07.1, irq: > 19, latency: 64, memory: 0xec201000 > DVB: registering new adapter (bttv0). > DVB: registering frontend 0 (LG Electronics LGDT3303 > VSB/QAM Frontend)... > > ...and that last line makes me wonder how come cx88-dvb > wasn't designed to behave the same way. cx88-dvb prints > card name instead of frontend name. I used a poor template for my driver. I'll look into fixing it. > Anyhow, below is the current patch... I don't feel good > about the .serial_mpeg setting in the lgdt330x_config > struct. I don't know if that's supposed to stay there or > not... I figure it should be chomped, since there is no > mpeg chip on board, but it looks like lgdt330x is > expecting something to be in there. I have tried both > 0x40 and 0x00, neither made a difference. What do u > think? Something else has to transfer the data to the application. The lgdt3303 can not do it directly. The MPEG interface is the only way data gets from out of the lgdt3303. Something else must take the data and put it into buffers for the application. The interface must match as serial or parallel.
