Cannot get display to work using LVDS bridge in an i.MX7ULP

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

Cannot get display to work using LVDS bridge in an i.MX7ULP

309件の閲覧回数
HenrikZ
Contributor III

Hi 

I'm having some  troubles getting my display to work (TX18D211VM0BAA) with the i.MX7ULP. The display is using LVDS for communication, thus I have place a MIPI_DSI-LVDS bridge (SN65DSI83TPAPRQ1) to convert the signals for the display.
When booting Linux, it all seems fine:


root@imx7ulpevk:/# dmesg | grep -i -E "mipi|sn65|lcdif|video|drm|panel"
[ 0.085332] platform 40a90000.mipi_dsi: Fixed dependency cycle(s) with /bus@40000000/lpi2c4@402b0000/sn65dsi83@2c
[ 0.134710] platform 40a90000.mipi_dsi: Fixed dependency cycle(s) with /bus@40000000/lpi2c4@402b0000/sn65dsi83@2c
[ 0.135162] i2c 2-002c: Fixed dependency cycle(s) with /bus@40000000/lpi2c4@402b0000/sn65dsi83@2c/panel@0/ports/port@0
[ 0.135253] i2c 2-002c: Fixed dependency cycle(s) with /bus@40800000/mipi_dsi@40a90000
[ 0.142246] videodev: Linux video capture interface: v2.00
[ 0.146419] MIPI CSI2 driver module loaded
[ 0.564469] mipi_dsi_northwest 40a90000.mipi_dsi: i.MX MIPI DSI driver probed
[ 2.187945] [drm] Initialized vivante 1.0.0 20170808 for 41800000.gpu on minor 0
[ 7.157978] systemd[1]: Starting Load Kernel Module drm...
[ 14.327604] systemd[1]: modprobe@drm.service: Deactivated successfully.
[ 14.514570] systemd[1]: Finished Load Kernel Module drm.

though at the very end of the boot process I do get a notice the the Psplash failed to start:


[FAILED] Failed to start Terminate Psplash Boot Screen.
See 'systemctl status psplash-quit.service' for details.


Below is the snippets from the dts, that shows the configuration of the bridge and panel.

Do anyone have some ideas why nothing is shown on the display? Is there something that I'm failing or missing to do?

&lpi2c4 {
   #address-cells = <1>;
   #size-cells = <0>;
   clock-frequency = <100000>;
   pinctrl-names = "default", "sleep";
   pinctrl-0 = <&pinctrl_lpi2c4>;
   pinctrl-1 = <&pinctrl_lpi2c4>;
   status = "okay";


   dsi_lvds_bridge: sn65dsi83@2c {
      compatible = "ti,sn65dsi83";
      reg = <0x2c>;              /* 7-bit I2C address */
      pinctrl-names = "default";
      pinctrl-0 = <&sn65dsi83_enable_pins &sn65dsi83_irq_pins>;
      status = "okay";

      interrupt-gpios = <&gpio_ptc 2 GPIO_ACTIVE_LOW>;/* PTC2 */
      enable-gpios = <&gpio_ptc 3 GPIO_ACTIVE_HIGH>; /* PTC3 */

      ti,dsi-lanes = <2>;            /* Use two DSI lanes, DA0 and DA1 */
      ti,lvds-format = <1>;
      ti,lvds-bpp = <18>;            /* 6-bit per color -> 18 bpp */
      ti,lvds-channels = <1>;
      ti,width-mm = <152>;
      ti,height-mm = <91>;
      video-mode = <1>;
      /* dsi traffic mode (0=non-burst,1=sync-event,2=burst) */
      dsi-traffic-mode = <0>;

      panel: panel@0 {
         compatible = "panel-simple";
         reg = <0>;
         label = "lvds-panel";

         display-timings {
            native-mode = <&timing0>;
            timing0: timing0 {
               clock-frequency = <33300000>; /* Clock freq. 33.3 MHz */
               hactive = <800>;
               vactive = <480>;

               hsync-len = <128>;        /* thp (HS pulse) ≈ 128 */
               hback-porch = <10>;       /* thb */
               hfront-porch = <118>;     /* thf */

               vsync-len = <1>;          /* tvp~1 */
               vback-porch = <9>;        /* tvb (tvp+tvb = 10 -> tvb=9) */
               vfront-porch = <35>;      /* tvf */

               de-active = <1>;
               hsync-active = <0>;       
               vsync-active = <0>;
               pixelclk-active = <0>;
            };
         };

         ports {
            #address-cells = <1>;
            #size-cells = <0>;
            port@0 {
               reg = <0>;
               endpoint {
                  panel_ep: endpoint {
                     /* left empty: this is the panel end-point */
                  };
               };
            };
         };
      };

      ports {
            #address-cells = <1>;
            #size-cells = <0>;
            port@0 {
                reg = <0>;
                lvds_bridge_in: endpoint {
                    remote-endpoint = <&dsi_out>;  /* DSI host endpoint on &lcdif */
                    data-lanes = <0 1>;
                };
            };

            port@1 {
                reg = <1>;
                lvds_bridge_out: endpoint {
                    remote-endpoint = <&panel_ep>; /* link to panel node */
                };
            };
      };
   }; 
};

