[PATCH v4 00/13] Add ITE IT6263 LVDS to HDMI converter support

[PATCH v4 00/13] Add ITE IT6263 LVDS to HDMI converter support

[Liu Ying]

Hi,

This patch series aims to add ITE IT6263 LVDS to HDMI converter on
i.MX8MP EVK.  Combined with LVDS receiver and HDMI 1.4a transmitter,
the IT6263 supports LVDS input and HDMI 1.4 output by conversion
function.  IT6263 product link can be found at [1].

Patch 1 is a preparation patch to allow display mode of an existing
panel to pass the added mode validation logic in patch 3.

Patch 2 allows i.MX8MP LVDS Display Bridge(LDB) bridge driver to find
the next non-panel bridge, that is the IT6263 in this case.

Patch 3 adds mode validation logic to i.MX8MP LDB bridge driver against
"ldb" clock so that it can filter out unsupported display modes read
from EDID.

Patch 4 adds MEDIA_BUS_FMT_RGB101010_1X7X5_{SPWG,JEIDA} support, as they
are supported by IT6263(with LVDS data bit reversed order).

Patch 5 makes drm_of.c use MEDIA_BUS_FMT_RGB101010_1X7X5_{JEIDA,SPWG}.

Patch 6 supports getting dual-link LVDS pixel order for the sink side as
needed by IT6263 driver.

Patch 7 documents jeida-30 and vesa-30 data mappings in lvds-data-mapping.yaml,
as needed by IT6263 DT binding.

Patch 8 extracts common dual-link LVDS display properties into new
lvds-dual-ports.yaml so that IT6263 DT binding can reference it.

Patch 9 adds DT binding for IT6263.

Patch 10 adds IT6263 bridge driver.  Only video output is supported.

Patch 11 adds DT overlays to support NXP adapter cards[2][3] with IT6263
populated.

Patch 12 enables the IT6263 bridge driver in defconfig.

Patch 13 updates MAINTAINERS to add maintainer for IT6263 driver.

Note that patch 3 depends on patch[4] in shawnguo/imx/fixes.

[1] https://www.ite.com.tw/en/product/cate1/IT6263
[2] https://www.nxp.com/part/IMX-LVDS-HDMI
[3] https://www.nxp.com/part/IMX-DLVDS-HDMI
[4] https://patchwork.kernel.org/project/linux-arm-kernel/patch/20241017031146.157996-1-marex@denx.de/

v4:
* Squash change for advantech,idk-2121wr.yaml and
  panel-simple-lvds-dual-ports.yaml with lvds-dual-ports.yaml in patch 8.  (Rob)
* Improve description in lvds-dual-ports.yaml in patch 8.  (Krzysztof)
* Require dual-lvds-odd-pixels or dual-lvds-even-pixels DT properties for port@1
  in ite,it6263.yaml in patch 9.
* Drop "data-mirror: true" from ite,it6263.yaml in patch 9.
* Use local variable reset_gpio in IT6263 driver's probe() in patch 10.  (Biju)
* Move pixel clock rate validation from mode_valid callback to
  hdmi_tmds_char_rate_valid callback in IT6263 driver in patch 10.  (Maxime)
* Document IT6263 video processing throughput constraints by adding comments
  in IT6263 driver in patch 10.  (Maxime)
* Fix IT6263 LVDS 8-bit color depth macro BIT8 in IT6263 driver in patch 10.
* Drop 30-bit LVDS data bit order validation in IT6263 driver in patch 10.
* Rebase patch 11 upon next-20241025 to resolve conflicts when apply.
* Collect R-b and A-b tags.

v3:
* Use assigned-clock-rates DT property to set pixel clock rate for
  "multi-inno,mi1010ait-1cp" LVDS panel in patch 1 instead of using
  panel-timing node.  (Marek)
* Drop the patch for fixing pixel clock rate for "edt,etml1010g3dra"
  LVDS panel because there is already another better patch[4].
* Collect Dmitry's R-b tag for patch 2.
* Define MEDIA_BUS_FMT_RGB101010_1X7X5_{SPWG,JEIDA} in patch 4.
* Use MEDIA_BUS_FMT_RGB101010_1X7X5_{JEIDA,SPWG} in drm_of.c in patch 5.
* Add drm_of_lvds_get_dual_link_pixel_order_sink() in patch 6.  (Dmitry)
* Document jeida-30 and vesa-30 in lvds-data-mapping.yaml in patch 7.
* Extract dual-link LVDS display common properties(patch 8-10).  (Dmitry)
* Reference lvds-dual-ports.yaml in ite,it6263.yaml in patch 11.  (Dmitry)
* Add data-mapping DT property in ite,it6263.yaml in patch 11.  (Dmitry, Biju)
* Allow data-mirror in ite,it6263.yaml in patch 11.
* Drop ite,lvds-link-num-data-lanes DT property from ite,it6263.yaml
  in patch 11.  (Dmitry, Biju)
* Use HDMI connector framework in IT6263 driver in patch 12.  (Maxime)
* Control the missing HDMI_REG_AVI_INFOFRM_CTRL register in IT6263 driver
  in patch 12.
* Validate the maximal HDMI TMDS character rate in IT6263 driver in patch 12.
  (Dmitry)
* Get LVDS data mapping from data-mapping DT property in IT6263 driver
  in patch 12.  (Dmitry, Biju)
* Validate 30bit LVDS data bit order by checking data-mirror DT property
  in IT6263 driver in patch 12.
* Use drm_of_lvds_get_dual_link_pixel_order_sink() in IT6263 driver
  in patch 12.  (Dmitry)
* Initialize a bridge connector instead of open coding in IT6263 driver
  in patch 12.  (Dmitry)
* Add a comment that IT6263 chip has no HPD IRQ support in IT6263 driver
  in patch 12.  (Dmitry)
* Use devm_drm_bridge_add() instead of drm_bridge_add() in IT6263 driver
  in patch 12.  (Dmitry)
* Fix a minor build warning reported by kernel test robot in IT6263 driver
  in patch 12.
* Use data-mapping DT property instead of ite,lvds-link-num-data-lanes
  in i.MX8MP evk DT files in patch 13.  (Dmitry, Biju)

v2:
* Add more comments in fsl-ldb.c and commit message about pixel clock
  rate validation for patch 4.  (Maxime)
* Document number of LVDS link data lanes in patch 5.  (Biju)
* Simplify ports property by dropping "oneOf" in patch 5.  (Rob)
* Add AVI inforframe support in patch 6.  (Maxime)
* Add DRM_MODE_CONNECTOR_HDMIA in patch 6.  (Biju)
* Rename it6263_reset() to it6263_hw_reset() in patch 6.  (Biju)
* Check number of LVDS link data lanes in patch 6.  (Biju)
* Add ite,lvds-link-num-data-lanes properties in patch 7.
* Update MAINTAINERS.  (Maxime)

*** BLURB HERE ***

Liu Ying (13):
  arm64: dts: imx8mp-skov-revb-mi1010ait-1cp1: Set "media_disp2_pix"
    clock rate to 70MHz
  drm/bridge: fsl-ldb: Get the next non-panel bridge
  drm/bridge: fsl-ldb: Use clk_round_rate() to validate "ldb" clock rate
  media: uapi: Add MEDIA_BUS_FMT_RGB101010_1X7X5_{SPWG, JEIDA}
  drm: of: Get MEDIA_BUS_FMT_RGB101010_1X7X5_{JEIDA, SPWG} LVDS data
    mappings
  drm: of: Add drm_of_lvds_get_dual_link_pixel_order_sink()
  dt-bindings: display: lvds-data-mapping: Add 30-bit RGB pixel data
    mappings
  dt-bindings: display: Document dual-link LVDS display common
    properties
  dt-bindings: display: bridge: Add ITE IT6263 LVDS to HDMI converter
  drm/bridge: Add ITE IT6263 LVDS to HDMI converter
  arm64: dts: imx8mp-evk: Add NXP LVDS to HDMI adapter cards
  arm64: defconfig: Enable ITE IT6263 driver
  MAINTAINERS: Add maintainer for ITE IT6263 driver

 .../bindings/display/bridge/ite,it6263.yaml   | 250 +++++
 .../bindings/display/lvds-data-mapping.yaml   |  31 +
 .../bindings/display/lvds-dual-ports.yaml     |  76 ++
 .../display/panel/advantech,idk-2121wr.yaml   |  14 +-
 .../panel/panel-simple-lvds-dual-ports.yaml   |  20 +-
 .../media/v4l/subdev-formats.rst              | 156 ++-
 MAINTAINERS                                   |   8 +
 arch/arm64/boot/dts/freescale/Makefile        |   8 +
 .../imx8mp-evk-imx-lvds-hdmi-common.dtsi      |  29 +
 ...8mp-evk-lvds0-imx-dlvds-hdmi-channel0.dtso |  44 +
 ...imx8mp-evk-lvds0-imx-lvds-hdmi-common.dtsi |  43 +
 .../imx8mp-evk-lvds0-imx-lvds-hdmi.dtso       |  28 +
 ...8mp-evk-lvds1-imx-dlvds-hdmi-channel0.dtso |  44 +
 ...imx8mp-evk-lvds1-imx-lvds-hdmi-common.dtsi |  43 +
 .../imx8mp-evk-lvds1-imx-lvds-hdmi.dtso       |  28 +
 arch/arm64/boot/dts/freescale/imx8mp-evk.dts  |   6 +
 .../imx8mp-skov-revb-mi1010ait-1cp1.dts       |   8 +-
 arch/arm64/configs/defconfig                  |   1 +
 drivers/gpu/drm/bridge/Kconfig                |  11 +
 drivers/gpu/drm/bridge/Makefile               |   1 +
 drivers/gpu/drm/bridge/fsl-ldb.c              |  55 +-
 drivers/gpu/drm/bridge/ite-it6263.c           | 898 ++++++++++++++++++
 drivers/gpu/drm/drm_of.c                      |  82 +-
 include/drm/drm_of.h                          |   9 +
 include/uapi/linux/media-bus-format.h         |   4 +-
 25 files changed, 1827 insertions(+), 70 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/display/bridge/ite,it6263.yaml
 create mode 100644 Documentation/devicetree/bindings/display/lvds-dual-ports.yaml
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-evk-imx-lvds-hdmi-common.dtsi
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-evk-lvds0-imx-dlvds-hdmi-channel0.dtso
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-evk-lvds0-imx-lvds-hdmi-common.dtsi
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-evk-lvds0-imx-lvds-hdmi.dtso
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-evk-lvds1-imx-dlvds-hdmi-channel0.dtso
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-evk-lvds1-imx-lvds-hdmi-common.dtsi
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-evk-lvds1-imx-lvds-hdmi.dtso
 create mode 100644 drivers/gpu/drm/bridge/ite-it6263.c

-- 
2.34.1

[PATCH v4 01/13] arm64: dts: imx8mp-skov-revb-mi1010ait-1cp1: Set "media_disp2_pix" clock rate to 70MHz

[Liu Ying]

The LVDS panel "multi-inno,mi1010ait-1cp" used on this platform has
a typical pixel clock rate of 70MHz.  Set "media_disp2_pix" clock rate
to that rate, instead of the original 68.9MHz.  The LVDS serial clock
is controlled by "media_ldb" clock.  It should run at 490MHz(7-fold the
pixel clock rate due to single LVDS link).  Set "video_pll1" clock rate
and "media_ldb" to 490MHz to achieve that.

This should be able to suppress this LDB driver warning:
[   17.206644] fsl-ldb 32ec0000.blk-ctrl:bridge@5c: Configured LDB clock (70000000 Hz) does not match requested LVDS clock: 490000000 Hz

This also makes the display mode used by the panel pass mode validation
against pixel clock rate and "media_ldb" clock rate in a certain display
driver.

Signed-off-by: Liu Ying <victor.liu@nxp.com>
---
v4:
* No change.

v3:
* New patch.

 .../dts/freescale/imx8mp-skov-revb-mi1010ait-1cp1.dts     | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/boot/dts/freescale/imx8mp-skov-revb-mi1010ait-1cp1.dts b/arch/arm64/boot/dts/freescale/imx8mp-skov-revb-mi1010ait-1cp1.dts
