[linux-dvb] Re: [BUG] FusionHDTV5 Lite

[Michael Krufky]

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