Adding LCD display (none lvds) in Linux 5.4 fslc?


Wouter Vanhauwaert
 

How do you correctly put a parallel lcd display in linux 5.4?
Uptill 4.9, there was a mxc_lcdif.c, but seems to be missing now?
In the devicetree, you used to add a node which had compatible="fsl,lcd", addressing the pinctrl etc
But none of these seem to exist now?
I see a commit https://github.com/Freescale/linux-fslc/commit/afcde9250592b07f165e2f66217726e26ac54e7c
This is supposed to add the lcdif, but hasn't or principle has changed? Can someone explain?


Philippe Schenker
 

On Thu, 2020-08-13 at 03:28 -0700, Wouter Vanhauwaert wrote:
How do you correctly put a parallel lcd display in linux 5.4?
Uptill 4.9, there was a mxc_lcdif.c, but seems to be missing now?
In the devicetree, you used to add a node which had
compatible="fsl,lcd", addressing the pinctrl etc
But none of these seem to exist now?
I see a commit
https://github.com/Freescale/linux-fslc/commit/afcde9250592b07f165e2f66217726e26ac54e7c
This is supposed to add the lcdif, but hasn't or principle has
changed? Can someone explain?

Yes this has completely changed, look at NXP's MEK devicetrees to figure that out, at least I was once able to figure it out like that.
On Colibri-iMX8X I once had it running with something like this:

&dpu_disp1_lcdif {
remote-endpoint = <&lcd_display_in>;
status = "okay";
};


This points to:

panel {
compatible = "logictechno,lt161010-2nhc";
backlight = <&backlight>;
status = "okay";

port {
lcd_panel_in: endpoint {
remote-endpoint = <&lcd_display_out>;
};
};
};

display@disp1 {
compatible = "fsl,imx-lcdif-mux-display";
#address-cells = <1>;
#size-cells = <0>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_lcdif>;
clocks = <&clk IMX_SC_R_LCD_0 IMX_SC_PM_CLK_BYPASS>,
<&clk IMX_SC_R_LCD_0 IMX_SC_PM_CLK_MISC0>;
clock-names = "bypass_div", "pixel";
assigned-clocks = <&clk IMX_SC_R_LCD_0 IMX_SC_PM_CLK_MISC0>;
assigned-clock-parents = <&clk IMX_SC_R_LCD_0
IMX_SC_PM_CLK_BYPASS>;
fsl,lcdif-mux-regs = <&lcdif_mux_regs>;
fsl,interface-pix-fmt = "bgr666";
power-domains = <&pd IMX_SC_R_LCD_0>;
status = "okay";

port@0 {
reg = <0>;

lcd_display_in: endpoint {
remote-endpoint = <&dpu_disp1_lcdif>;
};
};

port@1 {
reg = <1>;

lcd_display_out: endpoint {
remote-endpoint = <&lcd_panel_in>;
};
};
};

Hope this helps,
Philippe


Wouter Vanhauwaert
 

But that's the mainline way of working, no? When using etnaviv/drm/imx-ipu... ?
Why would the old ldb-style still work, but the old lcd isn't?


Christian Betz
 

Hi. I recently faced a similar problem on a custom imx6dl board, also with linux-fslc.

