IMX8MM: assign panel to mipi_dsi in a device tree

IMX8MM: assign panel to mipi_dsi in a device tree

[Patrick Boettcher]

Hi list,

After several days of trying I realize my too small/old brain is unable
to map around how to assign/connect a panel to the mipi_dsi-node in a
device.

We are using a 'tdo,tl070wsh30' panel connected to the
mipi-dsi-interface of a imx8mm.

Of all the references I found on the in public repositories none of
them is using this exact panel. Well.

Looking at other device trees I came up with the following dts-node add
to the mipi_dsi-node:

&mipi_dsi {
	#address-cells = <1>;
	#size-cells = <0>;
	status = "okay";

	port@0 {
		reg = <0>;
		mipi_dsi_panel0_out: endpoint {
			remote-endpoint = <&panel0_in>;
			attach-bridge;
		};
	};

	panel@0 {
		compatible = "tdo,tl070wsh30";
		reg = <0>;

		pinctrl-0 = <&pinctrl_mipi_dsi>;
		pinctrl-names = "default";
		reset-gpios = <&gpio4 4 GPIO_ACTIVE_LOW>;
		enable-gpios = <&gpio4 6 GPIO_ACTIVE_LOW>;

		backlight = <&panel_gpio_backlight>;
		power-supply = <&panel_gpio_regulator>;

		dsi-lanes = <4>;

		video-mode = <0>; 

		panel-width-mm = <157>;
		panel-height-mm = <86>;

		status = "okay";

		port {
			panel0_in: endpoint {
				remote-endpoint =<&mipi_dsi_panel0_out>;
 			};
		};
	};
};


You'll see that I used the attach-bridge-option, which is maybe not
necessary. I found this during a debug-print-session in the
drm-bridge-driver, it wasn't attaching a bridge. But maybe I don't need
a bridge as the panel-driver contains everything to control the
controllers of the panel. I don't really know.

However, with this I have the following messages:

[    0.393985] [drm:drm_bridge_attach] *ERROR* failed to attach bridge /soc@0/bus@32c00000/mipi_dsi@32e10000 to encoder DSI-34: -19
[    0.405626] imx_sec_dsim_drv 32e10000.mipi_dsi: Failed to attach bridge: 32e10000.mipi_dsi
[    0.413974] imx_sec_dsim_drv 32e10000.mipi_dsi: failed to bind sec dsim bridge: -517

The panel driver is never instantiated.

I'm using 5.15.51 (-imx). mipi_dsi and the panel-driver are built into
the kernel.

I have to say that I'm basically trying to imitate the
device-tree-implementation based on example rather than understanding
the exact details of how to correctly work with mipi_dsi and the panel.

I'd appreciate any help and pointers which lead me into the right
direction.

Thanks in advance.

--
Patrick.

Re: IMX8MM: assign panel to mipi_dsi in a device tree

[Jagan Teki]

