mx53 fb_videomodes for custom lcd

cancel
Showing results for 
Search instead for 
Did you mean: 

mx53 fb_videomodes for custom lcd

Jump to solution
6,153 Views
alexeym
Contributor III

Hello all,

I've got lcd to show me part of picture when set kernel parameters to use default XGA mode.

I need to use lcd display with custom mx53 based board, how to properly determine "struct fb_videomode" structure from attached clocks.

I've got them from my ldc datasheet, but don't get how to calculate them to fb_videomode values.

Some general description below:

G065VN01 V0 is a Color Active Matrix Liquid Crystal Display composed of a TFT LCD panel, a

driver circuit, and backlight system. The screen format is intended to support the VGA (640(H) x

480(V)) screen and 16.2M (RGB 8-bits) or 262k colors (RGB 6-bits). All input signals are LVDS

interface compatible. Inverter card of backlight is not included.

Labels (2)
1 Solution
959 Views
qiang_li-mpu_se
NXP Employee
NXP Employee

You can use the followed video mode:

1000000 / fb_videomode.pixclock = 1000000 / 40000 = 25MHz pixel clock.

fb_videomode.refresh = 60;

fb_videomode.xres = 640;

fb_videomode.yres = 480;

fb_videomode.left_margin + right_margin + hsync_len = 70 + 70 + 20 = 160 = HBlanking

fb_videomode.upper_margin + lower_margin + vsync_len = 20 + 20 + 5 = 45 = VBlanking

static struct fb_videomode video_modes[] = {

{

  /* 640x480 @ 60 Hz , pixel clk @ 25MHz */

  "G065V-VGA", 60, 640, 480, 40000, 70, 70, 20, 20, 20, 5,

  FB_SYNC_CLK_LAT_FALL,

  FB_VMODE_NONINTERLACED,

  0,},

};

And in kernel command lines, if you had connected 24 pin data lines in hardware: video=mxcdi0fb:RGB24,G065V-VGA,bpp=32;

If you had connected 18 pin data lines in hardware: video=mxcdi0fb:RGB666,G065V-VGA,bpp=32;

If you had connected 16 pin data lines in hardware: video=mxcdi0fb:RGB565,G065V-VGA,bpp=32;

View solution in original post

0 Kudos
13 Replies
959 Views
jaiprakash
Contributor I

Hi alexeym,

   let if you  find solution,  I am new to kernel level debugging. I bought a LCD from ortus tech of 3.5" with dimension 240x320 and want to make changes according to that in kernel file for mxc_lcdif.c in function static struct fb_videomode lcdif_modedb which have different fields i.e LCD timing related parameters. I want to set these fields but not able to understand from i have to find out their exact value. By goggling i found only theoretical values and didn't find any  thing sufficient to understand, where i have to look in to find correct values. If posssible reply  me soon.

Regards

Jai Prakash

jaiprakash28790@gmail.com

0 Kudos
960 Views
qiang_li-mpu_se
NXP Employee
NXP Employee

You can use the followed video mode:

1000000 / fb_videomode.pixclock = 1000000 / 40000 = 25MHz pixel clock.

fb_videomode.refresh = 60;

fb_videomode.xres = 640;

fb_videomode.yres = 480;

fb_videomode.left_margin + right_margin + hsync_len = 70 + 70 + 20 = 160 = HBlanking

fb_videomode.upper_margin + lower_margin + vsync_len = 20 + 20 + 5 = 45 = VBlanking

static struct fb_videomode video_modes[] = {

{

  /* 640x480 @ 60 Hz , pixel clk @ 25MHz */

  "G065V-VGA", 60, 640, 480, 40000, 70, 70, 20, 20, 20, 5,

  FB_SYNC_CLK_LAT_FALL,

  FB_VMODE_NONINTERLACED,

  0,},

};

And in kernel command lines, if you had connected 24 pin data lines in hardware: video=mxcdi0fb:RGB24,G065V-VGA,bpp=32;

If you had connected 18 pin data lines in hardware: video=mxcdi0fb:RGB666,G065V-VGA,bpp=32;

If you had connected 16 pin data lines in hardware: video=mxcdi0fb:RGB565,G065V-VGA,bpp=32;

View solution in original post

0 Kudos
959 Views
allonli
Contributor II

Hi, Qiang,

   follow this formula you give, the bt656if_modedb[] of bt656-ntsc, calculate the pixel clock should be 32484but actually the default setting is 37037

   could you please show how to get this data?

   thanks a lot.

0 Kudos
959 Views
qiang_li-mpu_se
NXP Employee
NXP Employee

Hi Allon LI ,

BT656 timing calculation method is different with this, it is special.

