VPBE Clocks -Configuration to digital output and confusion about names

Ermaan,

I would start with the easiest of one I know :)

"-DM6437 VPBE document (SPRU952A) uses a "ENC clock" definition. For example, HSPLS register definition has "Horizontal sync pulse width (number of ENC clocks.)" But I don't see any other reference to ENC clock, other than in the register definitions. Do you have any idea what ENC clock may be? (I would say it is the VPBECLK, which is defined in VPSS_CLKCTL, but I am not sure.)"

I dont remember the exact definitions; but this is more less related to the output pixel clock only. Like, for a YCC 16bit-per-pixel configuration, two pixel clocks are required to output one pixel information (2 bytes; one byte xferred on one pixel clock). So the value fed into the HSPLS register must be twice the horizontal resolution. Eg a horz width of 720 should have the HSPLS value as 720x2. Else for the PRGB conifguration, when the one pixel clock outputs one pixel per clock (8 bits R, 8 bits G, 8 bits B ona 24 bit RGB interface),  this HSPLS value must be programmed as the horz width itself. Meaning, you need only that number of horizontal pixel clocks to output one line.

"-In DM6437 VPBE document, it says "VPBE must interface with a variety of LCDs, as well as 4-channel DAC module." When I examine LCD configuration in Digital Video Using DaVinci Soc document, and the codes provided, I see no DAC clocks are configured. Is this a problem? What is the difference between the DAC and VPBECLK?"

The DAC is for analog outputs, unrelated to the LCD outputs. Hence, you dont see any initialization of DAC modules in the code specific to the LCD output. Whilst for the rest of the analog outputs like composite, Svideo, component you would see the DAC reghosters being configured.

"-Also there is the "pixel clock". The pixel clock works as for every clock there is a new pixel color data. Is this not the same thing with the dot clock? If not, what is the difference? In Digital Video Using DaVinci Soc document, I understand that pixel clock is referenced as the VPBECLK, if I am not wrong. VPBECLK is set to 27MHz in muxsel by default, and it says if you need another frequency of "pixel clock " other than 27Mhz like 74.25Mhz, an external oscillator is needed. So we can consider VPBECLK is the same thing with pixel clock, cant we?"

Practically, its the same thing. In a simple term, I associate the VPBECLK to the output video pixel clock like 27MHz, 54MHz using the Muxsel registers, and any frequency greater than 54MHz supplied by the VPBEEXTCLK (the external VPBE Clock)

"-Also we have a small LCD which needs a clock frequency of min 5 Mhz and max 6 Mhz. Is it possible to adjust these values defining a pattern for DCLK? Do I need anything else?"

I read some earlier post regarding this somewhere in the forum. He was able to do this using some DCLK register values. Probably you can look up that!

"-We are not configuring Osd clocks as it is in the LCD configuration part of Digital Video Using DaVinci Soc document. Is this a problem?"

I think its OK. My experience says it doesnt affect much. Juan is the best expert on this :)

This may be a bit lengthy, but then I got my modules working by the above points :). Hope this helps!!

SundarIyer, 

Thanks for the support. It cleared a good amount of my doubts about DACs, pixel clock-VPBECLK confusion and OSD clocks.

