Video Output from VPBE in a start/stop mode

Sundar,

How are you cleaning up when you stop the VPBE?  Are you waiting for a frame sync, and flushing all memory buffers (or at least make sure none are in th middle of being processed, for example by codec engine).  Are you keeping DDR2 enabled during VPBE-off period?

Also, how does the garbage data look like; does it resemble the video data that was being viewed right before VPBE was turned off?

Hi Juan,

So Nice to hear from you after such a long time:)

I follow these steps in my routine.

1. Turn off VENC

2. Disable interrupts

3. Turn off VPBE output clocks like sync, pixel clock etc.

I do not wait for a frame sync; and I am running only ARM-Linux application; I do not touch the DDR settings for other processes would be using it.

I have a view that the VPBE peripheral as such is not desgined to abrupt clock changes on the HW. Saying this because a normal video display interface wouldnt require/mind turning off clocks!. I tried with varying blanking periods for the HSync as well to make sure that I allow the VPBE to output after some settling time. But I derive that the settling period for VPBE is atleast one frame time...

I would imagine that so long as you are only disabling VPBE (e.g. capture and decode video buffers are still running and not stopped in the middle of a frame), you should not have any problems when you restart VPBE.  I assume that you keep same DDR2 window (2 OSD and 2 video) address settings for the hardware in the VPBE driver; if so, when VPBE is re-started, it should start reading data from the corresponding DDR2 memory locations.  One thing you can try is to verify integrity of data in DDR2 prior to turning on VPBE.

Hi Juan,

I checked out this thing as the first debug experiment and found that the data in the DDR is exactly what I intend it to be. I am trying to zero it down to my curiosity if this is at all a silicon issue that doesnt respond to fast clock transition.

Sundar,

All silicon issues are described in the errata document; I believe you are using the DM6446, if so the errata should be found here http://focus.ti.com/lit/er/sprz241l/sprz241l.pdf

By quickly looking thru it, it seems like advisory 2.1.42 describes some inompatability with legacy Linux drivers that may cause some video jitter; a software workaround will be issued with next LSP release.  However, based on the descripton, it appears this would happen all the time, not only when it is first enabled.  Nevertheless, it may be contributing to what you are seeing, so it is definitely worth a look

If you are freeing and reallocating the display buffers it could explain some corruption, one particular aspect to keep in mind is caching, it is possible that you may not be seeing what is really in DDR because of the cache, so there may be junk out there that is getting cleaned out as your application runs. If you could provide more detail on what the corruption in the output looks like we may be able to provide further feedback as to what the cause could be.

Sundar,

How are you verifying that DDR2 data is good?  After discussing this with Bernie, if you are reading this thru CPU, you may be seeing cached data.  We are just curious as to how you are verifying DDR2 data is what you intend to see when you enable VPBE back on.

Hmm. Ok. I did some basic checking on the caching part. I read somewhere about invalidating cache and that stuff; but it doesnt have anything like that on the linux side. I reference the values of my start address in the buffers at the driver level itself and the prints are all ok. It is only when I see the output on the analyzer that I find that this is all either 0x00 data all till probably half the frame, and next frame onwards all correct data. But this behaviour is very wierd as I do not see 0x00 all the time. It is sometimes a remnant of the previous transfer that I did previously. and that was when I thought probably caching is some causing some problem but dropped it when saw that I can get all zeros also!

I dont disallocate the buffers at all. Only thing that i turn off the clocks as described above; the turn on is fairly just the opposite with the additional code for setting my timings on the VENC.

Can there be some time latency being required by the VENC to start outputting in different conditions as in a power reset and a clock reset?

There may be some latency but I would imagine that it is less than the frame period. Could you post a picture of the corrupted output? If we can see the output corruption it may help us to better suggest what may be causing it.

Sorry Guys..for I dont have the outputs with me. I will try to see if I can get the log outputs for the phenomenon!.

But was just thinking, if even the printks in the driver would be cached or not. Is it possible to use the CCS at this time to debug the memory values rather than depend on the linux calls?

Sundar,

You can use the attached program to do a memory dump (e.g. such as checking contents of video frame buffer in DDR2)

Steps to follow -

gcc devmem_test.c devmem_test.o

# ./devmem_test.o -r -4 -l <no. of words to read> <Physical address of register>

Sorry Juan, but where can I find the devmem_test.c file?

I am sorry. I missed the link!!!

Sundar said:

Sorry Juan, but where can I find the devmem_test.c file?

Sundar,

The file is attached to the message I posted earlier