index 30962922b361..2c75da5f064f 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp-skov-revb-mi1010ait-1cp1.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mp-skov-revb-mi1010ait-1cp1.dts
@@ -52,7 +52,7 @@ &lcdif2 {
 
 &lvds_bridge {
 	/* IMX8MP_CLK_MEDIA_LDB = IMX8MP_CLK_MEDIA_DISP2_PIX * 7 */
-	assigned-clock-rates = <482300000>;
+	assigned-clock-rates = <490000000>;
 	status = "okay";
 
 	ports {
@@ -70,10 +70,10 @@ &media_blk_ctrl {
 	 */
 	assigned-clock-rates = <500000000>, <200000000>, <0>,
 		/* IMX8MP_CLK_MEDIA_DISP2_PIX = pixelclk of lvds panel */
-		<68900000>,
+		<70000000>,
 		<500000000>,
-		/* IMX8MP_VIDEO_PLL1 = IMX8MP_CLK_MEDIA_LDB * 2 */
-		<964600000>;
+		/* IMX8MP_VIDEO_PLL1 = IMX8MP_CLK_MEDIA_LDB */
+		<490000000>;
 };
 
 &pwm4 {
-- 
2.34.1

[PATCH v4 02/13] drm/bridge: fsl-ldb: Get the next non-panel bridge

[Liu Ying]

The next bridge in bridge chain could be a panel bridge or a non-panel
bridge.  Use devm_drm_of_get_bridge() to replace the combination
function calls of of_drm_find_panel() and devm_drm_panel_bridge_add()
to get either a panel bridge or a non-panel bridge, instead of getting
a panel bridge only.

Signed-off-by: Liu Ying <victor.liu@nxp.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
---
v4:
* No change.

v3:
* Collect Dmitry' R-b tag.

v2:
* No change.

 drivers/gpu/drm/bridge/fsl-ldb.c | 31 +++++++++++--------------------
 1 file changed, 11 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/bridge/fsl-ldb.c b/drivers/gpu/drm/bridge/fsl-ldb.c
index 0e4bac7dd04f..b559f3e0bef6 100644
--- a/drivers/gpu/drm/bridge/fsl-ldb.c
+++ b/drivers/gpu/drm/bridge/fsl-ldb.c
@@ -15,7 +15,6 @@
 #include <drm/drm_atomic_helper.h>
 #include <drm/drm_bridge.h>
 #include <drm/drm_of.h>
-#include <drm/drm_panel.h>
 
 #define LDB_CTRL_CH0_ENABLE			BIT(0)
 #define LDB_CTRL_CH0_DI_SELECT			BIT(1)
@@ -86,7 +85,7 @@ static const struct fsl_ldb_devdata fsl_ldb_devdata[] = {
 struct fsl_ldb {
 	struct device *dev;
 	struct drm_bridge bridge;
-	struct drm_bridge *panel_bridge;
+	struct drm_bridge *next_bridge;
 	struct clk *clk;
 	struct regmap *regmap;
 	const struct fsl_ldb_devdata *devdata;
@@ -117,7 +116,7 @@ static int fsl_ldb_attach(struct drm_bridge *bridge,
 {
 	struct fsl_ldb *fsl_ldb = to_fsl_ldb(bridge);
 
-	return drm_bridge_attach(bridge->encoder, fsl_ldb->panel_bridge,
+	return drm_bridge_attach(bridge->encoder, fsl_ldb->next_bridge,
 				 bridge, flags);
 }
 
@@ -292,9 +291,7 @@ static const struct drm_bridge_funcs funcs = {
 static int fsl_ldb_probe(struct platform_device *pdev)
 {
 	struct device *dev = &pdev->dev;
-	struct device_node *panel_node;
 	struct device_node *remote1, *remote2;
-	struct drm_panel *panel;
 	struct fsl_ldb *fsl_ldb;
 	int dual_link;
 
@@ -318,33 +315,27 @@ static int fsl_ldb_probe(struct platform_device *pdev)
 	if (IS_ERR(fsl_ldb->regmap))
 		return PTR_ERR(fsl_ldb->regmap);
 
-	/* Locate the remote ports and the panel node */
+	/* Locate the remote ports. */
 	remote1 = of_graph_get_remote_node(dev->of_node, 1, 0);
 	remote2 = of_graph_get_remote_node(dev->of_node, 2, 0);
 	fsl_ldb->ch0_enabled = (remote1 != NULL);
 	fsl_ldb->ch1_enabled = (remote2 != NULL);
-	panel_node = of_node_get(remote1 ? remote1 : remote2);
 	of_node_put(remote1);
 	of_node_put(remote2);
 
-	if (!fsl_ldb->ch0_enabled && !fsl_ldb->ch1_enabled) {
-		of_node_put(panel_node);
-		return dev_err_probe(dev, -ENXIO, "No panel node found");
-	}
+	if (!fsl_ldb->ch0_enabled && !fsl_ldb->ch1_enabled)
+		return dev_err_probe(dev, -ENXIO, "No next bridge node found");
 
 	dev_dbg(dev, "Using %s\n",
 		fsl_ldb_is_dual(fsl_ldb) ? "dual-link mode" :
 		fsl_ldb->ch0_enabled ? "channel 0" : "channel 1");
 
-	panel = of_drm_find_panel(panel_node);
-	of_node_put(panel_node);
-	if (IS_ERR(panel))
-		return PTR_ERR(panel);
-
-	fsl_ldb->panel_bridge = devm_drm_panel_bridge_add(dev, panel);
-	if (IS_ERR(fsl_ldb->panel_bridge))
-		return PTR_ERR(fsl_ldb->panel_bridge);
-
+	fsl_ldb->next_bridge = devm_drm_of_get_bridge(dev, dev->of_node,
+						      fsl_ldb->ch0_enabled ? 1 : 2,
+						      0);
+	if (IS_ERR(fsl_ldb->next_bridge))
+		return dev_err_probe(dev, PTR_ERR(fsl_ldb->next_bridge),
+				     "failed to get next bridge\n");
 
 	if (fsl_ldb_is_dual(fsl_ldb)) {
 		struct device_node *port1, *port2;
-- 
2.34.1

[PATCH v4 03/13] drm/bridge: fsl-ldb: Use clk_round_rate() to validate "ldb" clock rate

[Liu Ying]

Multiple display modes could be read from a display device's EDID.
Use clk_round_rate() to validate the "ldb" clock rate for each mode
in drm_bridge_funcs::mode_valid() to filter unsupported modes out.

Also, since this driver doesn't directly reference pixel clock, use
clk_round_rate() to validate the pixel clock rate against the "ldb"
clock if the "ldb" clock and the pixel clock are sibling in clock
tree.  This is not done in display controller driver because
drm_crtc_helper_funcs::mode_valid() may not decide to do the
validation or not if multiple encoders are connected to the CRTC,
e.g., i.MX93 LCDIF may connect with MIPI DSI controller, LDB and
parallel display output simultaneously.

Signed-off-by: Liu Ying <victor.liu@nxp.com>
---
Note that this patch depends on a patch in shawnguo/imx/fixes:
https://patchwork.kernel.org/project/linux-arm-kernel/patch/20241017031146.157996-1-marex@denx.de/

v4:
* No change.

v3:
* No change.

v2:
* Add more comments in fsl-ldb.c and commit message about pixel clock
  rate validation.  (Maxime)

 drivers/gpu/drm/bridge/fsl-ldb.c | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

diff --git a/drivers/gpu/drm/bridge/fsl-ldb.c b/drivers/gpu/drm/bridge/fsl-ldb.c
index b559f3e0bef6..77afc169f0d3 100644
--- a/drivers/gpu/drm/bridge/fsl-ldb.c
+++ b/drivers/gpu/drm/bridge/fsl-ldb.c
@@ -11,6 +11,7 @@
 #include <linux/of_graph.h>
 #include <linux/platform_device.h>
 #include <linux/regmap.h>
+#include <linux/units.h>
 
 #include <drm/drm_atomic_helper.h>
 #include <drm/drm_bridge.h>
@@ -64,6 +65,7 @@ struct fsl_ldb_devdata {
 	u32 lvds_ctrl;
 	bool lvds_en_bit;
 	bool single_ctrl_reg;
+	bool ldb_clk_pixel_clk_sibling;
 };
 
 static const struct fsl_ldb_devdata fsl_ldb_devdata[] = {
@@ -74,11 +76,13 @@ static const struct fsl_ldb_devdata fsl_ldb_devdata[] = {
 	[IMX8MP_LDB] = {
 		.ldb_ctrl = 0x5c,
 		.lvds_ctrl = 0x128,
+		.ldb_clk_pixel_clk_sibling = true,
 	},
 	[IMX93_LDB] = {
 		.ldb_ctrl = 0x20,
 		.lvds_ctrl = 0x24,
 		.lvds_en_bit = true,
+		.ldb_clk_pixel_clk_sibling = true,
 	},
 };
 
@@ -269,11 +273,31 @@ fsl_ldb_mode_valid(struct drm_bridge *bridge,
 		   const struct drm_display_info *info,
 		   const struct drm_display_mode *mode)
 {
+	unsigned long link_freq, pclk_rate, rounded_pclk_rate;
 	struct fsl_ldb *fsl_ldb = to_fsl_ldb(bridge);
 
 	if (mode->clock > (fsl_ldb_is_dual(fsl_ldb) ? 160000 : 80000))
 		return MODE_CLOCK_HIGH;
 
+	/* Validate "ldb" clock rate. */
+	link_freq = fsl_ldb_link_frequency(fsl_ldb, mode->clock);
+	if (link_freq != clk_round_rate(fsl_ldb->clk, link_freq))
+		return MODE_NOCLOCK;
+
+	/*
+	 * Since this driver doesn't directly reference pixel clock and
+	 * display controller driver cannot validate pixel clock due to
+	 * multiple types of encoders connected, use "ldb" clock to
+	 * validate pixel clock rate, if the two clocks are sibling.
+	 */
+	if (fsl_ldb->devdata->ldb_clk_pixel_clk_sibling) {
+		pclk_rate = mode->clock * HZ_PER_KHZ;
+
+		rounded_pclk_rate = clk_round_rate(fsl_ldb->clk, pclk_rate);
+		if (rounded_pclk_rate != pclk_rate)
+			return MODE_NOCLOCK;
+	}
+
 	return MODE_OK;
 }
 
-- 
2.34.1

[PATCH v4 04/13] media: uapi: Add MEDIA_BUS_FMT_RGB101010_1X7X5_{SPWG, JEIDA}

[Liu Ying]

Add two media bus formats that identify 30-bit RGB pixels transmitted
by a LVDS link with five differential data pairs, serialized into 7
time slots, using standard SPWG/VESA or JEIDA data mapping.

Signed-off-by: Liu Ying <victor.liu@nxp.com>
---
v4:
* No change.

v3:
* New patch.

 .../media/v4l/subdev-formats.rst              | 156 +++++++++++++++++-
 include/uapi/linux/media-bus-format.h         |   4 +-
 2 files changed, 157 insertions(+), 3 deletions(-)

diff --git a/Documentation/userspace-api/media/v4l/subdev-formats.rst b/Documentation/userspace-api/media/v4l/subdev-formats.rst
index d2a6cd2e1eb2..2a94371448dc 100644
--- a/Documentation/userspace-api/media/v4l/subdev-formats.rst
+++ b/Documentation/userspace-api/media/v4l/subdev-formats.rst
@@ -2225,7 +2225,7 @@ The following table list existing packed 48bit wide RGB formats.
     \endgroup
 
 On LVDS buses, usually each sample is transferred serialized in seven
-time slots per pixel clock, on three (18-bit) or four (24-bit)
+time slots per pixel clock, on three (18-bit) or four (24-bit) or five (30-bit)
 differential data pairs at the same time. The remaining bits are used
 for control signals as defined by SPWG/PSWG/VESA or JEIDA standards. The
 24-bit RGB format serialized in seven time slots on four lanes using
@@ -2246,11 +2246,12 @@ JEIDA defined bit mapping will be named
       - Code
       -
       -
-      - :cspan:`3` Data organization
+      - :cspan:`4` Data organization
     * -
       -
       - Timeslot
       - Lane
+      - 4
       - 3
       - 2
       - 1
@@ -2262,6 +2263,7 @@ JEIDA defined bit mapping will be named
       - 0
       -
       -
+      -
       - d
       - b\ :sub:`1`
       - g\ :sub:`0`
@@ -2270,6 +2272,7 @@ JEIDA defined bit mapping will be named
       - 1
       -
       -
+      -
       - d
       - b\ :sub:`0`
       - r\ :sub:`5`
@@ -2278,6 +2281,7 @@ JEIDA defined bit mapping will be named
       - 2
       -
       -
+      -
       - d
       - g\ :sub:`5`
       - r\ :sub:`4`
@@ -2286,6 +2290,7 @@ JEIDA defined bit mapping will be named
       - 3
       -
       -
+      -
       - b\ :sub:`5`
       - g\ :sub:`4`
       - r\ :sub:`3`
@@ -2294,6 +2299,7 @@ JEIDA defined bit mapping will be named
       - 4
       -
       -
+      -
       - b\ :sub:`4`
       - g\ :sub:`3`
       - r\ :sub:`2`
@@ -2302,6 +2308,7 @@ JEIDA defined bit mapping will be named
       - 5
       -
       -
+      -
       - b\ :sub:`3`
       - g\ :sub:`2`
       - r\ :sub:`1`
@@ -2310,6 +2317,7 @@ JEIDA defined bit mapping will be named
       - 6
       -
       -
+      -
       - b\ :sub:`2`
       - g\ :sub:`1`
       - r\ :sub:`0`
@@ -2319,6 +2327,7 @@ JEIDA defined bit mapping will be named
       - 0x1011
       - 0
       -
+      -
       - d
       - d
       - b\ :sub:`1`
@@ -2327,6 +2336,7 @@ JEIDA defined bit mapping will be named
       -
       - 1
       -
+      -
       - b\ :sub:`7`
       - d
       - b\ :sub:`0`
@@ -2335,6 +2345,7 @@ JEIDA defined bit mapping will be named
       -
       - 2
       -
+      -
       - b\ :sub:`6`
       - d
       - g\ :sub:`5`
@@ -2343,6 +2354,7 @@ JEIDA defined bit mapping will be named
       -
       - 3
       -
+      -
       - g\ :sub:`7`
       - b\ :sub:`5`
       - g\ :sub:`4`
@@ -2351,6 +2363,7 @@ JEIDA defined bit mapping will be named
       -
       - 4
       -
+      -
       - g\ :sub:`6`
       - b\ :sub:`4`
       - g\ :sub:`3`
@@ -2359,6 +2372,7 @@ JEIDA defined bit mapping will be named
       -
       - 5
       -
+      -
       - r\ :sub:`7`
       - b\ :sub:`3`
       - g\ :sub:`2`
@@ -2367,6 +2381,7 @@ JEIDA defined bit mapping will be named
       -
       - 6
       -
+      -
       - r\ :sub:`6`
       - b\ :sub:`2`
       - g\ :sub:`1`
@@ -2377,6 +2392,7 @@ JEIDA defined bit mapping will be named
       - 0x1012
       - 0
       -
+      -
       - d
       - d
       - b\ :sub:`3`
@@ -2385,6 +2401,7 @@ JEIDA defined bit mapping will be named
       -
       - 1
       -
+      -
       - b\ :sub:`1`
       - d
       - b\ :sub:`2`
@@ -2393,6 +2410,7 @@ JEIDA defined bit mapping will be named
       -
       - 2
       -
+      -
       - b\ :sub:`0`
       - d
       - g\ :sub:`7`
@@ -2401,6 +2419,7 @@ JEIDA defined bit mapping will be named
       -
       - 3
       -
+      -
       - g\ :sub:`1`
       - b\ :sub:`7`
       - g\ :sub:`6`
@@ -2409,6 +2428,7 @@ JEIDA defined bit mapping will be named
       -
       - 4
       -
+      -
       - g\ :sub:`0`
       - b\ :sub:`6`
       - g\ :sub:`5`
@@ -2417,6 +2437,7 @@ JEIDA defined bit mapping will be named
       -
       - 5
       -
+      -
       - r\ :sub:`1`
       - b\ :sub:`5`
       - g\ :sub:`4`
@@ -2425,10 +2446,141 @@ JEIDA defined bit mapping will be named
       -
       - 6
       -
+      -
+      - r\ :sub:`0`
+      - b\ :sub:`4`
+      - g\ :sub:`3`
+      - r\ :sub:`2`
+    * .. _MEDIA-BUS-FMT-RGB101010-1X7X5-SPWG:
+
+      - MEDIA_BUS_FMT_RGB101010_1X7X5_SPWG
+      - 0x1026
+      - 0
+      -
+      - d
+      - d
+      - d
+      - b\ :sub:`1`
+      - g\ :sub:`0`
+    * -
+      -
+      - 1
+      -
+      - b\ :sub:`9`
+      - b\ :sub:`7`
+      - d
+      - b\ :sub:`0`
+      - r\ :sub:`5`
+    * -
+      -
+      - 2
+      -
+      - b\ :sub:`8`
+      - b\ :sub:`6`
+      - d
+      - g\ :sub:`5`
+      - r\ :sub:`4`
+    * -
+      -
+      - 3
+      -
+      - g\ :sub:`9`
+      - g\ :sub:`7`
+      - b\ :sub:`5`
+      - g\ :sub:`4`
+      - r\ :sub:`3`
+    * -
+      -
+      - 4
+      -
+      - g\ :sub:`8`
+      - g\ :sub:`6`
+      - b\ :sub:`4`
+      - g\ :sub:`3`
+      - r\ :sub:`2`
+    * -
+      -
+      - 5
+      -
+      - r\ :sub:`9`
+      - r\ :sub:`7`
+      - b\ :sub:`3`
+      - g\ :sub:`2`
+      - r\ :sub:`1`
+    * -
+      -
+      - 6
+      -
+      - r\ :sub:`8`
+      - r\ :sub:`6`
+      - b\ :sub:`2`
+      - g\ :sub:`1`
       - r\ :sub:`0`
+    * .. _MEDIA-BUS-FMT-RGB101010-1X7X5-JEIDA:
+
+      - MEDIA_BUS_FMT_RGB101010_1X7X5_JEIDA
+      - 0x1027
+      - 0
+      -
+      - d
+      - d
+      - d
+      - b\ :sub:`5`
+      - g\ :sub:`4`
+    * -
+      -
+      - 1
+      -
+      - b\ :sub:`1`
+      - b\ :sub:`3`
+      - d
       - b\ :sub:`4`
+      - r\ :sub:`9`
+    * -
+      -
+      - 2
+      -
+      - b\ :sub:`0`
+      - b\ :sub:`2`
+      - d
+      - g\ :sub:`9`
+      - r\ :sub:`8`
+    * -
+      -
+      - 3
+      -
+      - g\ :sub:`1`
       - g\ :sub:`3`
+      - b\ :sub:`9`
+      - g\ :sub:`8`
+      - r\ :sub:`7`
+    * -
+      -
+      - 4
+      -
+      - g\ :sub:`0`
+      - g\ :sub:`2`
+      - b\ :sub:`8`
+      - g\ :sub:`7`
+      - r\ :sub:`6`
+    * -
+      -
+      - 5
+      -
+      - r\ :sub:`1`
+      - r\ :sub:`3`
+      - b\ :sub:`7`
+      - g\ :sub:`6`
+      - r\ :sub:`5`
+    * -
+      -
+      - 6
+      -
+      - r\ :sub:`0`
       - r\ :sub:`2`
+      - b\ :sub:`6`
+      - g\ :sub:`5`
+      - r\ :sub:`4`
 
 .. raw:: latex
 
diff --git a/include/uapi/linux/media-bus-format.h b/include/uapi/linux/media-bus-format.h
index d4c1d991014b..ff62056feed5 100644
--- a/include/uapi/linux/media-bus-format.h
+++ b/include/uapi/linux/media-bus-format.h
@@ -34,7 +34,7 @@
 
 #define MEDIA_BUS_FMT_FIXED			0x0001
 
-/* RGB - next is	0x1026 */
+/* RGB - next is	0x1028 */
 #define MEDIA_BUS_FMT_RGB444_1X12		0x1016
 #define MEDIA_BUS_FMT_RGB444_2X8_PADHI_BE	0x1001
 #define MEDIA_BUS_FMT_RGB444_2X8_PADHI_LE	0x1002
@@ -68,6 +68,8 @@
 #define MEDIA_BUS_FMT_ARGB8888_1X32		0x100d
 #define MEDIA_BUS_FMT_RGB888_1X32_PADHI		0x100f
 #define MEDIA_BUS_FMT_RGB101010_1X30		0x1018
+#define MEDIA_BUS_FMT_RGB101010_1X7X5_SPWG	0x1026
+#define MEDIA_BUS_FMT_RGB101010_1X7X5_JEIDA	0x1027
 #define MEDIA_BUS_FMT_RGB666_1X36_CPADLO	0x1020
 #define MEDIA_BUS_FMT_RGB888_1X36_CPADLO	0x1021
 #define MEDIA_BUS_FMT_RGB121212_1X36		0x1019
-- 
2.34.1

[PATCH v4 05/13] drm: of: Get MEDIA_BUS_FMT_RGB101010_1X7X5_{JEIDA, SPWG} LVDS data mappings

[Liu Ying]

Add MEDIA_BUS_FMT_RGB101010_1X7X5_{JEIDA,SPWG} support in
drm_of_lvds_get_data_mapping() function implementation so that function
callers may get the two LVDS data mappings.

Signed-off-by: Liu Ying <victor.liu@nxp.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
---
v4:
* Collect Dmitry's R-b tag.

v3:
* New patch.

 drivers/gpu/drm/drm_of.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
index 177b600895d3..89863a35c731 100644
--- a/drivers/gpu/drm/drm_of.c
+++ b/drivers/gpu/drm/drm_of.c
@@ -410,7 +410,9 @@ EXPORT_SYMBOL_GPL(drm_of_lvds_get_dual_link_pixel_order);
  * Return:
  * * MEDIA_BUS_FMT_RGB666_1X7X3_SPWG - data-mapping is "jeida-18"
  * * MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA - data-mapping is "jeida-24"
+ * * MEDIA_BUS_FMT_RGB101010_1X7X5_JEIDA - data-mapping is "jeida-30"
  * * MEDIA_BUS_FMT_RGB888_1X7X4_SPWG - data-mapping is "vesa-24"
+ * * MEDIA_BUS_FMT_RGB101010_1X7X5_SPWG - data-mapping is "vesa-30"
  * * -EINVAL - the "data-mapping" property is unsupported
  * * -ENODEV - the "data-mapping" property is missing
  */
@@ -427,8 +429,12 @@ int drm_of_lvds_get_data_mapping(const struct device_node *port)
 		return MEDIA_BUS_FMT_RGB666_1X7X3_SPWG;
 	if (!strcmp(mapping, "jeida-24"))
 		return MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA;
+	if (!strcmp(mapping, "jeida-30"))
+		return MEDIA_BUS_FMT_RGB101010_1X7X5_JEIDA;
 	if (!strcmp(mapping, "vesa-24"))
 		return MEDIA_BUS_FMT_RGB888_1X7X4_SPWG;
+	if (!strcmp(mapping, "vesa-30"))
+		return MEDIA_BUS_FMT_RGB101010_1X7X5_SPWG;
 
 	return -EINVAL;
 }
-- 
2.34.1

[PATCH v4 06/13] drm: of: Add drm_of_lvds_get_dual_link_pixel_order_sink()

[Liu Ying]

drm_of_lvds_get_dual_link_pixel_order() gets LVDS dual-link source pixel
order.  Similar to it, add it's counterpart function
drm_of_lvds_get_dual_link_pixel_order_sink() to get LVDS dual-link sink
pixel order.

Suggested-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Liu Ying <victor.liu@nxp.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
---
v4:
* Collect Dmitry's R-b tag.

v3:
* New patch.  (Dmitry)

 drivers/gpu/drm/drm_of.c | 76 ++++++++++++++++++++++++++++++++++------
 include/drm/drm_of.h     |  9 +++++
 2 files changed, 74 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
index 89863a35c731..5c2abc9eca9c 100644
--- a/drivers/gpu/drm/drm_of.c
+++ b/drivers/gpu/drm/drm_of.c
@@ -341,8 +341,23 @@ static int drm_of_lvds_get_remote_pixels_type(
 	return pixels_type;
 }
 
+static int __drm_of_lvds_get_dual_link_pixel_order(int p1_pt, int p2_pt)
+{
+	/*
+	 * A valid dual-lVDS bus is found when one port is marked with
+	 * "dual-lvds-even-pixels", and the other port is marked with
+	 * "dual-lvds-odd-pixels", bail out if the markers are not right.
+	 */
+	if (p1_pt + p2_pt != DRM_OF_LVDS_EVEN + DRM_OF_LVDS_ODD)
+		return -EINVAL;
+
+	return p1_pt == DRM_OF_LVDS_EVEN ?
+		DRM_LVDS_DUAL_LINK_EVEN_ODD_PIXELS :
+		DRM_LVDS_DUAL_LINK_ODD_EVEN_PIXELS;
+}
+
 /**
- * drm_of_lvds_get_dual_link_pixel_order - Get LVDS dual-link pixel order
+ * drm_of_lvds_get_dual_link_pixel_order - Get LVDS dual-link source pixel order
  * @port1: First DT port node of the Dual-link LVDS source
  * @port2: Second DT port node of the Dual-link LVDS source
  *
@@ -387,19 +402,58 @@ int drm_of_lvds_get_dual_link_pixel_order(const struct device_node *port1,
 	if (remote_p2_pt < 0)
 		return remote_p2_pt;
 
-	/*
-	 * A valid dual-lVDS bus is found when one remote port is marked with
-	 * "dual-lvds-even-pixels", and the other remote port is marked with
-	 * "dual-lvds-odd-pixels", bail out if the markers are not right.
-	 */
-	if (remote_p1_pt + remote_p2_pt != DRM_OF_LVDS_EVEN + DRM_OF_LVDS_ODD)
+	return __drm_of_lvds_get_dual_link_pixel_order(remote_p1_pt, remote_p2_pt);
+}
+EXPORT_SYMBOL_GPL(drm_of_lvds_get_dual_link_pixel_order);
+
+/**
+ * drm_of_lvds_get_dual_link_pixel_order_sink - Get LVDS dual-link sink pixel order
+ * @port1: First DT port node of the Dual-link LVDS sink
+ * @port2: Second DT port node of the Dual-link LVDS sink
+ *
+ * An LVDS dual-link connection is made of two links, with even pixels
+ * transitting on one link, and odd pixels on the other link. This function
+ * returns, for two ports of an LVDS dual-link sink, which port shall transmit
+ * the even and odd pixels, based on the requirements of the sink.
+ *
+ * The pixel order is determined from the dual-lvds-even-pixels and
+ * dual-lvds-odd-pixels properties in the sink's DT port nodes. If those
+ * properties are not present, or if their usage is not valid, this function
+ * returns -EINVAL.
+ *
+ * If either port is not connected, this function returns -EPIPE.
+ *
+ * @port1 and @port2 are typically DT sibling nodes, but may have different
+ * parents when, for instance, two separate LVDS decoders receive the even and
+ * odd pixels.
+ *
+ * Return:
+ * * DRM_LVDS_DUAL_LINK_EVEN_ODD_PIXELS - @port1 receives even pixels and @port2
+ *   receives odd pixels
+ * * DRM_LVDS_DUAL_LINK_ODD_EVEN_PIXELS - @port1 receives odd pixels and @port2
+ *   receives even pixels
+ * * -EINVAL - @port1 or @port2 are NULL
+ * * -EPIPE - when @port1 or @port2 are not connected
+ */
+int drm_of_lvds_get_dual_link_pixel_order_sink(struct device_node *port1,
+					       struct device_node *port2)
+{
+	int sink_p1_pt, sink_p2_pt;
+
+	if (!port1 || !port2)
 		return -EINVAL;
 
-	return remote_p1_pt == DRM_OF_LVDS_EVEN ?
-		DRM_LVDS_DUAL_LINK_EVEN_ODD_PIXELS :
-		DRM_LVDS_DUAL_LINK_ODD_EVEN_PIXELS;
+	sink_p1_pt = drm_of_lvds_get_port_pixels_type(port1);
+	if (!sink_p1_pt)
+		return -EPIPE;
+
+	sink_p2_pt = drm_of_lvds_get_port_pixels_type(port2);
+	if (!sink_p2_pt)
+		return -EPIPE;
+
+	return __drm_of_lvds_get_dual_link_pixel_order(sink_p1_pt, sink_p2_pt);
 }
-EXPORT_SYMBOL_GPL(drm_of_lvds_get_dual_link_pixel_order);
+EXPORT_SYMBOL_GPL(drm_of_lvds_get_dual_link_pixel_order_sink);
 
 /**
  * drm_of_lvds_get_data_mapping - Get LVDS data mapping
diff --git a/include/drm/drm_of.h b/include/drm/drm_of.h
index 02d1cdd7f798..7f0256dae3f1 100644
--- a/include/drm/drm_of.h
+++ b/include/drm/drm_of.h
@@ -52,6 +52,8 @@ int drm_of_find_panel_or_bridge(const struct device_node *np,
 				struct drm_bridge **bridge);
 int drm_of_lvds_get_dual_link_pixel_order(const struct device_node *port1,
 					  const struct device_node *port2);
+int drm_of_lvds_get_dual_link_pixel_order_sink(struct device_node *port1,
+					       struct device_node *port2);
 int drm_of_lvds_get_data_mapping(const struct device_node *port);
 int drm_of_get_data_lanes_count(const struct device_node *endpoint,
 				const unsigned int min, const unsigned int max);
@@ -109,6 +111,13 @@ drm_of_lvds_get_dual_link_pixel_order(const struct device_node *port1,
 	return -EINVAL;
 }
 
+static inline int
+drm_of_lvds_get_dual_link_pixel_order_sink(struct device_node *port1,
+					   struct device_node *port2)
+{
+	return -EINVAL;
+}
+
 static inline int
 drm_of_lvds_get_data_mapping(const struct device_node *port)
 {
-- 
2.34.1

[PATCH v4 07/13] dt-bindings: display: lvds-data-mapping: Add 30-bit RGB pixel data mappings

[Liu Ying]

Add "jeida-30" and "vesa-30" data mappings that are compatible with JEIDA
and VESA respectively.

Signed-off-by: Liu Ying <victor.liu@nxp.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
v4:
* Collect Krzysztof's A-b tag.

v3:
* New patch.

 .../bindings/display/lvds-data-mapping.yaml   | 31 +++++++++++++++++++
 1 file changed, 31 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/lvds-data-mapping.yaml b/Documentation/devicetree/bindings/display/lvds-data-mapping.yaml
index d68982fe2e9b..ab842594feb9 100644
--- a/Documentation/devicetree/bindings/display/lvds-data-mapping.yaml
+++ b/Documentation/devicetree/bindings/display/lvds-data-mapping.yaml
@@ -26,12 +26,17 @@ description: |
   Device compatible with those specifications have been marketed under the
   FPD-Link and FlatLink brands.
 
+  This bindings also supports 30-bit data mapping compatible with JEIDA and
+  VESA.
+
 properties:
   data-mapping:
     enum:
       - jeida-18
       - jeida-24
+      - jeida-30
       - vesa-24
+      - vesa-30
     description: |
       The color signals mapping order.
 
@@ -60,6 +65,19 @@ properties:
       DATA2     ><_CTL2_><_CTL1_><_CTL0_><__B7__><__B6__><__B5__><__B4__><
       DATA3     ><_CTL3_><__B1__><__B0__><__G1__><__G0__><__R1__><__R0__><
 
+      - "jeida-30" - 30-bit data mapping compatible with JEIDA and VESA. Data
+        are transferred as follows on 5 LVDS lanes.
+
+      Slot          0       1       2       3       4       5       6
+                ________________                         _________________
+      Clock                     \_______________________/
+                  ______  ______  ______  ______  ______  ______  ______
+      DATA0     ><__G4__><__R9__><__R8__><__R7__><__R6__><__R5__><__R4__><
+      DATA1     ><__B5__><__B4__><__G9__><__G8__><__G7__><__G6__><__G5__><
+      DATA2     ><_CTL2_><_CTL1_><_CTL0_><__B9__><__B8__><__B7__><__B6__><
+      DATA3     ><_CTL3_><__B3__><__B2__><__G3__><__G2__><__R3__><__R2__><
+      DATA4     ><_CTL3_><__B1__><__B0__><__G1__><__G0__><__R1__><__R0__><
+
       - "vesa-24" - 24-bit data mapping compatible with the [VESA] specification.
         Data are transferred as follows on 4 LVDS lanes.
 
@@ -72,6 +90,19 @@ properties:
       DATA2     ><_CTL2_><_CTL1_><_CTL0_><__B5__><__B4__><__B3__><__B2__><
       DATA3     ><_CTL3_><__B7__><__B6__><__G7__><__G6__><__R7__><__R6__><
 
+      - "vesa-30" - 30-bit data mapping compatible with VESA. Data are
+        transferred as follows on 5 LVDS lanes.
+
+      Slot          0       1       2       3       4       5       6
+                ________________                         _________________
+      Clock                     \_______________________/
+                  ______  ______  ______  ______  ______  ______  ______
+      DATA0     ><__G0__><__R5__><__R4__><__R3__><__R2__><__R1__><__R0__><
+      DATA1     ><__B1__><__B0__><__G5__><__G4__><__G3__><__G2__><__G1__><
+      DATA2     ><_CTL2_><_CTL1_><_CTL0_><__B5__><__B4__><__B3__><__B2__><
+      DATA3     ><_CTL3_><__B7__><__B6__><__G7__><__G6__><__R7__><__R6__><
+      DATA4     ><_CTL3_><__B9__><__B8__><__G9__><__G8__><__R9__><__R8__><
+
       Control signals are mapped as follows.
 
       CTL0: HSync
-- 
2.34.1

[PATCH v4 08/13] dt-bindings: display: Document dual-link LVDS display common properties

[Liu Ying]

Dual-link LVDS displays receive odd pixels and even pixels separately from
dual LVDS links.  One link receives odd pixels and the other receives even
pixels.  Some of those displays may also use only one LVDS link to receive
all pixels, being odd and even agnostic.  Document common properties for
those displays by extending LVDS display common properties defined in
lvds.yaml.

Suggested-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Liu Ying <victor.liu@nxp.com>
---
v4:
* Squash change for advantech,idk-2121wr.yaml and
  panel-simple-lvds-dual-ports.yaml with lvds-dual-ports.yaml.  (Rob)
* Improve description in lvds-dual-ports.yaml.  (Krzysztof)

v3:
* New patch.  (Dmitry)

 .../bindings/display/lvds-dual-ports.yaml     | 76 +++++++++++++++++++
 .../display/panel/advantech,idk-2121wr.yaml   | 14 +---
 .../panel/panel-simple-lvds-dual-ports.yaml   | 20 +----
 3 files changed, 78 insertions(+), 32 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/display/lvds-dual-ports.yaml

diff --git a/Documentation/devicetree/bindings/display/lvds-dual-ports.yaml b/Documentation/devicetree/bindings/display/lvds-dual-ports.yaml
new file mode 100644
index 000000000000..5f7a30640404
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/lvds-dual-ports.yaml
@@ -0,0 +1,76 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/lvds-dual-ports.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Dual-link LVDS Display Common Properties
+
+maintainers:
+  - Liu Ying <victor.liu@nxp.com>
+
+description: |
+  Common properties for LVDS displays with dual LVDS links. Extend LVDS display
+  common properties defined in lvds.yaml.
+
+  Dual-link LVDS displays receive odd pixels and even pixels separately from
+  the dual LVDS links. One link receives odd pixels and the other receives
+  even pixels. Some of those displays may also use only one LVDS link to
+  receive all pixels, being odd and even agnostic.
+
+allOf:
+  - $ref: lvds.yaml#
+
+properties:
+  ports:
+    $ref: /schemas/graph.yaml#/properties/ports
+
+    properties:
+      port@0:
+        $ref: /schemas/graph.yaml#/$defs/port-base
+        unevaluatedProperties: false
+        description: the first LVDS input link
+
+        properties:
+          dual-lvds-odd-pixels:
+            type: boolean
+            description: the first LVDS input link for odd pixels
+
+          dual-lvds-even-pixels:
+            type: boolean
+            description: the first LVDS input link for even pixels
+
+        oneOf:
+          - required: [dual-lvds-odd-pixels]
+          - required: [dual-lvds-even-pixels]
+          - properties:
+              dual-lvds-odd-pixels: false
+              dual-lvds-even-pixels: false
+
+      port@1:
+        $ref: /schemas/graph.yaml#/$defs/port-base
+        unevaluatedProperties: false
+        description: the second LVDS input link
+
+        properties:
+          dual-lvds-odd-pixels:
+            type: boolean
+            description: the second LVDS input link for odd pixels
+
+          dual-lvds-even-pixels:
+            type: boolean
+            description: the second LVDS input link for even pixels
+
+        oneOf:
+          - required: [dual-lvds-odd-pixels]
+          - required: [dual-lvds-even-pixels]
+          - properties:
+              dual-lvds-odd-pixels: false
+              dual-lvds-even-pixels: false
+
+required:
+  - ports
+
+additionalProperties: true
+
+...
diff --git a/Documentation/devicetree/bindings/display/panel/advantech,idk-2121wr.yaml b/Documentation/devicetree/bindings/display/panel/advantech,idk-2121wr.yaml
index 2e8dbdb5a3d5..05ca3b2385f8 100644
--- a/Documentation/devicetree/bindings/display/panel/advantech,idk-2121wr.yaml
+++ b/Documentation/devicetree/bindings/display/panel/advantech,idk-2121wr.yaml
@@ -20,6 +20,7 @@ description: |
   dual-lvds-odd-pixels or dual-lvds-even-pixels).
 
 allOf:
+  - $ref: /schemas/display/lvds-dual-ports.yaml#
   - $ref: panel-common.yaml#
 
 properties:
@@ -44,22 +45,10 @@ properties:
 
     properties:
       port@0:
-        $ref: /schemas/graph.yaml#/$defs/port-base
-        unevaluatedProperties: false
-        description: The sink for odd pixels.
-        properties:
-          dual-lvds-odd-pixels: true
-
         required:
           - dual-lvds-odd-pixels
 
       port@1:
-        $ref: /schemas/graph.yaml#/$defs/port-base
-        unevaluatedProperties: false
-        description: The sink for even pixels.
-        properties:
-          dual-lvds-even-pixels: true
-
         required:
           - dual-lvds-even-pixels
 
@@ -75,7 +64,6 @@ required:
   - height-mm
   - data-mapping
   - panel-timing
-  - ports
 
 examples:
   - |+
diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple-lvds-dual-ports.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple-lvds-dual-ports.yaml
index 10ed4b57232b..e80fc7006984 100644
--- a/Documentation/devicetree/bindings/display/panel/panel-simple-lvds-dual-ports.yaml
+++ b/Documentation/devicetree/bindings/display/panel/panel-simple-lvds-dual-ports.yaml
@@ -22,6 +22,7 @@ description: |
   If the panel is more advanced a dedicated binding file is required.
 
 allOf:
+  - $ref: /schemas/display/lvds-dual-ports.yaml#
   - $ref: panel-common.yaml#
 
 properties:
@@ -55,28 +56,10 @@ properties:
 
     properties:
       port@0:
-        $ref: /schemas/graph.yaml#/$defs/port-base
-        unevaluatedProperties: false
-        description: The first sink port.
-
-        properties:
-          dual-lvds-odd-pixels:
-            type: boolean
-            description: The first sink port for odd pixels.
-
         required:
           - dual-lvds-odd-pixels
 
       port@1:
-        $ref: /schemas/graph.yaml#/$defs/port-base
-        unevaluatedProperties: false
-        description: The second sink port.
-
-        properties:
-          dual-lvds-even-pixels:
-            type: boolean
-            description: The second sink port for even pixels.
-
         required:
           - dual-lvds-even-pixels
 
@@ -88,7 +71,6 @@ unevaluatedProperties: false
 
 required:
   - compatible
-  - ports
   - power-supply
 
 examples:
-- 
2.34.1

[PATCH v4 09/13] dt-bindings: display: bridge: Add ITE IT6263 LVDS to HDMI converter

[Liu Ying]

Document ITE IT6263 LVDS to HDMI converter.

Product link:
https://www.ite.com.tw/en/product/cate1/IT6263

Signed-off-by: Liu Ying <victor.liu@nxp.com>
---
v4:
* Require dual-lvds-odd-pixels or dual-lvds-even-pixels DT properties for
  port@1.
* Drop "data-mirror: true"(30-bit LVDS data bit order is not reversed).

v3:
* Reference lvds-dual-ports.yaml.  (Dmitry)
* Add data-mapping DT property.  (Dmitry, Biju)
* Allow data-mirror.
* Drop ite,lvds-link-num-data-lanes DT property.  (Dmitry, Biju)

v2:
* Document number of LVDS link data lanes.  (Biju)
* Simplify ports property by dropping "oneOf".  (Rob)

 .../bindings/display/bridge/ite,it6263.yaml   | 250 ++++++++++++++++++
 1 file changed, 250 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/bridge/ite,it6263.yaml

diff --git a/Documentation/devicetree/bindings/display/bridge/ite,it6263.yaml b/Documentation/devicetree/bindings/display/bridge/ite,it6263.yaml
new file mode 100644
index 000000000000..0a10e10d80ff
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/ite,it6263.yaml
@@ -0,0 +1,250 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/ite,it6263.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ITE IT6263 LVDS to HDMI converter
+
+maintainers:
+  - Liu Ying <victor.liu@nxp.com>
+
+description: |
+  The IT6263 is a high-performance single-chip De-SSC(De-Spread Spectrum) LVDS
+  to HDMI converter.  Combined with LVDS receiver and HDMI 1.4a transmitter,
+  the IT6263 supports LVDS input and HDMI 1.4 output by conversion function.
+  The built-in LVDS receiver can support single-link and dual-link LVDS inputs,
+  and the built-in HDMI transmitter is fully compliant with HDMI 1.4a/3D, HDCP
+  1.2 and backward compatible with DVI 1.0 specification.
+
+  The IT6263 also encodes and transmits up to 8 channels of I2S digital audio,
+  with sampling rate up to 192KHz and sample size up to 24 bits. In addition,
+  an S/PDIF input port takes in compressed audio of up to 192KHz frame rate.
+
+  The newly supported High-Bit Rate(HBR) audio by HDMI specifications v1.3 is
+  provided by the IT6263 in two interfaces: the four I2S input ports or the
+  S/PDIF input port.  With both interfaces the highest possible HBR frame rate
+  is supported at up to 768KHz.
+
+allOf:
+  - $ref: /schemas/display/lvds-dual-ports.yaml#
+
+properties:
+  compatible:
+    const: ite,it6263
+
+  reg:
+    maxItems: 1
+
+  clocks:
+    maxItems: 1
+    description: audio master clock
+
+  clock-names:
+    const: mclk
+
+  data-mapping:
+    enum:
+      - jeida-18
+      - jeida-24
+      - jeida-30
+      - vesa-24
+      - vesa-30
+
+  reset-gpios:
+    maxItems: 1
+
+  ivdd-supply:
+    description: 1.8V digital logic power
+
+  ovdd-supply:
+    description: 3.3V I/O pin power
+
+  txavcc18-supply:
+    description: 1.8V HDMI analog frontend power
+
+  txavcc33-supply:
+    description: 3.3V HDMI analog frontend power
+
+  pvcc1-supply:
+    description: 1.8V HDMI frontend core PLL power
+
+  pvcc2-supply:
+    description: 1.8V HDMI frontend filter PLL power
+
+  avcc-supply:
+    description: 3.3V LVDS frontend power
+
+  anvdd-supply:
+    description: 1.8V LVDS frontend analog power
+
+  apvdd-supply:
+    description: 1.8V LVDS frontend PLL power
+
+  "#sound-dai-cells":
+    const: 0
+
+  ite,i2s-audio-fifo-sources:
+    $ref: /schemas/types.yaml#/definitions/uint32-array
+    minItems: 1
+    maxItems: 4
+    items:
+      enum: [0, 1, 2, 3]
+    description:
+      Each array element indicates the pin number of an I2S serial data input
+      line which is connected to an audio FIFO, from audio FIFO0 to FIFO3.
+
+  ite,rl-channel-swap-audio-sources:
+    $ref: /schemas/types.yaml#/definitions/uint32-array
+    minItems: 1
+    maxItems: 4
+    uniqueItems: true
+    items:
+      enum: [0, 1, 2, 3]
+    description:
+      Each array element indicates an audio source whose right channel and left
+      channel are swapped by this converter. For I2S, the element is the pin
+      number of an I2S serial data input line. For S/PDIF, the element is always
+      0.
+
+  ports:
+    $ref: /schemas/graph.yaml#/properties/ports
+
+    properties:
+      port@0: true
+
+      port@1:
+        oneOf:
+          - required: [dual-lvds-odd-pixels]
+          - required: [dual-lvds-even-pixels]
+
+      port@2:
+        $ref: /schemas/graph.yaml#/properties/port
+        description: video port for the HDMI output
+
+      port@3:
+        $ref: /schemas/graph.yaml#/properties/port
+        description: sound input port
+
+    required:
+      - port@0
+      - port@2
+
+required:
+  - compatible
+  - reg
+  - data-mapping
+  - ivdd-supply
+  - ovdd-supply
+  - txavcc18-supply
+  - txavcc33-supply
+  - pvcc1-supply
+  - pvcc2-supply
+  - avcc-supply
+  - anvdd-supply
+  - apvdd-supply
+
+unevaluatedProperties: false
+
+examples:
+  - |
+    /* single-link LVDS input */
+    #include <dt-bindings/gpio/gpio.h>
+
+    i2c {
+        #address-cells = <1>;
+        #size-cells = <0>;
+
+        hdmi@4c {
+            compatible = "ite,it6263";
+            reg = <0x4c>;
+            data-mapping = "jeida-24";
+            reset-gpios = <&gpio1 10 GPIO_ACTIVE_LOW>;
+            ivdd-supply = <&reg_buck5>;
+            ovdd-supply = <&reg_vext_3v3>;
+            txavcc18-supply = <&reg_buck5>;
+            txavcc33-supply = <&reg_vext_3v3>;
+            pvcc1-supply = <&reg_buck5>;
+            pvcc2-supply = <&reg_buck5>;
+            avcc-supply = <&reg_vext_3v3>;
+            anvdd-supply = <&reg_buck5>;
+            apvdd-supply = <&reg_buck5>;
+
+            ports {
+                #address-cells = <1>;
+                #size-cells = <0>;
+
+                port@0 {
+                    reg = <0>;
+
+                    it6263_lvds_link1: endpoint {
+                        remote-endpoint = <&ldb_lvds_ch0>;
+                    };
+                };
+
+                port@2 {
+                    reg = <2>;
+
+                    it6263_out: endpoint {
+                        remote-endpoint = <&hdmi_in>;
+                    };
+                };
+            };
+        };
+    };
+
+  - |
+    /* dual-link LVDS input */
+    #include <dt-bindings/gpio/gpio.h>
+
+    i2c {
+        #address-cells = <1>;
+        #size-cells = <0>;
+
+        hdmi@4c {
+            compatible = "ite,it6263";
+            reg = <0x4c>;
+            data-mapping = "jeida-24";
+            reset-gpios = <&gpio1 10 GPIO_ACTIVE_LOW>;
+            ivdd-supply = <&reg_buck5>;
+            ovdd-supply = <&reg_vext_3v3>;
+            txavcc18-supply = <&reg_buck5>;
+            txavcc33-supply = <&reg_vext_3v3>;
+            pvcc1-supply = <&reg_buck5>;
+            pvcc2-supply = <&reg_buck5>;
+            avcc-supply = <&reg_vext_3v3>;
+            anvdd-supply = <&reg_buck5>;
+            apvdd-supply = <&reg_buck5>;
+
+            ports {
+                #address-cells = <1>;
+                #size-cells = <0>;
+
+                port@0 {
+                    reg = <0>;
+                    dual-lvds-odd-pixels;
+
+                    it6263_lvds_link1_dual: endpoint {
+                        remote-endpoint = <&ldb_lvds_ch0>;
+                    };
+                };
+
+                port@1 {
+                    reg = <1>;
+                    dual-lvds-even-pixels;
+
+                    it6263_lvds_link2_dual: endpoint {
+                        remote-endpoint = <&ldb_lvds_ch1>;
+                    };
+                };
+
+                port@2 {
+                    reg = <2>;
+
+                    it6263_out_dual: endpoint {
+                        remote-endpoint = <&hdmi_in>;
+                    };
+                };
+            };
+        };
+    };
-- 
2.34.1

[PATCH v4 10/13] drm/bridge: Add ITE IT6263 LVDS to HDMI converter

[Liu Ying]

Add basic HDMI video output support. Currently, only RGB888 output
pixel format is supported.  At the LVDS input side, the driver
supports single LVDS link and dual LVDS links with "jeida-24" LVDS
mapping.

Product link:
https://www.ite.com.tw/en/product/cate1/IT6263

Signed-off-by: Liu Ying <victor.liu@nxp.com>
Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com>
Acked-by: Maxime Ripard <mripard@kernel.org>
---
v4:
* Use local variable reset_gpio in probe().  (Biju)
* Move pixel clock rate validation from mode_valid callback to
  hdmi_tmds_char_rate_valid callback.  (Maxime)
* Document IT6263 video processing throughput constraints by adding comments.
  (Maxime)
* Fix LVDS 8-bit color depth macro BIT8.
* Drop 30-bit LVDS data bit order validation(30-bit LVDS data bit order is not
  reversed).
* Collect Biju's R-b tag and Maxime's A-b tag.

v3:
* Use HDMI connector framework.  (Maxime)
* Control the missing HDMI_REG_AVI_INFOFRM_CTRL register.
* Validate the maximal HDMI TMDS character rate.  (Dmitry)
* Get LVDS data mapping from data-mapping DT property.  (Dmitry, Biju)
* Validate 30bit LVDS data bit order by checking data-mirror DT property.
* Use drm_of_lvds_get_dual_link_pixel_order_sink().  (Dmitry)
* Initialize a bridge connector instead of open coding.  (Dmitry)
* Add a comment that IT6263 chip has no HPD IRQ support.  (Dmitry)
* Use devm_drm_bridge_add() instead of drm_bridge_add().  (Dmitry)
* Fix a minor build warning reported by kernel test robot.

v2:
* Add AVI inforframe support.  (Maxime)
* Add DRM_MODE_CONNECTOR_HDMIA.  (Biju)
* Rename it6263_reset() to it6263_hw_reset().  (Biju)
* Check number of LVDS link data lanes.  (Biju)

 drivers/gpu/drm/bridge/Kconfig      |  11 +
 drivers/gpu/drm/bridge/Makefile     |   1 +
 drivers/gpu/drm/bridge/ite-it6263.c | 898 ++++++++++++++++++++++++++++
 3 files changed, 910 insertions(+)
 create mode 100644 drivers/gpu/drm/bridge/ite-it6263.c

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 609f4d0ac93d..6b4664d91faa 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -90,6 +90,17 @@ config DRM_FSL_LDB
 	help
 	  Support for i.MX8MP DPI-to-LVDS on-SoC encoder.
 
+config DRM_ITE_IT6263
+	tristate "ITE IT6263 LVDS/HDMI bridge"
+	depends on OF
+	select DRM_DISPLAY_HDMI_STATE_HELPER
+	select DRM_DISPLAY_HELPER
+	select DRM_BRIDGE_CONNECTOR
+	select DRM_KMS_HELPER
+	select REGMAP_I2C
+	help
+	  ITE IT6263 LVDS to HDMI bridge chip driver.
+
 config DRM_ITE_IT6505
 	tristate "ITE IT6505 DisplayPort bridge"
 	depends on OF
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index 3daf803ce80b..97304b429a53 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -6,6 +6,7 @@ obj-$(CONFIG_DRM_CHRONTEL_CH7033) += chrontel-ch7033.o
 obj-$(CONFIG_DRM_CROS_EC_ANX7688) += cros-ec-anx7688.o
 obj-$(CONFIG_DRM_DISPLAY_CONNECTOR) += display-connector.o
 obj-$(CONFIG_DRM_FSL_LDB) += fsl-ldb.o
+obj-$(CONFIG_DRM_ITE_IT6263) += ite-it6263.o
 obj-$(CONFIG_DRM_ITE_IT6505) += ite-it6505.o
 obj-$(CONFIG_DRM_LONTIUM_LT8912B) += lontium-lt8912b.o
 obj-$(CONFIG_DRM_LONTIUM_LT9211) += lontium-lt9211.o
diff --git a/drivers/gpu/drm/bridge/ite-it6263.c b/drivers/gpu/drm/bridge/ite-it6263.c
new file mode 100644
index 000000000000..cbabd4e20d3e
--- /dev/null
+++ b/drivers/gpu/drm/bridge/ite-it6263.c
@@ -0,0 +1,898 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright 2024 NXP
+ */
+
+#include <linux/bitfield.h>
+#include <linux/bits.h>
+#include <linux/delay.h>
+#include <linux/gpio/consumer.h>
+#include <linux/hdmi.h>
+#include <linux/i2c.h>
+#include <linux/media-bus-format.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/regmap.h>
+#include <linux/regulator/consumer.h>
+
+#include <drm/display/drm_hdmi_helper.h>
+#include <drm/display/drm_hdmi_state_helper.h>
+#include <drm/drm_atomic.h>
+#include <drm/drm_atomic_helper.h>
+#include <drm/drm_atomic_state_helper.h>
+#include <drm/drm_bridge.h>
+#include <drm/drm_bridge_connector.h>
+#include <drm/drm_connector.h>
+#include <drm/drm_crtc.h>
+#include <drm/drm_edid.h>
+#include <drm/drm_of.h>
+#include <drm/drm_probe_helper.h>
+
+/* -----------------------------------------------------------------------------
+ * LVDS registers
+ */
+
+/* LVDS software reset registers */
+#define LVDS_REG_05			0x05
+#define  REG_SOFT_P_RST			BIT(1)
+
+/* LVDS system configuration registers */
+/* 0x0b */
+#define LVDS_REG_0B			0x0b
+#define  REG_SSC_PCLK_RF		BIT(0)
+#define  REG_LVDS_IN_SWAP		BIT(1)
+
+/* LVDS test pattern gen control registers */
+/* 0x2c */
+#define LVDS_REG_2C			0x2c
+#define  REG_COL_DEP			GENMASK(1, 0)
+#define  BIT8				FIELD_PREP(REG_COL_DEP, 1)
+#define  OUT_MAP			BIT(4)
+#define  JEIDA				0
+#define  REG_DESSC_ENB			BIT(6)
+#define  DMODE				BIT(7)
+#define  DISO				BIT(7)
+#define  SISO				0
+
+#define LVDS_REG_3C			0x3c
+#define LVDS_REG_3F			0x3f
+#define LVDS_REG_47			0x47
+#define LVDS_REG_48			0x48
+#define LVDS_REG_4F			0x4f
+#define LVDS_REG_52			0x52
+
+/* -----------------------------------------------------------------------------
+ * HDMI registers are separated into three banks:
+ * 1) HDMI register common bank: 0x00 ~ 0x2f
+ */
+
+/* HDMI genernal registers */
+#define HDMI_REG_SW_RST			0x04
+#define  SOFTREF_RST			BIT(5)
+#define  SOFTA_RST			BIT(4)
+#define  SOFTV_RST			BIT(3)
+#define  AUD_RST			BIT(2)
+#define  HDCP_RST			BIT(0)
+#define  HDMI_RST_ALL			(SOFTREF_RST | SOFTA_RST | SOFTV_RST | \
+					 AUD_RST | HDCP_RST)
+
+#define HDMI_REG_SYS_STATUS		0x0e
+#define  HPDETECT			BIT(6)
+#define  TXVIDSTABLE			BIT(4)
+
+#define HDMI_REG_BANK_CTRL		0x0f
+#define  REG_BANK_SEL			BIT(0)
+
+/* HDMI System DDC control registers */
+#define HDMI_REG_DDC_MASTER_CTRL	0x10
+#define  MASTER_SEL_HOST		BIT(0)
+
+#define HDMI_REG_DDC_HEADER		0x11
+
+#define HDMI_REG_DDC_REQOFF		0x12
+#define HDMI_REG_DDC_REQCOUNT		0x13
+#define HDMI_REG_DDC_EDIDSEG		0x14
+
+#define HDMI_REG_DDC_CMD		0x15
+#define  DDC_CMD_EDID_READ		0x3
+#define  DDC_CMD_FIFO_CLR		0x9
+
+#define HDMI_REG_DDC_STATUS		0x16
+#define  DDC_DONE			BIT(7)
+#define  DDC_NOACK			BIT(5)
+#define  DDC_WAITBUS			BIT(4)
+#define  DDC_ARBILOSE			BIT(3)
+#define  DDC_ERROR			(DDC_NOACK | DDC_WAITBUS | DDC_ARBILOSE)
+
+#define HDMI_DDC_FIFO_BYTES		32
+#define HDMI_REG_DDC_READFIFO		0x17
+#define HDMI_REG_LVDS_PORT		0x1d /* LVDS input control I2C addr */
+#define HDMI_REG_LVDS_PORT_EN		0x1e
+#define LVDS_INPUT_CTRL_I2C_ADDR	0x33
+
+/* -----------------------------------------------------------------------------
+ * 2) HDMI register bank0: 0x30 ~ 0xff
+ */
+
+/* HDMI AFE registers */
+#define HDMI_REG_AFE_DRV_CTRL		0x61
+#define  AFE_DRV_PWD			BIT(5)
+#define  AFE_DRV_RST			BIT(4)
+
+#define HDMI_REG_AFE_XP_CTRL		0x62
+#define  AFE_XP_GAINBIT			BIT(7)
+#define  AFE_XP_ER0			BIT(4)
+#define  AFE_XP_RESETB			BIT(3)
+
+#define HDMI_REG_AFE_ISW_CTRL		0x63
+
+#define HDMI_REG_AFE_IP_CTRL		0x64
+#define  AFE_IP_GAINBIT			BIT(7)
+#define  AFE_IP_ER0			BIT(3)
+#define  AFE_IP_RESETB			BIT(2)
+
+/* HDMI input data format registers */
+#define HDMI_REG_INPUT_MODE		0x70
+#define  IN_RGB				0x00
+
+/* HDMI general control registers */
+#define HDMI_REG_HDMI_MODE		0xc0
+#define  TX_HDMI_MODE			BIT(0)
+
+#define HDMI_REG_GCP			0xc1
+#define  AVMUTE				BIT(0)
+#define  HDMI_COLOR_DEPTH		GENMASK(6, 4)
+#define  HDMI_COLOR_DEPTH_24		FIELD_PREP(HDMI_COLOR_DEPTH, 4)
+
+#define HDMI_REG_PKT_GENERAL_CTRL	0xc6
+#define HDMI_REG_AVI_INFOFRM_CTRL	0xcd
+#define  ENABLE_PKT			BIT(0)
+#define  REPEAT_PKT			BIT(1)
+
+/* -----------------------------------------------------------------------------
+ * 3) HDMI register bank1: 0x130 ~ 0x1ff (HDMI packet registers)
+ */
+
+/* AVI packet registers */
+#define HDMI_REG_AVI_DB1		0x158
+#define HDMI_REG_AVI_DB2		0x159
+#define HDMI_REG_AVI_DB3		0x15a
+#define HDMI_REG_AVI_DB4		0x15b
+#define HDMI_REG_AVI_DB5		0x15c
+#define HDMI_REG_AVI_CSUM		0x15d
+#define HDMI_REG_AVI_DB6		0x15e
+#define HDMI_REG_AVI_DB7		0x15f
+#define HDMI_REG_AVI_DB8		0x160
+#define HDMI_REG_AVI_DB9		0x161
+#define HDMI_REG_AVI_DB10		0x162
+#define HDMI_REG_AVI_DB11		0x163
+#define HDMI_REG_AVI_DB12		0x164
+#define HDMI_REG_AVI_DB13		0x165
+
+#define HDMI_AVI_DB_CHUNK1_SIZE		(HDMI_REG_AVI_DB5 - HDMI_REG_AVI_DB1 + 1)
+#define HDMI_AVI_DB_CHUNK2_SIZE		(HDMI_REG_AVI_DB13 - HDMI_REG_AVI_DB6 + 1)
+
+/* IT6263 data sheet Rev0.8: LVDS RX supports input clock rate up to 150MHz. */
+#define MAX_PIXEL_CLOCK_KHZ		150000
+
+/* IT6263 programming guide Ver0.90: PCLK_HIGH for TMDS clock over 80MHz. */
+#define HIGH_PIXEL_CLOCK_KHZ		80000
+
+/*
+ * IT6263 data sheet Rev0.8: HDMI TX supports link speeds of up to 2.25Gbps
+ * (link clock rate of 225MHz).
+ */
+#define MAX_HDMI_TMDS_CHAR_RATE_HZ	225000000
+
+struct it6263 {
+	struct device *dev;
+	struct i2c_client *hdmi_i2c;
+	struct i2c_client *lvds_i2c;
+	struct regmap *hdmi_regmap;
+	struct regmap *lvds_regmap;
+	struct drm_bridge bridge;
+	struct drm_bridge *next_bridge;
+	int lvds_data_mapping;
+	bool lvds_dual_link;
+	bool lvds_link12_swap;
+};
+
+static inline struct it6263 *bridge_to_it6263(struct drm_bridge *bridge)
+{
+	return container_of(bridge, struct it6263, bridge);
+}
+
+static bool it6263_hdmi_writeable_reg(struct device *dev, unsigned int reg)
+{
+	switch (reg) {
+	case HDMI_REG_SW_RST:
+	case HDMI_REG_BANK_CTRL:
+	case HDMI_REG_DDC_MASTER_CTRL:
+	case HDMI_REG_DDC_HEADER:
+	case HDMI_REG_DDC_REQOFF:
+	case HDMI_REG_DDC_REQCOUNT:
+	case HDMI_REG_DDC_EDIDSEG:
+	case HDMI_REG_DDC_CMD:
+	case HDMI_REG_LVDS_PORT:
+	case HDMI_REG_LVDS_PORT_EN:
+	case HDMI_REG_AFE_DRV_CTRL:
+	case HDMI_REG_AFE_XP_CTRL:
+	case HDMI_REG_AFE_ISW_CTRL:
+	case HDMI_REG_AFE_IP_CTRL:
+	case HDMI_REG_INPUT_MODE:
+	case HDMI_REG_HDMI_MODE:
+	case HDMI_REG_GCP:
+	case HDMI_REG_PKT_GENERAL_CTRL:
+	case HDMI_REG_AVI_INFOFRM_CTRL:
+	case HDMI_REG_AVI_DB1:
+	case HDMI_REG_AVI_DB2:
+	case HDMI_REG_AVI_DB3:
+	case HDMI_REG_AVI_DB4:
+	case HDMI_REG_AVI_DB5:
+	case HDMI_REG_AVI_CSUM:
+	case HDMI_REG_AVI_DB6:
+	case HDMI_REG_AVI_DB7:
+	case HDMI_REG_AVI_DB8:
+	case HDMI_REG_AVI_DB9:
+	case HDMI_REG_AVI_DB10:
+	case HDMI_REG_AVI_DB11:
+	case HDMI_REG_AVI_DB12:
+	case HDMI_REG_AVI_DB13:
+		return true;
+	default:
+		return false;
+	}
+}
+
+static bool it6263_hdmi_readable_reg(struct device *dev, unsigned int reg)
+{
+	if (it6263_hdmi_writeable_reg(dev, reg))
+		return true;
+
+	switch (reg) {
+	case HDMI_REG_SYS_STATUS:
+	case HDMI_REG_DDC_STATUS:
+	case HDMI_REG_DDC_READFIFO:
+		return true;
+	default:
+		return false;
+	}
+}
+
+static bool it6263_hdmi_volatile_reg(struct device *dev, unsigned int reg)
+{
+	switch (reg) {
+	case HDMI_REG_SW_RST:
+	case HDMI_REG_SYS_STATUS:
+	case HDMI_REG_DDC_STATUS:
+	case HDMI_REG_DDC_READFIFO:
+		return true;
+	default:
+		return false;
+	}
+}
+
+static const struct regmap_range_cfg it6263_hdmi_range_cfg = {
+	.range_min = 0x00,
+	.range_max = HDMI_REG_AVI_DB13,
+	.selector_reg = HDMI_REG_BANK_CTRL,
+	.selector_mask = REG_BANK_SEL,
+	.selector_shift = 0,
+	.window_start = 0x00,
+	.window_len = 0x100,
+};
+
+static const struct regmap_config it6263_hdmi_regmap_config = {
+	.name = "it6263-hdmi",
+	.reg_bits = 8,
+	.val_bits = 8,
+	.writeable_reg = it6263_hdmi_writeable_reg,
+	.readable_reg = it6263_hdmi_readable_reg,
+	.volatile_reg = it6263_hdmi_volatile_reg,
+	.max_register = HDMI_REG_AVI_DB13,
+	.ranges = &it6263_hdmi_range_cfg,
+	.num_ranges = 1,
+	.cache_type = REGCACHE_MAPLE,
+};
+
+static bool it6263_lvds_writeable_reg(struct device *dev, unsigned int reg)
+{
+	switch (reg) {
+	case LVDS_REG_05:
+	case LVDS_REG_0B:
+	case LVDS_REG_2C:
+	case LVDS_REG_3C:
+	case LVDS_REG_3F:
+	case LVDS_REG_47:
+	case LVDS_REG_48:
+	case LVDS_REG_4F:
+	case LVDS_REG_52:
+		return true;
+	default:
+		return false;
+	}
+}
+
+static bool it6263_lvds_readable_reg(struct device *dev, unsigned int reg)
+{
+	return it6263_lvds_writeable_reg(dev, reg);
+}
+
+static bool it6263_lvds_volatile_reg(struct device *dev, unsigned int reg)
+{
+	return reg == LVDS_REG_05;
+}
+
+static const struct regmap_config it6263_lvds_regmap_config = {
+	.name = "it6263-lvds",
+	.reg_bits = 8,
+	.val_bits = 8,
+	.writeable_reg = it6263_lvds_writeable_reg,
+	.readable_reg = it6263_lvds_readable_reg,
+	.volatile_reg = it6263_lvds_volatile_reg,
+	.max_register = LVDS_REG_52,
+	.cache_type = REGCACHE_MAPLE,
+};
+
+static const char * const it6263_supplies[] = {
+	"ivdd", "ovdd", "txavcc18", "txavcc33", "pvcc1", "pvcc2",
+	"avcc", "anvdd", "apvdd"
+};
+
+static int it6263_parse_dt(struct it6263 *it)
+{
+	struct device *dev = it->dev;
+	struct device_node *port0, *port1;
+	int ret = 0;
+
+	it->lvds_data_mapping = drm_of_lvds_get_data_mapping(dev->of_node);
+	if (it->lvds_data_mapping < 0) {
+		dev_err(dev, "%pOF: invalid or missing %s DT property: %d\n",
+			dev->of_node, "data-mapping", it->lvds_data_mapping);
+		return it->lvds_data_mapping;
+	}
+
+	it->next_bridge = devm_drm_of_get_bridge(dev, dev->of_node, 2, 0);
+	if (IS_ERR(it->next_bridge))
+		return dev_err_probe(dev, PTR_ERR(it->next_bridge),
+				     "failed to get next bridge\n");
+
+	port0 = of_graph_get_port_by_id(dev->of_node, 0);
+	port1 = of_graph_get_port_by_id(dev->of_node, 1);
+	if (port0 && port1) {
+		int order;
+
+		it->lvds_dual_link = true;
+		order = drm_of_lvds_get_dual_link_pixel_order_sink(port0, port1);
+		if (order < 0) {
+			dev_err(dev,
+				"failed to get dual link pixel order: %d\n",
+				order);
+			ret = order;
+		} else if (order == DRM_LVDS_DUAL_LINK_EVEN_ODD_PIXELS) {
+			it->lvds_link12_swap = true;
+		}
+	} else if (port1) {
+		ret = -EINVAL;
+		dev_err(dev, "single input LVDS port1 is not supported\n");
+	} else if (!port0) {
+		ret = -EINVAL;
+		dev_err(dev, "no input LVDS port\n");
+	}
+
+	of_node_put(port0);
+	of_node_put(port1);
+
+	return ret;
+}
+
+static inline void it6263_hw_reset(struct gpio_desc *reset_gpio)
+{
+	if (!reset_gpio)
+		return;
+
+	gpiod_set_value_cansleep(reset_gpio, 0);
+	fsleep(1000);
+	gpiod_set_value_cansleep(reset_gpio, 1);
+	/* The chip maker says the low pulse should be at least 40ms. */
+	fsleep(40000);
+	gpiod_set_value_cansleep(reset_gpio, 0);
+	/* addtional time to wait the high voltage to be stable */
+	fsleep(5000);
+}
+
+static inline int it6263_lvds_set_i2c_addr(struct it6263 *it)
+{
+	int ret;
+
+	ret = regmap_write(it->hdmi_regmap, HDMI_REG_LVDS_PORT,
+			   LVDS_INPUT_CTRL_I2C_ADDR << 1);
+	if (ret)
+		return ret;
+
+	return regmap_write(it->hdmi_regmap, HDMI_REG_LVDS_PORT_EN, BIT(0));
+}
+
+static inline void it6263_lvds_reset(struct it6263 *it)
+{
+	/* AFE PLL reset */
+	regmap_write_bits(it->lvds_regmap, LVDS_REG_3C, BIT(0), 0x0);
+	fsleep(1000);
+	regmap_write_bits(it->lvds_regmap, LVDS_REG_3C, BIT(0), BIT(0));
+
+	/* software pixel clock domain reset */
+	regmap_write_bits(it->lvds_regmap, LVDS_REG_05, REG_SOFT_P_RST,
+			  REG_SOFT_P_RST);
+	fsleep(1000);
+	regmap_write_bits(it->lvds_regmap, LVDS_REG_05, REG_SOFT_P_RST, 0x0);
+	fsleep(10000);
+}
+
+static inline void it6263_lvds_set_interface(struct it6263 *it)
+{
+	/* color depth */
+	regmap_write_bits(it->lvds_regmap, LVDS_REG_2C, REG_COL_DEP, BIT8);
+	/* output mapping */
+	regmap_write_bits(it->lvds_regmap, LVDS_REG_2C, OUT_MAP, JEIDA);
+
+	if (it->lvds_dual_link) {
+		regmap_write_bits(it->lvds_regmap, LVDS_REG_2C, DMODE, DISO);
+		regmap_write_bits(it->lvds_regmap, LVDS_REG_52, BIT(1), BIT(1));
+	} else {
+		regmap_write_bits(it->lvds_regmap, LVDS_REG_2C, DMODE, SISO);
+		regmap_write_bits(it->lvds_regmap, LVDS_REG_52, BIT(1), 0);
+	}
+}
+
+static inline void it6263_lvds_set_afe(struct it6263 *it)
+{
+	regmap_write(it->lvds_regmap, LVDS_REG_3C, 0xaa);
+	regmap_write(it->lvds_regmap, LVDS_REG_3F, 0x02);
+	regmap_write(it->lvds_regmap, LVDS_REG_47, 0xaa);
+	regmap_write(it->lvds_regmap, LVDS_REG_48, 0x02);
+	regmap_write(it->lvds_regmap, LVDS_REG_4F, 0x11);
+
+	regmap_write_bits(it->lvds_regmap, LVDS_REG_0B, REG_SSC_PCLK_RF,
+			  REG_SSC_PCLK_RF);
+	regmap_write_bits(it->lvds_regmap, LVDS_REG_3C, 0x07, 0);
+	regmap_write_bits(it->lvds_regmap, LVDS_REG_2C, REG_DESSC_ENB,
+			  REG_DESSC_ENB);
+}
+
+static inline void it6263_lvds_sys_cfg(struct it6263 *it)
+{
+	regmap_write_bits(it->lvds_regmap, LVDS_REG_0B, REG_LVDS_IN_SWAP,
+			  it->lvds_link12_swap ? REG_LVDS_IN_SWAP : 0);
+}
+
+static inline void it6263_lvds_config(struct it6263 *it)
+{
+	it6263_lvds_reset(it);
+	it6263_lvds_set_interface(it);
+	it6263_lvds_set_afe(it);
+	it6263_lvds_sys_cfg(it);
+}
+
+static inline void it6263_hdmi_config(struct it6263 *it)
+{
+	regmap_write(it->hdmi_regmap, HDMI_REG_SW_RST, HDMI_RST_ALL);
+	regmap_write(it->hdmi_regmap, HDMI_REG_INPUT_MODE, IN_RGB);
+	regmap_write_bits(it->hdmi_regmap, HDMI_REG_GCP, HDMI_COLOR_DEPTH,
+			  HDMI_COLOR_DEPTH_24);
+}
+
+static enum drm_connector_status it6263_detect(struct it6263 *it)
+{
+	unsigned int val;
+
+	regmap_read(it->hdmi_regmap, HDMI_REG_SYS_STATUS, &val);
+	if (val & HPDETECT)
+		return connector_status_connected;
+	else
+		return connector_status_disconnected;
+}
+
+static int it6263_read_edid(void *data, u8 *buf, unsigned int block, size_t len)
+{
+	struct it6263 *it = data;
+	struct regmap *regmap = it->hdmi_regmap;
+	unsigned int start = (block % 2) * EDID_LENGTH;
+	unsigned int segment = block >> 1;
+	unsigned int count, val;
+	int ret;
+
+	regmap_write(regmap, HDMI_REG_DDC_MASTER_CTRL, MASTER_SEL_HOST);
+	regmap_write(regmap, HDMI_REG_DDC_HEADER, DDC_ADDR << 1);
+	regmap_write(regmap, HDMI_REG_DDC_EDIDSEG, segment);
+
+	while (len) {
+		/* clear DDC FIFO */
+		regmap_write(regmap, HDMI_REG_DDC_CMD, DDC_CMD_FIFO_CLR);
+
+		ret = regmap_read_poll_timeout(regmap, HDMI_REG_DDC_STATUS,
+					       val, val & DDC_DONE,
+					       2000, 10000);
+		if (ret) {
+			dev_err(it->dev, "failed to clear DDC FIFO:%d\n", ret);
+			return ret;
+		}
+
+		count = len > HDMI_DDC_FIFO_BYTES ? HDMI_DDC_FIFO_BYTES : len;
+
+		/* fire the read command */
+		regmap_write(regmap, HDMI_REG_DDC_REQOFF, start);
+		regmap_write(regmap, HDMI_REG_DDC_REQCOUNT, count);
+		regmap_write(regmap, HDMI_REG_DDC_CMD, DDC_CMD_EDID_READ);
+
+		start += count;
+		len -= count;
+
+		ret = regmap_read_poll_timeout(regmap, HDMI_REG_DDC_STATUS, val,
+					       val & (DDC_DONE | DDC_ERROR),
+					       20000, 250000);
+		if (ret && !(val & DDC_ERROR)) {
+			dev_err(it->dev, "failed to read EDID:%d\n", ret);
+			return ret;
+		}
+
+		if (val & DDC_ERROR) {
+			dev_err(it->dev, "DDC error\n");
+			return -EIO;
+		}
+
+		/* cache to buffer */
+		for (; count > 0; count--) {
+			regmap_read(regmap, HDMI_REG_DDC_READFIFO, &val);
+			*(buf++) = val;
+		}
+	}
+
+	return 0;
+}
+
+static int it6263_bridge_atomic_check(struct drm_bridge *bridge,
+				      struct drm_bridge_state *bridge_state,
+				      struct drm_crtc_state *crtc_state,
+				      struct drm_connector_state *conn_state)
+{
+	return drm_atomic_helper_connector_hdmi_check(conn_state->connector,
+						      conn_state->state);
+}
+
+static void
+it6263_bridge_atomic_disable(struct drm_bridge *bridge,
+			     struct drm_bridge_state *old_bridge_state)
+{
+	struct it6263 *it = bridge_to_it6263(bridge);
+
+	regmap_write_bits(it->hdmi_regmap, HDMI_REG_GCP, AVMUTE, AVMUTE);
+	regmap_write(it->hdmi_regmap, HDMI_REG_PKT_GENERAL_CTRL, 0);
+	regmap_write(it->hdmi_regmap, HDMI_REG_AFE_DRV_CTRL,
+		     AFE_DRV_RST | AFE_DRV_PWD);
+}
+
+static void
+it6263_bridge_atomic_enable(struct drm_bridge *bridge,
+			    struct drm_bridge_state *old_bridge_state)
+{
+	struct drm_atomic_state *state = old_bridge_state->base.state;
+	struct it6263 *it = bridge_to_it6263(bridge);
+	const struct drm_crtc_state *crtc_state;
+	struct regmap *regmap = it->hdmi_regmap;
+	const struct drm_display_mode *mode;
+	struct drm_connector *connector;
+	bool is_stable = false;
+	struct drm_crtc *crtc;
+	unsigned int val;
+	bool pclk_high;
+	int i, ret;
+
+	connector = drm_atomic_get_new_connector_for_encoder(state,
+							     bridge->encoder);
+	crtc = drm_atomic_get_new_connector_state(state, connector)->crtc;
+	crtc_state = drm_atomic_get_new_crtc_state(state, crtc);
+	mode = &crtc_state->adjusted_mode;
+
+	regmap_write(regmap, HDMI_REG_HDMI_MODE, TX_HDMI_MODE);
+
+	drm_atomic_helper_connector_hdmi_update_infoframes(connector, state);
+
+	/* HDMI AFE setup */
+	pclk_high = mode->clock > HIGH_PIXEL_CLOCK_KHZ;
+	regmap_write(regmap, HDMI_REG_AFE_DRV_CTRL, AFE_DRV_RST);
+	if (pclk_high)
+		regmap_write(regmap, HDMI_REG_AFE_XP_CTRL,
+			     AFE_XP_GAINBIT | AFE_XP_RESETB);
+	else
+		regmap_write(regmap, HDMI_REG_AFE_XP_CTRL,
+			     AFE_XP_ER0 | AFE_XP_RESETB);
+	regmap_write(regmap, HDMI_REG_AFE_ISW_CTRL, 0x10);
+	if (pclk_high)
+		regmap_write(regmap, HDMI_REG_AFE_IP_CTRL,
+			     AFE_IP_GAINBIT | AFE_IP_RESETB);
+	else
+		regmap_write(regmap, HDMI_REG_AFE_IP_CTRL,
+			     AFE_IP_ER0 | AFE_IP_RESETB);
+
+	/* HDMI software video reset */
+	regmap_write_bits(regmap, HDMI_REG_SW_RST, SOFTV_RST, SOFTV_RST);
+	fsleep(1000);
+	regmap_write_bits(regmap, HDMI_REG_SW_RST, SOFTV_RST, 0);
+
+	/* reconfigure LVDS and retry several times in case video is instable */
+	for (i = 0; i < 3; i++) {
+		ret = regmap_read_poll_timeout(regmap, HDMI_REG_SYS_STATUS, val,
+					       val & TXVIDSTABLE,
+					       20000, 500000);
+		if (!ret) {
+			is_stable = true;
+			break;
+		}
+
+		it6263_lvds_config(it);
+	}
+
+	if (!is_stable)
+		dev_warn(it->dev, "failed to wait for video stable\n");
+
+	/* HDMI AFE reset release and power up */
+	regmap_write(regmap, HDMI_REG_AFE_DRV_CTRL, 0);
+
+	regmap_write_bits(regmap, HDMI_REG_GCP, AVMUTE, 0);
+
+	regmap_write(regmap, HDMI_REG_PKT_GENERAL_CTRL, ENABLE_PKT | REPEAT_PKT);
+}
+
+static enum drm_mode_status
+it6263_bridge_mode_valid(struct drm_bridge *bridge,
+			 const struct drm_display_info *info,
+			 const struct drm_display_mode *mode)
+{
+	unsigned long long rate;
+
+	rate = drm_hdmi_compute_mode_clock(mode, 8, HDMI_COLORSPACE_RGB);
+	if (rate == 0)
+		return MODE_NOCLOCK;
+
+	return bridge->funcs->hdmi_tmds_char_rate_valid(bridge, mode, rate);
+}
+
+static int it6263_bridge_attach(struct drm_bridge *bridge,
+				enum drm_bridge_attach_flags flags)
+{
+	struct it6263 *it = bridge_to_it6263(bridge);
+	struct drm_connector *connector;
+	int ret;
+
+	ret = drm_bridge_attach(bridge->encoder, it->next_bridge, bridge,
+				flags | DRM_BRIDGE_ATTACH_NO_CONNECTOR);
+	if (ret < 0)
+		return ret;
+
+	if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)
+		return 0;
+
+	connector = drm_bridge_connector_init(bridge->dev, bridge->encoder);
+	if (IS_ERR(connector)) {
+		ret = PTR_ERR(connector);
+		dev_err(it->dev, "failed to initialize bridge connector: %d\n",
+			ret);
+		return ret;
+	}
+
+	drm_connector_attach_encoder(connector, bridge->encoder);
+
+	return 0;
+}
+
+static enum drm_connector_status it6263_bridge_detect(struct drm_bridge *bridge)
+{
+	struct it6263 *it = bridge_to_it6263(bridge);
+
+	return it6263_detect(it);
+}
+
+static const struct drm_edid *
+it6263_bridge_edid_read(struct drm_bridge *bridge,
+			struct drm_connector *connector)
+{
+	struct it6263 *it = bridge_to_it6263(bridge);
+
+	return drm_edid_read_custom(connector, it6263_read_edid, it);
+}
+
+static u32 *
+it6263_bridge_atomic_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 it6263 *it = bridge_to_it6263(bridge);
+	u32 *input_fmts;
+
+	*num_input_fmts = 0;
+
+	if (it->lvds_data_mapping != MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA)
+		return NULL;
+
+	input_fmts = kmalloc(sizeof(*input_fmts), GFP_KERNEL);
+	if (!input_fmts)
+		return NULL;
+
+	input_fmts[0] = MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA;
+	*num_input_fmts = 1;
+
+	return input_fmts;
+}
+
+static enum drm_mode_status
+it6263_hdmi_tmds_char_rate_valid(const struct drm_bridge *bridge,
+				 const struct drm_display_mode *mode,
+				 unsigned long long tmds_rate)
+{
+	if (mode->clock > MAX_PIXEL_CLOCK_KHZ)
+		return MODE_CLOCK_HIGH;
+
+	if (tmds_rate > MAX_HDMI_TMDS_CHAR_RATE_HZ)
+		return MODE_CLOCK_HIGH;
+
+	return MODE_OK;
+}
+
+static int it6263_hdmi_clear_infoframe(struct drm_bridge *bridge,
+				       enum hdmi_infoframe_type type)
+{
+	struct it6263 *it = bridge_to_it6263(bridge);
+
+	if (type == HDMI_INFOFRAME_TYPE_AVI)
+		regmap_write(it->hdmi_regmap, HDMI_REG_AVI_INFOFRM_CTRL, 0);
+	else
+		dev_dbg(it->dev, "unsupported HDMI infoframe 0x%x\n", type);
+
+	return 0;
+}
+
+static int it6263_hdmi_write_infoframe(struct drm_bridge *bridge,
+				       enum hdmi_infoframe_type type,
+				       const u8 *buffer, size_t len)
+{
+	struct it6263 *it = bridge_to_it6263(bridge);
+	struct regmap *regmap = it->hdmi_regmap;
+
+	if (type != HDMI_INFOFRAME_TYPE_AVI) {
+		dev_dbg(it->dev, "unsupported HDMI infoframe 0x%x\n", type);
+		return 0;
+	}
+
+	/* write the first AVI infoframe data byte chunk(DB1-DB5) */
+	regmap_bulk_write(regmap, HDMI_REG_AVI_DB1,
+			  &buffer[HDMI_INFOFRAME_HEADER_SIZE],
+			  HDMI_AVI_DB_CHUNK1_SIZE);
+
+	/* write the second AVI infoframe data byte chunk(DB6-DB13) */
+	regmap_bulk_write(regmap, HDMI_REG_AVI_DB6,
+			  &buffer[HDMI_INFOFRAME_HEADER_SIZE +
+				  HDMI_AVI_DB_CHUNK1_SIZE],
+			  HDMI_AVI_DB_CHUNK2_SIZE);
+
+	/* write checksum */
+	regmap_write(regmap, HDMI_REG_AVI_CSUM, buffer[3]);
+
+	regmap_write(regmap, HDMI_REG_AVI_INFOFRM_CTRL, ENABLE_PKT | REPEAT_PKT);
+
+	return 0;
+}
+
+static const struct drm_bridge_funcs it6263_bridge_funcs = {
+	.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,
+	.attach = it6263_bridge_attach,
+	.mode_valid = it6263_bridge_mode_valid,
+	.atomic_disable = it6263_bridge_atomic_disable,
+	.atomic_enable = it6263_bridge_atomic_enable,
+	.atomic_check = it6263_bridge_atomic_check,
+	.detect = it6263_bridge_detect,
+	.edid_read = it6263_bridge_edid_read,
+	.atomic_get_input_bus_fmts = it6263_bridge_atomic_get_input_bus_fmts,
+	.hdmi_tmds_char_rate_valid = it6263_hdmi_tmds_char_rate_valid,
+	.hdmi_clear_infoframe = it6263_hdmi_clear_infoframe,
+	.hdmi_write_infoframe = it6263_hdmi_write_infoframe,
+};
+
+static int it6263_probe(struct i2c_client *client)
+{
+	struct device *dev = &client->dev;
+	struct gpio_desc *reset_gpio;
+	struct it6263 *it;
+	int ret;
+
+	it = devm_kzalloc(dev, sizeof(*it), GFP_KERNEL);
+	if (!it)
+		return -ENOMEM;
+
+	it->dev = dev;
+	it->hdmi_i2c = client;
+
+	it->hdmi_regmap = devm_regmap_init_i2c(client,
+					       &it6263_hdmi_regmap_config);
+	if (IS_ERR(it->hdmi_regmap))
+		return dev_err_probe(dev, PTR_ERR(it->hdmi_regmap),
+				     "failed to init I2C regmap for HDMI\n");
+
+	reset_gpio = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_LOW);
+	if (IS_ERR(reset_gpio))
+		return dev_err_probe(dev, PTR_ERR(reset_gpio),
+				     "failed to get reset gpio\n");
+
+	ret = devm_regulator_bulk_get_enable(dev, ARRAY_SIZE(it6263_supplies),
+					     it6263_supplies);
+	if (ret)
+		return dev_err_probe(dev, ret, "failed to get power supplies\n");
+
+	ret = it6263_parse_dt(it);
+	if (ret)
+		return ret;
+
+	it6263_hw_reset(reset_gpio);
+
+	ret = it6263_lvds_set_i2c_addr(it);
+	if (ret)
+		return dev_err_probe(dev, ret, "failed to set I2C addr\n");
+
+	it->lvds_i2c = devm_i2c_new_dummy_device(dev, client->adapter,
+						 LVDS_INPUT_CTRL_I2C_ADDR);
+	if (IS_ERR(it->lvds_i2c))
+		dev_err_probe(it->dev, PTR_ERR(it->lvds_i2c),
+			      "failed to allocate I2C device for LVDS\n");
+
+	it->lvds_regmap = devm_regmap_init_i2c(it->lvds_i2c,
+					       &it6263_lvds_regmap_config);
+	if (IS_ERR(it->lvds_regmap))
+		return dev_err_probe(dev, PTR_ERR(it->lvds_regmap),
+				     "failed to init I2C regmap for LVDS\n");
+
+	it6263_lvds_config(it);
+	it6263_hdmi_config(it);
+
+	i2c_set_clientdata(client, it);
+
+	it->bridge.funcs = &it6263_bridge_funcs;
+	it->bridge.of_node = dev->of_node;
+	/* IT6263 chip doesn't support HPD interrupt. */
+	it->bridge.ops = DRM_BRIDGE_OP_DETECT | DRM_BRIDGE_OP_EDID |
+			 DRM_BRIDGE_OP_HDMI;
+	it->bridge.type = DRM_MODE_CONNECTOR_HDMIA;
+	it->bridge.vendor = "ITE";
+	it->bridge.product = "IT6263";
+
+	return devm_drm_bridge_add(dev, &it->bridge);
+}
+
+static const struct of_device_id it6263_of_match[] = {
+	{ .compatible = "ite,it6263", },
+	{ }
+};
+MODULE_DEVICE_TABLE(of, it6263_of_match);
+
+static const struct i2c_device_id it6263_i2c_ids[] = {
+	{ "it6263", 0 },
+	{ }
+};
+MODULE_DEVICE_TABLE(i2c, it6263_i2c_ids);
+
+static struct i2c_driver it6263_driver = {
+	.probe = it6263_probe,
+	.driver = {
+		.name = "it6263",
+		.of_match_table = it6263_of_match,
+	},
+	.id_table = it6263_i2c_ids,
+};
+module_i2c_driver(it6263_driver);
+
+MODULE_DESCRIPTION("ITE Tech. Inc. IT6263 LVDS/HDMI bridge");
+MODULE_AUTHOR("Liu Ying <victor.liu@nxp.com>");
+MODULE_LICENSE("GPL");
-- 
2.34.1

[PATCH v4 11/13] arm64: dts: imx8mp-evk: Add NXP LVDS to HDMI adapter cards

[Liu Ying]

One ITE IT6263 LVDS to HDMI converter is populated on NXP IMX-LVDS-HDMI
and IMX-DLVDS-HDMI adapter cards.

Card IMX-LVDS-HDMI supports single LVDS link(IT6263 link1).
Card IMX-DLVDS-HDMI supports dual LVDS links(IT6263 link1 and link2).

Only one card can be enabled with one i.MX8MP EVK.

Add dedicated overlays to support the below four connections:
1) imx8mp-evk-lvds0-imx-lvds-hdmi.dtso:
   i.MX8MP EVK LVDS0 connector <=> LVDS adapter card J6(IT6263 link1)

2) imx8mp-evk-lvds1-imx-lvds-hdmi.dtso:
   i.MX8MP EVK LVDS1 connector <=> LVDS adapter card J6(IT6263 link1)

3) imx8mp-evk-lvds0-imx-dlvds-hdmi-channel0.dtso:
   i.MX8MP EVK LVDS0 connector <=> DLVDS adapter card channel0(IT6263 link1)
   i.MX8MP EVK LVDS1 connector <=> DLVDS adapter card channel1(IT6263 link2)

4) imx8mp-evk-lvds1-imx-dlvds-hdmi-channel0.dtso:
   i.MX8MP EVK LVDS1 connector <=> DLVDS adapter card channel0(IT6263 link1)
   i.MX8MP EVK LVDS0 connector <=> DLVDS adapter card channel1(IT6263 link2)

Part links:
https://www.nxp.com/part/IMX-LVDS-HDMI
https://www.nxp.com/part/IMX-DLVDS-HDMI

Signed-off-by: Liu Ying <victor.liu@nxp.com>
---
v4:
* Rebase this patch upon next-20241025 to resolve conflicts when apply.

v3:
* Use data-mapping DT property instead of ite,lvds-link-num-data-lanes.
  (Dmitry, Biju)

v2:
* Add ite,lvds-link-num-data-lanes properties.

 arch/arm64/boot/dts/freescale/Makefile        |  8 ++++
 .../imx8mp-evk-imx-lvds-hdmi-common.dtsi      | 29 ++++++++++++
 ...8mp-evk-lvds0-imx-dlvds-hdmi-channel0.dtso | 44 +++++++++++++++++++
 ...imx8mp-evk-lvds0-imx-lvds-hdmi-common.dtsi | 43 ++++++++++++++++++
 .../imx8mp-evk-lvds0-imx-lvds-hdmi.dtso       | 28 ++++++++++++
 ...8mp-evk-lvds1-imx-dlvds-hdmi-channel0.dtso | 44 +++++++++++++++++++
 ...imx8mp-evk-lvds1-imx-lvds-hdmi-common.dtsi | 43 ++++++++++++++++++
 .../imx8mp-evk-lvds1-imx-lvds-hdmi.dtso       | 28 ++++++++++++
 arch/arm64/boot/dts/freescale/imx8mp-evk.dts  |  6 +++
 9 files changed, 273 insertions(+)
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-evk-imx-lvds-hdmi-common.dtsi
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-evk-lvds0-imx-dlvds-hdmi-channel0.dtso
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-evk-lvds0-imx-lvds-hdmi-common.dtsi
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-evk-lvds0-imx-lvds-hdmi.dtso
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-evk-lvds1-imx-dlvds-hdmi-channel0.dtso
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-evk-lvds1-imx-lvds-hdmi-common.dtsi
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-evk-lvds1-imx-lvds-hdmi.dtso

diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
index 5c157529fb88..ec04d693c313 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -207,8 +207,16 @@ dtb-$(CONFIG_ARCH_MXC) += imx8mp-verdin-wifi-ivy.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mp-verdin-wifi-mallow.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mp-verdin-wifi-yavia.dtb
 
+imx8mp-evk-lvds0-imx-dlvds-hdmi-channel0-dtbs += imx8mp-evk.dtb imx8mp-evk-lvds0-imx-dlvds-hdmi-channel0.dtbo
+imx8mp-evk-lvds0-imx-lvds-hdmi-dtbs += imx8mp-evk.dtb imx8mp-evk-lvds0-imx-lvds-hdmi.dtbo
+imx8mp-evk-lvds1-imx-dlvds-hdmi-channel0-dtbs += imx8mp-evk.dtb imx8mp-evk-lvds1-imx-dlvds-hdmi-channel0.dtbo
+imx8mp-evk-lvds1-imx-lvds-hdmi-dtbs += imx8mp-evk.dtb imx8mp-evk-lvds1-imx-lvds-hdmi.dtbo
 imx8mp-evk-mx8-dlvds-lcd1-dtbs += imx8mp-evk.dtb imx8mp-evk-mx8-dlvds-lcd1.dtbo
 imx8mp-evk-pcie-ep-dtbs += imx8mp-evk.dtb imx8mp-evk-pcie-ep.dtbo
+dtb-$(CONFIG_ARCH_MXC) += imx8mp-evk-lvds0-imx-dlvds-hdmi-channel0.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx8mp-evk-lvds0-imx-lvds-hdmi.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx8mp-evk-lvds1-imx-dlvds-hdmi-channel0.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx8mp-evk-lvds1-imx-lvds-hdmi.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mp-evk-mx8-dlvds-lcd1.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mp-evk-pcie-ep.dtb
 
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-evk-imx-lvds-hdmi-common.dtsi b/arch/arm64/boot/dts/freescale/imx8mp-evk-imx-lvds-hdmi-common.dtsi
new file mode 100644
index 000000000000..44b30e9b3fde
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mp-evk-imx-lvds-hdmi-common.dtsi
@@ -0,0 +1,29 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright 2024 NXP
+ */
+
+/dts-v1/;
+/plugin/;
+
+&{/} {
+	lvds-hdmi-connector {
+		compatible = "hdmi-connector";
+		label = "J2";
+		type = "a";
+
+		port {
+			lvds2hdmi_connector_in: endpoint {
+				remote-endpoint = <&it6263_out>;
+			};
+		};
+	};
+};
+
+&lcdif2 {
+	status = "okay";
+};
+
+&lvds_bridge {
+	status = "okay";
+};
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-evk-lvds0-imx-dlvds-hdmi-channel0.dtso b/arch/arm64/boot/dts/freescale/imx8mp-evk-lvds0-imx-dlvds-hdmi-channel0.dtso
new file mode 100644
index 000000000000..4008d2fd36d6
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mp-evk-lvds0-imx-dlvds-hdmi-channel0.dtso
@@ -0,0 +1,44 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright 2024 NXP
+ */
+
+#include "imx8mp-evk-lvds0-imx-lvds-hdmi-common.dtsi"
+
+&it6263 {
+	ports {
+		port@0 {
+			reg = <0>;
+			dual-lvds-odd-pixels;
+
+			it6263_lvds_link1: endpoint {
+				remote-endpoint = <&ldb_lvds_ch0>;
+			};
+		};
+
+		port@1 {
+			reg = <1>;
+			dual-lvds-even-pixels;
+
+			it6263_lvds_link2: endpoint {
+				remote-endpoint = <&ldb_lvds_ch1>;
+			};
+		};
+	};
+};
+
+&lvds_bridge {
+	ports {
+		port@1 {
+			ldb_lvds_ch0: endpoint {
+				remote-endpoint = <&it6263_lvds_link1>;
+			};
+		};
+
+		port@2 {
+			ldb_lvds_ch1: endpoint {
+				remote-endpoint = <&it6263_lvds_link2>;
+			};
+		};
+	};
+};
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-evk-lvds0-imx-lvds-hdmi-common.dtsi b/arch/arm64/boot/dts/freescale/imx8mp-evk-lvds0-imx-lvds-hdmi-common.dtsi
new file mode 100644
index 000000000000..6eae7477abf8
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mp-evk-lvds0-imx-lvds-hdmi-common.dtsi
@@ -0,0 +1,43 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright 2024 NXP
+ */
+
+#include <dt-bindings/gpio/gpio.h>
+#include "imx8mp-evk-imx-lvds-hdmi-common.dtsi"
+
+&i2c2 {
+	#address-cells = <1>;
+	#size-cells = <0>;
+
+	it6263: hdmi@4c {
+		compatible = "ite,it6263";
+		reg = <0x4c>;
+		data-mapping = "jeida-24";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_lvds_en>;
+		reset-gpios = <&gpio1 10 GPIO_ACTIVE_LOW>;
+		ivdd-supply = <&reg_buck5>;
+		ovdd-supply = <&reg_vext_3v3>;
+		txavcc18-supply = <&reg_buck5>;
+		txavcc33-supply = <&reg_vext_3v3>;
+		pvcc1-supply = <&reg_buck5>;
+		pvcc2-supply = <&reg_buck5>;
+		avcc-supply = <&reg_vext_3v3>;
+		anvdd-supply = <&reg_buck5>;
+		apvdd-supply = <&reg_buck5>;
+
+		ports {
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			port@2 {
+				reg = <2>;
+
+				it6263_out: endpoint {
+					remote-endpoint = <&lvds2hdmi_connector_in>;
+				};
+			};
+		};
+	};
+};
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-evk-lvds0-imx-lvds-hdmi.dtso b/arch/arm64/boot/dts/freescale/imx8mp-evk-lvds0-imx-lvds-hdmi.dtso
new file mode 100644
index 000000000000..9e11f261ad13
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mp-evk-lvds0-imx-lvds-hdmi.dtso
@@ -0,0 +1,28 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright 2024 NXP
+ */
+
+#include "imx8mp-evk-lvds0-imx-lvds-hdmi-common.dtsi"
+
+&it6263 {
+	ports {
+		port@0 {
+			reg = <0>;
+
+			it6263_lvds_link1: endpoint {
+				remote-endpoint = <&ldb_lvds_ch0>;
+			};
+		};
+	};
+};
+
+&lvds_bridge {
+	ports {
+		port@1 {
+			ldb_lvds_ch0: endpoint {
+				remote-endpoint = <&it6263_lvds_link1>;
+			};
+		};
+	};
+};
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-evk-lvds1-imx-dlvds-hdmi-channel0.dtso b/arch/arm64/boot/dts/freescale/imx8mp-evk-lvds1-imx-dlvds-hdmi-channel0.dtso
new file mode 100644
index 000000000000..af2e73e36a1b
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mp-evk-lvds1-imx-dlvds-hdmi-channel0.dtso
@@ -0,0 +1,44 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright 2024 NXP
+ */
+
+#include "imx8mp-evk-lvds1-imx-lvds-hdmi-common.dtsi"
+
+&it6263 {
+	ports {
+		port@0 {
+			reg = <0>;
+			dual-lvds-even-pixels;
+
+			it6263_lvds_link1: endpoint {
+				remote-endpoint = <&ldb_lvds_ch1>;
+			};
+		};
+
+		port@1 {
+			reg = <1>;
+			dual-lvds-odd-pixels;
+
+			it6263_lvds_link2: endpoint {
+				remote-endpoint = <&ldb_lvds_ch0>;
+			};
+		};
+	};
+};
+
+&lvds_bridge {
+	ports {
+		port@1 {
+			ldb_lvds_ch0: endpoint {
+				remote-endpoint = <&it6263_lvds_link2>;
+			};
+		};
+
+		port@2 {
+			ldb_lvds_ch1: endpoint {
+				remote-endpoint = <&it6263_lvds_link1>;
+			};
+		};
+	};
+};
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-evk-lvds1-imx-lvds-hdmi-common.dtsi b/arch/arm64/boot/dts/freescale/imx8mp-evk-lvds1-imx-lvds-hdmi-common.dtsi
new file mode 100644
index 000000000000..8cc9d361c2a4
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mp-evk-lvds1-imx-lvds-hdmi-common.dtsi
@@ -0,0 +1,43 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright 2024 NXP
+ */
+
+#include <dt-bindings/gpio/gpio.h>
+#include "imx8mp-evk-imx-lvds-hdmi-common.dtsi"
+
+&i2c3 {
+	#address-cells = <1>;
+	#size-cells = <0>;
+
+	it6263: hdmi@4c {
+		compatible = "ite,it6263";
+		reg = <0x4c>;
+		data-mapping = "jeida-24";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_lvds_en>;
+		reset-gpios = <&gpio1 10 GPIO_ACTIVE_LOW>;
+		ivdd-supply = <&reg_buck5>;
+		ovdd-supply = <&reg_vext_3v3>;
+		txavcc18-supply = <&reg_buck5>;
+		txavcc33-supply = <&reg_vext_3v3>;
+		pvcc1-supply = <&reg_buck5>;
+		pvcc2-supply = <&reg_buck5>;
+		avcc-supply = <&reg_vext_3v3>;
+		anvdd-supply = <&reg_buck5>;
+		apvdd-supply = <&reg_buck5>;
+
+		ports {
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			port@2 {
+				reg = <2>;
+
+				it6263_out: endpoint {
+					remote-endpoint = <&lvds2hdmi_connector_in>;
+				};
+			};
+		};
+	};
+};
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-evk-lvds1-imx-lvds-hdmi.dtso b/arch/arm64/boot/dts/freescale/imx8mp-evk-lvds1-imx-lvds-hdmi.dtso
new file mode 100644
index 000000000000..527a893a71b2
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mp-evk-lvds1-imx-lvds-hdmi.dtso
@@ -0,0 +1,28 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright 2024 NXP
+ */
+
+#include "imx8mp-evk-lvds1-imx-lvds-hdmi-common.dtsi"
+
+&it6263 {
+	ports {
+		port@0 {
+			reg = <0>;
+
+			it6263_lvds_link1: endpoint {
+				remote-endpoint = <&ldb_lvds_ch1>;
+			};
+		};
+	};
+};
+
+&lvds_bridge {
+	ports {
+		port@2 {
+			ldb_lvds_ch1: endpoint {
+				remote-endpoint = <&it6263_lvds_link1>;
+			};
+		};
+	};
+};
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-evk.dts b/arch/arm64/boot/dts/freescale/imx8mp-evk.dts
index d26930f1a9e9..68e12a752edd 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp-evk.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mp-evk.dts
@@ -938,6 +938,12 @@ MX8MP_IOMUXC_SPDIF_TX__I2C5_SCL         0x400001c2
 		>;
 	};
 
+	pinctrl_lvds_en: lvdsengrp {
+		fsl,pins = <
+			MX8MP_IOMUXC_GPIO1_IO10__GPIO1_IO10	0x1c0
+		>;
+	};
+
 	pinctrl_pcie0: pcie0grp {
 		fsl,pins = <
 			MX8MP_IOMUXC_I2C4_SCL__PCIE_CLKREQ_B	0x60 /* open drain, pull up */
-- 
2.34.1

[PATCH v4 12/13] arm64: defconfig: Enable ITE IT6263 driver

[Liu Ying]

ITE IT6263 LVDS to HDMI converter is populated on NXP IMX-LVDS-HDMI
and IMX-DLVDS-HDMI adapter cards.  The adapter cards can connect to
i.MX8MP EVK base board to support video output through HDMI connectors.
Build the ITE IT6263 driver as a module.

Signed-off-by: Liu Ying <victor.liu@nxp.com>
---
v4:
* No change.

v3:
* No change.

v2:
* No change.

 arch/arm64/configs/defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 36b33b9f1704..d249df72e2bd 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -899,6 +899,7 @@ CONFIG_DRM_PANEL_SITRONIX_ST7703=m
 CONFIG_DRM_PANEL_TRULY_NT35597_WQXGA=m
 CONFIG_DRM_PANEL_VISIONOX_VTDR6130=m
 CONFIG_DRM_FSL_LDB=m
+CONFIG_DRM_ITE_IT6263=m
 CONFIG_DRM_LONTIUM_LT8912B=m
 CONFIG_DRM_LONTIUM_LT9611=m
 CONFIG_DRM_LONTIUM_LT9611UXC=m
-- 
2.34.1

[PATCH v4 13/13] MAINTAINERS: Add maintainer for ITE IT6263 driver

[Liu Ying]

Add myself as the maintainer of ITE IT6263 LVDS TO HDMI BRIDGE DRIVER.

Signed-off-by: Liu Ying <victor.liu@nxp.com>
---
v4:
* No change.

v3:
* No change.

v2:
* New patch.  (Maxime)

 MAINTAINERS | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index a858224b59d5..615ba0e905af 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -12234,6 +12234,14 @@ W:	https://linuxtv.org
 Q:	http://patchwork.linuxtv.org/project/linux-media/list/
 F:	drivers/media/tuners/it913x*
 
+ITE IT6263 LVDS TO HDMI BRIDGE DRIVER
+M:	Liu Ying <victor.liu@nxp.com>
+L:	dri-devel@lists.freedesktop.org
+S:	Maintained
+T:	git https://gitlab.freedesktop.org/drm/misc/kernel.git
+F:	Documentation/devicetree/bindings/display/bridge/ite,it6263.yaml
+F:	drivers/gpu/drm/bridge/ite-it6263.c
+
 ITE IT66121 HDMI BRIDGE DRIVER
 M:	Phong LE <ple@baylibre.com>
 M:	Neil Armstrong <neil.armstrong@linaro.org>
-- 
2.34.1

RE: [PATCH v4 09/13] dt-bindings: display: bridge: Add ITE IT6263 LVDS to HDMI converter

[Biju Das]

Hi Liu Ying,

Thanks for the patch.

> -----Original Message-----
> From: Liu Ying <victor.liu@nxp.com>
> Sent: 28 October 2024 02:38
> Subject: [PATCH v4 09/13] dt-bindings: display: bridge: Add ITE IT6263 LVDS to HDMI converter
> 
> Document ITE IT6263 LVDS to HDMI converter.
> 
> Product link:
> https://www.ite.com.tw/en/product/cate1/IT6263
> 
> Signed-off-by: Liu Ying <victor.liu@nxp.com>

Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com>

Cheers,
Biju


> ---
> v4:
> * Require dual-lvds-odd-pixels or dual-lvds-even-pixels DT properties for
>   port@1.
> * Drop "data-mirror: true"(30-bit LVDS data bit order is not reversed).
> 
> v3:
> * Reference lvds-dual-ports.yaml.  (Dmitry)
> * Add data-mapping DT property.  (Dmitry, Biju)
> * Allow data-mirror.
> * Drop ite,lvds-link-num-data-lanes DT property.  (Dmitry, Biju)
> 
> v2:
> * Document number of LVDS link data lanes.  (Biju)
> * Simplify ports property by dropping "oneOf".  (Rob)
> 
>  .../bindings/display/bridge/ite,it6263.yaml   | 250 ++++++++++++++++++
>  1 file changed, 250 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/display/bridge/ite,it6263.yaml
> 
> diff --git a/Documentation/devicetree/bindings/display/bridge/ite,it6263.yaml
> b/Documentation/devicetree/bindings/display/bridge/ite,it6263.yaml
> new file mode 100644
> index 000000000000..0a10e10d80ff
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/ite,it6263.yaml
> @@ -0,0 +1,250 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/bridge/ite,it6263.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: ITE IT6263 LVDS to HDMI converter
> +
> +maintainers:
> +  - Liu Ying <victor.liu@nxp.com>
> +
> +description: |
> +  The IT6263 is a high-performance single-chip De-SSC(De-Spread
> +Spectrum) LVDS
> +  to HDMI converter.  Combined with LVDS receiver and HDMI 1.4a
> +transmitter,
> +  the IT6263 supports LVDS input and HDMI 1.4 output by conversion function.
> +  The built-in LVDS receiver can support single-link and dual-link LVDS
> +inputs,
> +  and the built-in HDMI transmitter is fully compliant with HDMI
> +1.4a/3D, HDCP
> +  1.2 and backward compatible with DVI 1.0 specification.
> +
> +  The IT6263 also encodes and transmits up to 8 channels of I2S digital
> + audio,  with sampling rate up to 192KHz and sample size up to 24 bits.
> + In addition,  an S/PDIF input port takes in compressed audio of up to 192KHz frame rate.
> +
> +  The newly supported High-Bit Rate(HBR) audio by HDMI specifications
> + v1.3 is  provided by the IT6263 in two interfaces: the four I2S input
> + ports or the  S/PDIF input port.  With both interfaces the highest
> + possible HBR frame rate  is supported at up to 768KHz.
> +
> +allOf:
> +  - $ref: /schemas/display/lvds-dual-ports.yaml#
> +
> +properties:
> +  compatible:
> +    const: ite,it6263
> +
> +  reg:
> +    maxItems: 1
> +
> +  clocks:
> +    maxItems: 1
> +    description: audio master clock
> +
> +  clock-names:
> +    const: mclk
> +
> +  data-mapping:
> +    enum:
> +      - jeida-18
> +      - jeida-24
> +      - jeida-30
> +      - vesa-24
> +      - vesa-30
> +
> +  reset-gpios:
> +    maxItems: 1
> +
> +  ivdd-supply:
> +    description: 1.8V digital logic power
> +
> +  ovdd-supply:
> +    description: 3.3V I/O pin power
> +
> +  txavcc18-supply:
> +    description: 1.8V HDMI analog frontend power
> +
> +  txavcc33-supply:
> +    description: 3.3V HDMI analog frontend power
> +
> +  pvcc1-supply:
> +    description: 1.8V HDMI frontend core PLL power
> +
> +  pvcc2-supply:
> +    description: 1.8V HDMI frontend filter PLL power
> +
> +  avcc-supply:
> +    description: 3.3V LVDS frontend power
> +
> +  anvdd-supply:
> +    description: 1.8V LVDS frontend analog power
> +
> +  apvdd-supply:
> +    description: 1.8V LVDS frontend PLL power
> +
> +  "#sound-dai-cells":
> +    const: 0
> +
> +  ite,i2s-audio-fifo-sources:
> +    $ref: /schemas/types.yaml#/definitions/uint32-array
> +    minItems: 1
> +    maxItems: 4
> +    items:
> +      enum: [0, 1, 2, 3]
> +    description:
> +      Each array element indicates the pin number of an I2S serial data input
> +      line which is connected to an audio FIFO, from audio FIFO0 to FIFO3.
> +
> +  ite,rl-channel-swap-audio-sources:
> +    $ref: /schemas/types.yaml#/definitions/uint32-array
> +    minItems: 1
> +    maxItems: 4
> +    uniqueItems: true
> +    items:
> +      enum: [0, 1, 2, 3]
> +    description:
> +      Each array element indicates an audio source whose right channel and left
> +      channel are swapped by this converter. For I2S, the element is the pin
> +      number of an I2S serial data input line. For S/PDIF, the element is always
> +      0.
> +
> +  ports:
> +    $ref: /schemas/graph.yaml#/properties/ports
> +
> +    properties:
> +      port@0: true
> +
> +      port@1:
> +        oneOf:
> +          - required: [dual-lvds-odd-pixels]
> +          - required: [dual-lvds-even-pixels]
> +
> +      port@2:
> +        $ref: /schemas/graph.yaml#/properties/port
> +        description: video port for the HDMI output
> +
> +      port@3:
> +        $ref: /schemas/graph.yaml#/properties/port
> +        description: sound input port
> +
> +    required:
> +      - port@0
> +      - port@2
> +
> +required:
> +  - compatible
> +  - reg
> +  - data-mapping
> +  - ivdd-supply
> +  - ovdd-supply
> +  - txavcc18-supply
> +  - txavcc33-supply
> +  - pvcc1-supply
> +  - pvcc2-supply
> +  - avcc-supply
> +  - anvdd-supply
> +  - apvdd-supply
> +
> +unevaluatedProperties: false
> +
> +examples:
> +  - |
> +    /* single-link LVDS input */
> +    #include <dt-bindings/gpio/gpio.h>
> +
> +    i2c {
> +        #address-cells = <1>;
> +        #size-cells = <0>;
> +
> +        hdmi@4c {
> +            compatible = "ite,it6263";
> +            reg = <0x4c>;
> +            data-mapping = "jeida-24";
> +            reset-gpios = <&gpio1 10 GPIO_ACTIVE_LOW>;
> +            ivdd-supply = <&reg_buck5>;
> +            ovdd-supply = <&reg_vext_3v3>;
> +            txavcc18-supply = <&reg_buck5>;
> +            txavcc33-supply = <&reg_vext_3v3>;
> +            pvcc1-supply = <&reg_buck5>;
> +            pvcc2-supply = <&reg_buck5>;
> +            avcc-supply = <&reg_vext_3v3>;
> +            anvdd-supply = <&reg_buck5>;
> +            apvdd-supply = <&reg_buck5>;
> +
> +            ports {
> +                #address-cells = <1>;
> +                #size-cells = <0>;
> +
> +                port@0 {
> +                    reg = <0>;
> +
> +                    it6263_lvds_link1: endpoint {
> +                        remote-endpoint = <&ldb_lvds_ch0>;
> +                    };
> +                };
> +
> +                port@2 {
> +                    reg = <2>;
> +
> +                    it6263_out: endpoint {
> +                        remote-endpoint = <&hdmi_in>;
> +                    };
> +                };
> +            };
> +        };
> +    };
> +
> +  - |
> +    /* dual-link LVDS input */
> +    #include <dt-bindings/gpio/gpio.h>
> +
> +    i2c {
> +        #address-cells = <1>;
> +        #size-cells = <0>;
> +
> +        hdmi@4c {
> +            compatible = "ite,it6263";
> +            reg = <0x4c>;
> +            data-mapping = "jeida-24";
> +            reset-gpios = <&gpio1 10 GPIO_ACTIVE_LOW>;
> +            ivdd-supply = <&reg_buck5>;
> +            ovdd-supply = <&reg_vext_3v3>;
> +            txavcc18-supply = <&reg_buck5>;
> +            txavcc33-supply = <&reg_vext_3v3>;
> +            pvcc1-supply = <&reg_buck5>;
> +            pvcc2-supply = <&reg_buck5>;
> +            avcc-supply = <&reg_vext_3v3>;
> +            anvdd-supply = <&reg_buck5>;
> +            apvdd-supply = <&reg_buck5>;
> +
> +            ports {
> +                #address-cells = <1>;
> +                #size-cells = <0>;
> +
> +                port@0 {
> +                    reg = <0>;
> +                    dual-lvds-odd-pixels;
> +
> +                    it6263_lvds_link1_dual: endpoint {
> +                        remote-endpoint = <&ldb_lvds_ch0>;
> +                    };
> +                };
> +
> +                port@1 {
> +                    reg = <1>;
> +                    dual-lvds-even-pixels;
> +
> +                    it6263_lvds_link2_dual: endpoint {
> +                        remote-endpoint = <&ldb_lvds_ch1>;
> +                    };
> +                };
> +
> +                port@2 {
> +                    reg = <2>;
> +
> +                    it6263_out_dual: endpoint {
> +                        remote-endpoint = <&hdmi_in>;
> +                    };
> +                };
> +            };
> +        };
> +    };
> --
> 2.34.1

RE: [PATCH v4 10/13] drm/bridge: Add ITE IT6263 LVDS to HDMI converter

[Biju Das]

Hi Liu Ying,

Thanks for the patch.

> -----Original Message-----
> From: Liu Ying <victor.liu@nxp.com>
> Sent: 28 October 2024 02:38
> Subject: [PATCH v4 10/13] drm/bridge: Add ITE IT6263 LVDS to HDMI converter
> 
> Add basic HDMI video output support. Currently, only RGB888 output pixel format is supported.  At the
> LVDS input side, the driver supports single LVDS link and dual LVDS links with "jeida-24" LVDS
> mapping.
> 
> Product link:
> https://www.ite.com.tw/en/product/cate1/IT6263
> 
> Signed-off-by: Liu Ying <victor.liu@nxp.com>
> Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com>
> Acked-by: Maxime Ripard <mripard@kernel.org>

Tested on Renesas RZ/G3E SMARC EVK:

Dual LVDS link: 1080p@60
Single LVDS link:720p@60

Tested-by: Biju Das <biju.das.jz@bp.renesas.com>

Cheers,
Biju

> ---
> v4:
> * Use local variable reset_gpio in probe().  (Biju)
> * Move pixel clock rate validation from mode_valid callback to
>   hdmi_tmds_char_rate_valid callback.  (Maxime)
> * Document IT6263 video processing throughput constraints by adding comments.
>   (Maxime)
> * Fix LVDS 8-bit color depth macro BIT8.
> * Drop 30-bit LVDS data bit order validation(30-bit LVDS data bit order is not
>   reversed).
> * Collect Biju's R-b tag and Maxime's A-b tag.
> 
> v3:
> * Use HDMI connector framework.  (Maxime)
> * Control the missing HDMI_REG_AVI_INFOFRM_CTRL register.
> * Validate the maximal HDMI TMDS character rate.  (Dmitry)
> * Get LVDS data mapping from data-mapping DT property.  (Dmitry, Biju)
> * Validate 30bit LVDS data bit order by checking data-mirror DT property.
> * Use drm_of_lvds_get_dual_link_pixel_order_sink().  (Dmitry)
> * Initialize a bridge connector instead of open coding.  (Dmitry)
> * Add a comment that IT6263 chip has no HPD IRQ support.  (Dmitry)
> * Use devm_drm_bridge_add() instead of drm_bridge_add().  (Dmitry)
> * Fix a minor build warning reported by kernel test robot.
> 
> v2:
> * Add AVI inforframe support.  (Maxime)
> * Add DRM_MODE_CONNECTOR_HDMIA.  (Biju)
> * Rename it6263_reset() to it6263_hw_reset().  (Biju)
> * Check number of LVDS link data lanes.  (Biju)
> 
>  drivers/gpu/drm/bridge/Kconfig      |  11 +
>  drivers/gpu/drm/bridge/Makefile     |   1 +
>  drivers/gpu/drm/bridge/ite-it6263.c | 898 ++++++++++++++++++++++++++++
>  3 files changed, 910 insertions(+)
>  create mode 100644 drivers/gpu/drm/bridge/ite-it6263.c
> 
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig index
> 609f4d0ac93d..6b4664d91faa 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -90,6 +90,17 @@ config DRM_FSL_LDB
>  	help
>  	  Support for i.MX8MP DPI-to-LVDS on-SoC encoder.
> 
> +config DRM_ITE_IT6263
> +	tristate "ITE IT6263 LVDS/HDMI bridge"
> +	depends on OF
> +	select DRM_DISPLAY_HDMI_STATE_HELPER
> +	select DRM_DISPLAY_HELPER
> +	select DRM_BRIDGE_CONNECTOR
> +	select DRM_KMS_HELPER
> +	select REGMAP_I2C
> +	help
> +	  ITE IT6263 LVDS to HDMI bridge chip driver.
> +
>  config DRM_ITE_IT6505
>  	tristate "ITE IT6505 DisplayPort bridge"
>  	depends on OF
> diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile index
> 3daf803ce80b..97304b429a53 100644
> --- a/drivers/gpu/drm/bridge/Makefile
> +++ b/drivers/gpu/drm/bridge/Makefile
> @@ -6,6 +6,7 @@ obj-$(CONFIG_DRM_CHRONTEL_CH7033) += chrontel-ch7033.o
>  obj-$(CONFIG_DRM_CROS_EC_ANX7688) += cros-ec-anx7688.o
>  obj-$(CONFIG_DRM_DISPLAY_CONNECTOR) += display-connector.o
>  obj-$(CONFIG_DRM_FSL_LDB) += fsl-ldb.o
> +obj-$(CONFIG_DRM_ITE_IT6263) += ite-it6263.o
>  obj-$(CONFIG_DRM_ITE_IT6505) += ite-it6505.o
>  obj-$(CONFIG_DRM_LONTIUM_LT8912B) += lontium-lt8912b.o
>  obj-$(CONFIG_DRM_LONTIUM_LT9211) += lontium-lt9211.o diff --git a/drivers/gpu/drm/bridge/ite-it6263.c
> b/drivers/gpu/drm/bridge/ite-it6263.c
> new file mode 100644
> index 000000000000..cbabd4e20d3e
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/ite-it6263.c
> @@ -0,0 +1,898 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright 2024 NXP
> + */
> +
> +#include <linux/bitfield.h>
> +#include <linux/bits.h>
> +#include <linux/delay.h>
> +#include <linux/gpio/consumer.h>
> +#include <linux/hdmi.h>
> +#include <linux/i2c.h>
> +#include <linux/media-bus-format.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/regmap.h>
> +#include <linux/regulator/consumer.h>
> +
> +#include <drm/display/drm_hdmi_helper.h> #include
> +<drm/display/drm_hdmi_state_helper.h>
> +#include <drm/drm_atomic.h>
> +#include <drm/drm_atomic_helper.h>
> +#include <drm/drm_atomic_state_helper.h> #include <drm/drm_bridge.h>
> +#include <drm/drm_bridge_connector.h> #include <drm/drm_connector.h>
> +#include <drm/drm_crtc.h> #include <drm/drm_edid.h> #include
> +<drm/drm_of.h> #include <drm/drm_probe_helper.h>
> +
> +/*
> +-----------------------------------------------------------------------
> +------
> + * LVDS registers
> + */
> +
> +/* LVDS software reset registers */
> +#define LVDS_REG_05			0x05
> +#define  REG_SOFT_P_RST			BIT(1)
> +
> +/* LVDS system configuration registers */
> +/* 0x0b */
> +#define LVDS_REG_0B			0x0b
> +#define  REG_SSC_PCLK_RF		BIT(0)
> +#define  REG_LVDS_IN_SWAP		BIT(1)
> +
> +/* LVDS test pattern gen control registers */
> +/* 0x2c */
> +#define LVDS_REG_2C			0x2c
> +#define  REG_COL_DEP			GENMASK(1, 0)
> +#define  BIT8				FIELD_PREP(REG_COL_DEP, 1)
> +#define  OUT_MAP			BIT(4)
> +#define  JEIDA				0
> +#define  REG_DESSC_ENB			BIT(6)
> +#define  DMODE				BIT(7)
> +#define  DISO				BIT(7)
> +#define  SISO				0
> +
> +#define LVDS_REG_3C			0x3c
> +#define LVDS_REG_3F			0x3f
> +#define LVDS_REG_47			0x47
> +#define LVDS_REG_48			0x48
> +#define LVDS_REG_4F			0x4f
> +#define LVDS_REG_52			0x52
> +
> +/*
> +-----------------------------------------------------------------------
> +------
> + * HDMI registers are separated into three banks:
> + * 1) HDMI register common bank: 0x00 ~ 0x2f  */
> +
> +/* HDMI genernal registers */
> +#define HDMI_REG_SW_RST			0x04
> +#define  SOFTREF_RST			BIT(5)
> +#define  SOFTA_RST			BIT(4)
> +#define  SOFTV_RST			BIT(3)
> +#define  AUD_RST			BIT(2)
> +#define  HDCP_RST			BIT(0)
> +#define  HDMI_RST_ALL			(SOFTREF_RST | SOFTA_RST | SOFTV_RST | \
> +					 AUD_RST | HDCP_RST)
> +
> +#define HDMI_REG_SYS_STATUS		0x0e
> +#define  HPDETECT			BIT(6)
> +#define  TXVIDSTABLE			BIT(4)
> +
> +#define HDMI_REG_BANK_CTRL		0x0f
> +#define  REG_BANK_SEL			BIT(0)
> +
> +/* HDMI System DDC control registers */
> +#define HDMI_REG_DDC_MASTER_CTRL	0x10
> +#define  MASTER_SEL_HOST		BIT(0)
> +
> +#define HDMI_REG_DDC_HEADER		0x11
> +
> +#define HDMI_REG_DDC_REQOFF		0x12
> +#define HDMI_REG_DDC_REQCOUNT		0x13
> +#define HDMI_REG_DDC_EDIDSEG		0x14
> +
> +#define HDMI_REG_DDC_CMD		0x15
> +#define  DDC_CMD_EDID_READ		0x3
> +#define  DDC_CMD_FIFO_CLR		0x9
> +
> +#define HDMI_REG_DDC_STATUS		0x16
> +#define  DDC_DONE			BIT(7)
> +#define  DDC_NOACK			BIT(5)
> +#define  DDC_WAITBUS			BIT(4)
> +#define  DDC_ARBILOSE			BIT(3)
> +#define  DDC_ERROR			(DDC_NOACK | DDC_WAITBUS | DDC_ARBILOSE)
> +
> +#define HDMI_DDC_FIFO_BYTES		32
> +#define HDMI_REG_DDC_READFIFO		0x17
> +#define HDMI_REG_LVDS_PORT		0x1d /* LVDS input control I2C addr */
> +#define HDMI_REG_LVDS_PORT_EN		0x1e
> +#define LVDS_INPUT_CTRL_I2C_ADDR	0x33
> +
> +/*
> +-----------------------------------------------------------------------
> +------
> + * 2) HDMI register bank0: 0x30 ~ 0xff
> + */
> +
> +/* HDMI AFE registers */
> +#define HDMI_REG_AFE_DRV_CTRL		0x61
> +#define  AFE_DRV_PWD			BIT(5)
> +#define  AFE_DRV_RST			BIT(4)
> +
> +#define HDMI_REG_AFE_XP_CTRL		0x62
> +#define  AFE_XP_GAINBIT			BIT(7)
> +#define  AFE_XP_ER0			BIT(4)
> +#define  AFE_XP_RESETB			BIT(3)
> +
> +#define HDMI_REG_AFE_ISW_CTRL		0x63
> +
> +#define HDMI_REG_AFE_IP_CTRL		0x64
> +#define  AFE_IP_GAINBIT			BIT(7)
> +#define  AFE_IP_ER0			BIT(3)
> +#define  AFE_IP_RESETB			BIT(2)
> +
> +/* HDMI input data format registers */
> +#define HDMI_REG_INPUT_MODE		0x70
> +#define  IN_RGB				0x00
> +
> +/* HDMI general control registers */
> +#define HDMI_REG_HDMI_MODE		0xc0
> +#define  TX_HDMI_MODE			BIT(0)
> +
> +#define HDMI_REG_GCP			0xc1
> +#define  AVMUTE				BIT(0)
> +#define  HDMI_COLOR_DEPTH		GENMASK(6, 4)
> +#define  HDMI_COLOR_DEPTH_24		FIELD_PREP(HDMI_COLOR_DEPTH, 4)
> +
> +#define HDMI_REG_PKT_GENERAL_CTRL	0xc6
> +#define HDMI_REG_AVI_INFOFRM_CTRL	0xcd
> +#define  ENABLE_PKT			BIT(0)
> +#define  REPEAT_PKT			BIT(1)
> +
> +/*
> +-----------------------------------------------------------------------
> +------
> + * 3) HDMI register bank1: 0x130 ~ 0x1ff (HDMI packet registers)  */
> +
> +/* AVI packet registers */
> +#define HDMI_REG_AVI_DB1		0x158
> +#define HDMI_REG_AVI_DB2		0x159
> +#define HDMI_REG_AVI_DB3		0x15a
> +#define HDMI_REG_AVI_DB4		0x15b
> +#define HDMI_REG_AVI_DB5		0x15c
> +#define HDMI_REG_AVI_CSUM		0x15d
> +#define HDMI_REG_AVI_DB6		0x15e
> +#define HDMI_REG_AVI_DB7		0x15f
> +#define HDMI_REG_AVI_DB8		0x160
> +#define HDMI_REG_AVI_DB9		0x161
> +#define HDMI_REG_AVI_DB10		0x162
> +#define HDMI_REG_AVI_DB11		0x163
> +#define HDMI_REG_AVI_DB12		0x164
> +#define HDMI_REG_AVI_DB13		0x165
> +
> +#define HDMI_AVI_DB_CHUNK1_SIZE		(HDMI_REG_AVI_DB5 - HDMI_REG_AVI_DB1 + 1)
> +#define HDMI_AVI_DB_CHUNK2_SIZE		(HDMI_REG_AVI_DB13 - HDMI_REG_AVI_DB6 + 1)
> +
> +/* IT6263 data sheet Rev0.8: LVDS RX supports input clock rate up to 150MHz. */
> +#define MAX_PIXEL_CLOCK_KHZ		150000
> +
> +/* IT6263 programming guide Ver0.90: PCLK_HIGH for TMDS clock over 80MHz. */
> +#define HIGH_PIXEL_CLOCK_KHZ		80000
> +
> +/*
> + * IT6263 data sheet Rev0.8: HDMI TX supports link speeds of up to
> +2.25Gbps
> + * (link clock rate of 225MHz).
> + */
> +#define MAX_HDMI_TMDS_CHAR_RATE_HZ	225000000
> +
> +struct it6263 {
> +	struct device *dev;
> +	struct i2c_client *hdmi_i2c;
> +	struct i2c_client *lvds_i2c;
> +	struct regmap *hdmi_regmap;
> +	struct regmap *lvds_regmap;
> +	struct drm_bridge bridge;
> +	struct drm_bridge *next_bridge;
> +	int lvds_data_mapping;
> +	bool lvds_dual_link;
> +	bool lvds_link12_swap;
> +};
> +
> +static inline struct it6263 *bridge_to_it6263(struct drm_bridge
> +*bridge) {
> +	return container_of(bridge, struct it6263, bridge); }
> +
> +static bool it6263_hdmi_writeable_reg(struct device *dev, unsigned int
> +reg) {
> +	switch (reg) {
> +	case HDMI_REG_SW_RST:
> +	case HDMI_REG_BANK_CTRL:
> +	case HDMI_REG_DDC_MASTER_CTRL:
> +	case HDMI_REG_DDC_HEADER:
> +	case HDMI_REG_DDC_REQOFF:
> +	case HDMI_REG_DDC_REQCOUNT:
> +	case HDMI_REG_DDC_EDIDSEG:
> +	case HDMI_REG_DDC_CMD:
> +	case HDMI_REG_LVDS_PORT:
> +	case HDMI_REG_LVDS_PORT_EN:
> +	case HDMI_REG_AFE_DRV_CTRL:
> +	case HDMI_REG_AFE_XP_CTRL:
> +	case HDMI_REG_AFE_ISW_CTRL:
> +	case HDMI_REG_AFE_IP_CTRL:
> +	case HDMI_REG_INPUT_MODE:
> +	case HDMI_REG_HDMI_MODE:
> +	case HDMI_REG_GCP:
> +	case HDMI_REG_PKT_GENERAL_CTRL:
> +	case HDMI_REG_AVI_INFOFRM_CTRL:
> +	case HDMI_REG_AVI_DB1:
> +	case HDMI_REG_AVI_DB2:
> +	case HDMI_REG_AVI_DB3:
> +	case HDMI_REG_AVI_DB4:
> +	case HDMI_REG_AVI_DB5:
> +	case HDMI_REG_AVI_CSUM:
> +	case HDMI_REG_AVI_DB6:
> +	case HDMI_REG_AVI_DB7:
> +	case HDMI_REG_AVI_DB8:
> +	case HDMI_REG_AVI_DB9:
> +	case HDMI_REG_AVI_DB10:
> +	case HDMI_REG_AVI_DB11:
> +	case HDMI_REG_AVI_DB12:
> +	case HDMI_REG_AVI_DB13:
> +		return true;
> +	default:
> +		return false;
> +	}
> +}
> +
> +static bool it6263_hdmi_readable_reg(struct device *dev, unsigned int
> +reg) {
> +	if (it6263_hdmi_writeable_reg(dev, reg))
> +		return true;
> +
> +	switch (reg) {
> +	case HDMI_REG_SYS_STATUS:
> +	case HDMI_REG_DDC_STATUS:
> +	case HDMI_REG_DDC_READFIFO:
> +		return true;
> +	default:
> +		return false;
> +	}
> +}
> +
> +static bool it6263_hdmi_volatile_reg(struct device *dev, unsigned int
> +reg) {
> +	switch (reg) {
> +	case HDMI_REG_SW_RST:
> +	case HDMI_REG_SYS_STATUS:
> +	case HDMI_REG_DDC_STATUS:
> +	case HDMI_REG_DDC_READFIFO:
> +		return true;
> +	default:
> +		return false;
> +	}
> +}
> +
> +static const struct regmap_range_cfg it6263_hdmi_range_cfg = {
> +	.range_min = 0x00,
> +	.range_max = HDMI_REG_AVI_DB13,
> +	.selector_reg = HDMI_REG_BANK_CTRL,
> +	.selector_mask = REG_BANK_SEL,
> +	.selector_shift = 0,
> +	.window_start = 0x00,
> +	.window_len = 0x100,
> +};
> +
> +static const struct regmap_config it6263_hdmi_regmap_config = {
> +	.name = "it6263-hdmi",
> +	.reg_bits = 8,
> +	.val_bits = 8,
> +	.writeable_reg = it6263_hdmi_writeable_reg,
> +	.readable_reg = it6263_hdmi_readable_reg,
> +	.volatile_reg = it6263_hdmi_volatile_reg,
> +	.max_register = HDMI_REG_AVI_DB13,
> +	.ranges = &it6263_hdmi_range_cfg,
> +	.num_ranges = 1,
> +	.cache_type = REGCACHE_MAPLE,
> +};
> +
> +static bool it6263_lvds_writeable_reg(struct device *dev, unsigned int
> +reg) {
> +	switch (reg) {
> +	case LVDS_REG_05:
> +	case LVDS_REG_0B:
> +	case LVDS_REG_2C:
> +	case LVDS_REG_3C:
> +	case LVDS_REG_3F:
> +	case LVDS_REG_47:
> +	case LVDS_REG_48:
> +	case LVDS_REG_4F:
> +	case LVDS_REG_52:
> +		return true;
> +	default:
> +		return false;
> +	}
> +}
> +
> +static bool it6263_lvds_readable_reg(struct device *dev, unsigned int
> +reg) {
> +	return it6263_lvds_writeable_reg(dev, reg); }
> +
> +static bool it6263_lvds_volatile_reg(struct device *dev, unsigned int
> +reg) {
> +	return reg == LVDS_REG_05;
> +}
> +
> +static const struct regmap_config it6263_lvds_regmap_config = {
> +	.name = "it6263-lvds",
> +	.reg_bits = 8,
> +	.val_bits = 8,
> +	.writeable_reg = it6263_lvds_writeable_reg,
> +	.readable_reg = it6263_lvds_readable_reg,
> +	.volatile_reg = it6263_lvds_volatile_reg,
> +	.max_register = LVDS_REG_52,
> +	.cache_type = REGCACHE_MAPLE,
> +};
> +
> +static const char * const it6263_supplies[] = {
> +	"ivdd", "ovdd", "txavcc18", "txavcc33", "pvcc1", "pvcc2",
> +	"avcc", "anvdd", "apvdd"
> +};
> +
> +static int it6263_parse_dt(struct it6263 *it) {
> +	struct device *dev = it->dev;
> +	struct device_node *port0, *port1;
> +	int ret = 0;
> +
> +	it->lvds_data_mapping = drm_of_lvds_get_data_mapping(dev->of_node);
> +	if (it->lvds_data_mapping < 0) {
> +		dev_err(dev, "%pOF: invalid or missing %s DT property: %d\n",
> +			dev->of_node, "data-mapping", it->lvds_data_mapping);
> +		return it->lvds_data_mapping;
> +	}
> +
> +	it->next_bridge = devm_drm_of_get_bridge(dev, dev->of_node, 2, 0);
> +	if (IS_ERR(it->next_bridge))
> +		return dev_err_probe(dev, PTR_ERR(it->next_bridge),
> +				     "failed to get next bridge\n");
> +
> +	port0 = of_graph_get_port_by_id(dev->of_node, 0);
> +	port1 = of_graph_get_port_by_id(dev->of_node, 1);
> +	if (port0 && port1) {
> +		int order;
> +
> +		it->lvds_dual_link = true;
> +		order = drm_of_lvds_get_dual_link_pixel_order_sink(port0, port1);
> +		if (order < 0) {
> +			dev_err(dev,
> +				"failed to get dual link pixel order: %d\n",
> +				order);
> +			ret = order;
> +		} else if (order == DRM_LVDS_DUAL_LINK_EVEN_ODD_PIXELS) {
> +			it->lvds_link12_swap = true;
> +		}
> +	} else if (port1) {
> +		ret = -EINVAL;
> +		dev_err(dev, "single input LVDS port1 is not supported\n");
> +	} else if (!port0) {
> +		ret = -EINVAL;
> +		dev_err(dev, "no input LVDS port\n");
> +	}
> +
> +	of_node_put(port0);
> +	of_node_put(port1);
> +
> +	return ret;
> +}
> +
> +static inline void it6263_hw_reset(struct gpio_desc *reset_gpio) {
> +	if (!reset_gpio)
> +		return;
> +
> +	gpiod_set_value_cansleep(reset_gpio, 0);
> +	fsleep(1000);
> +	gpiod_set_value_cansleep(reset_gpio, 1);
> +	/* The chip maker says the low pulse should be at least 40ms. */
> +	fsleep(40000);
> +	gpiod_set_value_cansleep(reset_gpio, 0);
> +	/* addtional time to wait the high voltage to be stable */
> +	fsleep(5000);
> +}
> +
> +static inline int it6263_lvds_set_i2c_addr(struct it6263 *it) {
> +	int ret;
> +
> +	ret = regmap_write(it->hdmi_regmap, HDMI_REG_LVDS_PORT,
> +			   LVDS_INPUT_CTRL_I2C_ADDR << 1);
> +	if (ret)
> +		return ret;
> +
> +	return regmap_write(it->hdmi_regmap, HDMI_REG_LVDS_PORT_EN, BIT(0)); }
> +
> +static inline void it6263_lvds_reset(struct it6263 *it) {
> +	/* AFE PLL reset */
> +	regmap_write_bits(it->lvds_regmap, LVDS_REG_3C, BIT(0), 0x0);
> +	fsleep(1000);
> +	regmap_write_bits(it->lvds_regmap, LVDS_REG_3C, BIT(0), BIT(0));
> +
> +	/* software pixel clock domain reset */
> +	regmap_write_bits(it->lvds_regmap, LVDS_REG_05, REG_SOFT_P_RST,
> +			  REG_SOFT_P_RST);
> +	fsleep(1000);
> +	regmap_write_bits(it->lvds_regmap, LVDS_REG_05, REG_SOFT_P_RST, 0x0);
> +	fsleep(10000);
> +}
> +
> +static inline void it6263_lvds_set_interface(struct it6263 *it) {
> +	/* color depth */
> +	regmap_write_bits(it->lvds_regmap, LVDS_REG_2C, REG_COL_DEP, BIT8);
> +	/* output mapping */
> +	regmap_write_bits(it->lvds_regmap, LVDS_REG_2C, OUT_MAP, JEIDA);
> +
> +	if (it->lvds_dual_link) {
> +		regmap_write_bits(it->lvds_regmap, LVDS_REG_2C, DMODE, DISO);
> +		regmap_write_bits(it->lvds_regmap, LVDS_REG_52, BIT(1), BIT(1));
> +	} else {
> +		regmap_write_bits(it->lvds_regmap, LVDS_REG_2C, DMODE, SISO);
> +		regmap_write_bits(it->lvds_regmap, LVDS_REG_52, BIT(1), 0);
> +	}
> +}
> +
> +static inline void it6263_lvds_set_afe(struct it6263 *it) {
> +	regmap_write(it->lvds_regmap, LVDS_REG_3C, 0xaa);
> +	regmap_write(it->lvds_regmap, LVDS_REG_3F, 0x02);
> +	regmap_write(it->lvds_regmap, LVDS_REG_47, 0xaa);
> +	regmap_write(it->lvds_regmap, LVDS_REG_48, 0x02);
> +	regmap_write(it->lvds_regmap, LVDS_REG_4F, 0x11);
> +
> +	regmap_write_bits(it->lvds_regmap, LVDS_REG_0B, REG_SSC_PCLK_RF,
> +			  REG_SSC_PCLK_RF);
> +	regmap_write_bits(it->lvds_regmap, LVDS_REG_3C, 0x07, 0);
> +	regmap_write_bits(it->lvds_regmap, LVDS_REG_2C, REG_DESSC_ENB,
> +			  REG_DESSC_ENB);
> +}
> +
> +static inline void it6263_lvds_sys_cfg(struct it6263 *it) {
> +	regmap_write_bits(it->lvds_regmap, LVDS_REG_0B, REG_LVDS_IN_SWAP,
> +			  it->lvds_link12_swap ? REG_LVDS_IN_SWAP : 0); }
> +
> +static inline void it6263_lvds_config(struct it6263 *it) {
> +	it6263_lvds_reset(it);
> +	it6263_lvds_set_interface(it);
> +	it6263_lvds_set_afe(it);
> +	it6263_lvds_sys_cfg(it);
> +}
> +
> +static inline void it6263_hdmi_config(struct it6263 *it) {
> +	regmap_write(it->hdmi_regmap, HDMI_REG_SW_RST, HDMI_RST_ALL);
> +	regmap_write(it->hdmi_regmap, HDMI_REG_INPUT_MODE, IN_RGB);
> +	regmap_write_bits(it->hdmi_regmap, HDMI_REG_GCP, HDMI_COLOR_DEPTH,
> +			  HDMI_COLOR_DEPTH_24);
> +}
> +
> +static enum drm_connector_status it6263_detect(struct it6263 *it) {
> +	unsigned int val;
> +
> +	regmap_read(it->hdmi_regmap, HDMI_REG_SYS_STATUS, &val);
> +	if (val & HPDETECT)
> +		return connector_status_connected;
> +	else
> +		return connector_status_disconnected; }
> +
> +static int it6263_read_edid(void *data, u8 *buf, unsigned int block,
> +size_t len) {
> +	struct it6263 *it = data;
> +	struct regmap *regmap = it->hdmi_regmap;
> +	unsigned int start = (block % 2) * EDID_LENGTH;
> +	unsigned int segment = block >> 1;
> +	unsigned int count, val;
> +	int ret;
> +
> +	regmap_write(regmap, HDMI_REG_DDC_MASTER_CTRL, MASTER_SEL_HOST);
> +	regmap_write(regmap, HDMI_REG_DDC_HEADER, DDC_ADDR << 1);
> +	regmap_write(regmap, HDMI_REG_DDC_EDIDSEG, segment);
> +
> +	while (len) {
> +		/* clear DDC FIFO */
> +		regmap_write(regmap, HDMI_REG_DDC_CMD, DDC_CMD_FIFO_CLR);
> +
> +		ret = regmap_read_poll_timeout(regmap, HDMI_REG_DDC_STATUS,
> +					       val, val & DDC_DONE,
> +					       2000, 10000);
> +		if (ret) {
> +			dev_err(it->dev, "failed to clear DDC FIFO:%d\n", ret);
> +			return ret;
> +		}
> +
> +		count = len > HDMI_DDC_FIFO_BYTES ? HDMI_DDC_FIFO_BYTES : len;
> +
> +		/* fire the read command */
> +		regmap_write(regmap, HDMI_REG_DDC_REQOFF, start);
> +		regmap_write(regmap, HDMI_REG_DDC_REQCOUNT, count);
> +		regmap_write(regmap, HDMI_REG_DDC_CMD, DDC_CMD_EDID_READ);
> +
> +		start += count;
> +		len -= count;
> +
> +		ret = regmap_read_poll_timeout(regmap, HDMI_REG_DDC_STATUS, val,
> +					       val & (DDC_DONE | DDC_ERROR),
> +					       20000, 250000);
> +		if (ret && !(val & DDC_ERROR)) {
> +			dev_err(it->dev, "failed to read EDID:%d\n", ret);
> +			return ret;
> +		}
> +
> +		if (val & DDC_ERROR) {
> +			dev_err(it->dev, "DDC error\n");
> +			return -EIO;
> +		}
> +
> +		/* cache to buffer */
> +		for (; count > 0; count--) {
> +			regmap_read(regmap, HDMI_REG_DDC_READFIFO, &val);
> +			*(buf++) = val;
> +		}
> +	}
> +
> +	return 0;
> +}
> +
> +static int it6263_bridge_atomic_check(struct drm_bridge *bridge,
> +				      struct drm_bridge_state *bridge_state,
> +				      struct drm_crtc_state *crtc_state,
> +				      struct drm_connector_state *conn_state) {
> +	return drm_atomic_helper_connector_hdmi_check(conn_state->connector,
> +						      conn_state->state);
> +}
> +
> +static void
> +it6263_bridge_atomic_disable(struct drm_bridge *bridge,
> +			     struct drm_bridge_state *old_bridge_state) {
> +	struct it6263 *it = bridge_to_it6263(bridge);
> +
> +	regmap_write_bits(it->hdmi_regmap, HDMI_REG_GCP, AVMUTE, AVMUTE);
> +	regmap_write(it->hdmi_regmap, HDMI_REG_PKT_GENERAL_CTRL, 0);
> +	regmap_write(it->hdmi_regmap, HDMI_REG_AFE_DRV_CTRL,
> +		     AFE_DRV_RST | AFE_DRV_PWD);
> +}
> +
> +static void
> +it6263_bridge_atomic_enable(struct drm_bridge *bridge,
> +			    struct drm_bridge_state *old_bridge_state) {
> +	struct drm_atomic_state *state = old_bridge_state->base.state;
> +	struct it6263 *it = bridge_to_it6263(bridge);
> +	const struct drm_crtc_state *crtc_state;
> +	struct regmap *regmap = it->hdmi_regmap;
> +	const struct drm_display_mode *mode;
> +	struct drm_connector *connector;
> +	bool is_stable = false;
> +	struct drm_crtc *crtc;
> +	unsigned int val;
> +	bool pclk_high;
> +	int i, ret;
> +
> +	connector = drm_atomic_get_new_connector_for_encoder(state,
> +							     bridge->encoder);
> +	crtc = drm_atomic_get_new_connector_state(state, connector)->crtc;
> +	crtc_state = drm_atomic_get_new_crtc_state(state, crtc);
> +	mode = &crtc_state->adjusted_mode;
> +
> +	regmap_write(regmap, HDMI_REG_HDMI_MODE, TX_HDMI_MODE);
> +
> +	drm_atomic_helper_connector_hdmi_update_infoframes(connector, state);
> +
> +	/* HDMI AFE setup */
> +	pclk_high = mode->clock > HIGH_PIXEL_CLOCK_KHZ;
> +	regmap_write(regmap, HDMI_REG_AFE_DRV_CTRL, AFE_DRV_RST);
> +	if (pclk_high)
> +		regmap_write(regmap, HDMI_REG_AFE_XP_CTRL,
> +			     AFE_XP_GAINBIT | AFE_XP_RESETB);
> +	else
> +		regmap_write(regmap, HDMI_REG_AFE_XP_CTRL,
> +			     AFE_XP_ER0 | AFE_XP_RESETB);
> +	regmap_write(regmap, HDMI_REG_AFE_ISW_CTRL, 0x10);
> +	if (pclk_high)
> +		regmap_write(regmap, HDMI_REG_AFE_IP_CTRL,
> +			     AFE_IP_GAINBIT | AFE_IP_RESETB);
> +	else
> +		regmap_write(regmap, HDMI_REG_AFE_IP_CTRL,
> +			     AFE_IP_ER0 | AFE_IP_RESETB);
> +
> +	/* HDMI software video reset */
> +	regmap_write_bits(regmap, HDMI_REG_SW_RST, SOFTV_RST, SOFTV_RST);
> +	fsleep(1000);
> +	regmap_write_bits(regmap, HDMI_REG_SW_RST, SOFTV_RST, 0);
> +
> +	/* reconfigure LVDS and retry several times in case video is instable */
> +	for (i = 0; i < 3; i++) {
> +		ret = regmap_read_poll_timeout(regmap, HDMI_REG_SYS_STATUS, val,
> +					       val & TXVIDSTABLE,
> +					       20000, 500000);
> +		if (!ret) {
> +			is_stable = true;
> +			break;
> +		}
> +
> +		it6263_lvds_config(it);
> +	}
> +
> +	if (!is_stable)
> +		dev_warn(it->dev, "failed to wait for video stable\n");
> +
> +	/* HDMI AFE reset release and power up */
> +	regmap_write(regmap, HDMI_REG_AFE_DRV_CTRL, 0);
> +
> +	regmap_write_bits(regmap, HDMI_REG_GCP, AVMUTE, 0);
> +
> +	regmap_write(regmap, HDMI_REG_PKT_GENERAL_CTRL, ENABLE_PKT |
> +REPEAT_PKT); }
> +
> +static enum drm_mode_status
> +it6263_bridge_mode_valid(struct drm_bridge *bridge,
> +			 const struct drm_display_info *info,
> +			 const struct drm_display_mode *mode) {
> +	unsigned long long rate;
> +
> +	rate = drm_hdmi_compute_mode_clock(mode, 8, HDMI_COLORSPACE_RGB);
> +	if (rate == 0)
> +		return MODE_NOCLOCK;
> +
> +	return bridge->funcs->hdmi_tmds_char_rate_valid(bridge, mode, rate); }
> +
> +static int it6263_bridge_attach(struct drm_bridge *bridge,
> +				enum drm_bridge_attach_flags flags) {
> +	struct it6263 *it = bridge_to_it6263(bridge);
> +	struct drm_connector *connector;
> +	int ret;
> +
> +	ret = drm_bridge_attach(bridge->encoder, it->next_bridge, bridge,
> +				flags | DRM_BRIDGE_ATTACH_NO_CONNECTOR);
> +	if (ret < 0)
> +		return ret;
> +
> +	if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)
> +		return 0;
> +
> +	connector = drm_bridge_connector_init(bridge->dev, bridge->encoder);
> +	if (IS_ERR(connector)) {
> +		ret = PTR_ERR(connector);
> +		dev_err(it->dev, "failed to initialize bridge connector: %d\n",
> +			ret);
> +		return ret;
> +	}
> +
> +	drm_connector_attach_encoder(connector, bridge->encoder);
> +
> +	return 0;
> +}
> +
> +static enum drm_connector_status it6263_bridge_detect(struct drm_bridge
> +*bridge) {
> +	struct it6263 *it = bridge_to_it6263(bridge);
> +
> +	return it6263_detect(it);
> +}
> +
> +static const struct drm_edid *
> +it6263_bridge_edid_read(struct drm_bridge *bridge,
> +			struct drm_connector *connector)
> +{
> +	struct it6263 *it = bridge_to_it6263(bridge);
> +
> +	return drm_edid_read_custom(connector, it6263_read_edid, it); }
> +
> +static u32 *
> +it6263_bridge_atomic_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 it6263 *it = bridge_to_it6263(bridge);
> +	u32 *input_fmts;
> +
> +	*num_input_fmts = 0;
> +
> +	if (it->lvds_data_mapping != MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA)
> +		return NULL;
> +
> +	input_fmts = kmalloc(sizeof(*input_fmts), GFP_KERNEL);
> +	if (!input_fmts)
> +		return NULL;
> +
> +	input_fmts[0] = MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA;
> +	*num_input_fmts = 1;
> +
> +	return input_fmts;
> +}
> +
> +static enum drm_mode_status
> +it6263_hdmi_tmds_char_rate_valid(const struct drm_bridge *bridge,
> +				 const struct drm_display_mode *mode,
> +				 unsigned long long tmds_rate)
> +{
> +	if (mode->clock > MAX_PIXEL_CLOCK_KHZ)
> +		return MODE_CLOCK_HIGH;
> +
> +	if (tmds_rate > MAX_HDMI_TMDS_CHAR_RATE_HZ)
> +		return MODE_CLOCK_HIGH;
> +
> +	return MODE_OK;
> +}
> +
> +static int it6263_hdmi_clear_infoframe(struct drm_bridge *bridge,
> +				       enum hdmi_infoframe_type type) {
> +	struct it6263 *it = bridge_to_it6263(bridge);
> +
> +	if (type == HDMI_INFOFRAME_TYPE_AVI)
> +		regmap_write(it->hdmi_regmap, HDMI_REG_AVI_INFOFRM_CTRL, 0);
> +	else
> +		dev_dbg(it->dev, "unsupported HDMI infoframe 0x%x\n", type);
> +
> +	return 0;
> +}
> +
> +static int it6263_hdmi_write_infoframe(struct drm_bridge *bridge,
> +				       enum hdmi_infoframe_type type,
> +				       const u8 *buffer, size_t len) {
> +	struct it6263 *it = bridge_to_it6263(bridge);
> +	struct regmap *regmap = it->hdmi_regmap;
> +
> +	if (type != HDMI_INFOFRAME_TYPE_AVI) {
> +		dev_dbg(it->dev, "unsupported HDMI infoframe 0x%x\n", type);
> +		return 0;
> +	}
> +
> +	/* write the first AVI infoframe data byte chunk(DB1-DB5) */
> +	regmap_bulk_write(regmap, HDMI_REG_AVI_DB1,
> +			  &buffer[HDMI_INFOFRAME_HEADER_SIZE],
> +			  HDMI_AVI_DB_CHUNK1_SIZE);
> +
> +	/* write the second AVI infoframe data byte chunk(DB6-DB13) */
> +	regmap_bulk_write(regmap, HDMI_REG_AVI_DB6,
> +			  &buffer[HDMI_INFOFRAME_HEADER_SIZE +
> +				  HDMI_AVI_DB_CHUNK1_SIZE],
> +			  HDMI_AVI_DB_CHUNK2_SIZE);
> +
> +	/* write checksum */
> +	regmap_write(regmap, HDMI_REG_AVI_CSUM, buffer[3]);
> +
> +	regmap_write(regmap, HDMI_REG_AVI_INFOFRM_CTRL, ENABLE_PKT |
> +REPEAT_PKT);
> +
> +	return 0;
> +}
> +
> +static const struct drm_bridge_funcs it6263_bridge_funcs = {
> +	.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,
> +	.attach = it6263_bridge_attach,
> +	.mode_valid = it6263_bridge_mode_valid,
> +	.atomic_disable = it6263_bridge_atomic_disable,
> +	.atomic_enable = it6263_bridge_atomic_enable,
> +	.atomic_check = it6263_bridge_atomic_check,
> +	.detect = it6263_bridge_detect,
> +	.edid_read = it6263_bridge_edid_read,
> +	.atomic_get_input_bus_fmts = it6263_bridge_atomic_get_input_bus_fmts,
> +	.hdmi_tmds_char_rate_valid = it6263_hdmi_tmds_char_rate_valid,
> +	.hdmi_clear_infoframe = it6263_hdmi_clear_infoframe,
> +	.hdmi_write_infoframe = it6263_hdmi_write_infoframe, };
> +
> +static int it6263_probe(struct i2c_client *client) {
> +	struct device *dev = &client->dev;
> +	struct gpio_desc *reset_gpio;
> +	struct it6263 *it;
> +	int ret;
> +
> +	it = devm_kzalloc(dev, sizeof(*it), GFP_KERNEL);
> +	if (!it)
> +		return -ENOMEM;
> +
> +	it->dev = dev;
> +	it->hdmi_i2c = client;
> +
> +	it->hdmi_regmap = devm_regmap_init_i2c(client,
> +					       &it6263_hdmi_regmap_config);
> +	if (IS_ERR(it->hdmi_regmap))
> +		return dev_err_probe(dev, PTR_ERR(it->hdmi_regmap),
> +				     "failed to init I2C regmap for HDMI\n");
> +
> +	reset_gpio = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_LOW);
> +	if (IS_ERR(reset_gpio))
> +		return dev_err_probe(dev, PTR_ERR(reset_gpio),
> +				     "failed to get reset gpio\n");
> +
> +	ret = devm_regulator_bulk_get_enable(dev, ARRAY_SIZE(it6263_supplies),
> +					     it6263_supplies);
> +	if (ret)
> +		return dev_err_probe(dev, ret, "failed to get power supplies\n");
> +
> +	ret = it6263_parse_dt(it);
> +	if (ret)
> +		return ret;
> +
> +	it6263_hw_reset(reset_gpio);
> +
> +	ret = it6263_lvds_set_i2c_addr(it);
> +	if (ret)
> +		return dev_err_probe(dev, ret, "failed to set I2C addr\n");
> +
> +	it->lvds_i2c = devm_i2c_new_dummy_device(dev, client->adapter,
> +						 LVDS_INPUT_CTRL_I2C_ADDR);
> +	if (IS_ERR(it->lvds_i2c))
> +		dev_err_probe(it->dev, PTR_ERR(it->lvds_i2c),
> +			      "failed to allocate I2C device for LVDS\n");
> +
> +	it->lvds_regmap = devm_regmap_init_i2c(it->lvds_i2c,
> +					       &it6263_lvds_regmap_config);
> +	if (IS_ERR(it->lvds_regmap))
> +		return dev_err_probe(dev, PTR_ERR(it->lvds_regmap),
> +				     "failed to init I2C regmap for LVDS\n");
> +
> +	it6263_lvds_config(it);
> +	it6263_hdmi_config(it);
> +
> +	i2c_set_clientdata(client, it);
> +
> +	it->bridge.funcs = &it6263_bridge_funcs;
> +	it->bridge.of_node = dev->of_node;
> +	/* IT6263 chip doesn't support HPD interrupt. */
> +	it->bridge.ops = DRM_BRIDGE_OP_DETECT | DRM_BRIDGE_OP_EDID |
> +			 DRM_BRIDGE_OP_HDMI;
> +	it->bridge.type = DRM_MODE_CONNECTOR_HDMIA;
> +	it->bridge.vendor = "ITE";
> +	it->bridge.product = "IT6263";
> +
> +	return devm_drm_bridge_add(dev, &it->bridge); }
> +
> +static const struct of_device_id it6263_of_match[] = {
> +	{ .compatible = "ite,it6263", },
> +	{ }
> +};
> +MODULE_DEVICE_TABLE(of, it6263_of_match);
> +
> +static const struct i2c_device_id it6263_i2c_ids[] = {
> +	{ "it6263", 0 },
> +	{ }
> +};
> +MODULE_DEVICE_TABLE(i2c, it6263_i2c_ids);
> +
> +static struct i2c_driver it6263_driver = {
> +	.probe = it6263_probe,
> +	.driver = {
> +		.name = "it6263",
> +		.of_match_table = it6263_of_match,
> +	},
> +	.id_table = it6263_i2c_ids,
> +};
> +module_i2c_driver(it6263_driver);
> +
> +MODULE_DESCRIPTION("ITE Tech. Inc. IT6263 LVDS/HDMI bridge");
> +MODULE_AUTHOR("Liu Ying <victor.liu@nxp.com>"); MODULE_LICENSE("GPL");
> --
> 2.34.1