In my case i only have a single panel but it seems I had to define two panels to make the devicetree compiler happy (one of them is disabled though; and the DRM subsystem doesn't show multiple LVDS nodes). I am new to this though, so perhaps I am doing something wrong. I'm sure i could avoid duplicating the timings at least. (note: afaict the status=disabled on the LDB nodes have no effect; but the panel disable does).

after a day or two i settled on the following DTS definitions which are basically just mods to the stock imx6qdl-sabresd.dtsi

       panel1 {
                compatible = "panel-lvds";
                backlight = <&backlight_lvds>;

                data-mapping = "vesa-24";
                width-mm = <154>;
                height-mm = <87>;

                panel-timing {
                        clock-frequency = <67200000>;
                        hactive = <1024>;
                        vactive = <600>;
                        hfront-porch = <150>;
                        hsync-len = <76>;
                        hback-porch = <150>;
                        vfront-porch = <60>;
                        vsync-len = <80>;
                        vback-porch = <60>;
                        pixelclk-active = <0>;
                        hsync-active = <0>;
                        vsync-active = <0>;
                };

                 port {
                        panel1_in: endpoint {
                                remote-endpoint = <&lvds0_out>;
                        };
                };
        };

        panel2 {
                compatible = "panel-lvds";
                backlight = <&backlight_lvds>;
                status = "disabled";

                data-mapping = "vesa-24";
                width-mm = <154>;
                height-mm = <87>;

                panel-timing {
                        clock-frequency = <67200000>;
                        hactive = <1024>;
                        vactive = <600>;
                        hfront-porch = <150>;
                        hsync-len = <76>;
                        hback-porch = <150>;
                        vfront-porch = <60>;
                        vsync-len = <80>;
                        vback-porch = <60>;
                        pixelclk-active = <0>;
                        hsync-active = <0>;
                        vsync-active = <0>;
                };

                 port {
                        panel2_in: endpoint {
                                remote-endpoint = <&lvds1_out>;
                        };
                };
        };

...

&ldb {
        status = "okay";

        lvds-channel@0 {
                status = "okay";

                port@4 {
                        reg = <4>;

                        lvds0_out: endpoint {
                                remote-endpoint = <&panel1_in>;
                        };
                };
        };

        lvds-channel@1 {
                status = "disabled";

                port@4 {
                        reg = <4>;
                        status = "disabled";

                        lvds1_out: endpoint {
                                remote-endpoint = <&panel2_in>;
                        };
                };
        };
};



On Thu, Aug 13, 2020 at 8:28 AM Wouter Vanhauwaert <w.vanhauwaert@...> wrote:
But that's the mainline way of working, no? When using etnaviv/drm/imx-ipu... ?
Why would the old ldb-style still work, but the old lcd isn't?


--
"the new garbage collector will be an arena-based, quad-color incremental, generational, non-copying, high-speed, cache-optimized garbage collector" -- LuaJIT Roadmap


Christian Betz
 

On Thu, Aug 13, 2020 at 9:49 AM Christian Betz via lists.yoctoproject.org <christian.betz=gmail.com@...> wrote:
Hi. I recently faced a similar problem on a custom imx6dl board, also with linux-fslc.

I forgot to mention: I am using "use-mainline-bsp" here and I think that matters, as you've pointed out.
 

In my case i only have a single panel but it seems I had to define two panels to make the devicetree compiler happy (one of them is disabled though; and the DRM subsystem doesn't show multiple LVDS nodes). I am new to this though, so perhaps I am doing something wrong. I'm sure i could avoid duplicating the timings at least. (note: afaict the status=disabled on the LDB nodes have no effect; but the panel disable does).

after a day or two i settled on the following DTS definitions which are basically just mods to the stock imx6qdl-sabresd.dtsi

       panel1 {
                compatible = "panel-lvds";
                backlight = <&backlight_lvds>;

                data-mapping = "vesa-24";
                width-mm = <154>;
                height-mm = <87>;

                panel-timing {
                        clock-frequency = <67200000>;
                        hactive = <1024>;
                        vactive = <600>;
                        hfront-porch = <150>;
                        hsync-len = <76>;
                        hback-porch = <150>;
                        vfront-porch = <60>;
                        vsync-len = <80>;
                        vback-porch = <60>;
                        pixelclk-active = <0>;
                        hsync-active = <0>;
                        vsync-active = <0>;
                };

                 port {
                        panel1_in: endpoint {
                                remote-endpoint = <&lvds0_out>;
                        };
                };
        };

        panel2 {
                compatible = "panel-lvds";
                backlight = <&backlight_lvds>;
                status = "disabled";

                data-mapping = "vesa-24";
                width-mm = <154>;
                height-mm = <87>;

                panel-timing {
                        clock-frequency = <67200000>;
                        hactive = <1024>;
                        vactive = <600>;
                        hfront-porch = <150>;
                        hsync-len = <76>;
                        hback-porch = <150>;
                        vfront-porch = <60>;
                        vsync-len = <80>;
                        vback-porch = <60>;
                        pixelclk-active = <0>;
                        hsync-active = <0>;
                        vsync-active = <0>;
                };

                 port {
                        panel2_in: endpoint {
                                remote-endpoint = <&lvds1_out>;
                        };
                };
        };

...

&ldb {
        status = "okay";

        lvds-channel@0 {
                status = "okay";

                port@4 {
                        reg = <4>;

                        lvds0_out: endpoint {
                                remote-endpoint = <&panel1_in>;
                        };
                };
        };

        lvds-channel@1 {
                status = "disabled";

                port@4 {
                        reg = <4>;
                        status = "disabled";

                        lvds1_out: endpoint {
                                remote-endpoint = <&panel2_in>;
                        };
                };
        };
};



On Thu, Aug 13, 2020 at 8:28 AM Wouter Vanhauwaert <w.vanhauwaert@...> wrote:
But that's the mainline way of working, no? When using etnaviv/drm/imx-ipu... ?
Why would the old ldb-style still work, but the old lcd isn't?


--
"the new garbage collector will be an arena-based, quad-color incremental, generational, non-copying, high-speed, cache-optimized garbage collector" -- LuaJIT Roadmap



--
"the new garbage collector will be an arena-based, quad-color incremental, generational, non-copying, high-speed, cache-optimized garbage collector" -- LuaJIT Roadmap


Wouter Vanhauwaert
 

Ok, I'll try it out.
Still I don't understand why they would only change half of the functionality.... (And who decides or follows up)


Wouter Vanhauwaert
 

Hmm, it doesn't work.
But is this endpoint-setup not meant to be used together with DRM?
Whereas before it was for mxcfb? I'm stilll a bit lost...


Fabio Estevam
 

Hi Wouter,

On Thu, Aug 13, 2020 at 7:28 AM Wouter Vanhauwaert
<w.vanhauwaert@...> wrote:

How do you correctly put a parallel lcd display in linux 5.4?
Uptill 4.9, there was a mxc_lcdif.c, but seems to be missing now?
In the devicetree, you used to add a node which had compatible="fsl,lcd", addressing the pinctrl etc
But none of these seem to exist now?
I see a commit https://github.com/Freescale/linux-fslc/commit/afcde9250592b07f165e2f66217726e26ac54e7c
eLCDIF is a different display controller that is found on other i.MX
SoCs like imx23/imx28/imx6sl/imx6sx.

On imx6q/dl the display controller is the IPU.

In order to drive a parallel display using the IPU on imx6dl you need
to pass compatible = "fsl,imx-parallel-display";

Please see some dts as examples, such as arch/arm/boot/dts/imx6qdl-pico.dtsi.

It is also recommended to add an entry for the panel you are using
inside drivers/gpu/drm/panel/panel-simple.c


Wouter Vanhauwaert
 

Sorry, but I think that's not correct...
Indeed, you can use fsl,imx-parallel-display, but then you're using the opensource/drm mainline way of addressing the ipu, and not the freescale proprietary way.

fbdev/mxc/ldb.c is still providing the freescale proprietary way of configuring a mxcfb device
fbdev/mxc/mxc_lcdif.c is also using the imx6q/dl ipu for it's parallel lcd display, only it is gone since kernel 4.9-imx, which is strange as even the imx6qdl-sabresd.dtsi in the 5.4-2.0.x-imx branch is referring to it.. 
The way it is now, nothing is handling the compatible "fsl,lcd" in the whole 4.9-imx or 5.4-imx kernels, which is wrong according to me. I think it is just forgotten in a previous merge...
That would mean that commit https://github.com/Freescale/linux-fslc/commit/afcde9250592b07f165e2f66217726e26ac54e7c was incomplete.
As a test, I just put back the mxc_lcdif.c, and now my display is working perfectly again with configured devicetree:

   lcd@0 {
        compatible = "fsl,lcd";
        ipu_id = <0>;
        disp_id = <0>;
        default_ifmt = "RGB24";
        pinctrl-names = "default";
        pinctrl-0 = <&pinctrl_ipu1>;
        status = "okay";
    };
 
    mxcfb1: fb@0 {
        compatible = "fsl,mxc_sdc_fb";
        disp_dev = "lcd";
        interface_pix_fmt = "RGB24";
        mode_str ="CLAA-WVGA";
        default_bpp = <16>;
        int_clk = <0>;
        late_init = <0>;
        status = "disabled";
    };

If you think I am correct, I can create a pullrequest...


Fabio Estevam
 

Hi Wouter,

On Mon, Aug 17, 2020 at 3:59 PM Wouter Vanhauwaert
<w.vanhauwaert@...> wrote:

Sorry, but I think that's not correct...
Yes, when I looked at the commit you referred to I thought initially
that it only added drivers/video/fbdev/mxsfb.c, which is the eLCDIF
controller. In fact, it adds more things other than the mxsfb driver
and it also handles the IPU driver.

Indeed, you can use fsl,imx-parallel-display, but then you're using the opensource/drm mainline way of addressing the ipu, and not the freescale proprietary way.
Correct.

fbdev/mxc/ldb.c is still providing the freescale proprietary way of configuring a mxcfb device
fbdev/mxc/mxc_lcdif.c is also using the imx6q/dl ipu for it's parallel lcd display, only it is gone since kernel 4.9-imx, which is strange as even the imx6qdl-sabresd.dtsi in the 5.4-2.0.x-imx branch is referring to it..
The way it is now, nothing is handling the compatible "fsl,lcd" in the whole 4.9-imx or 5.4-imx kernels, which is wrong according to me. I think it is just forgotten in a previous merge...
Yes, I agree.

That would mean that commit https://github.com/Freescale/linux-fslc/commit/afcde9250592b07f165e2f66217726e26ac54e7c was incomplete.
As a test, I just put back the mxc_lcdif.c, and now my display is working perfectly again with configured devicetree:

lcd@0 {
compatible = "fsl,lcd";
ipu_id = <0>;
disp_id = <0>;
default_ifmt = "RGB24";
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_ipu1>;
status = "okay";
};

mxcfb1: fb@0 {
compatible = "fsl,mxc_sdc_fb";
disp_dev = "lcd";
interface_pix_fmt = "RGB24";
mode_str ="CLAA-WVGA";
default_bpp = <16>;
int_clk = <0>;
late_init = <0>;
status = "disabled";
};

If you think I am correct, I can create a pullrequest...
It looks correct.

Sorry for the confusion, I thought your goal was to use the "mainline"
way to drive a parallel panel on mx6. Now I understand that you want
to use the "NXP way".