On 11/9/21 8:35 PM, Adam Ford wrote:
[...]
diff --git a/arch/arm64/boot/dts/freescale/imx8mm.dtsi b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
index 208a0ed840f4..195dcbff7058 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
@@ -188,6 +188,12 @@
clock-output-names = "clk_ext4";
};
+ mipi_phy: mipi-video-phy {
+ compatible = "fsl,imx8mm-mipi-video-phy";
+ syscon = <&disp_blk_ctrl>;
+ #phy-cells = <1>;
+ };
+
psci {
compatible = "arm,psci-1.0";
method = "smc";
@@ -1068,6 +1074,68 @@
#size-cells = <1>;
ranges = <0x32c00000 0x32c00000 0x400000>;
+ lcdif: lcdif@32e00000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl,imx8mm-lcdif", "fsl,imx6sx-lcdif";
The compatible "imx6sx-lcdif" implies MXSFB_V6. FWICT, it is like
MXSFB_V4, but with overlays and those overlays have more registers
configured in the mxsfb_kms driver. Have you tried using imx28-lcdif
to see if it makes a difference?
Indeed, MX6SX has AS overlay plane support, MX{2,}8 does not.
LCDIFv3 (as NXP calls it) in MX8MP is like LCDIFv6 (in MX6SX) with
slightly reordered register bits, but nothing like LCDIF rev3 (in MX23)
... just to make sure there is no confusion.
[...]
+ mipi_dsi: mipi_dsi@32e10000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl,imx8mm-mipi-dsim";
+ reg = <0x32e10000 0x400>;
+ clocks = <&clk IMX8MM_CLK_DSI_CORE>,
+ <&clk IMX8MM_CLK_DSI_PHY_REF>;
+ clock-names = "bus_clk", "sclk_mipi";
+ assigned-clocks = <&clk IMX8MM_CLK_DSI_CORE>,
+ <&clk IMX8MM_VIDEO_PLL1_OUT>,
+ <&clk IMX8MM_CLK_DSI_PHY_REF>;
+ assigned-clock-parents = <&clk IMX8MM_SYS_PLL1_266M>,
+ <&clk IMX8MM_VIDEO_PLL1_BYPASS>,
+ <&clk IMX8MM_VIDEO_PLL1_OUT>;
+ assigned-clock-rates = <266000000>, <594000000>, <27000000>;
+ interrupts = <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH>;
+ phys = <&mipi_phy 0>;
+ phy-names = "dsim";
+ power-domains = <&disp_blk_ctrl IMX8MM_DISPBLK_PD_MIPI_DSI>;
+ samsung,burst-clock-frequency = <891000000>;
+ samsung,esc-clock-frequency = <54000000>;
+ samsung,pll-clock-frequency = <27000000>;
This 27 MHz is really IMX8MM_CLK_DSI_PHY_REF and
samsung,burst-clock-frequency is really the DSI link clock which is
panel/bridge specific ... but, why do we need to specify such policy in
DT rather than have the panel/bridge drivers negotiate the best clock
settings with DSIM bridge driver ? This should be something which should
be implemented in the DRM subsystem, not hard-coded in DT. These ad-hoc
samsung,*-clock-frequency properties shouldn't even be needed then.
Also, are the DSIM bindings stable now ?
