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.
fbset output:
mode "640x512-60"
#
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:
But, If I modify the buffer using mmap, I get a strange behavior:
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.
Solved! Go to Solution.
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.
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.
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:
> it seems the memory is not organised like YUYV format.
in general GPU output can only be RGB format.
Best regards
igor
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