&mipi_dsi {
    #address-cells = <1>;
    #size-cells = <0>;
   
   pinctrl-names = "default", "sleep";
   pinctrl-0 = <&pinctrl_mipi_dsi_reset>;
   pinctrl-1 = <&pinctrl_mipi_dsi_reset>;
   lcd_panel = "TX18D211VM0BAA";
   resets = <&mipi_dsi_reset>;
   status = "okay";

   ports {
      #address-cells = <1>;
         #size-cells = <0>;
        port@0 {
            reg = <0>;
            dsi_out: endpoint {            
            remote-endpoint = <&lvds_bridge_in>;
                data-lanes = <0 1>;
            attach-bridge;            
            };
        };
    };
};

 

ラベル(3)
タグ(2)
0 件の賞賛
返信
4 返答(返信)

280件の閲覧回数
Bio_TICFSL
NXP TechSupport
NXP TechSupport

Hello, 

The sn65dsi83 probe function pries to lock PLL from MIPI-DSI before imx_sec_dsim_encoder_atomic_enable() function ensbles it.

Moved piece of code that sets PLL to sn65dsi83_atomic_enable() function.

This problem was fixed after I adding

loglevel=8 drm.debug=0x1ff

to kernel commandline.

It was incorrect LVDS timing configuration so the mode was rejected.

 

Regards

0 件の賞賛
返信

259件の閲覧回数
HenrikZ
Contributor III

Hi

Thanks for the answer.

I tried to apply the patch but it seems that the version (scarthgap 6.6.52) already have the modification in place. When applying patch, i tried to make a dry run and get the message:

"error: drivers/gpu/drm/imx/sec_mipi_dsim-imx.c: patch does not apply"

HenrikZ_0-1759404669732.png

Looking into the file that are going to be patched, the lines that are added is found a little further down in the file.

HenrikZ_1-1759404830247.png

This means that the patch unfortunately does not solve the problem.
Other suggestions to solve the problem are very welcome:-)

Regards

 

0 件の賞賛
返信

254件の閲覧回数
HenrikZ
Contributor III

Hi

Maybe one more thing to consider in order to solve the problem... When I look at the clock for the mipi-dsi, it seems not to be enabled. I'm not sure if it supposed to be like that or if it should be enabled. Below is a screenshot of the clock register, and besides "hardware enable" which is no, then also the clock rate does not look right?

HenrikZ_0-1759407813777.png

Any ideas?

/Regards

0 件の賞賛
返信

180件の閲覧回数
HenrikZ
Contributor III

The device tree source (dts) for linux kernel defines some of the settings for the MIPI_DSI output and input for the LVDS-bridge, e.g.  number of dsi lanes and lvds-bpp, but the bridge has more register settings that seems necessary to define to get the bridge working together with the MIPI_DSI output. The clock source for the LVDS-bridge is defined in register 0x0A, where bit zero is defining of the clock source is either derived from the REFCLK pin (default) or from the MIPI D-PHY channel – in my case I use the latter, which meant that bit 0 needs to be set. This is not the case when I am reading the registers from the linux command line.

All the channel posts that I can find regarding this topic seem only to mention the dts configuration and leave out the configuration of the registers of the bridge. Is there something I have missed?

Also the Kernel configuration provides an option of either compiling the sn65dsi83 kernel module or include the kernel module. To my understanding the kernel module provides the link between the dts and the hardware, thus the settings dts should be read by the kernel module and reflected in the settings of the bridge? Or how are the settings of the bridge defined if not by the kernel module?

I guess that the kernel module is compiled from the file ti-sn65dsi83.c which is included in the yocto/bitbake repository. This file seems to get the settings from somewhere else, could it be from the dts as suggested above?

Hope someone can shed some light on this

/Regards

0 件の賞賛
返信