i.MX6Q LVDS Timing issue

[sanjeevsharma]

Hi all,

I have a custom iMX6q derived from nitrogen6x Board and I wanted to use a LVDS display 1280*800 with clock frequency minimum 60 and Maximum 80 MHZ.

The display has been configured for the 71 MHZ and below is the content of dts i have been using for the custom board.

Kernel is built using boundary-imx_3.14.28_1.0.0_ga branch from here https://github.com/boundarydevices/linux-imx6/commits/boundary-imx_3.14.28_1.0.0_ga and ldb driver successfully loaded. I could see that fb0 and fb1 device is created in /dev/directory.

To verify the Frame-buffer functionality I have used fb-test app which successfully fill frame-buffer with color to the screen.Attached FullSizeRender1.jpg is the one which shows that green color has been filled in framebuffer but When I tried to send random data to /dev/fb0 (dd if=/dev/urandom of=/dev/fb0) I could see horizontal lines FullSizeRender.jpg which is not the expected output.

Header 1
fb_lvds: fb@1 {         compatible = "fsl,mxc_sdc_fb";         disp_dev = "ldb";         interface_pix_fmt = "RGB24";         default_bpp = <24>;         int_clk = <0>;         late_init = <0>;         status = "disabled";     }; &ldb {     status = "okay";     lvds_channel0: lvds-channel@0 {         crtc = "ipu1-di1";         fsl,data-mapping = "spwg";         fsl,data-width = <24>;         status = "okay";         primary;         display-timings { kyoceratcg121wxlpx: kyoceratcg121wxlpx {                 clock-frequency = <71000000>;                 hactive = <1280>;                 vactive = <800>;                 hback-porch = <48>;                 hfront-porch = <80>;                 vback-porch = <15>;                 vfront-porch = <2>;                 hsync-len = <32>;                 vsync-len = <6>; }

In addition to that,I could see some strange kernel message appearing while booting in the area around ldb clk parent which can't be ignored while investigating the problem.

imx-ipuv3 2400000.ipu: IPU DMFC NORMAL mode: 1(0~1), 5B(4,5), 5F(6,7)

imx-ipuv3 2800000.ipu: IPU DMFC NORMAL mode: 1(0~1), 5B(4,5), 5F(6,7)

imx-ipuv3 2400000.ipu: use special clk parent

imx-ipuv3 2400000.ipu: disp=1, pixel_clk=71103000 71458646 parent=71458646 div=1

imx-ipuv3 2400000.ipu: IPU DMFC DP HIGH RESOLUTION: 1(0,1), 5B(2~5), 5F(6,7)

imx-ipuv3 2400000.ipu: IPU Warning - IPU_INT_STAT_10 = 0x00100000

imx-ipuv3 2400000.ipu: IPU Warning - IPU_INT_STAT_10 = 0x00100000

imx-ipuv3 2400000.ipu: use special clk parent

imx-ipuv3 2400000.ipu: disp=1, pixel_clk=71103000 71458646 parent=71458646 div=1

I would really appreciate if someone look into this issue and help me out what could be the potential reason for this cause.

Regards

Sanju

[sanjeevsharma]

we have further investigated the issue and here is our finding.

The behavior of the data enable (DE) signal within the display signals is wrong. It has to be high during data transmission of a line of pixels, then low for a short period of time and the high for the next line of pixels. Current signal is high until all lines of pixels are transmitted, then low for a short time (see picture attached; line drawn with pencil is our measurement).looks like this is an clock issue.

Is anybody also facing the same issue in Linux kernel 3.14.28 from boundary device.

[CarlosCasillas]

Hello Sanju,

Have you checked on boundary devices forums? Since the nitrogen6x board is manufactured by them it will be easier to get the support from their sites:

http://boundarydevices.com/blog/

Also, let me mention Boundary Devices to see if someone from their team is familiar with your issue.

Hope this will be useful for you.

Best regards!

/Carlos

[sanjeevsharma · Accepted solution]

Thanks Carlos.

Problem has been fixed.Unfortunately issue was inside some commit of boundary device linux kernel specially in code of Display controller of IPU.

I have started debugging the problem by tracing the DE signal. I know that DE signal is controlled by the Display Controller in the IPU, So I have started looking into ipu_init_sync_panel() in drivers/mxc/ipu3/ipu-disp.c and during debugging it has been identified that issue is because of latest change checked-in in ipu display controller,
https://github.com/boundarydevices/linux-imx6/commits/boundary-imx_3.14.28_1.0.0_ga/drivers/mxc/ipu3...
I have further narrow down the problem and issue found in 2 commits though ipu_disp: dynamically allocate mappings looks ok.

ipu_disp: reorder microcode to separate di0/di1

ipu_disp: remove duplicate code  

Along with this,below code shouldn't be removed from the tree which is responsible for show last horizontal line pixel observed.

            _ipu_dc_write_tmpl(ipu, 4, WRG, 0, map, NULL_WAVE, 0, DI_SYNC_CLK, 1, 0, 0);

Troy already confirmed that,he has already fixed and re-based the code.