YUYV 16bits LCD configuration and data organisation

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

YUYV 16bits LCD configuration and data organisation

Jump to solution
1,317 Views
pierre-olivierh
Contributor III

Hello,

We will use the LCD output of the iMX6 for one of our project, but I think something is missing for my LCD configuration.

We plan to use the LCD output, in YUYV format (packed, 16bits), with HSYNC, VSYNC, DE, CLK. The LCD data will be read by a FPGA (not a real screen), and we have flexibility on the parameters. DISP0_DAT0-15 are used (0-7 for Y, 8-15 for UV)

I have added a new screen in the mxc_lcdif.c file:

{
/* 640x512 @ 60 Hz , pixel clk @ 27MHz */
/* name, rfresh, xres, yres, pixclk in ps, left, right, top, bot, hsynclen, vsynclen */
"640X512P", 60, 640, 512, 37037, 30, 30, 20, 20, 50, 48,
/* clock per row (cpr): xres + left + right + hsync = 640 + 30 + 30 + 50 = 750 */
/* total lines : lines + top + bottom + vsync = 512 + 20 + 20 + 48 = 600 */
/* clock per frame: cpf = cpr * total lines: 450000 */
/* max fps: clk/cpf = 27000000/450000 = 60 Hz */

FB_SYNC_CLK_LAT_FALL,
FB_VMODE_NONINTERLACED,
0,}

I have also added the support in the DTB:

mxcfb1: fb@0 {
compatible = "fsl,mxc_sdc_fb";
disp_dev = "lcd";
interface_pix_fmt = "YUYV16";
mode_str ="640X512P";
default_bpp = <16>;
int_clk = <0>;
late_init = <0>;
status = "okay";
};

...

lcd@0 {
compatible = "fsl,lcd";
ipu_id = <0>;
disp_id = <0>;
default_ifmt = "YUYV16";
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_ipu1>;
status = "okay";
};

pinctrl_ipu1: ipu1grp {
fsl,pins = <
MX6QDL_PAD_DI0_DISP_CLK__IPU1_DI0_DISP_CLK PAD_CTRL_DISP_STD /* 0xa1 */
MX6QDL_PAD_DI0_PIN15__IPU1_DI0_PIN15 PAD_CTRL_DISP_STD /* DRDY */
MX6QDL_PAD_DI0_PIN2__IPU1_DI0_PIN02 PAD_CTRL_DISP_STD /* HSYNC */
MX6QDL_PAD_DI0_PIN3__IPU1_DI0_PIN03 PAD_CTRL_DISP_STD /* VSYNC */
MX6QDL_PAD_DI0_PIN4__IPU1_DI0_PIN04 0x80000000
MX6QDL_PAD_DISP0_DAT0__IPU1_DISP0_DATA00 PAD_CTRL_DISP_STD
...
MX6QDL_PAD_DISP0_DAT15__IPU1_DISP0_DATA15 PAD_CTRL_DISP_STD
>;
};

Video args from uboot are also updated:

video=mxcfb0:dev=lcd,640X512P,if=YUYV,bpp=16 ;video=mxcfb1:off fbmem=32M

Using an oscilloscope, the PIXCLK, HSYNC, VSYNC are correct. The frequencies are good, and the VSYNC is 60Hz as expected.

I tried to set some pixel values while monitoring DAT0 and DAT8 on an oscilloscope.

  • cat /dev/random > /dev/fb0  -> Random Values seen on DAT0/DAT8
  • cat /dev/zero > /dev/fb0  -> DAT0/DAT8 at 0V (as expected).

fbset output:

mode "640x512-60"
# 27.000 MHz, H: 36.000 kHz, V: 60.000 Hz
geometry 640 512 640 512 16
timings 37037 30 30 20 20 50 48
accel false
rgba 5/11,6/5,5/0,0/0
endmode

With a small piece of software (attached), I can get infos on the fb device:

  • smem_len: 655360 (as expected, 640*512*2)
  • line_lenght: 1280 (as expected, 640*2)
  • xres: 640 (as expected)
  • yres: 512 (as expected)
  • bpp: 16 (as expected)

But, If I modify the buffer using mmap, I get a strange behavior:

  • Setting all the buffer to 0, DAT0 and DAT8 are 0V (as expected)
  • Setting the first data to 0x1, DAT0 and DAT8 are '1' for one pixel clock every 16.6ms (60Hz)
    • I understand why DAT0 is at '1', but DAT8 should stay at '0'
  • Setting the second data to 0x1, DAT0 and DAT8 are '1' for one pixel clock every 16.6ms (60Hz)
    I understand why DAT8 is at '1', but DAT1 should stay at '0'

In my mind, the memory is organised in YUYV format, packed, so 1st byte is Y, 2nd byte is U, third byte is Y...

Did I do something wrong? it seems the memory is not organised like YUYV format.

Labels (4)
0 Kudos
Reply
1 Solution
1,268 Views
pierre-olivierh
Contributor III

I finally found the issue.

I applied the patch for BT656 but I don't use it at the end.

The "fbpix" was not set in the kernel command line. It defaults to RGB565. Th IPU converted the input framebuffer values from RGB565 to YUYV16, that's why the values changed.

I set the "if" and "fbpix" to the same format now, and the framebuffer values match the output values on the DAT pins.

View solution in original post

0 Kudos
Reply
3 Replies
1,269 Views
pierre-olivierh
Contributor III

I finally found the issue.

I applied the patch for BT656 but I don't use it at the end.

The "fbpix" was not set in the kernel command line. It defaults to RGB565. Th IPU converted the input framebuffer values from RGB565 to YUYV16, that's why the values changed.

I set the "if" and "fbpix" to the same format now, and the framebuffer values match the output values on the DAT pins.

0 Kudos
Reply
1,311 Views
igorpadykov
NXP Employee
NXP Employee

Hi Pierre-Olivier

 

for this case one can consider sect.4.12.10.4 IPU Display Interface Signal Mapping

i.MX 6Dual/6Quad Applications Processors for Consumer Products - Data Sheet

from software side I am afraid LCD output in YUYV format is not supported in BSPs, probably may help below:

https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/Patch-to-Support-BT656-and-BT1120-Output...

 

> it seems the memory is not organised like YUYV format.

 

in general GPU output can only be RGB format.

 

Best regards
igor

1,297 Views
pierre-olivierh
Contributor III

Hi igor,

Thank you for the fast reply.

I thought the BSP support the YUV format as the mxc_ipuv3_fb.c file mention "YUYV16" format (equals to IPU_PIX_FMT_YUYV).

I will try to apply the patches.

Best regards,
Pierre-Olivier

0 Kudos
Reply