Date
1 - 10 of 10
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? 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... ? -- "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:
I forgot to mention: I am using "use-mainline-bsp" here and I think that matters, as you've pointed out.
-- "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: 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: 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 deviceYes, I agree. That would mean that commit https://github.com/Freescale/linux-fslc/commit/afcde9250592b07f165e2f66217726e26ac54e7c was incomplete.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".
|
|
|