[linux-dvb] Status of High Level CI driver

Henrik Sjoberg hsjo at epact.se
Thu Dec 8 13:48:10 CET 2005


> Henrik Sjoberg wrote:
>
>>>Henrik Sjoberg wrote:
>>>
>>>
>>>
>>>>I have started working on HLCI support for mythtv (for now without any
>>>>coordination with the mythtv project). When I last worked on it (a
>>>> couple
>>>>of weeks ago) I managed to decode at least some encypted channels.
>>>>
>>>>I started looking into it again last week. However, I'm seeing problem
>>>>with the latest cvs (or any cvs since the merge) that I often don't get
>>>> a
>>>>lock when tuning channels. when I revert to cvs from for example nov 11
>>>>everthing works fine again.
>>>>
>>>>
>>>>
>>>>
>>>The only thing that is of considerable change is the addition of a
>>>MONOSHOT read of flags ..
>>>
>>>mode_flags & FE_TUNE_MODE_ONESHOT
>>>
>>>Can you check whether this condition becomes valid for you ? If it
>>> becomes
>>>valid, it will not read back the status from the frontend in this case
>>> and
>>>no lock.
>>>This condition should not ideally become valid, unless specified
>>>explicitly.
>>>
>>>
>>>
>>>
>>
>>The condition is not valid.
>>I have produced two logs using latest cvs, one where the fault occurs and
>>one where it does not. Both when I am tuning to the same channel. When
>>doing a diff between them, the first diff starts when I am to read the
>>reply from the lock command.
>>
>>(When using cvs from nov 11, the log file looks as the one that is ok.)
>>
>>Here is the diff between the two:
>>
>>[root at evermeet ~]# diff -pub /tmp/ok.log /tmp/error.log
>>--- /tmp/ok.log 2005-12-06 22:44:03.000000000 +0100
>>+++ /tmp/error.log      2005-12-06 22:43:57.000000000 +0100
>>@@ -8,9 +8,9 @@ evermeet kernel: dst_gpio_outb: mask=[00
>> evermeet kernel: writing [ 09 00 0a 48 d0 07 00 08 00 c6 ]
>> evermeet kernel: dst_gpio_outb: mask=[ffffffff], enbb=[0000],
>> outhigh=[0000]
>> evermeet kernel: read_dst: reply is 0xff
>>-evermeet kernel: dst_wait_dst_ready: dst wait ready after 74
>>+evermeet kernel: dst_wait_dst_ready: dst wait ready after 1
>> evermeet kernel: read_dst: reply is 0x9
>>-evermeet kernel:  0x0 0xa 0x48 0xd0 0x32 0x80 0x47 0x0 0xdc
>>+evermeet kernel:  0x0 0xa 0x48 0xd0 0x7 0x0 0x8 0x0 0xc6
>> evermeet kernel: dst_comm_init: Initializing DST.
>> evermeet kernel: dst_gpio_outb: mask=[ffffffff], enbb=[0001],
>> outhigh=[0000]
>> evermeet kernel: rdc_reset_state: Resetting state machine
>>@@ -20,8 +20,8 @@ evermeet kernel: writing [ 00 05 00 00 0
>> evermeet kernel: dst_gpio_outb: mask=[ffffffff], enbb=[0000],
>> outhigh=[0000]
>> evermeet kernel: read_dst: reply is 0xff
>> evermeet kernel: dst_wait_dst_ready: dst wait ready after 1
>>-evermeet kernel: read_dst: reply is 0xa
>>-evermeet kernel:  0x48 0xd0 0x46 0x80 0x47 0x0 0xd1
>>+evermeet kernel: read_dst: reply is 0x0
>>+evermeet kernel:  0x0 0x0 0xc 0x80 0x47 0x0 0x2d
>> evermeet kernel: dst_comm_init: Initializing DST.
>> evermeet kernel: dst_gpio_outb: mask=[ffffffff], enbb=[0001],
>> outhigh=[0000]
>> evermeet kernel: rdc_reset_state: Resetting state machine
>>@@ -31,6 +31,5 @@ evermeet kernel: writing [ 00 05 00 00 0
>> evermeet kernel: dst_gpio_outb: mask=[ffffffff], enbb=[0000],
>> outhigh=[0000]
>> evermeet kernel: read_dst: reply is 0xff
>> evermeet kernel: dst_wait_dst_ready: dst wait ready after 1
>>-evermeet kernel: read_dst: reply is 0xa
>>-evermeet kernel:  0x48 0xd0 0x4b 0x80 0x49 0x0 0xca
>>-
>>+evermeet kernel: read_dst: reply is 0x0
>>+evermeet kernel:  0x0 0x0 0x4b 0x80 0x4b 0x0 0xea
>>
>>If anyone has any idea what the problem could be, please let me know.
>>
>>
>
> I will check this. No clue ATM. will post as soon as i find something.
>

I have run tuning scripts over night with different cvs versions and I'm
fairly sure that the problem is around the area you mentioned before. Some
thing that happend here:
cvs diff -D 20051118 -D 20051119

However, it is a strange fault. Sometimes when I run with a newer cvs
everything works fine for a while, but at some point, the problems start
and then never goes away. I have yet to find a connection to when it
happens.

I will continue to look into it this weekend.

Henrik




More information about the linux-dvb mailing list