About 1080p with LCD output on MX6Q

[RobbieJiang]

I'm working with MX6Q Sabrelite board and the latest BSP Ltib3.0.25_4.1.0.

And I would like to have LCD output in 1080p ( i.e, 1920x1080) mode.

The MX6Q reference manual states that 1080p is supported by hardware.

However, with this BSP, I can have LCD output in 1024x768, but not in 1920x1080.

Seems that current BSP does not support 1080p LCD output.

Does Freescale has any plan to support LCD in 1080p?

Or anyone else has successful experience in driving LCD ouput in 1080p mode?

[fabio_estevam]

Robbie,

Could you try 3.10.17 kernel?

[RobbieJiang]

Fabio,

Do you mean the standard kernel 3.10.17 from kernel.org?

Or is it provided by Freescale with some special patches?

If so, could you please let me know the download link?

[fabio_estevam]

I mean the 3.10.17 GA kernel available at:

http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/log/?h=imx_3.10.17_1.0.0_ga

[fabio_estevam]

Or in your case, you could use Boundary's kernel that Eric has pointed out.

[dlschaeffer]

Was there any resolution to this issue? I'm having a similar issue with a ADV7513 at 1080p 60Hz but the clock looks fine at 720p 60Hz. Running on a custom board with the L3.10.17 kernel release.

[EricNelson]

Hi Fabio,

Since Robbie's running on a Nitrogen6x, he'll need the DTS files at least from our repository.

[fabio_estevam]

Yes, just added this comment, thanks :-)

[EricNelson]

The 'boundary-imx_3.10.17_1.0.0_ga' branch in our Github repository has support for Nitrogen6x:

     boundarydevices/linux-imx6 at boundary-imx_3.10.17_1.0.0_ga · GitHub

[EricNelson]

Hi Robbie,

The SABRE Lite certainly supports 1080P.

If you look in /sys, you can see the modes supported by the monitor:

     $ cat /sys/class/graphics/fb0/modes

and you can change the mode to 1080P by sending the mode to

the "mode" entry:

     $ echo V:1920x1080p-60 > /sys/class/graphics/fb0/mode

Note that this is from memory, so "V:1920x1080p-60" is likely wrong

and should be replaced with a line of output from "modes".

If you're running X and running with the latest updates, you can use

xrandr to set the mode:

     $ xrandr --fb 1920x1080

(Again, this is from memory. Please check the syntax with xrandr --help).

[RobbieJiang]

Hi Eric,

Are you sure?

I can have 1080p output with the HDMI port, but not the LCD display port.

And the lcdif_modedb[ ]  in drivers/video/mxc/mxc_lcdif.c contains only two modes,

there is no 1080p mode there.

And if I specify "video=mxcfb0:dev=lcd,1920x1080,if=RGB24,bpp=24" command line parameters in Uboot,

there is nothing displayed on my LCD monitor. However, if with 1024x768 resolution, everything is OK.

Of course, the 1024x768 mode was added to the lcdif_modedb[ ] array by me.

But even if the 1920x1080 mode was also added, it could not work.

[admin]

Hi Robbie,

You can add your 1080P mode by yourself. (in drivers/video/mxc/mxc_lcdif.c)

for example:

     static struct fb_videomode lcdif_modedb[] = {

       {

       /* 1080P 50Hz, pixel clk @ 120MHz*/

       "1080P", 50, 1080, 1920, 8333, 50, 100, 4, 4, 10, 2,

       FB_SYNC_CLK_LAT_FALL,

       FB_VMODE_NONINTERLACED,

       0,},

       {

       /* 800x480 @ 60 Hz , pixel clk @ 32MHz */

      "SEIKO-WVGA", 60, 800, 480, 29850, 89, 164, 23, 10, 10, 10,

       FB_SYNC_CLK_LAT_FALL,

       FB_VMODE_NONINTERLACED,

       0,},

     };

About command line, you can use "video=mxcfb0:dev=lcd,1080P,if=RGB24".

[RobbieJiang]

Hi liver,

When working with your 1080p@50Hz mode,

I still can not get output on my DVI display.

And the 'fbset' command gives the following outputs:

root@freescale ~$  fbset

mode "1920x1080-53"

    # D: 120.005 MHz, H: 57.695 kHz, V: 52.931 Hz

    geometry 1920 1080 1920 1080 24

    timings 8333 50 100 4 4 10 2

    rgba 8/16,8/8,8/0,0/0

endmode

