DM355 VPBE: How do I get digital video in the VPBE output pins?

All 4 windows you described above are available at both analog and digital video output interfaces; which interface is selected for output depends on which one is enabled via bootargs (and possibly sysfs); the PSP documents describe this in more detail..

Thank you very much!

Where can I get that PSP documents? What does PSP stand for?

PSP (Platform Support Package) docs are included in DVSDK.  If you have the latest DVSDK Installed, you should see a directory with a name similar to

   /home/<user>/dvsdk_1_30_00_41/PSP_X_XX_XX_XXX/docs

After reading the documents (thanks again Juan) I still have some doubts. Is it true the next assignation?

· /sys/class/davinci_display/ch0/output --> digital output ?

· /sys/class/davinci_display/ch1/output --> analogic output ?

And related to this I have seen that "/davinci_display" is a non-existent directory inside "/sys/class". What can I do?

I believe in the case of the DM355 you only have one channel so you only would work with ch0, to change ch0 to a digital output you would run 'echo "LCD" >/sys/class/davinci_display/ch0/output' or replace LCD with COMPONENT1, the two digital output modes supported in the PSP driver package are for the Logic PD LCD daughterboard and the THS8200 daughterboard which you would be configuring for with the two settings given respectively.

If you are missing /sys/class/davinci_display than it is possible that you are running a version of the kernel other than the version discussed in the PSP documentation (earlier versions did not have the sysfs interface), I would make sure you are booting your kernel and filesystem from the same DVSDK install you are getting your PSP docs from.

Thank you for your answer!

The thing is that I have the /sys/class directory, but there is no /davinci_display directory inside it. So I guess the sysfs interface is ok. But how can I install (or load or whatever) /davinci_display?

Besides, why is there VPBE analog video output (I can see this video signal) without having the /davinci_display directory? Where is it selected then?

What DVSDK version are you using?

Normally, when you buy a DM355 EVM, you register at www.ti.com/davinciregistration and this will give you access to our software update site www.ti.com/davincisoftwareupdates where you can get the latest DVSDK releases.

As Bernie suggested, not all our DVSDK releases have sysfs support for the video drivers; in older DVSDKs, we provided digital analog support, and had ell the /dev/fb/x device nodes present for all 4 windows supported by the hardware, but there was no sysfs support for our video drivers (hence no /davinci_display directory ).

As I tried to point out, in the latest DVSDK (which have sysfs support for video peripherals), the PSP directory has documentation on how to use this sysfs support.  Apologies if we were not very clear with this information.

Don't worry Juan and thanks again. Right now I'm using the dvsdk_1_30_00_40. I thought this version already had the sysfs support. Which is the first version that comes with this support? Does the one I'm using have it?

you are correct, dvsdk_1_30_00_40 should have this support; unfortunately, I am traveling this week and away from my hardware, but maybe someone else can verify this and chime in.

I am running 1.30.00.41 and I have it, I dont have a 1.30.00.40 install handy but I suspect based on Juan's comments that it should have the sysfs support as well.

If you are not seeing it my first thought would be that you may inadvertently be still booting an older kernel, such as if you were booting your kernel out of flash which was never updated to the newer version with the sysfs entries. In this case you may want to try setting up your board to boot with TFTP (for the kernel) and NFS (for the file system) so you boot over the network to ensure you are using the kernel and filesystem from the newer DVSDK, this operation is discussed in the getting started guide.

