[PATCH V8 00/12] soc: imx8mp: Add support for HDMI

[PATCH V8 00/12] soc: imx8mp: Add support for HDMI

[Adam Ford]

The i.MX8M Plus has an HDMI controller, but it depends on two
other systems, the Parallel Video Interface (PVI) and the
HDMI PHY from Samsung. The LCDIF controller generates the display
and routes it to the PVI which converts passes the parallel video
to the HDMI bridge.  The HDMI system has a corresponding power
domain controller whose driver was partially written, but the
device tree for it was never applied, so some changes to the
power domain should be harmless because they've not really been
used yet.

This series is adapted from multiple series from Lucas Stach with
edits and suggestions from feedback from various series, but it
since it's difficult to use and test them independently,
I merged them into on unified series.  The version history is a
bit ambiguous since different components were submitted at different
times and had different amount of retries.  In an effort to merge them
I used the highest version attempt.

Adam Ford (3):
  dt-bindings: soc: imx: add missing clock and power-domains to
    imx8mp-hdmi-blk-ctrl
  pmdomain: imx8mp-blk-ctrl: imx8mp_blk: Add fdcc clock to hdmimix
    domain
  arm64: defconfig: Enable DRM_IMX8MP_DW_HDMI_BRIDGE as module

Lucas Stach (9):
  dt-bindings: phy: add binding for the i.MX8MP HDMI PHY
  phy: freescale: add Samsung HDMI PHY
  arm64: dts: imx8mp: add HDMI power-domains
  arm64: dts: imx8mp: add HDMI irqsteer
  dt-bindings: display: imx: add binding for i.MX8MP HDMI PVI
  drm/bridge: imx: add driver for HDMI TX Parallel Video Interface
  dt-bindings: display: imx: add binding for i.MX8MP HDMI TX
  drm/bridge: imx: add bridge wrapper driver for i.MX8MP DWC HDMI
  arm64: dts: imx8mp: add HDMI display pipeline

 .../display/bridge/fsl,imx8mp-hdmi-tx.yaml    |  102 ++
 .../display/imx/fsl,imx8mp-hdmi-pvi.yaml      |   84 ++
 .../bindings/phy/fsl,imx8mp-hdmi-phy.yaml     |   62 +
 .../soc/imx/fsl,imx8mp-hdmi-blk-ctrl.yaml     |   22 +-
 arch/arm64/boot/dts/freescale/imx8mp.dtsi     |  145 +++
 arch/arm64/configs/defconfig                  |    1 +
 drivers/gpu/drm/bridge/imx/Kconfig            |   18 +
 drivers/gpu/drm/bridge/imx/Makefile           |    2 +
 drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c  |  207 ++++
 drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx.c   |  154 +++
 drivers/phy/freescale/Kconfig                 |    6 +
 drivers/phy/freescale/Makefile                |    1 +
 drivers/phy/freescale/phy-fsl-samsung-hdmi.c  | 1075 +++++++++++++++++
 drivers/pmdomain/imx/imx8mp-blk-ctrl.c        |   10 +-
 14 files changed, 1876 insertions(+), 13 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/display/bridge/fsl,imx8mp-hdmi-tx.yaml
 create mode 100644 Documentation/devicetree/bindings/display/imx/fsl,imx8mp-hdmi-pvi.yaml
 create mode 100644 Documentation/devicetree/bindings/phy/fsl,imx8mp-hdmi-phy.yaml
 create mode 100644 drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c
 create mode 100644 drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx.c
 create mode 100644 drivers/phy/freescale/phy-fsl-samsung-hdmi.c

-- 
2.43.0

[PATCH V8 01/12] dt-bindings: phy: add binding for the i.MX8MP HDMI PHY

[Adam Ford]

From: Lucas Stach <l.stach@pengutronix.de>

Add a DT binding for the HDMI PHY found on the i.MX8MP SoC.

Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Adam Ford <aford173@gmail.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
V3:  Removed mintems at the request of Krzysztof and add his
     reviewed-by

V2:  I tried to help move this along, so I took Lucas' patch and
     attempted to apply fixes based on feedback.  I don't have
     all the history, so apologies for that.

     Added phy-cells to the required list and fixed an error due
     to the word 'binding' being in the title.
---
 .../bindings/phy/fsl,imx8mp-hdmi-phy.yaml     | 62 +++++++++++++++++++
 1 file changed, 62 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/fsl,imx8mp-hdmi-phy.yaml

diff --git a/Documentation/devicetree/bindings/phy/fsl,imx8mp-hdmi-phy.yaml b/Documentation/devicetree/bindings/phy/fsl,imx8mp-hdmi-phy.yaml
new file mode 100644
index 000000000000..c43e86a8c2e0
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/fsl,imx8mp-hdmi-phy.yaml
@@ -0,0 +1,62 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/fsl,imx8mp-hdmi-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX8MP HDMI PHY
+
+maintainers:
+  - Lucas Stach <l.stach@pengutronix.de>
+
+properties:
+  compatible:
+    enum:
+      - fsl,imx8mp-hdmi-phy
+
+  reg:
+    maxItems: 1
+
+  "#clock-cells":
+    const: 0
+
+  clocks:
+    maxItems: 2
+
+  clock-names:
+    items:
+      - const: apb
+      - const: ref
+
+  "#phy-cells":
+    const: 0
+
+  power-domains:
+    maxItems: 1
+
+required:
+  - compatible
+  - reg
+  - "#clock-cells"
+  - clocks
+  - clock-names
+  - "#phy-cells"
+  - power-domains
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/clock/imx8mp-clock.h>
+    #include <dt-bindings/power/imx8mp-power.h>
+
+    phy@32fdff00 {
+        compatible = "fsl,imx8mp-hdmi-phy";
+        reg = <0x32fdff00 0x100>;
+        clocks = <&clk IMX8MP_CLK_HDMI_APB>,
+                 <&clk IMX8MP_CLK_HDMI_24M>;
+        clock-names = "apb", "ref";
+        power-domains = <&hdmi_blk_ctrl IMX8MP_HDMIBLK_PD_HDMI_TX_PHY>;
+        #clock-cells = <0>;
+        #phy-cells = <0>;
+    };
-- 
2.43.0

[PATCH V8 02/12] phy: freescale: add Samsung HDMI PHY

[Adam Ford]

From: Lucas Stach <l.stach@pengutronix.de>

This adds the driver for the Samsung HDMI PHY found on the
i.MX8MP SoC.

Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Adam Ford <aford173@gmail.com>
Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com>
---
V4:  Make lookup table hex values lower case.

V3:  Re-order the Makefile to keep it alphabetical
     Remove unused defines

V2:  Fixed some whitespace found from checkpatch
     Change error handling when enabling apbclk to use dev_err_probe
     Rebase on Linux-Next

     I (Adam) tried to help move this along, so I took Lucas' patch and
     attempted to apply fixes based on feedback.  I don't have
     all the history, so apologies for that.
---
 drivers/phy/freescale/Kconfig                |    6 +
 drivers/phy/freescale/Makefile               |    1 +
 drivers/phy/freescale/phy-fsl-samsung-hdmi.c | 1075 ++++++++++++++++++
 3 files changed, 1082 insertions(+)
 create mode 100644 drivers/phy/freescale/phy-fsl-samsung-hdmi.c

diff --git a/drivers/phy/freescale/Kconfig b/drivers/phy/freescale/Kconfig
index 853958fb2c06..5c2b73042dfc 100644
--- a/drivers/phy/freescale/Kconfig
+++ b/drivers/phy/freescale/Kconfig
@@ -35,6 +35,12 @@ config PHY_FSL_IMX8M_PCIE
 	  Enable this to add support for the PCIE PHY as found on
 	  i.MX8M family of SOCs.
 
+config PHY_FSL_SAMSUNG_HDMI_PHY
+	tristate "Samsung HDMI PHY support"
+	depends on OF && HAS_IOMEM
+	help
+	  Enable this to add support for the Samsung HDMI PHY in i.MX8MP.
+
 endif
 
 config PHY_FSL_LYNX_28G
diff --git a/drivers/phy/freescale/Makefile b/drivers/phy/freescale/Makefile
index cedb328bc4d2..79e5f16d3ce8 100644
--- a/drivers/phy/freescale/Makefile
+++ b/drivers/phy/freescale/Makefile
@@ -4,3 +4,4 @@ obj-$(CONFIG_PHY_MIXEL_LVDS_PHY)	+= phy-fsl-imx8qm-lvds-phy.o
 obj-$(CONFIG_PHY_MIXEL_MIPI_DPHY)	+= phy-fsl-imx8-mipi-dphy.o
 obj-$(CONFIG_PHY_FSL_IMX8M_PCIE)	+= phy-fsl-imx8m-pcie.o
 obj-$(CONFIG_PHY_FSL_LYNX_28G)		+= phy-fsl-lynx-28g.o
+obj-$(CONFIG_PHY_FSL_SAMSUNG_HDMI_PHY)  += phy-fsl-samsung-hdmi.o
diff --git a/drivers/phy/freescale/phy-fsl-samsung-hdmi.c b/drivers/phy/freescale/phy-fsl-samsung-hdmi.c
new file mode 100644
index 000000000000..bf0e2299d00f
--- /dev/null
+++ b/drivers/phy/freescale/phy-fsl-samsung-hdmi.c
@@ -0,0 +1,1075 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2020 NXP
+ * Copyright 2022 Pengutronix, Lucas Stach <kernel@pengutronix.de>
+ */
+
+#include <linux/clk-provider.h>
+#include <linux/clk.h>
+#include <linux/delay.h>
+#include <linux/io.h>
+#include <linux/iopoll.h>
+#include <linux/module.h>
+#include <linux/of_device.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/pm_runtime.h>
+
+#define PHY_REG_33		0x84
+#define  REG33_MODE_SET_DONE	BIT(7)
+#define  REG33_FIX_DA		BIT(1)
+
+#define PHY_REG_34		0x88
+#define  REG34_PHY_READY	BIT(7)
+#define  REG34_PLL_LOCK		BIT(6)
+#define  REG34_PHY_CLK_READY	BIT(5)
+
+
+#define PHY_PLL_REGS_NUM 48
+
+struct phy_config {
+	u32	clk_rate;
+	u8 regs[PHY_PLL_REGS_NUM];
+};
+
+const struct phy_config phy_pll_cfg[] = {
+	{	22250000, {
+			0x00, 0xd1, 0x4b, 0xf1, 0x89, 0x88, 0x80, 0x40,
+			0x4f, 0x30, 0x33, 0x65, 0x00, 0x15, 0x25, 0x80,
+			0x6c, 0xf2, 0x67, 0x00, 0x10, 0x8f, 0x30, 0x32,
+			0x60, 0x8f, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
+			0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+			0x00, 0xe0, 0x83, 0x0f, 0x3e, 0xf8, 0x00, 0x00,
+		},
+	}, {
+		23750000, {
+			0x00, 0xd1, 0x50, 0xf1, 0x86, 0x85, 0x80, 0x40,
+			0x4f, 0x30, 0x33, 0x65, 0x00, 0x03, 0x25, 0x80,
+			0x6c, 0xf2, 0x67, 0x00, 0x10, 0x8f, 0x30, 0x32,
+			0x60, 0x8f, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
+			0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+			0x00, 0xe0, 0x83, 0x0f, 0x3e, 0xf8, 0x00, 0x00,
+		},
+	}, {
+		24000000, {
+			0x00, 0xd1, 0x50, 0xf0, 0x00, 0x00, 0x80, 0x00,
+			0x4f, 0x30, 0x33, 0x65, 0x00, 0x01, 0x25, 0x80,
+			0x6c, 0xf2, 0x67, 0x00, 0x10, 0x8f, 0x30, 0x32,
+			0x60, 0x8f, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
+			0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+			0x00, 0xe0, 0x83, 0x0f, 0x3e, 0xf8, 0x00, 0x00,
+		},
+	}, {
+		24024000, {
+			0x00, 0xd1, 0x50, 0xf1, 0x99, 0x02, 0x80, 0x40,
+			0x4f, 0x30, 0x33, 0x65, 0x00, 0x00, 0x25, 0x80,
+			0x6c, 0xf2, 0x67, 0x00, 0x10, 0x8f, 0x30, 0x32,
+			0x60, 0x8f, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
+			0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+			0x00, 0xe0, 0x83, 0x0f, 0x3e, 0xf8, 0x00, 0x00,
+		},
+	}, {
+		25175000, {
+			0x00, 0xd1, 0x54, 0xfc, 0xcc, 0x91, 0x80, 0x40,
+			0x4f, 0x30, 0x33, 0x65, 0x00, 0xf5, 0x24, 0x80,
+			0x6c, 0xf2, 0x67, 0x00, 0x10, 0x8f, 0x30, 0x32,
+			0x60, 0x8f, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
+			0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+			0x00, 0xe0, 0x83, 0x0f, 0x3e, 0xf8, 0x00, 0x00,
+		},
+	}, {
+		25200000, {
+			0x00, 0xd1, 0x54, 0xf0, 0x00, 0x00, 0x80, 0x00,
+			0x4f, 0x30, 0x33, 0x65, 0x00, 0xf4, 0x24, 0x80,
+			0x6c, 0xf2, 0x67, 0x00, 0x10, 0x8f, 0x30, 0x32,
+			0x60, 0x8f, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
+			0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+			0x00, 0xe0, 0x83, 0x0f, 0x3e, 0xf8, 0x00, 0x00,
+		},
+	}, {
+		26750000, {
+			0x00, 0xd1, 0x5a, 0xf2, 0x89, 0x88, 0x80, 0x40,
+			0x4f, 0x30, 0x33, 0x65, 0x00, 0xe6, 0x24, 0x80,
+			0x6c, 0xf2, 0x67, 0x00, 0x10, 0x8f, 0x30, 0x32,
+			0x60, 0x8f, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
+			0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+			0x00, 0xe0, 0x83, 0x0f, 0x3e, 0xf8, 0x00, 0x00,
+		},
+	}, {
+		27000000, {
+			0x00, 0xd1, 0x5a, 0xf0, 0x00, 0x00, 0x80, 0x00,
+			0x4f, 0x30, 0x33, 0x65, 0x00, 0xe4, 0x24, 0x80,
+			0x6c, 0xf2, 0x67, 0x00, 0x10, 0x8f, 0x30, 0x32,
+			0x60, 0x8f, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
+			0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+			0x00, 0xe0, 0x83, 0x0f, 0x3e, 0xf8, 0x00, 0x00,
+		},
+	}, {
+		27027000, {
+			0x00, 0xd1, 0x5a, 0xf2, 0xfd, 0x0c, 0x80, 0x40,
+			0x4f, 0x30, 0x33, 0x65, 0x00, 0xe4, 0x24, 0x80,
+			0x6c, 0xf2, 0x67, 0x00, 0x10, 0x8f, 0x30, 0x32,
+			0x60, 0x8f, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
+			0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+			0x00, 0xe0, 0x83, 0x0f, 0x3e, 0xf8, 0x00, 0x00,
+		},
+	}, {
+		29500000, {
+			0x00, 0xd1, 0x62, 0xf4, 0x95, 0x08, 0x80, 0x40,
+			0x4f, 0x30, 0x33, 0x65, 0x00, 0xd1, 0x24, 0x80,
+			0x6c, 0xf2, 0x67, 0x00, 0x10, 0x8f, 0x30, 0x32,
+			0x60, 0x8f, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
+			0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+			0x00, 0xe0, 0x83, 0x0f, 0x3e, 0xf8, 0x00, 0x00,
+		},
+	}, {
+		30750000, {
+			0x00, 0xd1, 0x66, 0xf4, 0x82, 0x01, 0x88, 0x45,
+			0x4f, 0x30, 0x33, 0x65, 0x00, 0xc8, 0x24, 0x80,
+			0x6c, 0xf2, 0x67, 0x00, 0x10, 0x8f, 0x30, 0x32,
+			0x60, 0x8f, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
+			0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+			0x00, 0xe0, 0x83, 0x0f, 0x3e, 0xf8, 0x00, 0x00,
+		},
+	}, {
+		30888000, {
+			0x00, 0xd1, 0x66, 0xf4, 0x99, 0x18, 0x88, 0x45,
+			0x4f, 0x30, 0x33, 0x65, 0x00, 0xc7, 0x24, 0x80,
+			0x6c, 0xf2, 0x67, 0x00, 0x10, 0x8f, 0x30, 0x32,
+			0x60, 0x8f, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
+			0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+			0x00, 0xe0, 0x83, 0x0f, 0x3e, 0xf8, 0x00, 0x00,
+		},
+	}, {
+		33750000, {
+			0x00, 0xd1, 0x70, 0xf4, 0x82, 0x01, 0x80, 0x40,
+			0x4f, 0x30, 0x33, 0x65, 0x00, 0xb7, 0x24, 0x80,
+			0x6c, 0xf2, 0x67, 0x00, 0x10, 0x8f, 0x30, 0x32,
+			0x60, 0x8f, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
+			0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+			0x00, 0xe0, 0x83, 0x0f, 0x3e, 0xf8, 0x00, 0x00,
+		},
+	}, {
+		35000000, {
+			0x00, 0xd1, 0x58, 0xb8, 0x8b, 0x88, 0x80, 0x40,
+			0x4f, 0x30, 0x33, 0x65, 0x00, 0xb0, 0x24, 0x80,
+			0x6c, 0xf2, 0x67, 0x00, 0x10, 0x8b, 0x30, 0x32,
+			0x60, 0x8f, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
+			0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+			0x00, 0xe0, 0x83, 0x0f, 0x3e, 0xf8, 0x00, 0x00,
+		},
+	}, {
+		36000000, {
+			0x00, 0xd1, 0x5a, 0xb0, 0x00, 0x00, 0x80, 0x00,
+			0x4f, 0x30, 0x33, 0x65, 0x00, 0xab, 0x24, 0x80,
+			0x6c, 0xf2, 0x67, 0x00, 0x10, 0x8b, 0x30, 0x32,
+			0x60, 0x8f, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
+			0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+			0x00, 0xe0, 0x83, 0x0f, 0x3e, 0xf8, 0x00, 0x00,
+		},
+	}, {
+		36036000, {
+			0x00, 0xd1, 0x5a, 0xb2, 0xfd, 0x0c, 0x80, 0x40,
+			0x4f, 0x30, 0x33, 0x65, 0x00, 0xab, 0x24, 0x80,
+			0x6c, 0xf2, 0x67, 0x00, 0x10, 0x8b, 0x30, 0x32,
+			0x60, 0x8f, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
+			0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+			0x00, 0xe0, 0x83, 0x0f, 0x3e, 0xf8, 0x00, 0x00,
+		},
+	}, {
+		40000000, {
+			0x00, 0xd1, 0x64, 0xb0, 0x00, 0x00, 0x80, 0x00,
+			0x4f, 0x30, 0x33, 0x65, 0x00, 0x9a, 0x24, 0x80,
+			0x6c, 0xf2, 0x67, 0x00, 0x10, 0x8b, 0x30, 0x32,
+			0x60, 0x8f, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
+			0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+			0x00, 0xe0, 0x83, 0x0f, 0x3e, 0xf8, 0x00, 0x00,
+		},
+	}, {
+		43200000, {
+			0x00, 0xd1, 0x5a, 0x90, 0x00, 0x00, 0x80, 0x00,
+			0x4f, 0x30, 0x33, 0x65, 0x00, 0x8f, 0x24, 0x80,
+			0x6c, 0xf2, 0x67, 0x00, 0x10, 0x89, 0x30, 0x32,
+			0x60, 0x8f, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
+			0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+			0x00, 0xe0, 0x83, 0x0f, 0x3e, 0xf8, 0x00, 0x00,
+		},
+	}, {
+		43243200, {
+			0x00, 0xd1, 0x5a, 0x92, 0xfd, 0x0c, 0x80, 0x40,
+			0x4f, 0x30, 0x33, 0x65, 0x00, 0x8f, 0x24, 0x80,
+			0x6c, 0xf2, 0x67, 0x00, 0x10, 0x89, 0x30, 0x32,
+			0x60, 0x8f, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
+			0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+			0x00, 0xe0, 0x83, 0x0f, 0x3e, 0xf8, 0x00, 0x00,
+		},
+	}, {
+		44500000, {
+			0x00, 0xd1, 0x5c, 0x92, 0x98, 0x11, 0x84, 0x41,
+			0x4f, 0x30, 0x33, 0x65, 0x00, 0x8b, 0x24, 0x80,
+			0x6c, 0xf2, 0x67, 0x00, 0x10, 0x89, 0x30, 0x32,
+			0x60, 0x8f, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
+			0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+			0x00, 0xe0, 0x83, 0x0f, 0x3e, 0xf8, 0x00, 0x00,
+		},
+	}, {
+		47000000, {
+			0x00, 0xd1, 0x62, 0x94, 0x95, 0x82, 0x80, 0x40,
+			0x4f, 0x30, 0x33, 0x65, 0x00, 0x83, 0x24, 0x80,
+			0x6c, 0xf2, 0x67, 0x00, 0x10, 0x89, 0x30, 0x32,
+			0x60, 0x8f, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
+			0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+			0x00, 0xe0, 0x83, 0x0f, 0x3e, 0xf8, 0x00, 0x00,
+		},
+	}, {
+		47500000, {
+			0x00, 0xd1, 0x63, 0x96, 0xa1, 0x82, 0x80, 0x40,
+			0x4f, 0x30, 0x33, 0x65, 0x00, 0x82, 0x24, 0x80,
+			0x6c, 0xf2, 0x67, 0x00, 0x10, 0x89, 0x30, 0x32,
+			0x60, 0x8f, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
+			0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+			0x00, 0xe0, 0x83, 0x0f, 0x3e, 0xf8, 0x00, 0x00,
+		},
+	}, {
+		50349650, {
+			0x00, 0xd1, 0x54, 0x7c, 0xc3, 0x8f, 0x80, 0x40,
+			0x4f, 0x30, 0x33, 0x65, 0x10, 0xf5, 0x24, 0x80,
+			0x6c, 0xf2, 0x67, 0x00, 0x10, 0x87, 0x30, 0x32,
+			0x60, 0x8f, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
+			0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+			0x00, 0xe0, 0x83, 0x0f, 0x3e, 0xf8, 0x00, 0x00,
+		},
+	}, {
+		50400000, {
+			0x00, 0xd1, 0x54, 0x70, 0x00, 0x00, 0x80, 0x00,
+			0x4f, 0x30, 0x33, 0x65, 0x10, 0xf4, 0x24, 0x80,
+			0x6c, 0xf2, 0x67, 0x00, 0x10, 0x87, 0x30, 0x32,
+			0x60, 0x8f, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
+			0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+			0x00, 0xe0, 0x83, 0x0f, 0x3e, 0xf8, 0x00, 0x00,
+		},
+	}, {
+		53250000, {
+			0x00, 0xd1, 0x58, 0x72, 0x84, 0x03, 0x82, 0x41,
+			0x4f, 0x30, 0x33, 0x65, 0x10, 0xe7, 0x24, 0x80,
+			0x6c, 0xf2, 0x67, 0x00, 0x10, 0x87, 0x30, 0x32,
+			0x60, 0x8f, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
+			0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+			0x00, 0xe0, 0x83, 0x0f, 0x3e, 0xf8, 0x00, 0x00,
+		},
+	}, {
+		53500000, {
+			0x00, 0xd1, 0x5a, 0x72, 0x89, 0x88, 0x80, 0x40,
+			0x4f, 0x30, 0x33, 0x65, 0x10, 0xe6, 0x24, 0x80,
+			0x6c, 0xf2, 0x67, 0x00, 0x10, 0x87, 0x30, 0x32,
+			0x60, 0x8f, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
+			0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+			0x00, 0xe0, 0x83, 0x0f, 0x3e, 0xf8, 0x00, 0x00,
+		},
+	}, {
+		54000000, {
+			0x00, 0xd1, 0x5a, 0x70, 0x00, 0x00, 0x80, 0x00,
+			0x4f, 0x30, 0x33, 0x65, 0x10, 0xe4, 0x24, 0x80,
+			0x6c, 0xf2, 0x67, 0x00, 0x10, 0x87, 0x30, 0x32,
+			0x60, 0x8f, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
+			0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+			0x00, 0xe0, 0x83, 0x0f, 0x3e, 0xf8, 0x00, 0x00,
+		},
+	}, {
+		54054000, {
+			0x00, 0xd1, 0x5a, 0x72, 0xfd, 0x0c, 0x80, 0x40,
+			0x4f, 0x30, 0x33, 0x65, 0x10, 0xe4, 0x24, 0x80,
+			0x6c, 0xf2, 0x67, 0x00, 0x10, 0x87, 0x30, 0x32,
+			0x60, 0x8f, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
+			0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+			0x00, 0xe0, 0x83, 0x0f, 0x3e, 0xf8, 0x00, 0x00,
+		},
+	}, {
+		59000000, {
+			0x00, 0xd1, 0x62, 0x74, 0x95, 0x08, 0x80, 0x40,
+			0x4f, 0x30, 0x33, 0x65, 0x10, 0xd1, 0x24, 0x80,
+			0x6c, 0xf2, 0x67, 0x00, 0x10, 0x87, 0x30, 0x32,
+			0x60, 0x8f, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
+			0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+			0x00, 0xe0, 0x83, 0x0f, 0x3e, 0xf8, 0x00, 0x00,
+		},
+	}, {
+		59340659, {
+			0x00, 0xd1, 0x62, 0x74, 0xdb, 0x52, 0x88, 0x47,
+			0x4f, 0x30, 0x33, 0x65, 0x10, 0xd0, 0x24, 0x80,
+			0x6c, 0xf2, 0x67, 0x00, 0x10, 0x87, 0x30, 0x32,
+			0x60, 0x8f, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
+			0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+			0x00, 0xe0, 0x83, 0x0f, 0x3e, 0xf8, 0x00, 0x00,
+		},
+	}, {
+		59400000, {
+			0x00, 0xd1, 0x63, 0x70, 0x00, 0x00, 0x80, 0x00,
+			0x4f, 0x30, 0x33, 0x65, 0x10, 0xcf, 0x24, 0x80,
+			0x6c, 0xf2, 0x67, 0x00, 0x10, 0x87, 0x30, 0x32,
+			0x60, 0x8f, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
+			0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+			0x00, 0xe0, 0x83, 0x0f, 0x3e, 0xf8, 0x00, 0x00,
+		},
+	}, {
+		61500000, {
+			0x00, 0xd1, 0x66, 0x74, 0x82, 0x01, 0x88, 0x45,
+			0x4f, 0x30, 0x33, 0x65, 0x10, 0xc8, 0x24, 0x80,
+			0x6c, 0xf2, 0x67, 0x00, 0x10, 0x87, 0x30, 0x32,
+			0x60, 0x8f, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
+			0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+			0x00, 0xe0, 0x83, 0x0f, 0x3e, 0xf8, 0x00, 0x00,
+		},
+	}, {
+		63500000, {
+			0x00, 0xd1, 0x69, 0x74, 0x89, 0x08, 0x80, 0x40,
+			0x4f, 0x30, 0x33, 0x65, 0x10, 0xc2, 0x24, 0x80,
+			0x6c, 0xf2, 0x67, 0x00, 0x10, 0x87, 0x30, 0x32,
+			0x60, 0x8f, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
+			0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+			0x00, 0xe0, 0x83, 0x0f, 0x3e, 0xf8, 0x00, 0x00,
+		},
+	}, {
+		67500000, {
+			0x00, 0xd1, 0x54, 0x52, 0x87, 0x03, 0x80, 0x40,
+			0x4f, 0x30, 0x33, 0x65, 0x10, 0xb7, 0x24, 0x80,
+			0x6c, 0xf2, 0x67, 0x00, 0x10, 0x85, 0x30, 0x32,
+			0x60, 0x8f, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
+			0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+			0x00, 0xe0, 0x83, 0x0f, 0x3e, 0xf8, 0x00, 0x00,
+		},
+	}, {
+		70000000, {
+			0x00, 0xd1, 0x58, 0x58, 0x8b, 0x88, 0x80, 0x40,
+			0x4f, 0x30, 0x33, 0x65, 0x10, 0xb0, 0x24, 0x80,
+			0x6c, 0xf2, 0x67, 0x00, 0x10, 0x85, 0x30, 0x32,
+			0x60, 0x8f, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
+			0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+			0x00, 0xe0, 0x83, 0x0f, 0x3e, 0xf8, 0x00, 0x00,
+		},
+	}, {
+		72000000, {
+			0x00, 0xd1, 0x5a, 0x50, 0x00, 0x00, 0x80, 0x00,
+			0x4f, 0x30, 0x33, 0x65, 0x10, 0xab, 0x24, 0x80,
+			0x6c, 0xf2, 0x67, 0x00, 0x10, 0x85, 0x30, 0x32,
+			0x60, 0x8f, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
+			0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+			0x00, 0xe0, 0x83, 0x0f, 0x3e, 0xf8, 0x00, 0x00,
+		},
+	}, {
+		72072000, {
+			0x00, 0xd1, 0x5a, 0x52, 0xfd, 0x0c, 0x80, 0x40,
+			0x4f, 0x30, 0x33, 0x65, 0x10, 0xab, 0x24, 0x80,
+			0x6c, 0xf2, 0x67, 0x00, 0x10, 0x85, 0x30, 0x32,
+			0x60, 0x8f, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
+			0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+			0x00, 0xe0, 0x83, 0x0f, 0x3e, 0xf8, 0x00, 0x00,
+		},
+	}, {
+		74176000, {
+			0x00, 0xd1, 0x5d, 0x58, 0xdb, 0xa2, 0x88, 0x41,
+			0x4f, 0x30, 0x33, 0x65, 0x10, 0xa6, 0x24, 0x80,
+			0x6c, 0xf2, 0x67, 0x00, 0x10, 0x85, 0x30, 0x32,
+			0x60, 0x8f, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
+			0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+			0x00, 0xe0, 0x83, 0x0f, 0x3e, 0xf8, 0x00, 0x00,
+		},
+	}, {
+		74250000, {
+			0x00, 0xd1, 0x5c, 0x52, 0x90, 0x0d, 0x84, 0x41,
+			0x4f, 0x30, 0x33, 0x65, 0x10, 0xa6, 0x24, 0x80,
+			0x6c, 0xf2, 0x67, 0x00, 0x10, 0x85, 0x30, 0x32,
+			0x60, 0x8f, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
+			0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+			0x00, 0xe0, 0x83, 0x0f, 0x3e, 0xf8, 0x00, 0x00,
+		},
+	}, {
+		78500000, {
+			0x00, 0xd1, 0x62, 0x54, 0x87, 0x01, 0x80, 0x40,
+			0x4f, 0x30, 0x33, 0x65, 0x10, 0x9d, 0x24, 0x80,
+			0x6c, 0xf2, 0x67, 0x00, 0x10, 0x85, 0x30, 0x32,
+			0x60, 0x8f, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
+			0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+			0x00, 0xe0, 0x83, 0x0f, 0x3e, 0xf8, 0x00, 0x00,
+		},
+	}, {
+		80000000, {
+			0x00, 0xd1, 0x64, 0x50, 0x00, 0x00, 0x80, 0x00,
+			0x4f, 0x30, 0x33, 0x65, 0x10, 0x9a, 0x24, 0x80,
+			0x6c, 0xf2, 0x67, 0x00, 0x10, 0x85, 0x30, 0x32,
+			0x60, 0x8f, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
+			0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+			0x00, 0xe0, 0x83, 0x0f, 0x3e, 0xf8, 0x00, 0x00,
+		},
+	}, {
+		82000000, {
+			0x00, 0xd1, 0x66, 0x54, 0x82, 0x01, 0x88, 0x45,
+			0x4f, 0x30, 0x33, 0x65, 0x10, 0x96, 0x24, 0x80,
+			0x6c, 0xf2, 0x67, 0x00, 0x10, 0x85, 0x30, 0x32,
+			0x60, 0x8f, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
+			0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+			0x00, 0xe0, 0x83, 0x0f, 0x3e, 0xf8, 0x00, 0x00,
+		},
+	}, {
+		82500000, {
+			0x00, 0xd1, 0x67, 0x54, 0x88, 0x01, 0x90, 0x49,
+			0x4f, 0x30, 0x33, 0x65, 0x10, 0x95, 0x24, 0x80,
+			0x6c, 0xf2, 0x67, 0x00, 0x10, 0x85, 0x30, 0x32,
+			0x60, 0x8f, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
+			0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+			0x00, 0xe0, 0x83, 0x0f, 0x3e, 0xf8, 0x00, 0x00,
+		},
+	}, {
+		89000000, {
+			0x00, 0xd1, 0x70, 0x54, 0x84, 0x83, 0x80, 0x40,
+			0x4f, 0x30, 0x33, 0x65, 0x10, 0x8b, 0x24, 0x80,
+			0x6c, 0xf2, 0x67, 0x00, 0x10, 0x85, 0x30, 0x32,
+			0x60, 0x8f, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
+			0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+			0x00, 0xe0, 0x83, 0x0f, 0x3e, 0xf8, 0x00, 0x00,
+		},
+	}, {
+		90000000, {
+			0x00, 0xd1, 0x70, 0x54, 0x82, 0x01, 0x80, 0x40,
+			0x4f, 0x30, 0x33, 0x65, 0x10, 0x89, 0x24, 0x80,
+			0x6c, 0xf2, 0x67, 0x00, 0x10, 0x85, 0x30, 0x32,
+			0x60, 0x8f, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
+			0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+			0x00, 0xe0, 0x83, 0x0f, 0x3e, 0xf8, 0x00, 0x00,
+		},
+	}, {
+		94000000, {
+			0x00, 0xd1, 0x4e, 0x32, 0xa7, 0x10, 0x80, 0x40,
+			0x4f, 0x30, 0x33, 0x65, 0x10, 0x83, 0x24, 0x80,
+			0x6c, 0xf2, 0x67, 0x00, 0x10, 0x83, 0x30, 0x32,
+			0x60, 0x8f, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
+			0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+			0x00, 0xe0, 0x83, 0x0f, 0x3e, 0xf8, 0x00, 0x00,
+		},
+	}, {
+		95000000, {
+			0x00, 0xd1, 0x50, 0x31, 0x86, 0x85, 0x80, 0x40,
+			0x4f, 0x30, 0x33, 0x65, 0x10, 0x82, 0x24, 0x80,
+			0x6c, 0xf2, 0x67, 0x00, 0x10, 0x83, 0x30, 0x32,
+			0x60, 0x8f, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
+			0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+			0x00, 0xe0, 0x83, 0x0f, 0x3e, 0xf8, 0x00, 0x00,
+		},
+	}, {
+		98901099, {
+			0x00, 0xd1, 0x52, 0x3a, 0xdb, 0x4c, 0x88, 0x47,
+			0x4f, 0x30, 0x33, 0x65, 0x10, 0x7d, 0x24, 0x80,
+			0x6c, 0xf2, 0x67, 0x00, 0x10, 0x83, 0x30, 0x32,
+			0x60, 0x8f, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
+			0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+			0x00, 0xe0, 0x83, 0x0f, 0x3e, 0xf8, 0x00, 0x00,
+		},
+	}, {
+		99000000, {
+			0x00, 0xd1, 0x52, 0x32, 0x82, 0x01, 0x88, 0x47,
+			0x4f, 0x30, 0x33, 0x65, 0x10, 0x7d, 0x24, 0x80,
+			0x6c, 0xf2, 0x67, 0x00, 0x10, 0x83, 0x30, 0x32,
+			0x60, 0x8f, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
+			0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+			0x00, 0xe0, 0x83, 0x0f, 0x3e, 0xf8, 0x00, 0x00,
+		},
+	}, {
+		100699300, {
+			0x00, 0xd1, 0x54, 0x3c, 0xc3, 0x8f, 0x80, 0x40,
+			0x4f, 0x30, 0x33, 0x65, 0x20, 0xf5, 0x24, 0x80,
+			0x6c, 0xf2, 0x67, 0x00, 0x10, 0x83, 0x30, 0x32,
+			0x60, 0x8f, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
+			0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+			0x00, 0xe0, 0x83, 0x0f, 0x3e, 0xf8, 0x00, 0x00,
+		},
+	}, {
+		100800000, {
+			0x00, 0xd1, 0x54, 0x30, 0x00, 0x00, 0x80, 0x00,
+			0x4f, 0x30, 0x33, 0x65, 0x20, 0xf4, 0x24, 0x80,
+			0x6c, 0xf2, 0x67, 0x00, 0x10, 0x83, 0x30, 0x32,
+			0x60, 0x8f, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
+			0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+			0x00, 0xe0, 0x83, 0x0f, 0x3e, 0xf8, 0x00, 0x00,
+		},
+	}, {
+		102500000, {
+			0x00, 0xd1, 0x55, 0x32, 0x8c, 0x05, 0x90, 0x4b,
+			0x4f, 0x30, 0x33, 0x65, 0x20, 0xf0, 0x24, 0x80,
+			0x6c, 0xf2, 0x67, 0x00, 0x10, 0x83, 0x30, 0x32,
+			0x60, 0x8f, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
+			0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+			0x00, 0xe0, 0x83, 0x0f, 0x3e, 0xf8, 0x00, 0x00,
+		},
+	}, {
+		104750000, {
+			0x00, 0xd1, 0x57, 0x32, 0x98, 0x07, 0x90, 0x49,
+			0x4f, 0x30, 0x33, 0x65, 0x20, 0xeb, 0x24, 0x80,
+			0x6c, 0xf2, 0x67, 0x00, 0x10, 0x83, 0x30, 0x32,
+			0x60, 0x8f, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
+			0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+			0x00, 0xe0, 0x83, 0x0f, 0x3e, 0xf8, 0x00, 0x00,
+		},
+	}, {
+		106500000, {
+			0x00, 0xd1, 0x58, 0x32, 0x84, 0x03, 0x82, 0x41,
+			0x4f, 0x30, 0x33, 0x65, 0x20, 0xe7, 0x24, 0x80,
+			0x6c, 0xf2, 0x67, 0x00, 0x10, 0x83, 0x30, 0x32,
+			0x60, 0x8f, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
+			0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+			0x00, 0xe0, 0x83, 0x0f, 0x3e, 0xf8, 0x00, 0x00,
+		},
+	}, {
+		107000000, {
+			0x00, 0xd1, 0x5a, 0x32, 0x89, 0x88, 0x80, 0x40,
+			0x4f, 0x30, 0x33, 0x65, 0x20, 0xe6, 0x24, 0x80,
+			0x6c, 0xf2, 0x67, 0x00, 0x10, 0x83, 0x30, 0x32,
+			0x60, 0x8f, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
+			0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+			0x00, 0xe0, 0x83, 0x0f, 0x3e, 0xf8, 0x00, 0x00,
+		},
+	}, {
+		108000000, {
+			0x00, 0xd1, 0x5a, 0x30, 0x00, 0x00, 0x80, 0x00,
+			0x4f, 0x30, 0x33, 0x65, 0x20, 0xe4, 0x24, 0x80,
+			0x6c, 0xf2, 0x67, 0x00, 0x10, 0x83, 0x30, 0x32,
+			0x60, 0x8f, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
+			0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+			0x00, 0xe0, 0x83, 0x0f, 0x3e, 0xf8, 0x00, 0x00,
+		},
+	}, {
+		108108000, {
+			0x00, 0xd1, 0x5a, 0x32, 0xfd, 0x0c, 0x80, 0x40,
+			0x4f, 0x30, 0x33, 0x65, 0x20, 0xe4, 0x24, 0x80,
+			0x6c, 0xf2, 0x67, 0x00, 0x10, 0x83, 0x30, 0x32,
+			0x60, 0x8f, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
+			0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+			0x00, 0xe0, 0x83, 0x0f, 0x3e, 0xf8, 0x00, 0x00,
+		},
+	}, {
+		118000000, {
+			0x00, 0xd1, 0x62, 0x34, 0x95, 0x08, 0x80, 0x40,
+			0x4f, 0x30, 0x33, 0x65, 0x20, 0xd1, 0x24, 0x80,
+			0x6c, 0xf2, 0x67, 0x00, 0x10, 0x83, 0x30, 0x32,
+			0x60, 0x8f, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
+			0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+			0x00, 0xe0, 0x83, 0x0f, 0x3e, 0xf8, 0x00, 0x00,
+		},
+	}, {
+		118800000, {
+			0x00, 0xd1, 0x63, 0x30, 0x00, 0x00, 0x80, 0x00,
+			0x4f, 0x30, 0x33, 0x65, 0x20, 0xcf, 0x24, 0x80,
+			0x6c, 0xf2, 0x67, 0x00, 0x10, 0x83, 0x30, 0x32,
+			0x60, 0x8f, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
+			0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+			0x00, 0xe0, 0x83, 0x0f, 0x3e, 0xf8, 0x00, 0x00,
+		},
+	}, {
+		123000000, {
+			0x00, 0xd1, 0x66, 0x34, 0x82, 0x01, 0x88, 0x45,
+			0x4f, 0x30, 0x33, 0x65, 0x20, 0xc8, 0x24, 0x80,
+			0x6c, 0xf2, 0x67, 0x00, 0x10, 0x83, 0x30, 0x32,
+			0x60, 0x8f, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
+			0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+			0x00, 0xe0, 0x83, 0x0f, 0x3e, 0xf8, 0x00, 0x00,
+		},
+	}, {
+		127000000, {
+			0x00, 0xd1, 0x69, 0x34, 0x89, 0x08, 0x80, 0x40,
+			0x4f, 0x30, 0x33, 0x65, 0x20, 0xc2, 0x24, 0x80,
+			0x6c, 0xf2, 0x67, 0x00, 0x10, 0x83, 0x30, 0x32,
+			0x60, 0x8f, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
+			0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+			0x00, 0xe0, 0x83, 0x0f, 0x3e, 0xf8, 0x00, 0x00,
+		},
+	}, {
+		135000000, {
+			0x00, 0xd1, 0x70, 0x34, 0x82, 0x01, 0x80, 0x40,
+			0x4f, 0x30, 0x33, 0x65, 0x20, 0xb7, 0x24, 0x80,
+			0x6c, 0xf2, 0x67, 0x00, 0x10, 0x83, 0x30, 0x32,
+			0x60, 0x8f, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
+			0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+			0x00, 0xe0, 0x83, 0x0f, 0x3e, 0xf8, 0x00, 0x00,
+		},
+	}, {
+		135580000, {
+			0x00, 0xd1, 0x71, 0x39, 0xe9, 0x82, 0x9c, 0x5b,
+			0x4f, 0x30, 0x33, 0x65, 0x20, 0xb6, 0x24, 0x80,
+			0x6c, 0xf2, 0x67, 0x00, 0x10, 0x83, 0x30, 0x32,
+			0x60, 0x8f, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
+			0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+			0x00, 0xe0, 0x83, 0x0f, 0x3e, 0xf8, 0x00, 0x00,
+		},
+	}, {
+		137520000, {
+			0x00, 0xd1, 0x72, 0x38, 0x99, 0x10, 0x85, 0x41,
+			0x4f, 0x30, 0x33, 0x65, 0x20, 0xb3, 0x24, 0x80,
+			0x6c, 0xf2, 0x67, 0x00, 0x10, 0x83, 0x30, 0x32,
+			0x60, 0x8f, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
+			0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+			0x00, 0xe0, 0x83, 0x0f, 0x3e, 0xf8, 0x00, 0x00,
+		},
+	}, {
+		138750000, {
+			0x00, 0xd1, 0x73, 0x35, 0x88, 0x05, 0x90, 0x4d,
+			0x4f, 0x30, 0x33, 0x65, 0x20, 0xb2, 0x24, 0x80,
+			0x6c, 0xf2, 0x67, 0x00, 0x10, 0x83, 0x30, 0x32,
+			0x60, 0x8f, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
+			0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+			0x00, 0xe0, 0x83, 0x0f, 0x3e, 0xf8, 0x00, 0x00,
+		},
+	}, {
+		140000000, {
+			0x00, 0xd1, 0x75, 0x36, 0xa7, 0x90, 0x80, 0x40,
+			0x4f, 0x30, 0x33, 0x65, 0x20, 0xb0, 0x24, 0x80,
+			0x6c, 0xf2, 0x67, 0x00, 0x10, 0x83, 0x30, 0x32,
+			0x60, 0x8f, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
+			0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+			0x00, 0xe0, 0x83, 0x0f, 0x3e, 0xf8, 0x00, 0x00,
+		},
+	}, {
+		144000000, {
+			0x00, 0xd1, 0x78, 0x30, 0x00, 0x00, 0x80, 0x00,
+			0x4f, 0x30, 0x33, 0x65, 0x20, 0xab, 0x24, 0x80,
+			0x6c, 0xf2, 0x67, 0x00, 0x10, 0x83, 0x30, 0x32,
+			0x60, 0x8f, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
+			0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+			0x00, 0xe0, 0x83, 0x0f, 0x3e, 0xf8, 0x00, 0x00,
+		},
+	}, {
+		148352000, {
+			0x00, 0xd1, 0x7b, 0x35, 0xdb, 0x39, 0x90, 0x45,
+			0x4f, 0x30, 0x33, 0x65, 0x20, 0xa6, 0x24, 0x80,
+			0x6c, 0xf2, 0x67, 0x00, 0x10, 0x83, 0x30, 0x32,
+			0x60, 0x8f, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
+			0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+			0x00, 0xe0, 0x83, 0x0f, 0x3e, 0xf8, 0x00, 0x00,
+		},
+	}, {
+		148500000, {
+			0x00, 0xd1, 0x7b, 0x35, 0x84, 0x03, 0x90, 0x45,
+			0x4f, 0x30, 0x33, 0x65, 0x20, 0xa6, 0x24, 0x80,
+			0x6c, 0xf2, 0x67, 0x00, 0x10, 0x83, 0x30, 0x32,
+			0x60, 0x8f, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
+			0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+			0x00, 0xe0, 0x83, 0x0f, 0x3e, 0xf8, 0x00, 0x00,
+		},
+	}, {
+		154000000, {
+			0x00, 0xd1, 0x40, 0x18, 0x83, 0x01, 0x00, 0x40,
+			0x4f, 0x30, 0x33, 0x65, 0x20, 0xa0, 0x24, 0x80,
+			0x6c, 0xf2, 0x67, 0x00, 0x10, 0x81, 0x30, 0x32,
+			0x60, 0x8f, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
+			0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+			0x00, 0xe0, 0x83, 0x0f, 0x3e, 0xf8, 0x00, 0x00,
+		},
+	}, {
+		157000000, {
+			0x00, 0xd1, 0x41, 0x11, 0xa7, 0x14, 0x80, 0x40,
+			0x4f, 0x30, 0x33, 0x65, 0x20, 0x9d, 0x24, 0x80,
+			0x6c, 0xf2, 0x67, 0x00, 0x10, 0x81, 0x30, 0x32,
+			0x60, 0x8f, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
+			0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+			0x00, 0xe0, 0x83, 0x0f, 0x3e, 0xf8, 0x00, 0x00,
+		},
+	}, {
+		160000000, {
+			0x00, 0xd1, 0x42, 0x12, 0xa1, 0x20, 0x80, 0x40,
+			0x4f, 0x30, 0x33, 0x65, 0x20, 0x9a, 0x24, 0x80,
+			0x6c, 0xf2, 0x67, 0x00, 0x10, 0x81, 0x30, 0x32,
+			0x60, 0x8f, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
+			0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+			0x00, 0xe0, 0x83, 0x0f, 0x3e, 0xf8, 0x00, 0x00,
+		},
+	}, {
+		162000000, {
+			0x00, 0xd1, 0x43, 0x18, 0x8b, 0x08, 0x96, 0x55,
+			0x4f, 0x30, 0x33, 0x65, 0x20, 0x98, 0x24, 0x80,
+			0x6c, 0xf2, 0x67, 0x00, 0x10, 0x81, 0x30, 0x32,
+			0x60, 0x8f, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
+			0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+			0x00, 0xe0, 0x83, 0x0f, 0x3e, 0xf8, 0x00, 0x00,
+		},
+	}, {
+		164000000, {
+			0x00, 0xd1, 0x45, 0x11, 0x83, 0x82, 0x90, 0x4b,
+			0x4f, 0x30, 0x33, 0x65, 0x20, 0x96, 0x24, 0x80,
+			0x6c, 0xf2, 0x67, 0x00, 0x10, 0x81, 0x30, 0x32,
+			0x60, 0x8f, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
+			0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+			0x00, 0xe0, 0x83, 0x0f, 0x3e, 0xf8, 0x00, 0x00,
+		},
+	}, {
+		165000000, {
+			0x00, 0xd1, 0x45, 0x11, 0x84, 0x81, 0x90, 0x4b,
+			0x4f, 0x30, 0x33, 0x65, 0x20, 0x95, 0x24, 0x80,
+			0x6c, 0xf2, 0x67, 0x00, 0x10, 0x81, 0x30, 0x32,
+			0x60, 0x8f, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
+			0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+			0x00, 0xe0, 0x83, 0x0f, 0x3e, 0xf8, 0x00, 0x00,
+		},
+	}, {
+		180000000, {
+			0x00, 0xd1, 0x4b, 0x10, 0x00, 0x00, 0x80, 0x00,
+			0x4f, 0x30, 0x33, 0x65, 0x20, 0x89, 0x24, 0x80,
+			0x6c, 0xf2, 0x67, 0x00, 0x10, 0x81, 0x30, 0x32,
+			0x60, 0x8f, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
+			0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+			0x00, 0xe0, 0x83, 0x0f, 0x3e, 0xf8, 0x00, 0x00,
+		},
+	}, {
+		185625000, {
+			0x00, 0xd1, 0x4e, 0x12, 0x9a, 0x95, 0x80, 0x40,
+			0x4f, 0x30, 0x33, 0x65, 0x20, 0x85, 0x24, 0x80,
+			0x6c, 0xf2, 0x67, 0x00, 0x10, 0x81, 0x30, 0x32,
+			0x60, 0x8f, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
+			0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+			0x00, 0xe0, 0x83, 0x0f, 0x3e, 0xf8, 0x00, 0x00,
+		},
+	}, {
+		188000000, {
+			0x00, 0xd1, 0x4e, 0x12, 0xa7, 0x10, 0x80, 0x40,
+			0x4f, 0x30, 0x33, 0x65, 0x20, 0x83, 0x24, 0x80,
+			0x6c, 0xf2, 0x67, 0x00, 0x10, 0x81, 0x30, 0x32,
+			0x60, 0x8f, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
+			0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+			0x00, 0xe0, 0x83, 0x0f, 0x3e, 0xf8, 0x00, 0x00,
+		},
+	}, {
+		198000000, {
+			0x00, 0xd1, 0x52, 0x12, 0x82, 0x01, 0x88, 0x47,
+			0x4f, 0x30, 0x33, 0x65, 0x20, 0x7d, 0x24, 0x80,
+			0x6c, 0xf2, 0x67, 0x00, 0x10, 0x81, 0x30, 0x32,
+			0x60, 0x8f, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
+			0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+			0x00, 0xe0, 0x83, 0x0f, 0x3e, 0xf8, 0x00, 0x00,
+		},
+	}, {
+		205000000, {
+			0x00, 0xd1, 0x55, 0x12, 0x8c, 0x05, 0x90, 0x4b,
+			0x4f, 0x30, 0x33, 0x65, 0x30, 0xf0, 0x24, 0x80,
+			0x6c, 0xf2, 0x67, 0x00, 0x10, 0x81, 0x30, 0x32,
+			0x60, 0x8f, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
+			0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+			0x00, 0xe0, 0x83, 0x0f, 0x3e, 0xf8, 0x00, 0x00,
+		},
+	}, {
+		209500000, {
+			0x00, 0xd1, 0x57, 0x12, 0x98, 0x07, 0x90, 0x49,
+			0x4f, 0x30, 0x33, 0x65, 0x30, 0xeb, 0x24, 0x80,
+			0x6c, 0xf2, 0x67, 0x00, 0x10, 0x81, 0x30, 0x32,
+			0x60, 0x8f, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
+			0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+			0x00, 0xe0, 0x83, 0x0f, 0x3e, 0xf8, 0x00, 0x00,
+		},
+	}, {
+		213000000, {
+			0x00, 0xd1, 0x58, 0x12, 0x84, 0x03, 0x82, 0x41,
+			0x4f, 0x30, 0x33, 0x65, 0x30, 0xe7, 0x24, 0x80,
+			0x6c, 0xf2, 0x67, 0x00, 0x10, 0x81, 0x30, 0x32,
+			0x60, 0x8f, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
+			0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+			0x00, 0xe0, 0x83, 0x0f, 0x3e, 0xf8, 0x00, 0x00,
+		},
+	}, {
+		216000000, {
+			0x00, 0xd1, 0x5a, 0x10, 0x00, 0x00, 0x80, 0x00,
+			0x4f, 0x30, 0x33, 0x65, 0x30, 0xe4, 0x24, 0x80,
+			0x6c, 0xf2, 0x67, 0x00, 0x10, 0x81, 0x30, 0x32,
+			0x60, 0x8f, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
+			0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+			0x00, 0xe0, 0x83, 0x0f, 0x3e, 0xf8, 0x00, 0x00,
+		},
+	}, {
+		216216000, {
+			0x00, 0xd1, 0x5a, 0x12, 0xfd, 0x0c, 0x80, 0x40,
+			0x4f, 0x30, 0x33, 0x65, 0x30, 0xe4, 0x24, 0x80,
+			0x6c, 0xf2, 0x67, 0x00, 0x10, 0x81, 0x30, 0x32,
+			0x60, 0x8f, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
+			0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+			0x00, 0xe0, 0x83, 0x0f, 0x3e, 0xf8, 0x00, 0x00,
+		},
+	}, {
+		237600000, {
+			0x00, 0xd1, 0x63, 0x10, 0x00, 0x00, 0x80, 0x00,
+			0x4f, 0x30, 0x33, 0x65, 0x30, 0xcf, 0x24, 0x80,
+			0x6c, 0xf2, 0x67, 0x00, 0x10, 0x81, 0x30, 0x32,
+			0x60, 0x8f, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
+			0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+			0x00, 0xe0, 0x83, 0x0f, 0x3e, 0xf8, 0x00, 0x00,
+		},
+	}, {
+		254000000, {
+			0x00, 0xd1, 0x69, 0x14, 0x89, 0x08, 0x80, 0x40,
+			0x4f, 0x30, 0x33, 0x65, 0x30, 0xc2, 0x24, 0x80,
+			0x6c, 0xf2, 0x67, 0x00, 0x10, 0x81, 0x30, 0x32,
+			0x60, 0x8f, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
+			0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+			0x00, 0xe0, 0x83, 0x0f, 0x3e, 0xf8, 0x00, 0x00,
+		},
+	}, {
+		277500000, {
+			0x00, 0xd1, 0x73, 0x15, 0x88, 0x05, 0x90, 0x4d,
+			0x4f, 0x30, 0x33, 0x65, 0x30, 0xb2, 0x24, 0x80,
+			0x6c, 0xf2, 0x67, 0x00, 0x10, 0x81, 0x30, 0x32,
+			0x60, 0x8f, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
+			0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+			0x00, 0xe0, 0x83, 0x0f, 0x3e, 0xf8, 0x00, 0x00,
+		},
+	}, {
+		288000000, {
+			0x00, 0xd1, 0x78, 0x10, 0x00, 0x00, 0x80, 0x00,
+			0x4f, 0x30, 0x33, 0x65, 0x30, 0xab, 0x24, 0x80,
+			0x6c, 0xf2, 0x67, 0x00, 0x10, 0x81, 0x30, 0x32,
+			0x60, 0x8f, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
+			0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+			0x00, 0xe0, 0x83, 0x0f, 0x3e, 0xf8, 0x00, 0x00,
+		},
+	}, {
+		297000000, {
+			0x00, 0xd1, 0x7b, 0x15, 0x84, 0x03, 0x90, 0x45,
+			0x4f, 0x30, 0x33, 0x65, 0x30, 0xa6, 0x24, 0x80,
+			0x6c, 0xf2, 0x67, 0x00, 0x10, 0x81, 0x30, 0x32,
+			0x60, 0x8f, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
+			0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+			0x00, 0xe0, 0x83, 0x0f, 0x3e, 0xf8, 0x00, 0x00,
+		},
+	},
+};
+
+struct fsl_samsung_hdmi_phy {
+	struct device *dev;
+	void __iomem *regs;
+	struct clk *apbclk;
+	struct clk *refclk;
+
+	/* clk provider */
+	struct clk_hw hw;
+	const struct phy_config *cur_cfg;
+};
+
+static inline struct fsl_samsung_hdmi_phy *
+to_fsl_samsung_hdmi_phy(struct clk_hw *hw)
+{
+	return container_of(hw, struct fsl_samsung_hdmi_phy, hw);
+}
+
+static int fsl_samsung_hdmi_phy_configure(struct fsl_samsung_hdmi_phy *phy,
+					  const struct phy_config *cfg)
+{
+	int i, ret;
+	u8 val;
+
+	/* HDMI PHY init */
+	writeb(REG33_FIX_DA, phy->regs + PHY_REG_33);
+
+	for (i = 0; i < PHY_PLL_REGS_NUM; i++)
+		writeb(cfg->regs[i], phy->regs + i * 4);
+
+	writeb(REG33_FIX_DA | REG33_MODE_SET_DONE, phy->regs + PHY_REG_33);
+
+	ret = readb_poll_timeout(phy->regs + PHY_REG_34, val,
+					 val & REG34_PLL_LOCK,
+					 50, 20000);
+	if (ret)
+		dev_err(phy->dev, "PLL failed to lock\n");
+
+	return ret;
+}
+
+static unsigned long phy_clk_recalc_rate(struct clk_hw *hw,
+					 unsigned long parent_rate)
+{
+	struct fsl_samsung_hdmi_phy *phy = to_fsl_samsung_hdmi_phy(hw);
+
+	if (!phy->cur_cfg)
+		return 74250000;
+
+	return phy->cur_cfg->clk_rate;
+}
+
+static long phy_clk_round_rate(struct clk_hw *hw,
+			       unsigned long rate, unsigned long *parent_rate)
+{
+	int i;
+
+	for (i = ARRAY_SIZE(phy_pll_cfg) - 1; i >= 0; i--)
+		if (phy_pll_cfg[i].clk_rate <= rate)
+			return phy_pll_cfg[i].clk_rate;
+
+	return -EINVAL;
+}
+
+static int phy_clk_set_rate(struct clk_hw *hw,
+			    unsigned long rate, unsigned long parent_rate)
+{
+	struct fsl_samsung_hdmi_phy *phy = to_fsl_samsung_hdmi_phy(hw);
+	int i;
+
+	for (i = ARRAY_SIZE(phy_pll_cfg) - 1; i >= 0; i--)
+		if (phy_pll_cfg[i].clk_rate <= rate)
+			break;
+
+	if (i < 0)
+		return -EINVAL;
+
+	phy->cur_cfg = &phy_pll_cfg[i];
+
+	return fsl_samsung_hdmi_phy_configure(phy, phy->cur_cfg);
+}
+
+static const struct clk_ops phy_clk_ops = {
+	.recalc_rate = phy_clk_recalc_rate,
+	.round_rate = phy_clk_round_rate,
+	.set_rate = phy_clk_set_rate,
+};
+
+static int phy_clk_register(struct fsl_samsung_hdmi_phy *phy)
+{
+	struct device *dev = phy->dev;
+	struct device_node *np = dev->of_node;
+	struct clk_init_data init;
+	const char *parent_name;
+	struct clk *phyclk;
+	int ret;
+
+	parent_name = __clk_get_name(phy->refclk);
+
+	init.parent_names = &parent_name;
+	init.num_parents = 1;
+	init.flags = 0;
+	init.name = "hdmi_pclk";
+	init.ops = &phy_clk_ops;
+
+	phy->hw.init = &init;
+
+	phyclk = devm_clk_register(dev, &phy->hw);
+	if (IS_ERR(phyclk))
+		return dev_err_probe(dev, PTR_ERR(phyclk),
+				     "failed to register clock\n");
+
+	ret = of_clk_add_provider(np, of_clk_src_simple_get, phyclk);
+	if (ret)
+		return dev_err_probe(dev, ret,
+				     "failed to register clock provider\n");
+
+	return 0;
+}
+
+static int fsl_samsung_hdmi_phy_probe(struct platform_device *pdev)
+{
+	struct fsl_samsung_hdmi_phy *phy;
+	int ret;
+
+	phy = devm_kzalloc(&pdev->dev, sizeof(*phy), GFP_KERNEL);
+	if (!phy)
+		return -ENOMEM;
+
+	platform_set_drvdata(pdev, phy);
+	phy->dev = &pdev->dev;
+
+	phy->regs = devm_platform_ioremap_resource(pdev, 0);
+	if (IS_ERR(phy->regs))
+		return PTR_ERR(phy->regs);
+
+	phy->apbclk = devm_clk_get(phy->dev, "apb");
+	if (IS_ERR(phy->apbclk))
+		return dev_err_probe(phy->dev, PTR_ERR(phy->apbclk),
+				     "failed to get apb clk\n");
+
+	phy->refclk = devm_clk_get(phy->dev, "ref");
+	if (IS_ERR(phy->refclk))
+		return dev_err_probe(phy->dev, PTR_ERR(phy->refclk),
+				     "failed to get ref clk\n");
+
+	ret = clk_prepare_enable(phy->apbclk);
+	if (ret) {
+		dev_err(phy->dev, "failed to enable apbclk\n");
+		return ret;
+	}
+
+	pm_runtime_get_noresume(phy->dev);
+	pm_runtime_set_active(phy->dev);
+	pm_runtime_enable(phy->dev);
+
+	ret = phy_clk_register(phy);
+	if (ret) {
+		dev_err(&pdev->dev, "register clk failed\n");
+		goto register_clk_failed;
+	}
+
+	pm_runtime_put(phy->dev);
+
+	return 0;
+
+register_clk_failed:
+	clk_disable_unprepare(phy->apbclk);
+
+	return ret;
+}
+
+static int fsl_samsung_hdmi_phy_remove(struct platform_device *pdev)
+{
+	of_clk_del_provider(pdev->dev.of_node);
+
+	return 0;
+}
+
+#ifdef CONFIG_PM
+static int fsl_samsung_hdmi_phy_suspend(struct device *dev)
+{
+	struct fsl_samsung_hdmi_phy *phy = dev_get_drvdata(dev);
+
+	clk_disable_unprepare(phy->apbclk);
+
+	return 0;
+}
+
+static int fsl_samsung_hdmi_phy_resume(struct device *dev)
+{
+	struct fsl_samsung_hdmi_phy *phy = dev_get_drvdata(dev);
+	int ret = 0;
+
+	ret = clk_prepare_enable(phy->apbclk);
+	if (ret) {
+		dev_err(phy->dev, "failed to enable apbclk\n");
+		return ret;
+	}
+
+	if (phy->cur_cfg)
+		ret = fsl_samsung_hdmi_phy_configure(phy, phy->cur_cfg);
+
+	return ret;
+
+}
+#endif
+
+static const struct dev_pm_ops fsl_samsung_hdmi_phy_pm_ops = {
+	SET_RUNTIME_PM_OPS(fsl_samsung_hdmi_phy_suspend,
+			   fsl_samsung_hdmi_phy_resume, NULL)
+	SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
+				pm_runtime_force_resume)
+};
+
+static const struct of_device_id fsl_samsung_hdmi_phy_of_match[] = {
+	{
+		.compatible = "fsl,imx8mp-hdmi-phy",
+	}, {
+		/* sentinel */
+	}
+};
+MODULE_DEVICE_TABLE(of, fsl_samsung_hdmi_phy_of_match);
+
+static struct platform_driver fsl_samsung_hdmi_phy_driver = {
+	.probe  = fsl_samsung_hdmi_phy_probe,
+	.remove = fsl_samsung_hdmi_phy_remove,
+	.driver = {
+		.name = "fsl-samsung-hdmi-phy",
+		.of_match_table = fsl_samsung_hdmi_phy_of_match,
+		.pm = &fsl_samsung_hdmi_phy_pm_ops,
+	},
+};
+module_platform_driver(fsl_samsung_hdmi_phy_driver);
+
+MODULE_AUTHOR("Sandor Yu <Sandor.yu@nxp.com>");
+MODULE_DESCRIPTION("SAMSUNG HDMI 2.0 Transmitter PHY Driver");
+MODULE_LICENSE("GPL v2");
-- 
2.43.0