Re: [PATCH v4 10/13] drm/bridge: Add ITE IT6263 LVDS to HDMI converter

[Dmitry Baryshkov]

On Mon, Oct 28, 2024 at 10:37:37AM +0800, Liu Ying wrote:
> Add basic HDMI video output support. Currently, only RGB888 output
> pixel format is supported.  At the LVDS input side, the driver
> supports single LVDS link and dual LVDS links with "jeida-24" LVDS
> mapping.
> 
> Product link:
> https://www.ite.com.tw/en/product/cate1/IT6263
> 
> Signed-off-by: Liu Ying <victor.liu@nxp.com>
> Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com>
> Acked-by: Maxime Ripard <mripard@kernel.org>

Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>

-- 
With best wishes
Dmitry

Re: [PATCH v4 13/13] MAINTAINERS: Add maintainer for ITE IT6263 driver

[Dmitry Baryshkov]

On Mon, Oct 28, 2024 at 10:37:40AM +0800, Liu Ying wrote:
> Add myself as the maintainer of ITE IT6263 LVDS TO HDMI BRIDGE DRIVER.
> 
> Signed-off-by: Liu Ying <victor.liu@nxp.com>
> ---
> v4:
> * No change.
> 
> v3:
> * No change.
> 
> v2:
> * New patch.  (Maxime)
> 
>  MAINTAINERS | 8 ++++++++
>  1 file changed, 8 insertions(+)

