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: > 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. > > > Regards, > Marko Ristola > Regards, Manu _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
