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


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

Join meta-freescale@lists.yoctoproject.org to automatically receive all group messages.