In my understanding, the Vsync signal should be 50Hz,not 52.93Hz.

Note this frequency is the same as what we have measured with oscilloscope.

Is this correct?

Could you please show me your outputs of fbset with 1080p?

Thanks.

[qiang_li-mpu_se]

Hi Robbie, reference to CEA-861 specification, the 1080p timing parameters should be followed in mxc_lcdif.c, the HSYNC and VSYNC should be high active, and you don't need invert the pixel clock with "FB_SYNC_CLK_LAT_FALL":

{

/* 1920x1080p @ 60 Hz , pixel clk @ 148.5MHz */

"LCD-1080P60", 60, 1920, 1080, 6734, 148, 88, 36, 4, 44, 5,

FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT,

FB_VMODE_NONINTERLACED,

0,},

{

/* 1920x1080p @ 50 Hz , pixel clk @ 148.5MHz */

"LCD-1080P50", 50, 1920, 1080, 6734, 148, 528, 36, 4, 44, 5,

FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT,

FB_VMODE_NONINTERLACED,

0,},

By they way, you should not enable the HDMI display at the same time, both the LCDIF driver and HDMI driver will use PLL5 as the clock source.

[RobbieJiang]

Hi Qiang,

Thanks for your help.

However, this still does not solve my problem.

With your given LCD-1080P60, there is no any outputs on my DVI display.

And with LCD-1080P50, I can get outputs, but the quality is not good.

Perhaps this is because ADV7513 has its own timing requirements.

I'm still working on it.

[davecbluechip]

Just a note about the PLL settings - we originally had problems trying to use HDMI as well as LCD, which turned out to be the way the PLL is set. When HDMI was selected, it over-wrote the PLL configuration that had been set for the LCD. In the end we found a bug in the Freescale code that sets the PLL where the rounding of the divisor calculation was incorrect. There are two clock sources available, the local IPU clock, and PLL5. If the local IPU clock can't provide a frequency close enough to what was requested (about 0.5% tolerance), it uses PLL5 instead. The problem was the setting of the IPU clock was incorrect, and for certain requested frequencies the software did not produce a close frequency when the hardware was in fact capable of doing so. Therefore PLL5 was used all the time (for both displays), when it didn't need to be. Here is the patch we used to fix the problem (based on 3.0.35 4.0.0 release) -

------------------------- drivers/mxc/ipu3/ipu_disp.c -------------------------

