LCD for OMAP

Annie,

there are quite a few parameters which need to be set to correspond to your LCD.

Horizontally you need to set the h-front, h-back, h-width and pixels per line

Vertically you need to set v-front, v-back, v-width and lines per frame.

The pixels per line also controls the external signal "ACBIAS" which is often also called DE. Some LCDs do not care about the h-sync and v-sync signals directly and are called "DE only" displays. The timings for H and V should still be set so that the total h and total v blanking times meet the the requirements of your LCD though.

Finally, the pixel clock rate needs to match your LCDs requirements.

All this information will be in the LCD data sheet in terms of pixel clocks, which is really what you need to ensure. From this the H & V frequencies will then end up being correct.

The simplest way to enable all 24 bits of the output is to use the current DVI configurations, which already do this. Basically, pretend you are using the DVI output and the output pins will be configured correctly.

Everything you need to change is already available in the current drivers, so you should not need to modify any drivers unless you want the LCD to be enabled during uboot.

Look at the following wiki pages for more information.

http://processors.wiki.ti.com/index.php/Display_Subsystem

http://processors.wiki.ti.com/index.php/Adding_new_DVI_resolutions

http://processors.wiki.ti.com/index.php/UserGuideDisplayDrivers_PSP_03.00.00.05

BR,

Steve

Annie,

You can use the sysfs interface to change your resolution at run time, for example to configure to 720P you can do:

# echo "72428,1280/190/120/32,720/13/3/5" > sys/devices/platform/omapdss/display2/timings

Here, the format is: <pixel_clock>,<xres/hfp/hbp/hsw>,<yres/vfp/vbp/vsw>

You can verify these timings by

# cat sys/devices/platform/omapdss/display2/timings

Regards,

Punya

----------------------------------------------------------------------------------------------------

Please click Verify Answer on this post of it answers your question.

----------------------------------------------------------------------------------------------------

Hi,

Thanks for both response. I was trying to add the LCD test to itbok and this new display requires SW send a sequence of command to the controller. So I modified the itbok code to add this test and I have modified the following registers,

DISPC_CONTROL: change to 24 bit data interface

DISPC_TIMING_H and DISPC_TIMING_V per the data sheet (for back porch etc)

DISPC_SIZE_LCD: for the new display size

DISPC_DIVISOR: for pixel clock. The logic clock divisor was 1 and pixel clock divisor was 3 for VGA and 13 for QVGA. I checked the Sharp data sheet, I think the VGA needs about 25M Hz pixel typical value, and 6.29 MHz pixel typical value, mine needs about 35 MHz pixel value, so I set the pixel clock divisor to 2 instead of 3.

Did I miss anything?  How about writing data to the display? In itbok example, the data was write to 0x80377000 - I assume this a memory for display, and they do 16 bit write for fill color - they are using RGB5:6:5, does this have anything to do with LCD data line width? I saw some post here mentioned, the display Subsystem will do automatic conversion if I input RGB16 to 24 bit data for LCD to display.

Sorry for some silly questions, I am new to OMAP and LCD display. Thanks for your help.

Annie

Annie, there are no silly questions, only silly answers :)

Basically, the pixel rate will be about width * height * frame-rate * 1.2. This is a good general rule of thumb.

Therefore VGA at 60fps will need a pixel rate of 640 * 480 * 60 * 1.2 = 22.1MHz. (Note, the 1.2 multiplier depends on the blanking times used, so can vary quite a bit, hence 25MHz is reasonable too)

Most LCDs can handle a fairly wide range of frequencies, which ultimately simply affects the frame rate.

I suggest that you have a look at the LCD signals on an oscilloscope to see if they are behaving how you think they need to, and make sure that they match the LCD data-sheet requirements.

For writing data to the display the frame buffer memory address can be anywhere in memory, and in the case of Linux when using V4L2 it can even move around all the time in order to support double buffering. Having said this, during ITBOK it is most likely fixed. There is a register that will tell you the frame buffer location. If you read the registers DISPC_GFX_BA0 and DISPC_GFX_BA1 they will contain the memory address of the graphics frame buffer.

The frame buffer and the LCD data width can be different, correct. The DSS will do the necessary conversion but you do need to set the DISPC_GFX_ATTRIBUTES and DISPC_CONTROL correctly for your configuration.

BR,

Steve

Hi, Steve,

Thanks for giving me a very informative response. It helped a lot, now I can put the pieces togather. You have been very helpful.

Best

Annie

Annie,

You are more than welcome. :)

BR,

Steve