Acked-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>

-- 
With best wishes
Dmitry

Re: [PATCH v4 00/13] Add ITE IT6263 LVDS to HDMI converter support

[Dmitry Baryshkov]

Hi,

On Mon, 28 Oct 2024 at 04:37, Liu Ying <victor.liu@nxp.com> wrote:
>
> Hi,
>
> This patch series aims to add ITE IT6263 LVDS to HDMI converter on
> i.MX8MP EVK.  Combined with LVDS receiver and HDMI 1.4a transmitter,
> the IT6263 supports LVDS input and HDMI 1.4 output by conversion
> function.  IT6263 product link can be found at [1].
>
> Patch 1 is a preparation patch to allow display mode of an existing
> panel to pass the added mode validation logic in patch 3.
>
> Patch 2 allows i.MX8MP LVDS Display Bridge(LDB) bridge driver to find
> the next non-panel bridge, that is the IT6263 in this case.
>
> Patch 3 adds mode validation logic to i.MX8MP LDB bridge driver against
> "ldb" clock so that it can filter out unsupported display modes read
> from EDID.
>
> Patch 4 adds MEDIA_BUS_FMT_RGB101010_1X7X5_{SPWG,JEIDA} support, as they
> are supported by IT6263(with LVDS data bit reversed order).
>
> Patch 5 makes drm_of.c use MEDIA_BUS_FMT_RGB101010_1X7X5_{JEIDA,SPWG}.
>
> Patch 6 supports getting dual-link LVDS pixel order for the sink side as
> needed by IT6263 driver.
>
> Patch 7 documents jeida-30 and vesa-30 data mappings in lvds-data-mapping.yaml,
> as needed by IT6263 DT binding.
>
> Patch 8 extracts common dual-link LVDS display properties into new
> lvds-dual-ports.yaml so that IT6263 DT binding can reference it.
>
> Patch 9 adds DT binding for IT6263.
>
> Patch 10 adds IT6263 bridge driver.  Only video output is supported.
>
> Patch 11 adds DT overlays to support NXP adapter cards[2][3] with IT6263
> populated.
>
> Patch 12 enables the IT6263 bridge driver in defconfig.
>
> Patch 13 updates MAINTAINERS to add maintainer for IT6263 driver.