@@ -85,20 +85,16 @@ static unsigned long _ipu_pixel_clk_round_rate(struct clk *clk, unsigned long ra

  */

  div = parent_rate;

  remainder = do_div(div, rate);

+

+ pr_debug("_ipu_pixel_clk_round_rate(%d) parent %lld, div %lld, remainder %d\n", rate, parent_rate, div, remainder);

+

  /* Round the divider value */

  if (remainder > (rate/2))

  div++;

+

  if (div < 0x10)            /* Min DI disp clock divider is 1 */

  div = 0x10;

- if (div & ~0xFEF)

- div &= 0xFF8;

- else {

- /* Round up divider if it gets us closer to desired pix clk */

- if ((div & 0xC) == 0xC) {

- div += 0x10;

- div &= ~0xF;

- }

- }

+

  final_rate = parent_rate;

  do_div(final_rate, div);

  return final_rate;

@@ -117,11 +113,8 @@ static int _ipu_pixel_clk_set_rate(struct clk *clk, unsigned long rate)

  if (remainder > (rate/2))

  div++;

- /* Round up divider if it gets us closer to desired pix clk */

- if ((div & 0xC) == 0xC) {

- div += 0x10;

- div &= ~0xF;

- }

+ if (div < 0x10)            /* Min DI disp clock divider is 1 */

+ div = 0x10;

  ipu_di_write(ipu, clk->id, (u32)div, DI_BS_CLKGEN0);

[qiang_li-mpu_se]

This is not an issue, for most of LCD display, there pixel clock has a range, so we can assign IPU 264MHz internal clock as the LCD pixel clock source in machine file, such as board-mx6q_sabresd.c, int_clk = true. But if the LCD interface output was connected to some video encoder chip, such as this adv7511, they need timing align with specification, so internal 264MHz clock source is not the better choise, it maybe can't divide correct pixel clock.

}, {

.disp_dev = "lcd",

.interface_pix_fmt = IPU_PIX_FMT_RGB565,

.mode_str = "CLAA-WVGA",

.default_bpp = 16,

.int_clk = true,

.late_init = false,

[RobbieJiang]

Hi Qiang,

Still back to this issue after 3 months.

Currently I'm working with Mx6q_sabrelite  and the latest BSP Ltib3.0.25_4.1.0.

And I would like to get 1280x1024@60Hz DVI output from ADV7513, which is connected to MX6Q LCD display port.

However, we can not get any output on our DVI display.

After checking the PIXCLK of the LCD port ( which is output by MX6Q processor ),

we found that the wave form of the PIXCLK signal is distorted ( As shown in enclose distored_pixclk.jpg).

Because of the incorrect wave form, adv7513 internal PLL circuit can not lock to this pix clock,

and naturally no output on the DVI display.

The fb_videomode for 1280x1024@60Hz in lcdif_modedb[], mxc_lcdif.c, is as follows：

{ "1280x1024@60", 60, 1280, 1024, 9259, 248, 48, 38, 1, 112, 3,
FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT,
FB_VMODE_NONINTERLACED, FB_MODE_IS_VESA,

}

However, if we change the LCD interface configuration to 1400x900@60Hz,

we can get a perfect PIXCLK output from MX6Q LCD interface.

The waveform of PIXCLK with 1400x900@60Hz can be found in attached perfect_pixclk.jpg.

And therefore everything goes well.

The fb_videomode for 1400x900@60Hz in lcdif_modedb[], mxc_lcdif.c  is as follows:

     {   "1400x900", 60, 1440, 900, 9389, 232, 80, 25,  3, 152, 6,
         0, FB_VMODE_NONINTERLACED, FB_MODE_IS_VESA,
    },

From the measured wave form, it seems that there is something wrong

with the pixclk generation for LCD interface in 1280x1024@60Hz mode.

Is this problem perhaps related to the issue mentioned by previous Davecbluechip's Post?

I mean, related to the system clock tree?

Any idea?

By the way, is there any Linux command to check the system clock tree?

Best regards,

Jie

[admin]

Hi Robbie,

Drive strength and slew rate may affect the PIXCLK wave form. Suitable configuration of PIXCLK drive strength and slew rate may solve the 1280x1024@60Hz mode distortion.

[qiang_li-mpu_se]

Hi Robbie, if you need support more resolution on LCD interface, you can't set ".int_clk = true," to use the 264MHz IPU internal clock to generate the pixel clock, this 264MHz frequency is fixed, so it can't generate all kinds of pixel clock frequency.

When ".int_clk =fase", then you need assign clock source for IPU DI, the code is in arch\arm\mach-mx6\clock.c, function mx6_clocks_init():

clk_set_parent(&ipu1_di_clk[0], &pll5_video_main_clk);

clk_set_parent(&ipu1_di_clk[1], &pll5_video_main_clk);

clk_set_parent(&ipu2_di_clk[0], &pll5_video_main_clk);

clk_set_parent(&ipu2_di_clk[1], &pll5_video_main_clk);

The above is the default setting, if you only use one display, that's no problem. But if you used more displays, you should set them to different clock source:

For example, on iMX6DQ, you can ue pll3_pfd_540M as another display's clock source:

clk_set_parent(&ipu1_di_clk[0], &pll3_pfd_540M);

clk_set_parent(&ipu1_di_clk[1], &pll5_video_main_clk);

[RobbieJiang]

Hi Qiang,

Thanks for your reply.

After checking the code,I'm sure ".int_clk = false" holds.

And now I have only ONE display device on the LCD interface, the HDMI and other LVDS display devices have been disabled.

From the measurement, we can see he PIXCLK wave form varies a lot with different resolution and timing configuration,

as you have seen from the attached files. Seems that PIXCLK signal with lower freq has better form.

My question is, with the same clock source, why is the wave form is much worse with 1280x1024@60Hz than 1400x900@60Hz?

By the way, after changing the SPPED field to 200Mhz and DSE field to 48Ohm,

we can get output on the LCD display, which is output by ADV7513 on MX6Q's LCD interface.

The default DSE is configured for 120Ohm. With these changes, ADV7513 internal PLL can lock the PIXCLK signal,

even the wave form is still not satisfied.

However, our customer has a special display device with strict timing requirement.

The same setting( 1280x1024@60H, which works on LCD display ),  still does not work on it,

I mean, there IS output on the device, but it looks bad.

I'm afraid this bad PIXCLK wave form is related to the incorrect timing on our customer's device.

Any idea?

Regards,

Jie