Ok. I've checked that I'm running a new version of the Kernel (Linux_IPNC_1.1.0) but it still doesn't work. It may have to do with the fact that when running the 'make menuconfig' command I'm not able to load "DaVinci Encoder Manager". Here it is the menu where I think "DaVinci Encoder Manager" should be ("Video For Linux" menu inside menuconfig):

 --- Video Adapters                                                                                 
  │ │                                                 <*> TVP5146 video decoder                                                                       
  │ │                                                 <*> MT9T001 video decoder                                                                       
  │ │                                                 <*> MT9P031 video decoder                                                                       
  │ │                                                 <*>   DM355 Video Capture                                                                          
  │ │                                                 <*>     DM355 IPIPE                                                                            
  │ │                                                 < > Davinci Video Capture                                                                      
  │ │                                                 <*> Davinci Video Display                                                                       
  │ │                                                           < >   Davinci DAC Encoder (NEW)                                                                   
  │ │                                                 < > DM355 Auto Focus Driver                                                                    
  │ │                                                 <*> DM355 Auto exposure /White Balance Driver                                                    
  │ │                                                 < > CPiA Video For Linux                                                                           
  │ │                                                 < > SAA5246A, SAA5281 Teletext processor                                                        
  │ │                                                 < > SAA5249 Teletext processor                                                                
  │ │                                                 < > SAB3036 tuner                                                                                
  │ │                                                 < > OmniVision Camera Chip support        

So I have two questions right now:

1.- Is it possible in any way to modify a kernel to add the "DaVinci Encoder Manager" option? I think this might be part of the solution. Anyway, if I'm wrong, feel free to tell me.

2.- How could I do things without the sysfs support?

I am not sure where you got Linux_IPNC_1.1.0 from, perhaps this is a support package from one of the DM355 IP netcam kits? I have never had a chance to work with one of the IP netcam kits so I am not sure what software stack they come with, it is possible that their Linux support package does not include the sysfs support. See below for the make menuconfig options for the DVSDK 1.30.01.41 LSP.

R&D said:

1.- Is it possible in any way to modify a kernel to add the "DaVinci Encoder Manager" option? I think this might be part of the solution. Anyway, if I'm wrong, feel free to tell me.

It certainly is, though I have not done enough work with sysfs in drivers to explain how properly, there is some discussion on sysfs in LDD3 though it would be some significant effort to implement it yourself, though you may be able to integrate the code from the more current DVSDK Linux support package to make it easier. Optimally you probably just want to use the DVSDK kernel if possible.

R&D said:

2.- How could I do things without the sysfs support?

You should be able to have a similar effect with the IOCTL APIs for the display driver, though since it seems you are not using the current DVSDK version, and I am not sure what display drivers you are actually using, I could only refer you to your driver documentation.

You're right Bernie, it's the support package from a netcam kit. Definitely, I cannot see the "Davinci Encoder Manger support" option in the menuconfig. As I think it's not worth implementing it in my kernel, I'm trying to cope with what I have now.

And I think I have good news: I've tried writing "video=dm355fb:output=ntsc:format=ycc8" in my bootargs and apparently that seems to work. I can see activity in the digital video pins (pixel CLK and horizontal/vertical sync). Right now I'm testing the signals in the YOUT pins to check if they are correct. It's great news! But unfortunately that means to eliminate the analog video output. Do I really have to chose one or is it possible to use both?

Besides, although I can see the pin activity, I get an error during initialization: "Encode Error: Failed mmap on /dev/fb/2". It seems the OSD1 mapping is failing. What can this be due to?

So my questions are now:

· How can I use both digital and analog video at the same time?

· Why does it fail during initialization?

Thanks again. I really appreciate your help.

I've just checked the digital video lines (YOUT) and there's no activity in them. Anyway, the HSYNC, VSYNC and PixelCLK signals seem perfectly correct. Any ideas?

I've just checked the digital video lines (YOUT) and there's no activity in them. Anyway, the HSYNC, VSYNC and PixelCLK signals seem perfectly correct. Any ideas?

Well, after studying the situation I guess the task left to do is to configure all the VPBE registers. Is there any place I can get a standard configuration of them to output YUV422 video directly or do I have to go one by one through all of them?

Besides, is it possible to modify the registers content from the console? I've tried "echo ADDRESS VALUE > /proc/davinci_vpbe" but surprisingly [:)] there's no "davinci_vpbe". Might "/proc/iomem" be an option? Any other ideas?

It seems I finally have some results as I can see activity in the VPBE YOUT and CLK lines. Anyway, my question now is about checking these results: is there any possibility to see in the software the data being output in these pins? It would be important to check the format of the signal.

