RZ/V2L: MIPI Display probe issue

You should debug inside function drm_bridge_attach() and find out why it is failing. Then you will know your answer.

If driver : drivers/gpu/drm/drm_bridge.c in function "drm_bridge_attach" there is a condition like below

if (bridge->funcs->attach) {
ret = bridge->funcs->attach(bridge, flags);
if (ret < 0)
goto err_reset_bridge;
}

exactly in this condition, error occurs and excution will directly go to "err_reset_bridge".

So, I am stuck here.

You have to see what function is bridge->funcs->attach()

That is one thing about the kernel that is annoying....all the function pointers that are filled in at run time.

You can print out the value of bridge->funcs->attach and see what matches up with it in your system.map file.

But, it is probably the function rzg2l_mipi_dsi_attach() in file drivers/gpu/drm/rcar-du/rzg2l_mipi_dsi.c

You can see where it fills in all the function pointers:

static const struct drm_bridge_funcs rzg2l_mipi_dsi_bridge_ops = {
       .attach = rzg2l_mipi_dsi_attach,
       .detach = rzg2l_mipi_dsi_detach,
       .mode_set = rzg2l_mipi_dsi_mode_set,
       .enable = rzg2l_mipi_dsi_enable,
       .disable = rzg2l_mipi_dsi_disable,
       .mode_valid = rzg2l_mipi_dsi_bridge_mode_valid,
};

I would put a printk in that rzg2l_mipi_dsi_attach() function to see if that is what it is calling.

And if so, why it is failing.

Basically, you just keep doing this procedure over and over again until you finally find the line that fails.

I had helped someone once that we did this for a several hours....only to find that the reason for the failure was a spelling mistake in the Device Tree. It was a very simple fix, but took hours to find. That's Linux.

Hi,

According to the suggestion i have put print statements in drivers and check what is failing.
Below are my observations:

In driver "drivers/gpu/drm/rcar-du/rzg2l_mipi_dsi.c" function "rzg2l_mipi_dsi_attach"
ret = rzg2l_mipi_dsi_find_panel_or_bridge(mipi_dsi);
This function is called and this is pointing to "rzg2l_mipi_dsi_find_panel_or_bridge" in same driver.
There is an if-else condition checking if bridge or not.

Our display is not connected to any brige. Direct MIPI lanes from CPU is connected to display.
Hence it goes to "else" condition and tries to find the display with below function
mipi_dsi->panel = of_drm_find_panel(remote);

This call points to driver "drivers/gpu/drm/drm_panel.c" function "of_drm_find_panel"
This function executes and directly returns "-EPROBE_DEFER".

Below is our dts configuration:
&dsi0 {
    status = "okay";

     panel@0 { /* MIPI_DSI: MIPI DSI Host */
         compatible = "panel-winstar";
         v3p3-supply = <&reg_3p3v>;
         v1p8-supply = <&reg_1p8v>;
         dsi-lanes = <4>;
         video-mode = <2>;
         width-mm = <154>;
         height-mm = <85>;
         status = "okay";

         port@0 {
              panel_in: endpoint {
                   remote-endpoint = <&dsi0_out>;
              };
         };
      };

      ports {
         port@1 {
               reg = <1>;
               dsi0_out: endpoint {
                              remote-endpoint = <&panel_in>;
                              data-lanes = <1 2 3 4>;
                              attach-bridge;
               };
            };
      };
};

&du {
      status = "okay";
};

Kindly help in solving this issue.

Do you actually have a panel driver?

You've got this in the device tree:

Navya said:

         compatible = "panel-winstar"

So you do actually have a driver file for that?

Hi,

Yes i have a driver which is exact copy of "drivers/gpu/drm/panel/panel-raydium-rm67191.c".

Only compatible is changed and respective changes in Makefile, Kconfig file to compile that driver.

I tried with  compatible = "raydium,rm67191"

Still probe fails

Navya said:

Still probe fails

That is what you need to fix. You have to find out why the probe fails.

At the end of the probe function in the driver, it will call:

drm_panel_add(&panel->panel);

And then you will have a panel that the MIPI driver can select.

And, you will not have this issue anymore:

Navya said:

Our display is not connected to any brige. Direct MIPI lanes from CPU is connected to display.
Hence it goes to "else" condition and tries to find the display with below function
mipi_dsi->panel = of_drm_find_panel(remote);

Hi,

I am using the same panel and I have similar issues.

I am using the panel-simple driver and adapted it to match with the winstar configuration.

The problem on my side is, that the probe function of the driver is never called. This makes it really hard to debug.

Do you face the same issue? 

BR

Hi joschi2804,

Here is the example to add the dsi panel that supports by panel-simple.c driver in devicetree.

Please check in your dts then retry:

&dsi0 {
        status = "okay";

+       #address-cells = <1>;
+       #size-cells = <0>;
+
        ports {
                port@1 {
                        dsi0_out: endpoint {
-                               remote-endpoint = <&adv7535_in>;
+                               remote-endpoint = <&panel_in>;
                                data-lanes = <1 2 3 4>;
                        };
                };
        };
+
+       panel@0 {
+               compatible = "lg,ld070wx3-sl01";
+               reg = <0>;
+
+                ports {
+                        #address-cells = <1>;
+                        #size-cells = <0>;
+                        port {
+                                panel_in: endpoint {
+                                        remote-endpoint = <&dsi0_out>;
+                                };
+                        };
+                };
+        };
 };

And please ensure that CONFIG_DRM_PANEL_SIMPLE=y is set.

Hi,

thanks for the fast response. Yes, my problem was that I've added the driver as kernel module and not compiled within the kernel.

Thanks.

BR