-We are using the pixel clock, or the VPBECLK, in 54Mhz, and created a DCLK pattern and succeded taking a frequency of 5.4Mhz. (although it is not looking perfectly in the oscilloscope, we have the frequency -suspecting the oscilloscope doesn't show precisely.) Hence our muxsel is configured as 1h, which means CLK_VENC and CLK_DAC is 54Mhz. But in the VPBE document, it says "In this mode, the VENC clock must be divided-down 27 MHz via the VENC_DIV bit in the VPBE peripheral control register (PCR)." What is the meaning of this? I need a 54Mhz clock but it says I have to divide to 27Mhz. Or the fact is that it is possible to use the clock in 54Mhz but I should be awaring of using VENC_DIV to use it in default mode, 24Mhz, when muxsel is set 1h. That's a little confusing.

-About the ENC clock... Actually HSPLS was just an example where the ENC clock is referenced. But if it In LCD configuration, for a 640*480 LCD, with a frequency of 27Mhz, HSPLS is set to 96, and VSPLS is set to 32. I didnt understand how these values are given, but they are already defined in SHARP LCD datasheet, and for our LCD (240*320), they are not given.

OOPsssss...

Erman, The HSPLS and the VSPLS registers are for the HSync and the VSync lengths; In a more layman terms , the width of the Hsync and VSync. The actual Horizontal widths and vertical heights are programmed via the HVALID and the VVALID registers. Sorry for the goof-up; reading your reply struck me. But the concept is same with reference to the ENC clocks.

Well, for the LCD, this blanking and sync length is customized for 640x480. Even you would have to do that. You can either use the same blanking and check if your test image fits perfect for your LCD panel OR you can probably search the net for any working sync lengths for the 320x240 LCD. 

If you would see the prgb function in the davinci_platform.c, the HINT register is the cummulative values of HSPLS, HVALID, left margin, right margin -1. So keeping all values same, except Xres should also give you some image; but it might be shifted in the horizontal axis. Same for the vertical settings. You can work them out.

Regarding the first question, I am sorry that even I am a bit confused :(. I would say "Juan Help!!!"

Sundar

Elric said:

But in the VPBE document, it says "In this mode, the VENC clock must be divided-down 27 MHz via the VENC_DIV bit in the VPBE peripheral control register (PCR)." What is the meaning of this?

I believe this only will apply when you are trying to use a standard analog output using the VENC/DACs, since having an analog output standard like NTSC or PAL means you have to have a known clock value, namely the 27MHz.

Running the DCLK at 5.4 MHz seems a little slow, as it is mentioned in section 3.1.1.3 of SPRU952a that the clock should be between 6.25 and 75MHz, I am not saying that it cannot be made to work as I have not done much work with LCD displays, but the minimum frequency mentioned would make me uneasy.

Sundar and Bernie have done an excellent job of hitting most (if not all) your concerns; just to add my two cents

1) VPBECLK pin allows you to provide an optional external clock for the video back end.  We used this on the App Note you mentioned above, but is not necessary, especially if you are doing lower pixel clock outputs.

2) ENC Clock can come from VPBECLK or various other clock sources (using a mux selection register as Sundar suggested), hence theoretically they can be the same clock, but no not have to.

3) Pixel clock is an widely used industry term (and one I like to use when describing video), and it basically says how many pixels you are outputting (or inputting) per second.  As Sundar also pointed out, in situations when it takes two clock cycles to output one pixel, it is not necessarily to same as the video clock (VLCK pin).

4) As both Bernie and Sundar suggested, references to DACs and VENC_DIV only apply to analog outputs, as opposed to digital LCD outputs.

If you have any additional concerns, please feel free to make a post and we will be happy to help in any way we can.

-I am mistaken about VPBECLK. Since it is an external clock, we don't use it.

-I understand the ENC clock now. For our situation, ENC clock is the VPBE clock, muxel = 2h so it is 54Mhz.

-Here comes my question. As I mentioned before, we need a clock frequency of about between 5 and 6 Mhz. To provide this, we use DCLK.DCKOH = 1, which divides output DCLK by 2. This provides a 27Mhz clock. But there is also an internal DCLK output divide field, DCLK.DCKIH. What is the difference between internal DCLK and output DCLK? It is ok to try these pins to adjust a clock value that I want? (Of course to get a clock between 5 and 6 Mhz, we use DCLK pattern registers too, but after setting .DCKOH = 1).

Our first attempt to output to LCD was failure. After setting the VENC registers and enabling the clock, LCD lights open up, but the screen is empty. There is no output on the screen. We tried altering some of the register values, especially the LCD timing related ones. But there wasn't even a slightest change on the screen, we cant see any output, background is white and the lights are on.

Thank you for the answers.

Hi again,

Finally we are able to interface to LCD on DM6437. But we have a problem about the output.

I will explain it in steps:

-First of all, we are able to take analog input correctly with our current OSD module setting.

-Our LCD is 240*320. The image we use is also 240*320.

-When trying the LCD output, we set the window (we are only using video window 0 ) in non-interlaced mode and give the exact height of it to the VIDWIN0YL. There is no different OSD configuration other than this,  while interfacing to LCD.

-We see the exact image on the LCD screen. But the problem is, the image height is still 320 but the width is about a quarter of 240. Since we see the exact image on the screen, it seems somehow  scaled to 1/4 in width. The rest portion of the LCD screen is in it's default color: black.