Thanks in advance.

I apologize for the lack of response to this thread, we did miss a few alerts do to a software upgrade.

That said, hopefully I can help shed some light here.  There is no way to read the data being output thru YOUT, COUT pins.  However, normally this data is stored in DDR2 prior to being output so potentially, you could see it there. 

Each of the four frame buffer windows (two video and two OSD) you described in your first post (/dev/fb/0 thry /dev/fb/3) represents a buffer in DDR2.   Depending on which of the 4 windows you have enabled, data from their corresponding buffers are merged and output via YOUT and COUT when digital output is enabled in hardware.  Therefore, theoretically, if all you have enabled is /dev/fb/3 (VID1 window) with default format YCbCr 4:2:2, then essentially what you should see in the YCOUT pins is what is stored in VID1's corresponding buffer.  However, keep in mind that VPBE is very flexible and allows swaping of Y and C component, or even swaping of Cb and CR components; this gives user maximum flexibility to interface to other part which may expect pixel order a bit different than the default.  In conclusion, due to the various video windows and VPBE configuration, the only dependable way to know exactly what is at the YOUT and COUT pins, is to use an oscilloscope.

I hope this helps.

Don't worry Juan, you don't have to apologize.

Well, after some experiments I think I'm able to say that I'm outputting YUV video correctly. The task now is to capture this video in the DM6437 VPFE. The closest I've got to success has been through the RawCaptureLoopback example (dvsdk_1_01_00_15\psp_1_00_02_00\pspdrivers\system\dm6437\bios\dm6437_evm\src\video\sample\rawcapture). But it still doesn't work properly. The video output I'm getting right now is the one shown in the image (sorry for the flash spot...):

I think everything is correctly configured. Besides, the upper-left rectangular window shows variations when changes (light variations) happen at the entrance of the video. It looks like a format problem or similar.

Any idea about what's going on? Thanks in advance once again!

Please! Help!

What is the pixel format of your video input source? RAW mode assumes Bayer Pattern pixel format, which is typical of CCD sensors; however TVP5146 found on BT.656 EVM uses BT.656 (by default) which assumes YCbCr 4:2:2 pixel format.

The DM6437 video input is supposed to be PAL YUV-8, as it is the video I'm outputting from the DM355. After trying with all the possible input formats available in the RawCapture example (YCbCr, RGB, RAW, etc.) I've checked that RAW is the only one that gives an output video signal (the one I showed in the picture). The others cast no video output at all.

The configuration of the DM6437 is shown here:

static PSP_VPFECcdcConfigParams ccdcParams =
{
    FVID_CCDC_RAW_FORMAT,               /* dataFlow     */
    FVID_FIELD_MODE,                          /* ffMode       */
    576,                                              /* height       */
    720,                                              /* width        */
    (720 *2),                                       /* pitch        */
    0,                                                  /* horzStartPix */
    0,                                                  /* vertStartPix */
    NULL,                                            /* appCallback  */
    {
        NULL,                                        /* extVD Fxn    */
        NULL,
        NULL,
    },
    0,                                                 /*segId         */
    {
        PSP_VPFE_BITS8,                      /* dataSize     */
        PSP_VPFE_PACK8_8BITS_PIXEL,  /* pack8        */
        PSP_VPFE_DataPol_Normal,      /* dataPol      */
        PSP_VPFE_SyncPol_Positive,      /* VDSyncPol    */
        PSP_VPFE_SyncPol_Positive,      /* HDSyncPol    */
        PSP_VPFE_SyncDir_Input,          /* HDVDMaster   */
        50,                                            /* HDSyncWidth  */
        4,                                              /* VDSyncWidth  */
        800,                                          /* numPxlPerLine*/
        1000,                                        /* numLinPerFld */
        PSP_VPFE_ALaw_Disable,          /* ALawEnable   */
        PSP_VPFE_ALaw_bits15_6,         /* ALaw_Width   */
    }
};

I wasn't sure about the HDSyncPol (as I think is negative) but changing it causes no effect in the video output. Any other clues?

