Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider: - [Medium] arm64: dts: imx8dxl-evk: invalid and unparsed lcdif endpoint bus-width - [Medium] arm64: dts: imx8dxl-evk: disabling acm and codecs breaks audio consumers --
commit cfee436980bc9bed627f94a41d5e90946202 Author: Frank Li <[email protected]> arm64: dts: imx8dxl-evk: add lcdif overlay This commit adds a device tree overlay to support the waiken,101wx001-wct LCD panel on the i.MX8DXL EVK board, enabling adma_lcdif and disabling peripherals that share pins with the LCDIF interface. > diff --git > a/arch/arm64/boot/dts/freescale/imx8dxl-evk-lcdif-101wx001-wct.dtso > b/arch/arm64/boot/dts/freescale/imx8dxl-evk-lcdif-101wx001-wct.dtso > new file mode 100644 > index 0000000000000..39abf9b3884ea > --- /dev/null > +++ b/arch/arm64/boot/dts/freescale/imx8dxl-evk-lcdif-101wx001-wct.dtso [ ... ] > +&acm { > + status = "disabled"; > +}; > + > +&adma_lcdif { > + pinctrl-0 = <&pinctrl_lcdif>, <&lcd_0_fun>, <&lcd_1_fun>, <&lcd_2_fun>, > <&lcd_3_fun>; > + pinctrl-names = "default"; > + status = "okay"; > + > + port { > + lcdif_out: endpoint { > + bus-width = <18>; > + remote-endpoint = <&panel_in>; > + }; > + }; > +}; [Severity: Medium] Does setting bus-width = <18> on the lcdif_out endpoint work with the fsl,lcdif binding and the mxsfb driver? In Documentation/devicetree/bindings/display/fsl,lcdif.yaml, the port property is defined as: port: $ref: /schemas/graph.yaml#/properties/port description: The LCDIF output port Because it references /schemas/graph.yaml#/properties/port directly without referencing video-interfaces.yaml on the endpoint, endpoint sets additionalProperties: false and only allows reg, remote-endpoint, and phandle. Adding bus-width = <18> causes dtbs_check schema validation to fail. Furthermore, at runtime neither mxsfb, drm_panel_bridge, nor panel-simple parses bus-width from the endpoint node. When mxsfb_crtc_atomic_enable() calls mxsfb_set_formats() in drivers/gpu/drm/mxsfb/mxsfb_kms.c, it selects the bus width strictly from bus_format: switch (bus_format) { case MEDIA_BUS_FMT_RGB565_1X16: ctrl |= CTRL_BUS_WIDTH_16; break; case MEDIA_BUS_FMT_RGB666_1X18: ctrl |= CTRL_BUS_WIDTH_18; break; case MEDIA_BUS_FMT_RGB888_1X24: ctrl |= CTRL_BUS_WIDTH_24; break; Since waiken_101wx001_wct_panel in drivers/gpu/drm/panel/panel-simple.c advertises MEDIA_BUS_FMT_RGB888_1X24, mxsfb programs CTRL_BUS_WIDTH_24 even though only 18 data lines (ADMA_LCDIF_D00 through ADMA_LCDIF_D17) are routed on the board. [ ... ] > +&sai0 { > + status = "disabled"; > +}; > + > +&sai1 { > + status = "disabled"; > +}; > + > +&wm8960_1 { > + status = "disabled"; > +}; > + > +&wm8960_2 { > + status = "disabled"; > +}; > + > +&wm8960_3 { > + status = "disabled"; > +}; [Severity: Medium] Should the remaining audio nodes and sound cards in imx8dxl-evk.dts and imx8-ss-audio.dtsi also be disabled when &acm, &sai0, &sai1, and &wm8960_1..3 are disabled? In the base device tree, several enabled nodes depend on &acm and the disabled codecs/SAIs: 1. The audio LPCG clock nodes (sai0_lpcg through sai3_lpcg, spdif0_lpcg, mclkout0_lpcg, mclkout1_lpcg, and mqs0_lpcg) take parent clocks from &acm. With &acm disabled, imx8qxp_lpcg_clk_probe() -> imx_lpcg_parse_clks_from_dt() in drivers/clk/imx/clk-imx8qxp-lpcg.c fails to resolve parent clock names via of_clk_parent_fill(): ret = of_clk_parent_fill(np, parent_names, count); if (ret != count) { dev_err(&pdev->dev, "failed to get clock parent names\n"); return count; } 2. &asrc0 remains enabled in imx8dxl-evk.dts and directly consumes clocks from &acm, causing fsl_asrc_probe() to fail with -ENOENT. 3. &sai2 and &sai3 remain enabled in imx8dxl-evk.dts and consume clocks from sai2_lpcg and sai3_lpcg, causing fsl_sai_probe() to fail clock acquisition and defer probe indefinitely. 4. The root sound card nodes (sound-bt-sco, sound-wm8960-1, sound-wm8960-2, and sound-wm8960-3) remain enabled in imx8dxl-evk.dts while referencing the disabled &sai0, &sai1, &wm8960_1..3, and failing &asrc0/&sai2/&sai3 nodes, leaving their drivers in permanent probe deferral. -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=7