This has pretty complicated structure from the merging point of view.

I propose we take patches 6, 8, 9 (without 30-bit formats, they can be
dropped while applying), 11, 12 (?) and 13 through drm-misc in one
batch (once DT maintainers review the binding parts). This looks like
a minimal set, having no extra dependencies.

The second set might be 4, 5 + new patch, re-adding 30-bit formats to
IT6263 binding (no driver changes are necessary). This can go in
separately, after an Ack from media maintainers.

Of course both sets can go together if linux-media maintainers reacts
quickly and ack merging media-formats patch through drm-misc tree.

The rest of the patches don't have such strong dependencies and go in
once ready / reviewed.

WDYT?

-- 
With best wishes
Dmitry

RE: [PATCH v4 00/13] Add ITE IT6263 LVDS to HDMI converter support

[Biju Das]

Hi Dmitry, Liu,

> -----Original Message-----
> From: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> Sent: 28 October 2024 10:20
> Subject: Re: [PATCH v4 00/13] Add ITE IT6263 LVDS to HDMI converter support
> 
> Hi,
> 
> On Mon, 28 Oct 2024 at 04:37, Liu Ying <victor.liu@nxp.com> wrote:
> >
> > Hi,
> >
> > This patch series aims to add ITE IT6263 LVDS to HDMI converter on
> > i.MX8MP EVK.  Combined with LVDS receiver and HDMI 1.4a transmitter,
> > the IT6263 supports LVDS input and HDMI 1.4 output by conversion
> > function.  IT6263 product link can be found at [1].
> >
> > Patch 1 is a preparation patch to allow display mode of an existing
> > panel to pass the added mode validation logic in patch 3.
> >
> > Patch 2 allows i.MX8MP LVDS Display Bridge(LDB) bridge driver to find
> > the next non-panel bridge, that is the IT6263 in this case.
> >
> > Patch 3 adds mode validation logic to i.MX8MP LDB bridge driver
> > against "ldb" clock so that it can filter out unsupported display
> > modes read from EDID.
> >
> > Patch 4 adds MEDIA_BUS_FMT_RGB101010_1X7X5_{SPWG,JEIDA} support, as
> > they are supported by IT6263(with LVDS data bit reversed order).
> >
> > Patch 5 makes drm_of.c use MEDIA_BUS_FMT_RGB101010_1X7X5_{JEIDA,SPWG}.
> >
> > Patch 6 supports getting dual-link LVDS pixel order for the sink side
> > as needed by IT6263 driver.
> >
> > Patch 7 documents jeida-30 and vesa-30 data mappings in
> > lvds-data-mapping.yaml, as needed by IT6263 DT binding.
> >
> > Patch 8 extracts common dual-link LVDS display properties into new
> > lvds-dual-ports.yaml so that IT6263 DT binding can reference it.
> >
> > Patch 9 adds DT binding for IT6263.
> >
> > Patch 10 adds IT6263 bridge driver.  Only video output is supported.
> >
> > Patch 11 adds DT overlays to support NXP adapter cards[2][3] with
> > IT6263 populated.
> >
> > Patch 12 enables the IT6263 bridge driver in defconfig.
> >
> > Patch 13 updates MAINTAINERS to add maintainer for IT6263 driver.
> 
> This has pretty complicated structure from the merging point of view.
> 
> I propose we take patches 6, 8, 9 (without 30-bit formats, they can be dropped while applying), 11, 12
> (?) and 13 through drm-misc in one batch (once DT maintainers review the binding parts). This looks
> like a minimal set, having no extra dependencies.

> 
> The second set might be 4, 5 + new patch, re-adding 30-bit formats to
> IT6263 binding (no driver changes are necessary). This can go in separately, after an Ack from media
> maintainers.
> 
> Of course both sets can go together if linux-media maintainers reacts quickly and ack merging media-
> formats patch through drm-misc tree.
> 
> The rest of the patches don't have such strong dependencies and go in once ready / reviewed.
> 
> WDYT?

I guess, 6,8,9(without 30-bit formats), 10, 12 and 13.

11 may have dependency on 1, 2 and 3 as it is SoC specific.

Then 4, 5 + new patch, re-adding 30-bit formats to IT6263 binding.

Cheers,
Biju        

Re: [PATCH v4 00/13] Add ITE IT6263 LVDS to HDMI converter support

[Dmitry Baryshkov]

On Mon, Oct 28, 2024 at 11:12:00AM +0000, Biju Das wrote:
> Hi Dmitry, Liu,
> 
> > -----Original Message-----
> > From: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> > Sent: 28 October 2024 10:20
> > Subject: Re: [PATCH v4 00/13] Add ITE IT6263 LVDS to HDMI converter support
> > 
> > Hi,
> > 
> > On Mon, 28 Oct 2024 at 04:37, Liu Ying <victor.liu@nxp.com> wrote:
> > >
> > > Hi,
> > >
> > > This patch series aims to add ITE IT6263 LVDS to HDMI converter on
> > > i.MX8MP EVK.  Combined with LVDS receiver and HDMI 1.4a transmitter,
> > > the IT6263 supports LVDS input and HDMI 1.4 output by conversion
> > > function.  IT6263 product link can be found at [1].
> > >
> > > Patch 1 is a preparation patch to allow display mode of an existing
> > > panel to pass the added mode validation logic in patch 3.
> > >
> > > Patch 2 allows i.MX8MP LVDS Display Bridge(LDB) bridge driver to find
> > > the next non-panel bridge, that is the IT6263 in this case.
> > >
> > > Patch 3 adds mode validation logic to i.MX8MP LDB bridge driver
> > > against "ldb" clock so that it can filter out unsupported display
> > > modes read from EDID.
> > >
> > > Patch 4 adds MEDIA_BUS_FMT_RGB101010_1X7X5_{SPWG,JEIDA} support, as
> > > they are supported by IT6263(with LVDS data bit reversed order).
> > >
> > > Patch 5 makes drm_of.c use MEDIA_BUS_FMT_RGB101010_1X7X5_{JEIDA,SPWG}.
> > >
> > > Patch 6 supports getting dual-link LVDS pixel order for the sink side
> > > as needed by IT6263 driver.
> > >
> > > Patch 7 documents jeida-30 and vesa-30 data mappings in
> > > lvds-data-mapping.yaml, as needed by IT6263 DT binding.
> > >
> > > Patch 8 extracts common dual-link LVDS display properties into new
> > > lvds-dual-ports.yaml so that IT6263 DT binding can reference it.
> > >
> > > Patch 9 adds DT binding for IT6263.
> > >
> > > Patch 10 adds IT6263 bridge driver.  Only video output is supported.
> > >
> > > Patch 11 adds DT overlays to support NXP adapter cards[2][3] with
> > > IT6263 populated.
> > >
> > > Patch 12 enables the IT6263 bridge driver in defconfig.
> > >
> > > Patch 13 updates MAINTAINERS to add maintainer for IT6263 driver.
> > 
> > This has pretty complicated structure from the merging point of view.
> > 
> > I propose we take patches 6, 8, 9 (without 30-bit formats, they can be dropped while applying), 11, 12
> > (?) and 13 through drm-misc in one batch (once DT maintainers review the binding parts). This looks
> > like a minimal set, having no extra dependencies.
> 
> > 
> > The second set might be 4, 5 + new patch, re-adding 30-bit formats to
> > IT6263 binding (no driver changes are necessary). This can go in separately, after an Ack from media
> > maintainers.
> > 
> > Of course both sets can go together if linux-media maintainers reacts quickly and ack merging media-
> > formats patch through drm-misc tree.
> > 
> > The rest of the patches don't have such strong dependencies and go in once ready / reviewed.
> > 
> > WDYT?
> 
> I guess, 6,8,9(without 30-bit formats), 10, 12 and 13.
> 
> 11 may have dependency on 1, 2 and 3 as it is SoC specific.

Yes, of course, 10, not 11.

> Then 4, 5 + new patch, re-adding 30-bit formats to IT6263 binding.

-- 
With best wishes
Dmitry

Re: [PATCH v4 00/13] Add ITE IT6263 LVDS to HDMI converter support

[Liu Ying]

On 10/28/2024, Dmitry Baryshkov wrote:
> On Mon, Oct 28, 2024 at 11:12:00AM +0000, Biju Das wrote:
>> Hi Dmitry, Liu,
>>
>>> -----Original Message-----
>>> From: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
>>> Sent: 28 October 2024 10:20
>>> Subject: Re: [PATCH v4 00/13] Add ITE IT6263 LVDS to HDMI converter support
>>>
>>> Hi,
>>>
>>> On Mon, 28 Oct 2024 at 04:37, Liu Ying <victor.liu@nxp.com> wrote:
>>>>
>>>> Hi,
>>>>
>>>> This patch series aims to add ITE IT6263 LVDS to HDMI converter on
>>>> i.MX8MP EVK.  Combined with LVDS receiver and HDMI 1.4a transmitter,
>>>> the IT6263 supports LVDS input and HDMI 1.4 output by conversion
>>>> function.  IT6263 product link can be found at [1].
>>>>
>>>> Patch 1 is a preparation patch to allow display mode of an existing
>>>> panel to pass the added mode validation logic in patch 3.
>>>>
>>>> Patch 2 allows i.MX8MP LVDS Display Bridge(LDB) bridge driver to find
>>>> the next non-panel bridge, that is the IT6263 in this case.
>>>>
>>>> Patch 3 adds mode validation logic to i.MX8MP LDB bridge driver
>>>> against "ldb" clock so that it can filter out unsupported display
>>>> modes read from EDID.
>>>>
>>>> Patch 4 adds MEDIA_BUS_FMT_RGB101010_1X7X5_{SPWG,JEIDA} support, as
>>>> they are supported by IT6263(with LVDS data bit reversed order).
>>>>
>>>> Patch 5 makes drm_of.c use MEDIA_BUS_FMT_RGB101010_1X7X5_{JEIDA,SPWG}.
>>>>
>>>> Patch 6 supports getting dual-link LVDS pixel order for the sink side
>>>> as needed by IT6263 driver.
>>>>
>>>> Patch 7 documents jeida-30 and vesa-30 data mappings in
>>>> lvds-data-mapping.yaml, as needed by IT6263 DT binding.
>>>>
>>>> Patch 8 extracts common dual-link LVDS display properties into new
>>>> lvds-dual-ports.yaml so that IT6263 DT binding can reference it.
>>>>
>>>> Patch 9 adds DT binding for IT6263.
>>>>
>>>> Patch 10 adds IT6263 bridge driver.  Only video output is supported.
>>>>
>>>> Patch 11 adds DT overlays to support NXP adapter cards[2][3] with
>>>> IT6263 populated.
>>>>
>>>> Patch 12 enables the IT6263 bridge driver in defconfig.
>>>>
>>>> Patch 13 updates MAINTAINERS to add maintainer for IT6263 driver.
>>>
>>> This has pretty complicated structure from the merging point of view.
>>>
>>> I propose we take patches 6, 8, 9 (without 30-bit formats, they can be dropped while applying), 11, 12
>>> (?) and 13 through drm-misc in one batch (once DT maintainers review the binding parts). This looks
>>> like a minimal set, having no extra dependencies.
>>
>>>
>>> The second set might be 4, 5 + new patch, re-adding 30-bit formats to
>>> IT6263 binding (no driver changes are necessary). This can go in separately, after an Ack from media
>>> maintainers.
>>>
>>> Of course both sets can go together if linux-media maintainers reacts quickly and ack merging media-
>>> formats patch through drm-misc tree.

I'm fine with merging the two sets through drm-misc tree as long
as linux-media and dri-devel maintainers accept this.  Up to them.

>>>
>>> The rest of the patches don't have such strong dependencies and go in once ready / reviewed.
>>>
>>> WDYT?
>>
>> I guess, 6,8,9(without 30-bit formats), 10, 12 and 13.
>>
>> 11 may have dependency on 1, 2 and 3 as it is SoC specific.
> 
> Yes, of course, 10, not 11.
> 
>> Then 4, 5 + new patch, re-adding 30-bit formats to IT6263 binding.

I think it would be good to directly support 30-bit formats in
IT6263 DT binding, not re-add them to it.  This way, we'll have one
version of the binding, not two.  So, a better first set would
contain patch 6, 7(one existing A-b from Krzysztof), 8, 9, 10, 12
and 13. 

-- 
Regards,
Liu Ying

Re: [PATCH v4 08/13] dt-bindings: display: Document dual-link LVDS display common properties

[Liu Ying]