On Sun, Mar 5, 2023 at 11:39 PM Patrick Boettcher
<patrick.boettcher@posteo.de> wrote:
>
> Hi list,
>
> After several days of trying I realize my too small/old brain is unable
> to map around how to assign/connect a panel to the mipi_dsi-node in a
> device.
>
> We are using a 'tdo,tl070wsh30' panel connected to the
> mipi-dsi-interface of a imx8mm.
>
> Of all the references I found on the in public repositories none of
> them is using this exact panel. Well.
>
> Looking at other device trees I came up with the following dts-node add
> to the mipi_dsi-node:
>
> &mipi_dsi {
>         #address-cells = <1>;
>         #size-cells = <0>;
>         status = "okay";
>
>         port@0 {
>                 reg = <0>;
>                 mipi_dsi_panel0_out: endpoint {
>                         remote-endpoint = <&panel0_in>;
>                         attach-bridge;
>                 };
>         };
>
>         panel@0 {
>                 compatible = "tdo,tl070wsh30";
>                 reg = <0>;
>
>                 pinctrl-0 = <&pinctrl_mipi_dsi>;
>                 pinctrl-names = "default";
>                 reset-gpios = <&gpio4 4 GPIO_ACTIVE_LOW>;
>                 enable-gpios = <&gpio4 6 GPIO_ACTIVE_LOW>;
>
>                 backlight = <&panel_gpio_backlight>;
>                 power-supply = <&panel_gpio_regulator>;
>
>                 dsi-lanes = <4>;
>
>                 video-mode = <0>;
>
>                 panel-width-mm = <157>;
>                 panel-height-mm = <86>;
>
>                 status = "okay";
>
>                 port {
>                         panel0_in: endpoint {
>                                 remote-endpoint =<&mipi_dsi_panel0_out>;
>                         };
>                 };
>         };
> };
>
>
> You'll see that I used the attach-bridge-option, which is maybe not
> necessary. I found this during a debug-print-session in the
> drm-bridge-driver, it wasn't attaching a bridge. But maybe I don't need
> a bridge as the panel-driver contains everything to control the
> controllers of the panel. I don't really know.
>
> However, with this I have the following messages:
>
> [    0.393985] [drm:drm_bridge_attach] *ERROR* failed to attach bridge /soc@0/bus@32c00000/mipi_dsi@32e10000 to encoder DSI-34: -19
> [    0.405626] imx_sec_dsim_drv 32e10000.mipi_dsi: Failed to attach bridge: 32e10000.mipi_dsi
> [    0.413974] imx_sec_dsim_drv 32e10000.mipi_dsi: failed to bind sec dsim bridge: -517
>
> The panel driver is never instantiated.
>
> I'm using 5.15.51 (-imx). mipi_dsi and the panel-driver are built into
> the kernel.

Please share the source repo link? B/W if you may try the mainline
code base of imx8mm dsi please check here.
https://github.com/openedev/kernel/commits/imx8mm-dsi-v16

Jagan.

Re: IMX8MM: assign panel to mipi_dsi in a device tree

[Patrick Boettcher]

On Mon, 6 Mar 2023 00:05:03 +0530
Jagan Teki <jagan@amarulasolutions.com> wrote:

>On Sun, Mar 5, 2023 at 11:39 PM Patrick Boettcher
><patrick.boettcher@posteo.de> wrote:
>>
>> Hi list,
>>
>> After several days of trying I realize my too small/old brain is
>> unable to map around how to assign/connect a panel to the
>> mipi_dsi-node in a device.
>>
>> We are using a 'tdo,tl070wsh30' panel connected to the
>> mipi-dsi-interface of a imx8mm.
>>
>> Of all the references I found on the in public repositories none of
>> them is using this exact panel. Well.
>>
>> Looking at other device trees I came up with the following dts-node
>> add to the mipi_dsi-node:
>>
>> &mipi_dsi {
>>         #address-cells = <1>;
>>         #size-cells = <0>;
>>         status = "okay";
>>
>>         port@0 {
>>                 reg = <0>;
>>                 mipi_dsi_panel0_out: endpoint {
>>                         remote-endpoint = <&panel0_in>;
>>                         attach-bridge;
>>                 };
>>         };
>>
>>         panel@0 {
>>                 compatible = "tdo,tl070wsh30";
>>                 reg = <0>;
>>
>>                 pinctrl-0 = <&pinctrl_mipi_dsi>;
>>                 pinctrl-names = "default";
>>                 reset-gpios = <&gpio4 4 GPIO_ACTIVE_LOW>;
>>                 enable-gpios = <&gpio4 6 GPIO_ACTIVE_LOW>;
>>
>>                 backlight = <&panel_gpio_backlight>;
>>                 power-supply = <&panel_gpio_regulator>;
>>
>>                 dsi-lanes = <4>;
>>
>>                 video-mode = <0>;
>>
>>                 panel-width-mm = <157>;
>>                 panel-height-mm = <86>;
>>
>>                 status = "okay";
>>
>>                 port {
>>                         panel0_in: endpoint {
>>                                 remote-endpoint
>> =<&mipi_dsi_panel0_out>; };
>>                 };
>>         };
>> };
>>
>>
>> You'll see that I used the attach-bridge-option, which is maybe not
>> necessary. I found this during a debug-print-session in the
>> drm-bridge-driver, it wasn't attaching a bridge. But maybe I don't
>> need a bridge as the panel-driver contains everything to control the
>> controllers of the panel. I don't really know.
>>
>> However, with this I have the following messages:
>>
>> [    0.393985] [drm:drm_bridge_attach] *ERROR* failed to attach
>> bridge /soc@0/bus@32c00000/mipi_dsi@32e10000 to encoder DSI-34: -19
>> [    0.405626] imx_sec_dsim_drv 32e10000.mipi_dsi: Failed to attach
>> bridge: 32e10000.mipi_dsi [    0.413974] imx_sec_dsim_drv
>> 32e10000.mipi_dsi: failed to bind sec dsim bridge: -517
>>
>> The panel driver is never instantiated.
>>
>> I'm using 5.15.51 (-imx). mipi_dsi and the panel-driver are built
>> into the kernel.  
>
>Please share the source repo link? 

