Michael Krufky wrote: > Manu Abraham wrote: > >> Michael Krufky wrote: >> >>> I can only zap once.... During these tests, I am using azap and >>> mplayer. I have noticed that after viewing a stream, if I kill azap >>> and try to zap to another channel, mplayer receives no ts data, >>> although azap reports status 1F. The only way to restore >>> functionality is to remove the module and re-insert it: >>> >>> modprobe -r dvb-bt8xx >>> modprobe dvb-bt8xx >>> >>> After doing this, it works again. This is also needed if I want to >>> view ATSC stream after watching analog tv. So, obviously there is a >>> bug that I have to fix. >>> >>> In attempting to fix this, I have tried resetting the frontend, by >>> calling lgdt330x_reset in tdvs_tua6034_pll_set, before >>> dvb_pll_configure, but that only made matters worse. >>> >>> ...or maybe it's a problem with gpio again, which is why my original >>> patch didnt work in the first place. The behavior is pretty much >>> the same. With my original patch, I was able to lock, but got no ts >>> data. With current cvs, I can lock, and get ts data. (beautiful >>> HDTV and DTV streams) But If I stop azap and start it again, then I >>> get no ts data again, just like with my original patch. >>> >>> But this error log makes me think otherwise: >>> >>>> bt878(0): irq FDSR risc_pc=2c4bd008 >>>> bt878(0): irq FDSR risc_pc=2c4bd008 >>>> bt878(0): irq SCERR risc_pc=2c4bd000 >>>> bt878(0): irq FDSR risc_pc=2c4bd008 >>>> [...] >>>> bt878(0): irq FDSR risc_pc=2c4bd008 >>>> bt878(0): irq FDSR risc_pc=2c4bd008 >>>> bt878(0): IRQ lockup, cleared int mask >>> >>> >>> >> >> Looks like you had too many a IRQ's due to FDSR errors, why don't you >> try ignoring the FBUS errors >> >> ie, >> >> card->irq_error_ignore = BT878_AFBUS | BT878_AFDSR | BT878_APABORT | >> BT878_ARIPERR | BT878_APPERR; >> >> you could try the same thing or whichever combination, but the basic >> idea is to reduce too many interrupts, since lockup >> you might like to try to add resync also, >> >> ie, >> >> card->op_sync_orin = BT878_RISC_SYNC_MASK; >> >> >> either both of them or a combination of them and see whether it still >> occurs. >> in the relevant section in dvb-bt8xx, similar to others. That will >> help you atleast to reduce the number or IRQ's > > > Manu- > > I applied both of the changes above and it fixes the problem. ie: > > diff -u -p -r1.49 dvb-bt8xx.c > --- linux/drivers/media/dvb/bt8xx/dvb-bt8xx.c 10 Sep 2005 07:26:02 > -0000 1.49 > +++ linux/drivers/media/dvb/bt8xx/dvb-bt8xx.c 11 Sep 2005 19:19:26 > -0000 > @@ -828,8 +828,8 @@ static int dvb_bt8xx_probe(struct device > case BTTV_DVICO_FUSIONHDTV_5_LITE: > #endif > card->gpio_mode = 0x0400c060; > - card->op_sync_orin = 0; > - card->irq_err_ignore = 0; > + card->op_sync_orin = BT878_RISC_SYNC_MASK; > + card->irq_err_ignore = BT878_AFBUS | BT878_AFDSR | > BT878_APABORT | BT878_ARIPERR | BT878_APPERR; > break; > > #ifdef BTTV_TWINHAN_VP3021 > > Should I leave it this way, or should I bother trying to remove some > of those ignore cases, figuring out what's necessary and only keep the > bare minimum? > Just trim it to the requirement. If someone has problems later on add more of them. In some cases you can possibly do some error correction depending upon how severe it is. Well it's a painstaking procedure to do that. Well, if you have the time give it a shot and see, trying to do error correction. It is okay as it is too .. > I suspect that it is safe to keep it as it shown in the patch above... > Please confirm. Yes, no problems .. I use all of them for the DST. Most of the Fusion 878 based cards, use similar stuff, except that the GPIO connections would be different and hence a difference in the GPIO config. Some cards would tweak the RISC program too, but that is not very critical, but helps in optimal settings. > > I wonder why Doug didnt have this problem. Do you think it might be a > quirk with my motherboard, causing those irq's ? It depends on the bus on which your cards sits.. Remember the old bttv and Avermedia problems ? Well it is the same, revisited. Some other bttv cards also might need that setting, also. If he has the card on a bus which is *relatively* free of data transfer, this case will not show up, but when you have all hardware onto a single PCI bus, the errors are shown highlighted. In this case you need to ignore some errors ! > >>>> lgdt330x: i2c_write_demod_bytes error (addr 4c <- 14, err = -121) >>> >>> >>> >>>> bt878(0): irq SCERR risc_pc=2c4bd000 >>>> bt878(0): irq FDSR risc_pc=2c4bd008 >>>> lgdt330x: i2c_read_demod_bytes: addr 0x0e select 0x1a error (ret == >>>> -121) >>>> lgdt330x: i2c_read_demod_bytes: addr 0x0e select 0x8b error (ret == >>>> -121) >>>> lgdt330x: i2c_write_demod_bytes error (addr 02 <- 00, err = -121) >>> >>> >>> >> Does your driver uses i2c bitbanging or hardware ? > > > This problem is still present... This is what happens if I try to zap > again after using the analog tuner. Maybe Mac can shed some light on > this? > Maybe, fiddling around with the analog stuff changes some gpio settings which are necessary for the digital part, or need to wait for some time probably. Could be either of them, or both. Manu
