[RFC] arm64: dts: imx8mm: Add MIPI and LCDIF nodes

[Marek Vasut]

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 at 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 at 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 ?