[linux-dvb] Re: Mantis VP-1027/VP-1033/VP-1034/VP-2033/VP-3033

Manu Abraham abraham.manu at gmail.com
Mon Oct 16 20:09:05 CEST 2006

Hello Marko,

Marko Ristola wrote:
> Hi Manu,
> I downloaded your code again.

I haven't updated the code out there.

> 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
> never try
> 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.

what Rev number do you have on your board .. ? It sounds a bit strange
though, i need to test a bit to verify the same.
what numbers do you have just below the "Mantis" on the chip ?

> 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.

DMA should be started only after a LOCK, but it is not the driver that
which starts the DMA but it is in the dvb-core. Need to see why DMA is
initiated much earlier, causing garbage in the buffers.

I will check it out in the coming few days.

> mmwrite(MANTIS_GPIF_RDWRN | 0x3000, MANTIS_GPIF_ADDR); // the idea is
> just not to change 0x3000 bits
> Here is another version:
> // 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.
> Regards,
> Marko Ristola


More information about the linux-dvb mailing list