-We tried a couple things; mostly playing with OSD registers but we couldn't take a result.

Do you have any idea where the problem may be?

Erman

when calculating the line buffer width, did you take into account that each pixel is 16-bits (two bytes); since default pixel format is YCbCr 16-bit, this is often overlooked.

Juan,

You are probably in the Christmas holiday, I am sorry to disturb you.

Is there anywhere I define the line buffer width? We are using parallel RGB mode (RGB666).

We made some progress but still it is not completely done. Maybe you could hit on the point:

We accomplished to use the full LCD screen. The source of the problem was that we didn't do any configuration to OSD clock registers. They were in their reset values -which probably they should not be-, we tried some values on them and it corrected the previous problem.

Now we can take the exact size output on the screen but it seems we have some data loss: some of the pixels are not correctly appearing. So, I think there is something wrong about the clocks.

The OSD clock related registers are OSDCLK0, OSDCLK1 and OSDHADV (horizontal sync advanced register). The LCD configuration in davincifb.c only configures OSDCLK1 (dispc_reg_out(VENC_OSDCLK1, 3);). But there is another function regarding digital output: enableDigitalOutput(), and this one configures them 0 1 0 relatively. (Although this function is only called in configuration for 720p and 1080i).

I don't know if I am suspecting the right place, but since our previous problem was on these registers, now I am suspecting a wrong configuration for these. Is there anything special about OSD clock registers that I should look to?

There are many registers regarding LCD interface and RBG mode. Most of them is not configured in the davinci.fb. Maybe our problem is on these; they are all in reset modes. This seems a little desperate.

Thank you again,

Erman

Erman,

I believe that you are getting some output on the LCD; but not the exact ones. Please confirm if otherwise. If this is the case, then I would suggest you to do some kind of tweaking with the BASEPX and the BASEPY registers.

Use cat /sys/class/davinci_system/system/vpbe_osd_basepx and /sys/class/davinci_system/system/vpbe_osd_basepy to get the values of the basepx and the basepy registers. Use echo "X" > /sys/class/davinci_system/system/vpbe_osd_basepx to write any new values to these. Being at command line interface, these things will be very fast and let us decide if we need to touch any other registers at all!

I already tried some tweakings on the BASEPX and BASEPY registers to take the output on the correct LCD screen size and base. I don't have any problem on this now. Our problem is that some pixels are not on the values they supposed to be. We are suspecting there is some wrong configuration for the OSDCLK registers, since we configured the LCD timing registers for the needs of the LCD.

I will try to give some info related to our LCD and problem:

-ENC clock is in 54Mhz. VCLK is configured in 5.4Mhz.

-In this case, as I said previously, we took an output which we see the exact image on the quarter potion of the LCD.

-Then we realized we didn't configure OSD clocks. Now we have done some configuration: OSDCLK0 = 0x00000009, OSDCLK1 = 0x00000001 and OSDHADV = 0x00000070. We are not sure how to configure the OSD clock registers and we gave these values random to see if it works. In this configuration, we took the output as the exact image size on the whole LCD, as it how it is supposed to be.

-But in this case, we have some loss data on the image. Some pixels (actually many pixels) are flashing in a purple color. To try to solve this, we increased HINT value. This solves the matter (we are not sure how) but now since the horizontal interval is increased, the frequency of VSYNC decreased from 60Hz to 45-48Hz.

That's the case. We are struggling but couldnt find any working solution yet. I will be appreciated for any advice.

Erman

Increasing the HINT value would relax the display timings a bit which makes it seem as if your flashing purple image corruption is rooted in some real time deadline being broken by your initial timings. You are already advancing the horizontal sync with OSDHADV, though it may be worth trying to increase this value, this is the only place I currently see that the OSD could get fixed based on changing the HINT value, the HINT being small along with a SDRAM bandwidth limitation could be causing corruption as discussed in section 4.5.3.1 of SPRU952 though I am not sure how this would manifest or if it is what you are seeing.

It may also be worth considering that this timing change with HINT would also effect how the LCD is receiving data, so we may not want to rule out the possibility that the relaxed timing is preventing the LCD from receiving erroneous data (i.e. some timing limitation within the LCD is fixed by HINT increasing).