On 10/28/2024, Liu Ying wrote:
> Dual-link LVDS displays receive odd pixels and even pixels separately from
> dual LVDS links.  One link receives odd pixels and the other receives even
> pixels.  Some of those displays may also use only one LVDS link to receive
> all pixels, being odd and even agnostic.  Document common properties for
> those displays by extending LVDS display common properties defined in
> lvds.yaml.
> 
> Suggested-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> Signed-off-by: Liu Ying <victor.liu@nxp.com>
> ---
> v4:
> * Squash change for advantech,idk-2121wr.yaml and
>   panel-simple-lvds-dual-ports.yaml with lvds-dual-ports.yaml.  (Rob)
> * Improve description in lvds-dual-ports.yaml.  (Krzysztof)
> 
> v3:
> * New patch.  (Dmitry)
> 
>  .../bindings/display/lvds-dual-ports.yaml     | 76 +++++++++++++++++++
>  .../display/panel/advantech,idk-2121wr.yaml   | 14 +---
>  .../panel/panel-simple-lvds-dual-ports.yaml   | 20 +----
>  3 files changed, 78 insertions(+), 32 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/display/lvds-dual-ports.yaml
> 
> diff --git a/Documentation/devicetree/bindings/display/lvds-dual-ports.yaml b/Documentation/devicetree/bindings/display/lvds-dual-ports.yaml
> new file mode 100644
> index 000000000000..5f7a30640404
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/lvds-dual-ports.yaml
> @@ -0,0 +1,76 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/lvds-dual-ports.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Dual-link LVDS Display Common Properties
> +
> +maintainers:
> +  - Liu Ying <victor.liu@nxp.com>
> +
> +description: |
> +  Common properties for LVDS displays with dual LVDS links. Extend LVDS display
> +  common properties defined in lvds.yaml.
> +
> +  Dual-link LVDS displays receive odd pixels and even pixels separately from
> +  the dual LVDS links. One link receives odd pixels and the other receives
> +  even pixels. Some of those displays may also use only one LVDS link to
> +  receive all pixels, being odd and even agnostic.
> +
> +allOf:
> +  - $ref: lvds.yaml#
> +
> +properties:
> +  ports:
> +    $ref: /schemas/graph.yaml#/properties/ports
> +
> +    properties:
> +      port@0:
> +        $ref: /schemas/graph.yaml#/$defs/port-base
> +        unevaluatedProperties: false
> +        description: the first LVDS input link
> +
> +        properties:
> +          dual-lvds-odd-pixels:
> +            type: boolean
> +            description: the first LVDS input link for odd pixels
> +
> +          dual-lvds-even-pixels:
> +            type: boolean
> +            description: the first LVDS input link for even pixels
> +
> +        oneOf:
> +          - required: [dual-lvds-odd-pixels]
> +          - required: [dual-lvds-even-pixels]
> +          - properties:
> +              dual-lvds-odd-pixels: false
> +              dual-lvds-even-pixels: false
> +
> +      port@1:
> +        $ref: /schemas/graph.yaml#/$defs/port-base
> +        unevaluatedProperties: false
> +        description: the second LVDS input link
> +
> +        properties:
> +          dual-lvds-odd-pixels:
> +            type: boolean
> +            description: the second LVDS input link for odd pixels
> +
> +          dual-lvds-even-pixels:
> +            type: boolean
> +            description: the second LVDS input link for even pixels
> +
> +        oneOf:
> +          - required: [dual-lvds-odd-pixels]
> +          - required: [dual-lvds-even-pixels]
> +          - properties:
> +              dual-lvds-odd-pixels: false
> +              dual-lvds-even-pixels: false

Hmm, I should require port@0 or port@1.
Will wait a while for comments and add this in next version.

--8<--
    anyOf:                                                                      
      - required:                                                               
          - port@0                                                              
      - required:                                                               
          - port@1
--8<--

> +
> +required:
> +  - ports
> +
> +additionalProperties: true
> +
> +...

[...]

-- 
Regards,
Liu Ying

RE: [PATCH v4 08/13] dt-bindings: display: Document dual-link LVDS display common properties

[Biju Das]

Hi Liu Ying,

> -----Original Message-----
> From: Liu Ying <victor.liu@nxp.com>
> Sent: 29 October 2024 06:17
> Subject: Re: [PATCH v4 08/13] dt-bindings: display: Document dual-link LVDS display common properties
> 
> On 10/28/2024, Liu Ying wrote:
> > Dual-link LVDS displays receive odd pixels and even pixels separately
> > from dual LVDS links.  One link receives odd pixels and the other
> > receives even pixels.  Some of those displays may also use only one
> > LVDS link to receive all pixels, being odd and even agnostic.
> > Document common properties for those displays by extending LVDS
> > display common properties defined in lvds.yaml.
> >
> > Suggested-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> > Signed-off-by: Liu Ying <victor.liu@nxp.com>
> > ---
> > v4:
> > * Squash change for advantech,idk-2121wr.yaml and
> >   panel-simple-lvds-dual-ports.yaml with lvds-dual-ports.yaml.  (Rob)
> > * Improve description in lvds-dual-ports.yaml.  (Krzysztof)
> >
> > v3:
> > * New patch.  (Dmitry)
> >
> >  .../bindings/display/lvds-dual-ports.yaml     | 76 +++++++++++++++++++
> >  .../display/panel/advantech,idk-2121wr.yaml   | 14 +---
> >  .../panel/panel-simple-lvds-dual-ports.yaml   | 20 +----
> >  3 files changed, 78 insertions(+), 32 deletions(-)  create mode
> > 100644 Documentation/devicetree/bindings/display/lvds-dual-ports.yaml
> >
> > diff --git
> > a/Documentation/devicetree/bindings/display/lvds-dual-ports.yaml
> > b/Documentation/devicetree/bindings/display/lvds-dual-ports.yaml
> > new file mode 100644
> > index 000000000000..5f7a30640404
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/lvds-dual-ports.yaml
> > @@ -0,0 +1,76 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/display/lvds-dual-ports.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Dual-link LVDS Display Common Properties
> > +
> > +maintainers:
> > +  - Liu Ying <victor.liu@nxp.com>
> > +
> > +description: |
> > +  Common properties for LVDS displays with dual LVDS links. Extend
> > +LVDS display
> > +  common properties defined in lvds.yaml.
> > +
> > +  Dual-link LVDS displays receive odd pixels and even pixels
> > + separately from  the dual LVDS links. One link receives odd pixels
> > + and the other receives  even pixels. Some of those displays may also
> > + use only one LVDS link to  receive all pixels, being odd and even agnostic.
> > +
> > +allOf:
> > +  - $ref: lvds.yaml#
> > +
> > +properties:
> > +  ports:
> > +    $ref: /schemas/graph.yaml#/properties/ports
> > +
> > +    properties:
> > +      port@0:
> > +        $ref: /schemas/graph.yaml#/$defs/port-base
> > +        unevaluatedProperties: false
> > +        description: the first LVDS input link
> > +
> > +        properties:
> > +          dual-lvds-odd-pixels:
> > +            type: boolean
> > +            description: the first LVDS input link for odd pixels
> > +
> > +          dual-lvds-even-pixels:
> > +            type: boolean
> > +            description: the first LVDS input link for even pixels
> > +
> > +        oneOf:
> > +          - required: [dual-lvds-odd-pixels]
> > +          - required: [dual-lvds-even-pixels]
> > +          - properties:
> > +              dual-lvds-odd-pixels: false
> > +              dual-lvds-even-pixels: false
> > +
> > +      port@1:
> > +        $ref: /schemas/graph.yaml#/$defs/port-base
> > +        unevaluatedProperties: false
> > +        description: the second LVDS input link
> > +
> > +        properties:
> > +          dual-lvds-odd-pixels:
> > +            type: boolean
> > +            description: the second LVDS input link for odd pixels
> > +
> > +          dual-lvds-even-pixels:
> > +            type: boolean
> > +            description: the second LVDS input link for even pixels
> > +
> > +        oneOf:
> > +          - required: [dual-lvds-odd-pixels]
> > +          - required: [dual-lvds-even-pixels]
> > +          - properties:
> > +              dual-lvds-odd-pixels: false
> > +              dual-lvds-even-pixels: false
> 
> Hmm, I should require port@0 or port@1.

For dual LVDS, you need 3 ports as common use case

2 input ports and 1 outport and all are required properties.

Cheers,
Biju

> Will wait a while for comments and add this in next version.
> 
> --8<--
>     anyOf:
>       - required:
>           - port@0
>       - required:
>           - port@1
> --8<--
> 
> > +
> > +required:
> > +  - ports
> > +
> > +additionalProperties: true
> > +
> > +...
> 
> [...]
> 
> --
> Regards,
> Liu Ying

Re: [PATCH v4 08/13] dt-bindings: display: Document dual-link LVDS display common properties

[Liu Ying]

On 10/29/2024, Biju Das wrote:
> Hi Liu Ying,

Hi Biju,

> 
>> -----Original Message-----
>> From: Liu Ying <victor.liu@nxp.com>
>> Sent: 29 October 2024 06:17
>> Subject: Re: [PATCH v4 08/13] dt-bindings: display: Document dual-link LVDS display common properties
>>
>> On 10/28/2024, Liu Ying wrote:
>>> Dual-link LVDS displays receive odd pixels and even pixels separately
>>> from dual LVDS links.  One link receives odd pixels and the other
>>> receives even pixels.  Some of those displays may also use only one
>>> LVDS link to receive all pixels, being odd and even agnostic.
>>> Document common properties for those displays by extending LVDS
>>> display common properties defined in lvds.yaml.
>>>
>>> Suggested-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
>>> Signed-off-by: Liu Ying <victor.liu@nxp.com>
>>> ---
>>> v4:
>>> * Squash change for advantech,idk-2121wr.yaml and
>>>   panel-simple-lvds-dual-ports.yaml with lvds-dual-ports.yaml.  (Rob)
>>> * Improve description in lvds-dual-ports.yaml.  (Krzysztof)
>>>
>>> v3:
>>> * New patch.  (Dmitry)
>>>
>>>  .../bindings/display/lvds-dual-ports.yaml     | 76 +++++++++++++++++++
>>>  .../display/panel/advantech,idk-2121wr.yaml   | 14 +---
>>>  .../panel/panel-simple-lvds-dual-ports.yaml   | 20 +----
>>>  3 files changed, 78 insertions(+), 32 deletions(-)  create mode
>>> 100644 Documentation/devicetree/bindings/display/lvds-dual-ports.yaml
>>>
>>> diff --git
>>> a/Documentation/devicetree/bindings/display/lvds-dual-ports.yaml
>>> b/Documentation/devicetree/bindings/display/lvds-dual-ports.yaml
>>> new file mode 100644
>>> index 000000000000..5f7a30640404
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/display/lvds-dual-ports.yaml
>>> @@ -0,0 +1,76 @@
>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2
>>> +---
>>> +$id: http://devicetree.org/schemas/display/lvds-dual-ports.yaml#
>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>> +
>>> +title: Dual-link LVDS Display Common Properties
>>> +
>>> +maintainers:
>>> +  - Liu Ying <victor.liu@nxp.com>
>>> +
>>> +description: |
>>> +  Common properties for LVDS displays with dual LVDS links. Extend
>>> +LVDS display
>>> +  common properties defined in lvds.yaml.
>>> +
>>> +  Dual-link LVDS displays receive odd pixels and even pixels
>>> + separately from  the dual LVDS links. One link receives odd pixels
>>> + and the other receives  even pixels. Some of those displays may also
>>> + use only one LVDS link to  receive all pixels, being odd and even agnostic.
>>> +
>>> +allOf:
>>> +  - $ref: lvds.yaml#
>>> +
>>> +properties:
>>> +  ports:
>>> +    $ref: /schemas/graph.yaml#/properties/ports
>>> +
>>> +    properties:
>>> +      port@0:
>>> +        $ref: /schemas/graph.yaml#/$defs/port-base
>>> +        unevaluatedProperties: false
>>> +        description: the first LVDS input link
>>> +
>>> +        properties:
>>> +          dual-lvds-odd-pixels:
>>> +            type: boolean
>>> +            description: the first LVDS input link for odd pixels
>>> +
>>> +          dual-lvds-even-pixels:
>>> +            type: boolean
>>> +            description: the first LVDS input link for even pixels
>>> +
>>> +        oneOf:
>>> +          - required: [dual-lvds-odd-pixels]
>>> +          - required: [dual-lvds-even-pixels]
>>> +          - properties:
>>> +              dual-lvds-odd-pixels: false
>>> +              dual-lvds-even-pixels: false
>>> +
>>> +      port@1:
>>> +        $ref: /schemas/graph.yaml#/$defs/port-base
>>> +        unevaluatedProperties: false
>>> +        description: the second LVDS input link
>>> +
>>> +        properties:
>>> +          dual-lvds-odd-pixels:
>>> +            type: boolean
>>> +            description: the second LVDS input link for odd pixels
>>> +
>>> +          dual-lvds-even-pixels:
>>> +            type: boolean
>>> +            description: the second LVDS input link for even pixels
>>> +
>>> +        oneOf:
>>> +          - required: [dual-lvds-odd-pixels]
>>> +          - required: [dual-lvds-even-pixels]
>>> +          - properties:
>>> +              dual-lvds-odd-pixels: false
>>> +              dual-lvds-even-pixels: false
>>
>> Hmm, I should require port@0 or port@1.
> 
> For dual LVDS, you need 3 ports as common use case

For LVDS panels, only two ports for LVDS sink are needed.
For display bridges with LVDS sink, one additional output
port is needed.  However, I'm not sure if this output
port should be documented in this binding or not, because
it doesn't look common enough considering the LVDS panels.

> 
> 2 input ports and 1 outport and all are required properties.

The output port cannot be required for LVDS panels at least.

We need to require one or two input ports, because IT6263
may use one LVDS link or two.

> 
> Cheers,
> Biju
> 
>> Will wait a while for comments and add this in next version.
>>
>> --8<--
>>     anyOf:
>>       - required:
>>           - port@0
>>       - required:
>>           - port@1
>> --8<--
>>
>>> +
>>> +required:
>>> +  - ports
>>> +
>>> +additionalProperties: true
>>> +
>>> +...
>>
>> [...]
>>
>> --
>> Regards,
>> Liu Ying
> 

-- 
Regards,
Liu Ying

RE: [PATCH v4 08/13] dt-bindings: display: Document dual-link LVDS display common properties

[Biju Das]

Hi Liu Ying,

> -----Original Message-----
> From: Liu Ying <victor.liu@nxp.com>
> Sent: 29 October 2024 07:13
> Subject: Re: [PATCH v4 08/13] dt-bindings: display: Document dual-link LVDS display common properties
> 
> On 10/29/2024, Biju Das wrote:
> > Hi Liu Ying,
> 
> Hi Biju,
> 
> >
> >> -----Original Message-----
> >> From: Liu Ying <victor.liu@nxp.com>
> >> Sent: 29 October 2024 06:17
> >> Subject: Re: [PATCH v4 08/13] dt-bindings: display: Document
> >> dual-link LVDS display common properties
> >>
> >> On 10/28/2024, Liu Ying wrote:
> >>> Dual-link LVDS displays receive odd pixels and even pixels
> >>> separately from dual LVDS links.  One link receives odd pixels and
> >>> the other receives even pixels.  Some of those displays may also use
> >>> only one LVDS link to receive all pixels, being odd and even agnostic.
> >>> Document common properties for those displays by extending LVDS
> >>> display common properties defined in lvds.yaml.
> >>>
> >>> Suggested-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> >>> Signed-off-by: Liu Ying <victor.liu@nxp.com>
> >>> ---
> >>> v4:
> >>> * Squash change for advantech,idk-2121wr.yaml and
> >>>   panel-simple-lvds-dual-ports.yaml with lvds-dual-ports.yaml.
> >>> (Rob)
> >>> * Improve description in lvds-dual-ports.yaml.  (Krzysztof)
> >>>
> >>> v3:
> >>> * New patch.  (Dmitry)
> >>>
> >>>  .../bindings/display/lvds-dual-ports.yaml     | 76 +++++++++++++++++++
> >>>  .../display/panel/advantech,idk-2121wr.yaml   | 14 +---
> >>>  .../panel/panel-simple-lvds-dual-ports.yaml   | 20 +----
> >>>  3 files changed, 78 insertions(+), 32 deletions(-)  create mode
> >>> 100644
> >>> Documentation/devicetree/bindings/display/lvds-dual-ports.yaml
> >>>
> >>> diff --git
> >>> a/Documentation/devicetree/bindings/display/lvds-dual-ports.yaml
> >>> b/Documentation/devicetree/bindings/display/lvds-dual-ports.yaml
> >>> new file mode 100644
> >>> index 000000000000..5f7a30640404
> >>> --- /dev/null
> >>> +++ b/Documentation/devicetree/bindings/display/lvds-dual-ports.yaml
> >>> @@ -0,0 +1,76 @@
> >>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2
> >>> +---
> >>> +$id: http://devicetree.org/schemas/display/lvds-dual-ports.yaml#
> >>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> >>> +
> >>> +title: Dual-link LVDS Display Common Properties
> >>> +
> >>> +maintainers:
> >>> +  - Liu Ying <victor.liu@nxp.com>
> >>> +
> >>> +description: |
> >>> +  Common properties for LVDS displays with dual LVDS links. Extend
> >>> +LVDS display
> >>> +  common properties defined in lvds.yaml.
> >>> +
> >>> +  Dual-link LVDS displays receive odd pixels and even pixels
> >>> + separately from  the dual LVDS links. One link receives odd pixels
> >>> + and the other receives  even pixels. Some of those displays may
> >>> + also use only one LVDS link to  receive all pixels, being odd and even agnostic.
> >>> +
> >>> +allOf:
> >>> +  - $ref: lvds.yaml#
> >>> +
> >>> +properties:
> >>> +  ports:
> >>> +    $ref: /schemas/graph.yaml#/properties/ports
> >>> +
> >>> +    properties:
> >>> +      port@0:
> >>> +        $ref: /schemas/graph.yaml#/$defs/port-base
> >>> +        unevaluatedProperties: false
> >>> +        description: the first LVDS input link
> >>> +
> >>> +        properties:
> >>> +          dual-lvds-odd-pixels:
> >>> +            type: boolean
> >>> +            description: the first LVDS input link for odd pixels
> >>> +
> >>> +          dual-lvds-even-pixels:
> >>> +            type: boolean
> >>> +            description: the first LVDS input link for even pixels
> >>> +
> >>> +        oneOf:
> >>> +          - required: [dual-lvds-odd-pixels]
> >>> +          - required: [dual-lvds-even-pixels]
> >>> +          - properties:
> >>> +              dual-lvds-odd-pixels: false
> >>> +              dual-lvds-even-pixels: false
> >>> +
> >>> +      port@1:
> >>> +        $ref: /schemas/graph.yaml#/$defs/port-base
> >>> +        unevaluatedProperties: false
> >>> +        description: the second LVDS input link
> >>> +
> >>> +        properties:
> >>> +          dual-lvds-odd-pixels:
> >>> +            type: boolean
> >>> +            description: the second LVDS input link for odd pixels
> >>> +
> >>> +          dual-lvds-even-pixels:
> >>> +            type: boolean
> >>> +            description: the second LVDS input link for even pixels
> >>> +
> >>> +        oneOf:
> >>> +          - required: [dual-lvds-odd-pixels]
> >>> +          - required: [dual-lvds-even-pixels]
> >>> +          - properties:
> >>> +              dual-lvds-odd-pixels: false
> >>> +              dual-lvds-even-pixels: false
> >>
> >> Hmm, I should require port@0 or port@1.
> >
> > For dual LVDS, you need 3 ports as common use case
> 
> For LVDS panels, only two ports for LVDS sink are needed.
> For display bridges with LVDS sink, one additional output port is needed.  However, I'm not sure if
> this output port should be documented in this binding or not, because it doesn't look common enough
> considering the LVDS panels.
> 
> >
> > 2 input ports and 1 outport and all are required properties.
> 
> The output port cannot be required for LVDS panels at least.

Ack.

> 
> We need to require one or two input ports, because IT6263 may use one LVDS link or two.

This patch is for generic dual link common cases and is not applicable for IT6263 single link case.


Cheers,
Biju

> 
> >
> > Cheers,
> > Biju
> >
> >> Will wait a while for comments and add this in next version.
> >>
> >> --8<--
> >>     anyOf:
> >>       - required:
> >>           - port@0
> >>       - required:
> >>           - port@1
> >> --8<--
> >>
> >>> +
> >>> +required:
> >>> +  - ports
> >>> +
> >>> +additionalProperties: true
> >>> +
> >>> +...
> >>
> >> [...]
> >>
> >> --
> >> Regards,
> >> Liu Ying
> >
> 
> --
> Regards,
> Liu Ying

RE: [PATCH v4 08/13] dt-bindings: display: Document dual-link LVDS display common properties

[Biju Das]

Hi Liu Ying,

> -----Original Message-----
> From: Liu Ying <victor.liu@nxp.com>
> Sent: 28 October 2024 02:38
> Subject: [PATCH v4 08/13] dt-bindings: display: Document dual-link LVDS display common properties
> 
> Dual-link LVDS displays receive odd pixels and even pixels separately from dual LVDS links.  One link
> receives odd pixels and the other receives even pixels.  Some of those displays may also use only one
> LVDS link to receive all pixels, being odd and even agnostic.  Document common properties for those
> displays by extending LVDS display common properties defined in lvds.yaml.
> 
> Suggested-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> Signed-off-by: Liu Ying <victor.liu@nxp.com>
> ---
> v4:
> * Squash change for advantech,idk-2121wr.yaml and
>   panel-simple-lvds-dual-ports.yaml with lvds-dual-ports.yaml.  (Rob)
> * Improve description in lvds-dual-ports.yaml.  (Krzysztof)
> 
> v3:
> * New patch.  (Dmitry)
> 
>  .../bindings/display/lvds-dual-ports.yaml     | 76 +++++++++++++++++++
>  .../display/panel/advantech,idk-2121wr.yaml   | 14 +---
>  .../panel/panel-simple-lvds-dual-ports.yaml   | 20 +----
>  3 files changed, 78 insertions(+), 32 deletions(-)  create mode 100644
> Documentation/devicetree/bindings/display/lvds-dual-ports.yaml
> 
> diff --git a/Documentation/devicetree/bindings/display/lvds-dual-ports.yaml
> b/Documentation/devicetree/bindings/display/lvds-dual-ports.yaml
> new file mode 100644
> index 000000000000..5f7a30640404
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/lvds-dual-ports.yaml
> @@ -0,0 +1,76 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/lvds-dual-ports.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Dual-link LVDS Display Common Properties
> +
> +maintainers:
> +  - Liu Ying <victor.liu@nxp.com>
> +
> +description: |
> +  Common properties for LVDS displays with dual LVDS links. Extend LVDS
> +display
> +  common properties defined in lvds.yaml.
> +
> +  Dual-link LVDS displays receive odd pixels and even pixels separately
> + from  the dual LVDS links. One link receives odd pixels and the other
> + receives  even pixels. Some of those displays may also use only one
> + LVDS link to  receive all pixels, being odd and even agnostic.
> +
> +allOf:
> +  - $ref: lvds.yaml#
> +
> +properties:
> +  ports:
> +    $ref: /schemas/graph.yaml#/properties/ports
> +
> +    properties:
> +      port@0:
> +        $ref: /schemas/graph.yaml#/$defs/port-base
> +        unevaluatedProperties: false
> +        description: the first LVDS input link
> +
> +        properties:
> +          dual-lvds-odd-pixels:
> +            type: boolean
> +            description: the first LVDS input link for odd pixels
> +
> +          dual-lvds-even-pixels:
> +            type: boolean
> +            description: the first LVDS input link for even pixels


port@0 we know it is first link
port@1 we know it is second link.
dual-lvds-odd-pixels: We know it is for odd pixels.
dual-lvds-even-pixels: We know it is for odd pixels.

Not sure, whether we can give common description and avoid the duplicate
from port@1 ??


> +
> +        oneOf:
> +          - required: [dual-lvds-odd-pixels]
> +          - required: [dual-lvds-even-pixels]
> +          - properties:
> +              dual-lvds-odd-pixels: false
> +              dual-lvds-even-pixels: false

Why this is false here? oneOf is not sufficient?

> +
> +      port@1:
> +        $ref: /schemas/graph.yaml#/$defs/port-base
> +        unevaluatedProperties: false
> +        description: the second LVDS input link
> +
> +        properties:
> +          dual-lvds-odd-pixels:
> +            type: boolean
> +            description: the second LVDS input link for odd pixels
> +
> +          dual-lvds-even-pixels:
> +            type: boolean
> +            description: the second LVDS input link for even pixels
> +
> +        oneOf:
> +          - required: [dual-lvds-odd-pixels]
> +          - required: [dual-lvds-even-pixels]
> +          - properties:
> +              dual-lvds-odd-pixels: false
> +              dual-lvds-even-pixels: false

Same as above??

Cheers,
Biju

> +
> +required:
> +  - ports
> +
> +additionalProperties: true
> +
> +...
> diff --git a/Documentation/devicetree/bindings/display/panel/advantech,idk-2121wr.yaml
> b/Documentation/devicetree/bindings/display/panel/advantech,idk-2121wr.yaml
> index 2e8dbdb5a3d5..05ca3b2385f8 100644
> --- a/Documentation/devicetree/bindings/display/panel/advantech,idk-2121wr.yaml
> +++ b/Documentation/devicetree/bindings/display/panel/advantech,idk-2121
> +++ wr.yaml
> @@ -20,6 +20,7 @@ description: |
>    dual-lvds-odd-pixels or dual-lvds-even-pixels).
> 
>  allOf:
> +  - $ref: /schemas/display/lvds-dual-ports.yaml#
>    - $ref: panel-common.yaml#
> 
>  properties:
> @@ -44,22 +45,10 @@ properties:
> 
>      properties:
>        port@0:
> -        $ref: /schemas/graph.yaml#/$defs/port-base
> -        unevaluatedProperties: false
> -        description: The sink for odd pixels.
> -        properties:
> -          dual-lvds-odd-pixels: true
> -
>          required:
>            - dual-lvds-odd-pixels
> 
>        port@1:
> -        $ref: /schemas/graph.yaml#/$defs/port-base
> -        unevaluatedProperties: false
> -        description: The sink for even pixels.
> -        properties:
> -          dual-lvds-even-pixels: true
> -
>          required:
>            - dual-lvds-even-pixels
> 
> @@ -75,7 +64,6 @@ required:
>    - height-mm
>    - data-mapping
>    - panel-timing
> -  - ports
> 
>  examples:
>    - |+
> diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple-lvds-dual-ports.yaml
> b/Documentation/devicetree/bindings/display/panel/panel-simple-lvds-dual-ports.yaml
> index 10ed4b57232b..e80fc7006984 100644
> --- a/Documentation/devicetree/bindings/display/panel/panel-simple-lvds-dual-ports.yaml
> +++ b/Documentation/devicetree/bindings/display/panel/panel-simple-lvds-
> +++ dual-ports.yaml
> @@ -22,6 +22,7 @@ description: |
>    If the panel is more advanced a dedicated binding file is required.
> 
>  allOf:
> +  - $ref: /schemas/display/lvds-dual-ports.yaml#
>    - $ref: panel-common.yaml#
> 
>  properties:
> @@ -55,28 +56,10 @@ properties:
> 
>      properties:
>        port@0:
> -        $ref: /schemas/graph.yaml#/$defs/port-base
> -        unevaluatedProperties: false
> -        description: The first sink port.
> -
> -        properties:
> -          dual-lvds-odd-pixels:
> -            type: boolean
> -            description: The first sink port for odd pixels.
> -
>          required:
>            - dual-lvds-odd-pixels
> 
>        port@1:
> -        $ref: /schemas/graph.yaml#/$defs/port-base
> -        unevaluatedProperties: false
> -        description: The second sink port.
> -
> -        properties:
> -          dual-lvds-even-pixels:
> -            type: boolean
> -            description: The second sink port for even pixels.
> -
>          required:
>            - dual-lvds-even-pixels
> 
> @@ -88,7 +71,6 @@ unevaluatedProperties: false
> 
>  required:
>    - compatible
> -  - ports
>    - power-supply
> 
>  examples:
> --
> 2.34.1

Re: [PATCH v4 08/13] dt-bindings: display: Document dual-link LVDS display common properties

[Liu Ying]

On 10/29/2024, Biju Das wrote:
> Hi Liu Ying,

Hi Biju,

> 
>> -----Original Message-----
>> From: Liu Ying <victor.liu@nxp.com>
>> Sent: 29 October 2024 07:13
>> Subject: Re: [PATCH v4 08/13] dt-bindings: display: Document dual-link LVDS display common properties
>>
>> On 10/29/2024, Biju Das wrote:
>>> Hi Liu Ying,
>>
>> Hi Biju,
>>
>>>
>>>> -----Original Message-----
>>>> From: Liu Ying <victor.liu@nxp.com>
>>>> Sent: 29 October 2024 06:17
>>>> Subject: Re: [PATCH v4 08/13] dt-bindings: display: Document
>>>> dual-link LVDS display common properties
>>>>
>>>> On 10/28/2024, Liu Ying wrote:
>>>>> Dual-link LVDS displays receive odd pixels and even pixels
>>>>> separately from dual LVDS links.  One link receives odd pixels and
>>>>> the other receives even pixels.  Some of those displays may also use
>>>>> only one LVDS link to receive all pixels, being odd and even agnostic.
>>>>> Document common properties for those displays by extending LVDS
>>>>> display common properties defined in lvds.yaml.
>>>>>
>>>>> Suggested-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
>>>>> Signed-off-by: Liu Ying <victor.liu@nxp.com>
>>>>> ---
>>>>> v4:
>>>>> * Squash change for advantech,idk-2121wr.yaml and
>>>>>   panel-simple-lvds-dual-ports.yaml with lvds-dual-ports.yaml.
>>>>> (Rob)
>>>>> * Improve description in lvds-dual-ports.yaml.  (Krzysztof)
>>>>>
>>>>> v3:
>>>>> * New patch.  (Dmitry)
>>>>>
>>>>>  .../bindings/display/lvds-dual-ports.yaml     | 76 +++++++++++++++++++
>>>>>  .../display/panel/advantech,idk-2121wr.yaml   | 14 +---
>>>>>  .../panel/panel-simple-lvds-dual-ports.yaml   | 20 +----
>>>>>  3 files changed, 78 insertions(+), 32 deletions(-)  create mode
>>>>> 100644
>>>>> Documentation/devicetree/bindings/display/lvds-dual-ports.yaml
>>>>>
>>>>> diff --git
>>>>> a/Documentation/devicetree/bindings/display/lvds-dual-ports.yaml
>>>>> b/Documentation/devicetree/bindings/display/lvds-dual-ports.yaml
>>>>> new file mode 100644
>>>>> index 000000000000..5f7a30640404
>>>>> --- /dev/null
>>>>> +++ b/Documentation/devicetree/bindings/display/lvds-dual-ports.yaml
>>>>> @@ -0,0 +1,76 @@
>>>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2
>>>>> +---
>>>>> +$id: http://devicetree.org/schemas/display/lvds-dual-ports.yaml#
>>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>>>> +
>>>>> +title: Dual-link LVDS Display Common Properties
>>>>> +
>>>>> +maintainers:
>>>>> +  - Liu Ying <victor.liu@nxp.com>
>>>>> +
>>>>> +description: |
>>>>> +  Common properties for LVDS displays with dual LVDS links. Extend
>>>>> +LVDS display
>>>>> +  common properties defined in lvds.yaml.
>>>>> +
>>>>> +  Dual-link LVDS displays receive odd pixels and even pixels
>>>>> + separately from  the dual LVDS links. One link receives odd pixels
>>>>> + and the other receives  even pixels. Some of those displays may
>>>>> + also use only one LVDS link to  receive all pixels, being odd and even agnostic.
>>>>> +
>>>>> +allOf:
>>>>> +  - $ref: lvds.yaml#
>>>>> +
>>>>> +properties:
>>>>> +  ports:
>>>>> +    $ref: /schemas/graph.yaml#/properties/ports
>>>>> +
>>>>> +    properties:
>>>>> +      port@0:
>>>>> +        $ref: /schemas/graph.yaml#/$defs/port-base
>>>>> +        unevaluatedProperties: false
>>>>> +        description: the first LVDS input link
>>>>> +
>>>>> +        properties:
>>>>> +          dual-lvds-odd-pixels:
>>>>> +            type: boolean
>>>>> +            description: the first LVDS input link for odd pixels
>>>>> +
>>>>> +          dual-lvds-even-pixels:
>>>>> +            type: boolean
>>>>> +            description: the first LVDS input link for even pixels
>>>>> +
>>>>> +        oneOf:
>>>>> +          - required: [dual-lvds-odd-pixels]
>>>>> +          - required: [dual-lvds-even-pixels]
>>>>> +          - properties:
>>>>> +              dual-lvds-odd-pixels: false
>>>>> +              dual-lvds-even-pixels: false
>>>>> +
>>>>> +      port@1:
>>>>> +        $ref: /schemas/graph.yaml#/$defs/port-base
>>>>> +        unevaluatedProperties: false
>>>>> +        description: the second LVDS input link
>>>>> +
>>>>> +        properties:
>>>>> +          dual-lvds-odd-pixels:
>>>>> +            type: boolean
>>>>> +            description: the second LVDS input link for odd pixels
>>>>> +
>>>>> +          dual-lvds-even-pixels:
>>>>> +            type: boolean
>>>>> +            description: the second LVDS input link for even pixels
>>>>> +
>>>>> +        oneOf:
>>>>> +          - required: [dual-lvds-odd-pixels]
>>>>> +          - required: [dual-lvds-even-pixels]
>>>>> +          - properties:
>>>>> +              dual-lvds-odd-pixels: false
>>>>> +              dual-lvds-even-pixels: false
>>>>
>>>> Hmm, I should require port@0 or port@1.
>>>
>>> For dual LVDS, you need 3 ports as common use case
>>
>> For LVDS panels, only two ports for LVDS sink are needed.
>> For display bridges with LVDS sink, one additional output port is needed.  However, I'm not sure if
>> this output port should be documented in this binding or not, because it doesn't look common enough
>> considering the LVDS panels.
>>
>>>
>>> 2 input ports and 1 outport and all are required properties.
>>
>> The output port cannot be required for LVDS panels at least.
> 
> Ack.
> 
>>
>> We need to require one or two input ports, because IT6263 may use one LVDS link or two.
> 
> This patch is for generic dual link common cases and is not applicable for IT6263 single link case.

