[linux-dvb] Status of High Level CI driver

Manu Abraham abraham.manu at gmail.com
Wed Dec 7 11:44:43 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.


Manu




More information about the linux-dvb mailing list