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?
I suspect that it is safe to keep it as it shown in the patch above...
Please confirm.
I wonder why Doug didnt have this problem. Do you think it might be a
quirk with my motherboard, causing those irq's ?
>>> 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?
--
Michael Krufky
