[linux-dvb] Re: Mantis VP-1027/VP-1033/VP-1034/VP-2033/VP-3033
abraham.manu at gmail.com
Mon Oct 16 20:09:05 CEST 2006
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:
> 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.
> Marko Ristola
More information about the linux-dvb