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.

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.

Regards,
Marko Ristola


_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Reply via email to