[PATCH V8 03/12] dt-bindings: soc: imx: add missing clock and power-domains to imx8mp-hdmi-blk-ctrl

[Adam Ford]

Per guidance from the NXP downstream kernel, if the clock is
disabled before HDMI/LCDIF probe, LCDIF will not get pixel
clock from HDMI PHY and throw an error:

[CRTC:39:crtc-2] vblank wait timed out
    WARNING: CPU: 2 PID: 9 at drivers/gpu/drm/drm_atomic_helper.c:
        1634 drm_atomic_helper_wait_for_vblanks.part.0+0x23c/0x260

Fix this by adding the fdcc clock to the hdmi_blk_ctrl.  This
should be safe, since neither this power domain nor the dependent
HDMI and LCDIF drivers been enabled or added to the SoC device
tree yet.

According to Sandor Yu from NXP, "the FDCC clock is not for HDMITX
in desgin, but it is part of HDMI domain that needed by HDMITX.
So I think it is reasonable added it to the power domain driver."

The driver also supports two power domains which are missing from the binding
that also fix an issue with resuming from suspend.

Signed-off-by: Adam Ford <aford173@gmail.com>
---
V2:  Update commit message to both show error and give a bit more
     background.
     Add missing power domains hdcp and hdrv as pointed out by Marek Vasut
---
 .../soc/imx/fsl,imx8mp-hdmi-blk-ctrl.yaml     | 22 ++++++++++++-------
 1 file changed, 14 insertions(+), 8 deletions(-)

diff --git a/Documentation/devicetree/bindings/soc/imx/fsl,imx8mp-hdmi-blk-ctrl.yaml b/Documentation/devicetree/bindings/soc/imx/fsl,imx8mp-hdmi-blk-ctrl.yaml
index 1be4ce2a45e8..bd1cdaa4f54b 100644
--- a/Documentation/devicetree/bindings/soc/imx/fsl,imx8mp-hdmi-blk-ctrl.yaml
+++ b/Documentation/devicetree/bindings/soc/imx/fsl,imx8mp-hdmi-blk-ctrl.yaml
@@ -27,8 +27,8 @@ properties:
     const: 1
 
   power-domains:
-    minItems: 8
-    maxItems: 8
+    minItems: 10
+    maxItems: 10
 
   power-domain-names:
     items:
@@ -40,10 +40,12 @@ properties:
       - const: trng
       - const: hdmi-tx
       - const: hdmi-tx-phy
+      - const: hdcp
+      - const: hrv
 
   clocks:
-    minItems: 4
-    maxItems: 4
+    minItems: 5
+    maxItems: 5
 
   clock-names:
     items:
@@ -51,6 +53,7 @@ properties:
       - const: axi
       - const: ref_266m
       - const: ref_24m
+      - const: fdcc
 
   interconnects:
     maxItems: 3
@@ -82,12 +85,15 @@ examples:
         clocks = <&clk IMX8MP_CLK_HDMI_APB>,
                  <&clk IMX8MP_CLK_HDMI_ROOT>,
                  <&clk IMX8MP_CLK_HDMI_REF_266M>,
-                 <&clk IMX8MP_CLK_HDMI_24M>;
-        clock-names = "apb", "axi", "ref_266m", "ref_24m";
+                 <&clk IMX8MP_CLK_HDMI_24M>,
+                 <&clk IMX8MP_CLK_HDMI_FDCC_TST>;
+        clock-names = "apb", "axi", "ref_266m", "ref_24m", "fdcc";
         power-domains = <&pgc_hdmimix>, <&pgc_hdmimix>, <&pgc_hdmimix>,
                         <&pgc_hdmimix>, <&pgc_hdmimix>, <&pgc_hdmimix>,
-                        <&pgc_hdmimix>, <&pgc_hdmi_phy>;
+                        <&pgc_hdmimix>, <&pgc_hdmi_phy>,
+                        <&pgc_hdmimix>, <&pgc_hdmimix>;
         power-domain-names = "bus", "irqsteer", "lcdif", "pai", "pvi", "trng",
-                             "hdmi-tx", "hdmi-tx-phy";
+                             "hdmi-tx", "hdmi-tx-phy",
+                             "hdcp", "hrv";
         #power-domain-cells = <1>;
     };
-- 
2.43.0

[PATCH V8 04/12] pmdomain: imx8mp-blk-ctrl: imx8mp_blk: Add fdcc clock to hdmimix domain

[Adam Ford]

According to i.MX8MP RM and HDMI ADD, the fdcc clock is part of
hdmi rx verification IP that should not enable for HDMI TX.
But actually if the clock is disabled before HDMI/LCDIF probe,
LCDIF will not get pixel clock from HDMI PHY and print the error
logs:

[CRTC:39:crtc-2] vblank wait timed out
WARNING: CPU: 2 PID: 9 at drivers/gpu/drm/drm_atomic_helper.c:1634 drm_atomic_helper_wait_for_vblanks.part.0+0x23c/0x260

Add fdcc clock to LCDIF and HDMI TX power domains to fix the issue.

Signed-off-by: Adam Ford <aford173@gmail.com>
Reviewed-by: Jacky Bai <ping.bai@nxp.com>
Signed-off-by: Sandor Yu <Sandor.yu@nxp.com>
---
V2:  No Change
---
 drivers/pmdomain/imx/imx8mp-blk-ctrl.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/pmdomain/imx/imx8mp-blk-ctrl.c b/drivers/pmdomain/imx/imx8mp-blk-ctrl.c
index e488cf79b800..77e889165eed 100644
--- a/drivers/pmdomain/imx/imx8mp-blk-ctrl.c
+++ b/drivers/pmdomain/imx/imx8mp-blk-ctrl.c
@@ -55,7 +55,7 @@ struct imx8mp_blk_ctrl_domain_data {
 	const char *gpc_name;
 };
 