I'm using this one (via yocto's recipe):

    github.com/nxp-imx/linux-imx.git, branch lf-5.15.y

> B/W if you may try the mainline
>code base of imx8mm dsi please check here.
>https://github.com/openedev/kernel/commits/imx8mm-dsi-v16

Do you really think this is a kernel version problem not only an
integration issue? I mean NXP's version is coming with device-tree's
using panels, and, although I can't test, I believe they are working,
aren't they?

--
Patrick.

Re: IMX8MM: assign panel to mipi_dsi in a device tree

[Frieder Schrempf]

On 05.03.23 20:45, Patrick Boettcher wrote:
> [Sie erhalten nicht häufig E-Mails von patrick.boettcher@posteo.de. Weitere Informationen, warum dies wichtig ist, finden Sie unter https://aka.ms/LearnAboutSenderIdentification ]
> 
> On Mon, 6 Mar 2023 00:05:03 +0530
> Jagan Teki <jagan@amarulasolutions.com> wrote:
> 
>> On Sun, Mar 5, 2023 at 11:39 PM Patrick Boettcher
>> <patrick.boettcher@posteo.de> wrote:
>>>
>>> Hi list,
>>>
>>> After several days of trying I realize my too small/old brain is
>>> unable to map around how to assign/connect a panel to the
>>> mipi_dsi-node in a device.
>>>
>>> We are using a 'tdo,tl070wsh30' panel connected to the
>>> mipi-dsi-interface of a imx8mm.
>>>
>>> Of all the references I found on the in public repositories none of
>>> them is using this exact panel. Well.
>>>
>>> Looking at other device trees I came up with the following dts-node
>>> add to the mipi_dsi-node:
>>>
>>> &mipi_dsi {
>>>         #address-cells = <1>;
>>>         #size-cells = <0>;
>>>         status = "okay";
>>>
>>>         port@0 {
>>>                 reg = <0>;
>>>                 mipi_dsi_panel0_out: endpoint {
>>>                         remote-endpoint = <&panel0_in>;
>>>                         attach-bridge;
>>>                 };
>>>         };
>>>
>>>         panel@0 {
>>>                 compatible = "tdo,tl070wsh30";
>>>                 reg = <0>;
>>>
>>>                 pinctrl-0 = <&pinctrl_mipi_dsi>;
>>>                 pinctrl-names = "default";
>>>                 reset-gpios = <&gpio4 4 GPIO_ACTIVE_LOW>;
>>>                 enable-gpios = <&gpio4 6 GPIO_ACTIVE_LOW>;
>>>
>>>                 backlight = <&panel_gpio_backlight>;
>>>                 power-supply = <&panel_gpio_regulator>;
>>>
>>>                 dsi-lanes = <4>;
>>>
>>>                 video-mode = <0>;
>>>
>>>                 panel-width-mm = <157>;
>>>                 panel-height-mm = <86>;
>>>
>>>                 status = "okay";
>>>
>>>                 port {
>>>                         panel0_in: endpoint {
>>>                                 remote-endpoint
>>> =<&mipi_dsi_panel0_out>; };
>>>                 };
>>>         };
>>> };
>>>
>>>
>>> You'll see that I used the attach-bridge-option, which is maybe not
>>> necessary. I found this during a debug-print-session in the
>>> drm-bridge-driver, it wasn't attaching a bridge. But maybe I don't
>>> need a bridge as the panel-driver contains everything to control the
>>> controllers of the panel. I don't really know.
>>>
>>> However, with this I have the following messages:
>>>
>>> [    0.393985] [drm:drm_bridge_attach] *ERROR* failed to attach
>>> bridge /soc@0/bus@32c00000/mipi_dsi@32e10000 to encoder DSI-34: -19
>>> [    0.405626] imx_sec_dsim_drv 32e10000.mipi_dsi: Failed to attach
>>> bridge: 32e10000.mipi_dsi [    0.413974] imx_sec_dsim_drv
>>> 32e10000.mipi_dsi: failed to bind sec dsim bridge: -517
>>>
>>> The panel driver is never instantiated.
>>>
>>> I'm using 5.15.51 (-imx). mipi_dsi and the panel-driver are built
>>> into the kernel.
>>
>> Please share the source repo link?
> 
> I'm using this one (via yocto's recipe):
> 
>     github.com/nxp-imx/linux-imx.git, branch lf-5.15.y

