720p@60Hz

All,

  in case you want to drive HTDVs with exactly 60Hz you can adjust the
invisible timing parameters. Depending on what kernel you work on you
need one of the following changes- see below.

For higher pixel clocks and resolutions (e.g. 1360x768 @ 60 Hz ->
84MHz pixelclock) the DSS clock can be derived from DSI PLL. I am
interested whether somebody has looked into this scheme yet.

- Thomas

Kernel modifications

Depending on the kernel version that is being used the modification
needed do be done in different files and ways.

Modifications kernel 2.6.22.18

This kernel version is current version that is available from the
beagle source site located at code.google.com. (kernel-2.6.22.18)
The file that needs to be modified is located in the directory
$KERNEL_SOURCE/arch/arm/plat-omap and is called display.c. Currently
the values of the resolution and the display timings are hard coded in
this file. There are two functions in which changes are to be made to
get a specific resolution at a wanted refresh rate. The first one is
called omap2_disp_set_panel_size. As the name implies this function
sets the display resolution. Almost at the end of the function the
function call

dispc_reg_out(DISPC_SIZE_LCD, 0x02cf04ff);

writes the display size into the corresponding register. The first
four hex digits describe the y resolution and the second group of four
digits defines the x resolution. In the example above the display
subsystem is configured to ouput an resolution of 720p (1280x720).
After this is done it is necessary to adjust the display timing
parameters. Namely horizontal back, front porch and horizontal sync
puls length. These parameters also exist in a vertical version. Each
of them is specified in pixelclock granularity. Since it is quite
complicated to change the pixel clock in this kernel version the
approach was to change the previous mentioned timing parameters to
achieve a refresh rate of 60Hz.
The function that is setting the display timing parameters is named
omap2_disp_config_lcd. The following two function calls are setting
the timing parameters.

dispc_reg_out(DISPC_TIMING_H, 0x0cf03f31);
dispc_reg_out(DISPC_TIMING_V, 0x01400504);

The DISPC_TIMING_H define is addressing the register for horizontal
timing.

Modifications kernel 2.6.26 OE

There is also a kernel that is available through the OpenEmbedded
build system. Basically this is the kernel from the monta vista git
tree. During the build process a lot a different patches are applied.
The adjustments to get a frame rate of 60 Hz have to be done in the
file $KERNEL_DIR/drivers/video/omap/lcd_omap3beagle.c. Locate the
following structure and make the small changes as follows:

.x_res = 1280,
.y_res = 720,
.hfp = 120,
.hsw = 32,
.hbp = 190,
.vfp = 3,
.vsw = 5,
.vbp = 13,
.pixel_clock = 72500

Note:
For this kernel you need at least the version 1.4.x of the uboot
otherwise you will get many messages about an unhandled IRQ -33. A
working uboot version can be obtained from http://git.mansr.com are as
precompiled version from here:

Modifications kernel 2.6.27 mansr

I am mentioning this kernel tree because it includes a lot of patches
concerning the display subsystem and the clock managment. It is
available via a git repository from http://git.mansr.com. Additionally
this patched kernel provides the possibility to specify which display
timing parameters should be used for the framebuffer.
The changes are in the file $KERNEL_DIR/drivers/video/omap/
omapfb_main.c, there you will find structures like
the one described in the previous section extend by a name entry. So
you can now define different modes which can be specified using boot
arguments.
An example boot command line could look like this.

bootargs = 'root=/dev/mmcblk0p2 noinitrd video=omapfb:mode:
1280x720@60'

The last argument implies that the name of the mode specified in the
structure in $KERNEL_DIR/drivers/video/omap/omapfb_main.c is

...
.name = 1280x720@60,
...

Note:
For this kernel you need at least the version 1.4.x of the uboot
otherwise you will get many messages about an unhandled IRQ -33. A
working uboot version can be obtained from http://git.mansr.com are as
precompiled version from here:

KDrive modifications

The kdrive is a lightweight version of the xserver. The source code
can either be obtain via the OpenEmbedded or via xorg. Because it is
also an integrated part of the xorg server. In the xorg tree the
kdrive source code can be found in the directory $XORG_DIR/hw/kdrive.
Assuming the kdrive is available to be compiled you will find a file
called kmode.c in the directory $KDRIVE_DIR/src. In there exists a
static array that contains all the display modes that are available.
Since the mode 1280x720@60 was not available it needed to be added.

...
},
{
    1280 , 720, 60 /*vertical refresh rate*/, 45000,
               63 /*HFP*/, 463 /*HBP*/, 575 /*Horizontal BLANK*/,
KdSyncPositive,
                5,/*VFP*/, 20 /*VBP*/, 29 /* Vertical BLANK*/ ,
KdSyncPositive,
},
...

HFP stands for horizontal front porch, HBP for horizontal back porch.
The BLANK is computed from the sum
of front porch, back porch and the length of the sync pulse.

Hi Thomas,
            Have you tried running OMAP3 at 74.25MHZ pixel clock
( this is required for 720p 60HZ display). The OMAP3 datasheet says
that it can have programmable pixel rate up to 65 MHz. Is this the
limitation of the DSS module or the limitation of the clock source ?

Regards,
Shaan

shaan wrote:

Hi Thomas,
            Have you tried running OMAP3 at 74.25MHZ pixel clock
( this is required for 720p 60HZ display). The OMAP3 datasheet says
that it can have programmable pixel rate up to 65 MHz. Is this the
limitation of the DSS module or the limitation of the clock source ?

Good question! It seems to me that community is actually quite
confused regarding possible pixel clocks. Additionally, with git
kernel we are currently limited to 72MHz pixel clock. With this we are
not able to configure 1280 x 1024 >= 50Hz refresh.

I already asked similiar question in

http://groups.google.com/group/beagleboard/browse_thread/thread/2c9e084418ff2d5c#

Anybody can clarify this? And if pixel rate can be xx MHz (with xx >
72MHz), some hints how to change/fix this in OMAP git driver?

Thanks

Dirk

Dirk Behme said the following on 09/01/2008 10:49 AM:

Anybody can clarify this? And if pixel rate can be xx MHz (with xx >
72MHz), some hints how to change/fix this in OMAP git driver?
  
Yes. you can get pix clk of 74.25Mhz by using DSI PLL instead of the
normal DSS clk. how to fix this in git tree is something I cannot comment.
Quote from Public TRM (rev G):
5.4.4.1 DSI PLL Controller Overview
      The DSI PLL controller module forms part of the display
sub-system. Nevertheless, it uses the SCP (Serial
      Configuration Port) and PMP (Power Management Port) ports as the
primary interfaces to the DSI
      protocol engine. The SCP interface is used to set the
configuration of the DPLL and HSDIVIDER modules,
      primarily the various counter values. The PMP port is used to
control the power state of the DPLL and
      HSDIVIDER modules. Figure 15-102 provides an overview of the DSI
PLL controller module inside the
      display subsystem.

        The DSI PLL is also used to generate the 74.25-MHz frequency
used for HDTV applications.

Regards,
Nishanth Menon

Nishanth Menon wrote:

Dirk Behme said the following on 09/01/2008 10:49 AM:

Anybody can clarify this? And if pixel rate can be xx MHz (with xx >
72MHz), some hints how to change/fix this in OMAP git driver?

Yes. you can get pix clk of 74.25Mhz by using DSI PLL instead of the
normal DSS clk. how to fix this in git tree is something I cannot comment.

Something tells me this should be my next mini-project...