-#define DOMAIN_MAX_CLKS 2
+#define DOMAIN_MAX_CLKS 3
 #define DOMAIN_MAX_PATHS 3
 
 struct imx8mp_blk_ctrl_domain {
@@ -457,8 +457,8 @@ static const struct imx8mp_blk_ctrl_domain_data imx8mp_hdmi_domain_data[] = {
 	},
 	[IMX8MP_HDMIBLK_PD_LCDIF] = {
 		.name = "hdmiblk-lcdif",
-		.clk_names = (const char *[]){ "axi", "apb" },
-		.num_clks = 2,
+		.clk_names = (const char *[]){ "axi", "apb", "fdcc" },
+		.num_clks = 3,
 		.gpc_name = "lcdif",
 		.path_names = (const char *[]){"lcdif-hdmi"},
 		.num_paths = 1,
@@ -483,8 +483,8 @@ static const struct imx8mp_blk_ctrl_domain_data imx8mp_hdmi_domain_data[] = {
 	},
 	[IMX8MP_HDMIBLK_PD_HDMI_TX] = {
 		.name = "hdmiblk-hdmi-tx",
-		.clk_names = (const char *[]){ "apb", "ref_266m" },
-		.num_clks = 2,
+		.clk_names = (const char *[]){ "apb", "ref_266m", "fdcc" },
+		.num_clks = 3,
 		.gpc_name = "hdmi-tx",
 	},
 	[IMX8MP_HDMIBLK_PD_HDMI_TX_PHY] = {
-- 
2.43.0

[PATCH V8 05/12] arm64: dts: imx8mp: add HDMI power-domains

[Adam Ford]

From: Lucas Stach <l.stach@pengutronix.de>

This adds the PGC and HDMI blk-ctrl nodes providing power control for
HDMI subsystem peripherals.

Signed-off-by: Adam Ford <aford173@gmail.com>
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
---
V2:  Add missing power-domains hdcp and hrv
---
 arch/arm64/boot/dts/freescale/imx8mp.dtsi | 38 +++++++++++++++++++++++
 1 file changed, 38 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/imx8mp.dtsi b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
index 76c73daf546b..5c54073de615 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
@@ -836,6 +836,23 @@ pgc_mediamix: power-domain@10 {
 							 <&clk IMX8MP_CLK_MEDIA_APB_ROOT>;
 					};
 
+					pgc_hdmimix: power-domains@14 {
+						#power-domain-cells = <0>;
+						reg = <IMX8MP_POWER_DOMAIN_HDMIMIX>;
+						clocks = <&clk IMX8MP_CLK_HDMI_ROOT>,
+							 <&clk IMX8MP_CLK_HDMI_APB>;
+						assigned-clocks = <&clk IMX8MP_CLK_HDMI_AXI>,
+								  <&clk IMX8MP_CLK_HDMI_APB>;
+						assigned-clock-parents = <&clk IMX8MP_SYS_PLL2_500M>,
+									 <&clk IMX8MP_SYS_PLL1_133M>;
+						assigned-clock-rates = <500000000>, <133000000>;
+					};
+
+					pgc_hdmi_phy: power-domains@15 {
+						#power-domain-cells = <0>;
+						reg = <IMX8MP_POWER_DOMAIN_HDMI_PHY>;
+					};
+
 					pgc_mipi_phy2: power-domain@16 {
 						#power-domain-cells = <0>;
 						reg = <IMX8MP_POWER_DOMAIN_MIPI_PHY2>;
@@ -1361,6 +1378,27 @@ eqos: ethernet@30bf0000 {
 				intf_mode = <&gpr 0x4>;
 				status = "disabled";
 			};
+
+			hdmi_blk_ctrl: blk-ctrl@32fc0000 {
+				compatible = "fsl,imx8mp-hdmi-blk-ctrl", "syscon";
+				reg = <0x32fc0000 0x23c>;
+				clocks = <&clk IMX8MP_CLK_HDMI_APB>,
+					 <&clk IMX8MP_CLK_HDMI_ROOT>,
+					 <&clk IMX8MP_CLK_HDMI_REF_266M>,
+					 <&clk IMX8MP_CLK_HDMI_24M>,
+					 <&clk IMX8MP_CLK_HDMI_FDCC_TST>;
+				clock-names = "apb", "axi", "ref_266m", "ref_24m", "fdcc";
+				power-domains = <&pgc_hdmimix>, <&pgc_hdmimix>,
+						<&pgc_hdmimix>, <&pgc_hdmimix>,
+						<&pgc_hdmimix>, <&pgc_hdmimix>,
+						<&pgc_hdmimix>, <&pgc_hdmi_phy>,
+						<&pgc_hdmimix>, <&pgc_hdmimix>;
+				power-domain-names = "bus", "irqsteer", "lcdif",
+						     "pai", "pvi", "trng",
+						     "hdmi-tx", "hdmi-tx-phy",
+						     "hdcp", "hrv";
+				#power-domain-cells = <1>;
+			};
 		};
 
 		aips5: bus@30c00000 {
-- 
2.43.0

[PATCH V8 06/12] arm64: dts: imx8mp: add HDMI irqsteer

[Adam Ford]

From: Lucas Stach <l.stach@pengutronix.de>

The HDMI irqsteer is a secondary interrupt controller within the HDMI
subsystem that maps all HDMI peripheral IRQs into a single upstream
IRQ line.

Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
---
 arch/arm64/boot/dts/freescale/imx8mp.dtsi | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/imx8mp.dtsi b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
index 5c54073de615..5e51a766f3d9 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
@@ -1399,6 +1399,19 @@ hdmi_blk_ctrl: blk-ctrl@32fc0000 {
 						     "hdcp", "hrv";
 				#power-domain-cells = <1>;
 			};
+
+			irqsteer_hdmi: interrupt-controller@32fc2000 {
+				compatible = "fsl,imx-irqsteer";
+				reg = <0x32fc2000 0x44>;
+				interrupts = <GIC_SPI 43 IRQ_TYPE_LEVEL_HIGH>;
+				interrupt-controller;
+				#interrupt-cells = <1>;
+				fsl,channel = <1>;
+				fsl,num-irqs = <64>;
+				clocks = <&clk IMX8MP_CLK_HDMI_APB>;
+				clock-names = "ipg";
+				power-domains = <&hdmi_blk_ctrl IMX8MP_HDMIBLK_PD_IRQSTEER>;
+			};
 		};
 
 		aips5: bus@30c00000 {
-- 
2.43.0

[PATCH V8 07/12] dt-bindings: display: imx: add binding for i.MX8MP HDMI PVI

[Adam Ford]

From: Lucas Stach <l.stach@pengutronix.de>

Add binding for the i.MX8MP HDMI parallel video interface block.

Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Adam Ford <aford173@gmail.com>
---
V8:  Add interrupt-parent

V7:  No Change

V6:  Add s-o-b message for myself (Adam)

V5:  I tried to help move this along, so I took Lucas' patch and
     attempted to apply fixes based on feedback.  I don't have
     all the history, so apologies for that.
     Removed the pipe character from the Description.
     Increased the register size from 0x40 to 0x44.
---
 .../display/imx/fsl,imx8mp-hdmi-pvi.yaml      | 84 +++++++++++++++++++
 1 file changed, 84 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/imx/fsl,imx8mp-hdmi-pvi.yaml

diff --git a/Documentation/devicetree/bindings/display/imx/fsl,imx8mp-hdmi-pvi.yaml b/Documentation/devicetree/bindings/display/imx/fsl,imx8mp-hdmi-pvi.yaml
new file mode 100644
index 000000000000..56da1636014c
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/imx/fsl,imx8mp-hdmi-pvi.yaml
@@ -0,0 +1,84 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/imx/fsl,imx8mp-hdmi-pvi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX8MP HDMI Parallel Video Interface
+
+maintainers:
+  - Lucas Stach <l.stach@pengutronix.de>
+
+description:
+  The HDMI parallel video interface is a timing and sync generator block in the
+  i.MX8MP SoC, that sits between the video source and the HDMI TX controller.
+
+properties:
+  compatible:
+    const: fsl,imx8mp-hdmi-pvi
+
+  reg:
+    maxItems: 1
+
+  interrupts:
+    maxItems: 1
+
+  power-domains:
+    maxItems: 1
+
+  ports:
+    $ref: /schemas/graph.yaml#/properties/ports
+
+    properties:
+      port@0:
+        $ref: /schemas/graph.yaml#/properties/port
+        description: Input from the LCDIF controller.
+
+      port@1:
+        $ref: /schemas/graph.yaml#/properties/port
+        description: Output to the HDMI TX controller.
+
+    required:
+      - port@0
+      - port@1
+
+required:
+  - compatible
+  - reg
+  - interrupts
+  - power-domains
+  - ports
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/interrupt-controller/irq.h>
+    #include <dt-bindings/power/imx8mp-power.h>
+
+    display-bridge@32fc4000 {
+        compatible = "fsl,imx8mp-hdmi-pvi";
+        reg = <0x32fc4000 0x44>;
+        interrupt-parent = <&irqsteer_hdmi>;
+        interrupts = <12 IRQ_TYPE_LEVEL_HIGH>;
+        power-domains = <&hdmi_blk_ctrl IMX8MP_HDMIBLK_PD_PVI>;
+
+        ports {
+            #address-cells = <1>;
+            #size-cells = <0>;
+
+            port@0 {
+                reg = <0>;
+                pvi_from_lcdif3: endpoint {
+                    remote-endpoint = <&lcdif3_to_pvi>;
+                };
+            };
+
+            port@1 {
+                reg = <1>;
+                pvi_to_hdmi_tx: endpoint {
+                    remote-endpoint = <&hdmi_tx_from_pvi>;
+                };
+            };
+        };
+    };
-- 
2.43.0

[PATCH V8 08/12] drm/bridge: imx: add driver for HDMI TX Parallel Video Interface

[Adam Ford]

From: Lucas Stach <l.stach@pengutronix.de>

This IP block is found in the HDMI subsystem of the i.MX8MP SoC. It has a
full timing generator and can switch between different video sources. On
the i.MX8MP however the only supported source is the LCDIF. The block
just needs to be powered up and told about the polarity of the video
sync signals to act in bypass mode.

Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> (v7)
Tested-by: Marek Vasut <marex@denx.de> (v1)
Tested-by: Luca Ceresoli <luca.ceresoli@bootlin.com> (v7)
Tested-by: Richard Leitner <richard.leitner@skidata.com> (v2)
Tested-by: Frieder Schrempf <frieder.schrempf@kontron.de> (v2)
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> (v3)
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Tested-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Tested-by: Fabio Estevam <festevam@gmail.com>
Signed-off-by: Adam Ford <aford173@gmail.com>
---
V8:  No Change

V7:  Re-do some includes to address build issues after rebasing from
     Linux-next

V6:  No change.

V5:  I (Adam) tried to help move this along, so I took Lucas' patch and
     attempted to apply fixes based on feedback.  I don't have
     all the history, so apologies for that.
     No changes from V4 to V5
---
 drivers/gpu/drm/bridge/imx/Kconfig           |   7 +
 drivers/gpu/drm/bridge/imx/Makefile          |   1 +
 drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c | 207 +++++++++++++++++++
 3 files changed, 215 insertions(+)
 create mode 100644 drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c

diff --git a/drivers/gpu/drm/bridge/imx/Kconfig b/drivers/gpu/drm/bridge/imx/Kconfig
index 5a4f3d58501e..a4d13331e320 100644
--- a/drivers/gpu/drm/bridge/imx/Kconfig
+++ b/drivers/gpu/drm/bridge/imx/Kconfig
@@ -3,6 +3,13 @@ if ARCH_MXC || COMPILE_TEST
 config DRM_IMX_LDB_HELPER
 	tristate
 
+config DRM_IMX8MP_HDMI_PVI
+	tristate "Freescale i.MX8MP HDMI PVI bridge support"
+	depends on OF
+	help
+	  Choose this to enable support for the internal HDMI TX Parallel
+	  Video Interface found on the Freescale i.MX8MP SoC.
+
 config DRM_IMX8QM_LDB
 	tristate "Freescale i.MX8QM LVDS display bridge"
 	depends on OF
diff --git a/drivers/gpu/drm/bridge/imx/Makefile b/drivers/gpu/drm/bridge/imx/Makefile
index 2b0c2e44aa1b..e2c2106509fa 100644
--- a/drivers/gpu/drm/bridge/imx/Makefile
+++ b/drivers/gpu/drm/bridge/imx/Makefile
@@ -1,4 +1,5 @@
 obj-$(CONFIG_DRM_IMX_LDB_HELPER) += imx-ldb-helper.o
+obj-$(CONFIG_DRM_IMX8MP_HDMI_PVI) += imx8mp-hdmi-pvi.o
 obj-$(CONFIG_DRM_IMX8QM_LDB) += imx8qm-ldb.o
 obj-$(CONFIG_DRM_IMX8QXP_LDB) += imx8qxp-ldb.o
 obj-$(CONFIG_DRM_IMX8QXP_PIXEL_COMBINER) += imx8qxp-pixel-combiner.o
diff --git a/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c b/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c
new file mode 100644
index 000000000000..a76b7669fe8a
--- /dev/null
+++ b/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c
@@ -0,0 +1,207 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+/*
+ * Copyright (C) 2022 Pengutronix, Lucas Stach <kernel@pengutronix.de>
+ */
+
+#include <drm/drm_atomic_helper.h>
+#include <drm/drm_bridge.h>
+#include <drm/drm_crtc.h>
+#include <linux/bitfield.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_graph.h>
+#include <linux/platform_device.h>
+#include <linux/pm_runtime.h>
+
+#define HTX_PVI_CTRL			0x0
+#define  PVI_CTRL_OP_VSYNC_POL		BIT(18)
+#define  PVI_CTRL_OP_HSYNC_POL		BIT(17)
+#define  PVI_CTRL_OP_DE_POL		BIT(16)
+#define  PVI_CTRL_INP_VSYNC_POL		BIT(14)
+#define  PVI_CTRL_INP_HSYNC_POL		BIT(13)
+#define  PVI_CTRL_INP_DE_POL		BIT(12)
+#define  PVI_CTRL_MODE_MASK		GENMASK(2, 1)
+#define  PVI_CTRL_MODE_LCDIF		2
+#define  PVI_CTRL_EN			BIT(0)
+
+struct imx8mp_hdmi_pvi {
+	struct drm_bridge	bridge;
+	struct device		*dev;
+	struct drm_bridge	*next_bridge;
+	void __iomem		*regs;
+};
+
+static inline struct imx8mp_hdmi_pvi *
+to_imx8mp_hdmi_pvi(struct drm_bridge *bridge)
+{
+	return container_of(bridge, struct imx8mp_hdmi_pvi, bridge);
+}
+
+static int imx8mp_hdmi_pvi_bridge_attach(struct drm_bridge *bridge,
+					 enum drm_bridge_attach_flags flags)
+{
+	struct imx8mp_hdmi_pvi *pvi = to_imx8mp_hdmi_pvi(bridge);
+
+	return drm_bridge_attach(bridge->encoder, pvi->next_bridge,
+				 bridge, flags);
+}
+
+static void imx8mp_hdmi_pvi_bridge_enable(struct drm_bridge *bridge,
+					  struct drm_bridge_state *bridge_state)
+{
+	struct drm_atomic_state *state = bridge_state->base.state;
+	struct imx8mp_hdmi_pvi *pvi = to_imx8mp_hdmi_pvi(bridge);
+	struct drm_connector_state *conn_state;
+	const struct drm_display_mode *mode;
+	struct drm_crtc_state *crtc_state;
+	struct drm_connector *connector;
+	u32 bus_flags, val;
+
+	connector = drm_atomic_get_new_connector_for_encoder(state, bridge->encoder);
+	conn_state = drm_atomic_get_new_connector_state(state, connector);
+	crtc_state = drm_atomic_get_new_crtc_state(state, conn_state->crtc);
+
+	if (WARN_ON(pm_runtime_resume_and_get(pvi->dev)))
+		return;
+
+	mode = &crtc_state->adjusted_mode;
+
+	val = FIELD_PREP(PVI_CTRL_MODE_MASK, PVI_CTRL_MODE_LCDIF) | PVI_CTRL_EN;
+
+	if (mode->flags & DRM_MODE_FLAG_PVSYNC)
+		val |= PVI_CTRL_OP_VSYNC_POL | PVI_CTRL_INP_VSYNC_POL;
+
+	if (mode->flags & DRM_MODE_FLAG_PHSYNC)
+		val |= PVI_CTRL_OP_HSYNC_POL | PVI_CTRL_INP_HSYNC_POL;
+
+	if (pvi->next_bridge->timings)
+		bus_flags = pvi->next_bridge->timings->input_bus_flags;
+	else if (bridge_state)
+		bus_flags = bridge_state->input_bus_cfg.flags;
+
+	if (bus_flags & DRM_BUS_FLAG_DE_HIGH)
+		val |= PVI_CTRL_OP_DE_POL | PVI_CTRL_INP_DE_POL;
+
+	writel(val, pvi->regs + HTX_PVI_CTRL);
+}
+
+static void imx8mp_hdmi_pvi_bridge_disable(struct drm_bridge *bridge,
+					   struct drm_bridge_state *bridge_state)
+{
+	struct imx8mp_hdmi_pvi *pvi = to_imx8mp_hdmi_pvi(bridge);
+
+	writel(0x0, pvi->regs + HTX_PVI_CTRL);
+
+	pm_runtime_put(pvi->dev);
+}
+
+static u32 *
+imx8mp_hdmi_pvi_bridge_get_input_bus_fmts(struct drm_bridge *bridge,
+					  struct drm_bridge_state *bridge_state,
+					  struct drm_crtc_state *crtc_state,
+					  struct drm_connector_state *conn_state,
+					  u32 output_fmt,
+					  unsigned int *num_input_fmts)
+{
+	struct imx8mp_hdmi_pvi *pvi = to_imx8mp_hdmi_pvi(bridge);
+	struct drm_bridge *next_bridge = pvi->next_bridge;
+	struct drm_bridge_state *next_state;
+
+	if (!next_bridge->funcs->atomic_get_input_bus_fmts)
+		return 0;
+
+	next_state = drm_atomic_get_new_bridge_state(crtc_state->state,
+						     next_bridge);
+
+	return next_bridge->funcs->atomic_get_input_bus_fmts(next_bridge,
+							     next_state,
+							     crtc_state,
+							     conn_state,
+							     output_fmt,
+							     num_input_fmts);
+}
+
+static const struct drm_bridge_funcs imx_hdmi_pvi_bridge_funcs = {
+	.attach		= imx8mp_hdmi_pvi_bridge_attach,
+	.atomic_enable	= imx8mp_hdmi_pvi_bridge_enable,
+	.atomic_disable	= imx8mp_hdmi_pvi_bridge_disable,
+	.atomic_get_input_bus_fmts = imx8mp_hdmi_pvi_bridge_get_input_bus_fmts,
+	.atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,
+	.atomic_destroy_state = drm_atomic_helper_bridge_destroy_state,
+	.atomic_reset = drm_atomic_helper_bridge_reset,
+};
+
+static int imx8mp_hdmi_pvi_probe(struct platform_device *pdev)
+{
+	struct device_node *remote;
+	struct imx8mp_hdmi_pvi *pvi;
+
+	pvi = devm_kzalloc(&pdev->dev, sizeof(*pvi), GFP_KERNEL);
+	if (!pvi)
+		return -ENOMEM;
+
+	platform_set_drvdata(pdev, pvi);
+	pvi->dev = &pdev->dev;
+
+	pvi->regs = devm_platform_ioremap_resource(pdev, 0);
+	if (IS_ERR(pvi->regs))
+		return PTR_ERR(pvi->regs);
+
+	/* Get the next bridge in the pipeline. */
+	remote = of_graph_get_remote_node(pdev->dev.of_node, 1, -1);
+	if (!remote)
+		return -EINVAL;
+
+	pvi->next_bridge = of_drm_find_bridge(remote);
+	of_node_put(remote);
+
+	if (!pvi->next_bridge)
+		return dev_err_probe(&pdev->dev, -EPROBE_DEFER,
+				     "could not find next bridge\n");
+
+	pm_runtime_enable(&pdev->dev);
+
+	/* Register the bridge. */
+	pvi->bridge.funcs = &imx_hdmi_pvi_bridge_funcs;
+	pvi->bridge.of_node = pdev->dev.of_node;
+	pvi->bridge.timings = pvi->next_bridge->timings;
+
+	drm_bridge_add(&pvi->bridge);
+
+	return 0;
+}
+
+static int imx8mp_hdmi_pvi_remove(struct platform_device *pdev)
+{
+	struct imx8mp_hdmi_pvi *pvi = platform_get_drvdata(pdev);
+
+	drm_bridge_remove(&pvi->bridge);
+
+	pm_runtime_disable(&pdev->dev);
+
+	return 0;
+}
+
+static const struct of_device_id imx8mp_hdmi_pvi_match[] = {
+	{
+		.compatible = "fsl,imx8mp-hdmi-pvi",
+	}, {
+		/* sentinel */
+	}
+};
+MODULE_DEVICE_TABLE(of, imx8mp_hdmi_pvi_match);
+
+static struct platform_driver imx8mp_hdmi_pvi_driver = {
+	.probe	= imx8mp_hdmi_pvi_probe,
+	.remove	= imx8mp_hdmi_pvi_remove,
+	.driver		= {
+		.name = "imx-hdmi-pvi",
+		.of_match_table	= imx8mp_hdmi_pvi_match,
+	},
+};
+module_platform_driver(imx8mp_hdmi_pvi_driver);
+
+MODULE_DESCRIPTION("i.MX8MP HDMI TX Parallel Video Interface bridge driver");
+MODULE_LICENSE("GPL");
-- 
2.43.0

[PATCH V8 09/12] dt-bindings: display: imx: add binding for i.MX8MP HDMI TX

[Adam Ford]

From: Lucas Stach <l.stach@pengutronix.de>

The HDMI TX controller on the i.MX8MP SoC is a Synopsys designware IP
core with a little bit of SoC integration around it.

Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Adam Ford <aford173@gmail.com>

---
V3:  Change name and location to better idenfity as a bridge and
     HDMI 2.0a transmitter

     Fix typos and feedback from Rob and added ports.
---
 .../display/bridge/fsl,imx8mp-hdmi-tx.yaml    | 102 ++++++++++++++++++
 1 file changed, 102 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/bridge/fsl,imx8mp-hdmi-tx.yaml

diff --git a/Documentation/devicetree/bindings/display/bridge/fsl,imx8mp-hdmi-tx.yaml b/Documentation/devicetree/bindings/display/bridge/fsl,imx8mp-hdmi-tx.yaml
new file mode 100644
index 000000000000..3791c9f4ebab
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/fsl,imx8mp-hdmi-tx.yaml
@@ -0,0 +1,102 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/fsl,imx8mp-hdmi-tx.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX8MP DWC HDMI TX Encoder
+
+maintainers:
+  - Lucas Stach <l.stach@pengutronix.de>
+
+description:
+  The i.MX8MP HDMI transmitter is a Synopsys DesignWare
+  HDMI 2.0a TX controller IP.
+
+allOf:
+  - $ref: /schemas/display/bridge/synopsys,dw-hdmi.yaml#
+
+properties:
+  compatible:
+    enum:
+      - fsl,imx8mp-hdmi-tx
+
+  reg-io-width:
+    const: 1
+
+  clocks:
+    maxItems: 4
+
+  clock-names:
+    items:
+      - const: iahb
+      - const: isfr
+      - const: cec
+      - const: pix
+
+  power-domains:
+    maxItems: 1
+
+  ports:
+    $ref: /schemas/graph.yaml#/properties/ports
+
+    properties:
+      port@0:
+        $ref: /schemas/graph.yaml#/properties/port
+        description: Parallel RGB input port
+
+      port@1:
+        $ref: /schemas/graph.yaml#/properties/port
+        description: HDMI output port
+
+    required:
+      - port@0
+      - port@1
+
+required:
+  - compatible
+  - reg
+  - clocks
+  - clock-names
+  - interrupts
+  - power-domains
+  - ports
+
+unevaluatedProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/clock/imx8mp-clock.h>
+    #include <dt-bindings/interrupt-controller/irq.h>
+    #include <dt-bindings/power/imx8mp-power.h>
+
+    hdmi@32fd8000 {
+        compatible = "fsl,imx8mp-hdmi-tx";
+        reg = <0x32fd8000 0x7eff>;
+        interrupts = <0 IRQ_TYPE_LEVEL_HIGH>;
+        clocks = <&clk IMX8MP_CLK_HDMI_APB>,
+                 <&clk IMX8MP_CLK_HDMI_REF_266M>,
+                 <&clk IMX8MP_CLK_32K>,
+                 <&hdmi_tx_phy>;
+        clock-names = "iahb", "isfr", "cec", "pix";
+        power-domains = <&hdmi_blk_ctrl IMX8MP_HDMIBLK_PD_HDMI_TX>;
+        reg-io-width = <1>;
+        ports {
+           #address-cells = <1>;
+           #size-cells = <0>;
+           port@0 {
+             reg = <0>;
+
+             hdmi_tx_from_pvi: endpoint {
+               remote-endpoint = <&pvi_to_hdmi_tx>;
+             };
+          };
+
+          port@1 {
+            reg = <1>;
+              hdmi_tx_out: endpoint {
+                remote-endpoint = <&hdmi0_con>;
+              };
+          };
+        };
+    };
-- 
2.43.0

[PATCH V8 10/12] drm/bridge: imx: add bridge wrapper driver for i.MX8MP DWC HDMI

[Adam Ford]

From: Lucas Stach <l.stach@pengutronix.de>

Add a simple wrapper driver for the DWC HDMI bridge driver that
implements the few bits that are necessary to abstract the i.MX8MP
SoC integration.

Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Tested-by: Marek Vasut <marex@denx.de>
Tested-by: Adam Ford <aford173@gmail.com> #imx8mp-beacon
Tested-by: Richard Leitner <richard.leitner@skidata.com>
Tested-by: Frieder Schrempf <frieder.schrempf@kontron.de>
Tested-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Signed-off-by:  Adam Ford <aford173@gmail.com>

---
v3:  To move this along, I (Adam) took Lucas' V2 and attempted
     to address concerns:

     Changed name to imx8mp-hdmi-tx
     Re-ordered includes to make drm come after linux
     Removed unused variable build warning
     Removed fdcc clock since it's part of the power domain now
     set the phy_force_vendor = true
     Removed comma after sentinel

     Also added suspend/resume functions from Marek Vasut

     Configured Kconfig to select the PVI and PHY automatically
     since the HDMI-tx is useless without the other two components

     I apologize that don't have the version history prior to V2.
---
 drivers/gpu/drm/bridge/imx/Kconfig          |  11 ++
 drivers/gpu/drm/bridge/imx/Makefile         |   1 +
 drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx.c | 154 ++++++++++++++++++++
 3 files changed, 166 insertions(+)
 create mode 100644 drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx.c

diff --git a/drivers/gpu/drm/bridge/imx/Kconfig b/drivers/gpu/drm/bridge/imx/Kconfig
index a4d13331e320..5965e8027529 100644
--- a/drivers/gpu/drm/bridge/imx/Kconfig
+++ b/drivers/gpu/drm/bridge/imx/Kconfig
@@ -3,6 +3,17 @@ if ARCH_MXC || COMPILE_TEST
 config DRM_IMX_LDB_HELPER
 	tristate
 
+config DRM_IMX8MP_DW_HDMI_BRIDGE
+	tristate "Freescale i.MX8MP HDMI-TX bridge support"
+	depends on OF
+	depends on COMMON_CLK
+	select DRM_DW_HDMI
+	select DRM_IMX8MP_HDMI_PVI
+	select PHY_FSL_SAMSUNG_HDMI_PHY
+	help
+	  Choose this to enable support for the internal HDMI encoder found
+	  on the i.MX8MP SoC.
+
 config DRM_IMX8MP_HDMI_PVI
 	tristate "Freescale i.MX8MP HDMI PVI bridge support"
 	depends on OF
diff --git a/drivers/gpu/drm/bridge/imx/Makefile b/drivers/gpu/drm/bridge/imx/Makefile
index e2c2106509fa..edb0a7b71b30 100644
--- a/drivers/gpu/drm/bridge/imx/Makefile
+++ b/drivers/gpu/drm/bridge/imx/Makefile
@@ -1,4 +1,5 @@
 obj-$(CONFIG_DRM_IMX_LDB_HELPER) += imx-ldb-helper.o
+obj-$(CONFIG_DRM_IMX8MP_DW_HDMI_BRIDGE) += imx8mp-hdmi-tx.o
 obj-$(CONFIG_DRM_IMX8MP_HDMI_PVI) += imx8mp-hdmi-pvi.o
 obj-$(CONFIG_DRM_IMX8QM_LDB) += imx8qm-ldb.o
 obj-$(CONFIG_DRM_IMX8QXP_LDB) += imx8qxp-ldb.o
diff --git a/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx.c b/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx.c
new file mode 100644
index 000000000000..89fc432ac611
--- /dev/null
+++ b/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx.c
@@ -0,0 +1,154 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+/*
+ * Copyright (C) 2022 Pengutronix, Lucas Stach <kernel@pengutronix.de>
+ */
+
+#include <linux/clk.h>
+#include <linux/mod_devicetable.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <drm/bridge/dw_hdmi.h>
+#include <drm/drm_modes.h>
+
+struct imx8mp_hdmi {
+	struct dw_hdmi_plat_data plat_data;
+	struct dw_hdmi *dw_hdmi;
+	struct clk *pixclk;
+};
+
+static enum drm_mode_status
+imx8mp_hdmi_mode_valid(struct dw_hdmi *dw_hdmi, void *data,
+		       const struct drm_display_info *info,
+		       const struct drm_display_mode *mode)
+{
+	struct imx8mp_hdmi *hdmi = (struct imx8mp_hdmi *)data;
+
+	if (mode->clock < 13500)
+		return MODE_CLOCK_LOW;
+
+	if (mode->clock > 297000)
+		return MODE_CLOCK_HIGH;
+
+	if (clk_round_rate(hdmi->pixclk, mode->clock * 1000) !=
+	    mode->clock * 1000)
+		return MODE_CLOCK_RANGE;
+
+	/* We don't support double-clocked and Interlaced modes */
+	if ((mode->flags & DRM_MODE_FLAG_DBLCLK) ||
+	    (mode->flags & DRM_MODE_FLAG_INTERLACE))
+		return MODE_BAD;
+
+	return MODE_OK;
+}
+
+static int imx8mp_hdmi_phy_init(struct dw_hdmi *dw_hdmi, void *data,
+				const struct drm_display_info *display,
+				const struct drm_display_mode *mode)
+{
+	return 0;
+}
+
+static void imx8mp_hdmi_phy_disable(struct dw_hdmi *dw_hdmi, void *data)
+{
+}
+
+static void im8mp_hdmi_phy_setup_hpd(struct dw_hdmi *hdmi, void *data)
+{
+	/*
+	 * Just release PHY core from reset, all other power management is done
+	 * by the PHY driver.
+	 */
+	dw_hdmi_phy_gen1_reset(hdmi);
+
+	dw_hdmi_phy_setup_hpd(hdmi, data);
+}
+
+static const struct dw_hdmi_phy_ops imx8mp_hdmi_phy_ops = {
+	.init		= imx8mp_hdmi_phy_init,
+	.disable	= imx8mp_hdmi_phy_disable,
+	.setup_hpd	= im8mp_hdmi_phy_setup_hpd,
+	.read_hpd	= dw_hdmi_phy_read_hpd,
+	.update_hpd	= dw_hdmi_phy_update_hpd,
+};
+
+static int imx8mp_dw_hdmi_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct dw_hdmi_plat_data *plat_data;
+	struct imx8mp_hdmi *hdmi;
+
+	hdmi = devm_kzalloc(dev, sizeof(*hdmi), GFP_KERNEL);
+	if (!hdmi)
+		return -ENOMEM;
+
+	plat_data = &hdmi->plat_data;
+
+	hdmi->pixclk = devm_clk_get(dev, "pix");
+	if (IS_ERR(hdmi->pixclk))
+		return dev_err_probe(dev, PTR_ERR(hdmi->pixclk),
+				     "Unable to get pixel clock\n");
+
+	plat_data->mode_valid = imx8mp_hdmi_mode_valid;
+	plat_data->phy_ops = &imx8mp_hdmi_phy_ops;
+	plat_data->phy_name = "SAMSUNG HDMI TX PHY";
+	plat_data->priv_data = hdmi;
+	plat_data->phy_force_vendor = true;
+
+	hdmi->dw_hdmi = dw_hdmi_probe(pdev, plat_data);
+	if (IS_ERR(hdmi->dw_hdmi))
+		return PTR_ERR(hdmi->dw_hdmi);
+
+	platform_set_drvdata(pdev, hdmi);
+
+	return 0;
+}
+
+static int imx8mp_dw_hdmi_remove(struct platform_device *pdev)
+{
+	struct imx8mp_hdmi *hdmi = platform_get_drvdata(pdev);
+
+	dw_hdmi_remove(hdmi->dw_hdmi);
+
+	return 0;
+}
+
+static int __maybe_unused imx8mp_dw_hdmi_pm_suspend(struct device *dev)
+{
+	return 0;
+}
+
+static int __maybe_unused imx8mp_dw_hdmi_pm_resume(struct device *dev)
+{
+	struct imx8mp_hdmi *hdmi = dev_get_drvdata(dev);
+
+	dw_hdmi_resume(hdmi->dw_hdmi);
+
+	return 0;
+}
+
+static const struct dev_pm_ops imx8mp_dw_hdmi_pm_ops = {
+	SET_SYSTEM_SLEEP_PM_OPS(imx8mp_dw_hdmi_pm_suspend,
+				imx8mp_dw_hdmi_pm_resume)
+};
+
+static const struct of_device_id imx8mp_dw_hdmi_of_table[] = {
+	{ .compatible = "fsl,imx8mp-hdmi-tx" },
+	{ /* Sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, imx8mp_dw_hdmi_of_table);
+
+static struct platform_driver imx8mp_dw_hdmi_platform_driver = {
+	.probe		= imx8mp_dw_hdmi_probe,
+	.remove		= imx8mp_dw_hdmi_remove,
+	.driver		= {
+		.name	= "imx8mp-dw-hdmi-tx",
+		.of_match_table = imx8mp_dw_hdmi_of_table,
+		.pm = &imx8mp_dw_hdmi_pm_ops,
+	},
+};
+
+module_platform_driver(imx8mp_dw_hdmi_platform_driver);
+
+MODULE_DESCRIPTION("i.MX8MP HDMI encoder driver");
+MODULE_LICENSE("GPL");
-- 
2.43.0

[PATCH V8 11/12] arm64: dts: imx8mp: add HDMI display pipeline

[Adam Ford]

From: Lucas Stach <l.stach@pengutronix.de>

This adds the DT nodes for all the peripherals that make up the
HDMI display pipeline.

Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Adam Ford <aford173@gmail.com>

---
V2:  I took this from Lucas' original submission with the following:
     Removed extra clock from HDMI-TX since it is now part of the
     power domain
     Added interrupt-parent to PVI
     Changed the name of the HDMI tranmitter to fsl,imx8mp-hdmi-tx
     Added ports to HDMI-tx
---
 arch/arm64/boot/dts/freescale/imx8mp.dtsi | 94 +++++++++++++++++++++++
 1 file changed, 94 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/imx8mp.dtsi b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
index 5e51a766f3d9..e84b4f40e570 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
@@ -1412,6 +1412,100 @@ irqsteer_hdmi: interrupt-controller@32fc2000 {
 				clock-names = "ipg";
 				power-domains = <&hdmi_blk_ctrl IMX8MP_HDMIBLK_PD_IRQSTEER>;
 			};
+
+			hdmi_pvi: display-bridge@32fc4000 {
+				compatible = "fsl,imx8mp-hdmi-pvi";
+				reg = <0x32fc4000 0x40>;
+				interrupt-parent = <&irqsteer_hdmi>;
+				interrupts = <12 IRQ_TYPE_LEVEL_HIGH>;
+				power-domains = <&hdmi_blk_ctrl IMX8MP_HDMIBLK_PD_PVI>;
+
+				ports {
+					#address-cells = <1>;
+					#size-cells = <0>;
+
+					port@0 {
+						reg = <0>;
+						pvi_from_lcdif3: endpoint {
+							remote-endpoint = <&lcdif3_to_pvi>;
+						};
+					};
+
+					port@1 {
+						reg = <1>;
+						pvi_to_hdmi_tx: endpoint {
+							remote-endpoint = <&hdmi_tx_from_pvi>;
+						};
+					};
+				};
+			};
+
+			lcdif3: display-controller@32fc6000 {
+				compatible = "fsl,imx8mp-lcdif";
+				reg = <0x32fc6000 0x238>;
+				interrupts = <8 IRQ_TYPE_LEVEL_HIGH>;
+				interrupt-parent = <&irqsteer_hdmi>;
+				clocks = <&hdmi_tx_phy>,
+					 <&clk IMX8MP_CLK_HDMI_APB>,
+					 <&clk IMX8MP_CLK_HDMI_ROOT>;
+				clock-names = "pix", "axi", "disp_axi";
+				power-domains = <&hdmi_blk_ctrl IMX8MP_HDMIBLK_PD_LCDIF>;
+
+				port {
+					lcdif3_to_pvi: endpoint {
+						remote-endpoint = <&pvi_from_lcdif3>;
+					};
+				};
+			};
+
+			hdmi_tx: hdmi@32fd8000 {
+				compatible = "fsl,imx8mp-hdmi-tx";
+				reg = <0x32fd8000 0x7eff>;
+				interrupts = <0 IRQ_TYPE_LEVEL_HIGH>;
+				interrupt-parent = <&irqsteer_hdmi>;
+				clocks = <&clk IMX8MP_CLK_HDMI_APB>,
+					 <&clk IMX8MP_CLK_HDMI_REF_266M>,
+					 <&clk IMX8MP_CLK_32K>,
+					 <&hdmi_tx_phy>;
+				clock-names = "iahb", "isfr", "cec", "pix";
+				assigned-clocks = <&clk IMX8MP_CLK_HDMI_REF_266M>;
+				assigned-clock-parents = <&clk IMX8MP_SYS_PLL1_266M>;
+				power-domains = <&hdmi_blk_ctrl IMX8MP_HDMIBLK_PD_HDMI_TX>;
+				reg-io-width = <1>;
+				status = "disabled";
+
+				ports {
+					#address-cells = <1>;
+					#size-cells = <0>;
+
+					port@0 {
+						reg = <0>;
+
+						hdmi_tx_from_pvi: endpoint {
+							remote-endpoint = <&pvi_to_hdmi_tx>;
+						};
+					};
+
+					port@1 {
+						reg = <1>;
+						/* Point endpoint to the HDMI connector */
+					};
+				};
+			};
+
+			hdmi_tx_phy: phy@32fdff00 {
+				compatible = "fsl,imx8mp-hdmi-phy";
+				reg = <0x32fdff00 0x100>;
+				clocks = <&clk IMX8MP_CLK_HDMI_APB>,
+					 <&clk IMX8MP_CLK_HDMI_24M>;
+				clock-names = "apb", "ref";
+				assigned-clocks = <&clk IMX8MP_CLK_HDMI_24M>;
+				assigned-clock-parents = <&clk IMX8MP_CLK_24M>;
+				power-domains = <&hdmi_blk_ctrl IMX8MP_HDMIBLK_PD_HDMI_TX_PHY>;
+				#clock-cells = <0>;
+				#phy-cells = <0>;
+				status = "disabled";
+			};
 		};
 
 		aips5: bus@30c00000 {
-- 
2.43.0

[PATCH V8 12/12] arm64: defconfig: Enable DRM_IMX8MP_DW_HDMI_BRIDGE as module

[Adam Ford]

The i.MX8M Plus has support for an HDMI transmitter.  The
video is genereated by lcdif3, routed to the hdmi parallel
video interface, then fed to a DW HDMI bridge to support
up to 4K video output.

Signed-off-by: Adam Ford <aford173@gmail.com>
---
 arch/arm64/configs/defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index e6cf3e5d63c3..3e33825f0ed7 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -880,6 +880,7 @@ CONFIG_DRM_ANALOGIX_ANX7625=m
 CONFIG_DRM_I2C_ADV7511=m
 CONFIG_DRM_I2C_ADV7511_AUDIO=y
 CONFIG_DRM_CDNS_MHDP8546=m
+CONFIG_DRM_IMX8MP_DW_HDMI_BRIDGE=m
 CONFIG_DRM_DW_HDMI_AHB_AUDIO=m
 CONFIG_DRM_DW_HDMI_CEC=m
 CONFIG_DRM_IMX_DCSS=m
-- 
2.43.0

Re: [PATCH V8 02/12] phy: freescale: add Samsung HDMI PHY

[Christophe JAILLET]

Le 03/02/2024 à 17:52, Adam Ford a écrit :
> From: Lucas Stach <l.stach-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
> 
> This adds the driver for the Samsung HDMI PHY found on the
> i.MX8MP SoC.
> 
> Signed-off-by: Lucas Stach <l.stach-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
> Signed-off-by: Adam Ford <aford173-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Tested-by: Alexander Stein <alexander.stein-W3o+9BuWjQaZox4op4iWzw@public.gmane.org>
> ---

...

> +static int fsl_samsung_hdmi_phy_probe(struct platform_device *pdev)
> +{
> +	struct fsl_samsung_hdmi_phy *phy;
> +	int ret;
> +
> +	phy = devm_kzalloc(&pdev->dev, sizeof(*phy), GFP_KERNEL);
> +	if (!phy)
> +		return -ENOMEM;
> +
> +	platform_set_drvdata(pdev, phy);
> +	phy->dev = &pdev->dev;
> +
> +	phy->regs = devm_platform_ioremap_resource(pdev, 0);
> +	if (IS_ERR(phy->regs))
> +		return PTR_ERR(phy->regs);
> +
> +	phy->apbclk = devm_clk_get(phy->dev, "apb");
> +	if (IS_ERR(phy->apbclk))
> +		return dev_err_probe(phy->dev, PTR_ERR(phy->apbclk),
> +				     "failed to get apb clk\n");
> +
> +	phy->refclk = devm_clk_get(phy->dev, "ref");
> +	if (IS_ERR(phy->refclk))
> +		return dev_err_probe(phy->dev, PTR_ERR(phy->refclk),
> +				     "failed to get ref clk\n");
> +
> +	ret = clk_prepare_enable(phy->apbclk);
> +	if (ret) {
> +		dev_err(phy->dev, "failed to enable apbclk\n");
> +		return ret;
> +	}
> +
> +	pm_runtime_get_noresume(phy->dev);
> +	pm_runtime_set_active(phy->dev);
> +	pm_runtime_enable(phy->dev);
> +
> +	ret = phy_clk_register(phy);
> +	if (ret) {
> +		dev_err(&pdev->dev, "register clk failed\n");
> +		goto register_clk_failed;
> +	}
> +
> +	pm_runtime_put(phy->dev);
> +
> +	return 0;
> +
> +register_clk_failed:
> +	clk_disable_unprepare(phy->apbclk);
> +
> +	return ret;
> +}
> +
> +static int fsl_samsung_hdmi_phy_remove(struct platform_device *pdev)
> +{
> +	of_clk_del_provider(pdev->dev.of_node);

A clk_disable_unprepare(phy->apbclk) call seems to be missing here.
Or maybe devm_clk_get_enabled() should be used for 'apbclk'?

CJ

> +
> +	return 0;
> +}

...

Re: [PATCH V8 02/12] phy: freescale: add Samsung HDMI PHY

[Dmitry Baryshkov]

On Sat, 3 Feb 2024 at 17:53, Adam Ford <aford173@gmail.com> wrote:
>
> From: Lucas Stach <l.stach@pengutronix.de>
>
> This adds the driver for the Samsung HDMI PHY found on the
> i.MX8MP SoC.
>
> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
> Signed-off-by: Adam Ford <aford173@gmail.com>
> Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com>
> ---
> V4:  Make lookup table hex values lower case.
>
> V3:  Re-order the Makefile to keep it alphabetical
>      Remove unused defines
>
> V2:  Fixed some whitespace found from checkpatch
>      Change error handling when enabling apbclk to use dev_err_probe
>      Rebase on Linux-Next
>
>      I (Adam) tried to help move this along, so I took Lucas' patch and
>      attempted to apply fixes based on feedback.  I don't have
>      all the history, so apologies for that.
> ---
>  drivers/phy/freescale/Kconfig                |    6 +
>  drivers/phy/freescale/Makefile               |    1 +
>  drivers/phy/freescale/phy-fsl-samsung-hdmi.c | 1075 ++++++++++++++++++
>  3 files changed, 1082 insertions(+)
>  create mode 100644 drivers/phy/freescale/phy-fsl-samsung-hdmi.c
>
> diff --git a/drivers/phy/freescale/Kconfig b/drivers/phy/freescale/Kconfig
> index 853958fb2c06..5c2b73042dfc 100644
> --- a/drivers/phy/freescale/Kconfig
> +++ b/drivers/phy/freescale/Kconfig
> @@ -35,6 +35,12 @@ config PHY_FSL_IMX8M_PCIE
>           Enable this to add support for the PCIE PHY as found on
>           i.MX8M family of SOCs.
>
> +config PHY_FSL_SAMSUNG_HDMI_PHY
> +       tristate "Samsung HDMI PHY support"
> +       depends on OF && HAS_IOMEM
> +       help
> +         Enable this to add support for the Samsung HDMI PHY in i.MX8MP.
> +
>  endif
>
>  config PHY_FSL_LYNX_28G
> diff --git a/drivers/phy/freescale/Makefile b/drivers/phy/freescale/Makefile
> index cedb328bc4d2..79e5f16d3ce8 100644
> --- a/drivers/phy/freescale/Makefile
> +++ b/drivers/phy/freescale/Makefile
> @@ -4,3 +4,4 @@ obj-$(CONFIG_PHY_MIXEL_LVDS_PHY)        += phy-fsl-imx8qm-lvds-phy.o
>  obj-$(CONFIG_PHY_MIXEL_MIPI_DPHY)      += phy-fsl-imx8-mipi-dphy.o
>  obj-$(CONFIG_PHY_FSL_IMX8M_PCIE)       += phy-fsl-imx8m-pcie.o
>  obj-$(CONFIG_PHY_FSL_LYNX_28G)         += phy-fsl-lynx-28g.o
> +obj-$(CONFIG_PHY_FSL_SAMSUNG_HDMI_PHY)  += phy-fsl-samsung-hdmi.o
> diff --git a/drivers/phy/freescale/phy-fsl-samsung-hdmi.c b/drivers/phy/freescale/phy-fsl-samsung-hdmi.c
> new file mode 100644
> index 000000000000..bf0e2299d00f
> --- /dev/null
> +++ b/drivers/phy/freescale/phy-fsl-samsung-hdmi.c
> @@ -0,0 +1,1075 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright 2020 NXP
> + * Copyright 2022 Pengutronix, Lucas Stach <kernel@pengutronix.de>
> + */
> +
> +#include <linux/clk-provider.h>
> +#include <linux/clk.h>
> +#include <linux/delay.h>
> +#include <linux/io.h>
> +#include <linux/iopoll.h>
> +#include <linux/module.h>
> +#include <linux/of_device.h>
> +#include <linux/of.h>
> +#include <linux/platform_device.h>
> +#include <linux/pm_runtime.h>
> +
> +#define PHY_REG_33             0x84
> +#define  REG33_MODE_SET_DONE   BIT(7)
> +#define  REG33_FIX_DA          BIT(1)
> +
> +#define PHY_REG_34             0x88
> +#define  REG34_PHY_READY       BIT(7)
> +#define  REG34_PLL_LOCK                BIT(6)
> +#define  REG34_PHY_CLK_READY   BIT(5)
> +
> +
> +#define PHY_PLL_REGS_NUM 48
> +
> +struct phy_config {
> +       u32     clk_rate;
> +       u8 regs[PHY_PLL_REGS_NUM];
> +};
> +
> +const struct phy_config phy_pll_cfg[] = {
> +       {       22250000, {
> +                       0x00, 0xd1, 0x4b, 0xf1, 0x89, 0x88, 0x80, 0x40,
> +                       0x4f, 0x30, 0x33, 0x65, 0x00, 0x15, 0x25, 0x80,
> +                       0x6c, 0xf2, 0x67, 0x00, 0x10, 0x8f, 0x30, 0x32,
> +                       0x60, 0x8f, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
> +                       0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> +                       0x00, 0xe0, 0x83, 0x0f, 0x3e, 0xf8, 0x00, 0x00,
> +               },
> +       }, {
> +               23750000, {
> +                       0x00, 0xd1, 0x50, 0xf1, 0x86, 0x85, 0x80, 0x40,
> +                       0x4f, 0x30, 0x33, 0x65, 0x00, 0x03, 0x25, 0x80,
> +                       0x6c, 0xf2, 0x67, 0x00, 0x10, 0x8f, 0x30, 0x32,
> +                       0x60, 0x8f, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
> +                       0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> +                       0x00, 0xe0, 0x83, 0x0f, 0x3e, 0xf8, 0x00, 0x00,
> +               },

Generally I see that these entries contain a high level of duplication.
Could you please extract the common part and a rate-dependent part.
Next, it would be best if instead of writing the register values via
the rate LUT, the driver could calculate those values.
This allows us to support other HDMI modes if the need arises at some point.

> +       }, {
> +               24000000, {
> +                       0x00, 0xd1, 0x50, 0xf0, 0x00, 0x00, 0x80, 0x00,
> +                       0x4f, 0x30, 0x33, 0x65, 0x00, 0x01, 0x25, 0x80,
> +                       0x6c, 0xf2, 0x67, 0x00, 0x10, 0x8f, 0x30, 0x32,
> +                       0x60, 0x8f, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
> +                       0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> +                       0x00, 0xe0, 0x83, 0x0f, 0x3e, 0xf8, 0x00, 0x00,
> +               },


-- 
With best wishes
Dmitry

Re: [PATCH V8 06/12] arm64: dts: imx8mp: add HDMI irqsteer

[Francesco Dolcini]

On Sat, Feb 03, 2024 at 10:52:46AM -0600, Adam Ford wrote:
> From: Lucas Stach <l.stach@pengutronix.de>
> 
> The HDMI irqsteer is a secondary interrupt controller within the HDMI
> subsystem that maps all HDMI peripheral IRQs into a single upstream
> IRQ line.
> 
> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>

This is missing your signed-off-by, and in other patches of this series
your signed-off-by is not the last, as it should be.

Please have a look and fix this and the other instances.

Thanks for this work!

Francesco

Re: [PATCH V8 06/12] arm64: dts: imx8mp: add HDMI irqsteer

[Adam Ford]

On Sun, Feb 4, 2024 at 6:00 AM Francesco Dolcini <francesco@dolcini.it> wrote:
>
> On Sat, Feb 03, 2024 at 10:52:46AM -0600, Adam Ford wrote:
> > From: Lucas Stach <l.stach@pengutronix.de>
> >
> > The HDMI irqsteer is a secondary interrupt controller within the HDMI
> > subsystem that maps all HDMI peripheral IRQs into a single upstream
> > IRQ line.
> >
> > Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
>
> This is missing your signed-off-by, and in other patches of this series

Opps.  I thought I caught all those.

> your signed-off-by is not the last, as it should be.
>
> Please have a look and fix this and the other instances.
>

OK.  I have some work to do on some other portions, so I'll clean up that too.

adam
> Thanks for this work!

Thanks for the feedback.

adam
>
> Francesco
>

Re: [PATCH V8 05/12] arm64: dts: imx8mp: add HDMI power-domains

[Alexander Stein]

Hi Adam,

thanks for working on this.

Am Samstag, 3. Februar 2024, 17:52:45 CET schrieb Adam Ford:
> From: Lucas Stach <l.stach@pengutronix.de>
> 
> This adds the PGC and HDMI blk-ctrl nodes providing power control for
> HDMI subsystem peripherals.
> 
> Signed-off-by: Adam Ford <aford173@gmail.com>
> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
> ---
> V2:  Add missing power-domains hdcp and hrv
> ---
>  arch/arm64/boot/dts/freescale/imx8mp.dtsi | 38 +++++++++++++++++++++++
>  1 file changed, 38 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/freescale/imx8mp.dtsi
> b/arch/arm64/boot/dts/freescale/imx8mp.dtsi index
> 76c73daf546b..5c54073de615 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mp.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
> @@ -836,6 +836,23 @@ pgc_mediamix: power-domain@10 {
>  							 <&clk 
IMX8MP_CLK_MEDIA_APB_ROOT>;
>  					};
> 
> +					pgc_hdmimix: power-
domains@14 {

As per Documentation/devicetree/bindings/power/fsl,imx-gpcv2.yaml the node 
should be called power-domain@.

> +						#power-domain-
cells = <0>;
> +						reg = 
<IMX8MP_POWER_DOMAIN_HDMIMIX>;
> +						clocks = <&clk 
IMX8MP_CLK_HDMI_ROOT>,
> +							 <&clk 
IMX8MP_CLK_HDMI_APB>;
> +						assigned-clocks = 
<&clk IMX8MP_CLK_HDMI_AXI>,
> +								
  <&clk IMX8MP_CLK_HDMI_APB>;
> +						assigned-clock-
parents = <&clk IMX8MP_SYS_PLL2_500M>,
> +								
	 <&clk IMX8MP_SYS_PLL1_133M>;
> +						assigned-clock-
rates = <500000000>, <133000000>;
> +					};
> +
> +					pgc_hdmi_phy: power-
domains@15 {

As per Documentation/devicetree/bindings/power/fsl,imx-gpcv2.yaml the node 
should be called power-domain@.

> +						#power-domain-
cells = <0>;
> +						reg = 
<IMX8MP_POWER_DOMAIN_HDMI_PHY>;
> +					};
> +
>  					pgc_mipi_phy2: power-
domain@16 {
>  						#power-domain-
cells = <0>;
>  						reg = 
<IMX8MP_POWER_DOMAIN_MIPI_PHY2>;
> @@ -1361,6 +1378,27 @@ eqos: ethernet@30bf0000 {
>  				intf_mode = <&gpr 0x4>;
>  				status = "disabled";
>  			};
> +
> +			hdmi_blk_ctrl: blk-ctrl@32fc0000 {
> +				compatible = "fsl,imx8mp-hdmi-blk-
ctrl", "syscon";
> +				reg = <0x32fc0000 0x23c>;
> +				clocks = <&clk IMX8MP_CLK_HDMI_APB>,
> +					 <&clk 
IMX8MP_CLK_HDMI_ROOT>,
> +					 <&clk 
IMX8MP_CLK_HDMI_REF_266M>,
> +					 <&clk IMX8MP_CLK_HDMI_24M>,
> +					 <&clk 
IMX8MP_CLK_HDMI_FDCC_TST>;
> +				clock-names = "apb", "axi", 
"ref_266m", "ref_24m", "fdcc";
> +				power-domains = <&pgc_hdmimix>, 
<&pgc_hdmimix>,
> +						<&pgc_hdmimix>, 
<&pgc_hdmimix>,
> +						<&pgc_hdmimix>, 
<&pgc_hdmimix>,
> +						<&pgc_hdmimix>, 
<&pgc_hdmi_phy>,
> +						<&pgc_hdmimix>, 
<&pgc_hdmimix>;
> +				power-domain-names = "bus", 
"irqsteer", "lcdif",
> +						     "pai", "pvi", 
"trng",
> +						     "hdmi-tx", 
"hdmi-tx-phy",
> +						     "hdcp", 
"hrv";
> +				#power-domain-cells = <1>;
> +			};
>  		};
> 

According to RM this block is part of AIPS4, so it should be below 
hsio_blk_ctrl.

Best regards,
Alexander

>  		aips5: bus@30c00000 {


-- 
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
http://www.tq-group.com/

Re: [PATCH V8 06/12] arm64: dts: imx8mp: add HDMI irqsteer

[Alexander Stein]

Hi Adam,

thanks for working on this.

Am Samstag, 3. Februar 2024, 17:52:46 CET schrieb Adam Ford:
> From: Lucas Stach <l.stach@pengutronix.de>
> 
> The HDMI irqsteer is a secondary interrupt controller within the HDMI
> subsystem that maps all HDMI peripheral IRQs into a single upstream
> IRQ line.
> 
> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
> ---
>  arch/arm64/boot/dts/freescale/imx8mp.dtsi | 13 +++++++++++++
>  1 file changed, 13 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/freescale/imx8mp.dtsi
> b/arch/arm64/boot/dts/freescale/imx8mp.dtsi index
> 5c54073de615..5e51a766f3d9 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mp.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
> @@ -1399,6 +1399,19 @@ hdmi_blk_ctrl: blk-ctrl@32fc0000 {
>  						     "hdcp", 
"hrv";
>  				#power-domain-cells = <1>;
>  			};
> +
> +			irqsteer_hdmi: interrupt-controller@32fc2000 {
> +				compatible = "fsl,imx-irqsteer";
> +				reg = <0x32fc2000 0x44>;
> +				interrupts = <GIC_SPI 43 
IRQ_TYPE_LEVEL_HIGH>;
> +				interrupt-controller;
> +				#interrupt-cells = <1>;
> +				fsl,channel = <1>;
> +				fsl,num-irqs = <64>;
> +				clocks = <&clk IMX8MP_CLK_HDMI_APB>;
> +				clock-names = "ipg";
> +				power-domains = <&hdmi_blk_ctrl 
IMX8MP_HDMIBLK_PD_IRQSTEER>;
> +			};

According to RM this block is part of HDMI_TX which is part of AIPS4, so it 
should be below hsio_blk_ctrl.

Best regards,
Alexander

>  		};
> 
>  		aips5: bus@30c00000 {


-- 
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
http://www.tq-group.com/

Re: [PATCH V8 11/12] arm64: dts: imx8mp: add HDMI display pipeline

[Alexander Stein]

Hi Adam,

thanks for working on this.

Am Samstag, 3. Februar 2024, 17:52:51 CET schrieb Adam Ford:
> From: Lucas Stach <l.stach@pengutronix.de>
> 
> This adds the DT nodes for all the peripherals that make up the
> HDMI display pipeline.
> 
> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
> Signed-off-by: Adam Ford <aford173@gmail.com>
> 
> ---
> V2:  I took this from Lucas' original submission with the following:
>      Removed extra clock from HDMI-TX since it is now part of the
>      power domain
>      Added interrupt-parent to PVI
>      Changed the name of the HDMI tranmitter to fsl,imx8mp-hdmi-tx
>      Added ports to HDMI-tx
> ---
>  arch/arm64/boot/dts/freescale/imx8mp.dtsi | 94 +++++++++++++++++++++++
>  1 file changed, 94 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/freescale/imx8mp.dtsi
> b/arch/arm64/boot/dts/freescale/imx8mp.dtsi index
> 5e51a766f3d9..e84b4f40e570 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mp.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
> @@ -1412,6 +1412,100 @@ irqsteer_hdmi: interrupt-controller@32fc2000 {
>  				clock-names = "ipg";
>  				power-domains = <&hdmi_blk_ctrl 
IMX8MP_HDMIBLK_PD_IRQSTEER>;
>  			};
> +
> +			hdmi_pvi: display-bridge@32fc4000 {
> +				compatible = "fsl,imx8mp-hdmi-pvi";
> +				reg = <0x32fc4000 0x40>;
> +				interrupt-parent = <&irqsteer_hdmi>;
> +				interrupts = <12 IRQ_TYPE_LEVEL_HIGH>;

irqsteer_hdmi has #interrupt-cells = <1>, so IRQ flags should be removed. 
dtbs_check also warns about this.

> +				power-domains = <&hdmi_blk_ctrl 
IMX8MP_HDMIBLK_PD_PVI>;
> +
> +				ports {
> +					#address-cells = <1>;
> +					#size-cells = <0>;
> +
> +					port@0 {
> +						reg = <0>;
> +						pvi_from_lcdif3: 
endpoint {
> +							remote-
endpoint = <&lcdif3_to_pvi>;
> +						};
> +					};
> +
> +					port@1 {
> +						reg = <1>;
> +						pvi_to_hdmi_tx: 
endpoint {
> +							remote-
endpoint = <&hdmi_tx_from_pvi>;
> +						};
> +					};
> +				};
> +			};
> +
> +			lcdif3: display-controller@32fc6000 {
> +				compatible = "fsl,imx8mp-lcdif";
> +				reg = <0x32fc6000 0x238>;
> +				interrupts = <8 IRQ_TYPE_LEVEL_HIGH>;

irqsteer_hdmi has #interrupt-cells = <1>, so IRQ flags should be removed. 
dtbs_check also warns about this.

> +				interrupt-parent = <&irqsteer_hdmi>;
> +				clocks = <&hdmi_tx_phy>,
> +					 <&clk IMX8MP_CLK_HDMI_APB>,
> +					 <&clk 
IMX8MP_CLK_HDMI_ROOT>;
> +				clock-names = "pix", "axi", 
"disp_axi";
> +				power-domains = <&hdmi_blk_ctrl 
IMX8MP_HDMIBLK_PD_LCDIF>;
> +
> +				port {
> +					lcdif3_to_pvi: endpoint {
> +						remote-endpoint = 
<&pvi_from_lcdif3>;
> +					};
> +				};
> +			};
> +
> +			hdmi_tx: hdmi@32fd8000 {
> +				compatible = "fsl,imx8mp-hdmi-tx";
> +				reg = <0x32fd8000 0x7eff>;
> +				interrupts = <0 IRQ_TYPE_LEVEL_HIGH>;

irqsteer_hdmi has #interrupt-cells = <1>, so IRQ flags should be removed. 
dtbs_check also warns about this.

> +				interrupt-parent = <&irqsteer_hdmi>;
> +				clocks = <&clk IMX8MP_CLK_HDMI_APB>,
> +					 <&clk 
IMX8MP_CLK_HDMI_REF_266M>,
> +					 <&clk IMX8MP_CLK_32K>,
> +					 <&hdmi_tx_phy>;
> +				clock-names = "iahb", "isfr", "cec", 
"pix";
> +				assigned-clocks = <&clk 
IMX8MP_CLK_HDMI_REF_266M>;
> +				assigned-clock-parents = <&clk 
IMX8MP_SYS_PLL1_266M>;
> +				power-domains = <&hdmi_blk_ctrl 
IMX8MP_HDMIBLK_PD_HDMI_TX>;
> +				reg-io-width = <1>;
> +				status = "disabled";
> +
> +				ports {
> +					#address-cells = <1>;
> +					#size-cells = <0>;
> +
> +					port@0 {
> +						reg = <0>;
> +
> +						hdmi_tx_from_pvi: 
endpoint {
> +							remote-
endpoint = <&pvi_to_hdmi_tx>;
> +						};
> +					};
> +
> +					port@1 {
> +						reg = <1>;
> +						/* Point endpoint 
to the HDMI connector */
> +					};
> +				};
> +			};
> +
> +			hdmi_tx_phy: phy@32fdff00 {
> +				compatible = "fsl,imx8mp-hdmi-phy";
> +				reg = <0x32fdff00 0x100>;
> +				clocks = <&clk IMX8MP_CLK_HDMI_APB>,
> +					 <&clk IMX8MP_CLK_HDMI_24M>;
> +				clock-names = "apb", "ref";
> +				assigned-clocks = <&clk 
IMX8MP_CLK_HDMI_24M>;
> +				assigned-clock-parents = <&clk 
IMX8MP_CLK_24M>;
> +				power-domains = <&hdmi_blk_ctrl 
IMX8MP_HDMIBLK_PD_HDMI_TX_PHY>;
> +				#clock-cells = <0>;
> +				#phy-cells = <0>;
> +				status = "disabled";
> +			};

According to RM these blocks are part of AIPS4, so it should be below 
hsio_blk_ctrl.

Best regards,
Alexander

>  		};
> 
>  		aips5: bus@30c00000 {


-- 
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
http://www.tq-group.com/

Re: [PATCH V8 02/12] phy: freescale: add Samsung HDMI PHY

[Marco Felsch]

On 24-02-04, Dmitry Baryshkov wrote:
> On Sat, 3 Feb 2024 at 17:53, Adam Ford <aford173@gmail.com> wrote:
> >
> > From: Lucas Stach <l.stach@pengutronix.de>
> >
> > This adds the driver for the Samsung HDMI PHY found on the
> > i.MX8MP SoC.
> >
> > Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
> > Signed-off-by: Adam Ford <aford173@gmail.com>
> > Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com>
> > ---
> > V4:  Make lookup table hex values lower case.
> >
> > V3:  Re-order the Makefile to keep it alphabetical
> >      Remove unused defines
> >
> > V2:  Fixed some whitespace found from checkpatch
> >      Change error handling when enabling apbclk to use dev_err_probe
> >      Rebase on Linux-Next
> >
> >      I (Adam) tried to help move this along, so I took Lucas' patch and
> >      attempted to apply fixes based on feedback.  I don't have
> >      all the history, so apologies for that.
> > ---
> >  drivers/phy/freescale/Kconfig                |    6 +
> >  drivers/phy/freescale/Makefile               |    1 +
> >  drivers/phy/freescale/phy-fsl-samsung-hdmi.c | 1075 ++++++++++++++++++
> >  3 files changed, 1082 insertions(+)
> >  create mode 100644 drivers/phy/freescale/phy-fsl-samsung-hdmi.c
> >
> > diff --git a/drivers/phy/freescale/Kconfig b/drivers/phy/freescale/Kconfig
> > index 853958fb2c06..5c2b73042dfc 100644
> > --- a/drivers/phy/freescale/Kconfig
> > +++ b/drivers/phy/freescale/Kconfig
> > @@ -35,6 +35,12 @@ config PHY_FSL_IMX8M_PCIE
> >           Enable this to add support for the PCIE PHY as found on
> >           i.MX8M family of SOCs.
> >
> > +config PHY_FSL_SAMSUNG_HDMI_PHY
> > +       tristate "Samsung HDMI PHY support"
> > +       depends on OF && HAS_IOMEM
> > +       help
> > +         Enable this to add support for the Samsung HDMI PHY in i.MX8MP.
> > +
> >  endif
> >
> >  config PHY_FSL_LYNX_28G
> > diff --git a/drivers/phy/freescale/Makefile b/drivers/phy/freescale/Makefile
> > index cedb328bc4d2..79e5f16d3ce8 100644
> > --- a/drivers/phy/freescale/Makefile
> > +++ b/drivers/phy/freescale/Makefile
> > @@ -4,3 +4,4 @@ obj-$(CONFIG_PHY_MIXEL_LVDS_PHY)        += phy-fsl-imx8qm-lvds-phy.o
> >  obj-$(CONFIG_PHY_MIXEL_MIPI_DPHY)      += phy-fsl-imx8-mipi-dphy.o
> >  obj-$(CONFIG_PHY_FSL_IMX8M_PCIE)       += phy-fsl-imx8m-pcie.o
> >  obj-$(CONFIG_PHY_FSL_LYNX_28G)         += phy-fsl-lynx-28g.o
> > +obj-$(CONFIG_PHY_FSL_SAMSUNG_HDMI_PHY)  += phy-fsl-samsung-hdmi.o
> > diff --git a/drivers/phy/freescale/phy-fsl-samsung-hdmi.c b/drivers/phy/freescale/phy-fsl-samsung-hdmi.c
> > new file mode 100644
> > index 000000000000..bf0e2299d00f
> > --- /dev/null
> > +++ b/drivers/phy/freescale/phy-fsl-samsung-hdmi.c
> > @@ -0,0 +1,1075 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * Copyright 2020 NXP
> > + * Copyright 2022 Pengutronix, Lucas Stach <kernel@pengutronix.de>
> > + */
> > +
> > +#include <linux/clk-provider.h>
> > +#include <linux/clk.h>
> > +#include <linux/delay.h>
> > +#include <linux/io.h>
> > +#include <linux/iopoll.h>
> > +#include <linux/module.h>
> > +#include <linux/of_device.h>
> > +#include <linux/of.h>
> > +#include <linux/platform_device.h>
> > +#include <linux/pm_runtime.h>
> > +
> > +#define PHY_REG_33             0x84
> > +#define  REG33_MODE_SET_DONE   BIT(7)
> > +#define  REG33_FIX_DA          BIT(1)
> > +
> > +#define PHY_REG_34             0x88
> > +#define  REG34_PHY_READY       BIT(7)
> > +#define  REG34_PLL_LOCK                BIT(6)
> > +#define  REG34_PHY_CLK_READY   BIT(5)
> > +
> > +
> > +#define PHY_PLL_REGS_NUM 48
> > +
> > +struct phy_config {
> > +       u32     clk_rate;
> > +       u8 regs[PHY_PLL_REGS_NUM];
> > +};
> > +
> > +const struct phy_config phy_pll_cfg[] = {
> > +       {       22250000, {
> > +                       0x00, 0xd1, 0x4b, 0xf1, 0x89, 0x88, 0x80, 0x40,
> > +                       0x4f, 0x30, 0x33, 0x65, 0x00, 0x15, 0x25, 0x80,
> > +                       0x6c, 0xf2, 0x67, 0x00, 0x10, 0x8f, 0x30, 0x32,
> > +                       0x60, 0x8f, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
> > +                       0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> > +                       0x00, 0xe0, 0x83, 0x0f, 0x3e, 0xf8, 0x00, 0x00,
> > +               },
> > +       }, {
> > +               23750000, {
> > +                       0x00, 0xd1, 0x50, 0xf1, 0x86, 0x85, 0x80, 0x40,
> > +                       0x4f, 0x30, 0x33, 0x65, 0x00, 0x03, 0x25, 0x80,
> > +                       0x6c, 0xf2, 0x67, 0x00, 0x10, 0x8f, 0x30, 0x32,
> > +                       0x60, 0x8f, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
> > +                       0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> > +                       0x00, 0xe0, 0x83, 0x0f, 0x3e, 0xf8, 0x00, 0x00,
> > +               },
> 
> Generally I see that these entries contain a high level of duplication.
> Could you please extract the common part and a rate-dependent part.
> Next, it would be best if instead of writing the register values via
> the rate LUT, the driver could calculate those values.
> This allows us to support other HDMI modes if the need arises at some point.

Hi Adam,

can you please have a look at: https://lore.kernel.org/all/4830698.GXAFRqVoOG@steina-w/

there we have fixed this already. Not sure which version you picked for
your work.

Regards,
  Marco

> 
> > +       }, {
> > +               24000000, {
> > +                       0x00, 0xd1, 0x50, 0xf0, 0x00, 0x00, 0x80, 0x00,
> > +                       0x4f, 0x30, 0x33, 0x65, 0x00, 0x01, 0x25, 0x80,
> > +                       0x6c, 0xf2, 0x67, 0x00, 0x10, 0x8f, 0x30, 0x32,
> > +                       0x60, 0x8f, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
> > +                       0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> > +                       0x00, 0xe0, 0x83, 0x0f, 0x3e, 0xf8, 0x00, 0x00,
> > +               },
> 
> 
> -- 
> With best wishes
> Dmitry
> 
> 

Re: [PATCH V8 09/12] dt-bindings: display: imx: add binding for i.MX8MP HDMI TX

[Neil Armstrong]

On 03/02/2024 17:52, Adam Ford wrote:
> From: Lucas Stach <l.stach@pengutronix.de>
> 
> The HDMI TX controller on the i.MX8MP SoC is a Synopsys designware IP
> core with a little bit of SoC integration around it.
> 
> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
> Signed-off-by: Adam Ford <aford173@gmail.com>
> 
> ---
> V3:  Change name and location to better idenfity as a bridge and
>       HDMI 2.0a transmitter
> 
>       Fix typos and feedback from Rob and added ports.
> ---
>   .../display/bridge/fsl,imx8mp-hdmi-tx.yaml    | 102 ++++++++++++++++++
>   1 file changed, 102 insertions(+)
>   create mode 100644 Documentation/devicetree/bindings/display/bridge/fsl,imx8mp-hdmi-tx.yaml
> 
> diff --git a/Documentation/devicetree/bindings/display/bridge/fsl,imx8mp-hdmi-tx.yaml b/Documentation/devicetree/bindings/display/bridge/fsl,imx8mp-hdmi-tx.yaml
> new file mode 100644
> index 000000000000..3791c9f4ebab
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/fsl,imx8mp-hdmi-tx.yaml
> @@ -0,0 +1,102 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/bridge/fsl,imx8mp-hdmi-tx.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Freescale i.MX8MP DWC HDMI TX Encoder
> +
> +maintainers:
> +  - Lucas Stach <l.stach@pengutronix.de>
> +
> +description:
> +  The i.MX8MP HDMI transmitter is a Synopsys DesignWare
> +  HDMI 2.0a TX controller IP.
> +
> +allOf:
> +  - $ref: /schemas/display/bridge/synopsys,dw-hdmi.yaml#
> +
> +properties:
> +  compatible:
> +    enum:
> +      - fsl,imx8mp-hdmi-tx
> +
> +  reg-io-width:
> +    const: 1
> +
> +  clocks:
> +    maxItems: 4
> +
> +  clock-names:
> +    items:
> +      - const: iahb
> +      - const: isfr
> +      - const: cec
> +      - const: pix
> +
> +  power-domains:
> +    maxItems: 1
> +
> +  ports:
> +    $ref: /schemas/graph.yaml#/properties/ports
> +
> +    properties:
> +      port@0:
> +        $ref: /schemas/graph.yaml#/properties/port
> +        description: Parallel RGB input port
> +
> +      port@1:
> +        $ref: /schemas/graph.yaml#/properties/port
> +        description: HDMI output port
> +
> +    required:
> +      - port@0
> +      - port@1
> +
> +required:
> +  - compatible
> +  - reg
> +  - clocks
> +  - clock-names
> +  - interrupts
> +  - power-domains
> +  - ports
> +
> +unevaluatedProperties: false
> +
> +examples:
> +  - |
> +    #include <dt-bindings/clock/imx8mp-clock.h>
> +    #include <dt-bindings/interrupt-controller/irq.h>
> +    #include <dt-bindings/power/imx8mp-power.h>
> +
> +    hdmi@32fd8000 {
> +        compatible = "fsl,imx8mp-hdmi-tx";
> +        reg = <0x32fd8000 0x7eff>;
> +        interrupts = <0 IRQ_TYPE_LEVEL_HIGH>;
> +        clocks = <&clk IMX8MP_CLK_HDMI_APB>,
> +                 <&clk IMX8MP_CLK_HDMI_REF_266M>,
> +                 <&clk IMX8MP_CLK_32K>,
> +                 <&hdmi_tx_phy>;
> +        clock-names = "iahb", "isfr", "cec", "pix";
> +        power-domains = <&hdmi_blk_ctrl IMX8MP_HDMIBLK_PD_HDMI_TX>;
> +        reg-io-width = <1>;
> +        ports {
> +           #address-cells = <1>;
> +           #size-cells = <0>;
> +           port@0 {
> +             reg = <0>;
> +
> +             hdmi_tx_from_pvi: endpoint {
> +               remote-endpoint = <&pvi_to_hdmi_tx>;
> +             };
> +          };
> +
> +          port@1 {
> +            reg = <1>;
> +              hdmi_tx_out: endpoint {
> +                remote-endpoint = <&hdmi0_con>;
> +              };
> +          };
> +        };
> +    };

I'll apply patches 9 & 10 once this one is properly reviewed

Thanks,
Neil

Re: (subset) [PATCH V8 00/12] soc: imx8mp: Add support for HDMI

[Neil Armstrong]

Hi,

On Sat, 03 Feb 2024 10:52:40 -0600, Adam Ford wrote:
> The i.MX8M Plus has an HDMI controller, but it depends on two
> other systems, the Parallel Video Interface (PVI) and the
> HDMI PHY from Samsung. The LCDIF controller generates the display
> and routes it to the PVI which converts passes the parallel video
> to the HDMI bridge.  The HDMI system has a corresponding power
> domain controller whose driver was partially written, but the
> device tree for it was never applied, so some changes to the
> power domain should be harmless because they've not really been
> used yet.
> 
> [...]

Thanks, Applied to https://anongit.freedesktop.org/git/drm/drm-misc.git (drm-misc-next)

[07/12] dt-bindings: display: imx: add binding for i.MX8MP HDMI PVI
        https://cgit.freedesktop.org/drm/drm-misc/commit/?id=f490d0cb9360466f6df0def3eccc47fabba9775b
[08/12] drm/bridge: imx: add driver for HDMI TX Parallel Video Interface
        https://cgit.freedesktop.org/drm/drm-misc/commit/?id=059c53e877ca6e723e10490c27c1487a63e66efe

-- 
Neil

Re: [PATCH V8 03/12] dt-bindings: soc: imx: add missing clock and power-domains to imx8mp-hdmi-blk-ctrl

[Rob Herring]

On Sat, 03 Feb 2024 10:52:43 -0600, Adam Ford wrote:
> Per guidance from the NXP downstream kernel, if the clock is
> disabled before HDMI/LCDIF probe, LCDIF will not get pixel
> clock from HDMI PHY and throw an error:
> 
> [CRTC:39:crtc-2] vblank wait timed out
>     WARNING: CPU: 2 PID: 9 at drivers/gpu/drm/drm_atomic_helper.c:
>         1634 drm_atomic_helper_wait_for_vblanks.part.0+0x23c/0x260
> 
> Fix this by adding the fdcc clock to the hdmi_blk_ctrl.  This
> should be safe, since neither this power domain nor the dependent
> HDMI and LCDIF drivers been enabled or added to the SoC device
> tree yet.
> 
> According to Sandor Yu from NXP, "the FDCC clock is not for HDMITX
> in desgin, but it is part of HDMI domain that needed by HDMITX.
> So I think it is reasonable added it to the power domain driver."
> 
> The driver also supports two power domains which are missing from the binding
> that also fix an issue with resuming from suspend.
> 
> Signed-off-by: Adam Ford <aford173@gmail.com>
> ---
> V2:  Update commit message to both show error and give a bit more
>      background.
>      Add missing power domains hdcp and hdrv as pointed out by Marek Vasut
> ---
>  .../soc/imx/fsl,imx8mp-hdmi-blk-ctrl.yaml     | 22 ++++++++++++-------
>  1 file changed, 14 insertions(+), 8 deletions(-)
> 

Reviewed-by: Rob Herring <robh@kernel.org>

Re: [PATCH V8 09/12] dt-bindings: display: imx: add binding for i.MX8MP HDMI TX

[Rob Herring]

On Sat, 03 Feb 2024 10:52:49 -0600, Adam Ford wrote:
> From: Lucas Stach <l.stach@pengutronix.de>
> 
> The HDMI TX controller on the i.MX8MP SoC is a Synopsys designware IP
> core with a little bit of SoC integration around it.
> 
> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
> Signed-off-by: Adam Ford <aford173@gmail.com>
> 
> ---
> V3:  Change name and location to better idenfity as a bridge and
>      HDMI 2.0a transmitter
> 
>      Fix typos and feedback from Rob and added ports.
> ---
>  .../display/bridge/fsl,imx8mp-hdmi-tx.yaml    | 102 ++++++++++++++++++
>  1 file changed, 102 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/display/bridge/fsl,imx8mp-hdmi-tx.yaml
> 

Reviewed-by: Rob Herring <robh@kernel.org>

Re: [PATCH V8 05/12] arm64: dts: imx8mp: add HDMI power-domains

[Adam Ford]

On Mon, Feb 5, 2024 at 1:26 AM Alexander Stein
<alexander.stein@ew.tq-group.com> wrote:
>
> Hi Adam,
>
> thanks for working on this.
>
> Am Samstag, 3. Februar 2024, 17:52:45 CET schrieb Adam Ford:
> > From: Lucas Stach <l.stach@pengutronix.de>
> >
> > This adds the PGC and HDMI blk-ctrl nodes providing power control for
> > HDMI subsystem peripherals.
> >
> > Signed-off-by: Adam Ford <aford173@gmail.com>
> > Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
> > ---
> > V2:  Add missing power-domains hdcp and hrv
> > ---
> >  arch/arm64/boot/dts/freescale/imx8mp.dtsi | 38 +++++++++++++++++++++++
> >  1 file changed, 38 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/freescale/imx8mp.dtsi
> > b/arch/arm64/boot/dts/freescale/imx8mp.dtsi index
> > 76c73daf546b..5c54073de615 100644
> > --- a/arch/arm64/boot/dts/freescale/imx8mp.dtsi
> > +++ b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
> > @@ -836,6 +836,23 @@ pgc_mediamix: power-domain@10 {
> >                                                        <&clk
> IMX8MP_CLK_MEDIA_APB_ROOT>;
> >                                       };
> >
> > +                                     pgc_hdmimix: power-
> domains@14 {
>

Alexander,

Thanks for the feedback.

> As per Documentation/devicetree/bindings/power/fsl,imx-gpcv2.yaml the node
> should be called power-domain@.
>
> > +                                             #power-domain-
> cells = <0>;
> > +                                             reg =
> <IMX8MP_POWER_DOMAIN_HDMIMIX>;
> > +                                             clocks = <&clk
> IMX8MP_CLK_HDMI_ROOT>,
> > +                                                      <&clk
> IMX8MP_CLK_HDMI_APB>;
> > +                                             assigned-clocks =
> <&clk IMX8MP_CLK_HDMI_AXI>,
> > +
>   <&clk IMX8MP_CLK_HDMI_APB>;
> > +                                             assigned-clock-
> parents = <&clk IMX8MP_SYS_PLL2_500M>,
> > +
>          <&clk IMX8MP_SYS_PLL1_133M>;
> > +                                             assigned-clock-
> rates = <500000000>, <133000000>;
> > +                                     };
> > +
> > +                                     pgc_hdmi_phy: power-
> domains@15 {
>
> As per Documentation/devicetree/bindings/power/fsl,imx-gpcv2.yaml the node
> should be called power-domain@.

Whoops.  I totally missed these when I applied them.  I'll have them
fixed on the next spin.
>
> > +                                             #power-domain-
> cells = <0>;
> > +                                             reg =
> <IMX8MP_POWER_DOMAIN_HDMI_PHY>;
> > +                                     };
> > +
> >                                       pgc_mipi_phy2: power-
> domain@16 {
> >                                               #power-domain-
> cells = <0>;
> >                                               reg =
> <IMX8MP_POWER_DOMAIN_MIPI_PHY2>;
> > @@ -1361,6 +1378,27 @@ eqos: ethernet@30bf0000 {
> >                               intf_mode = <&gpr 0x4>;
> >                               status = "disabled";
> >                       };
> > +
> > +                     hdmi_blk_ctrl: blk-ctrl@32fc0000 {
> > +                             compatible = "fsl,imx8mp-hdmi-blk-
> ctrl", "syscon";
> > +                             reg = <0x32fc0000 0x23c>;
> > +                             clocks = <&clk IMX8MP_CLK_HDMI_APB>,
> > +                                      <&clk
> IMX8MP_CLK_HDMI_ROOT>,
> > +                                      <&clk
> IMX8MP_CLK_HDMI_REF_266M>,
> > +                                      <&clk IMX8MP_CLK_HDMI_24M>,
> > +                                      <&clk
> IMX8MP_CLK_HDMI_FDCC_TST>;
> > +                             clock-names = "apb", "axi",
> "ref_266m", "ref_24m", "fdcc";
> > +                             power-domains = <&pgc_hdmimix>,
> <&pgc_hdmimix>,
> > +                                             <&pgc_hdmimix>,
> <&pgc_hdmimix>,
> > +                                             <&pgc_hdmimix>,
> <&pgc_hdmimix>,
> > +                                             <&pgc_hdmimix>,
> <&pgc_hdmi_phy>,
> > +                                             <&pgc_hdmimix>,
> <&pgc_hdmimix>;
> > +                             power-domain-names = "bus",
> "irqsteer", "lcdif",
> > +                                                  "pai", "pvi",
> "trng",
> > +                                                  "hdmi-tx",
> "hdmi-tx-phy",
> > +                                                  "hdcp",
> "hrv";
> > +                             #power-domain-cells = <1>;
> > +                     };
> >               };
> >
>
> According to RM this block is part of AIPS4, so it should be below
> hsio_blk_ctrl.

This is how it was when I got it, but I should have caught it.  Thanks
for that.  It looks like the subsequent HDMI, IRQ_steerting, LCDIF and
PHY ones are also out of place.

adam
>
> Best regards,
> Alexander
>
> >               aips5: bus@30c00000 {
>
>
> --
> TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
> Amtsgericht München, HRB 105018
> Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
> http://www.tq-group.com/
>
>

Re: [PATCH V8 02/12] phy: freescale: add Samsung HDMI PHY

[Adam Ford]

On Mon, Feb 5, 2024 at 2:17 AM Marco Felsch <m.felsch@pengutronix.de> wrote:
>
> On 24-02-04, Dmitry Baryshkov wrote:
> > On Sat, 3 Feb 2024 at 17:53, Adam Ford <aford173@gmail.com> wrote:
> > >
> > > From: Lucas Stach <l.stach@pengutronix.de>
> > >
> > > This adds the driver for the Samsung HDMI PHY found on the
> > > i.MX8MP SoC.
> > >
> > > Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
> > > Signed-off-by: Adam Ford <aford173@gmail.com>
> > > Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com>
> > > ---
> > > V4:  Make lookup table hex values lower case.
> > >
> > > V3:  Re-order the Makefile to keep it alphabetical
> > >      Remove unused defines
> > >
> > > V2:  Fixed some whitespace found from checkpatch
> > >      Change error handling when enabling apbclk to use dev_err_probe
> > >      Rebase on Linux-Next
> > >
> > >      I (Adam) tried to help move this along, so I took Lucas' patch and
> > >      attempted to apply fixes based on feedback.  I don't have
> > >      all the history, so apologies for that.
> > > ---
> > >  drivers/phy/freescale/Kconfig                |    6 +
> > >  drivers/phy/freescale/Makefile               |    1 +
> > >  drivers/phy/freescale/phy-fsl-samsung-hdmi.c | 1075 ++++++++++++++++++
> > >  3 files changed, 1082 insertions(+)
> > >  create mode 100644 drivers/phy/freescale/phy-fsl-samsung-hdmi.c
> > >
> > > diff --git a/drivers/phy/freescale/Kconfig b/drivers/phy/freescale/Kconfig
> > > index 853958fb2c06..5c2b73042dfc 100644
> > > --- a/drivers/phy/freescale/Kconfig
> > > +++ b/drivers/phy/freescale/Kconfig
> > > @@ -35,6 +35,12 @@ config PHY_FSL_IMX8M_PCIE
> > >           Enable this to add support for the PCIE PHY as found on
> > >           i.MX8M family of SOCs.
> > >
> > > +config PHY_FSL_SAMSUNG_HDMI_PHY
> > > +       tristate "Samsung HDMI PHY support"
> > > +       depends on OF && HAS_IOMEM
> > > +       help
> > > +         Enable this to add support for the Samsung HDMI PHY in i.MX8MP.
> > > +
> > >  endif
> > >
> > >  config PHY_FSL_LYNX_28G
> > > diff --git a/drivers/phy/freescale/Makefile b/drivers/phy/freescale/Makefile
> > > index cedb328bc4d2..79e5f16d3ce8 100644
> > > --- a/drivers/phy/freescale/Makefile
> > > +++ b/drivers/phy/freescale/Makefile
> > > @@ -4,3 +4,4 @@ obj-$(CONFIG_PHY_MIXEL_LVDS_PHY)        += phy-fsl-imx8qm-lvds-phy.o
> > >  obj-$(CONFIG_PHY_MIXEL_MIPI_DPHY)      += phy-fsl-imx8-mipi-dphy.o
> > >  obj-$(CONFIG_PHY_FSL_IMX8M_PCIE)       += phy-fsl-imx8m-pcie.o
> > >  obj-$(CONFIG_PHY_FSL_LYNX_28G)         += phy-fsl-lynx-28g.o
> > > +obj-$(CONFIG_PHY_FSL_SAMSUNG_HDMI_PHY)  += phy-fsl-samsung-hdmi.o
> > > diff --git a/drivers/phy/freescale/phy-fsl-samsung-hdmi.c b/drivers/phy/freescale/phy-fsl-samsung-hdmi.c
> > > new file mode 100644
> > > index 000000000000..bf0e2299d00f
> > > --- /dev/null
> > > +++ b/drivers/phy/freescale/phy-fsl-samsung-hdmi.c
> > > @@ -0,0 +1,1075 @@
> > > +// SPDX-License-Identifier: GPL-2.0+
> > > +/*
> > > + * Copyright 2020 NXP
> > > + * Copyright 2022 Pengutronix, Lucas Stach <kernel@pengutronix.de>
> > > + */
> > > +
> > > +#include <linux/clk-provider.h>
> > > +#include <linux/clk.h>
> > > +#include <linux/delay.h>
> > > +#include <linux/io.h>
> > > +#include <linux/iopoll.h>
> > > +#include <linux/module.h>
> > > +#include <linux/of_device.h>
> > > +#include <linux/of.h>
> > > +#include <linux/platform_device.h>
> > > +#include <linux/pm_runtime.h>
> > > +
> > > +#define PHY_REG_33             0x84
> > > +#define  REG33_MODE_SET_DONE   BIT(7)
> > > +#define  REG33_FIX_DA          BIT(1)
> > > +
> > > +#define PHY_REG_34             0x88
> > > +#define  REG34_PHY_READY       BIT(7)
> > > +#define  REG34_PLL_LOCK                BIT(6)
> > > +#define  REG34_PHY_CLK_READY   BIT(5)
> > > +
> > > +
> > > +#define PHY_PLL_REGS_NUM 48
> > > +
> > > +struct phy_config {
> > > +       u32     clk_rate;
> > > +       u8 regs[PHY_PLL_REGS_NUM];
> > > +};
> > > +
> > > +const struct phy_config phy_pll_cfg[] = {
> > > +       {       22250000, {
> > > +                       0x00, 0xd1, 0x4b, 0xf1, 0x89, 0x88, 0x80, 0x40,
> > > +                       0x4f, 0x30, 0x33, 0x65, 0x00, 0x15, 0x25, 0x80,
> > > +                       0x6c, 0xf2, 0x67, 0x00, 0x10, 0x8f, 0x30, 0x32,
> > > +                       0x60, 0x8f, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
> > > +                       0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> > > +                       0x00, 0xe0, 0x83, 0x0f, 0x3e, 0xf8, 0x00, 0x00,
> > > +               },
> > > +       }, {
> > > +               23750000, {
> > > +                       0x00, 0xd1, 0x50, 0xf1, 0x86, 0x85, 0x80, 0x40,
> > > +                       0x4f, 0x30, 0x33, 0x65, 0x00, 0x03, 0x25, 0x80,
> > > +                       0x6c, 0xf2, 0x67, 0x00, 0x10, 0x8f, 0x30, 0x32,
> > > +                       0x60, 0x8f, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
> > > +                       0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> > > +                       0x00, 0xe0, 0x83, 0x0f, 0x3e, 0xf8, 0x00, 0x00,
> > > +               },
> >
> > Generally I see that these entries contain a high level of duplication.
> > Could you please extract the common part and a rate-dependent part.
> > Next, it would be best if instead of writing the register values via
> > the rate LUT, the driver could calculate those values.
> > This allows us to support other HDMI modes if the need arises at some point.
>
> Hi Adam,
>
> can you please have a look at: https://lore.kernel.org/all/4830698.GXAFRqVoOG@steina-w/
>
> there we have fixed this already. Not sure which version you picked for
> your work.

It must have been an earlier version.  I got the list from Fabio, but
I might have also gotten it mixed up.  I'll look at this version and
base my series on it and try to address comments others made.  It'll
likely take me a few days to catch up.

thanks for the pointer.

adam
>
> Regards,
>   Marco
>
> >
> > > +       }, {
> > > +               24000000, {
> > > +                       0x00, 0xd1, 0x50, 0xf0, 0x00, 0x00, 0x80, 0x00,
> > > +                       0x4f, 0x30, 0x33, 0x65, 0x00, 0x01, 0x25, 0x80,
> > > +                       0x6c, 0xf2, 0x67, 0x00, 0x10, 0x8f, 0x30, 0x32,
> > > +                       0x60, 0x8f, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
> > > +                       0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> > > +                       0x00, 0xe0, 0x83, 0x0f, 0x3e, 0xf8, 0x00, 0x00,
> > > +               },
> >
> >
> > --
> > With best wishes
> > Dmitry
> >
> >

Re: (subset) [PATCH V8 00/12] soc: imx8mp: Add support for HDMI

[Neil Armstrong]

Hi,

On Sat, 03 Feb 2024 10:52:40 -0600, Adam Ford wrote:
> The i.MX8M Plus has an HDMI controller, but it depends on two
> other systems, the Parallel Video Interface (PVI) and the
> HDMI PHY from Samsung. The LCDIF controller generates the display
> and routes it to the PVI which converts passes the parallel video
> to the HDMI bridge.  The HDMI system has a corresponding power
> domain controller whose driver was partially written, but the
> device tree for it was never applied, so some changes to the
> power domain should be harmless because they've not really been
> used yet.
> 
> [...]

Thanks, Applied to https://anongit.freedesktop.org/git/drm/drm-misc.git (drm-misc-next)

[09/12] dt-bindings: display: imx: add binding for i.MX8MP HDMI TX
        https://cgit.freedesktop.org/drm/drm-misc/commit/?id=8933d29e7703f6f905bc84186b915b0ab4fe03bb
[10/12] drm/bridge: imx: add bridge wrapper driver for i.MX8MP DWC HDMI
        https://cgit.freedesktop.org/drm/drm-misc/commit/?id=1f36d634670d8001a45fe2f2dcae546819f9c7d8

-- 
Neil

Re: [PATCH V8 08/12] drm/bridge: imx: add driver for HDMI TX Parallel Video Interface

[Nathan Chancellor]

Hi all,

On Sat, Feb 03, 2024 at 10:52:48AM -0600, Adam Ford wrote:
> From: Lucas Stach <l.stach@pengutronix.de>
> 
> This IP block is found in the HDMI subsystem of the i.MX8MP SoC. It has a
> full timing generator and can switch between different video sources. On
> the i.MX8MP however the only supported source is the LCDIF. The block
> just needs to be powered up and told about the polarity of the video
> sync signals to act in bypass mode.
> 
> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> (v7)
> Tested-by: Marek Vasut <marex@denx.de> (v1)
> Tested-by: Luca Ceresoli <luca.ceresoli@bootlin.com> (v7)
> Tested-by: Richard Leitner <richard.leitner@skidata.com> (v2)
> Tested-by: Frieder Schrempf <frieder.schrempf@kontron.de> (v2)
> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> (v3)
> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
> Tested-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
> Tested-by: Fabio Estevam <festevam@gmail.com>
> Signed-off-by: Adam Ford <aford173@gmail.com>

<snip>

> diff --git a/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c b/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c
> new file mode 100644
> index 000000000000..a76b7669fe8a
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c
...
> +static void imx8mp_hdmi_pvi_bridge_enable(struct drm_bridge *bridge,
> +					  struct drm_bridge_state *bridge_state)
> +{
> +	struct drm_atomic_state *state = bridge_state->base.state;
> +	struct imx8mp_hdmi_pvi *pvi = to_imx8mp_hdmi_pvi(bridge);
> +	struct drm_connector_state *conn_state;
> +	const struct drm_display_mode *mode;
> +	struct drm_crtc_state *crtc_state;
> +	struct drm_connector *connector;
> +	u32 bus_flags, val;
> +
> +	connector = drm_atomic_get_new_connector_for_encoder(state, bridge->encoder);
> +	conn_state = drm_atomic_get_new_connector_state(state, connector);
> +	crtc_state = drm_atomic_get_new_crtc_state(state, conn_state->crtc);
> +
> +	if (WARN_ON(pm_runtime_resume_and_get(pvi->dev)))
> +		return;
> +
> +	mode = &crtc_state->adjusted_mode;
> +
> +	val = FIELD_PREP(PVI_CTRL_MODE_MASK, PVI_CTRL_MODE_LCDIF) | PVI_CTRL_EN;
> +
> +	if (mode->flags & DRM_MODE_FLAG_PVSYNC)
> +		val |= PVI_CTRL_OP_VSYNC_POL | PVI_CTRL_INP_VSYNC_POL;
> +
> +	if (mode->flags & DRM_MODE_FLAG_PHSYNC)
> +		val |= PVI_CTRL_OP_HSYNC_POL | PVI_CTRL_INP_HSYNC_POL;
> +
> +	if (pvi->next_bridge->timings)
> +		bus_flags = pvi->next_bridge->timings->input_bus_flags;
> +	else if (bridge_state)
> +		bus_flags = bridge_state->input_bus_cfg.flags;
> +
> +	if (bus_flags & DRM_BUS_FLAG_DE_HIGH)
> +		val |= PVI_CTRL_OP_DE_POL | PVI_CTRL_INP_DE_POL;
> +
> +	writel(val, pvi->regs + HTX_PVI_CTRL);
> +}

Apologies if this has already been reported or fixed, I searched lore
and did not find anything. Clang warns (or errors with CONFIG_WERROR=y)
for this function:

  drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c:81:11: error: variable 'bus_flags' is used uninitialized whenever 'if' condition is false [-Werror,-Wsometimes-uninitialized]
     81 |         else if (bridge_state)
        |                  ^~~~~~~~~~~~
  drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c:84:6: note: uninitialized use occurs here
     84 |         if (bus_flags & DRM_BUS_FLAG_DE_HIGH)
        |             ^~~~~~~~~
  drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c:81:7: note: remove the 'if' if its condition is always true
     81 |         else if (bridge_state)
        |              ^~~~~~~~~~~~~~~~~
     82 |                 bus_flags = bridge_state->input_bus_cfg.flags;
  drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c:60:15: note: initialize the variable 'bus_flags' to silence this warning
     60 |         u32 bus_flags, val;
        |                      ^
        |                       = 0
  1 error generated.

This seems legitimate. If bridge_state can be NULL, should bus_flags be
initialized to zero like it suggests or should that 'else if' be turned
into a plain 'else'? I am happy to send a patch with that guidance.

Cheers,
Nathan

Re: [PATCH V8 01/12] dt-bindings: phy: add binding for the i.MX8MP HDMI PHY

[Luca Ceresoli]

On Sat,  3 Feb 2024 10:52:41 -0600
Adam Ford <aford173@gmail.com> wrote:

> From: Lucas Stach <l.stach@pengutronix.de>
> 
> Add a DT binding for the HDMI PHY found on the i.MX8MP SoC.
> 
> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
> Signed-off-by: Adam Ford <aford173@gmail.com>
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>

Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>

-- 
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [PATCH V8 02/12] phy: freescale: add Samsung HDMI PHY

[Luca Ceresoli]

On Sat,  3 Feb 2024 10:52:42 -0600
Adam Ford <aford173@gmail.com> wrote:

> From: Lucas Stach <l.stach@pengutronix.de>
> 
> This adds the driver for the Samsung HDMI PHY found on the
> i.MX8MP SoC.
> 
> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
> Signed-off-by: Adam Ford <aford173@gmail.com>
> Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com>

[...]

> +#define PHY_REG_33		0x84
> +#define  REG33_MODE_SET_DONE	BIT(7)
> +#define  REG33_FIX_DA		BIT(1)
> +
> +#define PHY_REG_34		0x88
> +#define  REG34_PHY_READY	BIT(7)
> +#define  REG34_PLL_LOCK		BIT(6)
> +#define  REG34_PHY_CLK_READY	BIT(5)
> +
> +

Nitpick: only one empty line here.

> +#define PHY_PLL_REGS_NUM 48

[...]

> +static int phy_clk_register(struct fsl_samsung_hdmi_phy *phy)
> +{
> +	struct device *dev = phy->dev;
> +	struct device_node *np = dev->of_node;
> +	struct clk_init_data init;
> +	const char *parent_name;
> +	struct clk *phyclk;
> +	int ret;
> +
> +	parent_name = __clk_get_name(phy->refclk);
> +
> +	init.parent_names = &parent_name;
> +	init.num_parents = 1;
> +	init.flags = 0;
> +	init.name = "hdmi_pclk";
> +	init.ops = &phy_clk_ops;
> +
> +	phy->hw.init = &init;
> +
> +	phyclk = devm_clk_register(dev, &phy->hw);
> +	if (IS_ERR(phyclk))
> +		return dev_err_probe(dev, PTR_ERR(phyclk),
> +				     "failed to register clock\n");
> +
> +	ret = of_clk_add_provider(np, of_clk_src_simple_get, phyclk);

Ouch:

> This function is *deprecated*. Use of_clk_add_hw_provider() instead.

Appears as an easy replacement though.

Otherwise looks good.

Luca

-- 
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [PATCH V8 07/12] dt-bindings: display: imx: add binding for i.MX8MP HDMI PVI

[Luca Ceresoli]

Hi Adam,

On Sat,  3 Feb 2024 10:52:47 -0600
Adam Ford <aford173@gmail.com> wrote:

> From: Lucas Stach <l.stach@pengutronix.de>
> 
> Add binding for the i.MX8MP HDMI parallel video interface block.
> 
> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
> Signed-off-by: Adam Ford <aford173@gmail.com>

Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>

-- 
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [PATCH V8 09/12] dt-bindings: display: imx: add binding for i.MX8MP HDMI TX

[Luca Ceresoli]

On Sat,  3 Feb 2024 10:52:49 -0600
Adam Ford <aford173@gmail.com> wrote:

> From: Lucas Stach <l.stach@pengutronix.de>
> 
> The HDMI TX controller on the i.MX8MP SoC is a Synopsys designware IP
> core with a little bit of SoC integration around it.
> 
> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
> Signed-off-by: Adam Ford <aford173@gmail.com>

[...]

> +examples:
> +  - |
> +    #include <dt-bindings/clock/imx8mp-clock.h>
> +    #include <dt-bindings/interrupt-controller/irq.h>
> +    #include <dt-bindings/power/imx8mp-power.h>
> +
> +    hdmi@32fd8000 {
> +        compatible = "fsl,imx8mp-hdmi-tx";
> +        reg = <0x32fd8000 0x7eff>;
> +        interrupts = <0 IRQ_TYPE_LEVEL_HIGH>;
> +        clocks = <&clk IMX8MP_CLK_HDMI_APB>,
> +                 <&clk IMX8MP_CLK_HDMI_REF_266M>,
> +                 <&clk IMX8MP_CLK_32K>,
> +                 <&hdmi_tx_phy>;
> +        clock-names = "iahb", "isfr", "cec", "pix";
> +        power-domains = <&hdmi_blk_ctrl IMX8MP_HDMIBLK_PD_HDMI_TX>;
> +        reg-io-width = <1>;
> +        ports {
> +           #address-cells = <1>;
> +           #size-cells = <0>;
> +           port@0 {
> +             reg = <0>;
> +
> +             hdmi_tx_from_pvi: endpoint {
> +               remote-endpoint = <&pvi_to_hdmi_tx>;
> +             };
> +          };
> +
> +          port@1 {
> +            reg = <1>;
> +              hdmi_tx_out: endpoint {

Two excess indenting spaces on this line (port@0 is correct).
Also, I think there should an empty line between properties and nodes.

With these fixed:
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>

Luca

-- 
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [PATCH V8 10/12] drm/bridge: imx: add bridge wrapper driver for i.MX8MP DWC HDMI

[Luca Ceresoli]

On Sat,  3 Feb 2024 10:52:50 -0600
Adam Ford <aford173@gmail.com> wrote:

> From: Lucas Stach <l.stach@pengutronix.de>
> 
> Add a simple wrapper driver for the DWC HDMI bridge driver that
> implements the few bits that are necessary to abstract the i.MX8MP
> SoC integration.
> 
> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Tested-by: Marek Vasut <marex@denx.de>
> Tested-by: Adam Ford <aford173@gmail.com> #imx8mp-beacon
> Tested-by: Richard Leitner <richard.leitner@skidata.com>
> Tested-by: Frieder Schrempf <frieder.schrempf@kontron.de>
> Tested-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
> Signed-off-by:  Adam Ford <aford173@gmail.com>

Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>

-- 
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [PATCH V8 08/12] drm/bridge: imx: add driver for HDMI TX Parallel Video Interface

[Adam Ford]

On Tue, Feb 6, 2024 at 11:06 AM Nathan Chancellor <nathan@kernel.org> wrote:
>
> Hi all,
>
> On Sat, Feb 03, 2024 at 10:52:48AM -0600, Adam Ford wrote:
> > From: Lucas Stach <l.stach@pengutronix.de>
> >
> > This IP block is found in the HDMI subsystem of the i.MX8MP SoC. It has a
> > full timing generator and can switch between different video sources. On
> > the i.MX8MP however the only supported source is the LCDIF. The block
> > just needs to be powered up and told about the polarity of the video
> > sync signals to act in bypass mode.
> >
> > Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
> > Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> (v7)
> > Tested-by: Marek Vasut <marex@denx.de> (v1)
> > Tested-by: Luca Ceresoli <luca.ceresoli@bootlin.com> (v7)
> > Tested-by: Richard Leitner <richard.leitner@skidata.com> (v2)
> > Tested-by: Frieder Schrempf <frieder.schrempf@kontron.de> (v2)
> > Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> (v3)
> > Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
> > Tested-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
> > Tested-by: Fabio Estevam <festevam@gmail.com>
> > Signed-off-by: Adam Ford <aford173@gmail.com>
>
> <snip>
>
> > diff --git a/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c b/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c
> > new file mode 100644
> > index 000000000000..a76b7669fe8a
> > --- /dev/null
> > +++ b/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c
> ...
> > +static void imx8mp_hdmi_pvi_bridge_enable(struct drm_bridge *bridge,
> > +                                       struct drm_bridge_state *bridge_state)
> > +{
> > +     struct drm_atomic_state *state = bridge_state->base.state;
> > +     struct imx8mp_hdmi_pvi *pvi = to_imx8mp_hdmi_pvi(bridge);
> > +     struct drm_connector_state *conn_state;
> > +     const struct drm_display_mode *mode;
> > +     struct drm_crtc_state *crtc_state;
> > +     struct drm_connector *connector;
> > +     u32 bus_flags, val;
> > +
> > +     connector = drm_atomic_get_new_connector_for_encoder(state, bridge->encoder);
> > +     conn_state = drm_atomic_get_new_connector_state(state, connector);
> > +     crtc_state = drm_atomic_get_new_crtc_state(state, conn_state->crtc);
> > +
> > +     if (WARN_ON(pm_runtime_resume_and_get(pvi->dev)))
> > +             return;
> > +
> > +     mode = &crtc_state->adjusted_mode;
> > +
> > +     val = FIELD_PREP(PVI_CTRL_MODE_MASK, PVI_CTRL_MODE_LCDIF) | PVI_CTRL_EN;
> > +
> > +     if (mode->flags & DRM_MODE_FLAG_PVSYNC)
> > +             val |= PVI_CTRL_OP_VSYNC_POL | PVI_CTRL_INP_VSYNC_POL;
> > +
> > +     if (mode->flags & DRM_MODE_FLAG_PHSYNC)
> > +             val |= PVI_CTRL_OP_HSYNC_POL | PVI_CTRL_INP_HSYNC_POL;
> > +
> > +     if (pvi->next_bridge->timings)
> > +             bus_flags = pvi->next_bridge->timings->input_bus_flags;
> > +     else if (bridge_state)
> > +             bus_flags = bridge_state->input_bus_cfg.flags;
> > +
> > +     if (bus_flags & DRM_BUS_FLAG_DE_HIGH)
> > +             val |= PVI_CTRL_OP_DE_POL | PVI_CTRL_INP_DE_POL;
> > +
> > +     writel(val, pvi->regs + HTX_PVI_CTRL);
> > +}
>
> Apologies if this has already been reported or fixed, I searched lore
> and did not find anything. Clang warns (or errors with CONFIG_WERROR=y)
> for this function:
>
>   drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c:81:11: error: variable 'bus_flags' is used uninitialized whenever 'if' condition is false [-Werror,-Wsometimes-uninitialized]
>      81 |         else if (bridge_state)
>         |                  ^~~~~~~~~~~~
>   drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c:84:6: note: uninitialized use occurs here
>      84 |         if (bus_flags & DRM_BUS_FLAG_DE_HIGH)
>         |             ^~~~~~~~~
>   drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c:81:7: note: remove the 'if' if its condition is always true
>      81 |         else if (bridge_state)
>         |              ^~~~~~~~~~~~~~~~~
>      82 |                 bus_flags = bridge_state->input_bus_cfg.flags;
>   drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c:60:15: note: initialize the variable 'bus_flags' to silence this warning
>      60 |         u32 bus_flags, val;
>         |                      ^
>         |                       = 0
>   1 error generated.
>
> This seems legitimate. If bridge_state can be NULL, should bus_flags be
> initialized to zero like it suggests or should that 'else if' be turned
> into a plain 'else'? I am happy to send a patch with that guidance.

I don't think we can turn the else-if into a blind else, because in
order to make bus_flags point to bridge_state->input_bus_cfg.flags,
bridge_state must not be NULL, but we could add an additional else to
set bus_flags to 0, but I think the simplest thing to do would be to
set bus_flags = 0 at the initialization on line 60 as it suggests.

If you agree, I can submit a patch later tonight.  I need to fix
another issue found by the build-bot [1]  to make line 113 return NULL
instead of 0 anyway.  I figured I could just fix them both at the same
time.

adam

[1] - https://lore.kernel.org/oe-kbuild-all/202402062134.a6CqAt3s-lkp@intel.com/

>
> Cheers,
> Nathan

Re: [PATCH V8 08/12] drm/bridge: imx: add driver for HDMI TX Parallel Video Interface

[Nathan Chancellor]

On Tue, Feb 06, 2024 at 12:50:16PM -0600, Adam Ford wrote:
> On Tue, Feb 6, 2024 at 11:06 AM Nathan Chancellor <nathan@kernel.org> wrote:
> >
> > Hi all,
> >
> > On Sat, Feb 03, 2024 at 10:52:48AM -0600, Adam Ford wrote:
> > > From: Lucas Stach <l.stach@pengutronix.de>
> > >
> > > This IP block is found in the HDMI subsystem of the i.MX8MP SoC. It has a
> > > full timing generator and can switch between different video sources. On
> > > the i.MX8MP however the only supported source is the LCDIF. The block
> > > just needs to be powered up and told about the polarity of the video
> > > sync signals to act in bypass mode.
> > >
> > > Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
> > > Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> (v7)
> > > Tested-by: Marek Vasut <marex@denx.de> (v1)
> > > Tested-by: Luca Ceresoli <luca.ceresoli@bootlin.com> (v7)
> > > Tested-by: Richard Leitner <richard.leitner@skidata.com> (v2)
> > > Tested-by: Frieder Schrempf <frieder.schrempf@kontron.de> (v2)
> > > Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> (v3)
> > > Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
> > > Tested-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
> > > Tested-by: Fabio Estevam <festevam@gmail.com>
> > > Signed-off-by: Adam Ford <aford173@gmail.com>
> >
> > <snip>
> >
> > > diff --git a/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c b/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c
> > > new file mode 100644
> > > index 000000000000..a76b7669fe8a
> > > --- /dev/null
> > > +++ b/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c
> > ...
> > > +static void imx8mp_hdmi_pvi_bridge_enable(struct drm_bridge *bridge,
> > > +                                       struct drm_bridge_state *bridge_state)
> > > +{
> > > +     struct drm_atomic_state *state = bridge_state->base.state;
> > > +     struct imx8mp_hdmi_pvi *pvi = to_imx8mp_hdmi_pvi(bridge);
> > > +     struct drm_connector_state *conn_state;
> > > +     const struct drm_display_mode *mode;
> > > +     struct drm_crtc_state *crtc_state;
> > > +     struct drm_connector *connector;
> > > +     u32 bus_flags, val;
> > > +
> > > +     connector = drm_atomic_get_new_connector_for_encoder(state, bridge->encoder);
> > > +     conn_state = drm_atomic_get_new_connector_state(state, connector);
> > > +     crtc_state = drm_atomic_get_new_crtc_state(state, conn_state->crtc);
> > > +
> > > +     if (WARN_ON(pm_runtime_resume_and_get(pvi->dev)))
> > > +             return;
> > > +
> > > +     mode = &crtc_state->adjusted_mode;
> > > +
> > > +     val = FIELD_PREP(PVI_CTRL_MODE_MASK, PVI_CTRL_MODE_LCDIF) | PVI_CTRL_EN;
> > > +
> > > +     if (mode->flags & DRM_MODE_FLAG_PVSYNC)
> > > +             val |= PVI_CTRL_OP_VSYNC_POL | PVI_CTRL_INP_VSYNC_POL;
> > > +
> > > +     if (mode->flags & DRM_MODE_FLAG_PHSYNC)
> > > +             val |= PVI_CTRL_OP_HSYNC_POL | PVI_CTRL_INP_HSYNC_POL;
> > > +
> > > +     if (pvi->next_bridge->timings)
> > > +             bus_flags = pvi->next_bridge->timings->input_bus_flags;
> > > +     else if (bridge_state)
> > > +             bus_flags = bridge_state->input_bus_cfg.flags;
> > > +
> > > +     if (bus_flags & DRM_BUS_FLAG_DE_HIGH)
> > > +             val |= PVI_CTRL_OP_DE_POL | PVI_CTRL_INP_DE_POL;
> > > +
> > > +     writel(val, pvi->regs + HTX_PVI_CTRL);
> > > +}
> >
> > Apologies if this has already been reported or fixed, I searched lore
> > and did not find anything. Clang warns (or errors with CONFIG_WERROR=y)
> > for this function:
> >
> >   drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c:81:11: error: variable 'bus_flags' is used uninitialized whenever 'if' condition is false [-Werror,-Wsometimes-uninitialized]
> >      81 |         else if (bridge_state)
> >         |                  ^~~~~~~~~~~~
> >   drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c:84:6: note: uninitialized use occurs here
> >      84 |         if (bus_flags & DRM_BUS_FLAG_DE_HIGH)
> >         |             ^~~~~~~~~
> >   drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c:81:7: note: remove the 'if' if its condition is always true
> >      81 |         else if (bridge_state)
> >         |              ^~~~~~~~~~~~~~~~~
> >      82 |                 bus_flags = bridge_state->input_bus_cfg.flags;
> >   drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c:60:15: note: initialize the variable 'bus_flags' to silence this warning
> >      60 |         u32 bus_flags, val;
> >         |                      ^
> >         |                       = 0
> >   1 error generated.
> >
> > This seems legitimate. If bridge_state can be NULL, should bus_flags be
> > initialized to zero like it suggests or should that 'else if' be turned
> > into a plain 'else'? I am happy to send a patch with that guidance.
> 
> I don't think we can turn the else-if into a blind else, because in
> order to make bus_flags point to bridge_state->input_bus_cfg.flags,
> bridge_state must not be NULL, but we could add an additional else to
> set bus_flags to 0, but I think the simplest thing to do would be to
> set bus_flags = 0 at the initialization on line 60 as it suggests.
> 
> If you agree, I can submit a patch later tonight.  I need to fix
> another issue found by the build-bot [1]  to make line 113 return NULL
> instead of 0 anyway.  I figured I could just fix them both at the same
> time.
> 
> [1] - https://lore.kernel.org/oe-kbuild-all/202402062134.a6CqAt3s-lkp@intel.com/

Seems reasonable to me, thanks!

Nathan

Re: [PATCH V8 00/12] soc: imx8mp: Add support for HDMI

[Joao Paulo Goncalves]

>The i.MX8M Plus has an HDMI controller, but it depends on two
>other systems, the Parallel Video Interface (PVI) and the
>HDMI PHY from Samsung. The LCDIF controller generates the display
>and routes it to the PVI which converts passes the parallel video
>to the HDMI bridge.  The HDMI system has a corresponding power
>domain controller whose driver was partially written, but the
>device tree for it was never applied, so some changes to the
>power domain should be harmless because they've not really been
>used yet.

>This series is adapted from multiple series from Lucas Stach with
>edits and suggestions from feedback from various series, but it
>since it's difficult to use and test them independently,
>I merged them into on unified series.  The version history is a
>bit ambiguous since different components were submitted at different
times and had different amount of retries.  In an effort to merge them
>I used the highest version attempt.

Tested-by: Joao Paulo Goncalves <joao.goncalves@toradex.com>

Tested on Toradex Verdin-iMX8MP.

Thanks!

Regards,
Joao Paulo Goncalves

Re: [PATCH V8 09/12] dt-bindings: display: imx: add binding for i.MX8MP HDMI TX

[Alexander Stein]

Hi all,

Am Samstag, 3. Februar 2024, 17:52:49 CET schrieb Adam Ford:
> From: Lucas Stach <l.stach@pengutronix.de>
> 
> The HDMI TX controller on the i.MX8MP SoC is a Synopsys designware IP
> core with a little bit of SoC integration around it.
> 
> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
> Signed-off-by: Adam Ford <aford173@gmail.com>
> 
> ---
> V3:  Change name and location to better idenfity as a bridge and
>      HDMI 2.0a transmitter
> 
>      Fix typos and feedback from Rob and added ports.
> ---
>  .../display/bridge/fsl,imx8mp-hdmi-tx.yaml    | 102 ++++++++++++++++++
>  1 file changed, 102 insertions(+)
>  create mode 100644
> Documentation/devicetree/bindings/display/bridge/fsl,imx8mp-hdmi-tx.yaml
> 
> diff --git
> a/Documentation/devicetree/bindings/display/bridge/fsl,imx8mp-hdmi-tx.yaml
> b/Documentation/devicetree/bindings/display/bridge/fsl,imx8mp-hdmi-tx.yaml
> new file mode 100644
> index 000000000000..3791c9f4ebab
> --- /dev/null
> +++
> b/Documentation/devicetree/bindings/display/bridge/fsl,imx8mp-hdmi-tx.yaml
> @@ -0,0 +1,102 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/bridge/fsl,imx8mp-hdmi-tx.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Freescale i.MX8MP DWC HDMI TX Encoder
> +
> +maintainers:
> +  - Lucas Stach <l.stach@pengutronix.de>
> +
> +description:
> +  The i.MX8MP HDMI transmitter is a Synopsys DesignWare
> +  HDMI 2.0a TX controller IP.
> +
> +allOf:
> +  - $ref: /schemas/display/bridge/synopsys,dw-hdmi.yaml#
> +
> +properties:
> +  compatible:
> +    enum:
> +      - fsl,imx8mp-hdmi-tx
> +
> +  reg-io-width:
> +    const: 1
> +
> +  clocks:
> +    maxItems: 4
> +
> +  clock-names:
> +    items:
> +      - const: iahb
> +      - const: isfr
> +      - const: cec
> +      - const: pix
> +
> +  power-domains:
> +    maxItems: 1
> +
> +  ports:
> +    $ref: /schemas/graph.yaml#/properties/ports
> +
> +    properties:
> +      port@0:
> +        $ref: /schemas/graph.yaml#/properties/port
> +        description: Parallel RGB input port
> +
> +      port@1:
> +        $ref: /schemas/graph.yaml#/properties/port
> +        description: HDMI output port
> +
> +    required:
> +      - port@0
> +      - port@1

Is this really correct that port@1 is required? AFAICS this host already 
supports HPD and DDC by itself, so there is no need for a dedicated HDMI 
connector.
With the current state of the drivers this output port is completely ignored 
anyway. Yet it works for a lot of people.

Best regards,
Alexander

> +
> +required:
> +  - compatible
> +  - reg
> +  - clocks
> +  - clock-names
> +  - interrupts
> +  - power-domains
> +  - ports
> +
> +unevaluatedProperties: false
> +
> +examples:
> +  - |
> +    #include <dt-bindings/clock/imx8mp-clock.h>
> +    #include <dt-bindings/interrupt-controller/irq.h>
> +    #include <dt-bindings/power/imx8mp-power.h>
> +
> +    hdmi@32fd8000 {
> +        compatible = "fsl,imx8mp-hdmi-tx";
> +        reg = <0x32fd8000 0x7eff>;
> +        interrupts = <0 IRQ_TYPE_LEVEL_HIGH>;
> +        clocks = <&clk IMX8MP_CLK_HDMI_APB>,
> +                 <&clk IMX8MP_CLK_HDMI_REF_266M>,
> +                 <&clk IMX8MP_CLK_32K>,
> +                 <&hdmi_tx_phy>;
> +        clock-names = "iahb", "isfr", "cec", "pix";
> +        power-domains = <&hdmi_blk_ctrl IMX8MP_HDMIBLK_PD_HDMI_TX>;
> +        reg-io-width = <1>;
> +        ports {
> +           #address-cells = <1>;
> +           #size-cells = <0>;
> +           port@0 {
> +             reg = <0>;
> +
> +             hdmi_tx_from_pvi: endpoint {
> +               remote-endpoint = <&pvi_to_hdmi_tx>;
> +             };
> +          };
> +
> +          port@1 {
> +            reg = <1>;
> +              hdmi_tx_out: endpoint {
> +                remote-endpoint = <&hdmi0_con>;
> +              };
> +          };
> +        };
> +    };


-- 
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
http://www.tq-group.com/

Re: [PATCH V8 09/12] dt-bindings: display: imx: add binding for i.MX8MP HDMI TX

[Laurent Pinchart]

On Fri, Feb 16, 2024 at 10:05:26AM +0100, Alexander Stein wrote:
> Hi all,
> 
> Am Samstag, 3. Februar 2024, 17:52:49 CET schrieb Adam Ford:
> > From: Lucas Stach <l.stach@pengutronix.de>
> > 
> > The HDMI TX controller on the i.MX8MP SoC is a Synopsys designware IP
> > core with a little bit of SoC integration around it.
> > 
> > Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
> > Signed-off-by: Adam Ford <aford173@gmail.com>
> > 
> > ---
> > V3:  Change name and location to better idenfity as a bridge and
> >      HDMI 2.0a transmitter
> > 
> >      Fix typos and feedback from Rob and added ports.
> > ---
> >  .../display/bridge/fsl,imx8mp-hdmi-tx.yaml    | 102 ++++++++++++++++++
> >  1 file changed, 102 insertions(+)
> >  create mode 100644
> > Documentation/devicetree/bindings/display/bridge/fsl,imx8mp-hdmi-tx.yaml
> > 
> > diff --git
> > a/Documentation/devicetree/bindings/display/bridge/fsl,imx8mp-hdmi-tx.yaml
> > b/Documentation/devicetree/bindings/display/bridge/fsl,imx8mp-hdmi-tx.yaml
> > new file mode 100644
> > index 000000000000..3791c9f4ebab
> > --- /dev/null
> > +++
> > b/Documentation/devicetree/bindings/display/bridge/fsl,imx8mp-hdmi-tx.yaml
> > @@ -0,0 +1,102 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/display/bridge/fsl,imx8mp-hdmi-tx.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Freescale i.MX8MP DWC HDMI TX Encoder
> > +
> > +maintainers:
> > +  - Lucas Stach <l.stach@pengutronix.de>
> > +
> > +description:
> > +  The i.MX8MP HDMI transmitter is a Synopsys DesignWare
> > +  HDMI 2.0a TX controller IP.
> > +
> > +allOf:
> > +  - $ref: /schemas/display/bridge/synopsys,dw-hdmi.yaml#
> > +
> > +properties:
> > +  compatible:
> > +    enum:
> > +      - fsl,imx8mp-hdmi-tx
> > +
> > +  reg-io-width:
> > +    const: 1
> > +
> > +  clocks:
> > +    maxItems: 4
> > +
> > +  clock-names:
> > +    items:
> > +      - const: iahb
> > +      - const: isfr
> > +      - const: cec
> > +      - const: pix
> > +
> > +  power-domains:
> > +    maxItems: 1
> > +
> > +  ports:
> > +    $ref: /schemas/graph.yaml#/properties/ports
> > +
> > +    properties:
> > +      port@0:
> > +        $ref: /schemas/graph.yaml#/properties/port
> > +        description: Parallel RGB input port
> > +
> > +      port@1:
> > +        $ref: /schemas/graph.yaml#/properties/port
> > +        description: HDMI output port
> > +
> > +    required:
> > +      - port@0
> > +      - port@1
> 
> Is this really correct that port@1 is required? AFAICS this host already 
> supports HPD and DDC by itself, so there is no need for a dedicated HDMI 
> connector.

The chip has an HDMI output, so there's an output port.

> With the current state of the drivers this output port is completely ignored 
> anyway. Yet it works for a lot of people.

DT bindings describe the hardware. From a DT point of view, tt's fine
for drivers to ignore the port (that may or may not be true from a DRM
point of view, but that's a separate discussion).

> > +
> > +required:
> > +  - compatible
> > +  - reg
> > +  - clocks
> > +  - clock-names
> > +  - interrupts
> > +  - power-domains
> > +  - ports
> > +
> > +unevaluatedProperties: false
> > +
> > +examples:
> > +  - |
> > +    #include <dt-bindings/clock/imx8mp-clock.h>
> > +    #include <dt-bindings/interrupt-controller/irq.h>
> > +    #include <dt-bindings/power/imx8mp-power.h>
> > +
> > +    hdmi@32fd8000 {
> > +        compatible = "fsl,imx8mp-hdmi-tx";
> > +        reg = <0x32fd8000 0x7eff>;
> > +        interrupts = <0 IRQ_TYPE_LEVEL_HIGH>;
> > +        clocks = <&clk IMX8MP_CLK_HDMI_APB>,
> > +                 <&clk IMX8MP_CLK_HDMI_REF_266M>,
> > +                 <&clk IMX8MP_CLK_32K>,
> > +                 <&hdmi_tx_phy>;
> > +        clock-names = "iahb", "isfr", "cec", "pix";
> > +        power-domains = <&hdmi_blk_ctrl IMX8MP_HDMIBLK_PD_HDMI_TX>;
> > +        reg-io-width = <1>;
> > +        ports {
> > +           #address-cells = <1>;
> > +           #size-cells = <0>;
> > +           port@0 {
> > +             reg = <0>;
> > +
> > +             hdmi_tx_from_pvi: endpoint {
> > +               remote-endpoint = <&pvi_to_hdmi_tx>;
> > +             };
> > +          };
> > +
> > +          port@1 {
> > +            reg = <1>;
> > +              hdmi_tx_out: endpoint {
> > +                remote-endpoint = <&hdmi0_con>;
> > +              };
> > +          };
> > +        };
> > +    };

-- 
Regards,

Laurent Pinchart

Re: [PATCH V8 09/12] dt-bindings: display: imx: add binding for i.MX8MP HDMI TX

[Adam Ford]

On Fri, Feb 16, 2024 at 3:05 AM Alexander Stein
<alexander.stein@ew.tq-group.com> wrote:
>
> Hi all,
>
> Am Samstag, 3. Februar 2024, 17:52:49 CET schrieb Adam Ford:
> > From: Lucas Stach <l.stach@pengutronix.de>
> >
> > The HDMI TX controller on the i.MX8MP SoC is a Synopsys designware IP
> > core with a little bit of SoC integration around it.
> >
> > Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
> > Signed-off-by: Adam Ford <aford173@gmail.com>
> >
> > ---
> > V3:  Change name and location to better idenfity as a bridge and
> >      HDMI 2.0a transmitter
> >
> >      Fix typos and feedback from Rob and added ports.
> > ---
> >  .../display/bridge/fsl,imx8mp-hdmi-tx.yaml    | 102 ++++++++++++++++++
> >  1 file changed, 102 insertions(+)
> >  create mode 100644
> > Documentation/devicetree/bindings/display/bridge/fsl,imx8mp-hdmi-tx.yaml
> >
> > diff --git
> > a/Documentation/devicetree/bindings/display/bridge/fsl,imx8mp-hdmi-tx.yaml
> > b/Documentation/devicetree/bindings/display/bridge/fsl,imx8mp-hdmi-tx.yaml
> > new file mode 100644
> > index 000000000000..3791c9f4ebab
> > --- /dev/null
> > +++
> > b/Documentation/devicetree/bindings/display/bridge/fsl,imx8mp-hdmi-tx.yaml
> > @@ -0,0 +1,102 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/display/bridge/fsl,imx8mp-hdmi-tx.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Freescale i.MX8MP DWC HDMI TX Encoder
> > +
> > +maintainers:
> > +  - Lucas Stach <l.stach@pengutronix.de>
> > +
> > +description:
> > +  The i.MX8MP HDMI transmitter is a Synopsys DesignWare
> > +  HDMI 2.0a TX controller IP.
> > +
> > +allOf:
> > +  - $ref: /schemas/display/bridge/synopsys,dw-hdmi.yaml#
> > +
> > +properties:
> > +  compatible:
> > +    enum:
> > +      - fsl,imx8mp-hdmi-tx
> > +
> > +  reg-io-width:
> > +    const: 1
> > +
> > +  clocks:
> > +    maxItems: 4
> > +
> > +  clock-names:
> > +    items:
> > +      - const: iahb
> > +      - const: isfr
> > +      - const: cec
> > +      - const: pix
> > +
> > +  power-domains:
> > +    maxItems: 1
> > +
> > +  ports:
> > +    $ref: /schemas/graph.yaml#/properties/ports
> > +
> > +    properties:
> > +      port@0:
> > +        $ref: /schemas/graph.yaml#/properties/port
> > +        description: Parallel RGB input port
> > +
> > +      port@1:
> > +        $ref: /schemas/graph.yaml#/properties/port
> > +        description: HDMI output port
> > +
> > +    required:
> > +      - port@0
> > +      - port@1
>
> Is this really correct that port@1 is required? AFAICS this host already
> supports HPD and DDC by itself, so there is no need for a dedicated HDMI
> connector.
> With the current state of the drivers this output port is completely ignored
> anyway. Yet it works for a lot of people.

One of the feedback responses Lucas got was that it was missing the
reference to the HDMI connector, so I added it as a response to that
feedback.  I have tried device trees with and without it, and it
doesn't impact anything, but It seems like there may be a requirement
for it.

adam
>
> Best regards,
> Alexander
>
> > +
> > +required:
> > +  - compatible
> > +  - reg
> > +  - clocks
> > +  - clock-names
> > +  - interrupts
> > +  - power-domains
> > +  - ports
> > +
> > +unevaluatedProperties: false
> > +
> > +examples:
> > +  - |
> > +    #include <dt-bindings/clock/imx8mp-clock.h>
> > +    #include <dt-bindings/interrupt-controller/irq.h>
> > +    #include <dt-bindings/power/imx8mp-power.h>
> > +
> > +    hdmi@32fd8000 {
> > +        compatible = "fsl,imx8mp-hdmi-tx";
> > +        reg = <0x32fd8000 0x7eff>;
> > +        interrupts = <0 IRQ_TYPE_LEVEL_HIGH>;
> > +        clocks = <&clk IMX8MP_CLK_HDMI_APB>,
> > +                 <&clk IMX8MP_CLK_HDMI_REF_266M>,
> > +                 <&clk IMX8MP_CLK_32K>,
> > +                 <&hdmi_tx_phy>;
> > +        clock-names = "iahb", "isfr", "cec", "pix";
> > +        power-domains = <&hdmi_blk_ctrl IMX8MP_HDMIBLK_PD_HDMI_TX>;
> > +        reg-io-width = <1>;
> > +        ports {
> > +           #address-cells = <1>;
> > +           #size-cells = <0>;
> > +           port@0 {
> > +             reg = <0>;
> > +
> > +             hdmi_tx_from_pvi: endpoint {
> > +               remote-endpoint = <&pvi_to_hdmi_tx>;
> > +             };
> > +          };
> > +
> > +          port@1 {
> > +            reg = <1>;
> > +              hdmi_tx_out: endpoint {
> > +                remote-endpoint = <&hdmi0_con>;
> > +              };
> > +          };
> > +        };
> > +    };
>
>
> --
> TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
> Amtsgericht München, HRB 105018
> Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
> http://www.tq-group.com/
>
>

Re: [PATCH V8 09/12] dt-bindings: display: imx: add binding for i.MX8MP HDMI TX

[Alexander Stein]

Am Freitag, 16. Februar 2024, 12:31:12 CET schrieb Adam Ford:
> On Fri, Feb 16, 2024 at 3:05 AM Alexander Stein
> 
> <alexander.stein@ew.tq-group.com> wrote:
> > Hi all,
> > 
> > Am Samstag, 3. Februar 2024, 17:52:49 CET schrieb Adam Ford:
> > > From: Lucas Stach <l.stach@pengutronix.de>
> > > 
> > > The HDMI TX controller on the i.MX8MP SoC is a Synopsys designware IP
> > > core with a little bit of SoC integration around it.
> > > 
> > > Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
> > > Signed-off-by: Adam Ford <aford173@gmail.com>
> > > 
> > > ---
> > > V3:  Change name and location to better idenfity as a bridge and
> > > 
> > >      HDMI 2.0a transmitter
> > >      
> > >      Fix typos and feedback from Rob and added ports.
> > > 
> > > ---
> > > 
> > >  .../display/bridge/fsl,imx8mp-hdmi-tx.yaml    | 102 ++++++++++++++++++
> > >  1 file changed, 102 insertions(+)
> > >  create mode 100644
> > > 
> > > Documentation/devicetree/bindings/display/bridge/fsl,imx8mp-hdmi-tx.yaml
> > > 
> > > diff --git
> > > a/Documentation/devicetree/bindings/display/bridge/fsl,imx8mp-hdmi-tx.ya
> > > ml
> > > b/Documentation/devicetree/bindings/display/bridge/fsl,imx8mp-hdmi-tx.ya
> > > ml
> > > new file mode 100644
> > > index 000000000000..3791c9f4ebab
> > > --- /dev/null
> > > +++
> > > b/Documentation/devicetree/bindings/display/bridge/fsl,imx8mp-hdmi-tx.ya
> > > ml
> > > @@ -0,0 +1,102 @@
> > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > +%YAML 1.2
> > > +---
> > > +$id:
> > > http://devicetree.org/schemas/display/bridge/fsl,imx8mp-hdmi-tx.yaml#
> > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > +
> > > +title: Freescale i.MX8MP DWC HDMI TX Encoder
> > > +
> > > +maintainers:
> > > +  - Lucas Stach <l.stach@pengutronix.de>
> > > +
> > > +description:
> > > +  The i.MX8MP HDMI transmitter is a Synopsys DesignWare
> > > +  HDMI 2.0a TX controller IP.
> > > +
> > > +allOf:
> > > +  - $ref: /schemas/display/bridge/synopsys,dw-hdmi.yaml#
> > > +
> > > +properties:
> > > +  compatible:
> > > +    enum:
> > > +      - fsl,imx8mp-hdmi-tx
> > > +
> > > +  reg-io-width:
> > > +    const: 1
> > > +
> > > +  clocks:
> > > +    maxItems: 4
> > > +
> > > +  clock-names:
> > > +    items:
> > > +      - const: iahb
> > > +      - const: isfr
> > > +      - const: cec
> > > +      - const: pix
> > > +
> > > +  power-domains:
> > > +    maxItems: 1
> > > +
> > > +  ports:
> > > +    $ref: /schemas/graph.yaml#/properties/ports
> > > +
> > > +    properties:
> > > +      port@0:
> > > +        $ref: /schemas/graph.yaml#/properties/port
> > > +        description: Parallel RGB input port
> > > +
> > > +      port@1:
> > > +        $ref: /schemas/graph.yaml#/properties/port
> > > +        description: HDMI output port
> > > +
> > > +    required:
> > > +      - port@0
> > > +      - port@1
> > 
> > Is this really correct that port@1 is required? AFAICS this host already
> > supports HPD and DDC by itself, so there is no need for a dedicated HDMI
> > connector.
> > With the current state of the drivers this output port is completely
> > ignored anyway. Yet it works for a lot of people.
> 
> One of the feedback responses Lucas got was that it was missing the
> reference to the HDMI connector, so I added it as a response to that
> feedback.  I have tried device trees with and without it, and it
> doesn't impact anything, but It seems like there may be a requirement
> for it.

Yes, I noticed as well. A specified connector is completely ignored.
One reason is that dw_hdmi_plat_data.output_port is unsed in drivers/gpu/drm/
bridge/imx/imx8mp-hdmi-tx.c. Another one is that without 
DRM_BRIDGE_ATTACH_NO_CONNECTOR support in drivers/gpu/drm/mxsfb/lcdif_drv.c 
nothing changes.

Best regards,
Alexander

> adam
> 
> > Best regards,
> > Alexander
> > 
> > > +
> > > +required:
> > > +  - compatible
> > > +  - reg
> > > +  - clocks
> > > +  - clock-names
> > > +  - interrupts
> > > +  - power-domains
> > > +  - ports
> > > +
> > > +unevaluatedProperties: false
> > > +
> > > +examples:
> > > +  - |
> > > +    #include <dt-bindings/clock/imx8mp-clock.h>
> > > +    #include <dt-bindings/interrupt-controller/irq.h>
> > > +    #include <dt-bindings/power/imx8mp-power.h>
> > > +
> > > +    hdmi@32fd8000 {
> > > +        compatible = "fsl,imx8mp-hdmi-tx";
> > > +        reg = <0x32fd8000 0x7eff>;
> > > +        interrupts = <0 IRQ_TYPE_LEVEL_HIGH>;
> > > +        clocks = <&clk IMX8MP_CLK_HDMI_APB>,
> > > +                 <&clk IMX8MP_CLK_HDMI_REF_266M>,
> > > +                 <&clk IMX8MP_CLK_32K>,
> > > +                 <&hdmi_tx_phy>;
> > > +        clock-names = "iahb", "isfr", "cec", "pix";
> > > +        power-domains = <&hdmi_blk_ctrl IMX8MP_HDMIBLK_PD_HDMI_TX>;
> > > +        reg-io-width = <1>;
> > > +        ports {
> > > +           #address-cells = <1>;
> > > +           #size-cells = <0>;
> > > +           port@0 {
> > > +             reg = <0>;
> > > +
> > > +             hdmi_tx_from_pvi: endpoint {
> > > +               remote-endpoint = <&pvi_to_hdmi_tx>;
> > > +             };
> > > +          };
> > > +
> > > +          port@1 {
> > > +            reg = <1>;
> > > +              hdmi_tx_out: endpoint {
> > > +                remote-endpoint = <&hdmi0_con>;
> > > +              };
> > > +          };
> > > +        };
> > > +    };
> > 
> > --
> > TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
> > Amtsgericht München, HRB 105018
> > Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
> > http://www.tq-group.com/


-- 
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
http://www.tq-group.com/

Re: [PATCH V8 00/12] soc: imx8mp: Add support for HDMI

[Tommaso Merciai]

Hi Adam, Lucas,
Thanks for this series.

This series make HDMI work on evk.
All is working properly on my side.

Tested on: Linux imx8mp-lpddr4-evk 6.9.0-rc1.
Hope this help.

Tested-by: Tommaso Merciai <tomm.merciai@gmail.com>

Thanks & Regards,
Tommaso

On Sat, Feb 03, 2024 at 10:52:40AM -0600, Adam Ford wrote:
> The i.MX8M Plus has an HDMI controller, but it depends on two
> other systems, the Parallel Video Interface (PVI) and the
> HDMI PHY from Samsung. The LCDIF controller generates the display
> and routes it to the PVI which converts passes the parallel video
> to the HDMI bridge.  The HDMI system has a corresponding power
> domain controller whose driver was partially written, but the
> device tree for it was never applied, so some changes to the
> power domain should be harmless because they've not really been
> used yet.
> 
> This series is adapted from multiple series from Lucas Stach with
> edits and suggestions from feedback from various series, but it
> since it's difficult to use and test them independently,
> I merged them into on unified series.  The version history is a
> bit ambiguous since different components were submitted at different
> times and had different amount of retries.  In an effort to merge them
> I used the highest version attempt.
> 
> Adam Ford (3):
>   dt-bindings: soc: imx: add missing clock and power-domains to
>     imx8mp-hdmi-blk-ctrl
>   pmdomain: imx8mp-blk-ctrl: imx8mp_blk: Add fdcc clock to hdmimix
>     domain
>   arm64: defconfig: Enable DRM_IMX8MP_DW_HDMI_BRIDGE as module
> 
> Lucas Stach (9):
>   dt-bindings: phy: add binding for the i.MX8MP HDMI PHY
>   phy: freescale: add Samsung HDMI PHY
>   arm64: dts: imx8mp: add HDMI power-domains
>   arm64: dts: imx8mp: add HDMI irqsteer
>   dt-bindings: display: imx: add binding for i.MX8MP HDMI PVI
>   drm/bridge: imx: add driver for HDMI TX Parallel Video Interface
>   dt-bindings: display: imx: add binding for i.MX8MP HDMI TX
>   drm/bridge: imx: add bridge wrapper driver for i.MX8MP DWC HDMI
>   arm64: dts: imx8mp: add HDMI display pipeline
> 
>  .../display/bridge/fsl,imx8mp-hdmi-tx.yaml    |  102 ++
>  .../display/imx/fsl,imx8mp-hdmi-pvi.yaml      |   84 ++
>  .../bindings/phy/fsl,imx8mp-hdmi-phy.yaml     |   62 +
>  .../soc/imx/fsl,imx8mp-hdmi-blk-ctrl.yaml     |   22 +-
>  arch/arm64/boot/dts/freescale/imx8mp.dtsi     |  145 +++
>  arch/arm64/configs/defconfig                  |    1 +
>  drivers/gpu/drm/bridge/imx/Kconfig            |   18 +
>  drivers/gpu/drm/bridge/imx/Makefile           |    2 +
>  drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c  |  207 ++++
>  drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx.c   |  154 +++
>  drivers/phy/freescale/Kconfig                 |    6 +
>  drivers/phy/freescale/Makefile                |    1 +
>  drivers/phy/freescale/phy-fsl-samsung-hdmi.c  | 1075 +++++++++++++++++
>  drivers/pmdomain/imx/imx8mp-blk-ctrl.c        |   10 +-
>  14 files changed, 1876 insertions(+), 13 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/display/bridge/fsl,imx8mp-hdmi-tx.yaml
>  create mode 100644 Documentation/devicetree/bindings/display/imx/fsl,imx8mp-hdmi-pvi.yaml
>  create mode 100644 Documentation/devicetree/bindings/phy/fsl,imx8mp-hdmi-phy.yaml
>  create mode 100644 drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c
>  create mode 100644 drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx.c
>  create mode 100644 drivers/phy/freescale/phy-fsl-samsung-hdmi.c
> 
> -- 
> 2.43.0
> 
> 

Re: [PATCH V8 00/12] soc: imx8mp: Add support for HDMI

[Laurent Pinchart]

Hi Tommaso,

On Mon, Mar 25, 2024 at 10:48:56PM +0100, Tommaso Merciai wrote:
> Hi Adam, Lucas,
> Thanks for this series.
> 
> This series make HDMI work on evk.
> All is working properly on my side.
> 
> Tested on: Linux imx8mp-lpddr4-evk 6.9.0-rc1.
> Hope this help.
> 
> Tested-by: Tommaso Merciai <tomm.merciai@gmail.com>

The DRM side has been merged already. The only missing patches are for
the PHY, and the latest version can be found in
https://lore.kernel.org/linux-phy/20240227220444.77566-1-aford173@gmail.com/.
You can test that series and send a Tested-by tag. I'm crossing my
fingers and hoping it will be merged in v6.10.

> On Sat, Feb 03, 2024 at 10:52:40AM -0600, Adam Ford wrote:
> > The i.MX8M Plus has an HDMI controller, but it depends on two
> > other systems, the Parallel Video Interface (PVI) and the
> > HDMI PHY from Samsung. The LCDIF controller generates the display
> > and routes it to the PVI which converts passes the parallel video
> > to the HDMI bridge.  The HDMI system has a corresponding power
> > domain controller whose driver was partially written, but the
> > device tree for it was never applied, so some changes to the
> > power domain should be harmless because they've not really been
> > used yet.
> > 
> > This series is adapted from multiple series from Lucas Stach with
> > edits and suggestions from feedback from various series, but it
> > since it's difficult to use and test them independently,
> > I merged them into on unified series.  The version history is a
> > bit ambiguous since different components were submitted at different
> > times and had different amount of retries.  In an effort to merge them
> > I used the highest version attempt.
> > 
> > Adam Ford (3):
> >   dt-bindings: soc: imx: add missing clock and power-domains to
> >     imx8mp-hdmi-blk-ctrl
> >   pmdomain: imx8mp-blk-ctrl: imx8mp_blk: Add fdcc clock to hdmimix
> >     domain
> >   arm64: defconfig: Enable DRM_IMX8MP_DW_HDMI_BRIDGE as module
> > 
> > Lucas Stach (9):
> >   dt-bindings: phy: add binding for the i.MX8MP HDMI PHY
> >   phy: freescale: add Samsung HDMI PHY
> >   arm64: dts: imx8mp: add HDMI power-domains
> >   arm64: dts: imx8mp: add HDMI irqsteer
> >   dt-bindings: display: imx: add binding for i.MX8MP HDMI PVI
> >   drm/bridge: imx: add driver for HDMI TX Parallel Video Interface
> >   dt-bindings: display: imx: add binding for i.MX8MP HDMI TX
> >   drm/bridge: imx: add bridge wrapper driver for i.MX8MP DWC HDMI
> >   arm64: dts: imx8mp: add HDMI display pipeline
> > 
> >  .../display/bridge/fsl,imx8mp-hdmi-tx.yaml    |  102 ++
> >  .../display/imx/fsl,imx8mp-hdmi-pvi.yaml      |   84 ++
> >  .../bindings/phy/fsl,imx8mp-hdmi-phy.yaml     |   62 +
> >  .../soc/imx/fsl,imx8mp-hdmi-blk-ctrl.yaml     |   22 +-
> >  arch/arm64/boot/dts/freescale/imx8mp.dtsi     |  145 +++
> >  arch/arm64/configs/defconfig                  |    1 +
> >  drivers/gpu/drm/bridge/imx/Kconfig            |   18 +
> >  drivers/gpu/drm/bridge/imx/Makefile           |    2 +
> >  drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c  |  207 ++++
> >  drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx.c   |  154 +++
> >  drivers/phy/freescale/Kconfig                 |    6 +
> >  drivers/phy/freescale/Makefile                |    1 +
> >  drivers/phy/freescale/phy-fsl-samsung-hdmi.c  | 1075 +++++++++++++++++
> >  drivers/pmdomain/imx/imx8mp-blk-ctrl.c        |   10 +-
> >  14 files changed, 1876 insertions(+), 13 deletions(-)
> >  create mode 100644 Documentation/devicetree/bindings/display/bridge/fsl,imx8mp-hdmi-tx.yaml
> >  create mode 100644 Documentation/devicetree/bindings/display/imx/fsl,imx8mp-hdmi-pvi.yaml
> >  create mode 100644 Documentation/devicetree/bindings/phy/fsl,imx8mp-hdmi-phy.yaml
> >  create mode 100644 drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c
> >  create mode 100644 drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx.c
> >  create mode 100644 drivers/phy/freescale/phy-fsl-samsung-hdmi.c

-- 
Regards,

Laurent Pinchart

Re: [PATCH V8 00/12] soc: imx8mp: Add support for HDMI

[Tommaso Merciai]

Hi Laurent,

On Tue, Mar 26, 2024 at 12:03:38AM +0200, Laurent Pinchart wrote:
> Hi Tommaso,
> 
> On Mon, Mar 25, 2024 at 10:48:56PM +0100, Tommaso Merciai wrote:
> > Hi Adam, Lucas,
> > Thanks for this series.
> > 
> > This series make HDMI work on evk.
> > All is working properly on my side.
> > 
> > Tested on: Linux imx8mp-lpddr4-evk 6.9.0-rc1.
> > Hope this help.
> > 
> > Tested-by: Tommaso Merciai <tomm.merciai@gmail.com>
> 
> The DRM side has been merged already. The only missing patches are for
> the PHY, and the latest version can be found in
> https://lore.kernel.org/linux-phy/20240227220444.77566-1-aford173@gmail.com/.
> You can test that series and send a Tested-by tag. I'm crossing my
> fingers and hoping it will be merged in v6.10.
(same here :) )

Thanks for sharing! :)

To be honest I test all this series rebasing my alvium next branch on top of media_stage/master (6.9.0-rc1)
All is working properly on my side.
I found v8 into the commit msg here: https://patches.linaro.org/project/linux-pm/patch/20240203165307.7806-9-aford173@gmail.com/
then I'm thinking this is the latest.

I'm going to switch to your suggestion that looks more recent :)

Thanks again,
Tommaso

> 
> > On Sat, Feb 03, 2024 at 10:52:40AM -0600, Adam Ford wrote:
> > > The i.MX8M Plus has an HDMI controller, but it depends on two
> > > other systems, the Parallel Video Interface (PVI) and the
> > > HDMI PHY from Samsung. The LCDIF controller generates the display
> > > and routes it to the PVI which converts passes the parallel video
> > > to the HDMI bridge.  The HDMI system has a corresponding power
> > > domain controller whose driver was partially written, but the
> > > device tree for it was never applied, so some changes to the
> > > power domain should be harmless because they've not really been
> > > used yet.
> > > 
> > > This series is adapted from multiple series from Lucas Stach with
> > > edits and suggestions from feedback from various series, but it
> > > since it's difficult to use and test them independently,
> > > I merged them into on unified series.  The version history is a
> > > bit ambiguous since different components were submitted at different
> > > times and had different amount of retries.  In an effort to merge them
> > > I used the highest version attempt.
> > > 
> > > Adam Ford (3):
> > >   dt-bindings: soc: imx: add missing clock and power-domains to
> > >     imx8mp-hdmi-blk-ctrl
> > >   pmdomain: imx8mp-blk-ctrl: imx8mp_blk: Add fdcc clock to hdmimix
> > >     domain
> > >   arm64: defconfig: Enable DRM_IMX8MP_DW_HDMI_BRIDGE as module
> > > 
> > > Lucas Stach (9):
> > >   dt-bindings: phy: add binding for the i.MX8MP HDMI PHY
> > >   phy: freescale: add Samsung HDMI PHY
> > >   arm64: dts: imx8mp: add HDMI power-domains
> > >   arm64: dts: imx8mp: add HDMI irqsteer
> > >   dt-bindings: display: imx: add binding for i.MX8MP HDMI PVI
> > >   drm/bridge: imx: add driver for HDMI TX Parallel Video Interface
> > >   dt-bindings: display: imx: add binding for i.MX8MP HDMI TX
> > >   drm/bridge: imx: add bridge wrapper driver for i.MX8MP DWC HDMI
> > >   arm64: dts: imx8mp: add HDMI display pipeline
> > > 
> > >  .../display/bridge/fsl,imx8mp-hdmi-tx.yaml    |  102 ++
> > >  .../display/imx/fsl,imx8mp-hdmi-pvi.yaml      |   84 ++
> > >  .../bindings/phy/fsl,imx8mp-hdmi-phy.yaml     |   62 +
> > >  .../soc/imx/fsl,imx8mp-hdmi-blk-ctrl.yaml     |   22 +-
> > >  arch/arm64/boot/dts/freescale/imx8mp.dtsi     |  145 +++
> > >  arch/arm64/configs/defconfig                  |    1 +
> > >  drivers/gpu/drm/bridge/imx/Kconfig            |   18 +
> > >  drivers/gpu/drm/bridge/imx/Makefile           |    2 +
> > >  drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c  |  207 ++++
> > >  drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx.c   |  154 +++
> > >  drivers/phy/freescale/Kconfig                 |    6 +
> > >  drivers/phy/freescale/Makefile                |    1 +
> > >  drivers/phy/freescale/phy-fsl-samsung-hdmi.c  | 1075 +++++++++++++++++
> > >  drivers/pmdomain/imx/imx8mp-blk-ctrl.c        |   10 +-
> > >  14 files changed, 1876 insertions(+), 13 deletions(-)
> > >  create mode 100644 Documentation/devicetree/bindings/display/bridge/fsl,imx8mp-hdmi-tx.yaml
> > >  create mode 100644 Documentation/devicetree/bindings/display/imx/fsl,imx8mp-hdmi-pvi.yaml
> > >  create mode 100644 Documentation/devicetree/bindings/phy/fsl,imx8mp-hdmi-phy.yaml
> > >  create mode 100644 drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c
> > >  create mode 100644 drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx.c
> > >  create mode 100644 drivers/phy/freescale/phy-fsl-samsung-hdmi.c
> 
> -- 
> Regards,
> 
> Laurent Pinchart

Re: [PATCH V8 00/12] soc: imx8mp: Add support for HDMI

[Adam Ford]

On Tue, Mar 26, 2024 at 2:46 AM Tommaso Merciai <tomm.merciai@gmail.com> wrote:
>
> Hi Laurent,
>
> On Tue, Mar 26, 2024 at 12:03:38AM +0200, Laurent Pinchart wrote:
> > Hi Tommaso,
> >
> > On Mon, Mar 25, 2024 at 10:48:56PM +0100, Tommaso Merciai wrote:
> > > Hi Adam, Lucas,
> > > Thanks for this series.
> > >
> > > This series make HDMI work on evk.
> > > All is working properly on my side.
> > >
> > > Tested on: Linux imx8mp-lpddr4-evk 6.9.0-rc1.
> > > Hope this help.
> > >
> > > Tested-by: Tommaso Merciai <tomm.merciai@gmail.com>
> >
> > The DRM side has been merged already. The only missing patches are for
> > the PHY, and the latest version can be found in
> > https://lore.kernel.org/linux-phy/20240227220444.77566-1-aford173@gmail.com/.
> > You can test that series and send a Tested-by tag. I'm crossing my
> > fingers and hoping it will be merged in v6.10.
> (same here :) )
>
> Thanks for sharing! :)
>
> To be honest I test all this series rebasing my alvium next branch on top of media_stage/master (6.9.0-rc1)
> All is working properly on my side.
> I found v8 into the commit msg here: https://patches.linaro.org/project/linux-pm/patch/20240203165307.7806-9-aford173@gmail.com/
> then I'm thinking this is the latest.
>
> I'm going to switch to your suggestion that looks more recent :)

Sorry about the confusion.  I was confused by the versioning too when
I pulled from different parts of Lucas' stuff.  Since varying
components were applied at different times, and the remaining part was
based on the wrong starting point and not applied, I reverted back to
the versioning of the PHY which was the only remaining part other than
device tree stuff.

adam
>
> Thanks again,
> Tommaso
>
> >
> > > On Sat, Feb 03, 2024 at 10:52:40AM -0600, Adam Ford wrote:
> > > > The i.MX8M Plus has an HDMI controller, but it depends on two
> > > > other systems, the Parallel Video Interface (PVI) and the
> > > > HDMI PHY from Samsung. The LCDIF controller generates the display
> > > > and routes it to the PVI which converts passes the parallel video
> > > > to the HDMI bridge.  The HDMI system has a corresponding power
> > > > domain controller whose driver was partially written, but the
> > > > device tree for it was never applied, so some changes to the
> > > > power domain should be harmless because they've not really been
> > > > used yet.
> > > >
> > > > This series is adapted from multiple series from Lucas Stach with
> > > > edits and suggestions from feedback from various series, but it
> > > > since it's difficult to use and test them independently,
> > > > I merged them into on unified series.  The version history is a
> > > > bit ambiguous since different components were submitted at different
> > > > times and had different amount of retries.  In an effort to merge them
> > > > I used the highest version attempt.
> > > >
> > > > Adam Ford (3):
> > > >   dt-bindings: soc: imx: add missing clock and power-domains to
> > > >     imx8mp-hdmi-blk-ctrl
> > > >   pmdomain: imx8mp-blk-ctrl: imx8mp_blk: Add fdcc clock to hdmimix
> > > >     domain
> > > >   arm64: defconfig: Enable DRM_IMX8MP_DW_HDMI_BRIDGE as module
> > > >
> > > > Lucas Stach (9):
> > > >   dt-bindings: phy: add binding for the i.MX8MP HDMI PHY
> > > >   phy: freescale: add Samsung HDMI PHY
> > > >   arm64: dts: imx8mp: add HDMI power-domains
> > > >   arm64: dts: imx8mp: add HDMI irqsteer
> > > >   dt-bindings: display: imx: add binding for i.MX8MP HDMI PVI
> > > >   drm/bridge: imx: add driver for HDMI TX Parallel Video Interface
> > > >   dt-bindings: display: imx: add binding for i.MX8MP HDMI TX
> > > >   drm/bridge: imx: add bridge wrapper driver for i.MX8MP DWC HDMI
> > > >   arm64: dts: imx8mp: add HDMI display pipeline
> > > >
> > > >  .../display/bridge/fsl,imx8mp-hdmi-tx.yaml    |  102 ++
> > > >  .../display/imx/fsl,imx8mp-hdmi-pvi.yaml      |   84 ++
> > > >  .../bindings/phy/fsl,imx8mp-hdmi-phy.yaml     |   62 +
> > > >  .../soc/imx/fsl,imx8mp-hdmi-blk-ctrl.yaml     |   22 +-
> > > >  arch/arm64/boot/dts/freescale/imx8mp.dtsi     |  145 +++
> > > >  arch/arm64/configs/defconfig                  |    1 +
> > > >  drivers/gpu/drm/bridge/imx/Kconfig            |   18 +
> > > >  drivers/gpu/drm/bridge/imx/Makefile           |    2 +
> > > >  drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c  |  207 ++++
> > > >  drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx.c   |  154 +++
> > > >  drivers/phy/freescale/Kconfig                 |    6 +
> > > >  drivers/phy/freescale/Makefile                |    1 +
> > > >  drivers/phy/freescale/phy-fsl-samsung-hdmi.c  | 1075 +++++++++++++++++
> > > >  drivers/pmdomain/imx/imx8mp-blk-ctrl.c        |   10 +-
> > > >  14 files changed, 1876 insertions(+), 13 deletions(-)
> > > >  create mode 100644 Documentation/devicetree/bindings/display/bridge/fsl,imx8mp-hdmi-tx.yaml
> > > >  create mode 100644 Documentation/devicetree/bindings/display/imx/fsl,imx8mp-hdmi-pvi.yaml
> > > >  create mode 100644 Documentation/devicetree/bindings/phy/fsl,imx8mp-hdmi-phy.yaml
> > > >  create mode 100644 drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c
> > > >  create mode 100644 drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx.c
> > > >  create mode 100644 drivers/phy/freescale/phy-fsl-samsung-hdmi.c
> >
> > --
> > Regards,
> >
> > Laurent Pinchart

Re: [PATCH V8 00/12] soc: imx8mp: Add support for HDMI

[Tommaso Merciai]

Hi Adam,

On Tue, Mar 26, 2024 at 06:43:26AM -0500, Adam Ford wrote:
> On Tue, Mar 26, 2024 at 2:46 AM Tommaso Merciai <tomm.merciai@gmail.com> wrote:
> >
> > Hi Laurent,
> >
> > On Tue, Mar 26, 2024 at 12:03:38AM +0200, Laurent Pinchart wrote:
> > > Hi Tommaso,
> > >
> > > On Mon, Mar 25, 2024 at 10:48:56PM +0100, Tommaso Merciai wrote:
> > > > Hi Adam, Lucas,
> > > > Thanks for this series.
> > > >
> > > > This series make HDMI work on evk.
> > > > All is working properly on my side.
> > > >
> > > > Tested on: Linux imx8mp-lpddr4-evk 6.9.0-rc1.
> > > > Hope this help.
> > > >
> > > > Tested-by: Tommaso Merciai <tomm.merciai@gmail.com>
> > >
> > > The DRM side has been merged already. The only missing patches are for
> > > the PHY, and the latest version can be found in
> > > https://lore.kernel.org/linux-phy/20240227220444.77566-1-aford173@gmail.com/.
> > > You can test that series and send a Tested-by tag. I'm crossing my
> > > fingers and hoping it will be merged in v6.10.
> > (same here :) )
> >
> > Thanks for sharing! :)
> >
> > To be honest I test all this series rebasing my alvium next branch on top of media_stage/master (6.9.0-rc1)
> > All is working properly on my side.
> > I found v8 into the commit msg here: https://patches.linaro.org/project/linux-pm/patch/20240203165307.7806-9-aford173@gmail.com/
> > then I'm thinking this is the latest.
> >
> > I'm going to switch to your suggestion that looks more recent :)
> 
> Sorry about the confusion.  I was confused by the versioning too when
> I pulled from different parts of Lucas' stuff.  Since varying
> components were applied at different times, and the remaining part was
> based on the wrong starting point and not applied, I reverted back to
> the versioning of the PHY which was the only remaining part other than
> device tree stuff.

No problem, thanks for clarify :)

Thanks & Regards,
Tommaso

> 
> adam
> >
> > Thanks again,
> > Tommaso
> >
> > >
> > > > On Sat, Feb 03, 2024 at 10:52:40AM -0600, Adam Ford wrote:
> > > > > The i.MX8M Plus has an HDMI controller, but it depends on two
> > > > > other systems, the Parallel Video Interface (PVI) and the
> > > > > HDMI PHY from Samsung. The LCDIF controller generates the display
> > > > > and routes it to the PVI which converts passes the parallel video
> > > > > to the HDMI bridge.  The HDMI system has a corresponding power
> > > > > domain controller whose driver was partially written, but the
> > > > > device tree for it was never applied, so some changes to the
> > > > > power domain should be harmless because they've not really been
> > > > > used yet.
> > > > >
> > > > > This series is adapted from multiple series from Lucas Stach with
> > > > > edits and suggestions from feedback from various series, but it
> > > > > since it's difficult to use and test them independently,
> > > > > I merged them into on unified series.  The version history is a
> > > > > bit ambiguous since different components were submitted at different
> > > > > times and had different amount of retries.  In an effort to merge them
> > > > > I used the highest version attempt.
> > > > >
> > > > > Adam Ford (3):
> > > > >   dt-bindings: soc: imx: add missing clock and power-domains to
> > > > >     imx8mp-hdmi-blk-ctrl
> > > > >   pmdomain: imx8mp-blk-ctrl: imx8mp_blk: Add fdcc clock to hdmimix
> > > > >     domain
> > > > >   arm64: defconfig: Enable DRM_IMX8MP_DW_HDMI_BRIDGE as module
> > > > >
> > > > > Lucas Stach (9):
> > > > >   dt-bindings: phy: add binding for the i.MX8MP HDMI PHY
> > > > >   phy: freescale: add Samsung HDMI PHY
> > > > >   arm64: dts: imx8mp: add HDMI power-domains
> > > > >   arm64: dts: imx8mp: add HDMI irqsteer
> > > > >   dt-bindings: display: imx: add binding for i.MX8MP HDMI PVI
> > > > >   drm/bridge: imx: add driver for HDMI TX Parallel Video Interface
> > > > >   dt-bindings: display: imx: add binding for i.MX8MP HDMI TX
> > > > >   drm/bridge: imx: add bridge wrapper driver for i.MX8MP DWC HDMI
> > > > >   arm64: dts: imx8mp: add HDMI display pipeline
> > > > >
> > > > >  .../display/bridge/fsl,imx8mp-hdmi-tx.yaml    |  102 ++
> > > > >  .../display/imx/fsl,imx8mp-hdmi-pvi.yaml      |   84 ++
> > > > >  .../bindings/phy/fsl,imx8mp-hdmi-phy.yaml     |   62 +
> > > > >  .../soc/imx/fsl,imx8mp-hdmi-blk-ctrl.yaml     |   22 +-
> > > > >  arch/arm64/boot/dts/freescale/imx8mp.dtsi     |  145 +++
> > > > >  arch/arm64/configs/defconfig                  |    1 +
> > > > >  drivers/gpu/drm/bridge/imx/Kconfig            |   18 +
> > > > >  drivers/gpu/drm/bridge/imx/Makefile           |    2 +
> > > > >  drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c  |  207 ++++
> > > > >  drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx.c   |  154 +++
> > > > >  drivers/phy/freescale/Kconfig                 |    6 +
> > > > >  drivers/phy/freescale/Makefile                |    1 +
> > > > >  drivers/phy/freescale/phy-fsl-samsung-hdmi.c  | 1075 +++++++++++++++++
> > > > >  drivers/pmdomain/imx/imx8mp-blk-ctrl.c        |   10 +-
> > > > >  14 files changed, 1876 insertions(+), 13 deletions(-)
> > > > >  create mode 100644 Documentation/devicetree/bindings/display/bridge/fsl,imx8mp-hdmi-tx.yaml
> > > > >  create mode 100644 Documentation/devicetree/bindings/display/imx/fsl,imx8mp-hdmi-pvi.yaml
> > > > >  create mode 100644 Documentation/devicetree/bindings/phy/fsl,imx8mp-hdmi-phy.yaml
> > > > >  create mode 100644 drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c
> > > > >  create mode 100644 drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx.c
> > > > >  create mode 100644 drivers/phy/freescale/phy-fsl-samsung-hdmi.c
> > >
> > > --
> > > Regards,
> > >
> > > Laurent Pinchart

drm/bridge/imx8mp-hdmi-tx: Allow inexact pixel clock frequencies (Was: [PATCH V8 10/12] drm/bridge: imx: add bridge wrapper driver for i.MX8MP DWC HDMI)

[Dominique MARTINET]

Adam Ford wrote on Sat, Feb 03, 2024 at 10:52:50AM -0600:
> From: Lucas Stach <l.stach@pengutronix.de>
> 
> Add a simple wrapper driver for the DWC HDMI bridge driver that
> implements the few bits that are necessary to abstract the i.MX8MP
> SoC integration.

Hi Lucas, Adam,
(trimmed ccs a bit)

First, thank you for the effort of upstreaming all of this!! It's really
appreciated, and with display working I'll really be wanting to upstream
our DTS as well as soon as I have time (which is going to be a while,
but better late than never ?)

Until then, it's been a few months but I've got a question on this bit:

> diff --git a/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx.c b/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx.c
> new file mode 100644
> index 000000000000..89fc432ac611
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx.c
> +static enum drm_mode_status
> +imx8mp_hdmi_mode_valid(struct dw_hdmi *dw_hdmi, void *data,
> +		       const struct drm_display_info *info,
> +		       const struct drm_display_mode *mode)
> +{
> +	struct imx8mp_hdmi *hdmi = (struct imx8mp_hdmi *)data;
> +
> +	if (mode->clock < 13500)
> +		return MODE_CLOCK_LOW;
> +
> +	if (mode->clock > 297000)
> +		return MODE_CLOCK_HIGH;
> +
> +	if (clk_round_rate(hdmi->pixclk, mode->clock * 1000) !=
> +	    mode->clock * 1000)
> +		return MODE_CLOCK_RANGE;

Do you know why such a check is here?

When plugging in a screen with no frequency identically supported in its
EDID this check causes the screen to stay black, and we've been telling
customers to override the EDID but it's a huge pain.

Commit 6ad082bee902 ("phy: freescale: add Samsung HDMI PHY") already
"fixed" the samsung hdmi phy driver to return the next frequency if an
exact match hasn't been found (NXP tree's match frequencies exactly, but
this gets the first clock with pixclk <= rate), so if this check is also
relaxed our displays would work out of the box.

I also don't see any other bridge doing this kind of check.
drivers/gpu/drm/bridge/imx/imx93-mipi-dsi.c has a similar check with a
0.5% leeway, and all the other drivers don't check anything.
If you want to add some level of safety, I think we could make this work
with a 5% margin easily... Printing a warning in dmesg could work if
you're worried about artifacts, but litteraly anything is better than a
black screen with no error message in my opinion.


In practice the screen I'm looking at has an EDID which only supports
51.2MHz and the closest frequency supported by the Samsung HDMI phy is
50.4MHz, so that's a ~1.5% difference and it'd be great if it could work
out of the box.

For reference, the output of edid-decode is as follow:
---
edid-decode /sys/devices/platform/display-subsystem/drm/car
d1/card1-HDMI-A-1/edid
edid-decode (hex):

00 ff ff ff ff ff ff 00 3a 49 03 00 01 00 00 00
20 1e 01 03 80 10 09 00 0a 00 00 00 00 00 00 00
00 00 00 00 00 00 01 01 01 01 01 01 01 01 01 01
01 01 01 01 01 01 00 14 00 40 41 58 23 20 a0 20
c8 00 9a 56 00 00 00 18 00 00 00 10 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 10 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 10
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 9a

----------------

Block 0, Base EDID:
  EDID Structure Version & Revision: 1.3
  Vendor & Product Identification:
    Manufacturer: NRI
    Model: 3
    Serial Number: 1
    Made in: week 32 of 2020
  Basic Display Parameters & Features:
    Digital display
    Maximum image size: 16 cm x 9 cm
    Gamma: 1.00
    RGB color display
    First detailed timing is the preferred timing
  Color Characteristics:
    Red  : 0.0000, 0.0000
    Green: 0.0000, 0.0000
    Blue : 0.0000, 0.0000
    White: 0.0000, 0.0000
  Established Timings I & II: none
  Standard Timings: none
  Detailed Timing Descriptors:
    DTD 1:  1024x600    59.993 Hz 128:75   38.095 kHz  51.200 MHz (154 mm x 86 m
m)
                 Hfront  160 Hsync  32 Hback 128 Hpol N
                 Vfront   12 Vsync   8 Vback  15 Vpol N
    Dummy Descriptor:
    Dummy Descriptor:
    Dummy Descriptor:
Checksum: 0x9a
---


Thanks,
-- 
Dominique Martinet

Re: drm/bridge/imx8mp-hdmi-tx: Allow inexact pixel clock frequencies (Was: [PATCH V8 10/12] drm/bridge: imx: add bridge wrapper driver for i.MX8MP DWC HDMI)

[Adam Ford]

On Mon, Jun 17, 2024 at 1:17 AM Dominique MARTINET
<dominique.martinet@atmark-techno.com> wrote:
>
> Adam Ford wrote on Sat, Feb 03, 2024 at 10:52:50AM -0600:
> > From: Lucas Stach <l.stach@pengutronix.de>
> >
> > Add a simple wrapper driver for the DWC HDMI bridge driver that
> > implements the few bits that are necessary to abstract the i.MX8MP
> > SoC integration.
>
> Hi Lucas, Adam,
> (trimmed ccs a bit)
>
> First, thank you for the effort of upstreaming all of this!! It's really
> appreciated, and with display working I'll really be wanting to upstream
> our DTS as well as soon as I have time (which is going to be a while,
> but better late than never ?)
>
> Until then, it's been a few months but I've got a question on this bit:
>
> > diff --git a/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx.c b/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx.c
> > new file mode 100644
> > index 000000000000..89fc432ac611
> > --- /dev/null
> > +++ b/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx.c
> > +static enum drm_mode_status
> > +imx8mp_hdmi_mode_valid(struct dw_hdmi *dw_hdmi, void *data,
> > +                    const struct drm_display_info *info,
> > +                    const struct drm_display_mode *mode)
> > +{
> > +     struct imx8mp_hdmi *hdmi = (struct imx8mp_hdmi *)data;
> > +
> > +     if (mode->clock < 13500)
> > +             return MODE_CLOCK_LOW;
> > +
> > +     if (mode->clock > 297000)
> > +             return MODE_CLOCK_HIGH;
> > +
> > +     if (clk_round_rate(hdmi->pixclk, mode->clock * 1000) !=
> > +         mode->clock * 1000)
> > +             return MODE_CLOCK_RANGE;
>
> Do you know why such a check is here?

I didn't write the original code, so I'll defer to Lucas here.  I just
tried to edit/fix issues as they were identified to get it pushed
upstream.

>
> When plugging in a screen with no frequency identically supported in its
> EDID this check causes the screen to stay black, and we've been telling
> customers to override the EDID but it's a huge pain.
>
> Commit 6ad082bee902 ("phy: freescale: add Samsung HDMI PHY") already
> "fixed" the samsung hdmi phy driver to return the next frequency if an
> exact match hasn't been found (NXP tree's match frequencies exactly, but
> this gets the first clock with pixclk <= rate), so if this check is also
> relaxed our displays would work out of the box.

Are you proposing to replace 'return MODE_CLOCK_RANGE' with a printed warning?

>
> I also don't see any other bridge doing this kind of check.
> drivers/gpu/drm/bridge/imx/imx93-mipi-dsi.c has a similar check with a
> 0.5% leeway, and all the other drivers don't check anything.
> If you want to add some level of safety, I think we could make this work
> with a 5% margin easily... Printing a warning in dmesg could work if
> you're worried about artifacts, but litteraly anything is better than a
> black screen with no error message in my opinion.
>
>
> In practice the screen I'm looking at has an EDID which only supports
> 51.2MHz and the closest frequency supported by the Samsung HDMI phy is
> 50.4MHz, so that's a ~1.5% difference and it'd be great if it could work
> out of the box.

I wonder if the HDMI PHY could be improved to better dynamically
calculate values instead of the look tables.

adam
>
> For reference, the output of edid-decode is as follow:
> ---
> edid-decode /sys/devices/platform/display-subsystem/drm/car
> d1/card1-HDMI-A-1/edid
> edid-decode (hex):
>
> 00 ff ff ff ff ff ff 00 3a 49 03 00 01 00 00 00
> 20 1e 01 03 80 10 09 00 0a 00 00 00 00 00 00 00
> 00 00 00 00 00 00 01 01 01 01 01 01 01 01 01 01
> 01 01 01 01 01 01 00 14 00 40 41 58 23 20 a0 20
> c8 00 9a 56 00 00 00 18 00 00 00 10 00 00 00 00
> 00 00 00 00 00 00 00 00 00 00 00 00 00 10 00 00
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 10
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 9a
>
> ----------------
>
> Block 0, Base EDID:
>   EDID Structure Version & Revision: 1.3
>   Vendor & Product Identification:
>     Manufacturer: NRI
>     Model: 3
>     Serial Number: 1
>     Made in: week 32 of 2020
>   Basic Display Parameters & Features:
>     Digital display
>     Maximum image size: 16 cm x 9 cm
>     Gamma: 1.00
>     RGB color display
>     First detailed timing is the preferred timing
>   Color Characteristics:
>     Red  : 0.0000, 0.0000
>     Green: 0.0000, 0.0000
>     Blue : 0.0000, 0.0000
>     White: 0.0000, 0.0000
>   Established Timings I & II: none
>   Standard Timings: none
>   Detailed Timing Descriptors:
>     DTD 1:  1024x600    59.993 Hz 128:75   38.095 kHz  51.200 MHz (154 mm x 86 m
> m)
>                  Hfront  160 Hsync  32 Hback 128 Hpol N
>                  Vfront   12 Vsync   8 Vback  15 Vpol N
>     Dummy Descriptor:
>     Dummy Descriptor:
>     Dummy Descriptor:
> Checksum: 0x9a
> ---
>
>
> Thanks,
> --
> Dominique Martinet
>
>
>
> --
> linux-phy mailing list
> linux-phy@lists.infradead.org
> https://lists.infradead.org/mailman/listinfo/linux-phy

Re: drm/bridge/imx8mp-hdmi-tx: Allow inexact pixel clock frequencies (Was: [PATCH V8 10/12] drm/bridge: imx: add bridge wrapper driver for i.MX8MP DWC HDMI)

[Lucas Stach]

Hi Dominique,

Am Montag, dem 17.06.2024 um 15:16 +0900 schrieb Dominique MARTINET:
> Adam Ford wrote on Sat, Feb 03, 2024 at 10:52:50AM -0600:
> > From: Lucas Stach <l.stach@pengutronix.de>
> > 
> > Add a simple wrapper driver for the DWC HDMI bridge driver that
> > implements the few bits that are necessary to abstract the i.MX8MP
> > SoC integration.
> 
> Hi Lucas, Adam,
> (trimmed ccs a bit)
> 
> First, thank you for the effort of upstreaming all of this!! It's really
> appreciated, and with display working I'll really be wanting to upstream
> our DTS as well as soon as I have time (which is going to be a while,
> but better late than never ?)
> 
> Until then, it's been a few months but I've got a question on this bit:
> 
> > diff --git a/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx.c b/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx.c
> > new file mode 100644
> > index 000000000000..89fc432ac611
> > --- /dev/null
> > +++ b/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx.c
> > +static enum drm_mode_status
> > +imx8mp_hdmi_mode_valid(struct dw_hdmi *dw_hdmi, void *data,
> > +		       const struct drm_display_info *info,
> > +		       const struct drm_display_mode *mode)
> > +{
> > +	struct imx8mp_hdmi *hdmi = (struct imx8mp_hdmi *)data;
> > +
> > +	if (mode->clock < 13500)
> > +		return MODE_CLOCK_LOW;
> > +
> > +	if (mode->clock > 297000)
> > +		return MODE_CLOCK_HIGH;
> > +
> > +	if (clk_round_rate(hdmi->pixclk, mode->clock * 1000) !=
> > +	    mode->clock * 1000)
> > +		return MODE_CLOCK_RANGE;
> 
> Do you know why such a check is here?

Sending a HDMI signal with a different rate than what the display
expects rarely ends well, so this check avoids that.

However, this check is a bit overcautious in that it only allows exact
rate matches. IIRC HDMI allows a rate mismatch of +- 0.5%, so this
check could be relaxed quite a bit to allow for that.
> 
> When plugging in a screen with no frequency identically supported in its
> EDID this check causes the screen to stay black, and we've been telling
> customers to override the EDID but it's a huge pain.
> 
> Commit 6ad082bee902 ("phy: freescale: add Samsung HDMI PHY") already
> "fixed" the samsung hdmi phy driver to return the next frequency if an
> exact match hasn't been found (NXP tree's match frequencies exactly, but
> this gets the first clock with pixclk <= rate), so if this check is also
> relaxed our displays would work out of the box.
> 
> I also don't see any other bridge doing this kind of check.
> drivers/gpu/drm/bridge/imx/imx93-mipi-dsi.c has a similar check with a
> 0.5% leeway, and all the other drivers don't check anything.
> If you want to add some level of safety, I think we could make this work
> with a 5% margin easily... Printing a warning in dmesg could work if
> you're worried about artifacts, but litteraly anything is better than a
> black screen with no error message in my opinion.
> 
> 
> In practice the screen I'm looking at has an EDID which only supports
> 51.2MHz and the closest frequency supported by the Samsung HDMI phy is
> 50.4MHz, so that's a ~1.5% difference and it'd be great if it could work
> out of the box.

For rate mismatches larger than the 0.5% allowed by the HDMI spec it
would be better to actually add PHY PLL parameters matching those
rates.

We could potentially add some more leeway for displays like yours that
aren't actually HDMI (as it doesn't seem to have a standard HDMI
resolution). But that's more of a last resort option, as it may
introduce other problems for displays that aren't as tolerant with
their input rates. Remember the mode_valid call is used to filter modes
that aren't compatible with the source, so for a display with multiple
modes allowing too much leeway may lead to incompatible modes not
getting tossed, in turn allowing userspace to set a mode that the
display may not like due to too much rate deviation, instead of only
presenting a list of valid modes. This again would present the user
with a black-screen without warning situation.

Regards,
Lucas

> 
> For reference, the output of edid-decode is as follow:
> ---
> edid-decode /sys/devices/platform/display-subsystem/drm/car
> d1/card1-HDMI-A-1/edid
> edid-decode (hex):
> 
> 00 ff ff ff ff ff ff 00 3a 49 03 00 01 00 00 00
> 20 1e 01 03 80 10 09 00 0a 00 00 00 00 00 00 00
> 00 00 00 00 00 00 01 01 01 01 01 01 01 01 01 01
> 01 01 01 01 01 01 00 14 00 40 41 58 23 20 a0 20
> c8 00 9a 56 00 00 00 18 00 00 00 10 00 00 00 00
> 00 00 00 00 00 00 00 00 00 00 00 00 00 10 00 00
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 10
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 9a
> 
> ----------------
> 
> Block 0, Base EDID:
>   EDID Structure Version & Revision: 1.3
>   Vendor & Product Identification:
>     Manufacturer: NRI
>     Model: 3
>     Serial Number: 1
>     Made in: week 32 of 2020
>   Basic Display Parameters & Features:
>     Digital display
>     Maximum image size: 16 cm x 9 cm
>     Gamma: 1.00
>     RGB color display
>     First detailed timing is the preferred timing
>   Color Characteristics:
>     Red  : 0.0000, 0.0000
>     Green: 0.0000, 0.0000
>     Blue : 0.0000, 0.0000
>     White: 0.0000, 0.0000
>   Established Timings I & II: none
>   Standard Timings: none
>   Detailed Timing Descriptors:
>     DTD 1:  1024x600    59.993 Hz 128:75   38.095 kHz  51.200 MHz (154 mm x 86 m
> m)
>                  Hfront  160 Hsync  32 Hback 128 Hpol N
>                  Vfront   12 Vsync   8 Vback  15 Vpol N
>     Dummy Descriptor:
>     Dummy Descriptor:
>     Dummy Descriptor:
> Checksum: 0x9a
> ---
> 
> 
> Thanks,

Re: drm/bridge/imx8mp-hdmi-tx: Allow inexact pixel clock frequencies (Was: [PATCH V8 10/12] drm/bridge: imx: add bridge wrapper driver for i.MX8MP DWC HDMI)

[Dominique MARTINET]

Thanks for the replies, replying to both mails at once.

Adam Ford wrote on Mon, Jun 17, 2024 at 08:28:58AM -0500:
> > Commit 6ad082bee902 ("phy: freescale: add Samsung HDMI PHY") already
> > "fixed" the samsung hdmi phy driver to return the next frequency if an
> > exact match hasn't been found (NXP tree's match frequencies exactly, but
> > this gets the first clock with pixclk <= rate), so if this check is also
> > relaxed our displays would work out of the box.
> 
> Are you proposing to replace 'return MODE_CLOCK_RANGE' with a printed warning?

Yes, something like that.

The imx93-mipi-dsi.c code has a check that's a bit more complex that
might be closer to what we want if you think the check is useful:
        if ((bridge->ops & DRM_BRIDGE_OP_DETECT) &&
            (bridge->ops & DRM_BRIDGE_OP_EDID)) {
                unsigned long pixel_clock_rate = mode->clock * 1000;
                unsigned long rounded_rate;

                /* Allow +/-0.5% pixel clock rate deviation */
                rounded_rate = clk_round_rate(dsi->clk_pixel, pixel_clock_rate);
                if (rounded_rate < pixel_clock_rate * 995 / 1000 ||
                    rounded_rate > pixel_clock_rate * 1005 / 1000) {
                        dev_dbg(dsi->dev, "failed to round clock for mode " DRM_MODE_FMT "\n",
                                DRM_MODE_ARG(mode));
                        return MODE_NOCLOCK;
                }
        }

However, for my particular case 0.5% wouldn't be enough to get something
to display unfortunately :/

> > In practice the screen I'm looking at has an EDID which only supports
> > 51.2MHz and the closest frequency supported by the Samsung HDMI phy is
> > 50.4MHz, so that's a ~1.5% difference and it'd be great if it could work
> > out of the box.
> 
> I wonder if the HDMI PHY could be improved to better dynamically
> calculate values instead of the look tables.

That would probably be ideal, right... If we could do that we could
likely compute something within 0.5% of the required freq.

The original code from NXP was full of what seemed at the time magic
values, but with the new code it seems quite a bit clearer...
At least the values that are left seem to somewhat make sense:
https://gaia.codewreck.org/local/linux/hdmi/plot-combined.svg
https://gaia.codewreck.org/local/linux/hdmi/plot-1.svg
 -> dented linear values, per the intervals defined in
 fsl_samsung_hdmi_phy_configure_pixclk()
https://gaia.codewreck.org/local/linux/hdmi/plot-2.svg
 -> constant for each intervals?
https://gaia.codewreck.org/local/linux/hdmi/plot-3.svg
https://gaia.codewreck.org/local/linux/hdmi/plot-4.svg
 these don't really make sense to me...
https://gaia.codewreck.org/local/linux/hdmi/plot-5.svg
 that one 0 value at 154000000 looks odd,
 but that aside we could probably get away with constant 0x80
 if the value matters at all...
https://gaia.codewreck.org/local/linux/hdmi/plot-6.svg
 weird as well

I'm thinking the last few values just affect a very small % of the
values, but would need to check with a proper scope if I can get a hold
of the clock line...
Does any of you happen to have any datasheet for these registers,
or should we consider them to be magic values?

Lucas Stach wrote on Mon, Jun 17, 2024 at 06:32:45PM +0200:
> > Do you know why such a check is here?
> 
> Sending a HDMI signal with a different rate than what the display
> expects rarely ends well, so this check avoids that.
>
> However, this check is a bit overcautious in that it only allows exact
> rate matches. IIRC HDMI allows a rate mismatch of +- 0.5%, so this
> check could be relaxed quite a bit to allow for that.

I'd expect displays to be tolerant to quite a few percents, but I didn't
know the spec defined something like that... iirc the HDMI spec isn't
public?

> > In practice the screen I'm looking at has an EDID which only supports
> > 51.2MHz and the closest frequency supported by the Samsung HDMI phy is
> > 50.4MHz, so that's a ~1.5% difference and it'd be great if it could work
> > out of the box.
> 
> For rate mismatches larger than the 0.5% allowed by the HDMI spec it
> would be better to actually add PHY PLL parameters matching those
> rates.
> 
> We could potentially add some more leeway for displays like yours that
> aren't actually HDMI (as it doesn't seem to have a standard HDMI
> resolution). But that's more of a last resort option, as it may
> introduce other problems for displays that aren't as tolerant with
> their input rates. Remember the mode_valid call is used to filter modes
> that aren't compatible with the source, so for a display with multiple
> modes allowing too much leeway may lead to incompatible modes not
> getting tossed, in turn allowing userspace to set a mode that the
> display may not like due to too much rate deviation, instead of only
> presenting a list of valid modes. This again would present the user
> with a black-screen without warning situation.

Ah, that's a very good point, if other modes are valid then we don't
want to present modes that are less likely to work, we should only allow
bigger variations if no other mode worked...
I don't think we have this info at validation time though?

I think that Adam's suggestion of making this more dynamic would be
great, if we can just generate finer frequencies for a reasonable range
then it wouldn't be a problem to limit the check to 0.5%.

Short of something really dynamic I can add a value for our particular
display based on what I've seen above (just pick a couple of points
along the lines for the two values I understood and whatever value
neighbors have for the rest & check with a scope it's somewhat close),
but I honestly would rather not get too far down this hole, we can't
cover all the quirky hardwares that exist manually...


Cheers,
-- 
Dominique

Re: drm/bridge/imx8mp-hdmi-tx: Allow inexact pixel clock frequencies (Was: [PATCH V8 10/12] drm/bridge: imx: add bridge wrapper driver for i.MX8MP DWC HDMI)

[Dominique MARTINET]

Dominique MARTINET wrote on Tue, Jun 18, 2024 at 08:45:38AM +0900:
> I'm thinking the last few values just affect a very small % of the
> values, but would need to check with a proper scope if I can get a hold
> of the clock line...
> Does any of you happen to have any datasheet for these registers,
> or should we consider them to be magic values?

Answering to myself on this point, the registers are properly described
in the iMX8MP reference manual...
I don't make much sense of it at this point (what's SDC..?), but I guess
it does sound likely we could generate the values with some work.

I'll wait for replies a bit first in case one of you understands this
better than I (which is quite likely!), but can give this a few more
hours to help.

-- 
Dominique

Re: drm/bridge/imx8mp-hdmi-tx: Allow inexact pixel clock frequencies (Was: [PATCH V8 10/12] drm/bridge: imx: add bridge wrapper driver for i.MX8MP DWC HDMI)

[Frieder Schrempf]

Hi Dominique, hi Lucas,

On 17.06.24 6:32 PM, Lucas Stach wrote:
> Hi Dominique,
> 
> Am Montag, dem 17.06.2024 um 15:16 +0900 schrieb Dominique MARTINET:
>> Adam Ford wrote on Sat, Feb 03, 2024 at 10:52:50AM -0600:
>>> From: Lucas Stach <l.stach@pengutronix.de>
>>>
>>> Add a simple wrapper driver for the DWC HDMI bridge driver that
>>> implements the few bits that are necessary to abstract the i.MX8MP
>>> SoC integration.
>>
>> Hi Lucas, Adam,
>> (trimmed ccs a bit)
>>
>> First, thank you for the effort of upstreaming all of this!! It's really
>> appreciated, and with display working I'll really be wanting to upstream
>> our DTS as well as soon as I have time (which is going to be a while,
>> but better late than never ?)
>>
>> Until then, it's been a few months but I've got a question on this bit:
>>
>>> diff --git a/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx.c b/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx.c
>>> new file mode 100644
>>> index 000000000000..89fc432ac611
>>> --- /dev/null
>>> +++ b/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx.c
>>> +static enum drm_mode_status
>>> +imx8mp_hdmi_mode_valid(struct dw_hdmi *dw_hdmi, void *data,
>>> +		       const struct drm_display_info *info,
>>> +		       const struct drm_display_mode *mode)
>>> +{
>>> +	struct imx8mp_hdmi *hdmi = (struct imx8mp_hdmi *)data;
>>> +
>>> +	if (mode->clock < 13500)
>>> +		return MODE_CLOCK_LOW;
>>> +
>>> +	if (mode->clock > 297000)
>>> +		return MODE_CLOCK_HIGH;
>>> +
>>> +	if (clk_round_rate(hdmi->pixclk, mode->clock * 1000) !=
>>> +	    mode->clock * 1000)
>>> +		return MODE_CLOCK_RANGE;
>>
>> Do you know why such a check is here?
> 
> Sending a HDMI signal with a different rate than what the display
> expects rarely ends well, so this check avoids that.
> 
> However, this check is a bit overcautious in that it only allows exact
> rate matches. IIRC HDMI allows a rate mismatch of +- 0.5%, so this
> check could be relaxed quite a bit to allow for that.

I checked with a 1080p display that reports 23 possible modes via EDID.
Out of these 15 are accepted by the driver with the strict check.

Two more would be accepted with a relaxed check that allows a 0.5% margin.

For the remaining six modes, the pixel clock would deviate up to ~5%
from what the display expects. Still, if I remove the check altogether,
all 23 modes seem to work just fine.

>>
>> When plugging in a screen with no frequency identically supported in its
>> EDID this check causes the screen to stay black, and we've been telling
>> customers to override the EDID but it's a huge pain.
>>
>> Commit 6ad082bee902 ("phy: freescale: add Samsung HDMI PHY") already
>> "fixed" the samsung hdmi phy driver to return the next frequency if an
>> exact match hasn't been found (NXP tree's match frequencies exactly, but
>> this gets the first clock with pixclk <= rate), so if this check is also
>> relaxed our displays would work out of the box.
>>
>> I also don't see any other bridge doing this kind of check.
>> drivers/gpu/drm/bridge/imx/imx93-mipi-dsi.c has a similar check with a
>> 0.5% leeway, and all the other drivers don't check anything.
>> If you want to add some level of safety, I think we could make this work
>> with a 5% margin easily... Printing a warning in dmesg could work if
>> you're worried about artifacts, but litteraly anything is better than a
>> black screen with no error message in my opinion.
>>
>>
>> In practice the screen I'm looking at has an EDID which only supports
>> 51.2MHz and the closest frequency supported by the Samsung HDMI phy is
>> 50.4MHz, so that's a ~1.5% difference and it'd be great if it could work
>> out of the box.
> 
> For rate mismatches larger than the 0.5% allowed by the HDMI spec it
> would be better to actually add PHY PLL parameters matching those
> rates.

I'd really like to be able to add more PHY PLL setpoints for displays
that use non-CEA-861 modes. Unfortunately I didn't manage to figure out
the fractional-n PLL parameter calculation so far.

The i.MX8MP Reference Manual provides formulas to calculate the
parameters based on the register values and I tried to make sense of it
using the existing register values in the driver. But somehow it doesn't
add up for me.

Lucas, did you already work with the PLL parameters? By any chance, do
you now how the math behind them works?

> 
> We could potentially add some more leeway for displays like yours that
> aren't actually HDMI (as it doesn't seem to have a standard HDMI
> resolution). But that's more of a last resort option, as it may
> introduce other problems for displays that aren't as tolerant with
> their input rates. Remember the mode_valid call is used to filter modes
> that aren't compatible with the source, so for a display with multiple
> modes allowing too much leeway may lead to incompatible modes not
> getting tossed, in turn allowing userspace to set a mode that the
> display may not like due to too much rate deviation, instead of only
> presenting a list of valid modes. This again would present the user
> with a black-screen without warning situation.

What about adding some option to relax or remove the check for debugging
purposes? Maybe combined with printing a warning message?

I agree that we should prevent incompatible modes from passing the
filter, but it would be really helpful if people had an easy way to
relax/remove the check to see whether their display could potentially
work without them needing to modify and recompile the kernel.

Thanks
Frieder

Re: drm/bridge/imx8mp-hdmi-tx: Allow inexact pixel clock frequencies (Was: [PATCH V8 10/12] drm/bridge: imx: add bridge wrapper driver for i.MX8MP DWC HDMI)

[Adam Ford]

On Thu, Aug 15, 2024 at 3:19 AM Frieder Schrempf
<frieder.schrempf@kontron.de> wrote:
>
> Hi Dominique, hi Lucas,
>
> On 17.06.24 6:32 PM, Lucas Stach wrote:
> > Hi Dominique,
> >
> > Am Montag, dem 17.06.2024 um 15:16 +0900 schrieb Dominique MARTINET:
> >> Adam Ford wrote on Sat, Feb 03, 2024 at 10:52:50AM -0600:
> >>> From: Lucas Stach <l.stach@pengutronix.de>
> >>>
> >>> Add a simple wrapper driver for the DWC HDMI bridge driver that
> >>> implements the few bits that are necessary to abstract the i.MX8MP
> >>> SoC integration.
> >>
> >> Hi Lucas, Adam,
> >> (trimmed ccs a bit)
> >>
> >> First, thank you for the effort of upstreaming all of this!! It's really
> >> appreciated, and with display working I'll really be wanting to upstream
> >> our DTS as well as soon as I have time (which is going to be a while,
> >> but better late than never ?)
> >>
> >> Until then, it's been a few months but I've got a question on this bit:
> >>
> >>> diff --git a/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx.c b/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx.c
> >>> new file mode 100644
> >>> index 000000000000..89fc432ac611
> >>> --- /dev/null
> >>> +++ b/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx.c
> >>> +static enum drm_mode_status
> >>> +imx8mp_hdmi_mode_valid(struct dw_hdmi *dw_hdmi, void *data,
> >>> +                  const struct drm_display_info *info,
> >>> +                  const struct drm_display_mode *mode)
> >>> +{
> >>> +   struct imx8mp_hdmi *hdmi = (struct imx8mp_hdmi *)data;
> >>> +
> >>> +   if (mode->clock < 13500)
> >>> +           return MODE_CLOCK_LOW;
> >>> +
> >>> +   if (mode->clock > 297000)
> >>> +           return MODE_CLOCK_HIGH;
> >>> +
> >>> +   if (clk_round_rate(hdmi->pixclk, mode->clock * 1000) !=
> >>> +       mode->clock * 1000)
> >>> +           return MODE_CLOCK_RANGE;
> >>
> >> Do you know why such a check is here?
> >
> > Sending a HDMI signal with a different rate than what the display
> > expects rarely ends well, so this check avoids that.
> >
> > However, this check is a bit overcautious in that it only allows exact
> > rate matches. IIRC HDMI allows a rate mismatch of +- 0.5%, so this
> > check could be relaxed quite a bit to allow for that.
>
> I checked with a 1080p display that reports 23 possible modes via EDID.
> Out of these 15 are accepted by the driver with the strict check.
>
> Two more would be accepted with a relaxed check that allows a 0.5% margin.
>
> For the remaining six modes, the pixel clock would deviate up to ~5%
> from what the display expects. Still, if I remove the check altogether,
> all 23 modes seem to work just fine.
>
> >>
> >> When plugging in a screen with no frequency identically supported in its
> >> EDID this check causes the screen to stay black, and we've been telling
> >> customers to override the EDID but it's a huge pain.
> >>
> >> Commit 6ad082bee902 ("phy: freescale: add Samsung HDMI PHY") already
> >> "fixed" the samsung hdmi phy driver to return the next frequency if an
> >> exact match hasn't been found (NXP tree's match frequencies exactly, but
> >> this gets the first clock with pixclk <= rate), so if this check is also
> >> relaxed our displays would work out of the box.
> >>
> >> I also don't see any other bridge doing this kind of check.
> >> drivers/gpu/drm/bridge/imx/imx93-mipi-dsi.c has a similar check with a
> >> 0.5% leeway, and all the other drivers don't check anything.
> >> If you want to add some level of safety, I think we could make this work
> >> with a 5% margin easily... Printing a warning in dmesg could work if
> >> you're worried about artifacts, but litteraly anything is better than a
> >> black screen with no error message in my opinion.
> >>
> >>
> >> In practice the screen I'm looking at has an EDID which only supports
> >> 51.2MHz and the closest frequency supported by the Samsung HDMI phy is
> >> 50.4MHz, so that's a ~1.5% difference and it'd be great if it could work
> >> out of the box.
> >
> > For rate mismatches larger than the 0.5% allowed by the HDMI spec it
> > would be better to actually add PHY PLL parameters matching those
> > rates.
>
> I'd really like to be able to add more PHY PLL setpoints for displays
> that use non-CEA-861 modes. Unfortunately I didn't manage to figure out
> the fractional-n PLL parameter calculation so far.
>
> The i.MX8MP Reference Manual provides formulas to calculate the
> parameters based on the register values and I tried to make sense of it
> using the existing register values in the driver. But somehow it doesn't
> add up for me.
>
> Lucas, did you already work with the PLL parameters? By any chance, do
> you now how the math behind them works?

I spent a little time trying to understand it a bit.  I created a PMS
calculator similar to the one used on the DSI controller, except that
the M seems to be fixed at a value of 62 per the data sheet, so it's
more of a PS calculator.

Anyway, When I run my P-S calculator to generate the 'best rate' I get
a value that's usually 0.2% variance from nominal, but I only verified
a handful of values:

Several which were +0.2%
297600000 vs 297000000 (4k@30)
148800000 vs 148500000 (1080p60)
74400 vs 74200

One value was -0.16%
24800000 vs 25200000

If the M value was a bit more flexible, we might be able to reduce
that variance more.

If / when I get some time, I might play with trying to disable the
fractional mode and just use the PMS calculator for simplicity despite
the inaccuracy.  Maybe we could fall back to using the PMS calculator
if the desired frequency isn't in the look-up-table.

adam

>
> >
> > We could potentially add some more leeway for displays like yours that
> > aren't actually HDMI (as it doesn't seem to have a standard HDMI
> > resolution). But that's more of a last resort option, as it may
> > introduce other problems for displays that aren't as tolerant with
> > their input rates. Remember the mode_valid call is used to filter modes
> > that aren't compatible with the source, so for a display with multiple
> > modes allowing too much leeway may lead to incompatible modes not
> > getting tossed, in turn allowing userspace to set a mode that the
> > display may not like due to too much rate deviation, instead of only
> > presenting a list of valid modes. This again would present the user
> > with a black-screen without warning situation.
>
> What about adding some option to relax or remove the check for debugging
> purposes? Maybe combined with printing a warning message?
>
> I agree that we should prevent incompatible modes from passing the
> filter, but it would be really helpful if people had an easy way to
> relax/remove the check to see whether their display could potentially
> work without them needing to modify and recompile the kernel.
>
> Thanks
> Frieder

Re: drm/bridge/imx8mp-hdmi-tx: Allow inexact pixel clock frequencies (Was: [PATCH V8 10/12] drm/bridge: imx: add bridge wrapper driver for i.MX8MP DWC HDMI)

[Dominique MARTINET]

Adam Ford wrote on Tue, Aug 20, 2024 at 09:49:03PM -0500:
> > > However, this check is a bit overcautious in that it only allows exact
> > > rate matches. IIRC HDMI allows a rate mismatch of +- 0.5%, so this
> > > check could be relaxed quite a bit to allow for that.
> >
> > I checked with a 1080p display that reports 23 possible modes via EDID.
> > Out of these 15 are accepted by the driver with the strict check.
> >
> > Two more would be accepted with a relaxed check that allows a 0.5% margin.
> >
> > For the remaining six modes, the pixel clock would deviate up to ~5%
> > from what the display expects. Still, if I remove the check altogether,
> > all 23 modes seem to work just fine.

I can confirm the displays I tested also seem pretty tolerant in
practice (up to ~3-4% at least), but I agree with Lucas that this isn't
something we can rely on for a general purpose driver as having examples
of things being tolerant doesn't mean all hardware will be as flexible..

> > I'd really like to be able to add more PHY PLL setpoints for displays
> > that use non-CEA-861 modes. Unfortunately I didn't manage to figure out
> > the fractional-n PLL parameter calculation so far.
> >
> > The i.MX8MP Reference Manual provides formulas to calculate the
> > parameters based on the register values and I tried to make sense of it
> > using the existing register values in the driver. But somehow it doesn't
> > add up for me.
> >
> > Lucas, did you already work with the PLL parameters? By any chance, do
> > you now how the math behind them works?
> 
> I spent a little time trying to understand it a bit.  I created a PMS
> calculator similar to the one used on the DSI controller,

Great! I'll admit this also flies over my head and I don't have the
time to study this, so this is much appreciated.

> except that
> the M seems to be fixed at a value of 62 per the data sheet, so it's
> more of a PS calculator.

Hmm... PHY_REG2 in the datasheet only lists '0011_1110b - 62' as
example(?) values, but it doesn't say other values are reserved either,
I'm not sure what to make of it.
In the current driver PHY_REG_02 (driver macro) is assigned the first
field of .pll_div_regs, which goes anywhere from 0x4b to 0x7b -- pretty
far from 62(0x3e)...

Since other frequencies have been adjusting this main diviser ratio we
actually tried copying neighboring values and adjusting only that reg 2
(so the M if I get this right?), but the end result ended up not
synchronizing properly every time... We didn't have time to check with a
scope if the generated signal was ugly or if it just didn't lock
properly, but the display worked when we just re-used the neighboring
values without changing anything despite being ~3-4% off, so we took the
easy way out here and didn't dig much further.

> Anyway, When I run my P-S calculator to generate the 'best rate' I get
> a value that's usually 0.2% variance from nominal, but I only verified
> a handful of values:
> 
> Several which were +0.2%
> 297600000 vs 297000000 (4k@30)
> 148800000 vs 148500000 (1080p60)
> 74400 vs 74200
> 
> One value was -0.16%
> 24800000 vs 25200000
> 
> If the M value was a bit more flexible, we might be able to reduce
> that variance more.

Yes, I think the M value could be more flexible, but that'd require
checking if it actually works, whereas having slightly off frequencies
will most likely be OK so I don't think it's worth the effort -- happy
to stick to what the datasheet describes.

> If / when I get some time, I might play with trying to disable the
> fractional mode and just use the PMS calculator for simplicity despite
> the inaccuracy.  Maybe we could fall back to using the PMS calculator
> if the desired frequency isn't in the look-up-table.

That'd be greatly appreciated, I don't have any strong opinion on
whether that should completely replace the table, or only be used if
there is no exact match in the table as these are values we know will
work; but we can definitely test any patch you can throw at us here.


Cheers,
-- 
Dominique

Re: drm/bridge/imx8mp-hdmi-tx: Allow inexact pixel clock frequencies (Was: [PATCH V8 10/12] drm/bridge: imx: add bridge wrapper driver for i.MX8MP DWC HDMI)

[Adam Ford]

On Tue, Aug 20, 2024 at 10:58 PM Dominique MARTINET
<dominique.martinet@atmark-techno.com> wrote:
>
> Adam Ford wrote on Tue, Aug 20, 2024 at 09:49:03PM -0500:
> > > > However, this check is a bit overcautious in that it only allows exact
> > > > rate matches. IIRC HDMI allows a rate mismatch of +- 0.5%, so this
> > > > check could be relaxed quite a bit to allow for that.
> > >
> > > I checked with a 1080p display that reports 23 possible modes via EDID.
> > > Out of these 15 are accepted by the driver with the strict check.
> > >
> > > Two more would be accepted with a relaxed check that allows a 0.5% margin.
> > >
> > > For the remaining six modes, the pixel clock would deviate up to ~5%
> > > from what the display expects. Still, if I remove the check altogether,
> > > all 23 modes seem to work just fine.
>
> I can confirm the displays I tested also seem pretty tolerant in
> practice (up to ~3-4% at least), but I agree with Lucas that this isn't
> something we can rely on for a general purpose driver as having examples
> of things being tolerant doesn't mean all hardware will be as flexible..
>
> > > I'd really like to be able to add more PHY PLL setpoints for displays
> > > that use non-CEA-861 modes. Unfortunately I didn't manage to figure out
> > > the fractional-n PLL parameter calculation so far.
> > >
> > > The i.MX8MP Reference Manual provides formulas to calculate the
> > > parameters based on the register values and I tried to make sense of it
> > > using the existing register values in the driver. But somehow it doesn't
> > > add up for me.
> > >
> > > Lucas, did you already work with the PLL parameters? By any chance, do
> > > you now how the math behind them works?
> >
> > I spent a little time trying to understand it a bit.  I created a PMS
> > calculator similar to the one used on the DSI controller,
>
> Great! I'll admit this also flies over my head and I don't have the
> time to study this, so this is much appreciated.
>
> > except that
> > the M seems to be fixed at a value of 62 per the data sheet, so it's
> > more of a PS calculator.
>
> Hmm... PHY_REG2 in the datasheet only lists '0011_1110b - 62' as
> example(?) values, but it doesn't say other values are reserved either,
> I'm not sure what to make of it.
> In the current driver PHY_REG_02 (driver macro) is assigned the first
> field of .pll_div_regs, which goes anywhere from 0x4b to 0x7b -- pretty
> far from 62(0x3e)...

OK.  I will experiment with increasing the range of M from being fixed
at 3e to a range of 3b to 7b to see if my PMS integer calculator can
get more accurate.

>
> Since other frequencies have been adjusting this main diviser ratio we
> actually tried copying neighboring values and adjusting only that reg 2
> (so the M if I get this right?), but the end result ended up not
> synchronizing properly every time... We didn't have time to check with a
> scope if the generated signal was ugly or if it just didn't lock
> properly, but the display worked when we just re-used the neighboring
> values without changing anything despite being ~3-4% off, so we took the
> easy way out here and didn't dig much further.
>
> > Anyway, When I run my P-S calculator to generate the 'best rate' I get
> > a value that's usually 0.2% variance from nominal, but I only verified
> > a handful of values:
> >
> > Several which were +0.2%
> > 297600000 vs 297000000 (4k@30)
> > 148800000 vs 148500000 (1080p60)
> > 74400 vs 74200
> >
> > One value was -0.16%
> > 24800000 vs 25200000
> >
> > If the M value was a bit more flexible, we might be able to reduce
> > that variance more.
>
> Yes, I think the M value could be more flexible, but that'd require
> checking if it actually works, whereas having slightly off frequencies
> will most likely be OK so I don't think it's worth the effort -- happy
> to stick to what the datasheet describes.
>
> > If / when I get some time, I might play with trying to disable the
> > fractional mode and just use the PMS calculator for simplicity despite
> > the inaccuracy.  Maybe we could fall back to using the PMS calculator
> > if the desired frequency isn't in the look-up-table.
>
> That'd be greatly appreciated, I don't have any strong opinion on
> whether that should completely replace the table, or only be used if
> there is no exact match in the table as these are values we know will
> work; but we can definitely test any patch you can throw at us here.

I can't promise it'll be quick.  I am not fully certain I understand
how the whole thing works, but as a rule, I don't generally like look
up tables if they can be calculated dynamically.

adam
>
>
> Cheers,
> --
> Dominique
>
>

Re: drm/bridge/imx8mp-hdmi-tx: Allow inexact pixel clock frequencies (Was: [PATCH V8 10/12] drm/bridge: imx: add bridge wrapper driver for i.MX8MP DWC HDMI)

[Adam Ford]

On Wed, Aug 21, 2024 at 7:45 AM Adam Ford <aford173@gmail.com> wrote:
>
> On Tue, Aug 20, 2024 at 10:58 PM Dominique MARTINET
> <dominique.martinet@atmark-techno.com> wrote:
> >
> > Adam Ford wrote on Tue, Aug 20, 2024 at 09:49:03PM -0500:
> > > > > However, this check is a bit overcautious in that it only allows exact
> > > > > rate matches. IIRC HDMI allows a rate mismatch of +- 0.5%, so this
> > > > > check could be relaxed quite a bit to allow for that.
> > > >
> > > > I checked with a 1080p display that reports 23 possible modes via EDID.
> > > > Out of these 15 are accepted by the driver with the strict check.
> > > >
> > > > Two more would be accepted with a relaxed check that allows a 0.5% margin.
> > > >
> > > > For the remaining six modes, the pixel clock would deviate up to ~5%
> > > > from what the display expects. Still, if I remove the check altogether,
> > > > all 23 modes seem to work just fine.
> >
> > I can confirm the displays I tested also seem pretty tolerant in
> > practice (up to ~3-4% at least), but I agree with Lucas that this isn't
> > something we can rely on for a general purpose driver as having examples
> > of things being tolerant doesn't mean all hardware will be as flexible..
> >
> > > > I'd really like to be able to add more PHY PLL setpoints for displays
> > > > that use non-CEA-861 modes. Unfortunately I didn't manage to figure out
> > > > the fractional-n PLL parameter calculation so far.
> > > >
> > > > The i.MX8MP Reference Manual provides formulas to calculate the
> > > > parameters based on the register values and I tried to make sense of it
> > > > using the existing register values in the driver. But somehow it doesn't
> > > > add up for me.
> > > >
> > > > Lucas, did you already work with the PLL parameters? By any chance, do
> > > > you now how the math behind them works?
> > >
> > > I spent a little time trying to understand it a bit.  I created a PMS
> > > calculator similar to the one used on the DSI controller,
> >
> > Great! I'll admit this also flies over my head and I don't have the
> > time to study this, so this is much appreciated.
> >
> > > except that
> > > the M seems to be fixed at a value of 62 per the data sheet, so it's
> > > more of a PS calculator.
> >
> > Hmm... PHY_REG2 in the datasheet only lists '0011_1110b - 62' as
> > example(?) values, but it doesn't say other values are reserved either,
> > I'm not sure what to make of it.
> > In the current driver PHY_REG_02 (driver macro) is assigned the first
> > field of .pll_div_regs, which goes anywhere from 0x4b to 0x7b -- pretty
> > far from 62(0x3e)...
>
> OK.  I will experiment with increasing the range of M from being fixed
> at 3e to a range of 3b to 7b to see if my PMS integer calculator can
> get more accurate.
>
> >
> > Since other frequencies have been adjusting this main diviser ratio we
> > actually tried copying neighboring values and adjusting only that reg 2
> > (so the M if I get this right?), but the end result ended up not
> > synchronizing properly every time... We didn't have time to check with a
> > scope if the generated signal was ugly or if it just didn't lock
> > properly, but the display worked when we just re-used the neighboring
> > values without changing anything despite being ~3-4% off, so we took the
> > easy way out here and didn't dig much further.
> >
> > > Anyway, When I run my P-S calculator to generate the 'best rate' I get
> > > a value that's usually 0.2% variance from nominal, but I only verified
> > > a handful of values:
> > >
> > > Several which were +0.2%
> > > 297600000 vs 297000000 (4k@30)
> > > 148800000 vs 148500000 (1080p60)
> > > 74400 vs 74200
> > >
> > > One value was -0.16%
> > > 24800000 vs 25200000
> > >
> > > If the M value was a bit more flexible, we might be able to reduce
> > > that variance more.
> >
> > Yes, I think the M value could be more flexible, but that'd require
> > checking if it actually works, whereas having slightly off frequencies
> > will most likely be OK so I don't think it's worth the effort -- happy
> > to stick to what the datasheet describes.
> >
> > > If / when I get some time, I might play with trying to disable the
> > > fractional mode and just use the PMS calculator for simplicity despite
> > > the inaccuracy.  Maybe we could fall back to using the PMS calculator
> > > if the desired frequency isn't in the look-up-table.
> >
> > That'd be greatly appreciated, I don't have any strong opinion on
> > whether that should completely replace the table, or only be used if
> > there is no exact match in the table as these are values we know will
> > work; but we can definitely test any patch you can throw at us here.
>
> I can't promise it'll be quick.  I am not fully certain I understand
> how the whole thing works, but as a rule, I don't generally like look
> up tables if they can be calculated dynamically.

I updated my PMS calculator, and I randomly selected 5 resolutions and
they all returned an exact clock match, so I'll attempt to use the PMS
integer clock instead of the fractional one.

It'll be a little while longer before I can do anything with it.

adam
>
> adam
> >
> >
> > Cheers,
> > --
> > Dominique
> >
> >

Re: drm/bridge/imx8mp-hdmi-tx: Allow inexact pixel clock frequencies (Was: [PATCH V8 10/12] drm/bridge: imx: add bridge wrapper driver for i.MX8MP DWC HDMI)

[Adam Ford]

On Wed, Aug 21, 2024 at 8:59 PM Adam Ford <aford173@gmail.com> wrote:
>
> On Wed, Aug 21, 2024 at 7:45 AM Adam Ford <aford173@gmail.com> wrote:
> >
> > On Tue, Aug 20, 2024 at 10:58 PM Dominique MARTINET
> > <dominique.martinet@atmark-techno.com> wrote:
> > >
> > > Adam Ford wrote on Tue, Aug 20, 2024 at 09:49:03PM -0500:
> > > > > > However, this check is a bit overcautious in that it only allows exact
> > > > > > rate matches. IIRC HDMI allows a rate mismatch of +- 0.5%, so this
> > > > > > check could be relaxed quite a bit to allow for that.
> > > > >
> > > > > I checked with a 1080p display that reports 23 possible modes via EDID.
> > > > > Out of these 15 are accepted by the driver with the strict check.
> > > > >
> > > > > Two more would be accepted with a relaxed check that allows a 0.5% margin.
> > > > >
> > > > > For the remaining six modes, the pixel clock would deviate up to ~5%
> > > > > from what the display expects. Still, if I remove the check altogether,
> > > > > all 23 modes seem to work just fine.
> > >
> > > I can confirm the displays I tested also seem pretty tolerant in
> > > practice (up to ~3-4% at least), but I agree with Lucas that this isn't
> > > something we can rely on for a general purpose driver as having examples
> > > of things being tolerant doesn't mean all hardware will be as flexible..
> > >
> > > > > I'd really like to be able to add more PHY PLL setpoints for displays
> > > > > that use non-CEA-861 modes. Unfortunately I didn't manage to figure out
> > > > > the fractional-n PLL parameter calculation so far.
> > > > >
> > > > > The i.MX8MP Reference Manual provides formulas to calculate the
> > > > > parameters based on the register values and I tried to make sense of it
> > > > > using the existing register values in the driver. But somehow it doesn't
> > > > > add up for me.
> > > > >
> > > > > Lucas, did you already work with the PLL parameters? By any chance, do
> > > > > you now how the math behind them works?
> > > >
> > > > I spent a little time trying to understand it a bit.  I created a PMS
> > > > calculator similar to the one used on the DSI controller,
> > >
> > > Great! I'll admit this also flies over my head and I don't have the
> > > time to study this, so this is much appreciated.
> > >
> > > > except that
> > > > the M seems to be fixed at a value of 62 per the data sheet, so it's
> > > > more of a PS calculator.
> > >
> > > Hmm... PHY_REG2 in the datasheet only lists '0011_1110b - 62' as
> > > example(?) values, but it doesn't say other values are reserved either,
> > > I'm not sure what to make of it.
> > > In the current driver PHY_REG_02 (driver macro) is assigned the first
> > > field of .pll_div_regs, which goes anywhere from 0x4b to 0x7b -- pretty
> > > far from 62(0x3e)...
> >
> > OK.  I will experiment with increasing the range of M from being fixed
> > at 3e to a range of 3b to 7b to see if my PMS integer calculator can
> > get more accurate.
> >
> > >
> > > Since other frequencies have been adjusting this main diviser ratio we
> > > actually tried copying neighboring values and adjusting only that reg 2
> > > (so the M if I get this right?), but the end result ended up not
> > > synchronizing properly every time... We didn't have time to check with a
> > > scope if the generated signal was ugly or if it just didn't lock
> > > properly, but the display worked when we just re-used the neighboring
> > > values without changing anything despite being ~3-4% off, so we took the
> > > easy way out here and didn't dig much further.
> > >
> > > > Anyway, When I run my P-S calculator to generate the 'best rate' I get
> > > > a value that's usually 0.2% variance from nominal, but I only verified
> > > > a handful of values:
> > > >
> > > > Several which were +0.2%
> > > > 297600000 vs 297000000 (4k@30)
> > > > 148800000 vs 148500000 (1080p60)
> > > > 74400 vs 74200
> > > >
> > > > One value was -0.16%
> > > > 24800000 vs 25200000
> > > >
> > > > If the M value was a bit more flexible, we might be able to reduce
> > > > that variance more.
> > >
> > > Yes, I think the M value could be more flexible, but that'd require
> > > checking if it actually works, whereas having slightly off frequencies
> > > will most likely be OK so I don't think it's worth the effort -- happy
> > > to stick to what the datasheet describes.
> > >
> > > > If / when I get some time, I might play with trying to disable the
> > > > fractional mode and just use the PMS calculator for simplicity despite
> > > > the inaccuracy.  Maybe we could fall back to using the PMS calculator
> > > > if the desired frequency isn't in the look-up-table.
> > >
> > > That'd be greatly appreciated, I don't have any strong opinion on
> > > whether that should completely replace the table, or only be used if
> > > there is no exact match in the table as these are values we know will
> > > work; but we can definitely test any patch you can throw at us here.
> >
> > I can't promise it'll be quick.  I am not fully certain I understand
> > how the whole thing works, but as a rule, I don't generally like look
> > up tables if they can be calculated dynamically.
>
> I updated my PMS calculator, and I randomly selected 5 resolutions and
> they all returned an exact clock match, so I'll attempt to use the PMS
> integer clock instead of the fractional one.
>
> It'll be a little while longer before I can do anything with it.

Frieder,

Using my PMS calculator and Rev 2 of the Tech Ref Manual, I think I
can generate you a table entry for 51.2MHz.  I don't have the ability
to test it.  I am still working on figuring out an algorithm to
calculate the fractional divider, but 51.2MHz x 5 does not' appear to
need the fractional clock divider, so I think I can just get away with
the standard PMS calculations.

My algorithm showed:
HDMI PHY Best P = 1
HDMI PHY Best M = 64
HDMI PHY Best S = 6
HDMI PHY Best freq = 256000000

I'll try to generate a patch to get these values into the table if
you're willing to test it.

All,

I still think it's a good idea to fall back to the PMS calculator if
the fractional stuff isn't found.  We could then determine which clock
frequency is closer between the nearest table entry or the PMS
calculator until someone can come up with an algorithm for it.


adam


>
> adam
> >
> > adam
> > >
> > >
> > > Cheers,
> > > --
> > > Dominique
> > >
> > >

Re: drm/bridge/imx8mp-hdmi-tx: Allow inexact pixel clock frequencies (Was: [PATCH V8 10/12] drm/bridge: imx: add bridge wrapper driver for i.MX8MP DWC HDMI)

[Frieder Schrempf]

Hi Adam,

On 27.08.24 2:25 AM, Adam Ford wrote:
> On Wed, Aug 21, 2024 at 8:59 PM Adam Ford <aford173@gmail.com> wrote:
>>
>> On Wed, Aug 21, 2024 at 7:45 AM Adam Ford <aford173@gmail.com> wrote:
>>>
>>> On Tue, Aug 20, 2024 at 10:58 PM Dominique MARTINET
>>> <dominique.martinet@atmark-techno.com> wrote:
>>>>
>>>> Adam Ford wrote on Tue, Aug 20, 2024 at 09:49:03PM -0500:
>>>>>>> However, this check is a bit overcautious in that it only allows exact
>>>>>>> rate matches. IIRC HDMI allows a rate mismatch of +- 0.5%, so this
>>>>>>> check could be relaxed quite a bit to allow for that.
>>>>>>
>>>>>> I checked with a 1080p display that reports 23 possible modes via EDID.
>>>>>> Out of these 15 are accepted by the driver with the strict check.
>>>>>>
>>>>>> Two more would be accepted with a relaxed check that allows a 0.5% margin.
>>>>>>
>>>>>> For the remaining six modes, the pixel clock would deviate up to ~5%
>>>>>> from what the display expects. Still, if I remove the check altogether,
>>>>>> all 23 modes seem to work just fine.
>>>>
>>>> I can confirm the displays I tested also seem pretty tolerant in
>>>> practice (up to ~3-4% at least), but I agree with Lucas that this isn't
>>>> something we can rely on for a general purpose driver as having examples
>>>> of things being tolerant doesn't mean all hardware will be as flexible..
>>>>
>>>>>> I'd really like to be able to add more PHY PLL setpoints for displays
>>>>>> that use non-CEA-861 modes. Unfortunately I didn't manage to figure out
>>>>>> the fractional-n PLL parameter calculation so far.
>>>>>>
>>>>>> The i.MX8MP Reference Manual provides formulas to calculate the
>>>>>> parameters based on the register values and I tried to make sense of it
>>>>>> using the existing register values in the driver. But somehow it doesn't
>>>>>> add up for me.
>>>>>>
>>>>>> Lucas, did you already work with the PLL parameters? By any chance, do
>>>>>> you now how the math behind them works?
>>>>>
>>>>> I spent a little time trying to understand it a bit.  I created a PMS
>>>>> calculator similar to the one used on the DSI controller,
>>>>
>>>> Great! I'll admit this also flies over my head and I don't have the
>>>> time to study this, so this is much appreciated.
>>>>
>>>>> except that
>>>>> the M seems to be fixed at a value of 62 per the data sheet, so it's
>>>>> more of a PS calculator.
>>>>
>>>> Hmm... PHY_REG2 in the datasheet only lists '0011_1110b - 62' as
>>>> example(?) values, but it doesn't say other values are reserved either,
>>>> I'm not sure what to make of it.
>>>> In the current driver PHY_REG_02 (driver macro) is assigned the first
>>>> field of .pll_div_regs, which goes anywhere from 0x4b to 0x7b -- pretty
>>>> far from 62(0x3e)...
>>>
>>> OK.  I will experiment with increasing the range of M from being fixed
>>> at 3e to a range of 3b to 7b to see if my PMS integer calculator can
>>> get more accurate.
>>>
>>>>
>>>> Since other frequencies have been adjusting this main diviser ratio we
>>>> actually tried copying neighboring values and adjusting only that reg 2
>>>> (so the M if I get this right?), but the end result ended up not
>>>> synchronizing properly every time... We didn't have time to check with a
>>>> scope if the generated signal was ugly or if it just didn't lock
>>>> properly, but the display worked when we just re-used the neighboring
>>>> values without changing anything despite being ~3-4% off, so we took the
>>>> easy way out here and didn't dig much further.
>>>>
>>>>> Anyway, When I run my P-S calculator to generate the 'best rate' I get
>>>>> a value that's usually 0.2% variance from nominal, but I only verified
>>>>> a handful of values:
>>>>>
>>>>> Several which were +0.2%
>>>>> 297600000 vs 297000000 (4k@30)
>>>>> 148800000 vs 148500000 (1080p60)
>>>>> 74400 vs 74200
>>>>>
>>>>> One value was -0.16%
>>>>> 24800000 vs 25200000
>>>>>
>>>>> If the M value was a bit more flexible, we might be able to reduce
>>>>> that variance more.
>>>>
>>>> Yes, I think the M value could be more flexible, but that'd require
>>>> checking if it actually works, whereas having slightly off frequencies
>>>> will most likely be OK so I don't think it's worth the effort -- happy
>>>> to stick to what the datasheet describes.
>>>>
>>>>> If / when I get some time, I might play with trying to disable the
>>>>> fractional mode and just use the PMS calculator for simplicity despite
>>>>> the inaccuracy.  Maybe we could fall back to using the PMS calculator
>>>>> if the desired frequency isn't in the look-up-table.
>>>>
>>>> That'd be greatly appreciated, I don't have any strong opinion on
>>>> whether that should completely replace the table, or only be used if
>>>> there is no exact match in the table as these are values we know will
>>>> work; but we can definitely test any patch you can throw at us here.
>>>
>>> I can't promise it'll be quick.  I am not fully certain I understand
>>> how the whole thing works, but as a rule, I don't generally like look
>>> up tables if they can be calculated dynamically.
>>
>> I updated my PMS calculator, and I randomly selected 5 resolutions and
>> they all returned an exact clock match, so I'll attempt to use the PMS
>> integer clock instead of the fractional one.
>>
>> It'll be a little while longer before I can do anything with it.
> 
> Frieder,
> 
> Using my PMS calculator and Rev 2 of the Tech Ref Manual, I think I
> can generate you a table entry for 51.2MHz.  I don't have the ability
> to test it.  I am still working on figuring out an algorithm to
> calculate the fractional divider, but 51.2MHz x 5 does not' appear to
> need the fractional clock divider, so I think I can just get away with
> the standard PMS calculations.

Thanks Adam for all the efforts. The initial request for the 51.2 MHz
clock was from Dominique, not me. I was just jumping onto the bandwagon
with my own use-cases.

> 
> My algorithm showed:
> HDMI PHY Best P = 1
> HDMI PHY Best M = 64
> HDMI PHY Best S = 6
> HDMI PHY Best freq = 256000000
> 
> I'll try to generate a patch to get these values into the table if
> you're willing to test it.

Any chance you can share your algorithm, so I can try to generate some
table entries for the missing frequencies I encounter?

If we could figure out the calculation of the fractional divider, we
could generate table entries for arbitrary frequencies, which would be
an easy way to add support for any strange displays out there.

> 
> All,
> 
> I still think it's a good idea to fall back to the PMS calculator if
> the fractional stuff isn't found.  We could then determine which clock
> frequency is closer between the nearest table entry or the PMS
> calculator until someone can come up with an algorithm for it.

Yes, I think that's a good idea.

Thanks
Frieder

Re: drm/bridge/imx8mp-hdmi-tx: Allow inexact pixel clock frequencies (Was: [PATCH V8 10/12] drm/bridge: imx: add bridge wrapper driver for i.MX8MP DWC HDMI)

[Dominique MARTINET]

Frieder Schrempf wrote on Tue, Aug 27, 2024 at 09:00:34AM +0200:
> > Using my PMS calculator and Rev 2 of the Tech Ref Manual, I think I
> > can generate you a table entry for 51.2MHz.  I don't have the ability
> > to test it.  I am still working on figuring out an algorithm to
> > calculate the fractional divider, but 51.2MHz x 5 does not' appear to
> > need the fractional clock divider, so I think I can just get away with
> > the standard PMS calculations.
> 
> Thanks Adam for all the efforts. The initial request for the 51.2 MHz
> clock was from Dominique, not me. I was just jumping onto the bandwagon
> with my own use-cases.

We still have that 51.2 MHz display around, so happy to test -- might
take a little bit of time as this already has a workaround but it's
definitely something I'd like to clean up so more than happy to help.

> > I still think it's a good idea to fall back to the PMS calculator if
> > the fractional stuff isn't found.  We could then determine which clock
> > frequency is closer between the nearest table entry or the PMS
> > calculator until someone can come up with an algorithm for it.
> 
> Yes, I think that's a good idea.

Seconded; we can keep the code as fallback of the table at first and if
it works well maybe even remove the table altogether later, but just
having fallback first would be great.

-- 
Dominique

imx8mp: HDMI display blank/black problems

[mailinglist1]

Hey, 
We had some problems with the hdmi on the imx8mp and wanted to leave, what we found out about it, somewhere for others to find it.

The problem was that our hdmi display sometimes stayed blank after hot plugging and sometimes at startup. On older kernel versions 6.6 we did not have the problem with the not mainlined hdmi patches. 
We tracked the commit down that introduced the problem for us. It was the following “driver core: Enable fw_devlink=rpm by default”  https://lore.kernel.org/lkml/20231113220948.80089-1-saravanak@google.com/
So we switched back to FW_DEVLINK_FLAGS_ON via kernel parameter. Don’t really understand what the problem with RPM is.

So, this information is just for reference. Maybe someone has an idea what is going on here. And how to fix the problem in a more proper way.

Best regards Johannes

Re: imx8mp: HDMI display blank/black problems

[Frieder Schrempf]

Hi Johannes,

On 25.10.24 10:05 AM, mailinglist1@johanneskirchmair.de wrote:
> [Sie erhalten nicht häufig E-Mails von mailinglist1@johanneskirchmair.de. Weitere Informationen, warum dies wichtig ist, finden Sie unter https://aka.ms/LearnAboutSenderIdentification ]
> 
> Hey,
> We had some problems with the hdmi on the imx8mp and wanted to leave, what we found out about it, somewhere for others to find it.
> 
> The problem was that our hdmi display sometimes stayed blank after hot plugging and sometimes at startup. On older kernel versions 6.6 we did not have the problem with the not mainlined hdmi patches.
> We tracked the commit down that introduced the problem for us. It was the following “driver core: Enable fw_devlink=rpm by default”  https://lore.kernel.org/lkml/20231113220948.80089-1-saravanak@google.com/
> So we switched back to FW_DEVLINK_FLAGS_ON via kernel parameter. Don’t really understand what the problem with RPM is.
> 
> So, this information is just for reference. Maybe someone has an idea what is going on here. And how to fix the problem in a more proper way.

Thanks for investigating and sharing your results!

I'm seeing the same symptoms and previously found out that this is
related to LCDIF underrun errors. See [1] for more information.

Adam has also started this thread: [2].

Anyway, knowing that this is related to fw_devlink=rpm is really
helpful. I just tried with fw_devlink=on and wasn't able to see any
issues anymore. So this confirms your findings.

I hope that some of the driver framework and runtime PM experts can help
to find out what is actually wrong and how the correct fix might look like.

I'm also CC-ing Saravana who authored the change from fw_devlink=on to
fw_devlink=rpm to see if they have anything to add.

Thanks
Frieder

[1]
https://patchwork.kernel.org/project/linux-phy/cover/20240904233100.114611-1-aford173@gmail.com/#26014057
[2]
https://lore.kernel.org/imx/8cfd3052-c85a-4235-b9b8-6d2929e9e455@kontron.de/T/

Re: imx8mp: HDMI display blank/black problems

[Adam Ford]

On Wed, Oct 30, 2024 at 4:01 AM Frieder Schrempf
<frieder.schrempf@kontron.de> wrote:
>
> Hi Johannes,
>
> On 25.10.24 10:05 AM, mailinglist1@johanneskirchmair.de wrote:
> > [Sie erhalten nicht häufig E-Mails von mailinglist1@johanneskirchmair.de. Weitere Informationen, warum dies wichtig ist, finden Sie unter https://aka.ms/LearnAboutSenderIdentification ]
> >
> > Hey,
> > We had some problems with the hdmi on the imx8mp and wanted to leave, what we found out about it, somewhere for others to find it.
> >
> > The problem was that our hdmi display sometimes stayed blank after hot plugging and sometimes at startup. On older kernel versions 6.6 we did not have the problem with the not mainlined hdmi patches.
> > We tracked the commit down that introduced the problem for us. It was the following “driver core: Enable fw_devlink=rpm by default”  https://lore.kernel.org/lkml/20231113220948.80089-1-saravanak@google.com/
> > So we switched back to FW_DEVLINK_FLAGS_ON via kernel parameter. Don’t really understand what the problem with RPM is.
> >
> > So, this information is just for reference. Maybe someone has an idea what is going on here. And how to fix the problem in a more proper way.
>
> Thanks for investigating and sharing your results!
>
> I'm seeing the same symptoms and previously found out that this is
> related to LCDIF underrun errors. See [1] for more information.
>
> Adam has also started this thread: [2].
>
> Anyway, knowing that this is related to fw_devlink=rpm is really
> helpful. I just tried with fw_devlink=on and wasn't able to see any
> issues anymore. So this confirms your findings.

I was off in the weeds thinking there was something wrong in timing
and/or a race condition around the PLL or something.  This is good
news.
Please forgive my ignorance, what does fw_devlink do?  Is there
something we can do in the driver itself to force its behavior?

adam
>
> I hope that some of the driver framework and runtime PM experts can help
> to find out what is actually wrong and how the correct fix might look like.
>
> I'm also CC-ing Saravana who authored the change from fw_devlink=on to
> fw_devlink=rpm to see if they have anything to add.
>
> Thanks
> Frieder
>
> [1]
> https://patchwork.kernel.org/project/linux-phy/cover/20240904233100.114611-1-aford173@gmail.com/#26014057
> [2]
> https://lore.kernel.org/imx/8cfd3052-c85a-4235-b9b8-6d2929e9e455@kontron.de/T/

Re: imx8mp: HDMI display blank/black problems

[Saravana Kannan]

On Wed, Oct 30, 2024 at 10:28 AM Adam Ford <aford173@gmail.com> wrote:
>
> On Wed, Oct 30, 2024 at 4:01 AM Frieder Schrempf
> <frieder.schrempf@kontron.de> wrote:
> >
> > Hi Johannes,
> >
> > On 25.10.24 10:05 AM, mailinglist1@johanneskirchmair.de wrote:
> > > [Sie erhalten nicht häufig E-Mails von mailinglist1@johanneskirchmair.de. Weitere Informationen, warum dies wichtig ist, finden Sie unter https://aka.ms/LearnAboutSenderIdentification ]
> > >
> > > Hey,
> > > We had some problems with the hdmi on the imx8mp and wanted to leave, what we found out about it, somewhere for others to find it.
> > >
> > > The problem was that our hdmi display sometimes stayed blank after hot plugging and sometimes at startup. On older kernel versions 6.6 we did not have the problem with the not mainlined hdmi patches.
> > > We tracked the commit down that introduced the problem for us. It was the following “driver core: Enable fw_devlink=rpm by default”  https://lore.kernel.org/lkml/20231113220948.80089-1-saravanak@google.com/
> > > So we switched back to FW_DEVLINK_FLAGS_ON via kernel parameter. Don’t really understand what the problem with RPM is.
> > >
> > > So, this information is just for reference. Maybe someone has an idea what is going on here. And how to fix the problem in a more proper way.
> >
> > Thanks for investigating and sharing your results!
> >
> > I'm seeing the same symptoms and previously found out that this is
> > related to LCDIF underrun errors. See [1] for more information.
> >
> > Adam has also started this thread: [2].
> >
> > Anyway, knowing that this is related to fw_devlink=rpm is really
> > helpful. I just tried with fw_devlink=on and wasn't able to see any
> > issues anymore. So this confirms your findings.
>
> I was off in the weeds thinking there was something wrong in timing
> and/or a race condition around the PLL or something.  This is good
> news.
> Please forgive my ignorance, what does fw_devlink do?  Is there
> something we can do in the driver itself to force its behavior?

fw_devlink figures out supplier/consumer dependencies between devices
and creates device links between them. This ensures proper
probe/suspend/resume/shutdown/runtime PM ordering.

fw_devlink=rpm vs on means "enforce all of these" vs "enforce all of
these except runtime PM".

> adam
> >
> > I hope that some of the driver framework and runtime PM experts can help
> > to find out what is actually wrong and how the correct fix might look like.
> >
> > I'm also CC-ing Saravana who authored the change from fw_devlink=on to
> > fw_devlink=rpm to see if they have anything to add.

When fw_devlink=rpm, you'll have device links created between
consumers and suppliers with the DL_FLAG_PM_RUNTIME flag set. So
before your device is runtime resumed, it'll make sure all your
suppliers are resumed first.

My guess is that there is some issue in the runtime PM handling in
these drivers. I don't have enough context to provide further insight.

-Saravana

> >
> > Thanks
> > Frieder
> >
> > [1]
> > https://patchwork.kernel.org/project/linux-phy/cover/20240904233100.114611-1-aford173@gmail.com/#26014057
> > [2]
> > https://lore.kernel.org/imx/8cfd3052-c85a-4235-b9b8-6d2929e9e455@kontron.de/T/

Re: imx8mp: HDMI display blank/black problems

[Frieder Schrempf]

Am 30.10.24 um 9:20 PM schrieb Saravana Kannan:
> On Wed, Oct 30, 2024 at 10:28 AM Adam Ford <aford173@gmail.com> wrote:
>>
>> On Wed, Oct 30, 2024 at 4:01 AM Frieder Schrempf
>> <frieder.schrempf@kontron.de> wrote:
>>>
>>> Hi Johannes,
>>>
>>> On 25.10.24 10:05 AM, mailinglist1@johanneskirchmair.de wrote:
>>>> [Sie erhalten nicht häufig E-Mails von mailinglist1@johanneskirchmair.de. Weitere Informationen, warum dies wichtig ist, finden Sie unter https://aka.ms/LearnAboutSenderIdentification ]
>>>>
>>>> Hey,
>>>> We had some problems with the hdmi on the imx8mp and wanted to leave, what we found out about it, somewhere for others to find it.
>>>>
>>>> The problem was that our hdmi display sometimes stayed blank after hot plugging and sometimes at startup. On older kernel versions 6.6 we did not have the problem with the not mainlined hdmi patches.
>>>> We tracked the commit down that introduced the problem for us. It was the following “driver core: Enable fw_devlink=rpm by default”  https://lore.kernel.org/lkml/20231113220948.80089-1-saravanak@google.com/
>>>> So we switched back to FW_DEVLINK_FLAGS_ON via kernel parameter. Don’t really understand what the problem with RPM is.
>>>>
>>>> So, this information is just for reference. Maybe someone has an idea what is going on here. And how to fix the problem in a more proper way.
>>>
>>> Thanks for investigating and sharing your results!
>>>
>>> I'm seeing the same symptoms and previously found out that this is
>>> related to LCDIF underrun errors. See [1] for more information.
>>>
>>> Adam has also started this thread: [2].
>>>
>>> Anyway, knowing that this is related to fw_devlink=rpm is really
>>> helpful. I just tried with fw_devlink=on and wasn't able to see any
>>> issues anymore. So this confirms your findings.
>>
>> I was off in the weeds thinking there was something wrong in timing
>> and/or a race condition around the PLL or something.  This is good
>> news.
>> Please forgive my ignorance, what does fw_devlink do?  Is there
>> something we can do in the driver itself to force its behavior?
> 
> fw_devlink figures out supplier/consumer dependencies between devices
> and creates device links between them. This ensures proper
> probe/suspend/resume/shutdown/runtime PM ordering.
> 
> fw_devlink=rpm vs on means "enforce all of these" vs "enforce all of
> these except runtime PM".
> 
>> adam
>>>
>>> I hope that some of the driver framework and runtime PM experts can help
>>> to find out what is actually wrong and how the correct fix might look like.
>>>
>>> I'm also CC-ing Saravana who authored the change from fw_devlink=on to
>>> fw_devlink=rpm to see if they have anything to add.
> 
> When fw_devlink=rpm, you'll have device links created between
> consumers and suppliers with the DL_FLAG_PM_RUNTIME flag set. So
> before your device is runtime resumed, it'll make sure all your
> suppliers are resumed first.
> 
> My guess is that there is some issue in the runtime PM handling in
> these drivers. I don't have enough context to provide further insight.

I bet you are right. I tried to have a closer look but unfortunately I
didn't make any progress.

The drivers involved are lcdif_drv.c, imx8mp-hdmi-tx.c and
phy-fsl-samsung-hdmi.c.

As we see a "LCDIF Underrun Error" with fw_devlink=rpm my first guess
would be that the suppliers of LCDIF are maybe turned on in the wrong order.

Lucas, Marek: As the main authors of these drivers, do you think you
could help a little with further debugging? Any ideas?

Thanks!