marko.ristola at kolumbus.fi
Wed Nov 29 21:28:53 CET 2006
I hope you can try to figure out your problem
with these advices and code snippets.
I had lock taking problems also.
You could debug the locking issue by
printing a debug message of state->signal on function
When that number changes, there is some change in the signal
status. The last change might be a LOCK: It should not be
zero during DMA transfer.
You could try the following changes, that have helped me.
These aren't on the original Mantis Alpha version, but I have sent
these patches for Manu for inclusion into Mantis branch,
into this email list on 2006-10-30 - the full patch.
diff -up -r mantis.alpha/linux/drivers/media/dvb/mantis/mantis_dma.c
2006-10-19 17:24:03.000000000 +0300
+++ mantis/linux/drivers/media/dvb/mantis/mantis_dma.c 2006-10-19
@@ -192,7 +192,7 @@ void mantis_dma_start(struct mantis_pci
- mmwrite(MANTIS_GPIF_RDWRN, MANTIS_GPIF_ADDR);
+ mmwrite( mmread( MANTIS_GPIF_ADDR ) | MANTIS_GPIF_RDWRN,
mantis->last_block = mantis->finished_block = 0;
@@ -208,6 +208,7 @@ void mantis_dma_stop(struct mantis_pci *
u32 stat = 0, mask = 0;
+ mmwrite( (mmread(MANTIS_GPIF_ADDR) & ( ~(MANTIS_GPIF_RDWRN) ) ),
stat = mmread(MANTIS_INT_STAT);
mask = mmread(MANTIS_INT_MASK);
dprintk(verbose, MANTIS_DEBUG, 1, "Mantis Stop DMA engine");
@@ -231,7 +232,7 @@ void mantis_dma_xfer(unsigned long data)
dprintk(verbose, MANTIS_DEBUG, 1, "last block=[%d] finished
- (mantis->ts_size ? dvb_dmx_swfilter_204: dvb_dmx_swfilter)
+ (mantis->ts_size ? dvb_dmx_swfilter: dvb_dmx_swfilter_204)
(&mantis->demux, &mantis->buf_cpu[mantis->last_block *
mantis->last_block = (mantis->last_block + 1) % MANTIS_BLOCK_COUNT;
MANTIS_GPIF_ADDR changes (two of them) are meant to enable
to work during DMA transfer. That is a requirement for a
stable LOCK. Without it you might get a lock, but you
lose it immediately and never get it back. cu1216_read_status() returned
So without that patch you can't (re)get or keep a lock during DMA transfer.
The choise between dvb_dmx_swfilter() and dvb_dmx_swfilter_204() isn't
clear for me: with cu1216.c with DVB-C with cable TV in Finland
the "+" line works with me, but somebody needed the opposite.
The picture is garbage with a huge number of bad frames, if it goes
wrong, while the bit error rate from the card is zero.
(TS is read correctly, but parsing the TS data fails on software).
Elmar Schmidt wrote:
> I aded the Lines from Marko Ristola to my cu1216.c File.
> static int cu1216_get_tune_settings(struct dvb_frontend* fe, struct
> dvb_frontend_tune_settings* settings)
> settings->min_delay_ms = 50;
> settings->step_size = 0; /* FE_QAM: zero */
> settings->max_drift = 0; /* FE_QAM: zero */
> return 0;
> In dvb_frontend_ops:
> .get_tune_settings = cu1216_get_tune_settings,
> But it doesnt work. Same Output like before this Changes :(
> Is anything wrong with this Changes? Wrong Lines maybe?
> After i added these Changes I did the following:
> make all
> cp v4l/cu1216.kp /lib/modules/kernel/drivers/media/dvb/mantis/
> make install
> depmod -a
> amd64 Gentoo 2006.1
> PS: Hope this opens not a new Thread. If this Mail opens a new Thread,
> so I have to say sorry. I dont get the Answeres in my E-Mail Programm
> to work.
> --Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
> linux-dvb mailing list
> linux-dvb at linuxtv.org
More information about the linux-dvb