meta-freescale.lists.yoctoproject.org archive mirror
 help / color / mirror / Atom feed
* Adding LCD display (none lvds) in Linux 5.4 fslc?
@ 2020-08-13 10:28 Wouter Vanhauwaert
  2020-08-13 10:39 ` [meta-freescale] " Philippe Schenker
  2020-08-17 18:13 ` [meta-freescale] " Fabio Estevam
  0 siblings, 2 replies; 10+ messages in thread
From: Wouter Vanhauwaert @ 2020-08-13 10:28 UTC (permalink / raw)
  To: meta-freescale

[-- Attachment #1: Type: text/plain, Size: 468 bytes --]

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?

[-- Attachment #2: Type: text/html, Size: 595 bytes --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [meta-freescale] Adding LCD display (none lvds) in Linux 5.4 fslc?
  2020-08-13 10:28 Adding LCD display (none lvds) in Linux 5.4 fslc? Wouter Vanhauwaert
@ 2020-08-13 10:39 ` Philippe Schenker
  2020-08-13 12:28   ` Wouter Vanhauwaert
  2020-08-14  9:17   ` Wouter Vanhauwaert
  2020-08-17 18:13 ` [meta-freescale] " Fabio Estevam
  1 sibling, 2 replies; 10+ messages in thread
From: Philippe Schenker @ 2020-08-13 10:39 UTC (permalink / raw)
  To: w.vanhauwaert, meta-freescale

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Adding LCD display (none lvds) in Linux 5.4 fslc?
  2020-08-13 10:39 ` [meta-freescale] " Philippe Schenker
@ 2020-08-13 12:28   ` Wouter Vanhauwaert
  2020-08-13 13:49     ` [meta-freescale] " Christian Betz
       [not found]     ` <162AD810805EBE6C.3117@lists.yoctoproject.org>
  2020-08-14  9:17   ` Wouter Vanhauwaert
  1 sibling, 2 replies; 10+ messages in thread
From: Wouter Vanhauwaert @ 2020-08-13 12:28 UTC (permalink / raw)
  To: meta-freescale

[-- Attachment #1: Type: text/plain, Size: 145 bytes --]

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?

[-- Attachment #2: Type: text/html, Size: 149 bytes --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [meta-freescale] Adding LCD display (none lvds) in Linux 5.4 fslc?
  2020-08-13 12:28   ` Wouter Vanhauwaert
@ 2020-08-13 13:49     ` Christian Betz
       [not found]     ` <162AD810805EBE6C.3117@lists.yoctoproject.org>
  1 sibling, 0 replies; 10+ messages in thread
From: Christian Betz @ 2020-08-13 13:49 UTC (permalink / raw)
  To: Wouter Vanhauwaert; +Cc: meta-freescale

[-- Attachment #1: Type: text/plain, Size: 3875 bytes --]

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@televic.com> 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

[-- Attachment #2: Type: text/html, Size: 5625 bytes --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [meta-freescale] Adding LCD display (none lvds) in Linux 5.4 fslc?
       [not found]     ` <162AD810805EBE6C.3117@lists.yoctoproject.org>
@ 2020-08-13 14:08       ` Christian Betz
  0 siblings, 0 replies; 10+ messages in thread
From: Christian Betz @ 2020-08-13 14:08 UTC (permalink / raw)
  To: Christian Betz; +Cc: Wouter Vanhauwaert, meta-freescale

[-- Attachment #1: Type: text/plain, Size: 4519 bytes --]

On Thu, Aug 13, 2020 at 9:49 AM Christian Betz via lists.yoctoproject.org
<christian.betz=gmail.com@lists.yoctoproject.org> 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@televic.com> 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

[-- Attachment #2: Type: text/html, Size: 6624 bytes --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Adding LCD display (none lvds) in Linux 5.4 fslc?
  2020-08-13 10:39 ` [meta-freescale] " Philippe Schenker
  2020-08-13 12:28   ` Wouter Vanhauwaert
@ 2020-08-14  9:17   ` Wouter Vanhauwaert
  2020-08-17 10:16     ` Wouter Vanhauwaert
  1 sibling, 1 reply; 10+ messages in thread
From: Wouter Vanhauwaert @ 2020-08-14  9:17 UTC (permalink / raw)
  To: meta-freescale

[-- Attachment #1: Type: text/plain, Size: 137 bytes --]

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)

[-- Attachment #2: Type: text/html, Size: 141 bytes --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Adding LCD display (none lvds) in Linux 5.4 fslc?
  2020-08-14  9:17   ` Wouter Vanhauwaert
@ 2020-08-17 10:16     ` Wouter Vanhauwaert
  0 siblings, 0 replies; 10+ messages in thread
From: Wouter Vanhauwaert @ 2020-08-17 10:16 UTC (permalink / raw)
  To: meta-freescale

[-- Attachment #1: Type: text/plain, Size: 150 bytes --]

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...

[-- Attachment #2: Type: text/html, Size: 158 bytes --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [meta-freescale] Adding LCD display (none lvds) in Linux 5.4 fslc?
  2020-08-13 10:28 Adding LCD display (none lvds) in Linux 5.4 fslc? Wouter Vanhauwaert
  2020-08-13 10:39 ` [meta-freescale] " Philippe Schenker
@ 2020-08-17 18:13 ` Fabio Estevam
  2020-08-17 18:59   ` Wouter Vanhauwaert
  1 sibling, 1 reply; 10+ messages in thread
From: Fabio Estevam @ 2020-08-17 18:13 UTC (permalink / raw)
  To: Wouter Vanhauwaert; +Cc: meta-freescale

Hi Wouter,

On Thu, Aug 13, 2020 at 7:28 AM Wouter Vanhauwaert
<w.vanhauwaert@televic.com> 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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Adding LCD display (none lvds) in Linux 5.4 fslc?
  2020-08-17 18:13 ` [meta-freescale] " Fabio Estevam
@ 2020-08-17 18:59   ` Wouter Vanhauwaert
  2020-08-17 20:40     ` [meta-freescale] " Fabio Estevam
  0 siblings, 1 reply; 10+ messages in thread
From: Wouter Vanhauwaert @ 2020-08-17 18:59 UTC (permalink / raw)
  To: meta-freescale

[-- Attachment #1: Type: text/plain, Size: 1495 bytes --]

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 ( 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...

[-- Attachment #2: Type: text/html, Size: 2315 bytes --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [meta-freescale] Adding LCD display (none lvds) in Linux 5.4 fslc?
  2020-08-17 18:59   ` Wouter Vanhauwaert
@ 2020-08-17 20:40     ` Fabio Estevam
  0 siblings, 0 replies; 10+ messages in thread
From: Fabio Estevam @ 2020-08-17 20:40 UTC (permalink / raw)
  To: Wouter Vanhauwaert; +Cc: meta-freescale

Hi Wouter,

On Mon, Aug 17, 2020 at 3:59 PM Wouter Vanhauwaert
<w.vanhauwaert@televic.com> 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".

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2020-08-17 20:40 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-08-13 10:28 Adding LCD display (none lvds) in Linux 5.4 fslc? Wouter Vanhauwaert
2020-08-13 10:39 ` [meta-freescale] " Philippe Schenker
2020-08-13 12:28   ` Wouter Vanhauwaert
2020-08-13 13:49     ` [meta-freescale] " Christian Betz
     [not found]     ` <162AD810805EBE6C.3117@lists.yoctoproject.org>
2020-08-13 14:08       ` Christian Betz
2020-08-14  9:17   ` Wouter Vanhauwaert
2020-08-17 10:16     ` Wouter Vanhauwaert
2020-08-17 18:13 ` [meta-freescale] " Fabio Estevam
2020-08-17 18:59   ` Wouter Vanhauwaert
2020-08-17 20:40     ` [meta-freescale] " Fabio Estevam

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).