IMX8mp display shifting

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

IMX8mp display shifting

Jump to solution
103,872 Views
ZhouLiang1
Contributor III

Hi, experts

We have encounter a display shifting issue when test our board, the screen resolution is 1920x1080, it sometimes has a large offset in the x direction.

ZhouLiang1_0-1706258278241.png

 

The origin image is as follows:

origin imageorigin image

 

It is worth noting that the screen does not shift every time when I boot the system. The probability of the screen shifting is about 1/15. The offset of the image on the screen in the x direction is the same every time.

 

The display related device tree nodes are as following:

```

lcdif1: display-controller@32e80000 {
                compatible = "fsl,imx8mp-lcdif";
                reg = <0x32e80000 0x10000>;
                clocks = <&clk IMX8MP_CLK_MEDIA_DISP1_PIX_ROOT>,
                     <&clk IMX8MP_CLK_MEDIA_APB_ROOT>,
                     <&clk IMX8MP_CLK_MEDIA_AXI_ROOT>;
                clock-names = "pix", "axi", "disp_axi";
                interrupts = <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>;
                power-domains = <&media_blk_ctrl IMX8MP_MEDIABLK_PD_LCDIF_1>;
                status = "disabled";

                port {
                    lcdif1_to_dsim: endpoint {
                        remote-endpoint = <&dsim_from_lcdif1>;
                    };
                };
            };
 
mipi_dsi: dsi@32e60000 {
                compatible = "fsl,imx8mp-mipi-dsim";
                reg = <0x32e60000 0x400>;
                clocks = <&clk IMX8MP_CLK_MEDIA_APB_ROOT>,
                     <&clk IMX8MP_CLK_MEDIA_MIPI_PHY1_REF>;
                clock-names = "bus_clk", "sclk_mipi";
                assigned-clocks = <&clk IMX8MP_CLK_MEDIA_APB>,
                          <&clk IMX8MP_CLK_MEDIA_MIPI_PHY1_REF>;
                assigned-clock-parents = <&clk IMX8MP_SYS_PLL1_800M>,
                             <&clk IMX8MP_CLK_24M>;
                assigned-clock-rates = <200000000>, <24000000>;
                samsung,pll-clock-frequency = <24000000>;
                interrupts = <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH>;
                power-domains = <&media_blk_ctrl IMX8MP_MEDIABLK_PD_MIPI_DSI_1>;
                status = "disabled";

                ports {
                    #address-cells = <1>;
                    #size-cells = <0>;

                    port@0 {
                        reg = <0>;

                        dsim_from_lcdif1: endpoint {
                            remote-endpoint = <&lcdif1_to_dsim>;
                        };
                    };
                };
            };
 
&lcdif1 {
    status = "okay";

    assigned-clocks = <&clk IMX8MP_VIDEO_PLL1_OUT>,
                      <&clk IMX8MP_CLK_MEDIA_DISP1_PIX>,
                      <&clk IMX8MP_CLK_MEDIA_AXI>;
    assigned-clock-parents = <0>,
                             <&clk IMX8MP_VIDEO_PLL1_OUT>,
                             <&clk IMX8MP_SYS_PLL2_1000M>;
    assigned-clock-rates = <1039500000>,
                           <148500000>,
                           <500000000>;
};

&mipi_dsi {
    status = "okay";

    assigned-clocks = <&clk IMX8MP_CLK_MEDIA_APB>,
                      <&clk IMX8MP_CLK_MEDIA_MIPI_PHY1_REF>;
    assigned-clock-parents = <&clk IMX8MP_SYS_PLL1_800M>,
                             <&clk IMX8MP_CLK_24M>;
    assigned-clock-rates = <200000000>, <12000000>;

    samsung,pll-clock-frequency   =  <12000000>;
    samsung,burst-clock-frequency = <924000000>;
    samsung,esc-clock-frequency   =  <16000000>;

    ports {
        port@1 {
            reg = <1>;

            dsim_to_sn65dsi84: endpoint {
                remote-endpoint = <&sn65dsi84_from_dsim>;
            };
        };
    };
};
```
 

I have dump the registers of the LCDIF and MIPI DSI when the screen is shift, the values are as following:

32e80000: 00000000 ....
32e80004: 00000000 ....
32e80008: 00000000 ....
32e80010: 80000000 ....
32e80014: 04380780 ..8.
32e80018: 005a005a Z.Z.
32e8001c: 000a000a ....
32e80020: 000a001e ....
32e80024: 00010005 ....
32e80028: 00000000 ....
32e80030: 00000001 ....
32e80034: 00000001 ....
32e80200: 04380780 ..8.
32e80208: 00221e00 ..".
32e8020c: b5e00000 ....
32e80210: 00000000 ....
32e80214: 89000000 ....
32e60004: 80100400 ....
32e60008: 00000002 ....
32e6000c: 00000000 ....
32e60010: 91f80008 ....
32e60014: 00ffffff ....
32e60018: 3670707f .pp6
32e6001c: 01e00000 ....
32e60020: 84380780 ..8.
32e60024: f00a000a ....
32e60028: 00440044 D.D.
32e6002c: 02800013 ....
32e60030: 03000400 ....
32e60034: 01000000 ....
32e60038: 8b337fff ..3.
32e6003c: 00000000 ....
32e60040: 00000000 ....
32e60044: ff7fb5aa ....
32e60048: 000001ff ....
32e6004c: 0155541f .TU.
32e60050: 00004040 @@..
32e60078: 00010002 ....
32e60090: 00000000 ....
32e60094: 008049a2 .I..
32e60098: 00000000 ....
32e6009c: 00000000 ....
32e600a0: 000001f4 ....
32e600a4: 00000000 ....
32e600a8: 00000000 ....
32e600ac: 00000000 ....
32e600b0: 00000000 ....
32e600b4: 0000060c ....
32e600b8: 041e0d07 ....
32e600bc: 00050d09 ....

Could you help me see what's wrong on my platform? Thank you very much!

 

Snow

Best regards

 

 

0 Kudos
Reply
1 Solution
103,575 Views
ZhouLiang1
Contributor III

Hi Zhiming_Liu

After deeply investigate,  we found this issue indeed a bug in the mainline linux, and it has been fixed in linux-6.8, after apply that commit, this issue doesn't occurs after 200 times reboot.

 

Thank you for your help!

Zhou Liang

Best Regards

 

View solution in original post

0 Kudos
Reply
15 Replies
103,814 Views
Zhiming_Liu
NXP TechSupport
NXP TechSupport

Hi @ZhouLiang1 

Which display framework you are using? QT or other? or based on wayland?

0 Kudos
Reply
103,809 Views
ZhouLiang1
Contributor III

Hi, Zhiming_Liu

Thank you for your help.

We are using `weston`  to test the display, only show a background.  I previously saved the drm buffer created by weston as a png image when the background image has a big offset, and found that the saved image was correct. so I think this is a driver related issue.

When the display shifting issue occurs, I restart the weston service, but the shift is always exist, but if I force off and on the card by the following command:

```

echo off > /sys/class/drm/card2-LVDS-1/status

echo on > /sys/class/drm/card2-LVDS-1/status

```

After these operations, the background on the screen displays normally.

 

Zhou Liang

Best regards

0 Kudos
Reply
103,796 Views
Zhiming_Liu
NXP TechSupport
NXP TechSupport

Hi @ZhouLiang1 

What's the resolution of your original picture?

What's the resolution og the picture you dump from weston?

I think this should be weston issue, because the hardware is very simple. It receives display buffer(like 720p size) from userpace allocated. But if userspace give it bigger buffer size, like more that 800p. Maybe will exist such display issue.

 

You can try to resize original image size same as your panel size. And test again.

 

Best Regards

Zhiming

0 Kudos
Reply
103,791 Views
ZhouLiang1
Contributor III

Hi Zhiming

 

I have used the image with the pixel of 1920x1080 to test the display, it still have the shifting issue,  please see the attachments. One is the origin image, the other one display with x offset.

I also check the log of weston, the display mode is correct, the size of the frame-buffer also correct(1920x1080x4 = 8294400)

```

drm_output_init_pixman enter w= 1920, h = 1080..
1970-01-01T00:00:06.639231+00:00 valuemon64 weston[626]: [00:00:06.564] drm_fb_create_dumb 1920, 1080
1970-01-01T00:00:06.639330+00:00 valuemon64 weston[626]: [00:00:06.568] xxxx drm_fb_create_dumb: create_arg.size = 8294400, map_arg.offset = 8294400
1970-01-01T00:00:06.639424+00:00 valuemon64 weston[626]: [00:00:06.568] drm_fb_create_dumb 1920, 1080
1970-01-01T00:00:06.639519+00:00 valuemon64 weston[626]: [00:00:06.571] xxxx drm_fb_create_dumb: create_arg.size = 8294400, map_arg.offset = 16588800

```

Is this problem related to frequency configuration?

BTW, I just found the  value of Master PLL PMS Value setting Register (MIPI_M_PLLPMS) is 0x00000000

32ec000c: 00000000

Could this be the cause of the problem?

 

Thanks

 

Zhou Liang

Best Regards

0 Kudos
Reply
103,755 Views
Zhiming_Liu
NXP TechSupport
NXP TechSupport