One last thing: what is the BT.656 EVM?

If the DM355 is really outputting all the data than to get the image shifted onto your screen you would need to start playing with the values in the configuration you show here such as horzStartPix and vertStartPix, this is probably easiest if you can have the DM355 outputting some sort of test pattern you can recognize on the DM6437 so you can see how the data is transforming to the DM6437's display (i.e. is is cropped, scaled, shifted, color, etc.).

Assuming you only want to send video, and that video will be standard definition NTSC/PAL than the easiest way to transfer from the DM355 to the DM6437 would be to set both to bt.656 so you don't even need the external syncs, just the clock and data bus. With bt.656 since it is standardized you could almost use the video_preview example out of the box to pass through video, you would just need to ensure it does not get hung up on any initialization with the TVP5146 which would be disconnected.

R&D said:

One last thing: what is the BT.656 EVM?

There is no BT.656 EVM, I think that is a typo, it seems he meant that the TVP5146 found on the DM6437 EVM uses BT.656.

Thank you Bernie. I'm working on it. But meanwhile I have another "basic" question. What command may I use to show text from the DM6437 psp_driver code? I've tried printf and printk but it doesn't work. Any ideas?

On the DM6437, assuming you have Code Composer Studio connected up to it, you should see printf calls coming out of the stdio window in CCS. The two biggest reasons you would see nothing coming out from a printf on DM6437 on CCS would be if you did not have stdio.h included on the C file or if you have no heap allocated. Also note that you should have a \n at the end of the output of the print statement to flush the buffer and put in a carriage return (or if you have just a single printf with never any \n you may never see anything).

Thanks again Bernie! That was really useful!

Yet I have another question. Is there any document/example where I could find how to configure the DM355 VPBE to output video in BT.656 format? I think I'm kind of doing it, but with some mistakes. I'm checking what's wrong...

Well, I would bet everything is properly configured, but the result still looks like this (it is configured to output colour bar pattern):

Any idea about what might be wrong?

Assuming you are using digital video interface on DM355, you will need to ensure that YCCCTL.R656=1 and VIDCTL.VDMD=0, and that you have the proper clock source.

R&D said:

Well, I would bet everything is properly configured, but the result still looks like this (it is configured to output colour bar pattern):

Any idea about what might be wrong?

How are you viewing your video output?  Is it safe to assume digital video output to a daughter card?  If so, what daughter card are you using?    At first glance it looks like it may be that some pixels bits are being chopped off (e.g. only 6 bits per pixel connectd vs 8-bits ) or maybe Cb and CR components are swapped (you can configure this via VPBE registers).

Well, not really through a daughter card but through another software (it's not mine but it works) that runs on the DM6437 and shows the input video (that's where I captured the colourbar image I posted). I've already checked that no pixel bits are being chopped out (that was my first impression too!).

After checking signals in the oscilloscope I've found out that the sync words used in BT.656 before and after data are aparently correct. But I don't like what comes out next: I don't think the signals are correct. Next image shows some signals captured between DM355 VPBE and DM6437 VPFE:

Although they can hardly be seen, I can say that sync words are there. My questions are:

· Should VSYNC and HSYNC be present? I mean, if BT656 mode is selected in the DM355 VPBE, aren't these lines turned off?

· Is the result logical according to the colourbar pattern? If so, that would mean that Y, Cb and Cr have the same values for near pixels. Is that logical? There are hardly any changes in the data lines through a whole line. I'm not sure if I'm explaining it well...

· Going on with the last point: what should be the values of Y, Cb and Cr in the colourbar pattern? Is there any place I could get these values to compare with what I'm capturing?

As usually: thank you very much for your help!

I have heard from others that there is VSYNC/HSYNC activity at the pins even when in BT.656 mode; I have not investigated if there is a way to stop this activity, but I would not recommend using these pins when in BT.656 mode.

In color bar pattern, you normally have a bunch of same color pixels next to each other, depending how much data you are captuing on the oscilloscope, you could see same Cr and Cb ( and Y for that matter) over a long range of pixels on the oscilloscope, but certainly not the entire line. 