Based on previous discussion(especially Dmitry's suggestion),
this binding should cover display bridges that can use one
LVDS sink port or two LVDS sink ports, like IT6263.  To be
clear, those bridges may have two modes(supported by one
chip) - single LVDS sink link mode and dual LVDS sink link
mode.  Those bridges are considered as common dual-link
LVDS displays.  That's why I was asked to extract the common
properties to this schema when adding IT6263 DT binding.   

> 
> 
> Cheers,
> Biju
> 
>>
>>>
>>> Cheers,
>>> Biju
>>>
>>>> Will wait a while for comments and add this in next version.
>>>>
>>>> --8<--
>>>>     anyOf:
>>>>       - required:
>>>>           - port@0
>>>>       - required:
>>>>           - port@1
>>>> --8<--
>>>>
>>>>> +
>>>>> +required:
>>>>> +  - ports
>>>>> +
>>>>> +additionalProperties: true
>>>>> +
>>>>> +...
>>>>
>>>> [...]
>>>>
>>>> --
>>>> Regards,
>>>> Liu Ying
>>>
>>
>> --
>> Regards,
>> Liu Ying
> 

-- 
Regards,
Liu Ying

RE: [PATCH v4 08/13] dt-bindings: display: Document dual-link LVDS display common properties

[Biju Das]

Hi Liu Ying,

> -----Original Message-----
> From: dri-devel <dri-devel-bounces@lists.freedesktop.org> On Behalf Of Liu Ying
> Sent: 29 October 2024 07:35
> Subject: Re: [PATCH v4 08/13] dt-bindings: display: Document dual-link LVDS display common properties
> 
> On 10/29/2024, Biju Das wrote:
> > Hi Liu Ying,
> 
> Hi Biju,
> 
> >
> >> -----Original Message-----
> >> From: Liu Ying <victor.liu@nxp.com>
> >> Sent: 29 October 2024 07:13
> >> Subject: Re: [PATCH v4 08/13] dt-bindings: display: Document
> >> dual-link LVDS display common properties
> >>
> >> On 10/29/2024, Biju Das wrote:
> >>> Hi Liu Ying,
> >>
> >> Hi Biju,
> >>
> >>>
> >>>> -----Original Message-----
> >>>> From: Liu Ying <victor.liu@nxp.com>
> >>>> Sent: 29 October 2024 06:17
> >>>> Subject: Re: [PATCH v4 08/13] dt-bindings: display: Document
> >>>> dual-link LVDS display common properties
> >>>>
> >>>> On 10/28/2024, Liu Ying wrote:
> >>>>> Dual-link LVDS displays receive odd pixels and even pixels
> >>>>> separately from dual LVDS links.  One link receives odd pixels and
> >>>>> the other receives even pixels.  Some of those displays may also
> >>>>> use only one LVDS link to receive all pixels, being odd and even agnostic.
> >>>>> Document common properties for those displays by extending LVDS
> >>>>> display common properties defined in lvds.yaml.
> >>>>>
> >>>>> Suggested-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> >>>>> Signed-off-by: Liu Ying <victor.liu@nxp.com>
> >>>>> ---
> >>>>> v4:
> >>>>> * Squash change for advantech,idk-2121wr.yaml and
> >>>>>   panel-simple-lvds-dual-ports.yaml with lvds-dual-ports.yaml.
> >>>>> (Rob)
> >>>>> * Improve description in lvds-dual-ports.yaml.  (Krzysztof)
> >>>>>
> >>>>> v3:
> >>>>> * New patch.  (Dmitry)
> >>>>>
> >>>>>  .../bindings/display/lvds-dual-ports.yaml     | 76 +++++++++++++++++++
> >>>>>  .../display/panel/advantech,idk-2121wr.yaml   | 14 +---
> >>>>>  .../panel/panel-simple-lvds-dual-ports.yaml   | 20 +----
> >>>>>  3 files changed, 78 insertions(+), 32 deletions(-)  create mode
> >>>>> 100644
> >>>>> Documentation/devicetree/bindings/display/lvds-dual-ports.yaml
> >>>>>
> >>>>> diff --git
> >>>>> a/Documentation/devicetree/bindings/display/lvds-dual-ports.yaml
> >>>>> b/Documentation/devicetree/bindings/display/lvds-dual-ports.yaml
> >>>>> new file mode 100644
> >>>>> index 000000000000..5f7a30640404
> >>>>> --- /dev/null
> >>>>> +++ b/Documentation/devicetree/bindings/display/lvds-dual-ports.ya
> >>>>> +++ ml
> >>>>> @@ -0,0 +1,76 @@
> >>>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML
> >>>>> +1.2
> >>>>> +---
> >>>>> +$id: http://devicetree.org/schemas/display/lvds-dual-ports.yaml#
> >>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> >>>>> +
> >>>>> +title: Dual-link LVDS Display Common Properties
> >>>>> +
> >>>>> +maintainers:
> >>>>> +  - Liu Ying <victor.liu@nxp.com>
> >>>>> +
> >>>>> +description: |
> >>>>> +  Common properties for LVDS displays with dual LVDS links.
> >>>>> +Extend LVDS display
> >>>>> +  common properties defined in lvds.yaml.
> >>>>> +
> >>>>> +  Dual-link LVDS displays receive odd pixels and even pixels
> >>>>> + separately from  the dual LVDS links. One link receives odd
> >>>>> + pixels and the other receives  even pixels. Some of those
> >>>>> + displays may also use only one LVDS link to  receive all pixels, being odd and even agnostic.
> >>>>> +
> >>>>> +allOf:
> >>>>> +  - $ref: lvds.yaml#
> >>>>> +
> >>>>> +properties:
> >>>>> +  ports:
> >>>>> +    $ref: /schemas/graph.yaml#/properties/ports
> >>>>> +
> >>>>> +    properties:
> >>>>> +      port@0:
> >>>>> +        $ref: /schemas/graph.yaml#/$defs/port-base
> >>>>> +        unevaluatedProperties: false
> >>>>> +        description: the first LVDS input link
> >>>>> +
> >>>>> +        properties:
> >>>>> +          dual-lvds-odd-pixels:
> >>>>> +            type: boolean
> >>>>> +            description: the first LVDS input link for odd pixels
> >>>>> +
> >>>>> +          dual-lvds-even-pixels:
> >>>>> +            type: boolean
> >>>>> +            description: the first LVDS input link for even
> >>>>> + pixels
> >>>>> +
> >>>>> +        oneOf:
> >>>>> +          - required: [dual-lvds-odd-pixels]
> >>>>> +          - required: [dual-lvds-even-pixels]
> >>>>> +          - properties:
> >>>>> +              dual-lvds-odd-pixels: false
> >>>>> +              dual-lvds-even-pixels: false
> >>>>> +
> >>>>> +      port@1:
> >>>>> +        $ref: /schemas/graph.yaml#/$defs/port-base
> >>>>> +        unevaluatedProperties: false
> >>>>> +        description: the second LVDS input link
> >>>>> +
> >>>>> +        properties:
> >>>>> +          dual-lvds-odd-pixels:
> >>>>> +            type: boolean
> >>>>> +            description: the second LVDS input link for odd
> >>>>> + pixels
> >>>>> +
> >>>>> +          dual-lvds-even-pixels:
> >>>>> +            type: boolean
> >>>>> +            description: the second LVDS input link for even
> >>>>> + pixels
> >>>>> +
> >>>>> +        oneOf:
> >>>>> +          - required: [dual-lvds-odd-pixels]
> >>>>> +          - required: [dual-lvds-even-pixels]
> >>>>> +          - properties:
> >>>>> +              dual-lvds-odd-pixels: false
> >>>>> +              dual-lvds-even-pixels: false
> >>>>
> >>>> Hmm, I should require port@0 or port@1.
> >>>
> >>> For dual LVDS, you need 3 ports as common use case
> >>
> >> For LVDS panels, only two ports for LVDS sink are needed.
> >> For display bridges with LVDS sink, one additional output port is
> >> needed.  However, I'm not sure if this output port should be
> >> documented in this binding or not, because it doesn't look common enough considering the LVDS
> panels.
> >>
> >>>
> >>> 2 input ports and 1 outport and all are required properties.
> >>
> >> The output port cannot be required for LVDS panels at least.
> >
> > Ack.
> >
> >>
> >> We need to require one or two input ports, because IT6263 may use one LVDS link or two.
> >
> > This patch is for generic dual link common cases and is not applicable for IT6263 single link case.
> 
> Based on previous discussion(especially Dmitry's suggestion), this binding should cover display
> bridges that can use one LVDS sink port or two LVDS sink ports, like IT6263.  To be clear, those
> bridges may have two modes(supported by one
> chip) - single LVDS sink link mode and dual LVDS sink link mode.  Those bridges are considered as
> common dual-link LVDS displays.  That's why I was asked to extract the common
> properties to this schema when adding IT6263 DT binding.

As per [1] and [2] both panels don’t support single LVDS link.
IT6263 is bridge device that has single and dual link support.
Not sure the single link case has to be taken care in ITE6263 binding itself,
Leaving Dual link as it is??

[1]
https://elixir.bootlin.com/linux/v6.12-rc5/source/Documentation/devicetree/bindings/display/panel/advantech,idk-2121wr.yaml
[2]

https://elixir.bootlin.com/linux/v6.12-rc5/source/Documentation/devicetree/bindings/display/panel/panel-simple-lvds-dual-ports.yaml


Cheers,
Biju

Re: [PATCH v4 08/13] dt-bindings: display: Document dual-link LVDS display common properties

[Liu Ying]

On 10/29/2024, Biju Das wrote:
> Hi Liu Ying,

Hi Biju,

> 
>> -----Original Message-----
>> From: Liu Ying <victor.liu@nxp.com>
>> Sent: 28 October 2024 02:38
>> Subject: [PATCH v4 08/13] dt-bindings: display: Document dual-link LVDS display common properties
>>
>> Dual-link LVDS displays receive odd pixels and even pixels separately from dual LVDS links.  One link
>> receives odd pixels and the other receives even pixels.  Some of those displays may also use only one
>> LVDS link to receive all pixels, being odd and even agnostic.  Document common properties for those
>> displays by extending LVDS display common properties defined in lvds.yaml.
>>
>> Suggested-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
>> Signed-off-by: Liu Ying <victor.liu@nxp.com>
>> ---
>> v4:
>> * Squash change for advantech,idk-2121wr.yaml and
>>   panel-simple-lvds-dual-ports.yaml with lvds-dual-ports.yaml.  (Rob)
>> * Improve description in lvds-dual-ports.yaml.  (Krzysztof)
>>
>> v3:
>> * New patch.  (Dmitry)
>>
>>  .../bindings/display/lvds-dual-ports.yaml     | 76 +++++++++++++++++++
>>  .../display/panel/advantech,idk-2121wr.yaml   | 14 +---
>>  .../panel/panel-simple-lvds-dual-ports.yaml   | 20 +----
>>  3 files changed, 78 insertions(+), 32 deletions(-)  create mode 100644
>> Documentation/devicetree/bindings/display/lvds-dual-ports.yaml
>>
>> diff --git a/Documentation/devicetree/bindings/display/lvds-dual-ports.yaml
>> b/Documentation/devicetree/bindings/display/lvds-dual-ports.yaml
>> new file mode 100644
>> index 000000000000..5f7a30640404
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/display/lvds-dual-ports.yaml
>> @@ -0,0 +1,76 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/display/lvds-dual-ports.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Dual-link LVDS Display Common Properties
>> +
>> +maintainers:
>> +  - Liu Ying <victor.liu@nxp.com>
>> +
>> +description: |
>> +  Common properties for LVDS displays with dual LVDS links. Extend LVDS
>> +display
>> +  common properties defined in lvds.yaml.
>> +
>> +  Dual-link LVDS displays receive odd pixels and even pixels separately
>> + from  the dual LVDS links. One link receives odd pixels and the other
>> + receives  even pixels. Some of those displays may also use only one
>> + LVDS link to  receive all pixels, being odd and even agnostic.
>> +
>> +allOf:
>> +  - $ref: lvds.yaml#
>> +
>> +properties:
>> +  ports:
>> +    $ref: /schemas/graph.yaml#/properties/ports
>> +
>> +    properties:
>> +      port@0:
>> +        $ref: /schemas/graph.yaml#/$defs/port-base
>> +        unevaluatedProperties: false
>> +        description: the first LVDS input link
>> +
>> +        properties:
>> +          dual-lvds-odd-pixels:
>> +            type: boolean
>> +            description: the first LVDS input link for odd pixels
>> +
>> +          dual-lvds-even-pixels:
>> +            type: boolean
>> +            description: the first LVDS input link for even pixels
> 
> 
> port@0 we know it is first link
> port@1 we know it is second link.
> dual-lvds-odd-pixels: We know it is for odd pixels.
> dual-lvds-even-pixels: We know it is for odd pixels.
> 
> Not sure, whether we can give common description and avoid the duplicate
> from port@1 ??

Yes, it'd better to use patternProperties. Thanks.

--8<--
    patternProperties:                                                           
      '^port@[01]$':                                                             
        $ref: /schemas/graph.yaml#/$defs/port-base                               
        unevaluatedProperties: false                                             
        description: |                                                           
          port@0 is for the first LVDS input link.                               
          port@1 is for the second LVDS input link.                              
                                                                                 
        properties:                                                              
          dual-lvds-odd-pixels:                                                  
            type: boolean                                                        
            description: LVDS input link for odd pixels                          
                                                                                 
          dual-lvds-even-pixels:                                                 
            type: boolean                                                        
            description: LVDS input link for even pixels                         
                                                                                 
        oneOf:                                                                   
          - required: [dual-lvds-odd-pixels]                                     
          - required: [dual-lvds-even-pixels]                                    
          - properties:                                                          
              dual-lvds-odd-pixels: false                                        
              dual-lvds-even-pixels: false                                       
                                                                                 
    anyOf:                                                                       
      - required:                                                                
          - port@0                                                               
      - required:                                                                
          - port@1
--8<--

> 
> 
>> +
>> +        oneOf:
>> +          - required: [dual-lvds-odd-pixels]
>> +          - required: [dual-lvds-even-pixels]
>> +          - properties:
>> +              dual-lvds-odd-pixels: false
>> +              dual-lvds-even-pixels: false
> 
> Why this is false here? oneOf is not sufficient?

The 'false' is used when this LVDS link works alone
as a single LVDS link, being odd and even agnostic.

The 'oneOf' allows a LVDS link to be defined as a single
LVDS link or one link of dual LVDS links.

> 
>> +
>> +      port@1:
>> +        $ref: /schemas/graph.yaml#/$defs/port-base
>> +        unevaluatedProperties: false
>> +        description: the second LVDS input link
>> +
>> +        properties:
>> +          dual-lvds-odd-pixels:
>> +            type: boolean
>> +            description: the second LVDS input link for odd pixels
>> +
>> +          dual-lvds-even-pixels:
>> +            type: boolean
>> +            description: the second LVDS input link for even pixels
>> +
>> +        oneOf:
>> +          - required: [dual-lvds-odd-pixels]
>> +          - required: [dual-lvds-even-pixels]
>> +          - properties:
>> +              dual-lvds-odd-pixels: false
>> +              dual-lvds-even-pixels: false
> 
> Same as above??
> 
> Cheers,
> Biju
> 
>> +
>> +required:
>> +  - ports
>> +
>> +additionalProperties: true
>> +
>> +...
>> diff --git a/Documentation/devicetree/bindings/display/panel/advantech,idk-2121wr.yaml
>> b/Documentation/devicetree/bindings/display/panel/advantech,idk-2121wr.yaml
>> index 2e8dbdb5a3d5..05ca3b2385f8 100644
>> --- a/Documentation/devicetree/bindings/display/panel/advantech,idk-2121wr.yaml
>> +++ b/Documentation/devicetree/bindings/display/panel/advantech,idk-2121
>> +++ wr.yaml
>> @@ -20,6 +20,7 @@ description: |
>>    dual-lvds-odd-pixels or dual-lvds-even-pixels).
>>
>>  allOf:
>> +  - $ref: /schemas/display/lvds-dual-ports.yaml#
>>    - $ref: panel-common.yaml#
>>
>>  properties:
>> @@ -44,22 +45,10 @@ properties:
>>
>>      properties:
>>        port@0:
>> -        $ref: /schemas/graph.yaml#/$defs/port-base
>> -        unevaluatedProperties: false
>> -        description: The sink for odd pixels.
>> -        properties:
>> -          dual-lvds-odd-pixels: true
>> -
>>          required:
>>            - dual-lvds-odd-pixels
>>
>>        port@1:
>> -        $ref: /schemas/graph.yaml#/$defs/port-base
>> -        unevaluatedProperties: false
>> -        description: The sink for even pixels.
>> -        properties:
>> -          dual-lvds-even-pixels: true
>> -
>>          required:
>>            - dual-lvds-even-pixels
>>
>> @@ -75,7 +64,6 @@ required:
>>    - height-mm
>>    - data-mapping
>>    - panel-timing
>> -  - ports
>>
>>  examples:
>>    - |+
>> diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple-lvds-dual-ports.yaml
>> b/Documentation/devicetree/bindings/display/panel/panel-simple-lvds-dual-ports.yaml
>> index 10ed4b57232b..e80fc7006984 100644
>> --- a/Documentation/devicetree/bindings/display/panel/panel-simple-lvds-dual-ports.yaml
>> +++ b/Documentation/devicetree/bindings/display/panel/panel-simple-lvds-
>> +++ dual-ports.yaml
>> @@ -22,6 +22,7 @@ description: |
>>    If the panel is more advanced a dedicated binding file is required.
>>
>>  allOf:
>> +  - $ref: /schemas/display/lvds-dual-ports.yaml#
>>    - $ref: panel-common.yaml#
>>
>>  properties:
>> @@ -55,28 +56,10 @@ properties:
>>
>>      properties:
>>        port@0:
>> -        $ref: /schemas/graph.yaml#/$defs/port-base
>> -        unevaluatedProperties: false
>> -        description: The first sink port.
>> -
>> -        properties:
>> -          dual-lvds-odd-pixels:
>> -            type: boolean
>> -            description: The first sink port for odd pixels.
>> -
>>          required:
>>            - dual-lvds-odd-pixels
>>
>>        port@1:
>> -        $ref: /schemas/graph.yaml#/$defs/port-base
>> -        unevaluatedProperties: false
>> -        description: The second sink port.
>> -
>> -        properties:
>> -          dual-lvds-even-pixels:
>> -            type: boolean
>> -            description: The second sink port for even pixels.
>> -
>>          required:
>>            - dual-lvds-even-pixels
>>
>> @@ -88,7 +71,6 @@ unevaluatedProperties: false
>>
>>  required:
>>    - compatible
>> -  - ports
>>    - power-supply
>>
>>  examples:
>> --
>> 2.34.1
> 

-- 
Regards,
Liu Ying

Re: [PATCH v4 08/13] dt-bindings: display: Document dual-link LVDS display common properties

[Liu Ying]

On 10/29/2024, Biju Das wrote:
> 
> Hi Liu Ying,

Hi Biju,

> 
>> -----Original Message-----
>> From: dri-devel <dri-devel-bounces@lists.freedesktop.org> On Behalf Of Liu Ying
>> Sent: 29 October 2024 07:35
>> Subject: Re: [PATCH v4 08/13] dt-bindings: display: Document dual-link LVDS display common properties
>>
>> On 10/29/2024, Biju Das wrote:
>>> Hi Liu Ying,
>>
>> Hi Biju,
>>
>>>
>>>> -----Original Message-----
>>>> From: Liu Ying <victor.liu@nxp.com>
>>>> Sent: 29 October 2024 07:13
>>>> Subject: Re: [PATCH v4 08/13] dt-bindings: display: Document
>>>> dual-link LVDS display common properties
>>>>
>>>> On 10/29/2024, Biju Das wrote:
>>>>> Hi Liu Ying,
>>>>
>>>> Hi Biju,
>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Liu Ying <victor.liu@nxp.com>
>>>>>> Sent: 29 October 2024 06:17
>>>>>> Subject: Re: [PATCH v4 08/13] dt-bindings: display: Document
>>>>>> dual-link LVDS display common properties
>>>>>>
>>>>>> On 10/28/2024, Liu Ying wrote:
>>>>>>> Dual-link LVDS displays receive odd pixels and even pixels
>>>>>>> separately from dual LVDS links.  One link receives odd pixels and
>>>>>>> the other receives even pixels.  Some of those displays may also
>>>>>>> use only one LVDS link to receive all pixels, being odd and even agnostic.
>>>>>>> Document common properties for those displays by extending LVDS
>>>>>>> display common properties defined in lvds.yaml.
>>>>>>>
>>>>>>> Suggested-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
>>>>>>> Signed-off-by: Liu Ying <victor.liu@nxp.com>
>>>>>>> ---
>>>>>>> v4:
>>>>>>> * Squash change for advantech,idk-2121wr.yaml and
>>>>>>>   panel-simple-lvds-dual-ports.yaml with lvds-dual-ports.yaml.
>>>>>>> (Rob)
>>>>>>> * Improve description in lvds-dual-ports.yaml.  (Krzysztof)
>>>>>>>
>>>>>>> v3:
>>>>>>> * New patch.  (Dmitry)
>>>>>>>
>>>>>>>  .../bindings/display/lvds-dual-ports.yaml     | 76 +++++++++++++++++++
>>>>>>>  .../display/panel/advantech,idk-2121wr.yaml   | 14 +---
>>>>>>>  .../panel/panel-simple-lvds-dual-ports.yaml   | 20 +----
>>>>>>>  3 files changed, 78 insertions(+), 32 deletions(-)  create mode
>>>>>>> 100644
>>>>>>> Documentation/devicetree/bindings/display/lvds-dual-ports.yaml
>>>>>>>
>>>>>>> diff --git
>>>>>>> a/Documentation/devicetree/bindings/display/lvds-dual-ports.yaml
>>>>>>> b/Documentation/devicetree/bindings/display/lvds-dual-ports.yaml
>>>>>>> new file mode 100644
>>>>>>> index 000000000000..5f7a30640404
>>>>>>> --- /dev/null
>>>>>>> +++ b/Documentation/devicetree/bindings/display/lvds-dual-ports.ya
>>>>>>> +++ ml
>>>>>>> @@ -0,0 +1,76 @@
>>>>>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML
>>>>>>> +1.2
>>>>>>> +---
>>>>>>> +$id: http://devicetree.org/schemas/display/lvds-dual-ports.yaml#
>>>>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>>>>>> +
>>>>>>> +title: Dual-link LVDS Display Common Properties
>>>>>>> +
>>>>>>> +maintainers:
>>>>>>> +  - Liu Ying <victor.liu@nxp.com>
>>>>>>> +
>>>>>>> +description: |
>>>>>>> +  Common properties for LVDS displays with dual LVDS links.
>>>>>>> +Extend LVDS display
>>>>>>> +  common properties defined in lvds.yaml.
>>>>>>> +
>>>>>>> +  Dual-link LVDS displays receive odd pixels and even pixels
>>>>>>> + separately from  the dual LVDS links. One link receives odd
>>>>>>> + pixels and the other receives  even pixels. Some of those
>>>>>>> + displays may also use only one LVDS link to  receive all pixels, being odd and even agnostic.
>>>>>>> +
>>>>>>> +allOf:
>>>>>>> +  - $ref: lvds.yaml#
>>>>>>> +
>>>>>>> +properties:
>>>>>>> +  ports:
>>>>>>> +    $ref: /schemas/graph.yaml#/properties/ports
>>>>>>> +
>>>>>>> +    properties:
>>>>>>> +      port@0:
>>>>>>> +        $ref: /schemas/graph.yaml#/$defs/port-base
>>>>>>> +        unevaluatedProperties: false
>>>>>>> +        description: the first LVDS input link
>>>>>>> +
>>>>>>> +        properties:
>>>>>>> +          dual-lvds-odd-pixels:
>>>>>>> +            type: boolean
>>>>>>> +            description: the first LVDS input link for odd pixels
>>>>>>> +
>>>>>>> +          dual-lvds-even-pixels:
>>>>>>> +            type: boolean
>>>>>>> +            description: the first LVDS input link for even
>>>>>>> + pixels
>>>>>>> +
>>>>>>> +        oneOf:
>>>>>>> +          - required: [dual-lvds-odd-pixels]
>>>>>>> +          - required: [dual-lvds-even-pixels]
>>>>>>> +          - properties:
>>>>>>> +              dual-lvds-odd-pixels: false
>>>>>>> +              dual-lvds-even-pixels: false
>>>>>>> +
>>>>>>> +      port@1:
>>>>>>> +        $ref: /schemas/graph.yaml#/$defs/port-base
>>>>>>> +        unevaluatedProperties: false
>>>>>>> +        description: the second LVDS input link
>>>>>>> +
>>>>>>> +        properties:
>>>>>>> +          dual-lvds-odd-pixels:
>>>>>>> +            type: boolean
>>>>>>> +            description: the second LVDS input link for odd
>>>>>>> + pixels
>>>>>>> +
>>>>>>> +          dual-lvds-even-pixels:
>>>>>>> +            type: boolean
>>>>>>> +            description: the second LVDS input link for even
>>>>>>> + pixels
>>>>>>> +
>>>>>>> +        oneOf:
>>>>>>> +          - required: [dual-lvds-odd-pixels]
>>>>>>> +          - required: [dual-lvds-even-pixels]
>>>>>>> +          - properties:
>>>>>>> +              dual-lvds-odd-pixels: false
>>>>>>> +              dual-lvds-even-pixels: false
>>>>>>
>>>>>> Hmm, I should require port@0 or port@1.
>>>>>
>>>>> For dual LVDS, you need 3 ports as common use case
>>>>
>>>> For LVDS panels, only two ports for LVDS sink are needed.
>>>> For display bridges with LVDS sink, one additional output port is
>>>> needed.  However, I'm not sure if this output port should be
>>>> documented in this binding or not, because it doesn't look common enough considering the LVDS
>> panels.
>>>>
>>>>>
>>>>> 2 input ports and 1 outport and all are required properties.
>>>>
>>>> The output port cannot be required for LVDS panels at least.
>>>
>>> Ack.
>>>
>>>>
>>>> We need to require one or two input ports, because IT6263 may use one LVDS link or two.
>>>
>>> This patch is for generic dual link common cases and is not applicable for IT6263 single link case.
>>
>> Based on previous discussion(especially Dmitry's suggestion), this binding should cover display
>> bridges that can use one LVDS sink port or two LVDS sink ports, like IT6263.  To be clear, those
>> bridges may have two modes(supported by one
>> chip) - single LVDS sink link mode and dual LVDS sink link mode.  Those bridges are considered as
>> common dual-link LVDS displays.  That's why I was asked to extract the common
>> properties to this schema when adding IT6263 DT binding.
> 
> As per [1] and [2] both panels don’t support single LVDS link.
> IT6263 is bridge device that has single and dual link support.
> Not sure the single link case has to be taken care in ITE6263 binding itself,
> Leaving Dual link as it is??

There are a couple of bridges supporting dual-link LVDS like
IT6263, see lontium,lt9211.yaml and thine,thc63lvd1024.yaml.
So, it looks fine for this binding to cover those bridges,
as those LVDS links are sort of common stuff.

> 
> [1]
> https://elixir.bootlin.com/linux/v6.12-rc5/source/Documentation/devicetree/bindings/display/panel/advantech,idk-2121wr.yaml
> [2]
> 
> https://elixir.bootlin.com/linux/v6.12-rc5/source/Documentation/devicetree/bindings/display/panel/panel-simple-lvds-dual-ports.yaml
> 
> 
> Cheers,
> Biju

-- 
Regards,
Liu Ying

RE: [PATCH v4 08/13] dt-bindings: display: Document dual-link LVDS display common properties

[Biju Das]

Hi Liu Ying,

> -----Original Message-----
> From: dri-devel <dri-devel-bounces@lists.freedesktop.org> On Behalf Of Liu Ying
> Sent: 29 October 2024 08:02
> Subject: Re: [PATCH v4 08/13] dt-bindings: display: Document dual-link LVDS display common properties
> 
> On 10/29/2024, Biju Das wrote:
> > Hi Liu Ying,
> 
> Hi Biju,
> 
> >
> >> -----Original Message-----
> >> From: Liu Ying <victor.liu@nxp.com>
> >> Sent: 28 October 2024 02:38
> >> Subject: [PATCH v4 08/13] dt-bindings: display: Document dual-link
> >> LVDS display common properties
> >>
> >> Dual-link LVDS displays receive odd pixels and even pixels separately
> >> from dual LVDS links.  One link receives odd pixels and the other
> >> receives even pixels.  Some of those displays may also use only one
> >> LVDS link to receive all pixels, being odd and even agnostic.  Document common properties for those
> displays by extending LVDS display common properties defined in lvds.yaml.
> >>
> >> Suggested-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> >> Signed-off-by: Liu Ying <victor.liu@nxp.com>
> >> ---
> >> v4:
> >> * Squash change for advantech,idk-2121wr.yaml and
> >>   panel-simple-lvds-dual-ports.yaml with lvds-dual-ports.yaml.  (Rob)
> >> * Improve description in lvds-dual-ports.yaml.  (Krzysztof)
> >>
> >> v3:
> >> * New patch.  (Dmitry)
> >>
> >>  .../bindings/display/lvds-dual-ports.yaml     | 76 +++++++++++++++++++
> >>  .../display/panel/advantech,idk-2121wr.yaml   | 14 +---
> >>  .../panel/panel-simple-lvds-dual-ports.yaml   | 20 +----
> >>  3 files changed, 78 insertions(+), 32 deletions(-)  create mode
> >> 100644 Documentation/devicetree/bindings/display/lvds-dual-ports.yaml
> >>
> >> diff --git
> >> a/Documentation/devicetree/bindings/display/lvds-dual-ports.yaml
> >> b/Documentation/devicetree/bindings/display/lvds-dual-ports.yaml
> >> new file mode 100644
> >> index 000000000000..5f7a30640404
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/display/lvds-dual-ports.yaml
> >> @@ -0,0 +1,76 @@
> >> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2
> >> +---
> >> +$id: http://devicetree.org/schemas/display/lvds-dual-ports.yaml#
> >> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> >> +
> >> +title: Dual-link LVDS Display Common Properties
> >> +
> >> +maintainers:
> >> +  - Liu Ying <victor.liu@nxp.com>
> >> +
> >> +description: |
> >> +  Common properties for LVDS displays with dual LVDS links. Extend
> >> +LVDS display
> >> +  common properties defined in lvds.yaml.
> >> +
> >> +  Dual-link LVDS displays receive odd pixels and even pixels
> >> + separately from  the dual LVDS links. One link receives odd pixels
> >> + and the other receives  even pixels. Some of those displays may
> >> + also use only one LVDS link to  receive all pixels, being odd and even agnostic.
> >> +
> >> +allOf:
> >> +  - $ref: lvds.yaml#
> >> +
> >> +properties:
> >> +  ports:
> >> +    $ref: /schemas/graph.yaml#/properties/ports
> >> +
> >> +    properties:
> >> +      port@0:
> >> +        $ref: /schemas/graph.yaml#/$defs/port-base
> >> +        unevaluatedProperties: false
> >> +        description: the first LVDS input link
> >> +
> >> +        properties:
> >> +          dual-lvds-odd-pixels:
> >> +            type: boolean
> >> +            description: the first LVDS input link for odd pixels
> >> +
> >> +          dual-lvds-even-pixels:
> >> +            type: boolean
> >> +            description: the first LVDS input link for even pixels
> >
> >
> > port@0 we know it is first link
> > port@1 we know it is second link.
> > dual-lvds-odd-pixels: We know it is for odd pixels.
> > dual-lvds-even-pixels: We know it is for odd pixels.
> >
> > Not sure, whether we can give common description and avoid the
> > duplicate from port@1 ??
> 
> Yes, it'd better to use patternProperties. Thanks.
> 
> --8<--
>     patternProperties:
>       '^port@[01]$':
>         $ref: /schemas/graph.yaml#/$defs/port-base
>         unevaluatedProperties: false
>         description: |
>           port@0 is for the first LVDS input link.
>           port@1 is for the second LVDS input link.
> 
>         properties:
>           dual-lvds-odd-pixels:
>             type: boolean
>             description: LVDS input link for odd pixels
> 
>           dual-lvds-even-pixels:
>             type: boolean
>             description: LVDS input link for even pixels
> 
>         oneOf:
>           - required: [dual-lvds-odd-pixels]
>           - required: [dual-lvds-even-pixels]
>           - properties:
>               dual-lvds-odd-pixels: false
>               dual-lvds-even-pixels: false
> 
>     anyOf:
>       - required:
>           - port@0
>       - required:
>           - port@1
> --8<--
> 
> >
> >
> >> +
> >> +        oneOf:
> >> +          - required: [dual-lvds-odd-pixels]
> >> +          - required: [dual-lvds-even-pixels]
> >> +          - properties:
> >> +              dual-lvds-odd-pixels: false
> >> +              dual-lvds-even-pixels: false
> >
> > Why this is false here? oneOf is not sufficient?
> 
> The 'false' is used when this LVDS link works alone as a single LVDS link, being odd and even
> agnostic.
> 
> The 'oneOf' allows a LVDS link to be defined as a single LVDS link or one link of dual LVDS links.

Ok, it makes sense for single LVDS link. Maybe rename the file to lvds-dual-ports.yaml->lvds-ports.yaml
to make it clear, it is for all LVDS ports, if it is going to address single link case aswell??

Cheers,
Biju

Re: [PATCH v4 08/13] dt-bindings: display: Document dual-link LVDS display common properties

[Liu Ying]

On 10/29/2024, Biju Das wrote:
> Hi Liu Ying,

Hi Biju,

> 
>> -----Original Message-----
>> From: dri-devel <dri-devel-bounces@lists.freedesktop.org> On Behalf Of Liu Ying
>> Sent: 29 October 2024 08:02
>> Subject: Re: [PATCH v4 08/13] dt-bindings: display: Document dual-link LVDS display common properties
>>
>> On 10/29/2024, Biju Das wrote:
>>> Hi Liu Ying,
>>
>> Hi Biju,
>>
>>>
>>>> -----Original Message-----
>>>> From: Liu Ying <victor.liu@nxp.com>
>>>> Sent: 28 October 2024 02:38
>>>> Subject: [PATCH v4 08/13] dt-bindings: display: Document dual-link
>>>> LVDS display common properties
>>>>
>>>> Dual-link LVDS displays receive odd pixels and even pixels separately
>>>> from dual LVDS links.  One link receives odd pixels and the other
>>>> receives even pixels.  Some of those displays may also use only one
>>>> LVDS link to receive all pixels, being odd and even agnostic.  Document common properties for those
>> displays by extending LVDS display common properties defined in lvds.yaml.
>>>>
>>>> Suggested-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
>>>> Signed-off-by: Liu Ying <victor.liu@nxp.com>
>>>> ---
>>>> v4:
>>>> * Squash change for advantech,idk-2121wr.yaml and
>>>>   panel-simple-lvds-dual-ports.yaml with lvds-dual-ports.yaml.  (Rob)
>>>> * Improve description in lvds-dual-ports.yaml.  (Krzysztof)
>>>>
>>>> v3:
>>>> * New patch.  (Dmitry)
>>>>
>>>>  .../bindings/display/lvds-dual-ports.yaml     | 76 +++++++++++++++++++
>>>>  .../display/panel/advantech,idk-2121wr.yaml   | 14 +---
>>>>  .../panel/panel-simple-lvds-dual-ports.yaml   | 20 +----
>>>>  3 files changed, 78 insertions(+), 32 deletions(-)  create mode
>>>> 100644 Documentation/devicetree/bindings/display/lvds-dual-ports.yaml
>>>>
>>>> diff --git
>>>> a/Documentation/devicetree/bindings/display/lvds-dual-ports.yaml
>>>> b/Documentation/devicetree/bindings/display/lvds-dual-ports.yaml
>>>> new file mode 100644
>>>> index 000000000000..5f7a30640404
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/display/lvds-dual-ports.yaml
>>>> @@ -0,0 +1,76 @@
>>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2
>>>> +---
>>>> +$id: http://devicetree.org/schemas/display/lvds-dual-ports.yaml#
>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>>> +
>>>> +title: Dual-link LVDS Display Common Properties
>>>> +
>>>> +maintainers:
>>>> +  - Liu Ying <victor.liu@nxp.com>
>>>> +
>>>> +description: |
>>>> +  Common properties for LVDS displays with dual LVDS links. Extend
>>>> +LVDS display
>>>> +  common properties defined in lvds.yaml.
>>>> +
>>>> +  Dual-link LVDS displays receive odd pixels and even pixels
>>>> + separately from  the dual LVDS links. One link receives odd pixels
>>>> + and the other receives  even pixels. Some of those displays may
>>>> + also use only one LVDS link to  receive all pixels, being odd and even agnostic.
>>>> +
>>>> +allOf:
>>>> +  - $ref: lvds.yaml#
>>>> +
>>>> +properties:
>>>> +  ports:
>>>> +    $ref: /schemas/graph.yaml#/properties/ports
>>>> +
>>>> +    properties:
>>>> +      port@0:
>>>> +        $ref: /schemas/graph.yaml#/$defs/port-base
>>>> +        unevaluatedProperties: false
>>>> +        description: the first LVDS input link
>>>> +
>>>> +        properties:
>>>> +          dual-lvds-odd-pixels:
>>>> +            type: boolean
>>>> +            description: the first LVDS input link for odd pixels
>>>> +
>>>> +          dual-lvds-even-pixels:
>>>> +            type: boolean
>>>> +            description: the first LVDS input link for even pixels
>>>
>>>
>>> port@0 we know it is first link
>>> port@1 we know it is second link.
>>> dual-lvds-odd-pixels: We know it is for odd pixels.
>>> dual-lvds-even-pixels: We know it is for odd pixels.
>>>
>>> Not sure, whether we can give common description and avoid the
>>> duplicate from port@1 ??
>>
>> Yes, it'd better to use patternProperties. Thanks.
>>
>> --8<--
>>     patternProperties:
>>       '^port@[01]$':
>>         $ref: /schemas/graph.yaml#/$defs/port-base
>>         unevaluatedProperties: false
>>         description: |
>>           port@0 is for the first LVDS input link.
>>           port@1 is for the second LVDS input link.
>>
>>         properties:
>>           dual-lvds-odd-pixels:
>>             type: boolean
>>             description: LVDS input link for odd pixels
>>
>>           dual-lvds-even-pixels:
>>             type: boolean
>>             description: LVDS input link for even pixels
>>
>>         oneOf:
>>           - required: [dual-lvds-odd-pixels]
>>           - required: [dual-lvds-even-pixels]
>>           - properties:
>>               dual-lvds-odd-pixels: false
>>               dual-lvds-even-pixels: false
>>
>>     anyOf:
>>       - required:
>>           - port@0
>>       - required:
>>           - port@1
>> --8<--
>>
>>>
>>>
>>>> +
>>>> +        oneOf:
>>>> +          - required: [dual-lvds-odd-pixels]
>>>> +          - required: [dual-lvds-even-pixels]
>>>> +          - properties:
>>>> +              dual-lvds-odd-pixels: false
>>>> +              dual-lvds-even-pixels: false
>>>
>>> Why this is false here? oneOf is not sufficient?
>>
>> The 'false' is used when this LVDS link works alone as a single LVDS link, being odd and even
>> agnostic.
>>
>> The 'oneOf' allows a LVDS link to be defined as a single LVDS link or one link of dual LVDS links.
> 
> Ok, it makes sense for single LVDS link. Maybe rename the file to lvds-dual-ports.yaml->lvds-ports.yaml
> to make it clear, it is for all LVDS ports, if it is going to address single link case aswell??

Single-link LVDS displays are supposed to be documented
without referencing this schema, i.e., they may reference
lvds.yaml and define the single LVDS sink link with port
property(for panels) or port@0 property(for bridges).
port@1 would be defined as output port for bridges, not
input port.  Maybe, we'll have something like
lvds-single-port.yaml in the future.

> 
> Cheers,
> Biju
> 

-- 
Regards,
Liu Ying

RE: [PATCH v4 08/13] dt-bindings: display: Document dual-link LVDS display common properties

[Biju Das]

Hi Liu Ying,

> -----Original Message-----
> From: dri-devel <dri-devel-bounces@lists.freedesktop.org> On Behalf Of Liu Ying
> Sent: 29 October 2024 09:07
> Subject: Re: [PATCH v4 08/13] dt-bindings: display: Document dual-link LVDS display common properties
> 
> On 10/29/2024, Biju Das wrote:
> > Hi Liu Ying,
> 
> Hi Biju,
> 
> >
> >> -----Original Message-----
> >> From: dri-devel <dri-devel-bounces@lists.freedesktop.org> On Behalf
> >> Of Liu Ying
> >> Sent: 29 October 2024 08:02
> >> Subject: Re: [PATCH v4 08/13] dt-bindings: display: Document
> >> dual-link LVDS display common properties
> >>
> >> On 10/29/2024, Biju Das wrote:
> >>> Hi Liu Ying,
> >>
> >> Hi Biju,
> >>
> >>>
> >>>> -----Original Message-----
> >>>> From: Liu Ying <victor.liu@nxp.com>
> >>>> Sent: 28 October 2024 02:38
> >>>> Subject: [PATCH v4 08/13] dt-bindings: display: Document dual-link
> >>>> LVDS display common properties
> >>>>
> >>>> Dual-link LVDS displays receive odd pixels and even pixels
> >>>> separately from dual LVDS links.  One link receives odd pixels and
> >>>> the other receives even pixels.  Some of those displays may also
> >>>> use only one LVDS link to receive all pixels, being odd and even
> >>>> agnostic.  Document common properties for those
> >> displays by extending LVDS display common properties defined in lvds.yaml.
> >>>>
> >>>> Suggested-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> >>>> Signed-off-by: Liu Ying <victor.liu@nxp.com>
> >>>> ---
> >>>> v4:
> >>>> * Squash change for advantech,idk-2121wr.yaml and
> >>>>   panel-simple-lvds-dual-ports.yaml with lvds-dual-ports.yaml.
> >>>> (Rob)
> >>>> * Improve description in lvds-dual-ports.yaml.  (Krzysztof)
> >>>>
> >>>> v3:
> >>>> * New patch.  (Dmitry)
> >>>>
> >>>>  .../bindings/display/lvds-dual-ports.yaml     | 76 +++++++++++++++++++
> >>>>  .../display/panel/advantech,idk-2121wr.yaml   | 14 +---
> >>>>  .../panel/panel-simple-lvds-dual-ports.yaml   | 20 +----
> >>>>  3 files changed, 78 insertions(+), 32 deletions(-)  create mode
> >>>> 100644
> >>>> Documentation/devicetree/bindings/display/lvds-dual-ports.yaml
> >>>>
> >>>> diff --git
> >>>> a/Documentation/devicetree/bindings/display/lvds-dual-ports.yaml
> >>>> b/Documentation/devicetree/bindings/display/lvds-dual-ports.yaml
> >>>> new file mode 100644
> >>>> index 000000000000..5f7a30640404
> >>>> --- /dev/null
> >>>> +++ b/Documentation/devicetree/bindings/display/lvds-dual-ports.yam
> >>>> +++ l
> >>>> @@ -0,0 +1,76 @@
> >>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML
> >>>> +1.2
> >>>> +---
> >>>> +$id: http://devicetree.org/schemas/display/lvds-dual-ports.yaml#
> >>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> >>>> +
> >>>> +title: Dual-link LVDS Display Common Properties
> >>>> +
> >>>> +maintainers:
> >>>> +  - Liu Ying <victor.liu@nxp.com>
> >>>> +
> >>>> +description: |
> >>>> +  Common properties for LVDS displays with dual LVDS links. Extend
> >>>> +LVDS display
> >>>> +  common properties defined in lvds.yaml.
> >>>> +
> >>>> +  Dual-link LVDS displays receive odd pixels and even pixels
> >>>> + separately from  the dual LVDS links. One link receives odd
> >>>> + pixels and the other receives  even pixels. Some of those
> >>>> + displays may also use only one LVDS link to  receive all pixels, being odd and even agnostic.
> >>>> +
> >>>> +allOf:
> >>>> +  - $ref: lvds.yaml#
> >>>> +
> >>>> +properties:
> >>>> +  ports:
> >>>> +    $ref: /schemas/graph.yaml#/properties/ports
> >>>> +
> >>>> +    properties:
> >>>> +      port@0:
> >>>> +        $ref: /schemas/graph.yaml#/$defs/port-base
> >>>> +        unevaluatedProperties: false
> >>>> +        description: the first LVDS input link
> >>>> +
> >>>> +        properties:
> >>>> +          dual-lvds-odd-pixels:
> >>>> +            type: boolean
> >>>> +            description: the first LVDS input link for odd pixels
> >>>> +
> >>>> +          dual-lvds-even-pixels:
> >>>> +            type: boolean
> >>>> +            description: the first LVDS input link for even pixels
> >>>
> >>>
> >>> port@0 we know it is first link
> >>> port@1 we know it is second link.
> >>> dual-lvds-odd-pixels: We know it is for odd pixels.
> >>> dual-lvds-even-pixels: We know it is for odd pixels.
> >>>
> >>> Not sure, whether we can give common description and avoid the
> >>> duplicate from port@1 ??
> >>
> >> Yes, it'd better to use patternProperties. Thanks.
> >>
> >> --8<--
> >>     patternProperties:
> >>       '^port@[01]$':
> >>         $ref: /schemas/graph.yaml#/$defs/port-base
> >>         unevaluatedProperties: false
> >>         description: |
> >>           port@0 is for the first LVDS input link.
> >>           port@1 is for the second LVDS input link.
> >>
> >>         properties:
> >>           dual-lvds-odd-pixels:
> >>             type: boolean
> >>             description: LVDS input link for odd pixels
> >>
> >>           dual-lvds-even-pixels:
> >>             type: boolean
> >>             description: LVDS input link for even pixels
> >>
> >>         oneOf:
> >>           - required: [dual-lvds-odd-pixels]
> >>           - required: [dual-lvds-even-pixels]
> >>           - properties:
> >>               dual-lvds-odd-pixels: false
> >>               dual-lvds-even-pixels: false
> >>
> >>     anyOf:
> >>       - required:
> >>           - port@0
> >>       - required:
> >>           - port@1
> >> --8<--
> >>
> >>>
> >>>
> >>>> +
> >>>> +        oneOf:
> >>>> +          - required: [dual-lvds-odd-pixels]
> >>>> +          - required: [dual-lvds-even-pixels]
> >>>> +          - properties:
> >>>> +              dual-lvds-odd-pixels: false
> >>>> +              dual-lvds-even-pixels: false
> >>>
> >>> Why this is false here? oneOf is not sufficient?
> >>
> >> The 'false' is used when this LVDS link works alone as a single LVDS
> >> link, being odd and even agnostic.
> >>
> >> The 'oneOf' allows a LVDS link to be defined as a single LVDS link or one link of dual LVDS links.
> >
> > Ok, it makes sense for single LVDS link. Maybe rename the file to
> > lvds-dual-ports.yaml->lvds-ports.yaml
> > to make it clear, it is for all LVDS ports, if it is going to address single link case aswell??
> 
> Single-link LVDS displays are supposed to be documented without referencing this schema, i.e., they
> may reference lvds.yaml and define the single LVDS sink link with port property(for panels) or port@0
> property(for bridges).
> port@1 would be defined as output port for bridges, not input port.  Maybe, we'll have something like
> lvds-single-port.yaml in the future.

OK, then this binding is suffient I guess.

As description says, majority devices supports dual links.
Some dual link display supports single link as well.

Cheers,
Biju

Re: [PATCH v4 00/13] Add ITE IT6263 LVDS to HDMI converter support

[Dmitry Baryshkov]

On Tue, 29 Oct 2024 at 04:41, Liu Ying <victor.liu@nxp.com> wrote:
>
> On 10/28/2024, Dmitry Baryshkov wrote:
> > On Mon, Oct 28, 2024 at 11:12:00AM +0000, Biju Das wrote:
> >> Hi Dmitry, Liu,
> >>
> >>> -----Original Message-----
> >>> From: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> >>> Sent: 28 October 2024 10:20
> >>> Subject: Re: [PATCH v4 00/13] Add ITE IT6263 LVDS to HDMI converter support
> >>>
> >>> Hi,
> >>>
> >>> On Mon, 28 Oct 2024 at 04:37, Liu Ying <victor.liu@nxp.com> wrote:
> >>>>
> >>>> Hi,
> >>>>
> >>>> This patch series aims to add ITE IT6263 LVDS to HDMI converter on
> >>>> i.MX8MP EVK.  Combined with LVDS receiver and HDMI 1.4a transmitter,
> >>>> the IT6263 supports LVDS input and HDMI 1.4 output by conversion
> >>>> function.  IT6263 product link can be found at [1].
> >>>>
> >>>> Patch 1 is a preparation patch to allow display mode of an existing
> >>>> panel to pass the added mode validation logic in patch 3.
> >>>>
> >>>> Patch 2 allows i.MX8MP LVDS Display Bridge(LDB) bridge driver to find
> >>>> the next non-panel bridge, that is the IT6263 in this case.
> >>>>
> >>>> Patch 3 adds mode validation logic to i.MX8MP LDB bridge driver
> >>>> against "ldb" clock so that it can filter out unsupported display
> >>>> modes read from EDID.
> >>>>
> >>>> Patch 4 adds MEDIA_BUS_FMT_RGB101010_1X7X5_{SPWG,JEIDA} support, as
> >>>> they are supported by IT6263(with LVDS data bit reversed order).
> >>>>
> >>>> Patch 5 makes drm_of.c use MEDIA_BUS_FMT_RGB101010_1X7X5_{JEIDA,SPWG}.
> >>>>
> >>>> Patch 6 supports getting dual-link LVDS pixel order for the sink side
> >>>> as needed by IT6263 driver.
> >>>>
> >>>> Patch 7 documents jeida-30 and vesa-30 data mappings in
> >>>> lvds-data-mapping.yaml, as needed by IT6263 DT binding.
> >>>>
> >>>> Patch 8 extracts common dual-link LVDS display properties into new
> >>>> lvds-dual-ports.yaml so that IT6263 DT binding can reference it.
> >>>>
> >>>> Patch 9 adds DT binding for IT6263.
> >>>>
> >>>> Patch 10 adds IT6263 bridge driver.  Only video output is supported.
> >>>>
> >>>> Patch 11 adds DT overlays to support NXP adapter cards[2][3] with
> >>>> IT6263 populated.
> >>>>
> >>>> Patch 12 enables the IT6263 bridge driver in defconfig.
> >>>>
> >>>> Patch 13 updates MAINTAINERS to add maintainer for IT6263 driver.
> >>>
> >>> This has pretty complicated structure from the merging point of view.
> >>>
> >>> I propose we take patches 6, 8, 9 (without 30-bit formats, they can be dropped while applying), 11, 12
> >>> (?) and 13 through drm-misc in one batch (once DT maintainers review the binding parts). This looks
> >>> like a minimal set, having no extra dependencies.
> >>
> >>>
> >>> The second set might be 4, 5 + new patch, re-adding 30-bit formats to
> >>> IT6263 binding (no driver changes are necessary). This can go in separately, after an Ack from media
> >>> maintainers.
> >>>
> >>> Of course both sets can go together if linux-media maintainers reacts quickly and ack merging media-
> >>> formats patch through drm-misc tree.
>
> I'm fine with merging the two sets through drm-misc tree as long
> as linux-media and dri-devel maintainers accept this.  Up to them.
>
> >>>
> >>> The rest of the patches don't have such strong dependencies and go in once ready / reviewed.
> >>>
> >>> WDYT?
> >>
> >> I guess, 6,8,9(without 30-bit formats), 10, 12 and 13.
> >>
> >> 11 may have dependency on 1, 2 and 3 as it is SoC specific.
> >
> > Yes, of course, 10, not 11.
> >
> >> Then 4, 5 + new patch, re-adding 30-bit formats to IT6263 binding.
>
> I think it would be good to directly support 30-bit formats in
> IT6263 DT binding, not re-add them to it.  This way, we'll have one
> version of the binding, not two.  So, a better first set would
> contain patch 6, 7(one existing A-b from Krzysztof), 8, 9, 10, 12
> and 13.

I'm not sure that 7 can go without an ack from linux-media maintainers.

-- 
With best wishes
Dmitry

RE: [PATCH v4 00/13] Add ITE IT6263 LVDS to HDMI converter support

[Biju Das]

Hi Dmitry Baryshkov,

> -----Original Message-----
> From: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> Sent: 30 October 2024 03:17
> Subject: Re: [PATCH v4 00/13] Add ITE IT6263 LVDS to HDMI converter support
> 
> On Tue, 29 Oct 2024 at 04:41, Liu Ying <victor.liu@nxp.com> wrote:
> >
> > On 10/28/2024, Dmitry Baryshkov wrote:
> > > On Mon, Oct 28, 2024 at 11:12:00AM +0000, Biju Das wrote:
> > >> Hi Dmitry, Liu,
> > >>
> > >>> -----Original Message-----
> > >>> From: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> > >>> Sent: 28 October 2024 10:20
> > >>> Subject: Re: [PATCH v4 00/13] Add ITE IT6263 LVDS to HDMI
> > >>> converter support
> > >>>
> > >>> Hi,
> > >>>
> > >>> On Mon, 28 Oct 2024 at 04:37, Liu Ying <victor.liu@nxp.com> wrote:
> > >>>>
> > >>>> Hi,
> > >>>>
> > >>>> This patch series aims to add ITE IT6263 LVDS to HDMI converter
> > >>>> on i.MX8MP EVK.  Combined with LVDS receiver and HDMI 1.4a
> > >>>> transmitter, the IT6263 supports LVDS input and HDMI 1.4 output
> > >>>> by conversion function.  IT6263 product link can be found at [1].
> > >>>>
> > >>>> Patch 1 is a preparation patch to allow display mode of an
> > >>>> existing panel to pass the added mode validation logic in patch 3.
> > >>>>
> > >>>> Patch 2 allows i.MX8MP LVDS Display Bridge(LDB) bridge driver to
> > >>>> find the next non-panel bridge, that is the IT6263 in this case.
> > >>>>
> > >>>> Patch 3 adds mode validation logic to i.MX8MP LDB bridge driver
> > >>>> against "ldb" clock so that it can filter out unsupported display
> > >>>> modes read from EDID.
> > >>>>
> > >>>> Patch 4 adds MEDIA_BUS_FMT_RGB101010_1X7X5_{SPWG,JEIDA} support,
> > >>>> as they are supported by IT6263(with LVDS data bit reversed order).
> > >>>>
> > >>>> Patch 5 makes drm_of.c use MEDIA_BUS_FMT_RGB101010_1X7X5_{JEIDA,SPWG}.
> > >>>>
> > >>>> Patch 6 supports getting dual-link LVDS pixel order for the sink
> > >>>> side as needed by IT6263 driver.
> > >>>>
> > >>>> Patch 7 documents jeida-30 and vesa-30 data mappings in
> > >>>> lvds-data-mapping.yaml, as needed by IT6263 DT binding.
> > >>>>
> > >>>> Patch 8 extracts common dual-link LVDS display properties into
> > >>>> new lvds-dual-ports.yaml so that IT6263 DT binding can reference it.
> > >>>>
> > >>>> Patch 9 adds DT binding for IT6263.
> > >>>>
> > >>>> Patch 10 adds IT6263 bridge driver.  Only video output is supported.
> > >>>>
> > >>>> Patch 11 adds DT overlays to support NXP adapter cards[2][3] with
> > >>>> IT6263 populated.
> > >>>>
> > >>>> Patch 12 enables the IT6263 bridge driver in defconfig.
> > >>>>
> > >>>> Patch 13 updates MAINTAINERS to add maintainer for IT6263 driver.
> > >>>
> > >>> This has pretty complicated structure from the merging point of view.
> > >>>
> > >>> I propose we take patches 6, 8, 9 (without 30-bit formats, they
> > >>> can be dropped while applying), 11, 12
> > >>> (?) and 13 through drm-misc in one batch (once DT maintainers
> > >>> review the binding parts). This looks like a minimal set, having no extra dependencies.
> > >>
> > >>>
> > >>> The second set might be 4, 5 + new patch, re-adding 30-bit formats
> > >>> to
> > >>> IT6263 binding (no driver changes are necessary). This can go in
> > >>> separately, after an Ack from media maintainers.
> > >>>
> > >>> Of course both sets can go together if linux-media maintainers
> > >>> reacts quickly and ack merging media- formats patch through drm-misc tree.
> >
> > I'm fine with merging the two sets through drm-misc tree as long as
> > linux-media and dri-devel maintainers accept this.  Up to them.
> >
> > >>>
> > >>> The rest of the patches don't have such strong dependencies and go in once ready / reviewed.
> > >>>
> > >>> WDYT?
> > >>
> > >> I guess, 6,8,9(without 30-bit formats), 10, 12 and 13.
> > >>
> > >> 11 may have dependency on 1, 2 and 3 as it is SoC specific.
> > >
> > > Yes, of course, 10, not 11.
> > >
> > >> Then 4, 5 + new patch, re-adding 30-bit formats to IT6263 binding.
> >
> > I think it would be good to directly support 30-bit formats in
> > IT6263 DT binding, not re-add them to it.  This way, we'll have one
> > version of the binding, not two.  So, a better first set would contain
> > patch 6, 7(one existing A-b from Krzysztof), 8, 9, 10, 12 and 13.
> 
> I'm not sure that 7 can go without an ack from linux-media maintainers.

You mean in describing jeida-30 and vesa-30 format in
patch#7, is valid only if patch#4 is ok with media people
or they provide an ack for patch#7 to take it through drm tree?

Cheers,
Biju

Re: [PATCH v4 03/13] drm/bridge: fsl-ldb: Use clk_round_rate() to validate "ldb" clock rate

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 1229 bytes --]

On Mon, Oct 28, 2024 at 10:37:30AM +0800, Liu Ying wrote:
> Multiple display modes could be read from a display device's EDID.
> Use clk_round_rate() to validate the "ldb" clock rate for each mode
> in drm_bridge_funcs::mode_valid() to filter unsupported modes out.
> 
> Also, since this driver doesn't directly reference pixel clock, use
> clk_round_rate() to validate the pixel clock rate against the "ldb"
> clock if the "ldb" clock and the pixel clock are sibling in clock
> tree.  This is not done in display controller driver because
> drm_crtc_helper_funcs::mode_valid() may not decide to do the
> validation or not if multiple encoders are connected to the CRTC,
> e.g., i.MX93 LCDIF may connect with MIPI DSI controller, LDB and
> parallel display output simultaneously.
> 
> Signed-off-by: Liu Ying <victor.liu@nxp.com>
> ---
> Note that this patch depends on a patch in shawnguo/imx/fixes:
> https://patchwork.kernel.org/project/linux-arm-kernel/patch/20241017031146.157996-1-marex@denx.de/

I still believe that the root cause of this issue is your clock tree and
driver setup, and since I've asked for explanations and didn't get any,
I don't really see how we can move forward here.

Maxime

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]