Hi @ZhouLiang1 

How do you test this background display function?? with weston api? Can you share the test steps?

0 Kudos
Reply
103,752 Views
ZhouLiang1
Contributor III

Hi Zhiming_Liu

I test the display using the following steps:

step1:  Config the weston.ini

```

[core]
modules=systemd-notify.so
idle-time=0
shell=desktop-shell.so
pageflip-timeout=1000
pixman-shadow=false

[shell]
locking=false
panel-position=none
startup-animation=none
allow-zap=true
binding-modifier=super
background-image=/usr/share/helix-session/sun/splash.png
background-type=scale-crop

[keyboard]
keymap_layout=gb
vt-switching=false

[output]
name=LVDS-1

```

The background-image field configures the background image path.

Step2: Keep restarting the system to see if there is a display shifting problem. Currently, it may occur once about 20 restarts.

 

The weston is installed as a service in our system, when system starting, the weston will load the drm device and draw the background on the screen.

 

Zhou Liang

Best Regards

 

 

0 Kudos
Reply
103,740 Views
Zhiming_Liu
NXP TechSupport
NXP TechSupport

Hi @ZhouLiang1 

 

I have tested it on EVK board with MIPI-HDMI bridge.

There is no such issue after testing ~40 reboot on Linux 5.15.y and Linux 6.1.y on i.MX8MPlus EVK.

You can test MIPI panel(without sn65dsi84) if you have MIPI panel and other display interface.

 

Best Regards

Zhiming

 

0 Kudos
Reply
103,746 Views
Zhiming_Liu
NXP TechSupport
NXP TechSupport

Hi @ZhouLiang1 

Which BSP you are using?

Can you test other interface like HDMI?

0 Kudos
Reply
103,697 Views
ZhouLiang1
Contributor III

Hi Zhiming_Liu

Thank you for your support. We use Linux 6.5 to test our board. Currently the HDMI on our board isn't work, so I can test this issue by using the HDMI.

I did a test on my board yesterday, when the display issue occurs, I'm enable the TEST_PATTERN function of SN65DSI84, in this mode, the SN65DSI84 bridge will use the clock generated by DSI, but use the data generated by itself,  and the output seems doesn't have x offset, you can check the attachment.

 
 

So I think the issue doesn't caused by the SN65DSI84.

0 Kudos
Reply
103,669 Views
Zhiming_Liu
NXP TechSupport
NXP TechSupport

Hi @ZhouLiang1 

1. NXP maintain Linux6.1.y and Linux6.6.y, we never maintain Linux6.5.y, i think you are totally using MAINLINE kernel, because in our  dtsi, the lcdif is using such compatible name  "fsl,imx8mp-lcdif1", not "fsl,imx8mp-lcdif".. ONLY mainline kernel use one lcdif instance. Mainline kernel  is not maintained by NXP, also the display framework.

 

2. MIPI DSI driver:drivers/gpu/drm/imx/sec_mipi_dsim-imx.c

LCDIF driver :drivers/gpu/imx/lcdifv3/lcdifv3-common.c

 

3. You should use Linux from NXP.

https://github.com/nxp-imx/linux-imx

4. We only support  Linux from NXP.

0 Kudos
Reply
103,576 Views
ZhouLiang1
Contributor III

Hi Zhiming_Liu

After deeply investigate,  we found this issue indeed a bug in the mainline linux, and it has been fixed in linux-6.8, after apply that commit, this issue doesn't occurs after 200 times reboot.

 

Thank you for your help!

Zhou Liang

Best Regards

 

0 Kudos
Reply
102,237 Views
vinayak1710
Contributor I

Hi,

Could you please share the commit id or patch (changes) or where the fix was been made in https://github.com/nxp-imx/linux-imx?

Even I'm facing the same pixel shift issue in imx8mm with lf-5.10 kernel and not able to see issue with lf-6.1 kernel. Is this fix made in lf-6.1? or in any branch of https://github.com/nxp-imx/linux-imx?

Best Regards,

Vinayak

0 Kudos
Reply
102,135 Views
ZhouLiang1
Contributor III

I test my device using mainline linux, not the version of linux-imx,  It fix in the following commits, 

ff3d5d04db07e5374758baa7e877fde8d683ebab

It solved my problem.
0 Kudos
Reply
102,654 Views
gigli_korg
Contributor II
Hi ZhouLiang1,
can you provide info about find the fix in version 6.8?

The commit/file/symbol could be enough.

Thanks in advance.

Stefano
0 Kudos
Reply
102,574 Views
ZhouLiang1
Contributor III

Hi, 

Sorry for the delay, The issue related to this commit:

ff3d5d04db07e5374758baa7e877fde8d683ebab

It solved my problem.