[linux-dvb] Re: Mantis VP-1027/VP-1033/VP-1034/VP-2033/VP-3033
marko.ristola at kolumbus.fi
Sun Oct 15 22:22:03 CEST 2006
I downloaded your code again.
Known problems in cu1216.c and in mantis_dma.c with VP-2033:
In your codein cu1216_set_parameters() it still returns -1 or -EINVAL
always (never returns a success=0).
So kaffeine application tries to set parameters indefinitely and will
to use DMA transfer.
cu1216_set_parameters() doesn't check the lock status in your code.
I did such a change and I did get the lock and that function
returned 0 when it had the lock. It returned -1 if it didn't have the lock.
If the status function is not responsive (returns always 0 with any input),
the application will never get cu1216_set_parameters() return 0 (success).
Pauli Bordoulin found out that MANTIS_GPIF_ADDR has something
to do with the status nonresponsiveness. That is why I tried with 0x3000
on mantis_dma.c on this VP-2033. It seemed to help then:
i2c remained responsive.
How the DMA transfer should begin?
Is it so, that when the application has a LOCK,
it can freely start a DMA transfer. Is it so, that the LOCK must be in "
With me the result is distorted, with both QAM64 and QAM128.
With my code the distortion is still a mystery for me.
mmwrite(MANTIS_GPIF_RDWRN | 0x3000, MANTIS_GPIF_ADDR); // the idea is just not to change 0x3000 bits
Here is another version:
mmwrite(MANTIS_GPIF_RDWRN | mmread(MANTIS_GPIF_ADDR), MANTIS_GPIF_ADDR); // the idea is just not to change 0x3000 bits
Personally I'm not sure about the correct fix though.
Then there is the LOCK problem next.
I did something like this:
1. figure out optimal errRate.
2. Use that and try to get a lock.
3. If not, iterate with more time and do 1 and 2 again.
(these are done with both inversed and noninversed modes.
Manu Abraham wrote:
> Sorry i had been away the past few days. In fact dvb-core should start
> DMA only after there is a LOCK. I faced this issue (getting garbage in
> the DMA queue, before there is a valid LOCK), but i was able to get a
> LOCK, but that was with a DVB-S card, but the same bridge.
> Need to check a bit as to what's the exact issue in there.
More information about the linux-dvb