37037 means pixel clock = 1000000 / 37037 = 27MHz. This is same as standard timing.

But for BT656-NTSC, each frame's pixel clock = (720*2 + 276) * (480 + 19 + 3 + 20 + 3) = 1716 * 525. For NTFS, frame rate is 30fps, so pixel clock = 1716 * 525 * 30 = 27MHz.

They are same.

0 Kudos
959 Views
rajucm
Contributor III

Hi Qiang Li,

Along the same lines, I am connecting the lcd interface to RGB Analogue converter ADV7123. But I cant seem to find the parameters to fill for fb_videomode.

http://www.analog.com/en/products/digital-to-analog-converters/da-converters/adv7123.html

I am aiming for a 640x480 @ 60 Hz output.

Help would be greatly appreciated. Thank You.

Regards

Raju

0 Kudos
959 Views
rajucm
Contributor III

Hi Qiang Li,

I am using these figures below.

static struct fb_videomode lcdif_modedb[] = {

    {

    "ADV-WVGA", 60, 800, 480, 28800, 89, 164, 23, 10, 10, 10,

    FB_SYNC_CLK_LAT_FALL,

    FB_VMODE_NONINTERLACED,

    0,},

};

I get some output on the TV hooked up to the ADV7123 RGB out with the above values. Please help. Any changes in the values result in a blue screen. Please help. Many Thanks.

tvout.jpg

0 Kudos
959 Views
mbp
Contributor V

Qiang,

This is a great response - thank you.

However your response appears to conflict with this post:

Linux Framebuffer driver: Calculate Pixel Clock for struct fb_videomode -blog archive

Can you please clarify - what is the correct calculation?

Thanks again,

mike

0 Kudos
959 Views
qiang_li-mpu_se
NXP Employee
NXP Employee

They are same.

In driver code, the refresh rate will not be used, but to fill the video mode, you should use the refresh rate to calculate the pixel clock.

0 Kudos
959 Views
mbp
Contributor V

If these calculations are the same then,

#define PIXCLOCK (1e12/((XRES+LEFT_M+RIGHT_M+HSYNC_LEN)*(YRES+UPPER_M+LOWER_M+VSYNC_LEN)*REFRESH))

   applied to your parameters (60, 640, 480, 40000, 70, 70, 20, 20, 20, 5) =  1e12/(800*525*60) = 39682.54 or 39682

   and 1e12/39682 would yield a 25.2MHz clock.


Q1: Is the 40000 divisor you select for pix_clk less accurate than 39682?

Q2: How does the margins+sync play into pix_clock?

Q3: Should the margins be balanced (e.g. 70,70 and 20,20)?  does it matter?

Q4: Must the margins+sync = blanking_interval?

Q5: Many/most LCD's only spec one Blanking (e.g. 45), in these cases which blanking would this refer to and how does one determine the margins+sync if no blanking is provided?

Q5: How should the margin and sync be selected using your equation; margins+sync=blank?


Thanks for this clarification,

Mike


959 Views
qiang_li-mpu_se
NXP Employee
NXP Employee

All the video mode data should be comming from the LCD data sheet.

In driver, the divisor 40000 will be first used to set the pixel clock, it doesn't care other parameters, and if the IPU hardware can't get the correct target pixel clock, it will generate a close clock frequency.

Then the parameters "xres, yres, left_margin, right_margin, hsync_len, upper_margin, lower_margin, vsync_len" will be set into IPU hardware, all those parameters come from the LCD data sheet.

The the real LCD refresh is pixel clock / ((xres+left_margin+right_margin+hsync_len) * (yres+upper_margin+lower_margin+vsync_len)). The refresh rate 60 in video mode is not used.

In this customer's LCD datasheet, it only given total vertical blanking parameter 45, then it means the only requirement is "upper_margin+lower_margin+vsync_len = 45".

0 Kudos
959 Views
mbp
Contributor V

Got it! - Thanks for your clear and concise response!

0 Kudos
959 Views
jaiprakash
Contributor I

Hi Qiang Li,

                  I am new to kernel level debugging. I bought a LCD from ortus tech of 3.5" with dimension 240x320 and want to make changes according to that in kernel file for mxc_lcdif.c in function static struct fb_videomode lcdif_modedb which have different fields i.e LCD timing related parameters. I want to set these fields but not able to understand from i have to find out their exact value. By goggling i found only theoretical values and didn't find any  thing sufficient to understand, where i have to look in to find correct values. If posssible reply  me soon.

Regards

Jai Prakash

jaiprakash28790@gmail.com

0 Kudos
959 Views
alexeym
Contributor III

Thank you.

0 Kudos