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 _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