This is the NXP vendor kernel which differs a lot from mainline,
especially in the graphics/display area. You probably won't get much
support from this list as most people here (including me) would advise
against using the vendor kernel at all.

> 
>> B/W if you may try the mainline
>> code base of imx8mm dsi please check here.
>> https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenedev%2Fkernel%2Fcommits%2Fimx8mm-dsi-v16&data=05%7C01%7Cfrieder.schrempf%40kontron.de%7Cecab86504a844ecbe8fb08db1dc80c14%7C8c9d3c973fd941c8a2b1646f3942daf1%7C0%7C0%7C638136517256300234%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=D2Ri4bUaPvkRCiuYWihOgC8PkGC8BGAVG9qnGhlBhEE%3D&reserved=0
> 
> Do you really think this is a kernel version problem not only an
> integration issue? I mean NXP's version is coming with device-tree's
> using panels, and, although I can't test, I believe they are working,
> aren't they?

Probably they are working and probably you can get your setup working,
too, somehow. But you would need to ask for help in the NXP community or
elsewhere. The other option is to switch to mainline (recommended) and
use Jagan's patches for DSIM support that are about to be upstreamed.

Re: IMX8MM: assign panel to mipi_dsi in a device tree

[Patrick Boettcher]

On Mon, 6 Mar 2023 09:43:22 +0100
Frieder Schrempf <frieder.schrempf@kontron.de> wrote:
>This is the NXP vendor kernel which differs a lot from mainline,
>especially in the graphics/display area. You probably won't get much
>support from this list as most people here (including me) would advise
>against using the vendor kernel at all.

Understandable, I did the same at the time when I was working in media
and DVB was still a thing.

>Probably they are working and probably you can get your setup working,
>too, somehow. But you would need to ask for help in the NXP community
>or elsewhere. The other option is to switch to mainline (recommended)
>and use Jagan's patches for DSIM support that are about to be
>upstreamed.

Thanks for your feedback. Unfortunately my client wants to stick with
the vendor kernel, so my only chance is to see whether it works with
upstream mainline and if so, at least I know the hardware is OK.

Why oh why do we have vendor kernels? In small-system's Linux there
sooo many vendor kernels. Very hard to understand. It's 2023.

The answers to a similar problem I found in the NXP community board
was: go look at the driver source and see what's wrong.

Thanks again for your answers.

best regards,
--
Patrick.