[linux-dvb] Re: Mantis VP-1027/VP-1033/VP-1034/VP-2033/VP-3033

Marko Ristola marko.ristola at kolumbus.fi
Mon Oct 9 18:08:25 CEST 2006


Here is the modified cu1216.c file.

Regards
Marko Ristola

Manu Abraham wrote:
> Marko Ristola wrote:
>   
>> Hi
>>
>> I tested the Mantis driver. I used stock Fedora Core 5 kernel (AMD64)
>> I have the 2033 card, as described in
>> http://www.twinhan.com/product_cable_2033.asp
>>
>> 05:04.0 Multimedia controller: Twinhan Technology Co. Ltd Mantis DTV PCI
>> Bridge Controller [Ver 1.0] (rev 01)
>>        Subsystem: Twinhan Technology Co. Ltd Unknown device 0008
>>        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
>> ParErr- Stepping- SERR- FastB2B-
>>        Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
>> <TAbort+ <MAbort- >SERR- <PERR-
>>        Latency: 32 (2000ns min, 63750ns max)
>>        Interrupt: pin A routed to IRQ 217
>>        Region 0: Memory at c2100000 (32-bit, prefetchable) [size=4K]
>>
>> I'm new with this driver: I bought my first digital dvb card on saturday.
>>
>> I modified the Mantis driver when I tried to make it work:
>> cu1216_set_parameters(): return 0 on success (returned -1 always).
>> cu1216_set_parameters(): do thorough scanning:
>> - Test inverse and noninverse cases with all three gains.
>> - Test error rate ten times and accept the best one, that got FE_HAS_LOCK.
>> - Use the best inverse/noninverse case with the lock with the best gain.
>>
>> My implementation was unacceptably slow, but cu1216_set_parameters() was
>> successful.
>>
>> Here is a description of the gained status acquired with
>> cu1216_read_status:
>>
>> [cu1216_read_status]: status = 31, sync=47 {FE_HAS_SIGNAL |
>> FE_HAS_CARRIER} {FE_HAS_SYNC | FE_H
>> AS_VITERBI} {FE_HAS_LOCK}
>>
>> sync had varying values with status=31:
>> sync=47
>> sync=63
>> sync=15
>>
>> I haven't been able to get a picture yet.
>> While writing this email, I was able to get Kaffeine to open the pipe
>> for picture reading.
>> After testing the driver once, I have to reboot: the dvb card does not
>> respond otherwise.
>> cu1216_sleep() might be the cause for that: it powers down ADC and does
>> standby.
>>
>> I suspect that doing standby is the problem and thus:
>>
>> xine calls cu1216_sleep() before opening the pipe with FC5 and so it
>> can't read data stream.
>> Kaffeine calls cu1216_sleep() on exit. So restarting Kaffeine won't
>> work, but data stream reading
>> might work just after reboot as I have seen once.
>>     
>
> Just comment out the sleep callback in the ops struct in cu1216. That
> will make it not to sleep anymore, for debugging/testing.
>
>   
>> Here is the blocking problem for me (acquired with Kaffeine with lots of
>> added debug messages):
>>
>> Oct  8 22:12:43 koivu kernel: [cu1216_read_status]: status = 31, sync=47
>> {FE_HAS_SIGNAL | FE_HAS_CARRIER} {FE_HAS_SYNC | FE_HAS_VITERBI}
>> {FE_HAS_LOCK}
>> Oct  8 22:12:43 koivu kernel: mantis start feed & dma
>> Oct  8 22:12:43 koivu kernel: CALL cu1216_read_status
>> Oct  8 22:12:43 koivu kernel: [cu1216_read_status]: status = 0, sync=0
>> (Note: the signal has been lost here!)
>> Oct  8 22:12:43 koivu kernel: CALL cu1216_set_parameters
>> Oct  8 22:12:43 koivu kernel: CALL cu1216_read_status
>> Oct  8 22:12:43 koivu kernel: [cu1216_read_status]: status = 0, sync=0
>> ....
>>
>> If somebody wants my version of cu1216.c, I can send it by email.
>> The slowness makes it unacceptable as a final implementation.
>>     
>
>
> You can send it over/post it here itself.
>
>
> Regards,
> Manu
>   

-------------- next part --------------
A non-text attachment was scrubbed...
Name: cu1216.c
Type: text/x-csrc
Size: 28657 bytes
Desc: not available
Url : http://www.linuxtv.org/pipermail/linux-dvb/attachments/20061009/e68f9f97/cu1216-0001.c


More information about the linux-dvb mailing list