The following website should allow you to enter values for Y, Cb, and Cr and let you know what color you should be expecting to see as a result of these values: http://www.dvd-replica.com/DVD/colorrgb2.php?c=5

Just a comment on your colorbar output image, though there is probably more to it, in general if you see that sort of pink and green output it will often mean (from personal experience) that your luma (Y) and chroma (C) values are swapped (i.e. your receiver thinks it is getting YCbYCrYCbYCr... but it is really getting CbYCrYCbYCrY... or vice versa). When I was seeing this happen it was due to noise/interference on my cabling scheme, but it could be just a setting issue in your case.

You can tweak this on either end, but for starters you may try adjusting this on the DM6437 end with the BSWD and Y8POS bit fields in the CCDCFG register as discussed in section 6.1.22 of SPRU977, at the very least this should make the video output from the DM6437 look different (assuming you have DM355 -> DM6437 -> TV).

Ok, first of all it's good to know that HSYNC and VSYNC activity is normal while in BT.656 mode (I thought something was going wrong).

Related to what you said Bernie, I'm not totally sure if the order of Y, Cb and Cr expected in the DM6437 is the same order DM355 is sending. But before that there is something I can't understand: in my opinion the colour bar at the dm355 output is not correct.  I've found out (VPBE datasheet) that the colour bar should have these values:

        Color                Y           Cb          Cr        
        Black              16        128        128       
        Blue                41        240       110     
        Red                 81          90       240     
        Magenta       106        202       222     
        Green           145          54         34      
        Cyan             170        166         16      
        Yellow           210           16       146     
        White            235        128       128    

So the output should be something like this for a whole horizontal line (N would be the length of each bar so that N x number_of_bars)=image_width):

Y Cb Y Cr Y Cb Y Cr ... => (16 128 16 128) x N times ... (41 240 41 110) x N times ... etc => (Black pixel) x N times ... (Blue pixel) x N times ... etc

But according to my last posted picture, that's not what dm355 is outputting. What I see is three colour bands (as shown in red in next image): 

Band 1 is 0xAB [171dec], band 2 is 0x9B(155dec) and band 3 is 0x81 (129dec). Comparing to the desired output, we have:

Y Cb Y Cr Y Cb Y Cr ... => 171 171 171 171 ... 155 155 155 155 ... 129 129 129 129

That's why I think the colour bar is not correct: Y, Cb and Cr have the same values throughout the whole colour bar!! And that's exactly what DM6437 is seeing, three colour bars: light pink (Y=Cb=Cr=171),  dark pink (Y=Cb=Cr=155) and grey (Y=Cb=Cr=129).

Why is the colour bar incorrect? Any ideas?

I have good news! Finally I can see the colourbar perfectly. But when I turn the colourbar off there's something wrong with the video. Next image shows what I see:

It looks like a lack of synchronicity. I'm quite sure it has to do with the offsets of the data signals or something similar, but after trying some register values I still can't find the way to make it work properly. Ideas about what's going wrong?

Any ideas?

I am glad to hear that the color bar is now working, however as to this new image it looks like things are certainly out of sync as you suggest though this is likely internal as opposed to an external sync issue. Most likely this is an issue with the buffers in one of the devices (likely the sender since the color bar part worked) not being aligned with the settings of the video port. I suspect your video buffer is wider than the video port is expecting, such that each line of data in the buffer takes up slightly more than a line of display, leading to the entire image to be slanted down and to the right as shown in your screen capture. Since this is likely on the transmitting device that was sending the color bars due to the color bars working I would start by tweaking the width of the buffer in memory or the perceived width the VPBE has of the display buffer. It may be eaiser to visualize this by filling your buffer with a pattern of data as opposed to using real image data to start.

Well, it finally works! I can see video! Thank you all for your help. But yet I have another question. There are a couple of bands at the sides of the image (as seen in next picture), a bottom black band and a left purple one. I'm trying to eliminate them but I can't find the way. Any ideas?