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
mb86a16_read_status()
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
mantis/linux/drivers/media/dvb/mantis/mantis_dma.c
--- 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
17:44:31.000000000 +0300
@@ -192,7 +192,7 @@ void mantis_dma_start(struct mantis_pci
mantis_risc_program(mantis);
mmwrite(cpu_to_le32(mantis->risc_dma), MANTIS_RISC_START);
- mmwrite(MANTIS_GPIF_RDWRN, MANTIS_GPIF_ADDR);
+ mmwrite( mmread( MANTIS_GPIF_ADDR ) | MANTIS_GPIF_RDWRN,
MANTIS_GPIF_ADDR);
mmwrite(0, MANTIS_DMA_CTL);
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) ) ),
MANTIS_GPIF_ADDR);
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
block=[%d]",
mantis->last_block, mantis->finished_block);
- (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_BLOCK_BYTES], MANTIS_BLOCK_BYTES);
mantis->last_block = (mantis->last_block + 1) % MANTIS_BLOCK_COUNT;
}
MANTIS_GPIF_ADDR changes (two of them) are meant to enable
mb86a16_read_status()
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
zero always.
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).
Regards,
Marko Ristola
Elmar Schmidt wrote:
Hi,
I aded the Lines from Marko Ristola to my cu1216.c File.
Anywere:
---
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
modules-update
depmod -a
Infos:
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.
SORRY.
--Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
_______________________________________________
linux-dvb mailing list
linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
_______________________________________________
linux-dvb mailing list
linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