Re: [PATCH v4 03/13] drm/bridge: fsl-ldb: Use clk_round_rate() to validate "ldb" clock rate

[Liu Ying]

Hi Maxime,

On 10/30/2024, Maxime Ripard wrote:
> On Mon, Oct 28, 2024 at 10:37:30AM +0800, Liu Ying wrote:
>> Multiple display modes could be read from a display device's EDID.
>> Use clk_round_rate() to validate the "ldb" clock rate for each mode
>> in drm_bridge_funcs::mode_valid() to filter unsupported modes out.
>>
>> Also, since this driver doesn't directly reference pixel clock, use
>> clk_round_rate() to validate the pixel clock rate against the "ldb"
>> clock if the "ldb" clock and the pixel clock are sibling in clock
>> tree.  This is not done in display controller driver because
>> drm_crtc_helper_funcs::mode_valid() may not decide to do the
>> validation or not if multiple encoders are connected to the CRTC,
>> e.g., i.MX93 LCDIF may connect with MIPI DSI controller, LDB and
>> parallel display output simultaneously.
>>
>> Signed-off-by: Liu Ying <victor.liu@nxp.com>
>> ---
>> Note that this patch depends on a patch in shawnguo/imx/fixes:
>> https://patchwork.kernel.org/project/linux-arm-kernel/patch/20241017031146.157996-1-marex@denx.de/
> 
> I still believe that the root cause of this issue is your clock tree and
> driver setup, and since I've asked for explanations and didn't get any,
> I don't really see how we can move forward here.

Since you asked for a description at *somewhere* in another thread[1],
can you please suggest a place where this could happen?

[1] https://lore.kernel.org/imx/47d92ae0-c71a-4c18-9ad7-432c0f70a31f@nxp.com/T/#m587e6a25bdab542d5d99abbf01caaca89495b1d5

> 
> Maxime

-- 
Regards,
Liu Ying

Re: [PATCH v4 00/13] Add ITE IT6263 LVDS to HDMI converter support

[Dmitry Baryshkov]

On Wed, 30 Oct 2024 at 11:02, Biju Das <biju.das.jz@bp.renesas.com> wrote:
>
> Hi Dmitry Baryshkov,
>
> > -----Original Message-----
> > From: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> > Sent: 30 October 2024 03:17
> > Subject: Re: [PATCH v4 00/13] Add ITE IT6263 LVDS to HDMI converter support
> >
> > On Tue, 29 Oct 2024 at 04:41, Liu Ying <victor.liu@nxp.com> wrote:
> > >
> > > On 10/28/2024, Dmitry Baryshkov wrote:
> > > > On Mon, Oct 28, 2024 at 11:12:00AM +0000, Biju Das wrote:
> > > >> Hi Dmitry, Liu,
> > > >>
> > > >>> -----Original Message-----
> > > >>> From: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> > > >>> Sent: 28 October 2024 10:20
> > > >>> Subject: Re: [PATCH v4 00/13] Add ITE IT6263 LVDS to HDMI
> > > >>> converter support
> > > >>>
> > > >>> Hi,
> > > >>>
> > > >>> On Mon, 28 Oct 2024 at 04:37, Liu Ying <victor.liu@nxp.com> wrote:
> > > >>>>
> > > >>>> Hi,
> > > >>>>
> > > >>>> This patch series aims to add ITE IT6263 LVDS to HDMI converter
> > > >>>> on i.MX8MP EVK.  Combined with LVDS receiver and HDMI 1.4a
> > > >>>> transmitter, the IT6263 supports LVDS input and HDMI 1.4 output
> > > >>>> by conversion function.  IT6263 product link can be found at [1].
> > > >>>>
> > > >>>> Patch 1 is a preparation patch to allow display mode of an
> > > >>>> existing panel to pass the added mode validation logic in patch 3.
> > > >>>>
> > > >>>> Patch 2 allows i.MX8MP LVDS Display Bridge(LDB) bridge driver to
> > > >>>> find the next non-panel bridge, that is the IT6263 in this case.
> > > >>>>
> > > >>>> Patch 3 adds mode validation logic to i.MX8MP LDB bridge driver
> > > >>>> against "ldb" clock so that it can filter out unsupported display
> > > >>>> modes read from EDID.
> > > >>>>
> > > >>>> Patch 4 adds MEDIA_BUS_FMT_RGB101010_1X7X5_{SPWG,JEIDA} support,
> > > >>>> as they are supported by IT6263(with LVDS data bit reversed order).
> > > >>>>
> > > >>>> Patch 5 makes drm_of.c use MEDIA_BUS_FMT_RGB101010_1X7X5_{JEIDA,SPWG}.
> > > >>>>
> > > >>>> Patch 6 supports getting dual-link LVDS pixel order for the sink
> > > >>>> side as needed by IT6263 driver.
> > > >>>>
> > > >>>> Patch 7 documents jeida-30 and vesa-30 data mappings in
> > > >>>> lvds-data-mapping.yaml, as needed by IT6263 DT binding.
> > > >>>>
> > > >>>> Patch 8 extracts common dual-link LVDS display properties into
> > > >>>> new lvds-dual-ports.yaml so that IT6263 DT binding can reference it.
> > > >>>>
> > > >>>> Patch 9 adds DT binding for IT6263.
> > > >>>>
> > > >>>> Patch 10 adds IT6263 bridge driver.  Only video output is supported.
> > > >>>>
> > > >>>> Patch 11 adds DT overlays to support NXP adapter cards[2][3] with
> > > >>>> IT6263 populated.
> > > >>>>
> > > >>>> Patch 12 enables the IT6263 bridge driver in defconfig.
> > > >>>>
> > > >>>> Patch 13 updates MAINTAINERS to add maintainer for IT6263 driver.
> > > >>>
> > > >>> This has pretty complicated structure from the merging point of view.
> > > >>>
> > > >>> I propose we take patches 6, 8, 9 (without 30-bit formats, they
> > > >>> can be dropped while applying), 11, 12
> > > >>> (?) and 13 through drm-misc in one batch (once DT maintainers
> > > >>> review the binding parts). This looks like a minimal set, having no extra dependencies.
> > > >>
> > > >>>
> > > >>> The second set might be 4, 5 + new patch, re-adding 30-bit formats
> > > >>> to
> > > >>> IT6263 binding (no driver changes are necessary). This can go in
> > > >>> separately, after an Ack from media maintainers.
> > > >>>
> > > >>> Of course both sets can go together if linux-media maintainers
> > > >>> reacts quickly and ack merging media- formats patch through drm-misc tree.
> > >
> > > I'm fine with merging the two sets through drm-misc tree as long as
> > > linux-media and dri-devel maintainers accept this.  Up to them.
> > >
> > > >>>
> > > >>> The rest of the patches don't have such strong dependencies and go in once ready / reviewed.
> > > >>>
> > > >>> WDYT?
> > > >>
> > > >> I guess, 6,8,9(without 30-bit formats), 10, 12 and 13.
> > > >>
> > > >> 11 may have dependency on 1, 2 and 3 as it is SoC specific.
> > > >
> > > > Yes, of course, 10, not 11.
> > > >
> > > >> Then 4, 5 + new patch, re-adding 30-bit formats to IT6263 binding.
> > >
> > > I think it would be good to directly support 30-bit formats in
> > > IT6263 DT binding, not re-add them to it.  This way, we'll have one
> > > version of the binding, not two.  So, a better first set would contain
> > > patch 6, 7(one existing A-b from Krzysztof), 8, 9, 10, 12 and 13.
> >
> > I'm not sure that 7 can go without an ack from linux-media maintainers.
>
> You mean in describing jeida-30 and vesa-30 format in
> patch#7, is valid only if patch#4 is ok with media people
> or they provide an ack for patch#7 to take it through drm tree?

The former one. I'd prefer an ack from linux-media maintainers to
accept bindings based on those names.

-- 
With best wishes
Dmitry

Re: [PATCH v4 08/13] dt-bindings: display: Document dual-link LVDS display common properties

[Rob Herring]

On Tue, Oct 29, 2024 at 04:25:52PM +0800, Liu Ying wrote:
> On 10/29/2024, Biju Das wrote:
> > 
> > Hi Liu Ying,
> 
> Hi Biju,
> 
> > 
> >> -----Original Message-----
> >> From: dri-devel <dri-devel-bounces@lists.freedesktop.org> On Behalf Of Liu Ying
> >> Sent: 29 October 2024 07:35
> >> Subject: Re: [PATCH v4 08/13] dt-bindings: display: Document dual-link LVDS display common properties
> >>
> >> On 10/29/2024, Biju Das wrote:
> >>> Hi Liu Ying,
> >>
> >> Hi Biju,
> >>
> >>>
> >>>> -----Original Message-----
> >>>> From: Liu Ying <victor.liu@nxp.com>
> >>>> Sent: 29 October 2024 07:13
> >>>> Subject: Re: [PATCH v4 08/13] dt-bindings: display: Document
> >>>> dual-link LVDS display common properties
> >>>>
> >>>> On 10/29/2024, Biju Das wrote:
> >>>>> Hi Liu Ying,
> >>>>
> >>>> Hi Biju,
> >>>>
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: Liu Ying <victor.liu@nxp.com>
> >>>>>> Sent: 29 October 2024 06:17
> >>>>>> Subject: Re: [PATCH v4 08/13] dt-bindings: display: Document
> >>>>>> dual-link LVDS display common properties
> >>>>>>
> >>>>>> On 10/28/2024, Liu Ying wrote:
> >>>>>>> Dual-link LVDS displays receive odd pixels and even pixels
> >>>>>>> separately from dual LVDS links.  One link receives odd pixels and
> >>>>>>> the other receives even pixels.  Some of those displays may also
> >>>>>>> use only one LVDS link to receive all pixels, being odd and even agnostic.
> >>>>>>> Document common properties for those displays by extending LVDS
> >>>>>>> display common properties defined in lvds.yaml.
> >>>>>>>
> >>>>>>> Suggested-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> >>>>>>> Signed-off-by: Liu Ying <victor.liu@nxp.com>
> >>>>>>> ---
> >>>>>>> v4:
> >>>>>>> * Squash change for advantech,idk-2121wr.yaml and
> >>>>>>>   panel-simple-lvds-dual-ports.yaml with lvds-dual-ports.yaml.
> >>>>>>> (Rob)
> >>>>>>> * Improve description in lvds-dual-ports.yaml.  (Krzysztof)
> >>>>>>>
> >>>>>>> v3:
> >>>>>>> * New patch.  (Dmitry)
> >>>>>>>
> >>>>>>>  .../bindings/display/lvds-dual-ports.yaml     | 76 +++++++++++++++++++
> >>>>>>>  .../display/panel/advantech,idk-2121wr.yaml   | 14 +---
> >>>>>>>  .../panel/panel-simple-lvds-dual-ports.yaml   | 20 +----
> >>>>>>>  3 files changed, 78 insertions(+), 32 deletions(-)  create mode
> >>>>>>> 100644
> >>>>>>> Documentation/devicetree/bindings/display/lvds-dual-ports.yaml
> >>>>>>>
> >>>>>>> diff --git
> >>>>>>> a/Documentation/devicetree/bindings/display/lvds-dual-ports.yaml
> >>>>>>> b/Documentation/devicetree/bindings/display/lvds-dual-ports.yaml
> >>>>>>> new file mode 100644
> >>>>>>> index 000000000000..5f7a30640404
> >>>>>>> --- /dev/null
> >>>>>>> +++ b/Documentation/devicetree/bindings/display/lvds-dual-ports.ya
> >>>>>>> +++ ml
> >>>>>>> @@ -0,0 +1,76 @@
> >>>>>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML
> >>>>>>> +1.2
> >>>>>>> +---
> >>>>>>> +$id: http://devicetree.org/schemas/display/lvds-dual-ports.yaml#
> >>>>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> >>>>>>> +
> >>>>>>> +title: Dual-link LVDS Display Common Properties
> >>>>>>> +
> >>>>>>> +maintainers:
> >>>>>>> +  - Liu Ying <victor.liu@nxp.com>
> >>>>>>> +
> >>>>>>> +description: |
> >>>>>>> +  Common properties for LVDS displays with dual LVDS links.
> >>>>>>> +Extend LVDS display
> >>>>>>> +  common properties defined in lvds.yaml.
> >>>>>>> +
> >>>>>>> +  Dual-link LVDS displays receive odd pixels and even pixels
> >>>>>>> + separately from  the dual LVDS links. One link receives odd
> >>>>>>> + pixels and the other receives  even pixels. Some of those
> >>>>>>> + displays may also use only one LVDS link to  receive all pixels, being odd and even agnostic.
> >>>>>>> +
> >>>>>>> +allOf:
> >>>>>>> +  - $ref: lvds.yaml#
> >>>>>>> +
> >>>>>>> +properties:
> >>>>>>> +  ports:
> >>>>>>> +    $ref: /schemas/graph.yaml#/properties/ports
> >>>>>>> +
> >>>>>>> +    properties:
> >>>>>>> +      port@0:
> >>>>>>> +        $ref: /schemas/graph.yaml#/$defs/port-base
> >>>>>>> +        unevaluatedProperties: false
> >>>>>>> +        description: the first LVDS input link
> >>>>>>> +
> >>>>>>> +        properties:
> >>>>>>> +          dual-lvds-odd-pixels:
> >>>>>>> +            type: boolean
> >>>>>>> +            description: the first LVDS input link for odd pixels
> >>>>>>> +
> >>>>>>> +          dual-lvds-even-pixels:
> >>>>>>> +            type: boolean
> >>>>>>> +            description: the first LVDS input link for even
> >>>>>>> + pixels
> >>>>>>> +
> >>>>>>> +        oneOf:
> >>>>>>> +          - required: [dual-lvds-odd-pixels]
> >>>>>>> +          - required: [dual-lvds-even-pixels]
> >>>>>>> +          - properties:
> >>>>>>> +              dual-lvds-odd-pixels: false
> >>>>>>> +              dual-lvds-even-pixels: false
> >>>>>>> +
> >>>>>>> +      port@1:
> >>>>>>> +        $ref: /schemas/graph.yaml#/$defs/port-base
> >>>>>>> +        unevaluatedProperties: false
> >>>>>>> +        description: the second LVDS input link
> >>>>>>> +
> >>>>>>> +        properties:
> >>>>>>> +          dual-lvds-odd-pixels:
> >>>>>>> +            type: boolean
> >>>>>>> +            description: the second LVDS input link for odd
> >>>>>>> + pixels
> >>>>>>> +
> >>>>>>> +          dual-lvds-even-pixels:
> >>>>>>> +            type: boolean
> >>>>>>> +            description: the second LVDS input link for even
> >>>>>>> + pixels
> >>>>>>> +
> >>>>>>> +        oneOf:
> >>>>>>> +          - required: [dual-lvds-odd-pixels]
> >>>>>>> +          - required: [dual-lvds-even-pixels]
> >>>>>>> +          - properties:
> >>>>>>> +              dual-lvds-odd-pixels: false
> >>>>>>> +              dual-lvds-even-pixels: false
> >>>>>>
> >>>>>> Hmm, I should require port@0 or port@1.
> >>>>>
> >>>>> For dual LVDS, you need 3 ports as common use case
> >>>>
> >>>> For LVDS panels, only two ports for LVDS sink are needed.
> >>>> For display bridges with LVDS sink, one additional output port is
> >>>> needed.  However, I'm not sure if this output port should be
> >>>> documented in this binding or not, because it doesn't look common enough considering the LVDS
> >> panels.
> >>>>
> >>>>>
> >>>>> 2 input ports and 1 outport and all are required properties.
> >>>>
> >>>> The output port cannot be required for LVDS panels at least.
> >>>
> >>> Ack.
> >>>
> >>>>
> >>>> We need to require one or two input ports, because IT6263 may use one LVDS link or two.
> >>>
> >>> This patch is for generic dual link common cases and is not applicable for IT6263 single link case.
> >>
> >> Based on previous discussion(especially Dmitry's suggestion), this binding should cover display
> >> bridges that can use one LVDS sink port or two LVDS sink ports, like IT6263.  To be clear, those
> >> bridges may have two modes(supported by one
> >> chip) - single LVDS sink link mode and dual LVDS sink link mode.  Those bridges are considered as
> >> common dual-link LVDS displays.  That's why I was asked to extract the common
> >> properties to this schema when adding IT6263 DT binding.
> > 
> > As per [1] and [2] both panels don’t support single LVDS link.
> > IT6263 is bridge device that has single and dual link support.
> > Not sure the single link case has to be taken care in ITE6263 binding itself,
> > Leaving Dual link as it is??
> 
> There are a couple of bridges supporting dual-link LVDS like
> IT6263, see lontium,lt9211.yaml and thine,thc63lvd1024.yaml.
> So, it looks fine for this binding to cover those bridges,
> as those LVDS links are sort of common stuff.

Okay for that to be a follow-up patch.

This looks fine to me with the required addition.

Rob

Re: [PATCH v4 09/13] dt-bindings: display: bridge: Add ITE IT6263 LVDS to HDMI converter

[Rob Herring (Arm)]

On Mon, 28 Oct 2024 10:37:36 +0800, Liu Ying wrote:
> Document ITE IT6263 LVDS to HDMI converter.
> 
> Product link:
> https://www.ite.com.tw/en/product/cate1/IT6263
> 
> Signed-off-by: Liu Ying <victor.liu@nxp.com>
> ---
> v4:
> * Require dual-lvds-odd-pixels or dual-lvds-even-pixels DT properties for
>   port@1.
> * Drop "data-mirror: true"(30-bit LVDS data bit order is not reversed).
> 
> v3:
> * Reference lvds-dual-ports.yaml.  (Dmitry)
> * Add data-mapping DT property.  (Dmitry, Biju)
> * Allow data-mirror.
> * Drop ite,lvds-link-num-data-lanes DT property.  (Dmitry, Biju)
> 
> v2:
> * Document number of LVDS link data lanes.  (Biju)
> * Simplify ports property by dropping "oneOf".  (Rob)
> 
>  .../bindings/display/bridge/ite,it6263.yaml   | 250 ++++++++++++++++++
>  1 file changed, 250 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/display/bridge/ite,it6263.yaml
> 

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

Re: [PATCH v4 04/13] media: uapi: Add MEDIA_BUS_FMT_RGB101010_1X7X5_{SPWG, JEIDA}

[Sakari Ailus]

Hi Ying,

On Mon, Oct 28, 2024 at 10:37:31AM +0800, Liu Ying wrote:
> Add two media bus formats that identify 30-bit RGB pixels transmitted
> by a LVDS link with five differential data pairs, serialized into 7
> time slots, using standard SPWG/VESA or JEIDA data mapping.
> 
> Signed-off-by: Liu Ying <victor.liu@nxp.com>

Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>

It's fine to merge this via another tree, too.

-- 
Regards,

Sakari Ailus

Re: [PATCH v4 04/13] media: uapi: Add MEDIA_BUS_FMT_RGB101010_1X7X5_{SPWG, JEIDA}

[Dmitry Baryshkov]

On Tue, 5 Nov 2024 at 10:53, Sakari Ailus <sakari.ailus@linux.intel.com> wrote:
>
> Hi Ying,
>
> On Mon, Oct 28, 2024 at 10:37:31AM +0800, Liu Ying wrote:
> > Add two media bus formats that identify 30-bit RGB pixels transmitted
> > by a LVDS link with five differential data pairs, serialized into 7
> > time slots, using standard SPWG/VESA or JEIDA data mapping.
> >
> > Signed-off-by: Liu Ying <victor.liu@nxp.com>
>
> Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
>
> It's fine to merge this via another tree, too.

Thank you!


-- 
With best wishes
Dmitry

Re: [PATCH v4 03/13] drm/bridge: fsl-ldb: Use clk_round_rate() to validate "ldb" clock rate

[Liu Ying]

On 10/31/2024, Liu Ying wrote:
> Hi Maxime,
> 
> On 10/30/2024, Maxime Ripard wrote:
>> On Mon, Oct 28, 2024 at 10:37:30AM +0800, Liu Ying wrote:
>>> Multiple display modes could be read from a display device's EDID.
>>> Use clk_round_rate() to validate the "ldb" clock rate for each mode
>>> in drm_bridge_funcs::mode_valid() to filter unsupported modes out.
>>>
>>> Also, since this driver doesn't directly reference pixel clock, use
>>> clk_round_rate() to validate the pixel clock rate against the "ldb"
>>> clock if the "ldb" clock and the pixel clock are sibling in clock
>>> tree.  This is not done in display controller driver because
>>> drm_crtc_helper_funcs::mode_valid() may not decide to do the
>>> validation or not if multiple encoders are connected to the CRTC,
>>> e.g., i.MX93 LCDIF may connect with MIPI DSI controller, LDB and
>>> parallel display output simultaneously.
>>>
>>> Signed-off-by: Liu Ying <victor.liu@nxp.com>
>>> ---
>>> Note that this patch depends on a patch in shawnguo/imx/fixes:
>>> https://patchwork.kernel.org/project/linux-arm-kernel/patch/20241017031146.157996-1-marex@denx.de/
>>
>> I still believe that the root cause of this issue is your clock tree and
>> driver setup, and since I've asked for explanations and didn't get any,
>> I don't really see how we can move forward here.
> 
> Since you asked for a description at *somewhere* in another thread[1],
> can you please suggest a place where this could happen?

I have written a description in the cover letter of this patch series(v7):

https://patchwork.freedesktop.org/series/139266/#rev7

If you don't mind, please provide review comments there, thanks.

> 
> [1] https://lore.kernel.org/imx/47d92ae0-c71a-4c18-9ad7-432c0f70a31f@nxp.com/T/#m587e6a25bdab542d5d99abbf01caaca89495b1d5
> 
>>
>> Maxime
> 

-- 
Regards,
Liu Ying