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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Manu Abraham wrote:
>>>> Michael Krufky wrote:
>>>>
>>>> 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 !

I don't know what he's got, but I only have 1 pci slot in this machine, 
and that's where the FusionHDTV5 Lite is.

> 
>>
>>>>> 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.

Yeah, Good point.  I think I know how to fix this in bttv-cards.c ... 
I'll take a look.

-- 
Michael Krufky


[Index of Archives]     [Linux Media]     [Video 4 Linux]     [Asterisk]     [Samba]     [Xorg]     [Xfree86]     [Linux USB]

  Powered by Linux