[PATCH 00/14] Add initial support for the Rockchip RK3588 HDMI TX Controller

[PATCH 00/14] Add initial support for the Rockchip RK3588 HDMI TX Controller

[Cristian Ciocaltea]

The RK3588 SoC family integrates a Quad-Pixel (QP) variant of the
Synopsys DesignWare HDMI TX controller used in the previous SoCs.

It is HDMI 2.1 compliant and supports the following features, among
others:

* Fixed Rate Link (FRL)
* 4K@120Hz and 8K@60Hz video modes
* Variable Refresh Rate (VRR) including Quick Media Switching (QMS)
* Fast Vactive (FVA)
* SCDC I2C DDC access
* TMDS Scrambler enabling 2160p@60Hz with RGB/YCbCr4:4:4
* YCbCr4:2:0 enabling 2160p@60Hz at lower HDMI link speeds
* Multi-stream audio
* Enhanced Audio Return Channel (EARC)

This is the last required component that needs to be supported in order
to enable the HDMI output functionality on the RK3588 based SBCs, such
as the RADXA Rock 5B. The other components are the Video Output
Processor (VOP2) and the Samsung IP based HDMI/eDP TX Combo PHY, for
which basic support has been already made available via [1] and [2],
respectively.

The patches are grouped as follows:
* PATCH 1..7: DW HDMI TX driver refactor to minimize code duplication in
  the new QP driver (no functional changes intended)

* PATCH 8..11: Rockchip DW HDMI glue driver cleanup/improvements (no
  functional changes intended)

* PATCH 12..13: The new DW HDMI QP TX driver reusing the previously
  exported functions and structs from existing DW HDMI TX driver

* PATCH 14: Rockchip DW HDMI glue driver update to support RK3588 and
  make use of DW HDMI QP TX

They provide just the basic HDMI support for now, i.e. RGB output up to
4K@60Hz, without audio, CEC or any of the HDMI 2.1 specific features.
Also note the vop2 driver is currently not able to properly handle all
display modes supported by the connected screens, e.g. it doesn't cope
with non-integer refresh rates.

A possible workaround consists of enabling the display controller to
make use of the clock provided by the HDMI PHY PLL. This is still work
in progress and will be submitted later, as well as the required DTS
updates.

To facilitate testing and experimentation, all HDMI output related
patches, including those part of this series, are available at [3].
So far I could only verify this on the RADXA Rock 3A and 5B boards.

Thanks,
Cristian

[1]: 5a028e8f062f ("drm/rockchip: vop2: Add support for rk3588")
[2]: 553be2830c5f ("phy: rockchip: Add Samsung HDMI/eDP Combo PHY driver")
[3]: https://gitlab.collabora.com/hardware-enablement/rockchip-3588/linux/-/commits/rk3588-hdmi-bridge-v6.10-rc1

Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
---
Cristian Ciocaltea (14):
      drm/bridge: dw-hdmi: Simplify clock handling
      drm/bridge: dw-hdmi: Add dw-hdmi-common.h header
      drm/bridge: dw-hdmi: Commonize dw_hdmi_i2c_adapter()
      drm/bridge: dw-hdmi: Factor out AVI infoframe setup
      drm/bridge: dw-hdmi: Factor out vmode setup
      drm/bridge: dw-hdmi: Factor out hdmi_data_info setup
      drm/bridge: dw-hdmi: Commonize dw_hdmi_connector_create()
      drm/rockchip: dw_hdmi: Use modern drm_device based logging
      drm/rockchip: dw_hdmi: Simplify clock handling
      drm/rockchip: dw_hdmi: Use devm_regulator_get_enable()
      drm/rockchip: dw_hdmi: Drop superfluous assignments of mpll_cfg, cur_ctr and phy_config
      dt-bindings: display: rockchip,dw-hdmi: Add compatible for RK3588
      drm/bridge: synopsys: Add DW HDMI QP TX controller driver
      drm/rockchip: dw_hdmi: Add basic RK3588 support

 .../display/rockchip/rockchip,dw-hdmi.yaml         | 127 +++-
 drivers/gpu/drm/bridge/synopsys/Makefile           |   2 +-
 drivers/gpu/drm/bridge/synopsys/dw-hdmi-common.h   | 179 +++++
 drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c       | 787 +++++++++++++++++++
 drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.h       | 831 +++++++++++++++++++++
 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c          | 353 +++------
 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c        | 351 +++++++--
 include/drm/bridge/dw_hdmi.h                       |   8 +
 8 files changed, 2290 insertions(+), 348 deletions(-)
---
base-commit: 1613e604df0cd359cf2a7fbd9be7a0bcfacfabd0
change-id: 20240601-b4-rk3588-bridge-upstream-a27baff1b8fc


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 01/14] drm/bridge: dw-hdmi: Simplify clock handling

[Cristian Ciocaltea]

Make use of devm_clk_get_enabled() to replace devm_clk_get() and
clk_prepare_enable() for isfr and iahb clocks, and drop the now
unnecessary calls to clk_disable_unprepare().

Similarly, use devm_clk_get_optional_enabled() helper for cec clock,
which additionally allows to remove the -ENOENT test.

Moreover, the clock related members of struct dw_hdmi are not required
anymore, hence drop them.

Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
---
 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 66 ++++++++-----------------------
 1 file changed, 16 insertions(+), 50 deletions(-)

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index 9f2bc932c371..0031f3c54882 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -138,9 +138,6 @@ struct dw_hdmi {
 	struct platform_device *audio;
 	struct platform_device *cec;
 	struct device *dev;
-	struct clk *isfr_clk;
-	struct clk *iahb_clk;
-	struct clk *cec_clk;
 	struct dw_hdmi_i2c *i2c;
 
 	struct hdmi_data_info hdmi_data;
@@ -3326,6 +3323,7 @@ struct dw_hdmi *dw_hdmi_probe(struct platform_device *pdev,
 	struct device_node *ddc_node;
 	struct dw_hdmi_cec_data cec;
 	struct dw_hdmi *hdmi;
+	struct clk *clk;
 	struct resource *iores = NULL;
 	int irq;
 	int ret;
@@ -3405,50 +3403,27 @@ struct dw_hdmi *dw_hdmi_probe(struct platform_device *pdev,
 		hdmi->regm = plat_data->regm;
 	}
 
-	hdmi->isfr_clk = devm_clk_get(hdmi->dev, "isfr");
-	if (IS_ERR(hdmi->isfr_clk)) {
-		ret = PTR_ERR(hdmi->isfr_clk);
+	clk = devm_clk_get_enabled(hdmi->dev, "isfr");
+	if (IS_ERR(clk)) {
+		ret = PTR_ERR(clk);
 		dev_err(hdmi->dev, "Unable to get HDMI isfr clk: %d\n", ret);
 		goto err_res;
 	}
 
-	ret = clk_prepare_enable(hdmi->isfr_clk);
-	if (ret) {
-		dev_err(hdmi->dev, "Cannot enable HDMI isfr clock: %d\n", ret);
-		goto err_res;
-	}
-
-	hdmi->iahb_clk = devm_clk_get(hdmi->dev, "iahb");
-	if (IS_ERR(hdmi->iahb_clk)) {
-		ret = PTR_ERR(hdmi->iahb_clk);
+	clk = devm_clk_get_enabled(hdmi->dev, "iahb");
+	if (IS_ERR(clk)) {
+		ret = PTR_ERR(clk);
 		dev_err(hdmi->dev, "Unable to get HDMI iahb clk: %d\n", ret);
-		goto err_isfr;
-	}
-
-	ret = clk_prepare_enable(hdmi->iahb_clk);
-	if (ret) {
-		dev_err(hdmi->dev, "Cannot enable HDMI iahb clock: %d\n", ret);
-		goto err_isfr;
+		goto err_res;
 	}
 
-	hdmi->cec_clk = devm_clk_get(hdmi->dev, "cec");
-	if (PTR_ERR(hdmi->cec_clk) == -ENOENT) {
-		hdmi->cec_clk = NULL;
-	} else if (IS_ERR(hdmi->cec_clk)) {
-		ret = PTR_ERR(hdmi->cec_clk);
+	clk = devm_clk_get_optional_enabled(hdmi->dev, "cec");
+	if (IS_ERR(clk)) {
+		ret = PTR_ERR(clk);
 		if (ret != -EPROBE_DEFER)
 			dev_err(hdmi->dev, "Cannot get HDMI cec clock: %d\n",
 				ret);
-
-		hdmi->cec_clk = NULL;
-		goto err_iahb;
-	} else {
-		ret = clk_prepare_enable(hdmi->cec_clk);
-		if (ret) {
-			dev_err(hdmi->dev, "Cannot enable HDMI cec clock: %d\n",
-				ret);
-			goto err_iahb;
-		}
+		goto err_res;
 	}
 
 	/* Product and revision IDs */
@@ -3462,12 +3437,12 @@ struct dw_hdmi *dw_hdmi_probe(struct platform_device *pdev,
 		dev_err(dev, "Unsupported HDMI controller (%04x:%02x:%02x)\n",
 			hdmi->version, prod_id0, prod_id1);
 		ret = -ENODEV;
-		goto err_iahb;
+		goto err_res;
 	}
 
 	ret = dw_hdmi_detect_phy(hdmi);
 	if (ret < 0)
-		goto err_iahb;
+		goto err_res;
 
 	dev_info(dev, "Detected HDMI TX controller v%x.%03x %s HDCP (%s)\n",
 		 hdmi->version >> 12, hdmi->version & 0xfff,
@@ -3479,14 +3454,14 @@ struct dw_hdmi *dw_hdmi_probe(struct platform_device *pdev,
 	irq = platform_get_irq(pdev, 0);
 	if (irq < 0) {
 		ret = irq;
-		goto err_iahb;
+		goto err_res;
 	}
 
 	ret = devm_request_threaded_irq(dev, irq, dw_hdmi_hardirq,
 					dw_hdmi_irq, IRQF_SHARED,
 					dev_name(dev), hdmi);
 	if (ret)
-		goto err_iahb;
+		goto err_res;
 
 	/*
 	 * To prevent overflows in HDMI_IH_FC_STAT2, set the clk regenerator
@@ -3603,11 +3578,6 @@ struct dw_hdmi *dw_hdmi_probe(struct platform_device *pdev,
 
 	return hdmi;
 
-err_iahb:
-	clk_disable_unprepare(hdmi->iahb_clk);
-	clk_disable_unprepare(hdmi->cec_clk);
-err_isfr:
-	clk_disable_unprepare(hdmi->isfr_clk);
 err_res:
 	i2c_put_adapter(hdmi->ddc);
 
@@ -3627,10 +3597,6 @@ void dw_hdmi_remove(struct dw_hdmi *hdmi)
 	/* Disable all interrupts */
 	hdmi_writeb(hdmi, ~0, HDMI_IH_MUTE_PHY_STAT0);
 
-	clk_disable_unprepare(hdmi->iahb_clk);
-	clk_disable_unprepare(hdmi->isfr_clk);
-	clk_disable_unprepare(hdmi->cec_clk);
-
 	if (hdmi->i2c)
 		i2c_del_adapter(&hdmi->i2c->adap);
 	else

-- 
2.45.0


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 02/14] drm/bridge: dw-hdmi: Add dw-hdmi-common.h header

[Cristian Ciocaltea]

In preparation to add support for the HDMI 2.1 Quad-Pixel TX Controller
and minimize code duplication as much as possible, export all reusable
functions and provide the related declarations and structs within a new
header file.

For consistency, ensure the newly exported symbols share the 'dw_'
prefix.

Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
---
 drivers/gpu/drm/bridge/synopsys/dw-hdmi-common.h | 167 ++++++++++++++++++++++
 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c        | 170 ++++-------------------
 2 files changed, 194 insertions(+), 143 deletions(-)

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-common.h b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-common.h
new file mode 100644
index 000000000000..28e26ac142e6
--- /dev/null
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-common.h
@@ -0,0 +1,167 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+#ifndef __DW_HDMI_COMMON_H__
+#define __DW_HDMI_COMMON_H__
+
+#include <linux/i2c.h>
+#include <linux/completion.h>
+#include <linux/mutex.h>
+#include <linux/spinlock_types.h>
+
+#include <drm/bridge/dw_hdmi.h>
+#include <drm/drm_connector.h>
+#include <drm/drm_bridge.h>
+#include <drm/drm_modes.h>
+
+#include <sound/hdmi-codec.h>
+
+struct cec_notifier;
+struct device;
+struct drm_bridge_state;
+struct drm_crtc_state;
+struct drm_edid;
+struct pinctrl;
+struct pinctrl_state;
+struct platform_device;
+struct regmap;
+
+#define DDC_CI_ADDR		0x37
+#define DDC_SEGMENT_ADDR	0x30
+
+#define HDMI_EDID_LEN		512
+
+/* DW-HDMI Controller >= 0x200a are at least compliant with SCDC version 1 */
+#define SCDC_MIN_SOURCE_VERSION	0x1
+
+#define HDMI14_MAX_TMDSCLK	340000000
+
+struct hdmi_vmode {
+	bool mdataenablepolarity;
+
+	unsigned int mpixelclock;
+	unsigned int mpixelrepetitioninput;
+	unsigned int mpixelrepetitionoutput;
+	unsigned int mtmdsclock;
+};
+
+struct hdmi_data_info {
+	unsigned int enc_in_bus_format;
+	unsigned int enc_out_bus_format;
+	unsigned int enc_in_encoding;
+	unsigned int enc_out_encoding;
+	unsigned int pix_repet_factor;
+	unsigned int hdcp_enable;
+	struct hdmi_vmode video_mode;
+	bool rgb_limited_range;
+};
+
+struct dw_hdmi_i2c {
+	struct i2c_adapter	adap;
+
+	struct mutex		lock;	/* used to serialize data transfers */
+	struct completion	cmp;
+	u8			stat;
+
+	u8			slave_reg;
+	bool			is_regaddr;
+	bool			is_segment;
+};
+
+struct dw_hdmi_phy_data {
+	enum dw_hdmi_phy_type type;
+	const char *name;
+	unsigned int gen;
+	bool has_svsret;
+	int (*configure)(struct dw_hdmi *hdmi,
+			 const struct dw_hdmi_plat_data *pdata,
+			 unsigned long mpixelclock);
+};
+
+struct dw_hdmi {
+	struct drm_connector connector;
+	struct drm_bridge bridge;
+	struct drm_bridge *next_bridge;
+
+	unsigned int version;
+
+	struct platform_device *audio;
+	struct platform_device *cec;
+	struct device *dev;
+	struct dw_hdmi_i2c *i2c;
+
+	struct hdmi_data_info hdmi_data;
+	const struct dw_hdmi_plat_data *plat_data;
+
+	int vic;
+
+	u8 edid[HDMI_EDID_LEN];
+
+	struct {
+		const struct dw_hdmi_phy_ops *ops;
+		const char *name;
+		void *data;
+		bool enabled;
+	} phy;
+
+	struct drm_display_mode previous_mode;
+
+	struct i2c_adapter *ddc;
+	void __iomem *regs;
+	bool sink_is_hdmi;
+	bool sink_has_audio;
+
+	struct pinctrl *pinctrl;
+	struct pinctrl_state *default_state;
+	struct pinctrl_state *unwedge_state;
+
+	struct mutex mutex;		/* for state below and previous_mode */
+	enum drm_connector_force force;	/* mutex-protected force state */
+	struct drm_connector *curr_conn;/* current connector (only valid when !disabled) */
+	bool disabled;			/* DRM has disabled our bridge */
+	bool bridge_is_on;		/* indicates the bridge is on */
+	bool rxsense;			/* rxsense state */
+	u8 phy_mask;			/* desired phy int mask settings */
+	u8 mc_clkdis;			/* clock disable register */
+
+	spinlock_t audio_lock;
+	struct mutex audio_mutex;
+	unsigned int sample_non_pcm;
+	unsigned int sample_width;
+	unsigned int sample_rate;
+	unsigned int channels;
+	unsigned int audio_cts;
+	unsigned int audio_n;
+	bool audio_enable;
+
+	unsigned int reg_shift;
+	struct regmap *regm;
+	void (*enable_audio)(struct dw_hdmi *hdmi);
+	void (*disable_audio)(struct dw_hdmi *hdmi);
+
+	struct mutex cec_notifier_mutex;
+	struct cec_notifier *cec_notifier;
+
+	hdmi_codec_plugged_cb plugged_cb;
+	struct device *codec_dev;
+	enum drm_connector_status last_connector_result;
+};
+
+void dw_handle_plugged_change(struct dw_hdmi *hdmi, bool plugged);
+bool dw_hdmi_support_scdc(struct dw_hdmi *hdmi,
+			  const struct drm_display_info *display);
+
+enum drm_connector_status
+dw_hdmi_connector_detect(struct drm_connector *connector, bool force);
+
+int dw_hdmi_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);
+void dw_hdmi_bridge_detach(struct drm_bridge *bridge);
+void dw_hdmi_bridge_mode_set(struct drm_bridge *bridge,
+			     const struct drm_display_mode *orig_mode,
+			     const struct drm_display_mode *mode);
+enum drm_connector_status dw_hdmi_bridge_detect(struct drm_bridge *bridge);
+const struct drm_edid *
+dw_hdmi_bridge_edid_read(struct drm_bridge *bridge,
+			 struct drm_connector *connector);
+#endif /* __DW_HDMI_COMMON_H__ */
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index 0031f3c54882..b66877771f56 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -10,10 +10,8 @@
 #include <linux/delay.h>
 #include <linux/err.h>
 #include <linux/hdmi.h>
-#include <linux/i2c.h>
 #include <linux/irq.h>
 #include <linux/module.h>
-#include <linux/mutex.h>
 #include <linux/of.h>
 #include <linux/pinctrl/consumer.h>
 #include <linux/regmap.h>
@@ -25,12 +23,10 @@
 #include <uapi/linux/media-bus-format.h>
 #include <uapi/linux/videodev2.h>
 
-#include <drm/bridge/dw_hdmi.h>
 #include <drm/display/drm_hdmi_helper.h>
 #include <drm/display/drm_scdc_helper.h>
 #include <drm/drm_atomic.h>
 #include <drm/drm_atomic_helper.h>
-#include <drm/drm_bridge.h>
 #include <drm/drm_edid.h>
 #include <drm/drm_of.h>
 #include <drm/drm_print.h>
@@ -38,18 +34,9 @@
 
 #include "dw-hdmi-audio.h"
 #include "dw-hdmi-cec.h"
+#include "dw-hdmi-common.h"
 #include "dw-hdmi.h"
 
-#define DDC_CI_ADDR		0x37
-#define DDC_SEGMENT_ADDR	0x30
-
-#define HDMI_EDID_LEN		512
-
-/* DW-HDMI Controller >= 0x200a are at least compliant with SCDC version 1 */
-#define SCDC_MIN_SOURCE_VERSION	0x1
-
-#define HDMI14_MAX_TMDSCLK	340000000
-
 static const u16 csc_coeff_default[3][4] = {
 	{ 0x2000, 0x0000, 0x0000, 0x0000 },
 	{ 0x0000, 0x2000, 0x0000, 0x0000 },
@@ -86,117 +73,6 @@ static const u16 csc_coeff_rgb_full_to_rgb_limited[3][4] = {
 	{ 0x0000, 0x0000, 0x1b7c, 0x0020 }
 };
 
-struct hdmi_vmode {
-	bool mdataenablepolarity;
-
-	unsigned int mpixelclock;
-	unsigned int mpixelrepetitioninput;
-	unsigned int mpixelrepetitionoutput;
-	unsigned int mtmdsclock;
-};
-
-struct hdmi_data_info {
-	unsigned int enc_in_bus_format;
-	unsigned int enc_out_bus_format;
-	unsigned int enc_in_encoding;
-	unsigned int enc_out_encoding;
-	unsigned int pix_repet_factor;
-	unsigned int hdcp_enable;
-	struct hdmi_vmode video_mode;
-	bool rgb_limited_range;
-};
-
-struct dw_hdmi_i2c {
-	struct i2c_adapter	adap;
-
-	struct mutex		lock;	/* used to serialize data transfers */
-	struct completion	cmp;
-	u8			stat;
-
-	u8			slave_reg;
-	bool			is_regaddr;
-	bool			is_segment;
-};
-
-struct dw_hdmi_phy_data {
-	enum dw_hdmi_phy_type type;
-	const char *name;
-	unsigned int gen;
-	bool has_svsret;
-	int (*configure)(struct dw_hdmi *hdmi,
-			 const struct dw_hdmi_plat_data *pdata,
-			 unsigned long mpixelclock);
-};
-
-struct dw_hdmi {
-	struct drm_connector connector;
-	struct drm_bridge bridge;
-	struct drm_bridge *next_bridge;
-
-	unsigned int version;
-
-	struct platform_device *audio;
-	struct platform_device *cec;
-	struct device *dev;
-	struct dw_hdmi_i2c *i2c;
-
-	struct hdmi_data_info hdmi_data;
-	const struct dw_hdmi_plat_data *plat_data;
-
-	int vic;
-
-	u8 edid[HDMI_EDID_LEN];
-
-	struct {
-		const struct dw_hdmi_phy_ops *ops;
-		const char *name;
-		void *data;
-		bool enabled;
-	} phy;
-
-	struct drm_display_mode previous_mode;
-
-	struct i2c_adapter *ddc;
-	void __iomem *regs;
-	bool sink_is_hdmi;
-	bool sink_has_audio;
-
-	struct pinctrl *pinctrl;
-	struct pinctrl_state *default_state;
-	struct pinctrl_state *unwedge_state;
-
-	struct mutex mutex;		/* for state below and previous_mode */
-	enum drm_connector_force force;	/* mutex-protected force state */
-	struct drm_connector *curr_conn;/* current connector (only valid when !disabled) */
-	bool disabled;			/* DRM has disabled our bridge */
-	bool bridge_is_on;		/* indicates the bridge is on */
-	bool rxsense;			/* rxsense state */
-	u8 phy_mask;			/* desired phy int mask settings */
-	u8 mc_clkdis;			/* clock disable register */
-
-	spinlock_t audio_lock;
-	struct mutex audio_mutex;
-	unsigned int sample_non_pcm;
-	unsigned int sample_width;
-	unsigned int sample_rate;
-	unsigned int channels;
-	unsigned int audio_cts;
-	unsigned int audio_n;
-	bool audio_enable;
-
-	unsigned int reg_shift;
-	struct regmap *regm;
-	void (*enable_audio)(struct dw_hdmi *hdmi);
-	void (*disable_audio)(struct dw_hdmi *hdmi);
-
-	struct mutex cec_notifier_mutex;
-	struct cec_notifier *cec_notifier;
-
-	hdmi_codec_plugged_cb plugged_cb;
-	struct device *codec_dev;
-	enum drm_connector_status last_connector_result;
-};
-
 #define HDMI_IH_PHY_STAT0_RX_SENSE \
 	(HDMI_IH_PHY_STAT0_RX_SENSE0 | HDMI_IH_PHY_STAT0_RX_SENSE1 | \
 	 HDMI_IH_PHY_STAT0_RX_SENSE2 | HDMI_IH_PHY_STAT0_RX_SENSE3)
@@ -219,11 +95,12 @@ static inline u8 hdmi_readb(struct dw_hdmi *hdmi, int offset)
 	return val;
 }
 
-static void handle_plugged_change(struct dw_hdmi *hdmi, bool plugged)
+void dw_handle_plugged_change(struct dw_hdmi *hdmi, bool plugged)
 {
 	if (hdmi->plugged_cb && hdmi->codec_dev)
 		hdmi->plugged_cb(hdmi->codec_dev, plugged);
 }
+EXPORT_SYMBOL_GPL(dw_handle_plugged_change);
 
 int dw_hdmi_set_plugged_cb(struct dw_hdmi *hdmi, hdmi_codec_plugged_cb fn,
 			   struct device *codec_dev)
@@ -234,7 +111,7 @@ int dw_hdmi_set_plugged_cb(struct dw_hdmi *hdmi, hdmi_codec_plugged_cb fn,
 	hdmi->plugged_cb = fn;
 	hdmi->codec_dev = codec_dev;
 	plugged = hdmi->last_connector_result == connector_status_connected;
-	handle_plugged_change(hdmi, plugged);
+	dw_handle_plugged_change(hdmi, plugged);
 	mutex_unlock(&hdmi->mutex);
 
 	return 0;
@@ -1361,8 +1238,8 @@ void dw_hdmi_phy_i2c_write(struct dw_hdmi *hdmi, unsigned short data,
 EXPORT_SYMBOL_GPL(dw_hdmi_phy_i2c_write);
 
 /* Filter out invalid setups to avoid configuring SCDC and scrambling */
-static bool dw_hdmi_support_scdc(struct dw_hdmi *hdmi,
-				 const struct drm_display_info *display)
+bool dw_hdmi_support_scdc(struct dw_hdmi *hdmi,
+			  const struct drm_display_info *display)
 {
 	/* Completely disable SCDC support for older controllers */
 	if (hdmi->version < 0x200a)
@@ -1387,6 +1264,7 @@ static bool dw_hdmi_support_scdc(struct dw_hdmi *hdmi,
 
 	return true;
 }
+EXPORT_SYMBOL_GPL(dw_hdmi_support_scdc);
 
 /*
  * HDMI2.0 Specifies the following procedure for High TMDS Bit Rates:
@@ -2486,13 +2364,14 @@ static const struct drm_edid *dw_hdmi_edid_read(struct dw_hdmi *hdmi,
  * DRM Connector Operations
  */
 
-static enum drm_connector_status
+enum drm_connector_status
 dw_hdmi_connector_detect(struct drm_connector *connector, bool force)
 {
 	struct dw_hdmi *hdmi = container_of(connector, struct dw_hdmi,
 					     connector);
 	return dw_hdmi_detect(hdmi);
 }
+EXPORT_SYMBOL_GPL(dw_hdmi_connector_detect);
 
 static int dw_hdmi_connector_get_modes(struct drm_connector *connector)
 {
@@ -2868,10 +2747,10 @@ static u32 *dw_hdmi_bridge_atomic_get_input_bus_fmts(struct drm_bridge *bridge,
 	return input_fmts;
 }
 
-static int dw_hdmi_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)
+int dw_hdmi_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)
 {
 	struct dw_hdmi *hdmi = bridge->driver_private;
 
@@ -2887,6 +2766,7 @@ static int dw_hdmi_bridge_atomic_check(struct drm_bridge *bridge,
 
 	return 0;
 }
+EXPORT_SYMBOL_GPL(dw_hdmi_bridge_atomic_check);
 
 static int dw_hdmi_bridge_attach(struct drm_bridge *bridge,
 				 enum drm_bridge_attach_flags flags)
@@ -2900,7 +2780,7 @@ static int dw_hdmi_bridge_attach(struct drm_bridge *bridge,
 	return dw_hdmi_connector_create(hdmi);
 }
 
-static void dw_hdmi_bridge_detach(struct drm_bridge *bridge)
+void dw_hdmi_bridge_detach(struct drm_bridge *bridge)
 {
 	struct dw_hdmi *hdmi = bridge->driver_private;
 
@@ -2909,6 +2789,7 @@ static void dw_hdmi_bridge_detach(struct drm_bridge *bridge)
 	hdmi->cec_notifier = NULL;
 	mutex_unlock(&hdmi->cec_notifier_mutex);
 }
+EXPORT_SYMBOL_GPL(dw_hdmi_bridge_detach);
 
 static enum drm_mode_status
 dw_hdmi_bridge_mode_valid(struct drm_bridge *bridge,
@@ -2930,9 +2811,9 @@ dw_hdmi_bridge_mode_valid(struct drm_bridge *bridge,
 	return mode_status;
 }
 
-static void dw_hdmi_bridge_mode_set(struct drm_bridge *bridge,
-				    const struct drm_display_mode *orig_mode,
-				    const struct drm_display_mode *mode)
+void dw_hdmi_bridge_mode_set(struct drm_bridge *bridge,
+			     const struct drm_display_mode *orig_mode,
+			     const struct drm_display_mode *mode)
 {
 	struct dw_hdmi *hdmi = bridge->driver_private;
 
@@ -2943,6 +2824,7 @@ static void dw_hdmi_bridge_mode_set(struct drm_bridge *bridge,
 
 	mutex_unlock(&hdmi->mutex);
 }
+EXPORT_SYMBOL_GPL(dw_hdmi_bridge_mode_set);
 
 static void dw_hdmi_bridge_atomic_disable(struct drm_bridge *bridge,
 					  struct drm_bridge_state *old_state)
@@ -2954,7 +2836,7 @@ static void dw_hdmi_bridge_atomic_disable(struct drm_bridge *bridge,
 	hdmi->curr_conn = NULL;
 	dw_hdmi_update_power(hdmi);
 	dw_hdmi_update_phy_mask(hdmi);
-	handle_plugged_change(hdmi, false);
+	dw_handle_plugged_change(hdmi, false);
 	mutex_unlock(&hdmi->mutex);
 }
 
@@ -2973,24 +2855,26 @@ static void dw_hdmi_bridge_atomic_enable(struct drm_bridge *bridge,
 	hdmi->curr_conn = connector;
 	dw_hdmi_update_power(hdmi);
 	dw_hdmi_update_phy_mask(hdmi);
-	handle_plugged_change(hdmi, true);
+	dw_handle_plugged_change(hdmi, true);
 	mutex_unlock(&hdmi->mutex);
 }
 
-static enum drm_connector_status dw_hdmi_bridge_detect(struct drm_bridge *bridge)
+enum drm_connector_status dw_hdmi_bridge_detect(struct drm_bridge *bridge)
 {
 	struct dw_hdmi *hdmi = bridge->driver_private;
 
 	return dw_hdmi_detect(hdmi);
 }
+EXPORT_SYMBOL_GPL(dw_hdmi_bridge_detect);
 
-static const struct drm_edid *dw_hdmi_bridge_edid_read(struct drm_bridge *bridge,
-						       struct drm_connector *connector)
+const struct drm_edid *dw_hdmi_bridge_edid_read(struct drm_bridge *bridge,
+						struct drm_connector *connector)
 {
 	struct dw_hdmi *hdmi = bridge->driver_private;
 
 	return dw_hdmi_edid_read(hdmi, connector);
 }
+EXPORT_SYMBOL_GPL(dw_hdmi_bridge_edid_read);
 
 static const struct drm_bridge_funcs dw_hdmi_bridge_funcs = {
 	.atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,

-- 
2.45.0


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 03/14] drm/bridge: dw-hdmi: Commonize dw_hdmi_i2c_adapter()

[Cristian Ciocaltea]

In preparation to add support for the HDMI 2.1 Quad-Pixel TX Controller
and minimize code duplication, export dw_hdmi_i2c_adapter() while adding
a new parameter to allow using a different i2c_algorithm.

Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
---
 drivers/gpu/drm/bridge/synopsys/dw-hdmi-common.h | 2 ++
 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c        | 8 +++++---
 2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-common.h b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-common.h
index 28e26ac142e6..ffd2ee16466c 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-common.h
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-common.h
@@ -146,6 +146,8 @@ struct dw_hdmi {
 };
 
 void dw_handle_plugged_change(struct dw_hdmi *hdmi, bool plugged);
+struct i2c_adapter *dw_hdmi_i2c_adapter(struct dw_hdmi *hdmi,
+					const struct i2c_algorithm *algo);
 bool dw_hdmi_support_scdc(struct dw_hdmi *hdmi,
 			  const struct drm_display_info *display);
 
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index b66877771f56..5dd0e2bc080d 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -376,7 +376,8 @@ static const struct i2c_algorithm dw_hdmi_algorithm = {
 	.functionality	= dw_hdmi_i2c_func,
 };
 
-static struct i2c_adapter *dw_hdmi_i2c_adapter(struct dw_hdmi *hdmi)
+struct i2c_adapter *dw_hdmi_i2c_adapter(struct dw_hdmi *hdmi,
+					const struct i2c_algorithm *algo)
 {
 	struct i2c_adapter *adap;
 	struct dw_hdmi_i2c *i2c;
@@ -392,7 +393,7 @@ static struct i2c_adapter *dw_hdmi_i2c_adapter(struct dw_hdmi *hdmi)
 	adap = &i2c->adap;
 	adap->owner = THIS_MODULE;
 	adap->dev.parent = hdmi->dev;
-	adap->algo = &dw_hdmi_algorithm;
+	adap->algo = algo ? algo : &dw_hdmi_algorithm;
 	strscpy(adap->name, "DesignWare HDMI", sizeof(adap->name));
 	i2c_set_adapdata(adap, hdmi);
 
@@ -409,6 +410,7 @@ static struct i2c_adapter *dw_hdmi_i2c_adapter(struct dw_hdmi *hdmi)
 
 	return adap;
 }
+EXPORT_SYMBOL_GPL(dw_hdmi_i2c_adapter);
 
 static void hdmi_set_cts_n(struct dw_hdmi *hdmi, unsigned int cts,
 			   unsigned int n)
@@ -3373,7 +3375,7 @@ struct dw_hdmi *dw_hdmi_probe(struct platform_device *pdev,
 			}
 		}
 
-		hdmi->ddc = dw_hdmi_i2c_adapter(hdmi);
+		hdmi->ddc = dw_hdmi_i2c_adapter(hdmi, NULL);
 		if (IS_ERR(hdmi->ddc))
 			hdmi->ddc = NULL;
 	}

-- 
2.45.0


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 04/14] drm/bridge: dw-hdmi: Factor out AVI infoframe setup

[Cristian Ciocaltea]

In preparation to add support for the HDMI 2.1 Quad-Pixel TX Controller
and minimize code duplication, factor out the AVI infoframe setup from
hdmi_config_AVI() into a common dw_hdmi_prep_avi_infoframe() helper.

Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
---
 drivers/gpu/drm/bridge/synopsys/dw-hdmi-common.h |  4 ++
 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c        | 57 ++++++++++++++----------
 2 files changed, 37 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-common.h b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-common.h
index ffd2ee16466c..0569196bbe3b 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-common.h
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-common.h
@@ -150,6 +150,10 @@ struct i2c_adapter *dw_hdmi_i2c_adapter(struct dw_hdmi *hdmi,
 					const struct i2c_algorithm *algo);
 bool dw_hdmi_support_scdc(struct dw_hdmi *hdmi,
 			  const struct drm_display_info *display);
+void dw_hdmi_prep_avi_infoframe(struct hdmi_avi_infoframe *frame,
+				struct dw_hdmi *hdmi,
+				const struct drm_connector *connector,
+				const struct drm_display_mode *mode);
 
 enum drm_connector_status
 dw_hdmi_connector_detect(struct drm_connector *connector, bool force);
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index 5dd0e2bc080d..81d73fbcb2e6 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -1638,66 +1638,75 @@ static void hdmi_tx_hdcp_config(struct dw_hdmi *hdmi)
 		  HDMI_A_HDCPCFG1_ENCRYPTIONDISABLE_MASK, HDMI_A_HDCPCFG1);
 }
 
-static void hdmi_config_AVI(struct dw_hdmi *hdmi,
-			    const struct drm_connector *connector,
-			    const struct drm_display_mode *mode)
+void dw_hdmi_prep_avi_infoframe(struct hdmi_avi_infoframe *frame,
+				struct dw_hdmi *hdmi,
+				const struct drm_connector *connector,
+				const struct drm_display_mode *mode)
 {
-	struct hdmi_avi_infoframe frame;
-	u8 val;
-
 	/* Initialise info frame from DRM mode */
-	drm_hdmi_avi_infoframe_from_display_mode(&frame, connector, mode);
+	drm_hdmi_avi_infoframe_from_display_mode(frame, connector, mode);
 
 	if (hdmi_bus_fmt_is_rgb(hdmi->hdmi_data.enc_out_bus_format)) {
-		drm_hdmi_avi_infoframe_quant_range(&frame, connector, mode,
+		drm_hdmi_avi_infoframe_quant_range(frame, connector, mode,
 						   hdmi->hdmi_data.rgb_limited_range ?
 						   HDMI_QUANTIZATION_RANGE_LIMITED :
 						   HDMI_QUANTIZATION_RANGE_FULL);
 	} else {
-		frame.quantization_range = HDMI_QUANTIZATION_RANGE_DEFAULT;
-		frame.ycc_quantization_range =
+		frame->quantization_range = HDMI_QUANTIZATION_RANGE_DEFAULT;
+		frame->ycc_quantization_range =
 			HDMI_YCC_QUANTIZATION_RANGE_LIMITED;
 	}
 
 	if (hdmi_bus_fmt_is_yuv444(hdmi->hdmi_data.enc_out_bus_format))
-		frame.colorspace = HDMI_COLORSPACE_YUV444;
+		frame->colorspace = HDMI_COLORSPACE_YUV444;
 	else if (hdmi_bus_fmt_is_yuv422(hdmi->hdmi_data.enc_out_bus_format))
-		frame.colorspace = HDMI_COLORSPACE_YUV422;
+		frame->colorspace = HDMI_COLORSPACE_YUV422;
 	else if (hdmi_bus_fmt_is_yuv420(hdmi->hdmi_data.enc_out_bus_format))
-		frame.colorspace = HDMI_COLORSPACE_YUV420;
+		frame->colorspace = HDMI_COLORSPACE_YUV420;
 	else
-		frame.colorspace = HDMI_COLORSPACE_RGB;
+		frame->colorspace = HDMI_COLORSPACE_RGB;
 
 	/* Set up colorimetry */
 	if (!hdmi_bus_fmt_is_rgb(hdmi->hdmi_data.enc_out_bus_format)) {
 		switch (hdmi->hdmi_data.enc_out_encoding) {
 		case V4L2_YCBCR_ENC_601:
 			if (hdmi->hdmi_data.enc_in_encoding == V4L2_YCBCR_ENC_XV601)
-				frame.colorimetry = HDMI_COLORIMETRY_EXTENDED;
+				frame->colorimetry = HDMI_COLORIMETRY_EXTENDED;
 			else
-				frame.colorimetry = HDMI_COLORIMETRY_ITU_601;
-			frame.extended_colorimetry =
+				frame->colorimetry = HDMI_COLORIMETRY_ITU_601;
+			frame->extended_colorimetry =
 					HDMI_EXTENDED_COLORIMETRY_XV_YCC_601;
 			break;
 		case V4L2_YCBCR_ENC_709:
 			if (hdmi->hdmi_data.enc_in_encoding == V4L2_YCBCR_ENC_XV709)
-				frame.colorimetry = HDMI_COLORIMETRY_EXTENDED;
+				frame->colorimetry = HDMI_COLORIMETRY_EXTENDED;
 			else
-				frame.colorimetry = HDMI_COLORIMETRY_ITU_709;
-			frame.extended_colorimetry =
+				frame->colorimetry = HDMI_COLORIMETRY_ITU_709;
+			frame->extended_colorimetry =
 					HDMI_EXTENDED_COLORIMETRY_XV_YCC_709;
 			break;
 		default: /* Carries no data */
-			frame.colorimetry = HDMI_COLORIMETRY_ITU_601;
-			frame.extended_colorimetry =
+			frame->colorimetry = HDMI_COLORIMETRY_ITU_601;
+			frame->extended_colorimetry =
 					HDMI_EXTENDED_COLORIMETRY_XV_YCC_601;
 			break;
 		}
 	} else {
-		frame.colorimetry = HDMI_COLORIMETRY_NONE;
-		frame.extended_colorimetry =
+		frame->colorimetry = HDMI_COLORIMETRY_NONE;
+		frame->extended_colorimetry =
 			HDMI_EXTENDED_COLORIMETRY_XV_YCC_601;
 	}
+}
+EXPORT_SYMBOL_GPL(dw_hdmi_prep_avi_infoframe);
+
+static void hdmi_config_AVI(struct dw_hdmi *hdmi,
+			    const struct drm_connector *connector,
+			    const struct drm_display_mode *mode)
+{
+	struct hdmi_avi_infoframe frame;
+	u8 val;
+
+	dw_hdmi_prep_avi_infoframe(&frame, hdmi, connector, mode);
 
 	/*
 	 * The Designware IP uses a different byte format from standard

-- 
2.45.0


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 05/14] drm/bridge: dw-hdmi: Factor out vmode setup

[Cristian Ciocaltea]

In preparation to add support for the HDMI 2.1 Quad-Pixel TX Controller
and minimize code duplication, factor out the vmode setup from
hdmi_av_composer() into a common dw_hdmi_prep_vmode() helper.

Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
---
 drivers/gpu/drm/bridge/synopsys/dw-hdmi-common.h |  2 ++
 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c        | 23 ++++++++++++++++-------
 2 files changed, 18 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-common.h b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-common.h
index 0569196bbe3b..e73b8eb7528b 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-common.h
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-common.h
@@ -154,6 +154,8 @@ void dw_hdmi_prep_avi_infoframe(struct hdmi_avi_infoframe *frame,
 				struct dw_hdmi *hdmi,
 				const struct drm_connector *connector,
 				const struct drm_display_mode *mode);
+struct hdmi_vmode *dw_hdmi_prep_vmode(struct dw_hdmi *hdmi,
+				      const struct drm_display_mode *mode);
 
 enum drm_connector_status
 dw_hdmi_connector_detect(struct drm_connector *connector, bool force);
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index 81d73fbcb2e6..5cf929f68ae9 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -1864,15 +1864,10 @@ static void hdmi_config_drm_infoframe(struct dw_hdmi *hdmi,
 		  HDMI_FC_PACKET_TX_EN_DRM_MASK, HDMI_FC_PACKET_TX_EN);
 }
 
-static void hdmi_av_composer(struct dw_hdmi *hdmi,
-			     const struct drm_display_info *display,
-			     const struct drm_display_mode *mode)
+struct hdmi_vmode *dw_hdmi_prep_vmode(struct dw_hdmi *hdmi,
+				      const struct drm_display_mode *mode)
 {
-	u8 inv_val, bytes;
-	const struct drm_hdmi_info *hdmi_info = &display->hdmi;
 	struct hdmi_vmode *vmode = &hdmi->hdmi_data.video_mode;
-	int hblank, vblank, h_de_hs, v_de_vs, hsync_len, vsync_len;
-	unsigned int vdisplay, hdisplay;
 
 	vmode->mpixelclock = mode->clock * 1000;
 
@@ -1900,6 +1895,20 @@ static void hdmi_av_composer(struct dw_hdmi *hdmi,
 
 	dev_dbg(hdmi->dev, "final tmdsclock = %d\n", vmode->mtmdsclock);
 
+	return vmode;
+}
+EXPORT_SYMBOL_GPL(dw_hdmi_prep_vmode);
+
+static void hdmi_av_composer(struct dw_hdmi *hdmi,
+			     const struct drm_display_info *display,
+			     const struct drm_display_mode *mode)
+{
+	u8 inv_val, bytes;
+	const struct drm_hdmi_info *hdmi_info = &display->hdmi;
+	struct hdmi_vmode *vmode = dw_hdmi_prep_vmode(hdmi, mode);
+	int hblank, vblank, h_de_hs, v_de_vs, hsync_len, vsync_len;
+	unsigned int vdisplay, hdisplay;
+
 	/* Set up HDMI_FC_INVIDCONF */
 	inv_val = (hdmi->hdmi_data.hdcp_enable ||
 		   (dw_hdmi_support_scdc(hdmi, display) &&

-- 
2.45.0


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 06/14] drm/bridge: dw-hdmi: Factor out hdmi_data_info setup

[Cristian Ciocaltea]

In preparation to add support for the HDMI 2.1 Quad-Pixel TX Controller
and minimize code duplication, factor out the hdmi_data_info setup from
dw_hdmi_setup() into a common dw_hdmi_prep_data() helper.

Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
---
 drivers/gpu/drm/bridge/synopsys/dw-hdmi-common.h |  2 ++
 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c        | 21 ++++++++++++++-------
 2 files changed, 16 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-common.h b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-common.h
index e73b8eb7528b..5fb65db4aaea 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-common.h
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-common.h
@@ -156,6 +156,8 @@ void dw_hdmi_prep_avi_infoframe(struct hdmi_avi_infoframe *frame,
 				const struct drm_display_mode *mode);
 struct hdmi_vmode *dw_hdmi_prep_vmode(struct dw_hdmi *hdmi,
 				      const struct drm_display_mode *mode);
+void dw_hdmi_prep_data(struct dw_hdmi *hdmi,
+		       const struct drm_display_mode *mode);
 
 enum drm_connector_status
 dw_hdmi_connector_detect(struct drm_connector *connector, bool force);
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index 5cf929f68ae9..d124c781da20 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -2133,14 +2133,9 @@ static void hdmi_disable_overflow_interrupts(struct dw_hdmi *hdmi)
 		    HDMI_IH_MUTE_FC_STAT2);
 }
 
-static int dw_hdmi_setup(struct dw_hdmi *hdmi,
-			 const struct drm_connector *connector,
-			 const struct drm_display_mode *mode)
+void dw_hdmi_prep_data(struct dw_hdmi *hdmi,
+		       const struct drm_display_mode *mode)
 {
-	int ret;
-
-	hdmi_disable_overflow_interrupts(hdmi);
-
 	hdmi->vic = drm_match_cea_mode(mode);
 
 	if (!hdmi->vic) {
@@ -2180,6 +2175,18 @@ static int dw_hdmi_setup(struct dw_hdmi *hdmi,
 	hdmi->hdmi_data.pix_repet_factor = 0;
 	hdmi->hdmi_data.hdcp_enable = 0;
 	hdmi->hdmi_data.video_mode.mdataenablepolarity = true;
+}
+EXPORT_SYMBOL_GPL(dw_hdmi_prep_data);
+
+static int dw_hdmi_setup(struct dw_hdmi *hdmi,
+			 const struct drm_connector *connector,
+			 const struct drm_display_mode *mode)
+{
+	int ret;
+
+	hdmi_disable_overflow_interrupts(hdmi);
+
+	dw_hdmi_prep_data(hdmi, mode);
 
 	/* HDMI Initialization Step B.1 */
 	hdmi_av_composer(hdmi, &connector->display_info, mode);

-- 
2.45.0


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 07/14] drm/bridge: dw-hdmi: Commonize dw_hdmi_connector_create()

[Cristian Ciocaltea]

In preparation to add support for the HDMI 2.1 Quad-Pixel TX Controller
and minimize code duplication, export dw_hdmi_connector_create()
function, while adding a new parameter to allow using a different
drm_connector_funcs structure.

Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
---
 drivers/gpu/drm/bridge/synopsys/dw-hdmi-common.h | 2 ++
 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c        | 8 +++++---
 2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-common.h b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-common.h
index 5fb65db4aaea..512fbaa1bb0c 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-common.h
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-common.h
@@ -161,6 +161,8 @@ void dw_hdmi_prep_data(struct dw_hdmi *hdmi,
 
 enum drm_connector_status
 dw_hdmi_connector_detect(struct drm_connector *connector, bool force);
+int dw_hdmi_connector_create(struct dw_hdmi *hdmi,
+			     const struct drm_connector_funcs *funcs);
 
 int dw_hdmi_bridge_atomic_check(struct drm_bridge *bridge,
 				struct drm_bridge_state *bridge_state,
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index d124c781da20..95c9ccb809ec 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -2469,7 +2469,8 @@ static const struct drm_connector_helper_funcs dw_hdmi_connector_helper_funcs =
 	.atomic_check = dw_hdmi_connector_atomic_check,
 };
 
-static int dw_hdmi_connector_create(struct dw_hdmi *hdmi)
+int dw_hdmi_connector_create(struct dw_hdmi *hdmi,
+			     const struct drm_connector_funcs *funcs)
 {
 	struct drm_connector *connector = &hdmi->connector;
 	struct cec_connector_info conn_info;
@@ -2487,7 +2488,7 @@ static int dw_hdmi_connector_create(struct dw_hdmi *hdmi)
 	drm_connector_helper_add(connector, &dw_hdmi_connector_helper_funcs);
 
 	drm_connector_init_with_ddc(hdmi->bridge.dev, connector,
-				    &dw_hdmi_connector_funcs,
+				    funcs ? funcs : &dw_hdmi_connector_funcs,
 				    DRM_MODE_CONNECTOR_HDMIA,
 				    hdmi->ddc);
 
@@ -2516,6 +2517,7 @@ static int dw_hdmi_connector_create(struct dw_hdmi *hdmi)
 
 	return 0;
 }
+EXPORT_SYMBOL_GPL(dw_hdmi_connector_create);
 
 /* -----------------------------------------------------------------------------
  * DRM Bridge Operations
@@ -2804,7 +2806,7 @@ static int dw_hdmi_bridge_attach(struct drm_bridge *bridge,
 		return drm_bridge_attach(bridge->encoder, hdmi->next_bridge,
 					 bridge, flags);
 
-	return dw_hdmi_connector_create(hdmi);
+	return dw_hdmi_connector_create(hdmi, NULL);
 }
 
 void dw_hdmi_bridge_detach(struct drm_bridge *bridge)

-- 
2.45.0


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 08/14] drm/rockchip: dw_hdmi: Use modern drm_device based logging

[Cristian Ciocaltea]

Prefer drm_{err|info|dbg}() over deprecated DRM_DEV_{ERROR|INFO|DEBUG}()
logging macros.

Conversion done with the help of the following semantic patch, followed
by a few minor indentation adjustments:

@@
identifier T;
@@

(
-DRM_DEV_ERROR(T->dev,
+drm_err(T,
...)
|
-DRM_DEV_INFO(T->dev,
+drm_info(T,
...)
|
-DRM_DEV_DEBUG(T->dev,
+drm_dbg(T,
...)
)

Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
---
 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 24 +++++++++++-------------
 1 file changed, 11 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index fe33092abbe7..2509ce19313f 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -212,7 +212,7 @@ static int rockchip_hdmi_parse_dt(struct rockchip_hdmi *hdmi)
 
 	hdmi->regmap = syscon_regmap_lookup_by_phandle(np, "rockchip,grf");
 	if (IS_ERR(hdmi->regmap)) {
-		DRM_DEV_ERROR(hdmi->dev, "Unable to get rockchip,grf\n");
+		drm_err(hdmi, "Unable to get rockchip,grf\n");
 		return PTR_ERR(hdmi->regmap);
 	}
 
@@ -223,7 +223,7 @@ static int rockchip_hdmi_parse_dt(struct rockchip_hdmi *hdmi)
 	if (PTR_ERR(hdmi->ref_clk) == -EPROBE_DEFER) {
 		return -EPROBE_DEFER;
 	} else if (IS_ERR(hdmi->ref_clk)) {
-		DRM_DEV_ERROR(hdmi->dev, "failed to get reference clock\n");
+		drm_err(hdmi, "failed to get reference clock\n");
 		return PTR_ERR(hdmi->ref_clk);
 	}
 
@@ -233,7 +233,7 @@ static int rockchip_hdmi_parse_dt(struct rockchip_hdmi *hdmi)
 	} else if (PTR_ERR(hdmi->grf_clk) == -EPROBE_DEFER) {
 		return -EPROBE_DEFER;
 	} else if (IS_ERR(hdmi->grf_clk)) {
-		DRM_DEV_ERROR(hdmi->dev, "failed to get grf clock\n");
+		drm_err(hdmi, "failed to get grf clock\n");
 		return PTR_ERR(hdmi->grf_clk);
 	}
 
@@ -322,17 +322,16 @@ static void dw_hdmi_rockchip_encoder_enable(struct drm_encoder *encoder)
 
 	ret = clk_prepare_enable(hdmi->grf_clk);
 	if (ret < 0) {
-		DRM_DEV_ERROR(hdmi->dev, "failed to enable grfclk %d\n", ret);
+		drm_err(hdmi, "failed to enable grfclk %d\n", ret);
 		return;
 	}
 
 	ret = regmap_write(hdmi->regmap, hdmi->chip_data->lcdsel_grf_reg, val);
 	if (ret != 0)
-		DRM_DEV_ERROR(hdmi->dev, "Could not write to GRF: %d\n", ret);
+		drm_err(hdmi, "Could not write to GRF: %d\n", ret);
 
 	clk_disable_unprepare(hdmi->grf_clk);
-	DRM_DEV_DEBUG(hdmi->dev, "vop %s output to hdmi\n",
-		      ret ? "LIT" : "BIG");
+	drm_dbg(hdmi, "vop %s output to hdmi\n", ret ? "LIT" : "BIG");
 }
 
 static int
@@ -592,7 +591,7 @@ static int dw_hdmi_rockchip_bind(struct device *dev, struct device *master,
 	ret = rockchip_hdmi_parse_dt(hdmi);
 	if (ret) {
 		if (ret != -EPROBE_DEFER)
-			DRM_DEV_ERROR(hdmi->dev, "Unable to parse OF data\n");
+			drm_err(hdmi, "Unable to parse OF data\n");
 		return ret;
 	}
 
@@ -600,26 +599,25 @@ static int dw_hdmi_rockchip_bind(struct device *dev, struct device *master,
 	if (IS_ERR(hdmi->phy)) {
 		ret = PTR_ERR(hdmi->phy);
 		if (ret != -EPROBE_DEFER)
-			DRM_DEV_ERROR(hdmi->dev, "failed to get phy\n");
+			drm_err(hdmi, "failed to get phy\n");
 		return ret;
 	}
 
 	ret = regulator_enable(hdmi->avdd_0v9);
 	if (ret) {
-		DRM_DEV_ERROR(hdmi->dev, "failed to enable avdd0v9: %d\n", ret);
+		drm_err(hdmi, "failed to enable avdd0v9: %d\n", ret);
 		goto err_avdd_0v9;
 	}
 
 	ret = regulator_enable(hdmi->avdd_1v8);
 	if (ret) {
-		DRM_DEV_ERROR(hdmi->dev, "failed to enable avdd1v8: %d\n", ret);
+		drm_err(hdmi, "failed to enable avdd1v8: %d\n", ret);
 		goto err_avdd_1v8;
 	}
 
 	ret = clk_prepare_enable(hdmi->ref_clk);
 	if (ret) {
-		DRM_DEV_ERROR(hdmi->dev, "Failed to enable HDMI reference clock: %d\n",
-			      ret);
+		drm_err(hdmi, "Failed to enable HDMI reference clock: %d\n", ret);
 		goto err_clk;
 	}
 

-- 
2.45.0


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 09/14] drm/rockchip: dw_hdmi: Simplify clock handling

[Cristian Ciocaltea]

Make use of devm_clk_get_optional_enabled() to replace devm_clk_get()
and clk_prepare_enable() for ref_clk and drop the now unnecessary calls
to clk_disable_unprepare().

Additionally, use devm_clk_get_optional() helper for grf_clk to replace
the open coding call to devm_clk_get() followed by the -ENOENT test.

Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
---
 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 38 +++++++++++------------------
 1 file changed, 14 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index 2509ce19313f..7d07039ef096 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -209,6 +209,7 @@ static const struct dw_hdmi_phy_config rockchip_phy_config[] = {
 static int rockchip_hdmi_parse_dt(struct rockchip_hdmi *hdmi)
 {
 	struct device_node *np = hdmi->dev->of_node;
+	int ret;
 
 	hdmi->regmap = syscon_regmap_lookup_by_phandle(np, "rockchip,grf");
 	if (IS_ERR(hdmi->regmap)) {
@@ -216,25 +217,23 @@ static int rockchip_hdmi_parse_dt(struct rockchip_hdmi *hdmi)
 		return PTR_ERR(hdmi->regmap);
 	}
 
-	hdmi->ref_clk = devm_clk_get_optional(hdmi->dev, "ref");
+	hdmi->ref_clk = devm_clk_get_optional_enabled(hdmi->dev, "ref");
 	if (!hdmi->ref_clk)
-		hdmi->ref_clk = devm_clk_get_optional(hdmi->dev, "vpll");
+		hdmi->ref_clk = devm_clk_get_optional_enabled(hdmi->dev, "vpll");
 
-	if (PTR_ERR(hdmi->ref_clk) == -EPROBE_DEFER) {
-		return -EPROBE_DEFER;
-	} else if (IS_ERR(hdmi->ref_clk)) {
-		drm_err(hdmi, "failed to get reference clock\n");
-		return PTR_ERR(hdmi->ref_clk);
+	if (IS_ERR(hdmi->ref_clk)) {
+		ret = PTR_ERR(hdmi->ref_clk);
+		if (ret != -EPROBE_DEFER)
+			drm_err(hdmi, "failed to get reference clock\n");
+		return ret;
 	}
 
-	hdmi->grf_clk = devm_clk_get(hdmi->dev, "grf");
-	if (PTR_ERR(hdmi->grf_clk) == -ENOENT) {
-		hdmi->grf_clk = NULL;
-	} else if (PTR_ERR(hdmi->grf_clk) == -EPROBE_DEFER) {
-		return -EPROBE_DEFER;
-	} else if (IS_ERR(hdmi->grf_clk)) {
-		drm_err(hdmi, "failed to get grf clock\n");
-		return PTR_ERR(hdmi->grf_clk);
+	hdmi->grf_clk = devm_clk_get_optional(hdmi->dev, "grf");
+	if (IS_ERR(hdmi->grf_clk)) {
+		ret = PTR_ERR(hdmi->grf_clk);
+		if (ret != -EPROBE_DEFER)
+			drm_err(hdmi, "failed to get grf clock\n");
+		return ret;
 	}
 
 	hdmi->avdd_0v9 = devm_regulator_get(hdmi->dev, "avdd-0v9");
@@ -615,12 +614,6 @@ static int dw_hdmi_rockchip_bind(struct device *dev, struct device *master,
 		goto err_avdd_1v8;
 	}
 
-	ret = clk_prepare_enable(hdmi->ref_clk);
-	if (ret) {
-		drm_err(hdmi, "Failed to enable HDMI reference clock: %d\n", ret);
-		goto err_clk;
-	}
-
 	if (hdmi->chip_data == &rk3568_chip_data) {
 		regmap_write(hdmi->regmap, RK3568_GRF_VO_CON1,
 			     HIWORD_UPDATE(RK3568_HDMI_SDAIN_MSK |
@@ -649,8 +642,6 @@ static int dw_hdmi_rockchip_bind(struct device *dev, struct device *master,
 
 err_bind:
 	drm_encoder_cleanup(encoder);
-	clk_disable_unprepare(hdmi->ref_clk);
-err_clk:
 	regulator_disable(hdmi->avdd_1v8);
 err_avdd_1v8:
 	regulator_disable(hdmi->avdd_0v9);
@@ -665,7 +656,6 @@ static void dw_hdmi_rockchip_unbind(struct device *dev, struct device *master,
 
 	dw_hdmi_unbind(hdmi->hdmi);
 	drm_encoder_cleanup(&hdmi->encoder.encoder);
-	clk_disable_unprepare(hdmi->ref_clk);
 
 	regulator_disable(hdmi->avdd_1v8);
 	regulator_disable(hdmi->avdd_0v9);

-- 
2.45.0


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 10/14] drm/rockchip: dw_hdmi: Use devm_regulator_get_enable()

[Cristian Ciocaltea]

The regulators are only enabled at bind() and disabled at unbind(),
hence replace the boilerplate code by making use of
devm_regulator_get_enable() helper.

Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
---
 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 34 +++++------------------------
 1 file changed, 6 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index 7d07039ef096..edfd877c98fc 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -77,8 +77,6 @@ struct rockchip_hdmi {
 	struct clk *ref_clk;
 	struct clk *grf_clk;
 	struct dw_hdmi *hdmi;
-	struct regulator *avdd_0v9;
-	struct regulator *avdd_1v8;
 	struct phy *phy;
 };
 
@@ -236,15 +234,13 @@ static int rockchip_hdmi_parse_dt(struct rockchip_hdmi *hdmi)
 		return ret;
 	}
 
-	hdmi->avdd_0v9 = devm_regulator_get(hdmi->dev, "avdd-0v9");
-	if (IS_ERR(hdmi->avdd_0v9))
-		return PTR_ERR(hdmi->avdd_0v9);
+	ret = devm_regulator_get_enable(hdmi->dev, "avdd-0v9");
+	if (ret)
+		return ret;
 
-	hdmi->avdd_1v8 = devm_regulator_get(hdmi->dev, "avdd-1v8");
-	if (IS_ERR(hdmi->avdd_1v8))
-		return PTR_ERR(hdmi->avdd_1v8);
+	ret = devm_regulator_get_enable(hdmi->dev, "avdd-1v8");
 
-	return 0;
+	return ret;
 }
 
 static enum drm_mode_status
@@ -602,18 +598,6 @@ static int dw_hdmi_rockchip_bind(struct device *dev, struct device *master,
 		return ret;
 	}
 
-	ret = regulator_enable(hdmi->avdd_0v9);
-	if (ret) {
-		drm_err(hdmi, "failed to enable avdd0v9: %d\n", ret);
-		goto err_avdd_0v9;
-	}
-
-	ret = regulator_enable(hdmi->avdd_1v8);
-	if (ret) {
-		drm_err(hdmi, "failed to enable avdd1v8: %d\n", ret);
-		goto err_avdd_1v8;
-	}
-
 	if (hdmi->chip_data == &rk3568_chip_data) {
 		regmap_write(hdmi->regmap, RK3568_GRF_VO_CON1,
 			     HIWORD_UPDATE(RK3568_HDMI_SDAIN_MSK |
@@ -642,10 +626,7 @@ static int dw_hdmi_rockchip_bind(struct device *dev, struct device *master,
 
 err_bind:
 	drm_encoder_cleanup(encoder);
-	regulator_disable(hdmi->avdd_1v8);
-err_avdd_1v8:
-	regulator_disable(hdmi->avdd_0v9);
-err_avdd_0v9:
+
 	return ret;
 }
 
@@ -656,9 +637,6 @@ static void dw_hdmi_rockchip_unbind(struct device *dev, struct device *master,
 
 	dw_hdmi_unbind(hdmi->hdmi);
 	drm_encoder_cleanup(&hdmi->encoder.encoder);
-
-	regulator_disable(hdmi->avdd_1v8);
-	regulator_disable(hdmi->avdd_0v9);
 }
 
 static const struct component_ops dw_hdmi_rockchip_ops = {

-- 
2.45.0


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 11/14] drm/rockchip: dw_hdmi: Drop superfluous assignments of mpll_cfg, cur_ctr and phy_config

[Cristian Ciocaltea]

The mpll_cfg, cur_ctr and phy_config members in struct dw_hdmi_plat_data
are only used to configure the Synopsys PHYs supported internally by DW
HDMI transmitter driver (gpu/drm/bridge/synopsys/dw-hdmi.c), via
hdmi_phy_configure_dwc_hdmi_3d_tx(), which is further invoked from
dw_hdmi_phy_init().  This is part of the internal
dw_hdmi_synopsys_phy_ops struct, managed within dw_hdmi_detect_phy().

To handle vendor PHYs, DW HDMI driver doesn't make use of the internal
PHY ops and, instead, relies on the glue layer to provide the phy_ops
and phy_name members of struct dw_hdmi_plat_data.

Drop the unnecessary assignments of DW internal PHY related members from
structs rk3228_hdmi_drv_data and rk3328_hdmi_drv_data, since both set
the phy_force_vendor flag and correctly provide the expected vendor PHY
data.

Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
---
 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 6 ------
 1 file changed, 6 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index edfd877c98fc..ca6728a43159 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -444,9 +444,6 @@ static struct rockchip_hdmi_chip_data rk3228_chip_data = {
 
 static const struct dw_hdmi_plat_data rk3228_hdmi_drv_data = {
 	.mode_valid = dw_hdmi_rockchip_mode_valid,
-	.mpll_cfg = rockchip_mpll_cfg,
-	.cur_ctr = rockchip_cur_ctr,
-	.phy_config = rockchip_phy_config,
 	.phy_data = &rk3228_chip_data,
 	.phy_ops = &rk3228_hdmi_phy_ops,
 	.phy_name = "inno_dw_hdmi_phy2",
@@ -481,9 +478,6 @@ static struct rockchip_hdmi_chip_data rk3328_chip_data = {
 
 static const struct dw_hdmi_plat_data rk3328_hdmi_drv_data = {
 	.mode_valid = dw_hdmi_rockchip_mode_valid,
-	.mpll_cfg = rockchip_mpll_cfg,
-	.cur_ctr = rockchip_cur_ctr,
-	.phy_config = rockchip_phy_config,
 	.phy_data = &rk3328_chip_data,
 	.phy_ops = &rk3328_hdmi_phy_ops,
 	.phy_name = "inno_dw_hdmi_phy2",

-- 
2.45.0


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 12/14] dt-bindings: display: rockchip,dw-hdmi: Add compatible for RK3588

[Cristian Ciocaltea]

Document the Synopsys DesignWare HDMI 2.1 Quad-Pixel (QP) TX controller
found on Rockchip RK3588 SoC family.

Since RK3588 uses different clocks than previous Rockchip SoCs and also
requires a couple of reset lines and some additional properties, provide
the required changes in the binding to accommodate all variants.

Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
---
 .../display/rockchip/rockchip,dw-hdmi.yaml         | 127 +++++++++++++++------
 1 file changed, 90 insertions(+), 37 deletions(-)

diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
index 2aac62219ff6..60d6b815227f 100644
--- a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
+++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
@@ -10,12 +10,10 @@ maintainers:
   - Mark Yao <markyao0591@gmail.com>
 
 description: |
-  The HDMI transmitter is a Synopsys DesignWare HDMI 1.4 TX controller IP
-  with a companion PHY IP.
-
-allOf:
-  - $ref: ../bridge/synopsys,dw-hdmi.yaml#
-  - $ref: /schemas/sound/dai-common.yaml#
+  For SoCs up to RK3568, the HDMI transmitter is a Synopsys DesignWare
+  HDMI 1.4 TX controller IP with a companion PHY IP.
+  The RK3588 SoC integrates the Synopsys DesignWare HDMI 2.1 Quad-Pixel (QP)
+  TX controller IP and a HDMI/eDP TX Combo PHY based on a Samsung IP block.
 
 properties:
   compatible:
@@ -25,6 +23,7 @@ properties:
       - rockchip,rk3328-dw-hdmi
       - rockchip,rk3399-dw-hdmi
       - rockchip,rk3568-dw-hdmi
+      - rockchip,rk3588-dw-hdmi
 
   reg-io-width:
     const: 4
@@ -40,36 +39,6 @@ properties:
       A 1.8V supply that powers up the SoC internal circuitry. The pin name on the
       SoC usually is HDMI_TX_AVDD_1V8.
 
-  clocks:
-    minItems: 2
-    items:
-      - {}
-      - {}
-      # The next three clocks are all optional, but shall be specified in this
-      # order when present.
-      - description: The HDMI CEC controller main clock
-      - description: Power for GRF IO
-      - description: External clock for some HDMI PHY (old clock name, deprecated)
-      - description: External clock for some HDMI PHY (new name)
-
-  clock-names:
-    minItems: 2
-    items:
-      - {}
-      - {}
-      - enum:
-          - cec
-          - grf
-          - vpll
-          - ref
-      - enum:
-          - grf
-          - vpll
-          - ref
-      - enum:
-          - vpll
-          - ref
-
   ddc-i2c-bus:
     $ref: /schemas/types.yaml#/definitions/phandle
     description:
@@ -131,13 +100,97 @@ properties:
 required:
   - compatible
   - reg
-  - reg-io-width
   - clocks
   - clock-names
   - interrupts
   - ports
   - rockchip,grf
 
+allOf:
+  - $ref: /schemas/sound/dai-common.yaml#
+  - if:
+      properties:
+        compatible:
+          contains:
+            enum:
+              - rockchip,rk3588-dw-hdmi
+    then:
+      properties:
+        reg:
+          maxItems: 1
+
+        clocks:
+          minItems: 1
+          items:
+            - description: APB system interface clock
+            # The next clocks are optional, but shall be specified in this
+            # order when present.
+            - description: TMDS/FRL link clock
+            - description: EARC RX biphase clock
+            - description: Reference clock
+            - description: Audio interface clock
+            - description: Video datapath clock
+
+        clock-names:
+          minItems: 1
+          items:
+            - const: pclk
+            - enum: [hdp, earc, ref, aud, hclk_vo1]
+            - enum: [earc, ref, aud, hclk_vo1]
+            - enum: [ref, aud, hclk_vo1]
+            - enum: [aud, hclk_vo1]
+            - const: hclk_vo1
+
+        resets:
+          minItems: 2
+          maxItems: 2
+
+        reset-names:
+          items:
+            - const: ref
+            - const: hdp
+
+        interrupts:
+          minItems: 1
+          maxItems: 5
+
+        rockchip,vo1_grf:
+          $ref: /schemas/types.yaml#/definitions/phandle
+          description: Some QP related data is accessed through VO1 GRF regs
+
+      required:
+        - resets
+        - reset-names
+        - rockchip,vo1_grf
+
+    else:
+      $ref: ../bridge/synopsys,dw-hdmi.yaml#
+
+      properties:
+        clocks:
+          minItems: 2
+          items:
+            - {}
+            - {}
+            # The next three clocks are all optional, but shall be specified in this
+            # order when present.
+            - description: The HDMI CEC controller main clock
+            - description: Power for GRF IO
+            - description: External clock for some HDMI PHY (old clock name, deprecated)
+            - description: External clock for some HDMI PHY (new name)
+
+        clock-names:
+          minItems: 2
+          items:
+            - {}
+            - {}
+            - enum: [cec, grf, vpll, ref]
+            - enum: [grf, vpll, ref]
+            - enum: [vpll, ref]
+
+      required:
+        - reg-io-width
+
 unevaluatedProperties: false
 
 examples:

-- 
2.45.0


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 13/14] drm/bridge: synopsys: Add DW HDMI QP TX controller driver

[Cristian Ciocaltea]

The Synopsys DesignWare HDMI 2.1 Quad-Pixel (QP) TX controller supports
the following features, among others:

* Fixed Rate Link (FRL)
* 4K@120Hz and 8K@60Hz video modes
* Variable Refresh Rate (VRR) including Quick Media Switching (QMS), aka
  Cinema VRR
* Fast Vactive (FVA), aka Quick Frame Transport (QFT)
* SCDC I2C DDC access
* TMDS Scrambler enabling 2160p@60Hz with RGB/YCbCr4:4:4
* YCbCr4:2:0 enabling 2160p@60Hz at lower HDMI link speeds
* Multi-stream audio
* Enhanced Audio Return Channel (EARC)

Add driver to enable basic support, i.e. RGB output up to 4K@60Hz,
without audio, CEC or any HDMI 2.1 specific features.

Co-developed-by: Algea Cao <algea.cao@rock-chips.com>
Signed-off-by: Algea Cao <algea.cao@rock-chips.com>
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
---
 drivers/gpu/drm/bridge/synopsys/Makefile     |   2 +-
 drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c | 787 +++++++++++++++++++++++++
 drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.h | 831 +++++++++++++++++++++++++++
 include/drm/bridge/dw_hdmi.h                 |   8 +
 4 files changed, 1627 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/synopsys/Makefile b/drivers/gpu/drm/bridge/synopsys/Makefile
index ce715562e9e5..8354e4879f70 100644
--- a/drivers/gpu/drm/bridge/synopsys/Makefile
+++ b/drivers/gpu/drm/bridge/synopsys/Makefile
@@ -1,5 +1,5 @@
 # SPDX-License-Identifier: GPL-2.0-only
-obj-$(CONFIG_DRM_DW_HDMI) += dw-hdmi.o
+obj-$(CONFIG_DRM_DW_HDMI) += dw-hdmi.o dw-hdmi-qp.o
 obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw-hdmi-ahb-audio.o
 obj-$(CONFIG_DRM_DW_HDMI_GP_AUDIO) += dw-hdmi-gp-audio.o
 obj-$(CONFIG_DRM_DW_HDMI_I2S_AUDIO) += dw-hdmi-i2s-audio.o
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c
new file mode 100644
index 000000000000..0ff7c2e259f5
--- /dev/null
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c
@@ -0,0 +1,787 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (c) 2021-2022 Rockchip Electronics Co., Ltd.
+ * Copyright (c) 2024 Collabora Ltd.
+ *
+ * Author: Algea Cao <algea.cao@rock-chips.com>
+ * Author: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
+ */
+#include <linux/hdmi.h>
+#include <linux/irq.h>
+#include <linux/module.h>
+#include <linux/of.h>
+
+#include <drm/display/drm_hdmi_helper.h>
+#include <drm/display/drm_scdc_helper.h>
+#include <drm/drm_atomic.h>
+#include <drm/drm_atomic_helper.h>
+#include <drm/drm_edid.h>
+#include <drm/drm_probe_helper.h>
+
+#include "dw-hdmi-common.h"
+#include "dw-hdmi-qp.h"
+
+static void dw_hdmi_qp_write(struct dw_hdmi *hdmi, unsigned int val, int offset)
+{
+	regmap_write(hdmi->regm, offset, val);
+}
+
+static unsigned int dw_hdmi_qp_read(struct dw_hdmi *hdmi, int offset)
+{
+	unsigned int val = 0;
+
+	regmap_read(hdmi->regm, offset, &val);
+
+	return val;
+}
+
+static void dw_hdmi_qp_mod(struct dw_hdmi *hdmi, unsigned int data,
+			   unsigned int mask, unsigned int reg)
+{
+	regmap_update_bits(hdmi->regm, reg, mask, data);
+}
+
+static void dw_hdmi_qp_i2c_init(struct dw_hdmi *hdmi)
+{
+	/* Software reset */
+	dw_hdmi_qp_write(hdmi, 0x01, I2CM_CONTROL0);
+
+	dw_hdmi_qp_write(hdmi, 0x085c085c, I2CM_FM_SCL_CONFIG0);
+
+	dw_hdmi_qp_mod(hdmi, 0, I2CM_FM_EN, I2CM_INTERFACE_CONTROL0);
+
+	/* Clear DONE and ERROR interrupts */
+	dw_hdmi_qp_write(hdmi, I2CM_OP_DONE_CLEAR | I2CM_NACK_RCVD_CLEAR,
+			 MAINUNIT_1_INT_CLEAR);
+}
+
+static int dw_hdmi_qp_i2c_read(struct dw_hdmi *hdmi,
+			       unsigned char *buf, unsigned int length)
+{
+	struct dw_hdmi_i2c *i2c = hdmi->i2c;
+	int stat;
+
+	if (!i2c->is_regaddr) {
+		dev_dbg(hdmi->dev, "set read register address to 0\n");
+		i2c->slave_reg = 0x00;
+		i2c->is_regaddr = true;
+	}
+
+	while (length--) {
+		reinit_completion(&i2c->cmp);
+
+		dw_hdmi_qp_mod(hdmi, i2c->slave_reg++ << 12, I2CM_ADDR,
+			       I2CM_INTERFACE_CONTROL0);
+
+		dw_hdmi_qp_mod(hdmi, I2CM_FM_READ, I2CM_WR_MASK,
+			       I2CM_INTERFACE_CONTROL0);
+
+		stat = wait_for_completion_timeout(&i2c->cmp, HZ / 10);
+		if (!stat) {
+			dev_err(hdmi->dev, "i2c read timed out\n");
+			dw_hdmi_qp_write(hdmi, 0x01, I2CM_CONTROL0);
+			return -EAGAIN;
+		}
+
+		/* Check for error condition on the bus */
+		if (i2c->stat & I2CM_NACK_RCVD_IRQ) {
+			dev_err(hdmi->dev, "i2c read error\n");
+			dw_hdmi_qp_write(hdmi, 0x01, I2CM_CONTROL0);
+			return -EIO;
+		}
+
+		*buf++ = dw_hdmi_qp_read(hdmi, I2CM_INTERFACE_RDDATA_0_3) & 0xff;
+		dw_hdmi_qp_mod(hdmi, 0, I2CM_WR_MASK, I2CM_INTERFACE_CONTROL0);
+	}
+
+	i2c->is_segment = false;
+
+	return 0;
+}
+
+static int dw_hdmi_qp_i2c_write(struct dw_hdmi *hdmi,
+				unsigned char *buf, unsigned int length)
+{
+	struct dw_hdmi_i2c *i2c = hdmi->i2c;
+	int stat;
+
+	if (!i2c->is_regaddr) {
+		/* Use the first write byte as register address */
+		i2c->slave_reg = buf[0];
+		length--;
+		buf++;
+		i2c->is_regaddr = true;
+	}
+
+	while (length--) {
+		reinit_completion(&i2c->cmp);
+
+		dw_hdmi_qp_write(hdmi, *buf++, I2CM_INTERFACE_WRDATA_0_3);
+		dw_hdmi_qp_mod(hdmi, i2c->slave_reg++ << 12, I2CM_ADDR,
+			       I2CM_INTERFACE_CONTROL0);
+		dw_hdmi_qp_mod(hdmi, I2CM_FM_WRITE, I2CM_WR_MASK,
+			       I2CM_INTERFACE_CONTROL0);
+
+		stat = wait_for_completion_timeout(&i2c->cmp, HZ / 10);
+		if (!stat) {
+			dev_err(hdmi->dev, "i2c write time out!\n");
+			dw_hdmi_qp_write(hdmi, 0x01, I2CM_CONTROL0);
+			return -EAGAIN;
+		}
+
+		/* Check for error condition on the bus */
+		if (i2c->stat & I2CM_NACK_RCVD_IRQ) {
+			dev_err(hdmi->dev, "i2c write nack!\n");
+			dw_hdmi_qp_write(hdmi, 0x01, I2CM_CONTROL0);
+			return -EIO;
+		}
+
+		dw_hdmi_qp_mod(hdmi, 0, I2CM_WR_MASK, I2CM_INTERFACE_CONTROL0);
+	}
+
+	return 0;
+}
+
+static int dw_hdmi_qp_i2c_xfer(struct i2c_adapter *adap,
+			       struct i2c_msg *msgs, int num)
+{
+	struct dw_hdmi *hdmi = i2c_get_adapdata(adap);
+	struct dw_hdmi_i2c *i2c = hdmi->i2c;
+	u8 addr = msgs[0].addr;
+	int i, ret = 0;
+
+	if (addr == DDC_CI_ADDR)
+		/*
+		 * The internal I2C controller does not support the multi-byte
+		 * read and write operations needed for DDC/CI.
+		 * TOFIX: Blacklist the DDC/CI address until we filter out
+		 * unsupported I2C operations.
+		 */
+		return -EOPNOTSUPP;
+
+	for (i = 0; i < num; i++) {
+		if (msgs[i].len == 0) {
+			dev_err(hdmi->dev,
+				"unsupported transfer %d/%d, no data\n",
+				i + 1, num);
+			return -EOPNOTSUPP;
+		}
+	}
+
+	mutex_lock(&i2c->lock);
+
+	/* Unmute DONE and ERROR interrupts */
+	dw_hdmi_qp_mod(hdmi, I2CM_NACK_RCVD_MASK_N | I2CM_OP_DONE_MASK_N,
+		       I2CM_NACK_RCVD_MASK_N | I2CM_OP_DONE_MASK_N,
+		       MAINUNIT_1_INT_MASK_N);
+
+	/* Set slave device address taken from the first I2C message */
+	if (addr == DDC_SEGMENT_ADDR && msgs[0].len == 1)
+		addr = DDC_ADDR;
+
+	dw_hdmi_qp_mod(hdmi, addr << 5, I2CM_SLVADDR, I2CM_INTERFACE_CONTROL0);
+
+	/* Set slave device register address on transfer */
+	i2c->is_regaddr = false;
+
+	/* Set segment pointer for I2C extended read mode operation */
+	i2c->is_segment = false;
+
+	for (i = 0; i < num; i++) {
+		if (msgs[i].addr == DDC_SEGMENT_ADDR && msgs[i].len == 1) {
+			i2c->is_segment = true;
+			dw_hdmi_qp_mod(hdmi, DDC_SEGMENT_ADDR, I2CM_SEG_ADDR,
+				       I2CM_INTERFACE_CONTROL1);
+			dw_hdmi_qp_mod(hdmi, *msgs[i].buf, I2CM_SEG_PTR,
+				       I2CM_INTERFACE_CONTROL1);
+		} else {
+			if (msgs[i].flags & I2C_M_RD)
+				ret = dw_hdmi_qp_i2c_read(hdmi, msgs[i].buf,
+							  msgs[i].len);
+			else
+				ret = dw_hdmi_qp_i2c_write(hdmi, msgs[i].buf,
+							   msgs[i].len);
+		}
+		if (ret < 0)
+			break;
+	}
+
+	if (!ret)
+		ret = num;
+
+	/* Mute DONE and ERROR interrupts */
+	dw_hdmi_qp_mod(hdmi, 0, I2CM_OP_DONE_MASK_N | I2CM_NACK_RCVD_MASK_N,
+		       MAINUNIT_1_INT_MASK_N);
+
+	mutex_unlock(&i2c->lock);
+
+	return ret;
+}
+
+static u32 dw_hdmi_qp_i2c_func(struct i2c_adapter *adapter)
+{
+	return I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL;
+}
+
+static const struct i2c_algorithm dw_hdmi_algorithm = {
+	.master_xfer	= dw_hdmi_qp_i2c_xfer,
+	.functionality	= dw_hdmi_qp_i2c_func,
+};
+
+static void hdmi_infoframe_set_checksum(u8 *ptr, int size)
+{
+	u8 csum = 0;
+	int i;
+
+	ptr[3] = 0;
+	/* compute checksum */
+	for (i = 0; i < size; i++)
+		csum += ptr[i];
+
+	ptr[3] = 256 - csum;
+}
+
+static void hdmi_config_AVI(struct dw_hdmi *hdmi,
+			    const struct drm_connector *connector,
+			    const struct drm_display_mode *mode)
+{
+	struct hdmi_avi_infoframe frame;
+	u32 val, i, j;
+	u8 buf[17];
+
+	dw_hdmi_prep_avi_infoframe(&frame, hdmi, connector, mode);
+
+	frame.scan_mode = HDMI_SCAN_MODE_NONE;
+	frame.video_code = hdmi->vic;
+
+	hdmi_avi_infoframe_pack_only(&frame, buf, 17);
+
+	/* mode which vic >= 128 must use avi version 3 */
+	if (hdmi->vic >= 128) {
+		frame.version = 3;
+		buf[1] = frame.version;
+		buf[4] &= 0x1f;
+		buf[4] |= ((frame.colorspace & 0x7) << 5);
+		buf[7] = frame.video_code;
+		hdmi_infoframe_set_checksum(buf, 17);
+	}
+
+	/*
+	 * The Designware IP uses a different byte format from standard
+	 * AVI info frames, though generally the bits are in the correct
+	 * bytes.
+	 */
+
+	val = (frame.version << 8) | (frame.length << 16);
+	dw_hdmi_qp_write(hdmi, val, PKT_AVI_CONTENTS0);
+
+	for (i = 0; i < 4; i++) {
+		for (j = 0; j < 4; j++) {
+			if (i * 4 + j >= 14)
+				break;
+			if (!j)
+				val = buf[i * 4 + j + 3];
+			val |= buf[i * 4 + j + 3] << (8 * j);
+		}
+
+		dw_hdmi_qp_write(hdmi, val, PKT_AVI_CONTENTS1 + i * 4);
+	}
+
+	dw_hdmi_qp_mod(hdmi, 0, PKTSCHED_AVI_FIELDRATE, PKTSCHED_PKT_CONFIG1);
+
+	dw_hdmi_qp_mod(hdmi, PKTSCHED_AVI_TX_EN | PKTSCHED_GCP_TX_EN,
+		       PKTSCHED_AVI_TX_EN | PKTSCHED_GCP_TX_EN, PKTSCHED_PKT_EN);
+}
+
+static void hdmi_config_drm_infoframe(struct dw_hdmi *hdmi,
+				      const struct drm_connector *connector)
+{
+	const struct drm_connector_state *conn_state = connector->state;
+	struct hdr_output_metadata *hdr_metadata;
+	struct hdmi_drm_infoframe frame;
+	u8 buffer[30];
+	ssize_t err;
+	int i;
+	u32 val;
+
+	if (!hdmi->plat_data->use_drm_infoframe)
+		return;
+
+	dw_hdmi_qp_mod(hdmi, 0, PKTSCHED_DRMI_TX_EN, PKTSCHED_PKT_EN);
+
+	if (!hdmi->connector.hdr_sink_metadata.hdmi_type1.eotf) {
+		dev_dbg(hdmi->dev, "No need to set HDR metadata in infoframe\n");
+		return;
+	}
+
+	if (!conn_state->hdr_output_metadata) {
+		dev_dbg(hdmi->dev, "source metadata not set yet\n");
+		return;
+	}
+
+	hdr_metadata = (struct hdr_output_metadata *)
+		conn_state->hdr_output_metadata->data;
+
+	if (!(hdmi->connector.hdr_sink_metadata.hdmi_type1.eotf &
+	      BIT(hdr_metadata->hdmi_metadata_type1.eotf))) {
+		dev_err(hdmi->dev, "EOTF %d not supported\n",
+			hdr_metadata->hdmi_metadata_type1.eotf);
+		return;
+	}
+
+	err = drm_hdmi_infoframe_set_hdr_metadata(&frame, conn_state);
+	if (err < 0)
+		return;
+
+	err = hdmi_drm_infoframe_pack(&frame, buffer, sizeof(buffer));
+	if (err < 0) {
+		dev_err(hdmi->dev, "Failed to pack drm infoframe: %zd\n", err);
+		return;
+	}
+
+	val = (frame.version << 8) | (frame.length << 16);
+	dw_hdmi_qp_write(hdmi, val, PKT_DRMI_CONTENTS0);
+
+	for (i = 0; i <= frame.length; i++) {
+		if (i % 4 == 0)
+			val = buffer[3 + i];
+		val |= buffer[3 + i] << ((i % 4) * 8);
+
+		if ((i % 4 == 3) || i == frame.length)
+			dw_hdmi_qp_write(hdmi, val,
+					 PKT_DRMI_CONTENTS1 + ((i / 4) * 4));
+	}
+
+	dw_hdmi_qp_mod(hdmi, 0, PKTSCHED_DRMI_FIELDRATE, PKTSCHED_PKT_CONFIG1);
+	dw_hdmi_qp_mod(hdmi, PKTSCHED_DRMI_TX_EN, PKTSCHED_DRMI_TX_EN,
+		       PKTSCHED_PKT_EN);
+}
+
+static int dw_hdmi_qp_setup(struct dw_hdmi *hdmi,
+			    struct drm_connector *connector,
+			    struct drm_display_mode *mode)
+{
+	u8 bytes = 0;
+	int ret;
+
+	dw_hdmi_prep_data(hdmi, mode);
+
+	if (mode->flags & DRM_MODE_FLAG_DBLCLK) {
+		hdmi->hdmi_data.video_mode.mpixelrepetitionoutput = 1;
+		hdmi->hdmi_data.video_mode.mpixelrepetitioninput = 1;
+	}
+
+	/*
+	 * According to the dw-hdmi specification 6.4.2
+	 * vp_pr_cd[3:0]:
+	 * 0000b: No pixel repetition (pixel sent only once)
+	 * 0001b: Pixel sent two times (pixel repeated once)
+	 */
+	if (mode->flags & DRM_MODE_FLAG_DBLCLK)
+		hdmi->hdmi_data.pix_repet_factor = 1;
+
+	/* HDMI Initialization Step B.1 */
+	dw_hdmi_prep_vmode(hdmi, mode);
+
+	/* HDMI Initialization Step B.2 */
+	ret = hdmi->phy.ops->init(hdmi, hdmi->phy.data,
+				  &connector->display_info,
+				  &hdmi->previous_mode);
+	if (ret)
+		return ret;
+	hdmi->phy.enabled = true;
+
+	/* not for DVI mode */
+	if (hdmi->sink_is_hdmi) {
+		dev_dbg(hdmi->dev, "%s HDMI mode\n", __func__);
+
+		dw_hdmi_qp_mod(hdmi, 0, OPMODE_DVI, LINK_CONFIG0);
+		dw_hdmi_qp_mod(hdmi, HDCP2_BYPASS, HDCP2_BYPASS, HDCP2LOGIC_CONFIG0);
+
+		if (hdmi->hdmi_data.video_mode.mtmdsclock > HDMI14_MAX_TMDSCLK) {
+			if (dw_hdmi_support_scdc(hdmi, &connector->display_info)) {
+				drm_scdc_readb(hdmi->ddc, SCDC_SINK_VERSION, &bytes);
+				drm_scdc_writeb(hdmi->ddc, SCDC_SOURCE_VERSION,
+						min_t(u8, bytes, SCDC_MIN_SOURCE_VERSION));
+				drm_scdc_set_high_tmds_clock_ratio(connector, 1);
+				drm_scdc_set_scrambling(connector, 1);
+			}
+			dw_hdmi_qp_write(hdmi, 1, SCRAMB_CONFIG0);
+		} else {
+			if (dw_hdmi_support_scdc(hdmi, &connector->display_info)) {
+				drm_scdc_set_high_tmds_clock_ratio(connector, 0);
+				drm_scdc_set_scrambling(connector, 0);
+			}
+			dw_hdmi_qp_write(hdmi, 0, SCRAMB_CONFIG0);
+		}
+
+		/* HDMI Initialization Step F */
+		hdmi_config_AVI(hdmi, connector, mode);
+		hdmi_config_drm_infoframe(hdmi, connector);
+	} else {
+		dev_dbg(hdmi->dev, "%s DVI mode\n", __func__);
+
+		dw_hdmi_qp_mod(hdmi, HDCP2_BYPASS, HDCP2_BYPASS, HDCP2LOGIC_CONFIG0);
+		dw_hdmi_qp_mod(hdmi, OPMODE_DVI, OPMODE_DVI, LINK_CONFIG0);
+	}
+
+	return 0;
+}
+
+static void dw_hdmi_qp_update_power(struct dw_hdmi *hdmi)
+{
+	int force = hdmi->force;
+
+	if (hdmi->disabled) {
+		force = DRM_FORCE_OFF;
+	} else if (force == DRM_FORCE_UNSPECIFIED) {
+		if (hdmi->rxsense)
+			force = DRM_FORCE_ON;
+		else
+			force = DRM_FORCE_OFF;
+	}
+
+	if (force == DRM_FORCE_OFF) {
+		if (hdmi->bridge_is_on) {
+			if (hdmi->phy.enabled) {
+				hdmi->phy.ops->disable(hdmi, hdmi->phy.data);
+				hdmi->phy.enabled = false;
+			}
+
+			hdmi->bridge_is_on = false;
+		}
+	} else {
+		if (!hdmi->bridge_is_on) {
+			hdmi->bridge_is_on = true;
+
+			/*
+			 * The curr_conn field is guaranteed to be valid here, as this function
+			 * is only be called when !hdmi->disabled.
+			 */
+			dw_hdmi_qp_setup(hdmi, hdmi->curr_conn, &hdmi->previous_mode);
+		}
+	}
+}
+
+static void dw_hdmi_qp_connector_force(struct drm_connector *connector)
+{
+	struct dw_hdmi *hdmi =
+		container_of(connector, struct dw_hdmi, connector);
+
+	mutex_lock(&hdmi->mutex);
+	hdmi->force = connector->force;
+	dw_hdmi_qp_update_power(hdmi);
+	mutex_unlock(&hdmi->mutex);
+}
+
+static const struct drm_connector_funcs dw_hdmi_qp_connector_funcs = {
+	.fill_modes = drm_helper_probe_single_connector_modes,
+	.detect = dw_hdmi_connector_detect,
+	.destroy = drm_connector_cleanup,
+	.force = dw_hdmi_qp_connector_force,
+	.reset = drm_atomic_helper_connector_reset,
+	.atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
+	.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
+};
+
+static int dw_hdmi_qp_bridge_attach(struct drm_bridge *bridge,
+				    enum drm_bridge_attach_flags flags)
+{
+	struct dw_hdmi *hdmi = bridge->driver_private;
+
+	if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)
+		return drm_bridge_attach(bridge->encoder, hdmi->next_bridge,
+					 bridge, flags);
+
+	return dw_hdmi_connector_create(hdmi, &dw_hdmi_qp_connector_funcs);
+}
+
+static enum drm_mode_status
+dw_hdmi_qp_bridge_mode_valid(struct drm_bridge *bridge,
+			     const struct drm_display_info *info,
+			     const struct drm_display_mode *mode)
+{
+	struct dw_hdmi *hdmi = bridge->driver_private;
+	const struct dw_hdmi_plat_data *pdata = hdmi->plat_data;
+	enum drm_mode_status mode_status = MODE_OK;
+
+	if (pdata->mode_valid)
+		mode_status = pdata->mode_valid(hdmi, pdata->priv_data, info,
+						mode);
+
+	return mode_status;
+}
+
+static void dw_hdmi_qp_bridge_atomic_disable(struct drm_bridge *bridge,
+					     struct drm_bridge_state *old_state)
+{
+	struct dw_hdmi *hdmi = bridge->driver_private;
+
+	mutex_lock(&hdmi->mutex);
+	hdmi->disabled = true;
+	hdmi->curr_conn = NULL;
+	dw_hdmi_qp_update_power(hdmi);
+	dw_handle_plugged_change(hdmi, false);
+	mutex_unlock(&hdmi->mutex);
+}
+
+static void dw_hdmi_qp_bridge_atomic_enable(struct drm_bridge *bridge,
+					    struct drm_bridge_state *old_state)
+{
+	struct dw_hdmi *hdmi = bridge->driver_private;
+	struct drm_atomic_state *state = old_state->base.state;
+	struct drm_connector *connector;
+
+	connector = drm_atomic_get_new_connector_for_encoder(state,
+							     bridge->encoder);
+
+	mutex_lock(&hdmi->mutex);
+	hdmi->disabled = false;
+	hdmi->curr_conn = connector;
+	dw_hdmi_qp_update_power(hdmi);
+	dw_handle_plugged_change(hdmi, true);
+	mutex_unlock(&hdmi->mutex);
+}
+
+static const struct drm_bridge_funcs dw_hdmi_qp_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 = dw_hdmi_qp_bridge_attach,
+	.detach = dw_hdmi_bridge_detach,
+	.atomic_check = dw_hdmi_bridge_atomic_check,
+	.atomic_enable = dw_hdmi_qp_bridge_atomic_enable,
+	.atomic_disable = dw_hdmi_qp_bridge_atomic_disable,
+	.mode_set = dw_hdmi_bridge_mode_set,
+	.mode_valid = dw_hdmi_qp_bridge_mode_valid,
+	.detect = dw_hdmi_bridge_detect,
+	.edid_read = dw_hdmi_bridge_edid_read,
+};
+
+static irqreturn_t dw_hdmi_qp_main_hardirq(int irq, void *dev_id)
+{
+	struct dw_hdmi *hdmi = dev_id;
+	struct dw_hdmi_i2c *i2c = hdmi->i2c;
+	u32 stat;
+
+	stat = dw_hdmi_qp_read(hdmi, MAINUNIT_1_INT_STATUS);
+
+	i2c->stat = stat & (I2CM_OP_DONE_IRQ | I2CM_READ_REQUEST_IRQ |
+			    I2CM_NACK_RCVD_IRQ);
+
+	if (i2c->stat) {
+		dw_hdmi_qp_write(hdmi, i2c->stat, MAINUNIT_1_INT_CLEAR);
+		complete(&i2c->cmp);
+	}
+
+	if (stat)
+		return IRQ_HANDLED;
+
+	return IRQ_NONE;
+}
+
+static int dw_hdmi_qp_detect_phy(struct dw_hdmi *hdmi)
+{
+	if (!hdmi->plat_data->phy_force_vendor) {
+		dev_err(hdmi->dev, "Internal HDMI PHY not supported\n");
+		return -ENODEV;
+	}
+
+	/* Vendor PHYs require support from the glue layer. */
+	if (!hdmi->plat_data->phy_ops || !hdmi->plat_data->phy_name) {
+		dev_err(hdmi->dev,
+			"Vendor HDMI PHY not supported by glue layer\n");
+		return -ENODEV;
+	}
+
+	hdmi->phy.ops = hdmi->plat_data->phy_ops;
+	hdmi->phy.data = hdmi->plat_data->phy_data;
+	hdmi->phy.name = hdmi->plat_data->phy_name;
+
+	return 0;
+}
+
+static const struct regmap_config dw_hdmi_qp_regmap_config = {
+	.reg_bits	= 32,
+	.val_bits	= 32,
+	.reg_stride	= 4,
+	.max_register	= EARCRX_1_INT_FORCE,
+};
+
+static void dw_hdmi_qp_init_hw(struct dw_hdmi *hdmi)
+{
+	dw_hdmi_qp_write(hdmi, 0, MAINUNIT_0_INT_MASK_N);
+	dw_hdmi_qp_write(hdmi, 0, MAINUNIT_1_INT_MASK_N);
+	dw_hdmi_qp_write(hdmi, 428571429, TIMER_BASE_CONFIG0);
+
+	dw_hdmi_qp_i2c_init(hdmi);
+
+	if (hdmi->phy.ops->setup_hpd)
+		hdmi->phy.ops->setup_hpd(hdmi, hdmi->phy.data);
+}
+
+static struct dw_hdmi *
+dw_hdmi_qp_probe(struct platform_device *pdev,
+		 const struct dw_hdmi_plat_data *plat_data)
+{
+	struct device *dev = &pdev->dev;
+	struct device_node *np = dev->of_node;
+	struct device_node *ddc_node;
+	struct dw_hdmi *hdmi;
+	struct resource *iores = NULL;
+	int irq, ret;
+
+	hdmi = devm_kzalloc(dev, sizeof(*hdmi), GFP_KERNEL);
+	if (!hdmi)
+		return ERR_PTR(-ENOMEM);
+
+	hdmi->plat_data = plat_data;
+	hdmi->dev = dev;
+	hdmi->disabled = true;
+	hdmi->rxsense = true;
+	hdmi->last_connector_result = connector_status_disconnected;
+
+	mutex_init(&hdmi->mutex);
+	mutex_init(&hdmi->audio_mutex);
+	mutex_init(&hdmi->cec_notifier_mutex);
+	spin_lock_init(&hdmi->audio_lock);
+
+	ddc_node = of_parse_phandle(np, "ddc-i2c-bus", 0);
+	if (ddc_node) {
+		hdmi->ddc = of_get_i2c_adapter_by_node(ddc_node);
+		of_node_put(ddc_node);
+		if (!hdmi->ddc) {
+			dev_dbg(hdmi->dev, "failed to read ddc node\n");
+			return ERR_PTR(-EPROBE_DEFER);
+		}
+
+	} else {
+		dev_dbg(hdmi->dev, "no ddc property found\n");
+	}
+
+	if (!plat_data->regm) {
+		const struct regmap_config *reg_config;
+
+		reg_config = &dw_hdmi_qp_regmap_config;
+
+		iores = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+		hdmi->regs = devm_ioremap_resource(dev, iores);
+		if (IS_ERR(hdmi->regs)) {
+			ret = PTR_ERR(hdmi->regs);
+			goto err_put;
+		}
+
+		hdmi->regm = devm_regmap_init_mmio(dev, hdmi->regs, reg_config);
+		if (IS_ERR(hdmi->regm)) {
+			dev_err(dev, "Failed to configure regmap\n");
+			ret = PTR_ERR(hdmi->regm);
+			goto err_put;
+		}
+	} else {
+		hdmi->regm = plat_data->regm;
+	}
+
+	/* Allow SCDC advertising in dw_hdmi_support_scdc() */
+	hdmi->version = 0x200a;
+
+	ret = dw_hdmi_qp_detect_phy(hdmi);
+	if (ret < 0)
+		goto err_put;
+
+	dw_hdmi_qp_init_hw(hdmi);
+
+	if ((dw_hdmi_qp_read(hdmi, CMU_STATUS) & DISPLAY_CLK_MONITOR) ==
+			DISPLAY_CLK_LOCKED)
+		hdmi->disabled = false;
+
+	/* Not handled for now: IRQ0 (AVP), IRQ1 (CEC), IRQ2 (EARC) */
+	irq = platform_get_irq(pdev, 3);
+	if (irq < 0) {
+		ret = irq;
+		goto err_put;
+	}
+
+	ret = devm_request_threaded_irq(dev, irq,
+					dw_hdmi_qp_main_hardirq, NULL,
+					IRQF_SHARED, dev_name(dev), hdmi);
+	if (ret)
+		goto err_put;
+
+	/* If DDC bus is not specified, try to register HDMI I2C bus */
+	if (!hdmi->ddc) {
+		hdmi->ddc = dw_hdmi_i2c_adapter(hdmi, &dw_hdmi_algorithm);
+		if (IS_ERR(hdmi->ddc))
+			hdmi->ddc = NULL;
+	}
+
+	hdmi->bridge.driver_private = hdmi;
+	hdmi->bridge.funcs = &dw_hdmi_qp_bridge_funcs;
+	hdmi->bridge.ops = DRM_BRIDGE_OP_DETECT | DRM_BRIDGE_OP_EDID
+			 | DRM_BRIDGE_OP_HPD;
+	hdmi->bridge.ddc = hdmi->ddc;
+	hdmi->bridge.of_node = pdev->dev.of_node;
+	hdmi->bridge.type = DRM_MODE_CONNECTOR_HDMIA;
+
+	drm_bridge_add(&hdmi->bridge);
+
+	return hdmi;
+
+err_put:
+	i2c_put_adapter(hdmi->ddc);
+
+	return ERR_PTR(ret);
+}
+
+static void dw_hdmi_qp_remove(struct dw_hdmi *hdmi)
+{
+	drm_bridge_remove(&hdmi->bridge);
+
+	if (hdmi->audio && !IS_ERR(hdmi->audio))
+		platform_device_unregister(hdmi->audio);
+	if (!IS_ERR(hdmi->cec))
+		platform_device_unregister(hdmi->cec);
+
+	if (hdmi->i2c)
+		i2c_del_adapter(&hdmi->i2c->adap);
+	else
+		i2c_put_adapter(hdmi->ddc);
+}
+
+struct dw_hdmi *dw_hdmi_qp_bind(struct platform_device *pdev,
+				struct drm_encoder *encoder,
+				struct dw_hdmi_plat_data *plat_data)
+{
+	struct dw_hdmi *hdmi;
+	int ret;
+
+	hdmi = dw_hdmi_qp_probe(pdev, plat_data);
+	if (IS_ERR(hdmi))
+		return hdmi;
+
+	ret = drm_bridge_attach(encoder, &hdmi->bridge, NULL, 0);
+	if (ret) {
+		dw_hdmi_qp_remove(hdmi);
+		return ERR_PTR(ret);
+	}
+
+	return hdmi;
+}
+EXPORT_SYMBOL_GPL(dw_hdmi_qp_bind);
+
+void dw_hdmi_qp_unbind(struct dw_hdmi *hdmi)
+{
+	dw_hdmi_qp_remove(hdmi);
+}
+EXPORT_SYMBOL_GPL(dw_hdmi_qp_unbind);
+
+void dw_hdmi_qp_resume(struct device *dev, struct dw_hdmi *hdmi)
+{
+	dw_hdmi_qp_init_hw(hdmi);
+}
+EXPORT_SYMBOL_GPL(dw_hdmi_qp_resume);
+
+MODULE_AUTHOR("Algea Cao <algea.cao@rock-chips.com>");
+MODULE_AUTHOR("Cristian Ciocaltea <cristian.ciocaltea@collabora.com>");
+MODULE_DESCRIPTION("DW HDMI QP transmitter driver");
+MODULE_LICENSE("GPL");
+MODULE_ALIAS("platform:dw-hdmi-qp");
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.h b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.h
new file mode 100644
index 000000000000..a953cc00161d
--- /dev/null
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.h
@@ -0,0 +1,831 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) Rockchip Electronics Co.Ltd
+ * Author:
+ *      Algea Cao <algea.cao@rock-chips.com>
+ */
+#ifndef __DW_HDMI_QP_H__
+#define __DW_HDMI_QP_H__
+/* Main Unit Registers */
+#define CORE_ID						0x0
+#define VER_NUMBER					0x4
+#define VER_TYPE					0x8
+#define CONFIG_REG					0xc
+#define CONFIG_CEC					BIT(28)
+#define CONFIG_AUD_UD					BIT(23)
+#define CORE_TIMESTAMP_HHMM				0x14
+#define CORE_TIMESTAMP_MMDD				0x18
+#define CORE_TIMESTAMP_YYYY				0x1c
+/* Reset Manager Registers */
+#define GLOBAL_SWRESET_REQUEST				0x40
+#define EARCRX_CMDC_SWINIT_P				BIT(27)
+#define AVP_DATAPATH_PACKET_AUDIO_SWINIT_P		BIT(10)
+#define GLOBAL_SWDISABLE				0x44
+#define CEC_SWDISABLE					BIT(17)
+#define AVP_DATAPATH_PACKET_AUDIO_SWDISABLE		BIT(10)
+#define AVP_DATAPATH_VIDEO_SWDISABLE			BIT(6)
+#define RESET_MANAGER_CONFIG0				0x48
+#define RESET_MANAGER_STATUS0				0x50
+#define RESET_MANAGER_STATUS1				0x54
+#define RESET_MANAGER_STATUS2				0x58
+/* Timer Base Registers */
+#define TIMER_BASE_CONFIG0				0x80
+#define TIMER_BASE_STATUS0				0x84
+/* CMU Registers */
+#define CMU_CONFIG0					0xa0
+#define CMU_CONFIG1					0xa4
+#define CMU_CONFIG2					0xa8
+#define CMU_CONFIG3					0xac
+#define CMU_STATUS					0xb0
+#define DISPLAY_CLK_MONITOR				0x3f
+#define DISPLAY_CLK_LOCKED				0X15
+#define EARC_BPCLK_OFF					BIT(9)
+#define AUDCLK_OFF					BIT(7)
+#define LINKQPCLK_OFF					BIT(5)
+#define VIDQPCLK_OFF					BIT(3)
+#define IPI_CLK_OFF					BIT(1)
+#define CMU_IPI_CLK_FREQ				0xb4
+#define CMU_VIDQPCLK_FREQ				0xb8
+#define CMU_LINKQPCLK_FREQ				0xbc
+#define CMU_AUDQPCLK_FREQ				0xc0
+#define CMU_EARC_BPCLK_FREQ				0xc4
+/* I2CM Registers */
+#define I2CM_SM_SCL_CONFIG0				0xe0
+#define I2CM_FM_SCL_CONFIG0				0xe4
+#define I2CM_CONFIG0					0xe8
+#define I2CM_CONTROL0					0xec
+#define I2CM_STATUS0					0xf0
+#define I2CM_INTERFACE_CONTROL0				0xf4
+#define I2CM_ADDR					0xff000
+#define I2CM_SLVADDR					0xfe0
+#define I2CM_WR_MASK					0x1e
+#define I2CM_EXT_READ					BIT(4)
+#define I2CM_SHORT_READ					BIT(3)
+#define I2CM_FM_READ					BIT(2)
+#define I2CM_FM_WRITE					BIT(1)
+#define I2CM_FM_EN					BIT(0)
+#define I2CM_INTERFACE_CONTROL1				0xf8
+#define I2CM_SEG_PTR					0x7f80
+#define I2CM_SEG_ADDR					0x7f
+#define I2CM_INTERFACE_WRDATA_0_3			0xfc
+#define I2CM_INTERFACE_WRDATA_4_7			0x100
+#define I2CM_INTERFACE_WRDATA_8_11			0x104
+#define I2CM_INTERFACE_WRDATA_12_15			0x108
+#define I2CM_INTERFACE_RDDATA_0_3			0x10c
+#define I2CM_INTERFACE_RDDATA_4_7			0x110
+#define I2CM_INTERFACE_RDDATA_8_11			0x114
+#define I2CM_INTERFACE_RDDATA_12_15			0x118
+/* SCDC Registers */
+#define SCDC_CONFIG0					0x140
+#define SCDC_I2C_FM_EN					BIT(12)
+#define SCDC_UPD_FLAGS_AUTO_CLR				BIT(6)
+#define SCDC_UPD_FLAGS_POLL_EN				BIT(4)
+#define SCDC_CONTROL0					0x148
+#define SCDC_STATUS0					0x150
+#define STATUS_UPDATE					BIT(0)
+#define FRL_START					BIT(4)
+#define FLT_UPDATE					BIT(5)
+/* FLT Registers */
+#define FLT_CONFIG0					0x160
+#define FLT_CONFIG1					0x164
+#define FLT_CONFIG2					0x168
+#define FLT_CONTROL0					0x170
+/*  Main Unit 2 Registers */
+#define MAINUNIT_STATUS0				0x180
+/* Video Interface Registers */
+#define VIDEO_INTERFACE_CONFIG0				0x800
+#define VIDEO_INTERFACE_CONFIG1				0x804
+#define VIDEO_INTERFACE_CONFIG2				0x808
+#define VIDEO_INTERFACE_CONTROL0			0x80c
+#define VIDEO_INTERFACE_STATUS0				0x814
+/* Video Packing Registers */
+#define VIDEO_PACKING_CONFIG0				0x81c
+/* Audio Interface Registers */
+#define AUDIO_INTERFACE_CONFIG0				0x820
+#define AUD_IF_SEL_MSK					0x3
+#define AUD_IF_SPDIF					0x2
+#define AUD_IF_I2S					0x1
+#define AUD_IF_PAI					0x0
+#define AUD_FIFO_INIT_ON_OVF_MSK			BIT(2)
+#define AUD_FIFO_INIT_ON_OVF_EN				BIT(2)
+#define I2S_LINES_EN_MSK				GENMASK(7, 4)
+#define I2S_LINES_EN(x)					BIT((x) + 4)
+#define I2S_BPCUV_RCV_MSK				BIT(12)
+#define I2S_BPCUV_RCV_EN				BIT(12)
+#define I2S_BPCUV_RCV_DIS				0
+#define SPDIF_LINES_EN					GENMASK(19, 16)
+#define AUD_FORMAT_MSK					GENMASK(26, 24)
+#define AUD_3DOBA					(0x7 << 24)
+#define AUD_3DASP					(0x6 << 24)
+#define AUD_MSOBA					(0x5 << 24)
+#define AUD_MSASP					(0x4 << 24)
+#define AUD_HBR						(0x3 << 24)
+#define AUD_DST						(0x2 << 24)
+#define AUD_OBA						(0x1 << 24)
+#define AUD_ASP						(0x0 << 24)
+#define AUDIO_INTERFACE_CONFIG1				0x824
+#define AUDIO_INTERFACE_CONTROL0			0x82c
+#define AUDIO_FIFO_CLR_P				BIT(0)
+#define AUDIO_INTERFACE_STATUS0				0x834
+/* Frame Composer Registers */
+#define FRAME_COMPOSER_CONFIG0				0x840
+#define FRAME_COMPOSER_CONFIG1				0x844
+#define FRAME_COMPOSER_CONFIG2				0x848
+#define FRAME_COMPOSER_CONFIG3				0x84c
+#define FRAME_COMPOSER_CONFIG4				0x850
+#define FRAME_COMPOSER_CONFIG5				0x854
+#define FRAME_COMPOSER_CONFIG6				0x858
+#define FRAME_COMPOSER_CONFIG7				0x85c
+#define FRAME_COMPOSER_CONFIG8				0x860
+#define FRAME_COMPOSER_CONFIG9				0x864
+#define FRAME_COMPOSER_CONTROL0				0x86c
+/* Video Monitor Registers */
+#define VIDEO_MONITOR_CONFIG0				0x880
+#define VIDEO_MONITOR_STATUS0				0x884
+#define VIDEO_MONITOR_STATUS1				0x888
+#define VIDEO_MONITOR_STATUS2				0x88c
+#define VIDEO_MONITOR_STATUS3				0x890
+#define VIDEO_MONITOR_STATUS4				0x894
+#define VIDEO_MONITOR_STATUS5				0x898
+#define VIDEO_MONITOR_STATUS6				0x89c
+/* HDCP2 Logic Registers */
+#define HDCP2LOGIC_CONFIG0				0x8e0
+#define HDCP2_BYPASS					BIT(0)
+#define HDCP2LOGIC_ESM_GPIO_IN				0x8e4
+#define HDCP2LOGIC_ESM_GPIO_OUT				0x8e8
+/* HDCP14 Registers */
+#define HDCP14_CONFIG0					0x900
+#define HDCP14_CONFIG1					0x904
+#define HDCP14_CONFIG2					0x908
+#define HDCP14_CONFIG3					0x90c
+#define HDCP14_KEY_SEED					0x914
+#define HDCP14_KEY_H					0x918
+#define HDCP14_KEY_L					0x91c
+#define HDCP14_KEY_STATUS				0x920
+#define HDCP14_AKSV_H					0x924
+#define HDCP14_AKSV_L					0x928
+#define HDCP14_AN_H					0x92c
+#define HDCP14_AN_L					0x930
+#define HDCP14_STATUS0					0x934
+#define HDCP14_STATUS1					0x938
+/* Scrambler Registers */
+#define SCRAMB_CONFIG0					0x960
+/* Video Configuration Registers */
+#define LINK_CONFIG0					0x968
+#define OPMODE_FRL_4LANES				BIT(8)
+#define OPMODE_DVI					BIT(4)
+#define OPMODE_FRL					BIT(0)
+/* TMDS FIFO Registers */
+#define TMDS_FIFO_CONFIG0				0x970
+#define TMDS_FIFO_CONTROL0				0x974
+/* FRL RSFEC Registers */
+#define FRL_RSFEC_CONFIG0				0xa20
+#define FRL_RSFEC_STATUS0				0xa30
+/* FRL Packetizer Registers */
+#define FRL_PKTZ_CONFIG0				0xa40
+#define FRL_PKTZ_CONTROL0				0xa44
+#define FRL_PKTZ_CONTROL1				0xa50
+#define FRL_PKTZ_STATUS1				0xa54
+/* Packet Scheduler Registers */
+#define PKTSCHED_CONFIG0				0xa80
+#define PKTSCHED_PRQUEUE0_CONFIG0			0xa84
+#define PKTSCHED_PRQUEUE1_CONFIG0			0xa88
+#define PKTSCHED_PRQUEUE2_CONFIG0			0xa8c
+#define PKTSCHED_PRQUEUE2_CONFIG1			0xa90
+#define PKTSCHED_PRQUEUE2_CONFIG2			0xa94
+#define PKTSCHED_PKT_CONFIG0				0xa98
+#define PKTSCHED_PKT_CONFIG1				0xa9c
+#define PKTSCHED_DRMI_FIELDRATE				BIT(13)
+#define PKTSCHED_AVI_FIELDRATE				BIT(12)
+#define PKTSCHED_PKT_CONFIG2				0xaa0
+#define PKTSCHED_PKT_CONFIG3				0xaa4
+#define PKTSCHED_PKT_EN					0xaa8
+#define PKTSCHED_DRMI_TX_EN				BIT(17)
+#define PKTSCHED_AUDI_TX_EN				BIT(15)
+#define PKTSCHED_AVI_TX_EN				BIT(13)
+#define PKTSCHED_EMP_CVTEM_TX_EN			BIT(10)
+#define PKTSCHED_AMD_TX_EN				BIT(8)
+#define PKTSCHED_GCP_TX_EN				BIT(3)
+#define PKTSCHED_AUDS_TX_EN				BIT(2)
+#define PKTSCHED_ACR_TX_EN				BIT(1)
+#define PKTSCHED_NULL_TX_EN				BIT(0)
+#define PKTSCHED_PKT_CONTROL0				0xaac
+#define PKTSCHED_PKT_SEND				0xab0
+#define PKTSCHED_PKT_STATUS0				0xab4
+#define PKTSCHED_PKT_STATUS1				0xab8
+#define PKT_NULL_CONTENTS0				0xb00
+#define PKT_NULL_CONTENTS1				0xb04
+#define PKT_NULL_CONTENTS2				0xb08
+#define PKT_NULL_CONTENTS3				0xb0c
+#define PKT_NULL_CONTENTS4				0xb10
+#define PKT_NULL_CONTENTS5				0xb14
+#define PKT_NULL_CONTENTS6				0xb18
+#define PKT_NULL_CONTENTS7				0xb1c
+#define PKT_ACP_CONTENTS0				0xb20
+#define PKT_ACP_CONTENTS1				0xb24
+#define PKT_ACP_CONTENTS2				0xb28
+#define PKT_ACP_CONTENTS3				0xb2c
+#define PKT_ACP_CONTENTS4				0xb30
+#define PKT_ACP_CONTENTS5				0xb34
+#define PKT_ACP_CONTENTS6				0xb38
+#define PKT_ACP_CONTENTS7				0xb3c
+#define PKT_ISRC1_CONTENTS0				0xb40
+#define PKT_ISRC1_CONTENTS1				0xb44
+#define PKT_ISRC1_CONTENTS2				0xb48
+#define PKT_ISRC1_CONTENTS3				0xb4c
+#define PKT_ISRC1_CONTENTS4				0xb50
+#define PKT_ISRC1_CONTENTS5				0xb54
+#define PKT_ISRC1_CONTENTS6				0xb58
+#define PKT_ISRC1_CONTENTS7				0xb5c
+#define PKT_ISRC2_CONTENTS0				0xb60
+#define PKT_ISRC2_CONTENTS1				0xb64
+#define PKT_ISRC2_CONTENTS2				0xb68
+#define PKT_ISRC2_CONTENTS3				0xb6c
+#define PKT_ISRC2_CONTENTS4				0xb70
+#define PKT_ISRC2_CONTENTS5				0xb74
+#define PKT_ISRC2_CONTENTS6				0xb78
+#define PKT_ISRC2_CONTENTS7				0xb7c
+#define PKT_GMD_CONTENTS0				0xb80
+#define PKT_GMD_CONTENTS1				0xb84
+#define PKT_GMD_CONTENTS2				0xb88
+#define PKT_GMD_CONTENTS3				0xb8c
+#define PKT_GMD_CONTENTS4				0xb90
+#define PKT_GMD_CONTENTS5				0xb94
+#define PKT_GMD_CONTENTS6				0xb98
+#define PKT_GMD_CONTENTS7				0xb9c
+#define PKT_AMD_CONTENTS0				0xba0
+#define PKT_AMD_CONTENTS1				0xba4
+#define PKT_AMD_CONTENTS2				0xba8
+#define PKT_AMD_CONTENTS3				0xbac
+#define PKT_AMD_CONTENTS4				0xbb0
+#define PKT_AMD_CONTENTS5				0xbb4
+#define PKT_AMD_CONTENTS6				0xbb8
+#define PKT_AMD_CONTENTS7				0xbbc
+#define PKT_VSI_CONTENTS0				0xbc0
+#define PKT_VSI_CONTENTS1				0xbc4
+#define PKT_VSI_CONTENTS2				0xbc8
+#define PKT_VSI_CONTENTS3				0xbcc
+#define PKT_VSI_CONTENTS4				0xbd0
+#define PKT_VSI_CONTENTS5				0xbd4
+#define PKT_VSI_CONTENTS6				0xbd8
+#define PKT_VSI_CONTENTS7				0xbdc
+#define PKT_AVI_CONTENTS0				0xbe0
+#define HDMI_FC_AVICONF0_ACTIVE_FMT_INFO_PRESENT	BIT(4)
+#define HDMI_FC_AVICONF0_BAR_DATA_VERT_BAR		0x04
+#define HDMI_FC_AVICONF0_BAR_DATA_HORIZ_BAR		0x08
+#define HDMI_FC_AVICONF2_IT_CONTENT_VALID		0x80
+#define PKT_AVI_CONTENTS1				0xbe4
+#define PKT_AVI_CONTENTS2				0xbe8
+#define PKT_AVI_CONTENTS3				0xbec
+#define PKT_AVI_CONTENTS4				0xbf0
+#define PKT_AVI_CONTENTS5				0xbf4
+#define PKT_AVI_CONTENTS6				0xbf8
+#define PKT_AVI_CONTENTS7				0xbfc
+#define PKT_SPDI_CONTENTS0				0xc00
+#define PKT_SPDI_CONTENTS1				0xc04
+#define PKT_SPDI_CONTENTS2				0xc08
+#define PKT_SPDI_CONTENTS3				0xc0c
+#define PKT_SPDI_CONTENTS4				0xc10
+#define PKT_SPDI_CONTENTS5				0xc14
+#define PKT_SPDI_CONTENTS6				0xc18
+#define PKT_SPDI_CONTENTS7				0xc1c
+#define PKT_AUDI_CONTENTS0				0xc20
+#define PKT_AUDI_CONTENTS1				0xc24
+#define PKT_AUDI_CONTENTS2				0xc28
+#define PKT_AUDI_CONTENTS3				0xc2c
+#define PKT_AUDI_CONTENTS4				0xc30
+#define PKT_AUDI_CONTENTS5				0xc34
+#define PKT_AUDI_CONTENTS6				0xc38
+#define PKT_AUDI_CONTENTS7				0xc3c
+#define PKT_NVI_CONTENTS0				0xc40
+#define PKT_NVI_CONTENTS1				0xc44
+#define PKT_NVI_CONTENTS2				0xc48
+#define PKT_NVI_CONTENTS3				0xc4c
+#define PKT_NVI_CONTENTS4				0xc50
+#define PKT_NVI_CONTENTS5				0xc54
+#define PKT_NVI_CONTENTS6				0xc58
+#define PKT_NVI_CONTENTS7				0xc5c
+#define PKT_DRMI_CONTENTS0				0xc60
+#define PKT_DRMI_CONTENTS1				0xc64
+#define PKT_DRMI_CONTENTS2				0xc68
+#define PKT_DRMI_CONTENTS3				0xc6c
+#define PKT_DRMI_CONTENTS4				0xc70
+#define PKT_DRMI_CONTENTS5				0xc74
+#define PKT_DRMI_CONTENTS6				0xc78
+#define PKT_DRMI_CONTENTS7				0xc7c
+#define PKT_GHDMI1_CONTENTS0				0xc80
+#define PKT_GHDMI1_CONTENTS1				0xc84
+#define PKT_GHDMI1_CONTENTS2				0xc88
+#define PKT_GHDMI1_CONTENTS3				0xc8c
+#define PKT_GHDMI1_CONTENTS4				0xc90
+#define PKT_GHDMI1_CONTENTS5				0xc94
+#define PKT_GHDMI1_CONTENTS6				0xc98
+#define PKT_GHDMI1_CONTENTS7				0xc9c
+#define PKT_GHDMI2_CONTENTS0				0xca0
+#define PKT_GHDMI2_CONTENTS1				0xca4
+#define PKT_GHDMI2_CONTENTS2				0xca8
+#define PKT_GHDMI2_CONTENTS3				0xcac
+#define PKT_GHDMI2_CONTENTS4				0xcb0
+#define PKT_GHDMI2_CONTENTS5				0xcb4
+#define PKT_GHDMI2_CONTENTS6				0xcb8
+#define PKT_GHDMI2_CONTENTS7				0xcbc
+/* EMP Packetizer Registers */
+#define PKT_EMP_CONFIG0					0xce0
+#define PKT_EMP_CONTROL0				0xcec
+#define PKT_EMP_CONTROL1				0xcf0
+#define PKT_EMP_CONTROL2				0xcf4
+#define PKT_EMP_VTEM_CONTENTS0				0xd00
+#define PKT_EMP_VTEM_CONTENTS1				0xd04
+#define PKT_EMP_VTEM_CONTENTS2				0xd08
+#define PKT_EMP_VTEM_CONTENTS3				0xd0c
+#define PKT_EMP_VTEM_CONTENTS4				0xd10
+#define PKT_EMP_VTEM_CONTENTS5				0xd14
+#define PKT_EMP_VTEM_CONTENTS6				0xd18
+#define PKT_EMP_VTEM_CONTENTS7				0xd1c
+#define PKT0_EMP_CVTEM_CONTENTS0			0xd20
+#define PKT0_EMP_CVTEM_CONTENTS1			0xd24
+#define PKT0_EMP_CVTEM_CONTENTS2			0xd28
+#define PKT0_EMP_CVTEM_CONTENTS3			0xd2c
+#define PKT0_EMP_CVTEM_CONTENTS4			0xd30
+#define PKT0_EMP_CVTEM_CONTENTS5			0xd34
+#define PKT0_EMP_CVTEM_CONTENTS6			0xd38
+#define PKT0_EMP_CVTEM_CONTENTS7			0xd3c
+#define PKT1_EMP_CVTEM_CONTENTS0			0xd40
+#define PKT1_EMP_CVTEM_CONTENTS1			0xd44
+#define PKT1_EMP_CVTEM_CONTENTS2			0xd48
+#define PKT1_EMP_CVTEM_CONTENTS3			0xd4c
+#define PKT1_EMP_CVTEM_CONTENTS4			0xd50
+#define PKT1_EMP_CVTEM_CONTENTS5			0xd54
+#define PKT1_EMP_CVTEM_CONTENTS6			0xd58
+#define PKT1_EMP_CVTEM_CONTENTS7			0xd5c
+#define PKT2_EMP_CVTEM_CONTENTS0			0xd60
+#define PKT2_EMP_CVTEM_CONTENTS1			0xd64
+#define PKT2_EMP_CVTEM_CONTENTS2			0xd68
+#define PKT2_EMP_CVTEM_CONTENTS3			0xd6c
+#define PKT2_EMP_CVTEM_CONTENTS4			0xd70
+#define PKT2_EMP_CVTEM_CONTENTS5			0xd74
+#define PKT2_EMP_CVTEM_CONTENTS6			0xd78
+#define PKT2_EMP_CVTEM_CONTENTS7			0xd7c
+#define PKT3_EMP_CVTEM_CONTENTS0			0xd80
+#define PKT3_EMP_CVTEM_CONTENTS1			0xd84
+#define PKT3_EMP_CVTEM_CONTENTS2			0xd88
+#define PKT3_EMP_CVTEM_CONTENTS3			0xd8c
+#define PKT3_EMP_CVTEM_CONTENTS4			0xd90
+#define PKT3_EMP_CVTEM_CONTENTS5			0xd94
+#define PKT3_EMP_CVTEM_CONTENTS6			0xd98
+#define PKT3_EMP_CVTEM_CONTENTS7			0xd9c
+#define PKT4_EMP_CVTEM_CONTENTS0			0xda0
+#define PKT4_EMP_CVTEM_CONTENTS1			0xda4
+#define PKT4_EMP_CVTEM_CONTENTS2			0xda8
+#define PKT4_EMP_CVTEM_CONTENTS3			0xdac
+#define PKT4_EMP_CVTEM_CONTENTS4			0xdb0
+#define PKT4_EMP_CVTEM_CONTENTS5			0xdb4
+#define PKT4_EMP_CVTEM_CONTENTS6			0xdb8
+#define PKT4_EMP_CVTEM_CONTENTS7			0xdbc
+#define PKT5_EMP_CVTEM_CONTENTS0			0xdc0
+#define PKT5_EMP_CVTEM_CONTENTS1			0xdc4
+#define PKT5_EMP_CVTEM_CONTENTS2			0xdc8
+#define PKT5_EMP_CVTEM_CONTENTS3			0xdcc
+#define PKT5_EMP_CVTEM_CONTENTS4			0xdd0
+#define PKT5_EMP_CVTEM_CONTENTS5			0xdd4
+#define PKT5_EMP_CVTEM_CONTENTS6			0xdd8
+#define PKT5_EMP_CVTEM_CONTENTS7			0xddc
+/* Audio Packetizer Registers */
+#define AUDPKT_CONTROL0					0xe20
+#define AUDPKT_PBIT_FORCE_EN_MASK			BIT(12)
+#define AUDPKT_PBIT_FORCE_EN				BIT(12)
+#define AUDPKT_CHSTATUS_OVR_EN_MASK			BIT(0)
+#define AUDPKT_CHSTATUS_OVR_EN				BIT(0)
+#define AUDPKT_CONTROL1					0xe24
+#define AUDPKT_ACR_CONTROL0				0xe40
+#define AUDPKT_ACR_N_VALUE				0xfffff
+#define AUDPKT_ACR_CONTROL1				0xe44
+#define AUDPKT_ACR_CTS_OVR_VAL_MSK			GENMASK(23, 4)
+#define AUDPKT_ACR_CTS_OVR_VAL(x)			((x) << 4)
+#define AUDPKT_ACR_CTS_OVR_EN_MSK			BIT(1)
+#define AUDPKT_ACR_CTS_OVR_EN				BIT(1)
+#define AUDPKT_ACR_STATUS0				0xe4c
+#define AUDPKT_CHSTATUS_OVR0				0xe60
+#define AUDPKT_CHSTATUS_OVR1				0xe64
+/* IEC60958 Byte 3: Sampleing frenuency Bits 24 to 27 */
+#define AUDPKT_CHSTATUS_SR_MASK				GENMASK(3, 0)
+#define AUDPKT_CHSTATUS_SR_22050			0x4
+#define AUDPKT_CHSTATUS_SR_24000			0x6
+#define AUDPKT_CHSTATUS_SR_32000			0x3
+#define AUDPKT_CHSTATUS_SR_44100			0x0
+#define AUDPKT_CHSTATUS_SR_48000			0x2
+#define AUDPKT_CHSTATUS_SR_88200			0x8
+#define AUDPKT_CHSTATUS_SR_96000			0xa
+#define AUDPKT_CHSTATUS_SR_176400			0xc
+#define AUDPKT_CHSTATUS_SR_192000			0xe
+#define AUDPKT_CHSTATUS_SR_768000			0x9
+#define AUDPKT_CHSTATUS_SR_NOT_INDICATED		0x1
+/* IEC60958 Byte 4: Original Sampleing frenuency Bits 36 to 39 */
+#define AUDPKT_CHSTATUS_0SR_MASK			GENMASK(15, 12)
+#define AUDPKT_CHSTATUS_OSR_8000			0x6
+#define AUDPKT_CHSTATUS_OSR_11025			0xa
+#define AUDPKT_CHSTATUS_OSR_12000			0x2
+#define AUDPKT_CHSTATUS_OSR_16000			0x8
+#define AUDPKT_CHSTATUS_OSR_22050			0xb
+#define AUDPKT_CHSTATUS_OSR_24000			0x9
+#define AUDPKT_CHSTATUS_OSR_32000			0xc
+#define AUDPKT_CHSTATUS_OSR_44100			0xf
+#define AUDPKT_CHSTATUS_OSR_48000			0xd
+#define AUDPKT_CHSTATUS_OSR_88200			0x7
+#define AUDPKT_CHSTATUS_OSR_96000			0x5
+#define AUDPKT_CHSTATUS_OSR_176400			0x3
+#define AUDPKT_CHSTATUS_OSR_192000			0x1
+#define AUDPKT_CHSTATUS_OSR_NOT_INDICATED		0x0
+#define AUDPKT_CHSTATUS_OVR2				0xe68
+#define AUDPKT_CHSTATUS_OVR3				0xe6c
+#define AUDPKT_CHSTATUS_OVR4				0xe70
+#define AUDPKT_CHSTATUS_OVR5				0xe74
+#define AUDPKT_CHSTATUS_OVR6				0xe78
+#define AUDPKT_CHSTATUS_OVR7				0xe7c
+#define AUDPKT_CHSTATUS_OVR8				0xe80
+#define AUDPKT_CHSTATUS_OVR9				0xe84
+#define AUDPKT_CHSTATUS_OVR10				0xe88
+#define AUDPKT_CHSTATUS_OVR11				0xe8c
+#define AUDPKT_CHSTATUS_OVR12				0xe90
+#define AUDPKT_CHSTATUS_OVR13				0xe94
+#define AUDPKT_CHSTATUS_OVR14				0xe98
+#define AUDPKT_USRDATA_OVR_MSG_GENERIC0			0xea0
+#define AUDPKT_USRDATA_OVR_MSG_GENERIC1			0xea4
+#define AUDPKT_USRDATA_OVR_MSG_GENERIC2			0xea8
+#define AUDPKT_USRDATA_OVR_MSG_GENERIC3			0xeac
+#define AUDPKT_USRDATA_OVR_MSG_GENERIC4			0xeb0
+#define AUDPKT_USRDATA_OVR_MSG_GENERIC5			0xeb4
+#define AUDPKT_USRDATA_OVR_MSG_GENERIC6			0xeb8
+#define AUDPKT_USRDATA_OVR_MSG_GENERIC7			0xebc
+#define AUDPKT_USRDATA_OVR_MSG_GENERIC8			0xec0
+#define AUDPKT_USRDATA_OVR_MSG_GENERIC9			0xec4
+#define AUDPKT_USRDATA_OVR_MSG_GENERIC10		0xec8
+#define AUDPKT_USRDATA_OVR_MSG_GENERIC11		0xecc
+#define AUDPKT_USRDATA_OVR_MSG_GENERIC12		0xed0
+#define AUDPKT_USRDATA_OVR_MSG_GENERIC13		0xed4
+#define AUDPKT_USRDATA_OVR_MSG_GENERIC14		0xed8
+#define AUDPKT_USRDATA_OVR_MSG_GENERIC15		0xedc
+#define AUDPKT_USRDATA_OVR_MSG_GENERIC16		0xee0
+#define AUDPKT_USRDATA_OVR_MSG_GENERIC17		0xee4
+#define AUDPKT_USRDATA_OVR_MSG_GENERIC18		0xee8
+#define AUDPKT_USRDATA_OVR_MSG_GENERIC19		0xeec
+#define AUDPKT_USRDATA_OVR_MSG_GENERIC20		0xef0
+#define AUDPKT_USRDATA_OVR_MSG_GENERIC21		0xef4
+#define AUDPKT_USRDATA_OVR_MSG_GENERIC22		0xef8
+#define AUDPKT_USRDATA_OVR_MSG_GENERIC23		0xefc
+#define AUDPKT_USRDATA_OVR_MSG_GENERIC24		0xf00
+#define AUDPKT_USRDATA_OVR_MSG_GENERIC25		0xf04
+#define AUDPKT_USRDATA_OVR_MSG_GENERIC26		0xf08
+#define AUDPKT_USRDATA_OVR_MSG_GENERIC27		0xf0c
+#define AUDPKT_USRDATA_OVR_MSG_GENERIC28		0xf10
+#define AUDPKT_USRDATA_OVR_MSG_GENERIC29		0xf14
+#define AUDPKT_USRDATA_OVR_MSG_GENERIC30		0xf18
+#define AUDPKT_USRDATA_OVR_MSG_GENERIC31		0xf1c
+#define AUDPKT_USRDATA_OVR_MSG_GENERIC32		0xf20
+#define AUDPKT_VBIT_OVR0				0xf24
+/* CEC Registers */
+#define CEC_TX_CONTROL					0x1000
+#define CEC_STATUS					0x1004
+#define CEC_CONFIG					0x1008
+#define CEC_ADDR					0x100c
+#define CEC_TX_COUNT					0x1020
+#define CEC_TX_DATA3_0					0x1024
+#define CEC_TX_DATA7_4					0x1028
+#define CEC_TX_DATA11_8					0x102c
+#define CEC_TX_DATA15_12				0x1030
+#define CEC_RX_COUNT_STATUS				0x1040
+#define CEC_RX_DATA3_0					0x1044
+#define CEC_RX_DATA7_4					0x1048
+#define CEC_RX_DATA11_8					0x104c
+#define CEC_RX_DATA15_12				0x1050
+#define CEC_LOCK_CONTROL				0x1054
+#define CEC_RXQUAL_BITTIME_CONFIG			0x1060
+#define CEC_RX_BITTIME_CONFIG				0x1064
+#define CEC_TX_BITTIME_CONFIG				0x1068
+/* eARC RX CMDC Registers */
+#define EARCRX_CMDC_CONFIG0				0x1800
+#define EARCRX_XACTREAD_STOP_CFG			BIT(26)
+#define EARCRX_XACTREAD_RETRY_CFG			BIT(25)
+#define EARCRX_CMDC_DSCVR_EARCVALID0_TO_DISC1		BIT(24)
+#define EARCRX_CMDC_XACT_RESTART_EN			BIT(18)
+#define EARCRX_CMDC_CONFIG1				0x1804
+#define EARCRX_CMDC_CONTROL				0x1808
+#define EARCRX_CMDC_HEARTBEAT_LOSS_EN			BIT(4)
+#define EARCRX_CMDC_DISCOVERY_EN			BIT(3)
+#define EARCRX_CONNECTOR_HPD				BIT(1)
+#define EARCRX_CMDC_WHITELIST0_CONFIG			0x180c
+#define EARCRX_CMDC_WHITELIST1_CONFIG			0x1810
+#define EARCRX_CMDC_WHITELIST2_CONFIG			0x1814
+#define EARCRX_CMDC_WHITELIST3_CONFIG			0x1818
+#define EARCRX_CMDC_STATUS				0x181c
+#define EARCRX_CMDC_XACT_INFO				0x1820
+#define EARCRX_CMDC_XACT_ACTION				0x1824
+#define EARCRX_CMDC_HEARTBEAT_RXSTAT_SE			0x1828
+#define EARCRX_CMDC_HEARTBEAT_STATUS			0x182c
+#define EARCRX_CMDC_XACT_WR0				0x1840
+#define EARCRX_CMDC_XACT_WR1				0x1844
+#define EARCRX_CMDC_XACT_WR2				0x1848
+#define EARCRX_CMDC_XACT_WR3				0x184c
+#define EARCRX_CMDC_XACT_WR4				0x1850
+#define EARCRX_CMDC_XACT_WR5				0x1854
+#define EARCRX_CMDC_XACT_WR6				0x1858
+#define EARCRX_CMDC_XACT_WR7				0x185c
+#define EARCRX_CMDC_XACT_WR8				0x1860
+#define EARCRX_CMDC_XACT_WR9				0x1864
+#define EARCRX_CMDC_XACT_WR10				0x1868
+#define EARCRX_CMDC_XACT_WR11				0x186c
+#define EARCRX_CMDC_XACT_WR12				0x1870
+#define EARCRX_CMDC_XACT_WR13				0x1874
+#define EARCRX_CMDC_XACT_WR14				0x1878
+#define EARCRX_CMDC_XACT_WR15				0x187c
+#define EARCRX_CMDC_XACT_WR16				0x1880
+#define EARCRX_CMDC_XACT_WR17				0x1884
+#define EARCRX_CMDC_XACT_WR18				0x1888
+#define EARCRX_CMDC_XACT_WR19				0x188c
+#define EARCRX_CMDC_XACT_WR20				0x1890
+#define EARCRX_CMDC_XACT_WR21				0x1894
+#define EARCRX_CMDC_XACT_WR22				0x1898
+#define EARCRX_CMDC_XACT_WR23				0x189c
+#define EARCRX_CMDC_XACT_WR24				0x18a0
+#define EARCRX_CMDC_XACT_WR25				0x18a4
+#define EARCRX_CMDC_XACT_WR26				0x18a8
+#define EARCRX_CMDC_XACT_WR27				0x18ac
+#define EARCRX_CMDC_XACT_WR28				0x18b0
+#define EARCRX_CMDC_XACT_WR29				0x18b4
+#define EARCRX_CMDC_XACT_WR30				0x18b8
+#define EARCRX_CMDC_XACT_WR31				0x18bc
+#define EARCRX_CMDC_XACT_WR32				0x18c0
+#define EARCRX_CMDC_XACT_WR33				0x18c4
+#define EARCRX_CMDC_XACT_WR34				0x18c8
+#define EARCRX_CMDC_XACT_WR35				0x18cc
+#define EARCRX_CMDC_XACT_WR36				0x18d0
+#define EARCRX_CMDC_XACT_WR37				0x18d4
+#define EARCRX_CMDC_XACT_WR38				0x18d8
+#define EARCRX_CMDC_XACT_WR39				0x18dc
+#define EARCRX_CMDC_XACT_WR40				0x18e0
+#define EARCRX_CMDC_XACT_WR41				0x18e4
+#define EARCRX_CMDC_XACT_WR42				0x18e8
+#define EARCRX_CMDC_XACT_WR43				0x18ec
+#define EARCRX_CMDC_XACT_WR44				0x18f0
+#define EARCRX_CMDC_XACT_WR45				0x18f4
+#define EARCRX_CMDC_XACT_WR46				0x18f8
+#define EARCRX_CMDC_XACT_WR47				0x18fc
+#define EARCRX_CMDC_XACT_WR48				0x1900
+#define EARCRX_CMDC_XACT_WR49				0x1904
+#define EARCRX_CMDC_XACT_WR50				0x1908
+#define EARCRX_CMDC_XACT_WR51				0x190c
+#define EARCRX_CMDC_XACT_WR52				0x1910
+#define EARCRX_CMDC_XACT_WR53				0x1914
+#define EARCRX_CMDC_XACT_WR54				0x1918
+#define EARCRX_CMDC_XACT_WR55				0x191c
+#define EARCRX_CMDC_XACT_WR56				0x1920
+#define EARCRX_CMDC_XACT_WR57				0x1924
+#define EARCRX_CMDC_XACT_WR58				0x1928
+#define EARCRX_CMDC_XACT_WR59				0x192c
+#define EARCRX_CMDC_XACT_WR60				0x1930
+#define EARCRX_CMDC_XACT_WR61				0x1934
+#define EARCRX_CMDC_XACT_WR62				0x1938
+#define EARCRX_CMDC_XACT_WR63				0x193c
+#define EARCRX_CMDC_XACT_WR64				0x1940
+#define EARCRX_CMDC_XACT_RD0				0x1960
+#define EARCRX_CMDC_XACT_RD1				0x1964
+#define EARCRX_CMDC_XACT_RD2				0x1968
+#define EARCRX_CMDC_XACT_RD3				0x196c
+#define EARCRX_CMDC_XACT_RD4				0x1970
+#define EARCRX_CMDC_XACT_RD5				0x1974
+#define EARCRX_CMDC_XACT_RD6				0x1978
+#define EARCRX_CMDC_XACT_RD7				0x197c
+#define EARCRX_CMDC_XACT_RD8				0x1980
+#define EARCRX_CMDC_XACT_RD9				0x1984
+#define EARCRX_CMDC_XACT_RD10				0x1988
+#define EARCRX_CMDC_XACT_RD11				0x198c
+#define EARCRX_CMDC_XACT_RD12				0x1990
+#define EARCRX_CMDC_XACT_RD13				0x1994
+#define EARCRX_CMDC_XACT_RD14				0x1998
+#define EARCRX_CMDC_XACT_RD15				0x199c
+#define EARCRX_CMDC_XACT_RD16				0x19a0
+#define EARCRX_CMDC_XACT_RD17				0x19a4
+#define EARCRX_CMDC_XACT_RD18				0x19a8
+#define EARCRX_CMDC_XACT_RD19				0x19ac
+#define EARCRX_CMDC_XACT_RD20				0x19b0
+#define EARCRX_CMDC_XACT_RD21				0x19b4
+#define EARCRX_CMDC_XACT_RD22				0x19b8
+#define EARCRX_CMDC_XACT_RD23				0x19bc
+#define EARCRX_CMDC_XACT_RD24				0x19c0
+#define EARCRX_CMDC_XACT_RD25				0x19c4
+#define EARCRX_CMDC_XACT_RD26				0x19c8
+#define EARCRX_CMDC_XACT_RD27				0x19cc
+#define EARCRX_CMDC_XACT_RD28				0x19d0
+#define EARCRX_CMDC_XACT_RD29				0x19d4
+#define EARCRX_CMDC_XACT_RD30				0x19d8
+#define EARCRX_CMDC_XACT_RD31				0x19dc
+#define EARCRX_CMDC_XACT_RD32				0x19e0
+#define EARCRX_CMDC_XACT_RD33				0x19e4
+#define EARCRX_CMDC_XACT_RD34				0x19e8
+#define EARCRX_CMDC_XACT_RD35				0x19ec
+#define EARCRX_CMDC_XACT_RD36				0x19f0
+#define EARCRX_CMDC_XACT_RD37				0x19f4
+#define EARCRX_CMDC_XACT_RD38				0x19f8
+#define EARCRX_CMDC_XACT_RD39				0x19fc
+#define EARCRX_CMDC_XACT_RD40				0x1a00
+#define EARCRX_CMDC_XACT_RD41				0x1a04
+#define EARCRX_CMDC_XACT_RD42				0x1a08
+#define EARCRX_CMDC_XACT_RD43				0x1a0c
+#define EARCRX_CMDC_XACT_RD44				0x1a10
+#define EARCRX_CMDC_XACT_RD45				0x1a14
+#define EARCRX_CMDC_XACT_RD46				0x1a18
+#define EARCRX_CMDC_XACT_RD47				0x1a1c
+#define EARCRX_CMDC_XACT_RD48				0x1a20
+#define EARCRX_CMDC_XACT_RD49				0x1a24
+#define EARCRX_CMDC_XACT_RD50				0x1a28
+#define EARCRX_CMDC_XACT_RD51				0x1a2c
+#define EARCRX_CMDC_XACT_RD52				0x1a30
+#define EARCRX_CMDC_XACT_RD53				0x1a34
+#define EARCRX_CMDC_XACT_RD54				0x1a38
+#define EARCRX_CMDC_XACT_RD55				0x1a3c
+#define EARCRX_CMDC_XACT_RD56				0x1a40
+#define EARCRX_CMDC_XACT_RD57				0x1a44
+#define EARCRX_CMDC_XACT_RD58				0x1a48
+#define EARCRX_CMDC_XACT_RD59				0x1a4c
+#define EARCRX_CMDC_XACT_RD60				0x1a50
+#define EARCRX_CMDC_XACT_RD61				0x1a54
+#define EARCRX_CMDC_XACT_RD62				0x1a58
+#define EARCRX_CMDC_XACT_RD63				0x1a5c
+#define EARCRX_CMDC_XACT_RD64				0x1a60
+#define EARCRX_CMDC_SYNC_CONFIG				0x1b00
+/* eARC RX DMAC Registers */
+#define EARCRX_DMAC_PHY_CONTROL				0x1c00
+#define EARCRX_DMAC_CONFIG				0x1c08
+#define EARCRX_DMAC_CONTROL0				0x1c0c
+#define EARCRX_DMAC_AUDIO_EN				BIT(1)
+#define EARCRX_DMAC_EN					BIT(0)
+#define EARCRX_DMAC_CONTROL1				0x1c10
+#define EARCRX_DMAC_STATUS				0x1c14
+#define EARCRX_DMAC_CHSTATUS0				0x1c18
+#define EARCRX_DMAC_CHSTATUS1				0x1c1c
+#define EARCRX_DMAC_CHSTATUS2				0x1c20
+#define EARCRX_DMAC_CHSTATUS3				0x1c24
+#define EARCRX_DMAC_CHSTATUS4				0x1c28
+#define EARCRX_DMAC_CHSTATUS5				0x1c2c
+#define EARCRX_DMAC_USRDATA_MSG_HDMI_AC0		0x1c30
+#define EARCRX_DMAC_USRDATA_MSG_HDMI_AC1		0x1c34
+#define EARCRX_DMAC_USRDATA_MSG_HDMI_AC2		0x1c38
+#define EARCRX_DMAC_USRDATA_MSG_HDMI_AC3		0x1c3c
+#define EARCRX_DMAC_USRDATA_MSG_HDMI_AC4		0x1c40
+#define EARCRX_DMAC_USRDATA_MSG_HDMI_AC5		0x1c44
+#define EARCRX_DMAC_USRDATA_MSG_HDMI_AC6		0x1c48
+#define EARCRX_DMAC_USRDATA_MSG_HDMI_AC7		0x1c4c
+#define EARCRX_DMAC_USRDATA_MSG_HDMI_AC8		0x1c50
+#define EARCRX_DMAC_USRDATA_MSG_HDMI_AC9		0x1c54
+#define EARCRX_DMAC_USRDATA_MSG_HDMI_AC10		0x1c58
+#define EARCRX_DMAC_USRDATA_MSG_HDMI_AC11		0x1c5c
+#define EARCRX_DMAC_USRDATA_MSG_HDMI_ISRC1_PKT0		0x1c60
+#define EARCRX_DMAC_USRDATA_MSG_HDMI_ISRC1_PKT1		0x1c64
+#define EARCRX_DMAC_USRDATA_MSG_HDMI_ISRC1_PKT2		0x1c68
+#define EARCRX_DMAC_USRDATA_MSG_HDMI_ISRC1_PKT3		0x1c6c
+#define EARCRX_DMAC_USRDATA_MSG_HDMI_ISRC1_PKT4		0x1c70
+#define EARCRX_DMAC_USRDATA_MSG_HDMI_ISRC1_PKT5		0x1c74
+#define EARCRX_DMAC_USRDATA_MSG_HDMI_ISRC1_PKT6		0x1c78
+#define EARCRX_DMAC_USRDATA_MSG_HDMI_ISRC1_PKT7		0x1c7c
+#define EARCRX_DMAC_USRDATA_MSG_HDMI_ISRC1_PKT8		0x1c80
+#define EARCRX_DMAC_USRDATA_MSG_HDMI_ISRC1_PKT9		0x1c84
+#define EARCRX_DMAC_USRDATA_MSG_HDMI_ISRC1_PKT10	0x1c88
+#define EARCRX_DMAC_USRDATA_MSG_HDMI_ISRC1_PKT11	0x1c8c
+#define EARCRX_DMAC_USRDATA_MSG_HDMI_ISRC2_PKT0		0x1c90
+#define EARCRX_DMAC_USRDATA_MSG_HDMI_ISRC2_PKT1		0x1c94
+#define EARCRX_DMAC_USRDATA_MSG_HDMI_ISRC2_PKT2		0x1c98
+#define EARCRX_DMAC_USRDATA_MSG_HDMI_ISRC2_PKT3		0x1c9c
+#define EARCRX_DMAC_USRDATA_MSG_HDMI_ISRC2_PKT4		0x1ca0
+#define EARCRX_DMAC_USRDATA_MSG_HDMI_ISRC2_PKT5		0x1ca4
+#define EARCRX_DMAC_USRDATA_MSG_HDMI_ISRC2_PKT6		0x1ca8
+#define EARCRX_DMAC_USRDATA_MSG_HDMI_ISRC2_PKT7		0x1cac
+#define EARCRX_DMAC_USRDATA_MSG_HDMI_ISRC2_PKT8		0x1cb0
+#define EARCRX_DMAC_USRDATA_MSG_HDMI_ISRC2_PKT9		0x1cb4
+#define EARCRX_DMAC_USRDATA_MSG_HDMI_ISRC2_PKT10	0x1cb8
+#define EARCRX_DMAC_USRDATA_MSG_HDMI_ISRC2_PKT11	0x1cbc
+#define EARCRX_DMAC_USRDATA_MSG_GENERIC0		0x1cc0
+#define EARCRX_DMAC_USRDATA_MSG_GENERIC1		0x1cc4
+#define EARCRX_DMAC_USRDATA_MSG_GENERIC2		0x1cc8
+#define EARCRX_DMAC_USRDATA_MSG_GENERIC3		0x1ccc
+#define EARCRX_DMAC_USRDATA_MSG_GENERIC4		0x1cd0
+#define EARCRX_DMAC_USRDATA_MSG_GENERIC5		0x1cd4
+#define EARCRX_DMAC_USRDATA_MSG_GENERIC6		0x1cd8
+#define EARCRX_DMAC_USRDATA_MSG_GENERIC7		0x1cdc
+#define EARCRX_DMAC_USRDATA_MSG_GENERIC8		0x1ce0
+#define EARCRX_DMAC_USRDATA_MSG_GENERIC9		0x1ce4
+#define EARCRX_DMAC_USRDATA_MSG_GENERIC10		0x1ce8
+#define EARCRX_DMAC_USRDATA_MSG_GENERIC11		0x1cec
+#define EARCRX_DMAC_USRDATA_MSG_GENERIC12		0x1cf0
+#define EARCRX_DMAC_USRDATA_MSG_GENERIC13		0x1cf4
+#define EARCRX_DMAC_USRDATA_MSG_GENERIC14		0x1cf8
+#define EARCRX_DMAC_USRDATA_MSG_GENERIC15		0x1cfc
+#define EARCRX_DMAC_USRDATA_MSG_GENERIC16		0x1d00
+#define EARCRX_DMAC_USRDATA_MSG_GENERIC17		0x1d04
+#define EARCRX_DMAC_USRDATA_MSG_GENERIC18		0x1d08
+#define EARCRX_DMAC_USRDATA_MSG_GENERIC19		0x1d0c
+#define EARCRX_DMAC_USRDATA_MSG_GENERIC20		0x1d10
+#define EARCRX_DMAC_USRDATA_MSG_GENERIC21		0x1d14
+#define EARCRX_DMAC_USRDATA_MSG_GENERIC22		0x1d18
+#define EARCRX_DMAC_USRDATA_MSG_GENERIC23		0x1d1c
+#define EARCRX_DMAC_USRDATA_MSG_GENERIC24		0x1d20
+#define EARCRX_DMAC_USRDATA_MSG_GENERIC25		0x1d24
+#define EARCRX_DMAC_USRDATA_MSG_GENERIC26		0x1d28
+#define EARCRX_DMAC_USRDATA_MSG_GENERIC27		0x1d2c
+#define EARCRX_DMAC_USRDATA_MSG_GENERIC28		0x1d30
+#define EARCRX_DMAC_USRDATA_MSG_GENERIC29		0x1d34
+#define EARCRX_DMAC_USRDATA_MSG_GENERIC30		0x1d38
+#define EARCRX_DMAC_USRDATA_MSG_GENERIC31		0x1d3c
+#define EARCRX_DMAC_USRDATA_MSG_GENERIC32		0x1d40
+#define EARCRX_DMAC_CHSTATUS_STREAMER0			0x1d44
+#define EARCRX_DMAC_CHSTATUS_STREAMER1			0x1d48
+#define EARCRX_DMAC_CHSTATUS_STREAMER2			0x1d4c
+#define EARCRX_DMAC_CHSTATUS_STREAMER3			0x1d50
+#define EARCRX_DMAC_CHSTATUS_STREAMER4			0x1d54
+#define EARCRX_DMAC_CHSTATUS_STREAMER5			0x1d58
+#define EARCRX_DMAC_CHSTATUS_STREAMER6			0x1d5c
+#define EARCRX_DMAC_CHSTATUS_STREAMER7			0x1d60
+#define EARCRX_DMAC_CHSTATUS_STREAMER8			0x1d64
+#define EARCRX_DMAC_CHSTATUS_STREAMER9			0x1d68
+#define EARCRX_DMAC_CHSTATUS_STREAMER10			0x1d6c
+#define EARCRX_DMAC_CHSTATUS_STREAMER11			0x1d70
+#define EARCRX_DMAC_CHSTATUS_STREAMER12			0x1d74
+#define EARCRX_DMAC_CHSTATUS_STREAMER13			0x1d78
+#define EARCRX_DMAC_CHSTATUS_STREAMER14			0x1d7c
+#define EARCRX_DMAC_USRDATA_STREAMER0			0x1d80
+/* Main Unit Interrupt Registers */
+#define MAIN_INTVEC_INDEX				0x3000
+#define MAINUNIT_0_INT_STATUS				0x3010
+#define MAINUNIT_0_INT_MASK_N				0x3014
+#define MAINUNIT_0_INT_CLEAR				0x3018
+#define MAINUNIT_0_INT_FORCE				0x301c
+#define MAINUNIT_1_INT_STATUS				0x3020
+#define FLT_EXIT_TO_LTSL_IRQ				BIT(22)
+#define FLT_EXIT_TO_LTS4_IRQ				BIT(21)
+#define FLT_EXIT_TO_LTSP_IRQ				BIT(20)
+#define SCDC_NACK_RCVD_IRQ				BIT(12)
+#define SCDC_RR_REPLY_STOP_IRQ				BIT(11)
+#define SCDC_UPD_FLAGS_CLR_IRQ				BIT(10)
+#define SCDC_UPD_FLAGS_CHG_IRQ				BIT(9)
+#define SCDC_UPD_FLAGS_RD_IRQ				BIT(8)
+#define I2CM_NACK_RCVD_IRQ				BIT(2)
+#define I2CM_READ_REQUEST_IRQ				BIT(1)
+#define I2CM_OP_DONE_IRQ				BIT(0)
+#define MAINUNIT_1_INT_MASK_N				0x3024
+#define I2CM_NACK_RCVD_MASK_N				BIT(2)
+#define I2CM_READ_REQUEST_MASK_N			BIT(1)
+#define I2CM_OP_DONE_MASK_N				BIT(0)
+#define MAINUNIT_1_INT_CLEAR				0x3028
+#define I2CM_NACK_RCVD_CLEAR				BIT(2)
+#define I2CM_READ_REQUEST_CLEAR				BIT(1)
+#define I2CM_OP_DONE_CLEAR				BIT(0)
+#define MAINUNIT_1_INT_FORCE				0x302c
+/* AVPUNIT Interrupt Registers */
+#define AVP_INTVEC_INDEX				0x3800
+#define AVP_0_INT_STATUS				0x3810
+#define AVP_0_INT_MASK_N				0x3814
+#define AVP_0_INT_CLEAR					0x3818
+#define AVP_0_INT_FORCE					0x381c
+#define AVP_1_INT_STATUS				0x3820
+#define AVP_1_INT_MASK_N				0x3824
+#define HDCP14_AUTH_CHG_MASK_N				BIT(6)
+#define AVP_1_INT_CLEAR					0x3828
+#define AVP_1_INT_FORCE					0x382c
+#define AVP_2_INT_STATUS				0x3830
+#define AVP_2_INT_MASK_N				0x3834
+#define AVP_2_INT_CLEAR					0x3838
+#define AVP_2_INT_FORCE					0x383c
+#define AVP_3_INT_STATUS				0x3840
+#define AVP_3_INT_MASK_N				0x3844
+#define AVP_3_INT_CLEAR					0x3848
+#define AVP_3_INT_FORCE					0x384c
+#define AVP_4_INT_STATUS				0x3850
+#define AVP_4_INT_MASK_N				0x3854
+#define AVP_4_INT_CLEAR					0x3858
+#define AVP_4_INT_FORCE					0x385c
+#define AVP_5_INT_STATUS				0x3860
+#define AVP_5_INT_MASK_N				0x3864
+#define AVP_5_INT_CLEAR					0x3868
+#define AVP_5_INT_FORCE					0x386c
+#define AVP_6_INT_STATUS				0x3870
+#define AVP_6_INT_MASK_N				0x3874
+#define AVP_6_INT_CLEAR					0x3878
+#define AVP_6_INT_FORCE					0x387c
+/* CEC Interrupt Registers */
+#define CEC_INT_STATUS					0x4000
+#define CEC_INT_MASK_N					0x4004
+#define CEC_INT_CLEAR					0x4008
+#define CEC_INT_FORCE					0x400c
+/* eARC RX Interrupt Registers  */
+#define EARCRX_INTVEC_INDEX				0x4800
+#define EARCRX_0_INT_STATUS				0x4810
+#define EARCRX_CMDC_DISCOVERY_TIMEOUT_IRQ		BIT(9)
+#define EARCRX_CMDC_DISCOVERY_DONE_IRQ			BIT(8)
+#define EARCRX_0_INT_MASK_N				0x4814
+#define EARCRX_0_INT_CLEAR				0x4818
+#define EARCRX_0_INT_FORCE				0x481c
+#define EARCRX_1_INT_STATUS				0x4820
+#define EARCRX_1_INT_MASK_N				0x4824
+#define EARCRX_1_INT_CLEAR				0x4828
+#define EARCRX_1_INT_FORCE				0x482c
+
+#endif /* __DW_HDMI_QP_H__ */
diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h
index 6a46baa0737c..a9cc4604222a 100644
--- a/include/drm/bridge/dw_hdmi.h
+++ b/include/drm/bridge/dw_hdmi.h
@@ -131,6 +131,7 @@ struct dw_hdmi_plat_data {
 	unsigned long input_bus_encoding;
 	bool use_drm_infoframe;
 	bool ycbcr_420_allowed;
+	bool is_hdmi_qp;
 
 	/*
 	 * Private data passed to all the .mode_valid() and .configure_phy()
@@ -162,6 +163,7 @@ struct dw_hdmi_plat_data {
 			     unsigned long mpixelclock);
 
 	unsigned int disable_cec : 1;
+
 };
 
 struct dw_hdmi *dw_hdmi_probe(struct platform_device *pdev,
@@ -206,6 +208,12 @@ void dw_hdmi_phy_update_hpd(struct dw_hdmi *hdmi, void *data,
 			    bool force, bool disabled, bool rxsense);
 void dw_hdmi_phy_setup_hpd(struct dw_hdmi *hdmi, void *data);
 
+void dw_hdmi_qp_unbind(struct dw_hdmi *hdmi);
+struct dw_hdmi *dw_hdmi_qp_bind(struct platform_device *pdev,
+				struct drm_encoder *encoder,
+				struct dw_hdmi_plat_data *plat_data);
+void dw_hdmi_qp_resume(struct device *dev, struct dw_hdmi *hdmi);
+
 bool dw_hdmi_bus_fmt_is_420(struct dw_hdmi *hdmi);
 
 #endif /* __IMX_HDMI_H__ */

-- 
2.45.0


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 14/14] drm/rockchip: dw_hdmi: Add basic RK3588 support

[Cristian Ciocaltea]

The RK3588 SoC family integrates the newer Synopsys DesignWare HDMI 2.1
Quad-Pixel (QP) TX controller IP and a HDMI/eDP TX Combo PHY based on a
Samsung IP block.

Add just the basic support for now, i.e. RGB output up to 4K@60Hz,
without audio, CEC or any of the HDMI 2.1 specific features.

Co-developed-by: Algea Cao <algea.cao@rock-chips.com>
Signed-off-by: Algea Cao <algea.cao@rock-chips.com>
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
---
 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 261 +++++++++++++++++++++++++++-
 1 file changed, 253 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index ca6728a43159..48a777fe4214 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -29,8 +29,8 @@
 
 #define RK3288_GRF_SOC_CON6		0x025C
 #define RK3288_HDMI_LCDC_SEL		BIT(4)
-#define RK3328_GRF_SOC_CON2		0x0408
 
+#define RK3328_GRF_SOC_CON2		0x0408
 #define RK3328_HDMI_SDAIN_MSK		BIT(11)
 #define RK3328_HDMI_SCLIN_MSK		BIT(10)
 #define RK3328_HDMI_HPD_IOE		BIT(2)
@@ -54,6 +54,21 @@
 #define RK3568_HDMI_SDAIN_MSK		BIT(15)
 #define RK3568_HDMI_SCLIN_MSK		BIT(14)
 
+#define RK3588_GRF_SOC_CON2		0x0308
+#define RK3588_HDMI0_HPD_INT_MSK	BIT(13)
+#define RK3588_HDMI0_HPD_INT_CLR	BIT(12)
+#define RK3588_GRF_SOC_CON7		0x031c
+#define RK3588_SET_HPD_PATH_MASK	(0x3 << 12)
+#define RK3588_GRF_SOC_STATUS1		0x0384
+#define RK3588_HDMI0_LEVEL_INT		BIT(16)
+#define RK3588_GRF_VO1_CON3		0x000c
+#define RK3588_SCLIN_MASK		BIT(9)
+#define RK3588_SDAIN_MASK		BIT(10)
+#define RK3588_MODE_MASK		BIT(11)
+#define RK3588_I2S_SEL_MASK		BIT(13)
+#define RK3588_GRF_VO1_CON9		0x0024
+#define RK3588_HDMI0_GRANT_SEL		BIT(10)
+
 #define HIWORD_UPDATE(val, mask)	(val | (mask) << 16)
 
 /**
@@ -71,6 +86,7 @@ struct rockchip_hdmi_chip_data {
 struct rockchip_hdmi {
 	struct device *dev;
 	struct regmap *regmap;
+	struct regmap *vo1_regmap;
 	struct rockchip_encoder encoder;
 	const struct rockchip_hdmi_chip_data *chip_data;
 	const struct dw_hdmi_plat_data *plat_data;
@@ -78,6 +94,10 @@ struct rockchip_hdmi {
 	struct clk *grf_clk;
 	struct dw_hdmi *hdmi;
 	struct phy *phy;
+
+	bool is_hdmi_qp;
+	struct gpio_desc *qp_enable_gpio;
+	struct delayed_work qp_hpd_work;
 };
 
 static struct rockchip_hdmi *to_rockchip_hdmi(struct drm_encoder *encoder)
@@ -206,8 +226,12 @@ static const struct dw_hdmi_phy_config rockchip_phy_config[] = {
 
 static int rockchip_hdmi_parse_dt(struct rockchip_hdmi *hdmi)
 {
+	static const char * const qp_clk_names[] = {
+		"pclk", "hdp", "earc", "aud", "hclk_vo1",
+	};
 	struct device_node *np = hdmi->dev->of_node;
-	int ret;
+	struct clk *qp_clk;
+	int ret, i;
 
 	hdmi->regmap = syscon_regmap_lookup_by_phandle(np, "rockchip,grf");
 	if (IS_ERR(hdmi->regmap)) {
@@ -234,6 +258,34 @@ static int rockchip_hdmi_parse_dt(struct rockchip_hdmi *hdmi)
 		return ret;
 	}
 
+	if (hdmi->is_hdmi_qp) {
+		hdmi->vo1_regmap = syscon_regmap_lookup_by_phandle(np, "rockchip,vo1_grf");
+		if (IS_ERR(hdmi->vo1_regmap)) {
+			drm_err(hdmi, "Unable to get rockchip,vo1_grf\n");
+			return PTR_ERR(hdmi->vo1_regmap);
+		}
+
+		for (i = 0; i < ARRAY_SIZE(qp_clk_names); i++) {
+			qp_clk = devm_clk_get_optional_enabled(hdmi->dev, qp_clk_names[i]);
+
+			if (IS_ERR(qp_clk)) {
+				ret = PTR_ERR(qp_clk);
+				if (ret != -EPROBE_DEFER)
+					drm_err(hdmi, "failed to get %s clock: %d\n",
+						qp_clk_names[i], ret);
+				return ret;
+			}
+		}
+
+		hdmi->qp_enable_gpio = devm_gpiod_get_optional(hdmi->dev, "enable",
+							       GPIOD_OUT_HIGH);
+		if (IS_ERR(hdmi->qp_enable_gpio)) {
+			ret = PTR_ERR(hdmi->qp_enable_gpio);
+			drm_err(hdmi, "failed to request enable GPIO: %d\n", ret);
+			return ret;
+		}
+	}
+
 	ret = devm_regulator_get_enable(hdmi->dev, "avdd-0v9");
 	if (ret)
 		return ret;
@@ -303,8 +355,32 @@ static void dw_hdmi_rockchip_encoder_mode_set(struct drm_encoder *encoder,
 static void dw_hdmi_rockchip_encoder_enable(struct drm_encoder *encoder)
 {
 	struct rockchip_hdmi *hdmi = to_rockchip_hdmi(encoder);
+	struct drm_crtc *crtc = encoder->crtc;
 	u32 val;
-	int ret;
+	int ret, rate;
+
+	if (hdmi->is_hdmi_qp) {
+		/* Unconditionally switch to TMDS as FRL is not yet supported */
+		gpiod_set_value(hdmi->qp_enable_gpio, 1);
+
+		if (crtc && crtc->state) {
+			clk_set_rate(hdmi->ref_clk,
+				     crtc->state->adjusted_mode.crtc_clock * 1000);
+			/*
+			 * FIXME: Temporary workaround to pass pixel clock rate
+			 * to the PHY driver until phy_configure_opts_hdmi
+			 * becomes available in the PHY API. See also the related
+			 * comment in rk_hdptx_phy_power_on() from
+			 * drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c
+			 */
+			if (hdmi->phy) {
+				rate = crtc->state->mode.clock * 10;
+				phy_set_bus_width(hdmi->phy, rate);
+				drm_dbg(hdmi, "%s set bus_width=%u\n",
+					__func__, rate);
+			}
+		}
+	}
 
 	if (hdmi->chip_data->lcdsel_grf_reg < 0)
 		return;
@@ -356,6 +432,9 @@ static int dw_hdmi_rockchip_genphy_init(struct dw_hdmi *dw_hdmi, void *data,
 {
 	struct rockchip_hdmi *hdmi = (struct rockchip_hdmi *)data;
 
+	if (hdmi->is_hdmi_qp)
+		dw_hdmi_set_high_tmds_clock_ratio(dw_hdmi, display);
+
 	return phy_power_on(hdmi->phy);
 }
 
@@ -430,6 +509,29 @@ static void dw_hdmi_rk3328_setup_hpd(struct dw_hdmi *dw_hdmi, void *data)
 			      RK3328_HDMI_HPD_IOE));
 }
 
+static enum drm_connector_status
+dw_hdmi_rk3588_read_hpd(struct dw_hdmi *dw_hdmi, void *data)
+{
+	struct rockchip_hdmi *hdmi = (struct rockchip_hdmi *)data;
+	u32 val;
+
+	regmap_read(hdmi->regmap, RK3588_GRF_SOC_STATUS1, &val);
+
+	return val & RK3588_HDMI0_LEVEL_INT ?
+		connector_status_connected : connector_status_disconnected;
+}
+
+static void dw_hdmi_rk3588_setup_hpd(struct dw_hdmi *dw_hdmi, void *data)
+{
+	struct rockchip_hdmi *hdmi = (struct rockchip_hdmi *)data;
+
+	regmap_write(hdmi->regmap,
+		     RK3588_GRF_SOC_CON2,
+		     HIWORD_UPDATE(RK3588_HDMI0_HPD_INT_CLR,
+				   RK3588_HDMI0_HPD_INT_CLR |
+				   RK3588_HDMI0_HPD_INT_MSK));
+}
+
 static const struct dw_hdmi_phy_ops rk3228_hdmi_phy_ops = {
 	.init		= dw_hdmi_rockchip_genphy_init,
 	.disable	= dw_hdmi_rockchip_genphy_disable,
@@ -513,6 +615,82 @@ static const struct dw_hdmi_plat_data rk3568_hdmi_drv_data = {
 	.use_drm_infoframe = true,
 };
 
+static const struct dw_hdmi_phy_ops rk3588_hdmi_phy_ops = {
+	.init		= dw_hdmi_rockchip_genphy_init,
+	.disable	= dw_hdmi_rockchip_genphy_disable,
+	.read_hpd	= dw_hdmi_rk3588_read_hpd,
+	.setup_hpd	= dw_hdmi_rk3588_setup_hpd,
+};
+
+struct rockchip_hdmi_chip_data rk3588_chip_data = {
+	.lcdsel_grf_reg = -1,
+};
+
+static const struct dw_hdmi_plat_data rk3588_hdmi_drv_data = {
+	.phy_data = &rk3588_chip_data,
+	.phy_ops = &rk3588_hdmi_phy_ops,
+	.phy_name = "samsung_hdptx_phy",
+	.phy_force_vendor = true,
+	.use_drm_infoframe = true,
+	.is_hdmi_qp = true,
+};
+
+static void dw_hdmi_rk3588_hpd_work(struct work_struct *p_work)
+{
+	struct rockchip_hdmi *hdmi = container_of(p_work, struct rockchip_hdmi,
+						  qp_hpd_work.work);
+
+	struct drm_device *drm = hdmi->encoder.encoder.dev;
+	bool changed;
+
+	if (drm) {
+		changed = drm_helper_hpd_irq_event(drm);
+		if (changed)
+			drm_dbg(hdmi, "connector status changed\n");
+	}
+}
+
+static irqreturn_t dw_hdmi_rk3588_hardirq(int irq, void *dev_id)
+{
+	struct rockchip_hdmi *hdmi = dev_id;
+	u32 intr_stat, val;
+
+	regmap_read(hdmi->regmap, RK3588_GRF_SOC_STATUS1, &intr_stat);
+
+	if (intr_stat) {
+		val = HIWORD_UPDATE(RK3588_HDMI0_HPD_INT_MSK,
+				    RK3588_HDMI0_HPD_INT_MSK);
+		regmap_write(hdmi->regmap, RK3588_GRF_SOC_CON2, val);
+		return IRQ_WAKE_THREAD;
+	}
+
+	return IRQ_NONE;
+}
+
+static irqreturn_t dw_hdmi_rk3588_irq(int irq, void *dev_id)
+{
+	struct rockchip_hdmi *hdmi = dev_id;
+	u32 intr_stat, val;
+	int debounce_ms;
+
+	regmap_read(hdmi->regmap, RK3588_GRF_SOC_STATUS1, &intr_stat);
+	if (!intr_stat)
+		return IRQ_NONE;
+
+	val = HIWORD_UPDATE(RK3588_HDMI0_HPD_INT_CLR,
+			    RK3588_HDMI0_HPD_INT_CLR);
+	regmap_write(hdmi->regmap, RK3588_GRF_SOC_CON2, val);
+
+	debounce_ms = intr_stat & RK3588_HDMI0_LEVEL_INT ? 150 : 20;
+	mod_delayed_work(system_wq, &hdmi->qp_hpd_work,
+			 msecs_to_jiffies(debounce_ms));
+
+	val |= HIWORD_UPDATE(0, RK3588_HDMI0_HPD_INT_MSK);
+	regmap_write(hdmi->regmap, RK3588_GRF_SOC_CON2, val);
+
+	return IRQ_HANDLED;
+}
+
 static const struct of_device_id dw_hdmi_rockchip_dt_ids[] = {
 	{ .compatible = "rockchip,rk3228-dw-hdmi",
 	  .data = &rk3228_hdmi_drv_data
@@ -529,6 +707,9 @@ static const struct of_device_id dw_hdmi_rockchip_dt_ids[] = {
 	{ .compatible = "rockchip,rk3568-dw-hdmi",
 	  .data = &rk3568_hdmi_drv_data
 	},
+	{ .compatible = "rockchip,rk3588-dw-hdmi",
+	  .data = &rk3588_hdmi_drv_data
+	},
 	{},
 };
 MODULE_DEVICE_TABLE(of, dw_hdmi_rockchip_dt_ids);
@@ -542,7 +723,8 @@ static int dw_hdmi_rockchip_bind(struct device *dev, struct device *master,
 	struct drm_device *drm = data;
 	struct drm_encoder *encoder;
 	struct rockchip_hdmi *hdmi;
-	int ret;
+	int ret, irq;
+	u32 val;
 
 	if (!pdev->dev.of_node)
 		return -ENODEV;
@@ -553,13 +735,14 @@ static int dw_hdmi_rockchip_bind(struct device *dev, struct device *master,
 
 	match = of_match_node(dw_hdmi_rockchip_dt_ids, pdev->dev.of_node);
 	plat_data = devm_kmemdup(&pdev->dev, match->data,
-					     sizeof(*plat_data), GFP_KERNEL);
+				 sizeof(*plat_data), GFP_KERNEL);
 	if (!plat_data)
 		return -ENOMEM;
 
 	hdmi->dev = &pdev->dev;
 	hdmi->plat_data = plat_data;
 	hdmi->chip_data = plat_data->phy_data;
+	hdmi->is_hdmi_qp = plat_data->is_hdmi_qp;
 	plat_data->phy_data = hdmi;
 	plat_data->priv_data = hdmi;
 	encoder = &hdmi->encoder.encoder;
@@ -598,6 +781,37 @@ static int dw_hdmi_rockchip_bind(struct device *dev, struct device *master,
 					   RK3568_HDMI_SCLIN_MSK,
 					   RK3568_HDMI_SDAIN_MSK |
 					   RK3568_HDMI_SCLIN_MSK));
+	} else if (hdmi->is_hdmi_qp) {
+		val = HIWORD_UPDATE(RK3588_SCLIN_MASK, RK3588_SCLIN_MASK) |
+		      HIWORD_UPDATE(RK3588_SDAIN_MASK, RK3588_SDAIN_MASK) |
+		      HIWORD_UPDATE(RK3588_MODE_MASK, RK3588_MODE_MASK) |
+		      HIWORD_UPDATE(RK3588_I2S_SEL_MASK, RK3588_I2S_SEL_MASK);
+		regmap_write(hdmi->vo1_regmap, RK3588_GRF_VO1_CON3, val);
+
+		val = HIWORD_UPDATE(RK3588_SET_HPD_PATH_MASK,
+				    RK3588_SET_HPD_PATH_MASK);
+		regmap_write(hdmi->regmap, RK3588_GRF_SOC_CON7, val);
+
+		val = HIWORD_UPDATE(RK3588_HDMI0_GRANT_SEL,
+				    RK3588_HDMI0_GRANT_SEL);
+		regmap_write(hdmi->vo1_regmap, RK3588_GRF_VO1_CON9, val);
+
+		val = HIWORD_UPDATE(RK3588_HDMI0_HPD_INT_MSK, RK3588_HDMI0_HPD_INT_MSK);
+		regmap_write(hdmi->regmap, RK3588_GRF_SOC_CON2, val);
+
+		INIT_DELAYED_WORK(&hdmi->qp_hpd_work, dw_hdmi_rk3588_hpd_work);
+
+		irq = platform_get_irq(pdev, 4);
+		if (irq < 0)
+			return irq;
+
+		ret = devm_request_threaded_irq(hdmi->dev, irq,
+						dw_hdmi_rk3588_hardirq,
+						dw_hdmi_rk3588_irq,
+						IRQF_SHARED, "dw-hdmi-qp-hpd",
+						hdmi);
+		if (ret)
+			return ret;
 	}
 
 	drm_encoder_helper_add(encoder, &dw_hdmi_rockchip_encoder_helper_funcs);
@@ -605,7 +819,10 @@ static int dw_hdmi_rockchip_bind(struct device *dev, struct device *master,
 
 	platform_set_drvdata(pdev, hdmi);
 
-	hdmi->hdmi = dw_hdmi_bind(pdev, encoder, plat_data);
+	if (hdmi->is_hdmi_qp)
+		hdmi->hdmi = dw_hdmi_qp_bind(pdev, encoder, plat_data);
+	else
+		hdmi->hdmi = dw_hdmi_bind(pdev, encoder, plat_data);
 
 	/*
 	 * If dw_hdmi_bind() fails we'll never call dw_hdmi_unbind(),
@@ -629,7 +846,13 @@ static void dw_hdmi_rockchip_unbind(struct device *dev, struct device *master,
 {
 	struct rockchip_hdmi *hdmi = dev_get_drvdata(dev);
 
-	dw_hdmi_unbind(hdmi->hdmi);
+	if (hdmi->is_hdmi_qp) {
+		cancel_delayed_work_sync(&hdmi->qp_hpd_work);
+		dw_hdmi_qp_unbind(hdmi->hdmi);
+	} else {
+		dw_hdmi_unbind(hdmi->hdmi);
+	}
+
 	drm_encoder_cleanup(&hdmi->encoder.encoder);
 }
 
@@ -651,8 +874,30 @@ static void dw_hdmi_rockchip_remove(struct platform_device *pdev)
 static int __maybe_unused dw_hdmi_rockchip_resume(struct device *dev)
 {
 	struct rockchip_hdmi *hdmi = dev_get_drvdata(dev);
+	u32 val;
+
+	if (hdmi->is_hdmi_qp) {
+		val = HIWORD_UPDATE(RK3588_SCLIN_MASK, RK3588_SCLIN_MASK) |
+		      HIWORD_UPDATE(RK3588_SDAIN_MASK, RK3588_SDAIN_MASK) |
+		      HIWORD_UPDATE(RK3588_MODE_MASK, RK3588_MODE_MASK) |
+		      HIWORD_UPDATE(RK3588_I2S_SEL_MASK, RK3588_I2S_SEL_MASK);
+		regmap_write(hdmi->vo1_regmap, RK3588_GRF_VO1_CON3, val);
 
-	dw_hdmi_resume(hdmi->hdmi);
+		val = HIWORD_UPDATE(RK3588_SET_HPD_PATH_MASK,
+				    RK3588_SET_HPD_PATH_MASK);
+		regmap_write(hdmi->regmap, RK3588_GRF_SOC_CON7, val);
+
+		val = HIWORD_UPDATE(RK3588_HDMI0_GRANT_SEL,
+				    RK3588_HDMI0_GRANT_SEL);
+		regmap_write(hdmi->vo1_regmap, RK3588_GRF_VO1_CON9, val);
+
+		dw_hdmi_qp_resume(dev, hdmi->hdmi);
+
+		if (hdmi->encoder.encoder.dev)
+			drm_helper_hpd_irq_event(hdmi->encoder.encoder.dev);
+	} else {
+		dw_hdmi_resume(hdmi->hdmi);
+	}
 
 	return 0;
 }

-- 
2.45.0


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 13/14] drm/bridge: synopsys: Add DW HDMI QP TX controller driver

[Sam Ravnborg]

Hi Cristian,

a few drive-by comments below.

	Sam


> +
> +static const struct drm_connector_funcs dw_hdmi_qp_connector_funcs = {
> +	.fill_modes = drm_helper_probe_single_connector_modes,
> +	.detect = dw_hdmi_connector_detect,
> +	.destroy = drm_connector_cleanup,
> +	.force = dw_hdmi_qp_connector_force,
> +	.reset = drm_atomic_helper_connector_reset,
> +	.atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
> +	.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
> +};
> +
> +static int dw_hdmi_qp_bridge_attach(struct drm_bridge *bridge,
> +				    enum drm_bridge_attach_flags flags)
> +{
> +	struct dw_hdmi *hdmi = bridge->driver_private;
> +
> +	if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)
> +		return drm_bridge_attach(bridge->encoder, hdmi->next_bridge,
> +					 bridge, flags);
> +
> +	return dw_hdmi_connector_create(hdmi, &dw_hdmi_qp_connector_funcs);
> +}

Are there any users left that requires the display driver to create the
connector?
In other words - could this driver fail if DRM_BRIDGE_ATTACH_NO_CONNECTOR
is not passed and drop dw_hdmi_connector_create()?

I did not try to verify this - just a naive question.

> +
> +static enum drm_mode_status
> +dw_hdmi_qp_bridge_mode_valid(struct drm_bridge *bridge,
> +			     const struct drm_display_info *info,
> +			     const struct drm_display_mode *mode)
> +{
> +	struct dw_hdmi *hdmi = bridge->driver_private;
> +	const struct dw_hdmi_plat_data *pdata = hdmi->plat_data;
> +	enum drm_mode_status mode_status = MODE_OK;
> +
> +	if (pdata->mode_valid)
> +		mode_status = pdata->mode_valid(hdmi, pdata->priv_data, info,
> +						mode);
> +
> +	return mode_status;
> +}
> +
> +static void dw_hdmi_qp_bridge_atomic_disable(struct drm_bridge *bridge,
> +					     struct drm_bridge_state *old_state)
> +{
> +	struct dw_hdmi *hdmi = bridge->driver_private;
> +
> +	mutex_lock(&hdmi->mutex);
> +	hdmi->disabled = true;
> +	hdmi->curr_conn = NULL;
> +	dw_hdmi_qp_update_power(hdmi);
> +	dw_handle_plugged_change(hdmi, false);
> +	mutex_unlock(&hdmi->mutex);
> +}
> +
> +static void dw_hdmi_qp_bridge_atomic_enable(struct drm_bridge *bridge,
> +					    struct drm_bridge_state *old_state)
> +{
> +	struct dw_hdmi *hdmi = bridge->driver_private;
> +	struct drm_atomic_state *state = old_state->base.state;
> +	struct drm_connector *connector;
> +
> +	connector = drm_atomic_get_new_connector_for_encoder(state,
> +							     bridge->encoder);
> +
> +	mutex_lock(&hdmi->mutex);
> +	hdmi->disabled = false;
> +	hdmi->curr_conn = connector;
> +	dw_hdmi_qp_update_power(hdmi);
> +	dw_handle_plugged_change(hdmi, true);
> +	mutex_unlock(&hdmi->mutex);
> +}
> +
> +static const struct drm_bridge_funcs dw_hdmi_qp_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 = dw_hdmi_qp_bridge_attach,
> +	.detach = dw_hdmi_bridge_detach,
> +	.atomic_check = dw_hdmi_bridge_atomic_check,
> +	.atomic_enable = dw_hdmi_qp_bridge_atomic_enable,
> +	.atomic_disable = dw_hdmi_qp_bridge_atomic_disable,
> +	.mode_set = dw_hdmi_bridge_mode_set,

The use of mode_set is deprecated - see drm_bridge.h


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 14/14] drm/rockchip: dw_hdmi: Add basic RK3588 support

[kernel test robot]

Hi Cristian,

kernel test robot noticed the following build errors:

[auto build test ERROR on 1613e604df0cd359cf2a7fbd9be7a0bcfacfabd0]

url:    https://github.com/intel-lab-lkp/linux/commits/Cristian-Ciocaltea/drm-bridge-dw-hdmi-Simplify-clock-handling/20240601-211531
base:   1613e604df0cd359cf2a7fbd9be7a0bcfacfabd0
patch link:    https://lore.kernel.org/r/20240601-b4-rk3588-bridge-upstream-v1-14-f6203753232b%40collabora.com
patch subject: [PATCH 14/14] drm/rockchip: dw_hdmi: Add basic RK3588 support
config: i386-buildonly-randconfig-002-20240601 (https://download.01.org/0day-ci/archive/20240601/202406012207.Yjbj56eg-lkp@intel.com/config)
compiler: gcc-13 (Ubuntu 13.2.0-4ubuntu3) 13.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240601/202406012207.Yjbj56eg-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202406012207.Yjbj56eg-lkp@intel.com/

All errors (new ones prefixed by >>):

   drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c: In function 'rockchip_hdmi_parse_dt':
>> drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c:280:40: error: implicit declaration of function 'devm_gpiod_get_optional'; did you mean 'devm_clk_get_optional'? [-Werror=implicit-function-declaration]
     280 |                 hdmi->qp_enable_gpio = devm_gpiod_get_optional(hdmi->dev, "enable",
         |                                        ^~~~~~~~~~~~~~~~~~~~~~~
         |                                        devm_clk_get_optional
>> drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c:281:64: error: 'GPIOD_OUT_HIGH' undeclared (first use in this function)
     281 |                                                                GPIOD_OUT_HIGH);
         |                                                                ^~~~~~~~~~~~~~
   drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c:281:64: note: each undeclared identifier is reported only once for each function it appears in
   drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c: In function 'dw_hdmi_rockchip_encoder_enable':
>> drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c:364:17: error: implicit declaration of function 'gpiod_set_value' [-Werror=implicit-function-declaration]
     364 |                 gpiod_set_value(hdmi->qp_enable_gpio, 1);
         |                 ^~~~~~~~~~~~~~~
   cc1: some warnings being treated as errors


vim +280 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c

   226	
   227	static int rockchip_hdmi_parse_dt(struct rockchip_hdmi *hdmi)
   228	{
   229		static const char * const qp_clk_names[] = {
   230			"pclk", "hdp", "earc", "aud", "hclk_vo1",
   231		};
   232		struct device_node *np = hdmi->dev->of_node;
   233		struct clk *qp_clk;
   234		int ret, i;
   235	
   236		hdmi->regmap = syscon_regmap_lookup_by_phandle(np, "rockchip,grf");
   237		if (IS_ERR(hdmi->regmap)) {
   238			drm_err(hdmi, "Unable to get rockchip,grf\n");
   239			return PTR_ERR(hdmi->regmap);
   240		}
   241	
   242		hdmi->ref_clk = devm_clk_get_optional_enabled(hdmi->dev, "ref");
   243		if (!hdmi->ref_clk)
   244			hdmi->ref_clk = devm_clk_get_optional_enabled(hdmi->dev, "vpll");
   245	
   246		if (IS_ERR(hdmi->ref_clk)) {
   247			ret = PTR_ERR(hdmi->ref_clk);
   248			if (ret != -EPROBE_DEFER)
   249				drm_err(hdmi, "failed to get reference clock\n");
   250			return ret;
   251		}
   252	
   253		hdmi->grf_clk = devm_clk_get_optional(hdmi->dev, "grf");
   254		if (IS_ERR(hdmi->grf_clk)) {
   255			ret = PTR_ERR(hdmi->grf_clk);
   256			if (ret != -EPROBE_DEFER)
   257				drm_err(hdmi, "failed to get grf clock\n");
   258			return ret;
   259		}
   260	
   261		if (hdmi->is_hdmi_qp) {
   262			hdmi->vo1_regmap = syscon_regmap_lookup_by_phandle(np, "rockchip,vo1_grf");
   263			if (IS_ERR(hdmi->vo1_regmap)) {
   264				drm_err(hdmi, "Unable to get rockchip,vo1_grf\n");
   265				return PTR_ERR(hdmi->vo1_regmap);
   266			}
   267	
   268			for (i = 0; i < ARRAY_SIZE(qp_clk_names); i++) {
   269				qp_clk = devm_clk_get_optional_enabled(hdmi->dev, qp_clk_names[i]);
   270	
   271				if (IS_ERR(qp_clk)) {
   272					ret = PTR_ERR(qp_clk);
   273					if (ret != -EPROBE_DEFER)
   274						drm_err(hdmi, "failed to get %s clock: %d\n",
   275							qp_clk_names[i], ret);
   276					return ret;
   277				}
   278			}
   279	
 > 280			hdmi->qp_enable_gpio = devm_gpiod_get_optional(hdmi->dev, "enable",
 > 281								       GPIOD_OUT_HIGH);
   282			if (IS_ERR(hdmi->qp_enable_gpio)) {
   283				ret = PTR_ERR(hdmi->qp_enable_gpio);
   284				drm_err(hdmi, "failed to request enable GPIO: %d\n", ret);
   285				return ret;
   286			}
   287		}
   288	
   289		ret = devm_regulator_get_enable(hdmi->dev, "avdd-0v9");
   290		if (ret)
   291			return ret;
   292	
   293		ret = devm_regulator_get_enable(hdmi->dev, "avdd-1v8");
   294	
   295		return ret;
   296	}
   297	
   298	static enum drm_mode_status
   299	dw_hdmi_rockchip_mode_valid(struct dw_hdmi *dw_hdmi, void *data,
   300				    const struct drm_display_info *info,
   301				    const struct drm_display_mode *mode)
   302	{
   303		struct rockchip_hdmi *hdmi = data;
   304		const struct dw_hdmi_mpll_config *mpll_cfg = rockchip_mpll_cfg;
   305		int pclk = mode->clock * 1000;
   306		bool exact_match = hdmi->plat_data->phy_force_vendor;
   307		int i;
   308	
   309		if (hdmi->ref_clk) {
   310			int rpclk = clk_round_rate(hdmi->ref_clk, pclk);
   311	
   312			if (abs(rpclk - pclk) > pclk / 1000)
   313				return MODE_NOCLOCK;
   314		}
   315	
   316		for (i = 0; mpll_cfg[i].mpixelclock != (~0UL); i++) {
   317			/*
   318			 * For vendor specific phys force an exact match of the pixelclock
   319			 * to preserve the original behaviour of the driver.
   320			 */
   321			if (exact_match && pclk == mpll_cfg[i].mpixelclock)
   322				return MODE_OK;
   323			/*
   324			 * The Synopsys phy can work with pixelclocks up to the value given
   325			 * in the corresponding mpll_cfg entry.
   326			 */
   327			if (!exact_match && pclk <= mpll_cfg[i].mpixelclock)
   328				return MODE_OK;
   329		}
   330	
   331		return MODE_BAD;
   332	}
   333	
   334	static void dw_hdmi_rockchip_encoder_disable(struct drm_encoder *encoder)
   335	{
   336	}
   337	
   338	static bool
   339	dw_hdmi_rockchip_encoder_mode_fixup(struct drm_encoder *encoder,
   340					    const struct drm_display_mode *mode,
   341					    struct drm_display_mode *adj_mode)
   342	{
   343		return true;
   344	}
   345	
   346	static void dw_hdmi_rockchip_encoder_mode_set(struct drm_encoder *encoder,
   347						      struct drm_display_mode *mode,
   348						      struct drm_display_mode *adj_mode)
   349	{
   350		struct rockchip_hdmi *hdmi = to_rockchip_hdmi(encoder);
   351	
   352		clk_set_rate(hdmi->ref_clk, adj_mode->clock * 1000);
   353	}
   354	
   355	static void dw_hdmi_rockchip_encoder_enable(struct drm_encoder *encoder)
   356	{
   357		struct rockchip_hdmi *hdmi = to_rockchip_hdmi(encoder);
   358		struct drm_crtc *crtc = encoder->crtc;
   359		u32 val;
   360		int ret, rate;
   361	
   362		if (hdmi->is_hdmi_qp) {
   363			/* Unconditionally switch to TMDS as FRL is not yet supported */
 > 364			gpiod_set_value(hdmi->qp_enable_gpio, 1);
   365	
   366			if (crtc && crtc->state) {
   367				clk_set_rate(hdmi->ref_clk,
   368					     crtc->state->adjusted_mode.crtc_clock * 1000);
   369				/*
   370				 * FIXME: Temporary workaround to pass pixel clock rate
   371				 * to the PHY driver until phy_configure_opts_hdmi
   372				 * becomes available in the PHY API. See also the related
   373				 * comment in rk_hdptx_phy_power_on() from
   374				 * drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c
   375				 */
   376				if (hdmi->phy) {
   377					rate = crtc->state->mode.clock * 10;
   378					phy_set_bus_width(hdmi->phy, rate);
   379					drm_dbg(hdmi, "%s set bus_width=%u\n",
   380						__func__, rate);
   381				}
   382			}
   383		}
   384	
   385		if (hdmi->chip_data->lcdsel_grf_reg < 0)
   386			return;
   387	
   388		ret = drm_of_encoder_active_endpoint_id(hdmi->dev->of_node, encoder);
   389		if (ret)
   390			val = hdmi->chip_data->lcdsel_lit;
   391		else
   392			val = hdmi->chip_data->lcdsel_big;
   393	
   394		ret = clk_prepare_enable(hdmi->grf_clk);
   395		if (ret < 0) {
   396			drm_err(hdmi, "failed to enable grfclk %d\n", ret);
   397			return;
   398		}
   399	
   400		ret = regmap_write(hdmi->regmap, hdmi->chip_data->lcdsel_grf_reg, val);
   401		if (ret != 0)
   402			drm_err(hdmi, "Could not write to GRF: %d\n", ret);
   403	
   404		clk_disable_unprepare(hdmi->grf_clk);
   405		drm_dbg(hdmi, "vop %s output to hdmi\n", ret ? "LIT" : "BIG");
   406	}
   407	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 00/14] Add initial support for the Rockchip RK3588 HDMI TX Controller

[Dmitry Baryshkov]

On Sat, Jun 01, 2024 at 04:12:22PM +0300, Cristian Ciocaltea wrote:
> The RK3588 SoC family integrates a Quad-Pixel (QP) variant of the
> Synopsys DesignWare HDMI TX controller used in the previous SoCs.
> 
> It is HDMI 2.1 compliant and supports the following features, among
> others:
> 
> * Fixed Rate Link (FRL)
> * 4K@120Hz and 8K@60Hz video modes
> * Variable Refresh Rate (VRR) including Quick Media Switching (QMS)
> * Fast Vactive (FVA)
> * SCDC I2C DDC access
> * TMDS Scrambler enabling 2160p@60Hz with RGB/YCbCr4:4:4
> * YCbCr4:2:0 enabling 2160p@60Hz at lower HDMI link speeds
> * Multi-stream audio
> * Enhanced Audio Return Channel (EARC)

It would be really nice if you can take a look at using the HDMI
connector framework (landed few days ago) with adaptations for the
drm_bridge / drm_bridge_connector ([1]). Your comments for the
drm_bridge patches would be defeinitely appreciated.

[1] https://lore.kernel.org/dri-devel/20240531-bridge-hdmi-connector-v4-0-5110f7943622@linaro.org/

> 
> This is the last required component that needs to be supported in order
> to enable the HDMI output functionality on the RK3588 based SBCs, such
> as the RADXA Rock 5B. The other components are the Video Output
> Processor (VOP2) and the Samsung IP based HDMI/eDP TX Combo PHY, for
> which basic support has been already made available via [1] and [2],
> respectively.
> 
> The patches are grouped as follows:
> * PATCH 1..7: DW HDMI TX driver refactor to minimize code duplication in
>   the new QP driver (no functional changes intended)
> 
> * PATCH 8..11: Rockchip DW HDMI glue driver cleanup/improvements (no
>   functional changes intended)
> 
> * PATCH 12..13: The new DW HDMI QP TX driver reusing the previously
>   exported functions and structs from existing DW HDMI TX driver
> 
> * PATCH 14: Rockchip DW HDMI glue driver update to support RK3588 and
>   make use of DW HDMI QP TX
> 
> They provide just the basic HDMI support for now, i.e. RGB output up to
> 4K@60Hz, without audio, CEC or any of the HDMI 2.1 specific features.
> Also note the vop2 driver is currently not able to properly handle all
> display modes supported by the connected screens, e.g. it doesn't cope
> with non-integer refresh rates.
> 
> A possible workaround consists of enabling the display controller to
> make use of the clock provided by the HDMI PHY PLL. This is still work
> in progress and will be submitted later, as well as the required DTS
> updates.
> 
> To facilitate testing and experimentation, all HDMI output related
> patches, including those part of this series, are available at [3].
> So far I could only verify this on the RADXA Rock 3A and 5B boards.
> 
> Thanks,
> Cristian
> 
> [1]: 5a028e8f062f ("drm/rockchip: vop2: Add support for rk3588")
> [2]: 553be2830c5f ("phy: rockchip: Add Samsung HDMI/eDP Combo PHY driver")
> [3]: https://gitlab.collabora.com/hardware-enablement/rockchip-3588/linux/-/commits/rk3588-hdmi-bridge-v6.10-rc1
> 
> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
> ---
> Cristian Ciocaltea (14):
>       drm/bridge: dw-hdmi: Simplify clock handling
>       drm/bridge: dw-hdmi: Add dw-hdmi-common.h header
>       drm/bridge: dw-hdmi: Commonize dw_hdmi_i2c_adapter()
>       drm/bridge: dw-hdmi: Factor out AVI infoframe setup
>       drm/bridge: dw-hdmi: Factor out vmode setup
>       drm/bridge: dw-hdmi: Factor out hdmi_data_info setup
>       drm/bridge: dw-hdmi: Commonize dw_hdmi_connector_create()
>       drm/rockchip: dw_hdmi: Use modern drm_device based logging
>       drm/rockchip: dw_hdmi: Simplify clock handling
>       drm/rockchip: dw_hdmi: Use devm_regulator_get_enable()
>       drm/rockchip: dw_hdmi: Drop superfluous assignments of mpll_cfg, cur_ctr and phy_config
>       dt-bindings: display: rockchip,dw-hdmi: Add compatible for RK3588
>       drm/bridge: synopsys: Add DW HDMI QP TX controller driver
>       drm/rockchip: dw_hdmi: Add basic RK3588 support
> 
>  .../display/rockchip/rockchip,dw-hdmi.yaml         | 127 +++-
>  drivers/gpu/drm/bridge/synopsys/Makefile           |   2 +-
>  drivers/gpu/drm/bridge/synopsys/dw-hdmi-common.h   | 179 +++++
>  drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c       | 787 +++++++++++++++++++
>  drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.h       | 831 +++++++++++++++++++++
>  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c          | 353 +++------
>  drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c        | 351 +++++++--
>  include/drm/bridge/dw_hdmi.h                       |   8 +
>  8 files changed, 2290 insertions(+), 348 deletions(-)
> ---
> base-commit: 1613e604df0cd359cf2a7fbd9be7a0bcfacfabd0
> change-id: 20240601-b4-rk3588-bridge-upstream-a27baff1b8fc
> 

-- 
With best wishes
Dmitry

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 14/14] drm/rockchip: dw_hdmi: Add basic RK3588 support

[kernel test robot]

Hi Cristian,

kernel test robot noticed the following build errors:

[auto build test ERROR on 1613e604df0cd359cf2a7fbd9be7a0bcfacfabd0]

url:    https://github.com/intel-lab-lkp/linux/commits/Cristian-Ciocaltea/drm-bridge-dw-hdmi-Simplify-clock-handling/20240601-211531
base:   1613e604df0cd359cf2a7fbd9be7a0bcfacfabd0
patch link:    https://lore.kernel.org/r/20240601-b4-rk3588-bridge-upstream-v1-14-f6203753232b%40collabora.com
patch subject: [PATCH 14/14] drm/rockchip: dw_hdmi: Add basic RK3588 support
config: arm-defconfig (https://download.01.org/0day-ci/archive/20240602/202406020122.7LHytbS3-lkp@intel.com/config)
compiler: clang version 14.0.6 (https://github.com/llvm/llvm-project f28c006a5895fc0e329fe15fead81e37457cb1d1)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240602/202406020122.7LHytbS3-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202406020122.7LHytbS3-lkp@intel.com/

All errors (new ones prefixed by >>):

>> drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c:280:26: error: implicit declaration of function 'devm_gpiod_get_optional' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
                   hdmi->qp_enable_gpio = devm_gpiod_get_optional(hdmi->dev, "enable",
                                          ^
   drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c:280:26: note: did you mean 'devm_clk_get_optional'?
   include/linux/clk.h:597:13: note: 'devm_clk_get_optional' declared here
   struct clk *devm_clk_get_optional(struct device *dev, const char *id);
               ^
>> drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c:281:15: error: use of undeclared identifier 'GPIOD_OUT_HIGH'
                                                                  GPIOD_OUT_HIGH);
                                                                  ^
>> drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c:364:3: error: implicit declaration of function 'gpiod_set_value' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
                   gpiod_set_value(hdmi->qp_enable_gpio, 1);
                   ^
   3 errors generated.


vim +/devm_gpiod_get_optional +280 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c

   226	
   227	static int rockchip_hdmi_parse_dt(struct rockchip_hdmi *hdmi)
   228	{
   229		static const char * const qp_clk_names[] = {
   230			"pclk", "hdp", "earc", "aud", "hclk_vo1",
   231		};
   232		struct device_node *np = hdmi->dev->of_node;
   233		struct clk *qp_clk;
   234		int ret, i;
   235	
   236		hdmi->regmap = syscon_regmap_lookup_by_phandle(np, "rockchip,grf");
   237		if (IS_ERR(hdmi->regmap)) {
   238			drm_err(hdmi, "Unable to get rockchip,grf\n");
   239			return PTR_ERR(hdmi->regmap);
   240		}
   241	
   242		hdmi->ref_clk = devm_clk_get_optional_enabled(hdmi->dev, "ref");
   243		if (!hdmi->ref_clk)
   244			hdmi->ref_clk = devm_clk_get_optional_enabled(hdmi->dev, "vpll");
   245	
   246		if (IS_ERR(hdmi->ref_clk)) {
   247			ret = PTR_ERR(hdmi->ref_clk);
   248			if (ret != -EPROBE_DEFER)
   249				drm_err(hdmi, "failed to get reference clock\n");
   250			return ret;
   251		}
   252	
   253		hdmi->grf_clk = devm_clk_get_optional(hdmi->dev, "grf");
   254		if (IS_ERR(hdmi->grf_clk)) {
   255			ret = PTR_ERR(hdmi->grf_clk);
   256			if (ret != -EPROBE_DEFER)
   257				drm_err(hdmi, "failed to get grf clock\n");
   258			return ret;
   259		}
   260	
   261		if (hdmi->is_hdmi_qp) {
   262			hdmi->vo1_regmap = syscon_regmap_lookup_by_phandle(np, "rockchip,vo1_grf");
   263			if (IS_ERR(hdmi->vo1_regmap)) {
   264				drm_err(hdmi, "Unable to get rockchip,vo1_grf\n");
   265				return PTR_ERR(hdmi->vo1_regmap);
   266			}
   267	
   268			for (i = 0; i < ARRAY_SIZE(qp_clk_names); i++) {
   269				qp_clk = devm_clk_get_optional_enabled(hdmi->dev, qp_clk_names[i]);
   270	
   271				if (IS_ERR(qp_clk)) {
   272					ret = PTR_ERR(qp_clk);
   273					if (ret != -EPROBE_DEFER)
   274						drm_err(hdmi, "failed to get %s clock: %d\n",
   275							qp_clk_names[i], ret);
   276					return ret;
   277				}
   278			}
   279	
 > 280			hdmi->qp_enable_gpio = devm_gpiod_get_optional(hdmi->dev, "enable",
 > 281								       GPIOD_OUT_HIGH);
   282			if (IS_ERR(hdmi->qp_enable_gpio)) {
   283				ret = PTR_ERR(hdmi->qp_enable_gpio);
   284				drm_err(hdmi, "failed to request enable GPIO: %d\n", ret);
   285				return ret;
   286			}
   287		}
   288	
   289		ret = devm_regulator_get_enable(hdmi->dev, "avdd-0v9");
   290		if (ret)
   291			return ret;
   292	
   293		ret = devm_regulator_get_enable(hdmi->dev, "avdd-1v8");
   294	
   295		return ret;
   296	}
   297	
   298	static enum drm_mode_status
   299	dw_hdmi_rockchip_mode_valid(struct dw_hdmi *dw_hdmi, void *data,
   300				    const struct drm_display_info *info,
   301				    const struct drm_display_mode *mode)
   302	{
   303		struct rockchip_hdmi *hdmi = data;
   304		const struct dw_hdmi_mpll_config *mpll_cfg = rockchip_mpll_cfg;
   305		int pclk = mode->clock * 1000;
   306		bool exact_match = hdmi->plat_data->phy_force_vendor;
   307		int i;
   308	
   309		if (hdmi->ref_clk) {
   310			int rpclk = clk_round_rate(hdmi->ref_clk, pclk);
   311	
   312			if (abs(rpclk - pclk) > pclk / 1000)
   313				return MODE_NOCLOCK;
   314		}
   315	
   316		for (i = 0; mpll_cfg[i].mpixelclock != (~0UL); i++) {
   317			/*
   318			 * For vendor specific phys force an exact match of the pixelclock
   319			 * to preserve the original behaviour of the driver.
   320			 */
   321			if (exact_match && pclk == mpll_cfg[i].mpixelclock)
   322				return MODE_OK;
   323			/*
   324			 * The Synopsys phy can work with pixelclocks up to the value given
   325			 * in the corresponding mpll_cfg entry.
   326			 */
   327			if (!exact_match && pclk <= mpll_cfg[i].mpixelclock)
   328				return MODE_OK;
   329		}
   330	
   331		return MODE_BAD;
   332	}
   333	
   334	static void dw_hdmi_rockchip_encoder_disable(struct drm_encoder *encoder)
   335	{
   336	}
   337	
   338	static bool
   339	dw_hdmi_rockchip_encoder_mode_fixup(struct drm_encoder *encoder,
   340					    const struct drm_display_mode *mode,
   341					    struct drm_display_mode *adj_mode)
   342	{
   343		return true;
   344	}
   345	
   346	static void dw_hdmi_rockchip_encoder_mode_set(struct drm_encoder *encoder,
   347						      struct drm_display_mode *mode,
   348						      struct drm_display_mode *adj_mode)
   349	{
   350		struct rockchip_hdmi *hdmi = to_rockchip_hdmi(encoder);
   351	
   352		clk_set_rate(hdmi->ref_clk, adj_mode->clock * 1000);
   353	}
   354	
   355	static void dw_hdmi_rockchip_encoder_enable(struct drm_encoder *encoder)
   356	{
   357		struct rockchip_hdmi *hdmi = to_rockchip_hdmi(encoder);
   358		struct drm_crtc *crtc = encoder->crtc;
   359		u32 val;
   360		int ret, rate;
   361	
   362		if (hdmi->is_hdmi_qp) {
   363			/* Unconditionally switch to TMDS as FRL is not yet supported */
 > 364			gpiod_set_value(hdmi->qp_enable_gpio, 1);
   365	
   366			if (crtc && crtc->state) {
   367				clk_set_rate(hdmi->ref_clk,
   368					     crtc->state->adjusted_mode.crtc_clock * 1000);
   369				/*
   370				 * FIXME: Temporary workaround to pass pixel clock rate
   371				 * to the PHY driver until phy_configure_opts_hdmi
   372				 * becomes available in the PHY API. See also the related
   373				 * comment in rk_hdptx_phy_power_on() from
   374				 * drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c
   375				 */
   376				if (hdmi->phy) {
   377					rate = crtc->state->mode.clock * 10;
   378					phy_set_bus_width(hdmi->phy, rate);
   379					drm_dbg(hdmi, "%s set bus_width=%u\n",
   380						__func__, rate);
   381				}
   382			}
   383		}
   384	
   385		if (hdmi->chip_data->lcdsel_grf_reg < 0)
   386			return;
   387	
   388		ret = drm_of_encoder_active_endpoint_id(hdmi->dev->of_node, encoder);
   389		if (ret)
   390			val = hdmi->chip_data->lcdsel_lit;
   391		else
   392			val = hdmi->chip_data->lcdsel_big;
   393	
   394		ret = clk_prepare_enable(hdmi->grf_clk);
   395		if (ret < 0) {
   396			drm_err(hdmi, "failed to enable grfclk %d\n", ret);
   397			return;
   398		}
   399	
   400		ret = regmap_write(hdmi->regmap, hdmi->chip_data->lcdsel_grf_reg, val);
   401		if (ret != 0)
   402			drm_err(hdmi, "Could not write to GRF: %d\n", ret);
   403	
   404		clk_disable_unprepare(hdmi->grf_clk);
   405		drm_dbg(hdmi, "vop %s output to hdmi\n", ret ? "LIT" : "BIG");
   406	}
   407	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 00/14] Add initial support for the Rockchip RK3588 HDMI TX Controller

[Piotr Oniszczuk]

(resent as plain text instead of html)
 
Cristian,

I was awaiting over year for this work!

I’m devel. 2 distros where single mainline kernel serves 2835/2711/2712/h6/h313/h616/h618/rk3328/rk3399/rk3566/rk3568/rk3588/s905/s912/sm1/g12.

Before this work rk3588 was excluded because rk3588 hdmi was regressing hdmi on other socs.
With this code all other socs seems work ok now. Perfect.

As one of my project is multimedia appliance - good news is that now i can nicely play hdtv on rk3588 using mainline common 6.9.3 kernel and….started to hear from my users a lot of Qs like: „ah so nice! rk3588 now works nicely….but where is hdmi audio and cec?”

It will be fantastic to add (e.g. by backport Detlev https://gitlab.collabora.com/hardware-enablement/rockchip-3588/linux/-/tree/rk3588-hdmi-audio?ref_type=heads ) audio code to get basic support hdmi audio?
   
thx again for fantastic work!

> Wiadomość napisana przez Cristian Ciocaltea <cristian.ciocaltea@collabora.com> w dniu 01.06.2024, o godz. 15:12:
> 
> The RK3588 SoC family integrates a Quad-Pixel (QP) variant of the
> Synopsys DesignWare HDMI TX controller used in the previous SoCs.
> 
> It is HDMI 2.1 compliant and supports the following features, among
> others:
> 
> * Fixed Rate Link (FRL)
> * 4K@120Hz and 8K@60Hz video modes
> * Variable Refresh Rate (VRR) including Quick Media Switching (QMS)
> * Fast Vactive (FVA)
> * SCDC I2C DDC access
> * TMDS Scrambler enabling 2160p@60Hz with RGB/YCbCr4:4:4
> * YCbCr4:2:0 enabling 2160p@60Hz at lower HDMI link speeds
> * Multi-stream audio
> * Enhanced Audio Return Channel (EARC)
> 
> This is the last required component that needs to be supported in order
> to enable the HDMI output functionality on the RK3588 based SBCs, such
> as the RADXA Rock 5B. The other components are the Video Output
> Processor (VOP2) and the Samsung IP based HDMI/eDP TX Combo PHY, for
> which basic support has been already made available via [1] and [2],
> respectively.
> 
> The patches are grouped as follows:
> * PATCH 1..7: DW HDMI TX driver refactor to minimize code duplication in
>  the new QP driver (no functional changes intended)
> 
> * PATCH 8..11: Rockchip DW HDMI glue driver cleanup/improvements (no
>  functional changes intended)
> 
> * PATCH 12..13: The new DW HDMI QP TX driver reusing the previously
>  exported functions and structs from existing DW HDMI TX driver
> 
> * PATCH 14: Rockchip DW HDMI glue driver update to support RK3588 and
>  make use of DW HDMI QP TX
> 
> They provide just the basic HDMI support for now, i.e. RGB output up to
> 4K@60Hz, without audio, CEC or any of the HDMI 2.1 specific features.
> Also note the vop2 driver is currently not able to properly handle all
> display modes supported by the connected screens, e.g. it doesn't cope
> with non-integer refresh rates.
> 
> A possible workaround consists of enabling the display controller to
> make use of the clock provided by the HDMI PHY PLL. This is still work
> in progress and will be submitted later, as well as the required DTS
> updates.
> 
> To facilitate testing and experimentation, all HDMI output related
> patches, including those part of this series, are available at [3].
> So far I could only verify this on the RADXA Rock 3A and 5B boards.
> 
> Thanks,
> Cristian
> 
> [1]: 5a028e8f062f ("drm/rockchip: vop2: Add support for rk3588")
> [2]: 553be2830c5f ("phy: rockchip: Add Samsung HDMI/eDP Combo PHY driver")
> [3]: https://gitlab.collabora.com/hardware-enablement/rockchip-3588/linux/-/commits/rk3588-hdmi-bridge-v6.10-rc1
> 
> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
> ---
> Cristian Ciocaltea (14):
>      drm/bridge: dw-hdmi: Simplify clock handling
>      drm/bridge: dw-hdmi: Add dw-hdmi-common.h header
>      drm/bridge: dw-hdmi: Commonize dw_hdmi_i2c_adapter()
>      drm/bridge: dw-hdmi: Factor out AVI infoframe setup
>      drm/bridge: dw-hdmi: Factor out vmode setup
>      drm/bridge: dw-hdmi: Factor out hdmi_data_info setup
>      drm/bridge: dw-hdmi: Commonize dw_hdmi_connector_create()
>      drm/rockchip: dw_hdmi: Use modern drm_device based logging
>      drm/rockchip: dw_hdmi: Simplify clock handling
>      drm/rockchip: dw_hdmi: Use devm_regulator_get_enable()
>      drm/rockchip: dw_hdmi: Drop superfluous assignments of mpll_cfg, cur_ctr and phy_config
>      dt-bindings: display: rockchip,dw-hdmi: Add compatible for RK3588
>      drm/bridge: synopsys: Add DW HDMI QP TX controller driver
>      drm/rockchip: dw_hdmi: Add basic RK3588 support
> 
> .../display/rockchip/rockchip,dw-hdmi.yaml         | 127 +++-
> drivers/gpu/drm/bridge/synopsys/Makefile           |   2 +-
> drivers/gpu/drm/bridge/synopsys/dw-hdmi-common.h   | 179 +++++
> drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c       | 787 +++++++++++++++++++
> drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.h       | 831 +++++++++++++++++++++
> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c          | 353 +++------
> drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c        | 351 +++++++--
> include/drm/bridge/dw_hdmi.h                       |   8 +
> 8 files changed, 2290 insertions(+), 348 deletions(-)
> ---
> base-commit: 1613e604df0cd359cf2a7fbd9be7a0bcfacfabd0
> change-id: 20240601-b4-rk3588-bridge-upstream-a27baff1b8fc
> 
> 
> _______________________________________________
> Linux-rockchip mailing list
> Linux-rockchip@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 00/14] Add initial support for the Rockchip RK3588 HDMI TX Controller

[Neil Armstrong]

Hi Christian,

On 01/06/2024 15:12, Cristian Ciocaltea wrote:
> The RK3588 SoC family integrates a Quad-Pixel (QP) variant of the
> Synopsys DesignWare HDMI TX controller used in the previous SoCs.
> 
> It is HDMI 2.1 compliant and supports the following features, among
> others:
> 
.

..

> * SCDC I2C DDC access
> * TMDS Scrambler enabling 2160p@60Hz with RGB/YCbCr4:4:4
> * YCbCr4:2:0 enabling 2160p@60Hz at lower HDMI link speeds
> * Multi-stream audio
> * Enhanced Audio Return Channel (EARC)
-> Those features were already supported by the HDMI 2.0a compliant HW, just
list the _new_ features for HDMI 2.1

I did a quick review of your patchset and I don't understand why you need
to add a separate dw-hdmi-qp.c since you only need simple variants of the I2C
bus, infoframe and bridge setup.

Can you elaborate further ? isn't this Quad-Pixel (QP) TX controller version
detectable at runtime ?

I would prefer to keep a single dw-hdmi driver if possible.

Thanks,
Neil

> 
> This is the last required component that needs to be supported in order
> to enable the HDMI output functionality on the RK3588 based SBCs, such
> as the RADXA Rock 5B. The other components are the Video Output
> Processor (VOP2) and the Samsung IP based HDMI/eDP TX Combo PHY, for
> which basic support has been already made available via [1] and [2],
> respectively.
> 
> The patches are grouped as follows:
> * PATCH 1..7: DW HDMI TX driver refactor to minimize code duplication in
>    the new QP driver (no functional changes intended)
> 
> * PATCH 8..11: Rockchip DW HDMI glue driver cleanup/improvements (no
>    functional changes intended)
> 
> * PATCH 12..13: The new DW HDMI QP TX driver reusing the previously
>    exported functions and structs from existing DW HDMI TX driver
> 
> * PATCH 14: Rockchip DW HDMI glue driver update to support RK3588 and
>    make use of DW HDMI QP TX
> 
> They provide just the basic HDMI support for now, i.e. RGB output up to
> 4K@60Hz, without audio, CEC or any of the HDMI 2.1 specific features.
> Also note the vop2 driver is currently not able to properly handle all
> display modes supported by the connected screens, e.g. it doesn't cope
> with non-integer refresh rates.
> 
> A possible workaround consists of enabling the display controller to
> make use of the clock provided by the HDMI PHY PLL. This is still work
> in progress and will be submitted later, as well as the required DTS
> updates.
> 
> To facilitate testing and experimentation, all HDMI output related
> patches, including those part of this series, are available at [3].
> So far I could only verify this on the RADXA Rock 3A and 5B boards.
> 
> Thanks,
> Cristian
> 
> [1]: 5a028e8f062f ("drm/rockchip: vop2: Add support for rk3588")
> [2]: 553be2830c5f ("phy: rockchip: Add Samsung HDMI/eDP Combo PHY driver")
> [3]: https://gitlab.collabora.com/hardware-enablement/rockchip-3588/linux/-/commits/rk3588-hdmi-bridge-v6.10-rc1
> 
> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
> ---
> Cristian Ciocaltea (14):
>        drm/bridge: dw-hdmi: Simplify clock handling
>        drm/bridge: dw-hdmi: Add dw-hdmi-common.h header
>        drm/bridge: dw-hdmi: Commonize dw_hdmi_i2c_adapter()
>        drm/bridge: dw-hdmi: Factor out AVI infoframe setup
>        drm/bridge: dw-hdmi: Factor out vmode setup
>        drm/bridge: dw-hdmi: Factor out hdmi_data_info setup
>        drm/bridge: dw-hdmi: Commonize dw_hdmi_connector_create()
>        drm/rockchip: dw_hdmi: Use modern drm_device based logging
>        drm/rockchip: dw_hdmi: Simplify clock handling
>        drm/rockchip: dw_hdmi: Use devm_regulator_get_enable()
>        drm/rockchip: dw_hdmi: Drop superfluous assignments of mpll_cfg, cur_ctr and phy_config
>        dt-bindings: display: rockchip,dw-hdmi: Add compatible for RK3588
>        drm/bridge: synopsys: Add DW HDMI QP TX controller driver
>        drm/rockchip: dw_hdmi: Add basic RK3588 support
> 
>   .../display/rockchip/rockchip,dw-hdmi.yaml         | 127 +++-
>   drivers/gpu/drm/bridge/synopsys/Makefile           |   2 +-
>   drivers/gpu/drm/bridge/synopsys/dw-hdmi-common.h   | 179 +++++
>   drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c       | 787 +++++++++++++++++++
>   drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.h       | 831 +++++++++++++++++++++
>   drivers/gpu/drm/bridge/synopsys/dw-hdmi.c          | 353 +++------
>   drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c        | 351 +++++++--
>   include/drm/bridge/dw_hdmi.h                       |   8 +
>   8 files changed, 2290 insertions(+), 348 deletions(-)
> ---
> base-commit: 1613e604df0cd359cf2a7fbd9be7a0bcfacfabd0
> change-id: 20240601-b4-rk3588-bridge-upstream-a27baff1b8fc
> 


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 00/14] Add initial support for the Rockchip RK3588 HDMI TX Controller

[Andy Yan]

Hi Neil:

On 6/3/24 16:55, Neil Armstrong wrote:
> Hi Christian,
> 
> On 01/06/2024 15:12, Cristian Ciocaltea wrote:
>> The RK3588 SoC family integrates a Quad-Pixel (QP) variant of the
>> Synopsys DesignWare HDMI TX controller used in the previous SoCs.
>>
>> It is HDMI 2.1 compliant and supports the following features, among
>> others:
>>
> .
> 
> ..
> 
>> * SCDC I2C DDC access
>> * TMDS Scrambler enabling 2160p@60Hz with RGB/YCbCr4:4:4
>> * YCbCr4:2:0 enabling 2160p@60Hz at lower HDMI link speeds
>> * Multi-stream audio
>> * Enhanced Audio Return Channel (EARC)
> -> Those features were already supported by the HDMI 2.0a compliant HW, just
> list the _new_ features for HDMI 2.1
> 
> I did a quick review of your patchset and I don't understand why you need
> to add a separate dw-hdmi-qp.c since you only need simple variants of the I2C
> bus, infoframe and bridge setup.
> 
> Can you elaborate further ? isn't this Quad-Pixel (QP) TX controller version
> detectable at runtime ?
> 
> I would prefer to keep a single dw-hdmi driver if possible.



The QP HDMI controller is a completely different variant with totally different
registers layout, see PATCH 13/14.
I think make it a separate driver will be easier for development and maintenance.
> 
> Thanks,
> Neil
> 
>>
>> This is the last required component that needs to be supported in order
>> to enable the HDMI output functionality on the RK3588 based SBCs, such
>> as the RADXA Rock 5B. The other components are the Video Output
>> Processor (VOP2) and the Samsung IP based HDMI/eDP TX Combo PHY, for
>> which basic support has been already made available via [1] and [2],
>> respectively.
>>
>> The patches are grouped as follows:
>> * PATCH 1..7: DW HDMI TX driver refactor to minimize code duplication in
>>    the new QP driver (no functional changes intended)
>>
>> * PATCH 8..11: Rockchip DW HDMI glue driver cleanup/improvements (no
>>    functional changes intended)
>>
>> * PATCH 12..13: The new DW HDMI QP TX driver reusing the previously
>>    exported functions and structs from existing DW HDMI TX driver
>>
>> * PATCH 14: Rockchip DW HDMI glue driver update to support RK3588 and
>>    make use of DW HDMI QP TX
>>
>> They provide just the basic HDMI support for now, i.e. RGB output up to
>> 4K@60Hz, without audio, CEC or any of the HDMI 2.1 specific features.
>> Also note the vop2 driver is currently not able to properly handle all
>> display modes supported by the connected screens, e.g. it doesn't cope
>> with non-integer refresh rates.
>>
>> A possible workaround consists of enabling the display controller to
>> make use of the clock provided by the HDMI PHY PLL. This is still work
>> in progress and will be submitted later, as well as the required DTS
>> updates.
>>
>> To facilitate testing and experimentation, all HDMI output related
>> patches, including those part of this series, are available at [3].
>> So far I could only verify this on the RADXA Rock 3A and 5B boards.
>>
>> Thanks,
>> Cristian
>>
>> [1]: 5a028e8f062f ("drm/rockchip: vop2: Add support for rk3588")
>> [2]: 553be2830c5f ("phy: rockchip: Add Samsung HDMI/eDP Combo PHY driver")
>> [3]: https://gitlab.collabora.com/hardware-enablement/rockchip-3588/linux/-/commits/rk3588-hdmi-bridge-v6.10-rc1
>>
>> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
>> ---
>> Cristian Ciocaltea (14):
>>        drm/bridge: dw-hdmi: Simplify clock handling
>>        drm/bridge: dw-hdmi: Add dw-hdmi-common.h header
>>        drm/bridge: dw-hdmi: Commonize dw_hdmi_i2c_adapter()
>>        drm/bridge: dw-hdmi: Factor out AVI infoframe setup
>>        drm/bridge: dw-hdmi: Factor out vmode setup
>>        drm/bridge: dw-hdmi: Factor out hdmi_data_info setup
>>        drm/bridge: dw-hdmi: Commonize dw_hdmi_connector_create()
>>        drm/rockchip: dw_hdmi: Use modern drm_device based logging
>>        drm/rockchip: dw_hdmi: Simplify clock handling
>>        drm/rockchip: dw_hdmi: Use devm_regulator_get_enable()
>>        drm/rockchip: dw_hdmi: Drop superfluous assignments of mpll_cfg, cur_ctr and phy_config
>>        dt-bindings: display: rockchip,dw-hdmi: Add compatible for RK3588
>>        drm/bridge: synopsys: Add DW HDMI QP TX controller driver
>>        drm/rockchip: dw_hdmi: Add basic RK3588 support
>>
>>   .../display/rockchip/rockchip,dw-hdmi.yaml         | 127 +++-
>>   drivers/gpu/drm/bridge/synopsys/Makefile           |   2 +-
>>   drivers/gpu/drm/bridge/synopsys/dw-hdmi-common.h   | 179 +++++
>>   drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c       | 787 +++++++++++++++++++
>>   drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.h       | 831 +++++++++++++++++++++
>>   drivers/gpu/drm/bridge/synopsys/dw-hdmi.c          | 353 +++------
>>   drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c        | 351 +++++++--
>>   include/drm/bridge/dw_hdmi.h                       |   8 +
>>   8 files changed, 2290 insertions(+), 348 deletions(-)
>> ---
>> base-commit: 1613e604df0cd359cf2a7fbd9be7a0bcfacfabd0
>> change-id: 20240601-b4-rk3588-bridge-upstream-a27baff1b8fc
>>
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 00/14] Add initial support for the Rockchip RK3588 HDMI TX Controller

[Heiko Stuebner]

Am Montag, 3. Juni 2024, 14:14:17 CEST schrieb Andy Yan:
> Hi Neil:
> 
> On 6/3/24 16:55, Neil Armstrong wrote:
> > Hi Christian,
> > 
> > On 01/06/2024 15:12, Cristian Ciocaltea wrote:
> >> The RK3588 SoC family integrates a Quad-Pixel (QP) variant of the
> >> Synopsys DesignWare HDMI TX controller used in the previous SoCs.
> >>
> >> It is HDMI 2.1 compliant and supports the following features, among
> >> others:
> >>
> > .
> > 
> > ..
> > 
> >> * SCDC I2C DDC access
> >> * TMDS Scrambler enabling 2160p@60Hz with RGB/YCbCr4:4:4
> >> * YCbCr4:2:0 enabling 2160p@60Hz at lower HDMI link speeds
> >> * Multi-stream audio
> >> * Enhanced Audio Return Channel (EARC)
> > -> Those features were already supported by the HDMI 2.0a compliant HW, just
> > list the _new_ features for HDMI 2.1
> > 
> > I did a quick review of your patchset and I don't understand why you need
> > to add a separate dw-hdmi-qp.c since you only need simple variants of the I2C
> > bus, infoframe and bridge setup.
> > 
> > Can you elaborate further ? isn't this Quad-Pixel (QP) TX controller version
> > detectable at runtime ?
> > 
> > I would prefer to keep a single dw-hdmi driver if possible.
> 
> 
> 
> The QP HDMI controller is a completely different variant with totally different
> registers layout, see PATCH 13/14.
> I think make it a separate driver will be easier for development and maintenance.

I'm with Andy here. Trying to navigate a driver for two IP blocks really
sounds taxing especially when both are so different.

Synopsis also created a new dsi controller for the DSI2 standard, with
a vastly different registers layout.

I guess at some point there is time to say this really is a new IP ;-) .


Though while on that thought, I don't fully understand why both a compiled
under the dw_hdmi kconfig symbol. People going for a minimal kernel might
want one or the other, but not both for their specific board.


Heiko



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 00/14] Add initial support for the Rockchip RK3588 HDMI TX Controller

[neil.armstrong]

Hi,

On 03/06/2024 15:03, Heiko Stuebner wrote:
> Am Montag, 3. Juni 2024, 14:14:17 CEST schrieb Andy Yan:
>> Hi Neil:
>>
>> On 6/3/24 16:55, Neil Armstrong wrote:
>>> Hi Christian,
>>>
>>> On 01/06/2024 15:12, Cristian Ciocaltea wrote:
>>>> The RK3588 SoC family integrates a Quad-Pixel (QP) variant of the
>>>> Synopsys DesignWare HDMI TX controller used in the previous SoCs.
>>>>
>>>> It is HDMI 2.1 compliant and supports the following features, among
>>>> others:
>>>>
>>> .
>>>
>>> ..
>>>
>>>> * SCDC I2C DDC access
>>>> * TMDS Scrambler enabling 2160p@60Hz with RGB/YCbCr4:4:4
>>>> * YCbCr4:2:0 enabling 2160p@60Hz at lower HDMI link speeds
>>>> * Multi-stream audio
>>>> * Enhanced Audio Return Channel (EARC)
>>> -> Those features were already supported by the HDMI 2.0a compliant HW, just
>>> list the _new_ features for HDMI 2.1
>>>
>>> I did a quick review of your patchset and I don't understand why you need
>>> to add a separate dw-hdmi-qp.c since you only need simple variants of the I2C
>>> bus, infoframe and bridge setup.
>>>
>>> Can you elaborate further ? isn't this Quad-Pixel (QP) TX controller version
>>> detectable at runtime ?
>>>
>>> I would prefer to keep a single dw-hdmi driver if possible.
>>
>>
>>
>> The QP HDMI controller is a completely different variant with totally different
>> registers layout, see PATCH 13/14.
>> I think make it a separate driver will be easier for development and maintenance.
> 
> I'm with Andy here. Trying to navigate a driver for two IP blocks really
> sounds taxing especially when both are so different.

I agree, I just wanted more details than "variant of the
Synopsys DesignWare HDMI TX controller", if the register mapping is 100%
different, and does not match at all with the old IP, then it's indeed time
to make a brand new driver, but instead of doing a mix up, it's time to extract
the dw-hdmi code that could be common helpers into a dw-hdmi-common module
and use them.

As I see, no "driver" code can be shared, only DRM plumbings, so perhaps those
plumbing code should go into the DRM core ?

In any case, please add more details on the cover letter, including the detailed
HW differrence and the design you chose so support this new IP.

Neil

> 
> Synopsis also created a new dsi controller for the DSI2 standard, with
> a vastly different registers layout.
> 
> I guess at some point there is time to say this really is a new IP ;-) .
> 
> 
> Though while on that thought, I don't fully understand why both a compiled
> under the dw_hdmi kconfig symbol. People going for a minimal kernel might
> want one or the other, but not both for their specific board.
> 
> 
> Heiko
> 
> 


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 00/14] Add initial support for the Rockchip RK3588 HDMI TX Controller

[Maxime Ripard]

[-- Attachment #1.1: Type: text/plain, Size: 1834 bytes --]

On Mon, Jun 03, 2024 at 03:03:12PM GMT, Heiko Stuebner wrote:
> Am Montag, 3. Juni 2024, 14:14:17 CEST schrieb Andy Yan:
> > Hi Neil:
> > 
> > On 6/3/24 16:55, Neil Armstrong wrote:
> > > Hi Christian,
> > > 
> > > On 01/06/2024 15:12, Cristian Ciocaltea wrote:
> > >> The RK3588 SoC family integrates a Quad-Pixel (QP) variant of the
> > >> Synopsys DesignWare HDMI TX controller used in the previous SoCs.
> > >>
> > >> It is HDMI 2.1 compliant and supports the following features, among
> > >> others:
> > >>
> > > .
> > > 
> > > ..
> > > 
> > >> * SCDC I2C DDC access
> > >> * TMDS Scrambler enabling 2160p@60Hz with RGB/YCbCr4:4:4
> > >> * YCbCr4:2:0 enabling 2160p@60Hz at lower HDMI link speeds
> > >> * Multi-stream audio
> > >> * Enhanced Audio Return Channel (EARC)
> > > -> Those features were already supported by the HDMI 2.0a compliant HW, just
> > > list the _new_ features for HDMI 2.1
> > > 
> > > I did a quick review of your patchset and I don't understand why you need
> > > to add a separate dw-hdmi-qp.c since you only need simple variants of the I2C
> > > bus, infoframe and bridge setup.
> > > 
> > > Can you elaborate further ? isn't this Quad-Pixel (QP) TX controller version
> > > detectable at runtime ?
> > > 
> > > I would prefer to keep a single dw-hdmi driver if possible.
> >
> > The QP HDMI controller is a completely different variant with totally different
> > registers layout, see PATCH 13/14.
> > I think make it a separate driver will be easier for development and maintenance.
> 
> I'm with Andy here. Trying to navigate a driver for two IP blocks really
> sounds taxing especially when both are so different.

If it's a completely new controller, I agree that it needs a new driver,
but then why do we need to share code between the two?

Maxime

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

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 13/14] drm/bridge: synopsys: Add DW HDMI QP TX controller driver

[Cristian Ciocaltea]

Hi Sam,

On 6/1/24 5:32 PM, Sam Ravnborg wrote:
> Hi Cristian,
> 
> a few drive-by comments below.
> 
> 	Sam
> 
> 
>> +
>> +static const struct drm_connector_funcs dw_hdmi_qp_connector_funcs = {
>> +	.fill_modes = drm_helper_probe_single_connector_modes,
>> +	.detect = dw_hdmi_connector_detect,
>> +	.destroy = drm_connector_cleanup,
>> +	.force = dw_hdmi_qp_connector_force,
>> +	.reset = drm_atomic_helper_connector_reset,
>> +	.atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
>> +	.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
>> +};
>> +
>> +static int dw_hdmi_qp_bridge_attach(struct drm_bridge *bridge,
>> +				    enum drm_bridge_attach_flags flags)
>> +{
>> +	struct dw_hdmi *hdmi = bridge->driver_private;
>> +
>> +	if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)
>> +		return drm_bridge_attach(bridge->encoder, hdmi->next_bridge,
>> +					 bridge, flags);
>> +
>> +	return dw_hdmi_connector_create(hdmi, &dw_hdmi_qp_connector_funcs);
>> +}
> 
> Are there any users left that requires the display driver to create the
> connector?
> In other words - could this driver fail if DRM_BRIDGE_ATTACH_NO_CONNECTOR
> is not passed and drop dw_hdmi_connector_create()?
> 
> I did not try to verify this - just a naive question.

I've just tested this and it doesn't work - dw_hdmi_connector_create()
is still needed.

Regards,
Cristian

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 00/14] Add initial support for the Rockchip RK3588 HDMI TX Controller

[Cristian Ciocaltea]

On 6/1/24 7:32 PM, Dmitry Baryshkov wrote:
> On Sat, Jun 01, 2024 at 04:12:22PM +0300, Cristian Ciocaltea wrote:
>> The RK3588 SoC family integrates a Quad-Pixel (QP) variant of the
>> Synopsys DesignWare HDMI TX controller used in the previous SoCs.
>>
>> It is HDMI 2.1 compliant and supports the following features, among
>> others:
>>
>> * Fixed Rate Link (FRL)
>> * 4K@120Hz and 8K@60Hz video modes
>> * Variable Refresh Rate (VRR) including Quick Media Switching (QMS)
>> * Fast Vactive (FVA)
>> * SCDC I2C DDC access
>> * TMDS Scrambler enabling 2160p@60Hz with RGB/YCbCr4:4:4
>> * YCbCr4:2:0 enabling 2160p@60Hz at lower HDMI link speeds
>> * Multi-stream audio
>> * Enhanced Audio Return Channel (EARC)
> 
> It would be really nice if you can take a look at using the HDMI
> connector framework (landed few days ago) with adaptations for the
> drm_bridge / drm_bridge_connector ([1]). Your comments for the
> drm_bridge patches would be defeinitely appreciated.
> 
> [1] https://lore.kernel.org/dri-devel/20240531-bridge-hdmi-connector-v4-0-5110f7943622@linaro.org/

I will definitely check and try to use it, but I'd rather wait a bit
until this gets stabilized and focus instead on the mandatory changes
required to upstream this driver. That's mostly because my limited
availability and expertise on the matter, while trying to unblock other
work depending on this.

Thanks,
Cristian

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 00/14] Add initial support for the Rockchip RK3588 HDMI TX Controller

[Cristian Ciocaltea]

On 6/2/24 10:59 AM, Piotr Oniszczuk wrote:
> (resent as plain text instead of html)
>  
> Cristian,
> 
> I was awaiting over year for this work!
> 
> I’m devel. 2 distros where single mainline kernel serves 2835/2711/2712/h6/h313/h616/h618/rk3328/rk3399/rk3566/rk3568/rk3588/s905/s912/sm1/g12.
> 
> Before this work rk3588 was excluded because rk3588 hdmi was regressing hdmi on other socs.
> With this code all other socs seems work ok now. Perfect.

Many thanks for giving this a try on a broad range of SoCs, especially
considering my limited testing capabilities!

> As one of my project is multimedia appliance - good news is that now i can nicely play hdtv on rk3588 using mainline common 6.9.3 kernel and….started to hear from my users a lot of Qs like: „ah so nice! rk3588 now works nicely….but where is hdmi audio and cec?”
> 
> It will be fantastic to add (e.g. by backport Detlev https://gitlab.collabora.com/hardware-enablement/rockchip-3588/linux/-/tree/rk3588-hdmi-audio?ref_type=heads ) audio code to get basic support hdmi audio?

The main focus is now on upstreaming the basic support. This should
further facilitate adding the missing features, so we will slowly get
there, eventually.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 00/14] Add initial support for the Rockchip RK3588 HDMI TX Controller

[Cristian Ciocaltea]

On 6/3/24 4:08 PM, neil.armstrong@linaro.org wrote:
> Hi,
> 
> On 03/06/2024 15:03, Heiko Stuebner wrote:
>> Am Montag, 3. Juni 2024, 14:14:17 CEST schrieb Andy Yan:
>>> Hi Neil:
>>>
>>> On 6/3/24 16:55, Neil Armstrong wrote:
>>>> Hi Christian,
>>>>
>>>> On 01/06/2024 15:12, Cristian Ciocaltea wrote:
>>>>> The RK3588 SoC family integrates a Quad-Pixel (QP) variant of the
>>>>> Synopsys DesignWare HDMI TX controller used in the previous SoCs.
>>>>>
>>>>> It is HDMI 2.1 compliant and supports the following features, among
>>>>> others:
>>>>>
>>>> .
>>>>
>>>> ..
>>>>
>>>>> * SCDC I2C DDC access
>>>>> * TMDS Scrambler enabling 2160p@60Hz with RGB/YCbCr4:4:4
>>>>> * YCbCr4:2:0 enabling 2160p@60Hz at lower HDMI link speeds
>>>>> * Multi-stream audio
>>>>> * Enhanced Audio Return Channel (EARC)
>>>> -> Those features were already supported by the HDMI 2.0a compliant
>>>> HW, just
>>>> list the _new_ features for HDMI 2.1
>>>>
>>>> I did a quick review of your patchset and I don't understand why you
>>>> need
>>>> to add a separate dw-hdmi-qp.c since you only need simple variants
>>>> of the I2C
>>>> bus, infoframe and bridge setup.
>>>>
>>>> Can you elaborate further ? isn't this Quad-Pixel (QP) TX controller
>>>> version
>>>> detectable at runtime ?
>>>>
>>>> I would prefer to keep a single dw-hdmi driver if possible.
>>>
>>>
>>>
>>> The QP HDMI controller is a completely different variant with totally
>>> different
>>> registers layout, see PATCH 13/14.
>>> I think make it a separate driver will be easier for development and
>>> maintenance.
>>
>> I'm with Andy here. Trying to navigate a driver for two IP blocks really
>> sounds taxing especially when both are so different.

Thank you all for the valuable feedback!

> I agree, I just wanted more details than "variant of the
> Synopsys DesignWare HDMI TX controller", if the register mapping is 100%
> different, and does not match at all with the old IP, then it's indeed time
> to make a brand new driver, but instead of doing a mix up, it's time to
> extract
> the dw-hdmi code that could be common helpers into a dw-hdmi-common module
> and use them.

Sounds good, will handle this in v2.

> As I see, no "driver" code can be shared, only DRM plumbings, so perhaps
> those
> plumbing code should go into the DRM core ?
> 
> In any case, please add more details on the cover letter, including the
> detailed
> HW differrence and the design you chose so support this new IP.

Andy, could you please help with a summary of the HW changes?
The information I could provide is rather limited, since I don't have
access to any DW IP datasheets and I'm also not familiar enough with the
old variant.

> Neil
> 
>>
>> Synopsis also created a new dsi controller for the DSI2 standard, with
>> a vastly different registers layout.
>>
>> I guess at some point there is time to say this really is a new IP ;-) .
>>
>>
>> Though while on that thought, I don't fully understand why both a
>> compiled
>> under the dw_hdmi kconfig symbol. People going for a minimal kernel might
>> want one or the other, but not both for their specific board.

Indeed, it makes sense to have a dedicated Kconfig option. This is
mostly a leftover from downstream implementation, will fix in v2.

Thanks again,
Cristian

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 13/14] drm/bridge: synopsys: Add DW HDMI QP TX controller driver

[Sam Ravnborg]

Hi Cristian.

On Tue, Jun 04, 2024 at 10:32:04PM +0300, Cristian Ciocaltea wrote:
> Hi Sam,
> 
> On 6/1/24 5:32 PM, Sam Ravnborg wrote:
> > Hi Cristian,
> > 
> > a few drive-by comments below.
> > 
> > 	Sam
> > 
> > 
> >> +
> >> +static const struct drm_connector_funcs dw_hdmi_qp_connector_funcs = {
> >> +	.fill_modes = drm_helper_probe_single_connector_modes,
> >> +	.detect = dw_hdmi_connector_detect,
> >> +	.destroy = drm_connector_cleanup,
> >> +	.force = dw_hdmi_qp_connector_force,
> >> +	.reset = drm_atomic_helper_connector_reset,
> >> +	.atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
> >> +	.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
> >> +};
> >> +
> >> +static int dw_hdmi_qp_bridge_attach(struct drm_bridge *bridge,
> >> +				    enum drm_bridge_attach_flags flags)
> >> +{
> >> +	struct dw_hdmi *hdmi = bridge->driver_private;
> >> +
> >> +	if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)
> >> +		return drm_bridge_attach(bridge->encoder, hdmi->next_bridge,
> >> +					 bridge, flags);
> >> +
> >> +	return dw_hdmi_connector_create(hdmi, &dw_hdmi_qp_connector_funcs);
> >> +}
> > 
> > Are there any users left that requires the display driver to create the
> > connector?
> > In other words - could this driver fail if DRM_BRIDGE_ATTACH_NO_CONNECTOR
> > is not passed and drop dw_hdmi_connector_create()?
> > 
> > I did not try to verify this - just a naive question.
> 
> I've just tested this and it doesn't work - dw_hdmi_connector_create()
> is still needed.

Hmm, seems the display driver or some other bridge driver fails to
support "DRM_BRIDGE_ATTACH_NO_CONNECTOR".
what other drivers are involved?

Note that my comments here should be seen as potential future
improvements, and do not block the patch from being used.

	Sam

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 13/14] drm/bridge: synopsys: Add DW HDMI QP TX controller driver

[Cristian Ciocaltea]

On 6/4/24 11:41 PM, Sam Ravnborg wrote:
> Hi Cristian.
> 
> On Tue, Jun 04, 2024 at 10:32:04PM +0300, Cristian Ciocaltea wrote:
>> Hi Sam,
>>
>> On 6/1/24 5:32 PM, Sam Ravnborg wrote:
>>> Hi Cristian,
>>>
>>> a few drive-by comments below.
>>>
>>> 	Sam
>>>
>>>
>>>> +
>>>> +static const struct drm_connector_funcs dw_hdmi_qp_connector_funcs = {
>>>> +	.fill_modes = drm_helper_probe_single_connector_modes,
>>>> +	.detect = dw_hdmi_connector_detect,
>>>> +	.destroy = drm_connector_cleanup,
>>>> +	.force = dw_hdmi_qp_connector_force,
>>>> +	.reset = drm_atomic_helper_connector_reset,
>>>> +	.atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
>>>> +	.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
>>>> +};
>>>> +
>>>> +static int dw_hdmi_qp_bridge_attach(struct drm_bridge *bridge,
>>>> +				    enum drm_bridge_attach_flags flags)
>>>> +{
>>>> +	struct dw_hdmi *hdmi = bridge->driver_private;
>>>> +
>>>> +	if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)
>>>> +		return drm_bridge_attach(bridge->encoder, hdmi->next_bridge,
>>>> +					 bridge, flags);
>>>> +
>>>> +	return dw_hdmi_connector_create(hdmi, &dw_hdmi_qp_connector_funcs);
>>>> +}
>>>
>>> Are there any users left that requires the display driver to create the
>>> connector?
>>> In other words - could this driver fail if DRM_BRIDGE_ATTACH_NO_CONNECTOR
>>> is not passed and drop dw_hdmi_connector_create()?
>>>
>>> I did not try to verify this - just a naive question.
>>
>> I've just tested this and it doesn't work - dw_hdmi_connector_create()
>> is still needed.
> 
> Hmm, seems the display driver or some other bridge driver fails to
> support "DRM_BRIDGE_ATTACH_NO_CONNECTOR".
> what other drivers are involved?

Could it be related to the glue driver (updated in the next patch) which
is also responsible for setting up the encoder?

> Note that my comments here should be seen as potential future
> improvements, and do not block the patch from being used.

Thanks for the heads up! Will try to get back to this soon and investigate.

Cristian

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 00/14] Add initial support for the Rockchip RK3588 HDMI TX Controller

[Dmitry Baryshkov]

On Tue, Jun 04, 2024 at 10:44:04PM +0300, Cristian Ciocaltea wrote:
> On 6/1/24 7:32 PM, Dmitry Baryshkov wrote:
> > On Sat, Jun 01, 2024 at 04:12:22PM +0300, Cristian Ciocaltea wrote:
> >> The RK3588 SoC family integrates a Quad-Pixel (QP) variant of the
> >> Synopsys DesignWare HDMI TX controller used in the previous SoCs.
> >>
> >> It is HDMI 2.1 compliant and supports the following features, among
> >> others:
> >>
> >> * Fixed Rate Link (FRL)
> >> * 4K@120Hz and 8K@60Hz video modes
> >> * Variable Refresh Rate (VRR) including Quick Media Switching (QMS)
> >> * Fast Vactive (FVA)
> >> * SCDC I2C DDC access
> >> * TMDS Scrambler enabling 2160p@60Hz with RGB/YCbCr4:4:4
> >> * YCbCr4:2:0 enabling 2160p@60Hz at lower HDMI link speeds
> >> * Multi-stream audio
> >> * Enhanced Audio Return Channel (EARC)
> > 
> > It would be really nice if you can take a look at using the HDMI
> > connector framework (landed few days ago) with adaptations for the
> > drm_bridge / drm_bridge_connector ([1]). Your comments for the
> > drm_bridge patches would be defeinitely appreciated.
> > 
> > [1] https://lore.kernel.org/dri-devel/20240531-bridge-hdmi-connector-v4-0-5110f7943622@linaro.org/
> 
> I will definitely check and try to use it, but I'd rather wait a bit
> until this gets stabilized and focus instead on the mandatory changes
> required to upstream this driver. That's mostly because my limited
> availability and expertise on the matter, while trying to unblock other
> work depending on this.

Ack.

-- 
With best wishes
Dmitry

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re:Re: [PATCH 00/14] Add initial support for the Rockchip RK3588 HDMI TX Controller

[Andy Yan]

Hi,

At 2024-06-05 04:33:57, "Cristian Ciocaltea" <cristian.ciocaltea@collabora.com> wrote:
>On 6/3/24 4:08 PM, neil.armstrong@linaro.org wrote:
>> Hi,
>> 
>> On 03/06/2024 15:03, Heiko Stuebner wrote:
>>> Am Montag, 3. Juni 2024, 14:14:17 CEST schrieb Andy Yan:
>>>> Hi Neil:
>>>>
>>>> On 6/3/24 16:55, Neil Armstrong wrote:
>>>>> Hi Christian,
>>>>>
>>>>> On 01/06/2024 15:12, Cristian Ciocaltea wrote:
>>>>>> The RK3588 SoC family integrates a Quad-Pixel (QP) variant of the
>>>>>> Synopsys DesignWare HDMI TX controller used in the previous SoCs.
>>>>>>
>>>>>> It is HDMI 2.1 compliant and supports the following features, among
>>>>>> others:
>>>>>>
>>>>> .
>>>>>
>>>>> ..
>>>>>
>>>>>> * SCDC I2C DDC access
>>>>>> * TMDS Scrambler enabling 2160p@60Hz with RGB/YCbCr4:4:4
>>>>>> * YCbCr4:2:0 enabling 2160p@60Hz at lower HDMI link speeds
>>>>>> * Multi-stream audio
>>>>>> * Enhanced Audio Return Channel (EARC)
>>>>> -> Those features were already supported by the HDMI 2.0a compliant
>>>>> HW, just
>>>>> list the _new_ features for HDMI 2.1
>>>>>
>>>>> I did a quick review of your patchset and I don't understand why you
>>>>> need
>>>>> to add a separate dw-hdmi-qp.c since you only need simple variants
>>>>> of the I2C
>>>>> bus, infoframe and bridge setup.
>>>>>
>>>>> Can you elaborate further ? isn't this Quad-Pixel (QP) TX controller
>>>>> version
>>>>> detectable at runtime ?
>>>>>
>>>>> I would prefer to keep a single dw-hdmi driver if possible.
>>>>
>>>>
>>>>
>>>> The QP HDMI controller is a completely different variant with totally
>>>> different
>>>> registers layout, see PATCH 13/14.
>>>> I think make it a separate driver will be easier for development and
>>>> maintenance.
>>>
>>> I'm with Andy here. Trying to navigate a driver for two IP blocks really
>>> sounds taxing especially when both are so different.
>
>Thank you all for the valuable feedback!
>
>> I agree, I just wanted more details than "variant of the
>> Synopsys DesignWare HDMI TX controller", if the register mapping is 100%
>> different, and does not match at all with the old IP, then it's indeed time
>> to make a brand new driver, but instead of doing a mix up, it's time to
>> extract
>> the dw-hdmi code that could be common helpers into a dw-hdmi-common module
>> and use them.
>
>Sounds good, will handle this in v2.
>
>> As I see, no "driver" code can be shared, only DRM plumbings, so perhaps
>> those
>> plumbing code should go into the DRM core ?
>> 
>> In any case, please add more details on the cover letter, including the
>> detailed
>> HW differrence and the design you chose so support this new IP.
>
>Andy, could you please help with a summary of the HW changes?
>The information I could provide is rather limited, since I don't have
>access to any DW IP datasheets and I'm also not familiar enough with the
>old variant.
>
 Accurately, we should refer to it as an entirely new IP，it has nothing in common with
the current mainline dw-hdmi。 The only  commonality is that they both come from
Synopsys DesignWare：
（1）It has a 100% different register mapping
（2）It supports FRL and DSC 
（3）different configuration flow in many places。

So I have the same feeling with Heiko and Maxime：
The DW_HDMI_QP should have a  separate driver and with it's  own CONFIG  such as DRM_DW_HDMI_QP  in Kconfig.
and the rockchip part should also be split from dw_hdmi-rockchip.c.  
I am sorry we mixed them in dw_hdmi-rockchip.c when we develop the bsp driver，but we really regretted this decision
when  we repeatedly broke compatibility with dw-hdmi on other socs。 



>> Neil
>> 
>>>
>>> Synopsis also created a new dsi controller for the DSI2 standard, with
>>> a vastly different registers layout.
>>>
>>> I guess at some point there is time to say this really is a new IP ;-) .
>>>
>>>
>>> Though while on that thought, I don't fully understand why both a
>>> compiled
>>> under the dw_hdmi kconfig symbol. People going for a minimal kernel might
>>> want one or the other, but not both for their specific board.
>
>Indeed, it makes sense to have a dedicated Kconfig option. This is
>mostly a leftover from downstream implementation, will fix in v2.
>
>Thanks again,
>Cristian
>
>_______________________________________________
>linux-arm-kernel mailing list
>linux-arm-kernel@lists.infradead.org
>http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 00/14] Add initial support for the Rockchip RK3588 HDMI TX Controller

[neil.armstrong]

Hi,

On 05/06/2024 11:25, Andy Yan wrote:
> 
> Hi,
> 
> At 2024-06-05 04:33:57, "Cristian Ciocaltea" <cristian.ciocaltea@collabora.com> wrote:
>> On 6/3/24 4:08 PM, neil.armstrong@linaro.org wrote:
>>> Hi,
>>>
>>> On 03/06/2024 15:03, Heiko Stuebner wrote:
>>>> Am Montag, 3. Juni 2024, 14:14:17 CEST schrieb Andy Yan:
>>>>> Hi Neil:
>>>>>
>>>>> On 6/3/24 16:55, Neil Armstrong wrote:
>>>>>> Hi Christian,
>>>>>>
>>>>>> On 01/06/2024 15:12, Cristian Ciocaltea wrote:
>>>>>>> The RK3588 SoC family integrates a Quad-Pixel (QP) variant of the
>>>>>>> Synopsys DesignWare HDMI TX controller used in the previous SoCs.
>>>>>>>
>>>>>>> It is HDMI 2.1 compliant and supports the following features, among
>>>>>>> others:
>>>>>>>
>>>>>> .
>>>>>>
>>>>>> ..
>>>>>>
>>>>>>> * SCDC I2C DDC access
>>>>>>> * TMDS Scrambler enabling 2160p@60Hz with RGB/YCbCr4:4:4
>>>>>>> * YCbCr4:2:0 enabling 2160p@60Hz at lower HDMI link speeds
>>>>>>> * Multi-stream audio
>>>>>>> * Enhanced Audio Return Channel (EARC)
>>>>>> -> Those features were already supported by the HDMI 2.0a compliant
>>>>>> HW, just
>>>>>> list the _new_ features for HDMI 2.1
>>>>>>
>>>>>> I did a quick review of your patchset and I don't understand why you
>>>>>> need
>>>>>> to add a separate dw-hdmi-qp.c since you only need simple variants
>>>>>> of the I2C
>>>>>> bus, infoframe and bridge setup.
>>>>>>
>>>>>> Can you elaborate further ? isn't this Quad-Pixel (QP) TX controller
>>>>>> version
>>>>>> detectable at runtime ?
>>>>>>
>>>>>> I would prefer to keep a single dw-hdmi driver if possible.
>>>>>
>>>>>
>>>>>
>>>>> The QP HDMI controller is a completely different variant with totally
>>>>> different
>>>>> registers layout, see PATCH 13/14.
>>>>> I think make it a separate driver will be easier for development and
>>>>> maintenance.
>>>>
>>>> I'm with Andy here. Trying to navigate a driver for two IP blocks really
>>>> sounds taxing especially when both are so different.
>>
>> Thank you all for the valuable feedback!
>>
>>> I agree, I just wanted more details than "variant of the
>>> Synopsys DesignWare HDMI TX controller", if the register mapping is 100%
>>> different, and does not match at all with the old IP, then it's indeed time
>>> to make a brand new driver, but instead of doing a mix up, it's time to
>>> extract
>>> the dw-hdmi code that could be common helpers into a dw-hdmi-common module
>>> and use them.
>>
>> Sounds good, will handle this in v2.
>>
>>> As I see, no "driver" code can be shared, only DRM plumbings, so perhaps
>>> those
>>> plumbing code should go into the DRM core ?
>>>
>>> In any case, please add more details on the cover letter, including the
>>> detailed
>>> HW differrence and the design you chose so support this new IP.
>>
>> Andy, could you please help with a summary of the HW changes?
>> The information I could provide is rather limited, since I don't have
>> access to any DW IP datasheets and I'm also not familiar enough with the
>> old variant.
>>
>   Accurately, we should refer to it as an entirely new IP，it has nothing in common with
> the current mainline dw-hdmi。 The only  commonality is that they both come from
> Synopsys DesignWare：
> （1）It has a 100% different register mapping
> （2）It supports FRL and DSC
> （3）different configuration flow in many places。
> 
> So I have the same feeling with Heiko and Maxime：
> The DW_HDMI_QP should have a  separate driver and with it's  own CONFIG  such as DRM_DW_HDMI_QP  in Kconfig.
> and the rockchip part should also be split from dw_hdmi-rockchip.c.
> I am sorry we mixed them in dw_hdmi-rockchip.c when we develop the bsp driver，but we really regretted this decision
> when  we repeatedly broke compatibility with dw-hdmi on other socs。

Yes please, and as I say, if there's code common with the old dw-hdmi, please add a common
module if this code can't be moved in core bridge helpers.

Neil

> 
> 
> 
>>> Neil
>>>
>>>>
>>>> Synopsis also created a new dsi controller for the DSI2 standard, with
>>>> a vastly different registers layout.
>>>>
>>>> I guess at some point there is time to say this really is a new IP ;-) .
>>>>
>>>>
>>>> Though while on that thought, I don't fully understand why both a
>>>> compiled
>>>> under the dw_hdmi kconfig symbol. People going for a minimal kernel might
>>>> want one or the other, but not both for their specific board.
>>
>> Indeed, it makes sense to have a dedicated Kconfig option. This is
>> mostly a leftover from downstream implementation, will fix in v2.
>>
>> Thanks again,
>> Cristian
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 00/14] Add initial support for the Rockchip RK3588 HDMI TX Controller

[Maxime Ripard]

[-- Attachment #1.1: Type: text/plain, Size: 4781 bytes --]

On Wed, Jun 05, 2024 at 11:28:41AM GMT, neil.armstrong@linaro.org wrote:
> Hi,
> 
> On 05/06/2024 11:25, Andy Yan wrote:
> > 
> > Hi,
> > 
> > At 2024-06-05 04:33:57, "Cristian Ciocaltea" <cristian.ciocaltea@collabora.com> wrote:
> > > On 6/3/24 4:08 PM, neil.armstrong@linaro.org wrote:
> > > > Hi,
> > > > 
> > > > On 03/06/2024 15:03, Heiko Stuebner wrote:
> > > > > Am Montag, 3. Juni 2024, 14:14:17 CEST schrieb Andy Yan:
> > > > > > Hi Neil:
> > > > > > 
> > > > > > On 6/3/24 16:55, Neil Armstrong wrote:
> > > > > > > Hi Christian,
> > > > > > > 
> > > > > > > On 01/06/2024 15:12, Cristian Ciocaltea wrote:
> > > > > > > > The RK3588 SoC family integrates a Quad-Pixel (QP) variant of the
> > > > > > > > Synopsys DesignWare HDMI TX controller used in the previous SoCs.
> > > > > > > > 
> > > > > > > > It is HDMI 2.1 compliant and supports the following features, among
> > > > > > > > others:
> > > > > > > > 
> > > > > > > .
> > > > > > > 
> > > > > > > ..
> > > > > > > 
> > > > > > > > * SCDC I2C DDC access
> > > > > > > > * TMDS Scrambler enabling 2160p@60Hz with RGB/YCbCr4:4:4
> > > > > > > > * YCbCr4:2:0 enabling 2160p@60Hz at lower HDMI link speeds
> > > > > > > > * Multi-stream audio
> > > > > > > > * Enhanced Audio Return Channel (EARC)
> > > > > > > -> Those features were already supported by the HDMI 2.0a compliant
> > > > > > > HW, just
> > > > > > > list the _new_ features for HDMI 2.1
> > > > > > > 
> > > > > > > I did a quick review of your patchset and I don't understand why you
> > > > > > > need
> > > > > > > to add a separate dw-hdmi-qp.c since you only need simple variants
> > > > > > > of the I2C
> > > > > > > bus, infoframe and bridge setup.
> > > > > > > 
> > > > > > > Can you elaborate further ? isn't this Quad-Pixel (QP) TX controller
> > > > > > > version
> > > > > > > detectable at runtime ?
> > > > > > > 
> > > > > > > I would prefer to keep a single dw-hdmi driver if possible.
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > The QP HDMI controller is a completely different variant with totally
> > > > > > different
> > > > > > registers layout, see PATCH 13/14.
> > > > > > I think make it a separate driver will be easier for development and
> > > > > > maintenance.
> > > > > 
> > > > > I'm with Andy here. Trying to navigate a driver for two IP blocks really
> > > > > sounds taxing especially when both are so different.
> > > 
> > > Thank you all for the valuable feedback!
> > > 
> > > > I agree, I just wanted more details than "variant of the
> > > > Synopsys DesignWare HDMI TX controller", if the register mapping is 100%
> > > > different, and does not match at all with the old IP, then it's indeed time
> > > > to make a brand new driver, but instead of doing a mix up, it's time to
> > > > extract
> > > > the dw-hdmi code that could be common helpers into a dw-hdmi-common module
> > > > and use them.
> > > 
> > > Sounds good, will handle this in v2.
> > > 
> > > > As I see, no "driver" code can be shared, only DRM plumbings, so perhaps
> > > > those
> > > > plumbing code should go into the DRM core ?
> > > > 
> > > > In any case, please add more details on the cover letter, including the
> > > > detailed
> > > > HW differrence and the design you chose so support this new IP.
> > > 
> > > Andy, could you please help with a summary of the HW changes?
> > > The information I could provide is rather limited, since I don't have
> > > access to any DW IP datasheets and I'm also not familiar enough with the
> > > old variant.
> > > 
> >   Accurately, we should refer to it as an entirely new IP，it has nothing in common with
> > the current mainline dw-hdmi。 The only  commonality is that they both come from
> > Synopsys DesignWare：
> > （1）It has a 100% different register mapping
> > （2）It supports FRL and DSC
> > （3）different configuration flow in many places。
> > 
> > So I have the same feeling with Heiko and Maxime：
> > The DW_HDMI_QP should have a  separate driver and with it's  own CONFIG  such as DRM_DW_HDMI_QP  in Kconfig.
> > and the rockchip part should also be split from dw_hdmi-rockchip.c.
> > I am sorry we mixed them in dw_hdmi-rockchip.c when we develop the bsp driver，but we really regretted this decision
> > when  we repeatedly broke compatibility with dw-hdmi on other socs。
> 
> Yes please, and as I say, if there's code common with the old dw-hdmi, please add a common
> module if this code can't be moved in core bridge helpers.

And chances are that the common code is actually there to deal with HDMI
spec itself and not really the hardware, which is solved by moving both
drivers to the HDMI helpers that just got merged.

Maxime

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

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re:Re: [PATCH 00/14] Add initial support for the Rockchip RK3588 HDMI TX Controller

[Andy Yan]

Hi,
At 2024-06-05 17:39:48, "Maxime Ripard" <mripard@kernel.org> wrote:
>On Wed, Jun 05, 2024 at 11:28:41AM GMT, neil.armstrong@linaro.org wrote:
>> Hi,
>> 
>> On 05/06/2024 11:25, Andy Yan wrote:
>> > 
>> > Hi,
>> > 
>> > At 2024-06-05 04:33:57, "Cristian Ciocaltea" <cristian.ciocaltea@collabora.com> wrote:
>> > > On 6/3/24 4:08 PM, neil.armstrong@linaro.org wrote:
>> > > > Hi,
>> > > > 
>> > > > On 03/06/2024 15:03, Heiko Stuebner wrote:
>> > > > > Am Montag, 3. Juni 2024, 14:14:17 CEST schrieb Andy Yan:
>> > > > > > Hi Neil:
>> > > > > > 
>> > > > > > On 6/3/24 16:55, Neil Armstrong wrote:
>> > > > > > > Hi Christian,
>> > > > > > > 
>> > > > > > > On 01/06/2024 15:12, Cristian Ciocaltea wrote:
>> > > > > > > > The RK3588 SoC family integrates a Quad-Pixel (QP) variant of the
>> > > > > > > > Synopsys DesignWare HDMI TX controller used in the previous SoCs.
>> > > > > > > > 
>> > > > > > > > It is HDMI 2.1 compliant and supports the following features, among
>> > > > > > > > others:
>> > > > > > > > 
>> > > > > > > .
>> > > > > > > 
>> > > > > > > ..
>> > > > > > > 
>> > > > > > > > * SCDC I2C DDC access
>> > > > > > > > * TMDS Scrambler enabling 2160p@60Hz with RGB/YCbCr4:4:4
>> > > > > > > > * YCbCr4:2:0 enabling 2160p@60Hz at lower HDMI link speeds
>> > > > > > > > * Multi-stream audio
>> > > > > > > > * Enhanced Audio Return Channel (EARC)
>> > > > > > > -> Those features were already supported by the HDMI 2.0a compliant
>> > > > > > > HW, just
>> > > > > > > list the _new_ features for HDMI 2.1
>> > > > > > > 
>> > > > > > > I did a quick review of your patchset and I don't understand why you
>> > > > > > > need
>> > > > > > > to add a separate dw-hdmi-qp.c since you only need simple variants
>> > > > > > > of the I2C
>> > > > > > > bus, infoframe and bridge setup.
>> > > > > > > 
>> > > > > > > Can you elaborate further ? isn't this Quad-Pixel (QP) TX controller
>> > > > > > > version
>> > > > > > > detectable at runtime ?
>> > > > > > > 
>> > > > > > > I would prefer to keep a single dw-hdmi driver if possible.
>> > > > > > 
>> > > > > > 
>> > > > > > 
>> > > > > > The QP HDMI controller is a completely different variant with totally
>> > > > > > different
>> > > > > > registers layout, see PATCH 13/14.
>> > > > > > I think make it a separate driver will be easier for development and
>> > > > > > maintenance.
>> > > > > 
>> > > > > I'm with Andy here. Trying to navigate a driver for two IP blocks really
>> > > > > sounds taxing especially when both are so different.
>> > > 
>> > > Thank you all for the valuable feedback!
>> > > 
>> > > > I agree, I just wanted more details than "variant of the
>> > > > Synopsys DesignWare HDMI TX controller", if the register mapping is 100%
>> > > > different, and does not match at all with the old IP, then it's indeed time
>> > > > to make a brand new driver, but instead of doing a mix up, it's time to
>> > > > extract
>> > > > the dw-hdmi code that could be common helpers into a dw-hdmi-common module
>> > > > and use them.
>> > > 
>> > > Sounds good, will handle this in v2.
>> > > 
>> > > > As I see, no "driver" code can be shared, only DRM plumbings, so perhaps
>> > > > those
>> > > > plumbing code should go into the DRM core ?
>> > > > 
>> > > > In any case, please add more details on the cover letter, including the
>> > > > detailed
>> > > > HW differrence and the design you chose so support this new IP.
>> > > 
>> > > Andy, could you please help with a summary of the HW changes?
>> > > The information I could provide is rather limited, since I don't have
>> > > access to any DW IP datasheets and I'm also not familiar enough with the
>> > > old variant.
>> > > 
>> >   Accurately, we should refer to it as an entirely new IP，it has nothing in common with
>> > the current mainline dw-hdmi。 The only  commonality is that they both come from
>> > Synopsys DesignWare：
>> > （1）It has a 100% different register mapping
>> > （2）It supports FRL and DSC
>> > （3）different configuration flow in many places。
>> > 
>> > So I have the same feeling with Heiko and Maxime：
>> > The DW_HDMI_QP should have a  separate driver and with it's  own CONFIG  such as DRM_DW_HDMI_QP  in Kconfig.
>> > and the rockchip part should also be split from dw_hdmi-rockchip.c.
>> > I am sorry we mixed them in dw_hdmi-rockchip.c when we develop the bsp driver，but we really regretted this decision
>> > when  we repeatedly broke compatibility with dw-hdmi on other socs。
>> 
>> Yes please, and as I say, if there's code common with the old dw-hdmi, please add a common
>> module if this code can't be moved in core bridge helpers.
>
>And chances are that the common code is actually there to deal with HDMI
>spec itself and not really the hardware, which is solved by moving both
>drivers to the HDMI helpers that just got merged.
>

Yes, +1.
I don't think we need to share some common code with dw-hdmi here.

>Maxime
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 13/14] drm/bridge: synopsys: Add DW HDMI QP TX controller driver

[Cristian Ciocaltea]

On 6/5/24 12:34 AM, Cristian Ciocaltea wrote:
> On 6/4/24 11:41 PM, Sam Ravnborg wrote:
>> Hi Cristian.
>>
>> On Tue, Jun 04, 2024 at 10:32:04PM +0300, Cristian Ciocaltea wrote:
>>> Hi Sam,
>>>
>>> On 6/1/24 5:32 PM, Sam Ravnborg wrote:
>>>> Hi Cristian,
>>>>
>>>> a few drive-by comments below.
>>>>
>>>> 	Sam
>>>>
>>>>
>>>>> +
>>>>> +static const struct drm_connector_funcs dw_hdmi_qp_connector_funcs = {
>>>>> +	.fill_modes = drm_helper_probe_single_connector_modes,
>>>>> +	.detect = dw_hdmi_connector_detect,
>>>>> +	.destroy = drm_connector_cleanup,
>>>>> +	.force = dw_hdmi_qp_connector_force,
>>>>> +	.reset = drm_atomic_helper_connector_reset,
>>>>> +	.atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
>>>>> +	.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
>>>>> +};
>>>>> +
>>>>> +static int dw_hdmi_qp_bridge_attach(struct drm_bridge *bridge,
>>>>> +				    enum drm_bridge_attach_flags flags)
>>>>> +{
>>>>> +	struct dw_hdmi *hdmi = bridge->driver_private;
>>>>> +
>>>>> +	if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)
>>>>> +		return drm_bridge_attach(bridge->encoder, hdmi->next_bridge,
>>>>> +					 bridge, flags);
>>>>> +
>>>>> +	return dw_hdmi_connector_create(hdmi, &dw_hdmi_qp_connector_funcs);
>>>>> +}
>>>>
>>>> Are there any users left that requires the display driver to create the
>>>> connector?
>>>> In other words - could this driver fail if DRM_BRIDGE_ATTACH_NO_CONNECTOR
>>>> is not passed and drop dw_hdmi_connector_create()?
>>>>
>>>> I did not try to verify this - just a naive question.
>>>
>>> I've just tested this and it doesn't work - dw_hdmi_connector_create()
>>> is still needed.
>>
>> Hmm, seems the display driver or some other bridge driver fails to
>> support "DRM_BRIDGE_ATTACH_NO_CONNECTOR".
>> what other drivers are involved?
> 
> Could it be related to the glue driver (updated in the next patch) which
> is also responsible for setting up the encoder?
> 
>> Note that my comments here should be seen as potential future
>> improvements, and do not block the patch from being used.
> 
> Thanks for the heads up! Will try to get back to this soon and investigate.
 
IIUC, modern bridges should not create the connector but rely on display
drivers to take care of, which in this case is the VOP2 driver. However,
it also handles some of the older SoCs relying on the non-QP variant of
DW HDMI IP. Hence the existing dw-hdmi driver would be also impacted in
order to come up with a proper solution.

A quick check shows there are several users of this IP:

$ git grep -E '= dw_hdmi_(bind|probe)\('
drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx.c:    hdmi->dw_hdmi = dw_hdmi_probe(pdev, plat_data);
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c:      hdmi = dw_hdmi_probe(pdev, plat_data);
drivers/gpu/drm/imx/ipuv3/dw_hdmi-imx.c:        hdmi->hdmi = dw_hdmi_probe(pdev, match->data);
drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c:      hdmi = dw_hdmi_probe(pdev, &ingenic_dw_hdmi_plat_data);
drivers/gpu/drm/meson/meson_dw_hdmi.c:  meson_dw_hdmi->hdmi = dw_hdmi_probe(pdev, &meson_dw_hdmi->dw_plat_data);
drivers/gpu/drm/renesas/rcar-du/rcar_dw_hdmi.c: hdmi = dw_hdmi_probe(pdev, &rcar_dw_hdmi_plat_data);
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c:            hdmi->hdmi = dw_hdmi_bind(pdev, encoder, plat_data);
drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c:  hdmi->hdmi = dw_hdmi_bind(pdev, encoder, plat_data);

I didn't check which display drivers would be involved, I'd guess there
are quite a few of them as well. So it seems this ends up being a pretty
complex task.

Cristian

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 00/14] Add initial support for the Rockchip RK3588 HDMI TX Controller

[Cristian Ciocaltea]

On 6/5/24 12:49 PM, Andy Yan wrote:
> 
> Hi,
> At 2024-06-05 17:39:48, "Maxime Ripard" <mripard@kernel.org> wrote:
>> On Wed, Jun 05, 2024 at 11:28:41AM GMT, neil.armstrong@linaro.org wrote:
>>> Hi,
>>>
>>> On 05/06/2024 11:25, Andy Yan wrote:
>>>>
>>>> Hi,
>>>>
>>>> At 2024-06-05 04:33:57, "Cristian Ciocaltea" <cristian.ciocaltea@collabora.com> wrote:
>>>>> On 6/3/24 4:08 PM, neil.armstrong@linaro.org wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On 03/06/2024 15:03, Heiko Stuebner wrote:
>>>>>>> Am Montag, 3. Juni 2024, 14:14:17 CEST schrieb Andy Yan:
>>>>>>>> Hi Neil:
>>>>>>>>
>>>>>>>> On 6/3/24 16:55, Neil Armstrong wrote:
>>>>>>>>> Hi Christian,
>>>>>>>>>
>>>>>>>>> On 01/06/2024 15:12, Cristian Ciocaltea wrote:
>>>>>>>>>> The RK3588 SoC family integrates a Quad-Pixel (QP) variant of the
>>>>>>>>>> Synopsys DesignWare HDMI TX controller used in the previous SoCs.
>>>>>>>>>>
>>>>>>>>>> It is HDMI 2.1 compliant and supports the following features, among
>>>>>>>>>> others:
>>>>>>>>>>
>>>>>>>>> .
>>>>>>>>>
>>>>>>>>> ..
>>>>>>>>>
>>>>>>>>>> * SCDC I2C DDC access
>>>>>>>>>> * TMDS Scrambler enabling 2160p@60Hz with RGB/YCbCr4:4:4
>>>>>>>>>> * YCbCr4:2:0 enabling 2160p@60Hz at lower HDMI link speeds
>>>>>>>>>> * Multi-stream audio
>>>>>>>>>> * Enhanced Audio Return Channel (EARC)
>>>>>>>>> -> Those features were already supported by the HDMI 2.0a compliant
>>>>>>>>> HW, just
>>>>>>>>> list the _new_ features for HDMI 2.1
>>>>>>>>>
>>>>>>>>> I did a quick review of your patchset and I don't understand why you
>>>>>>>>> need
>>>>>>>>> to add a separate dw-hdmi-qp.c since you only need simple variants
>>>>>>>>> of the I2C
>>>>>>>>> bus, infoframe and bridge setup.
>>>>>>>>>
>>>>>>>>> Can you elaborate further ? isn't this Quad-Pixel (QP) TX controller
>>>>>>>>> version
>>>>>>>>> detectable at runtime ?
>>>>>>>>>
>>>>>>>>> I would prefer to keep a single dw-hdmi driver if possible.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> The QP HDMI controller is a completely different variant with totally
>>>>>>>> different
>>>>>>>> registers layout, see PATCH 13/14.
>>>>>>>> I think make it a separate driver will be easier for development and
>>>>>>>> maintenance.
>>>>>>>
>>>>>>> I'm with Andy here. Trying to navigate a driver for two IP blocks really
>>>>>>> sounds taxing especially when both are so different.
>>>>>
>>>>> Thank you all for the valuable feedback!
>>>>>
>>>>>> I agree, I just wanted more details than "variant of the
>>>>>> Synopsys DesignWare HDMI TX controller", if the register mapping is 100%
>>>>>> different, and does not match at all with the old IP, then it's indeed time
>>>>>> to make a brand new driver, but instead of doing a mix up, it's time to
>>>>>> extract
>>>>>> the dw-hdmi code that could be common helpers into a dw-hdmi-common module
>>>>>> and use them.
>>>>>
>>>>> Sounds good, will handle this in v2.
>>>>>
>>>>>> As I see, no "driver" code can be shared, only DRM plumbings, so perhaps
>>>>>> those
>>>>>> plumbing code should go into the DRM core ?
>>>>>>
>>>>>> In any case, please add more details on the cover letter, including the
>>>>>> detailed
>>>>>> HW differrence and the design you chose so support this new IP.
>>>>>
>>>>> Andy, could you please help with a summary of the HW changes?
>>>>> The information I could provide is rather limited, since I don't have
>>>>> access to any DW IP datasheets and I'm also not familiar enough with the
>>>>> old variant.
>>>>>
>>>>   Accurately, we should refer to it as an entirely new IP，it has nothing in common with
>>>> the current mainline dw-hdmi。 The only  commonality is that they both come from
>>>> Synopsys DesignWare：
>>>> （1）It has a 100% different register mapping
>>>> （2）It supports FRL and DSC
>>>> （3）different configuration flow in many places。
>>>>
>>>> So I have the same feeling with Heiko and Maxime：
>>>> The DW_HDMI_QP should have a  separate driver and with it's  own CONFIG  such as DRM_DW_HDMI_QP  in Kconfig.
>>>> and the rockchip part should also be split from dw_hdmi-rockchip.c.
>>>> I am sorry we mixed them in dw_hdmi-rockchip.c when we develop the bsp driver，but we really regretted this decision
>>>> when  we repeatedly broke compatibility with dw-hdmi on other socs。
>>>
>>> Yes please, and as I say, if there's code common with the old dw-hdmi, please add a common
>>> module if this code can't be moved in core bridge helpers.
>>
>> And chances are that the common code is actually there to deal with HDMI
>> spec itself and not really the hardware, which is solved by moving both
>> drivers to the HDMI helpers that just got merged.

I will make use of the new HDMI helpers and see if there is anything
else remaining in terms of common code.

> Yes, +1.
> I don't think we need to share some common code with dw-hdmi here.

Ok, I will completely separate the new driver's code, including the
Rockchip glue layer.

Thanks,
Cristian

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 13/14] drm/bridge: synopsys: Add DW HDMI QP TX controller driver

[Neil Armstrong]

On 05/06/2024 12:11, Cristian Ciocaltea wrote:
> On 6/5/24 12:34 AM, Cristian Ciocaltea wrote:
>> On 6/4/24 11:41 PM, Sam Ravnborg wrote:
>>> Hi Cristian.
>>>
>>> On Tue, Jun 04, 2024 at 10:32:04PM +0300, Cristian Ciocaltea wrote:
>>>> Hi Sam,
>>>>
>>>> On 6/1/24 5:32 PM, Sam Ravnborg wrote:
>>>>> Hi Cristian,
>>>>>
>>>>> a few drive-by comments below.
>>>>>
>>>>> 	Sam
>>>>>
>>>>>
>>>>>> +
>>>>>> +static const struct drm_connector_funcs dw_hdmi_qp_connector_funcs = {
>>>>>> +	.fill_modes = drm_helper_probe_single_connector_modes,
>>>>>> +	.detect = dw_hdmi_connector_detect,
>>>>>> +	.destroy = drm_connector_cleanup,
>>>>>> +	.force = dw_hdmi_qp_connector_force,
>>>>>> +	.reset = drm_atomic_helper_connector_reset,
>>>>>> +	.atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
>>>>>> +	.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
>>>>>> +};
>>>>>> +
>>>>>> +static int dw_hdmi_qp_bridge_attach(struct drm_bridge *bridge,
>>>>>> +				    enum drm_bridge_attach_flags flags)
>>>>>> +{
>>>>>> +	struct dw_hdmi *hdmi = bridge->driver_private;
>>>>>> +
>>>>>> +	if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)
>>>>>> +		return drm_bridge_attach(bridge->encoder, hdmi->next_bridge,
>>>>>> +					 bridge, flags);
>>>>>> +
>>>>>> +	return dw_hdmi_connector_create(hdmi, &dw_hdmi_qp_connector_funcs);
>>>>>> +}
>>>>>
>>>>> Are there any users left that requires the display driver to create the
>>>>> connector?
>>>>> In other words - could this driver fail if DRM_BRIDGE_ATTACH_NO_CONNECTOR
>>>>> is not passed and drop dw_hdmi_connector_create()?
>>>>>
>>>>> I did not try to verify this - just a naive question.
>>>>
>>>> I've just tested this and it doesn't work - dw_hdmi_connector_create()
>>>> is still needed.
>>>
>>> Hmm, seems the display driver or some other bridge driver fails to
>>> support "DRM_BRIDGE_ATTACH_NO_CONNECTOR".
>>> what other drivers are involved?
>>
>> Could it be related to the glue driver (updated in the next patch) which
>> is also responsible for setting up the encoder?
>>
>>> Note that my comments here should be seen as potential future
>>> improvements, and do not block the patch from being used.
>>
>> Thanks for the heads up! Will try to get back to this soon and investigate.
>   
> IIUC, modern bridges should not create the connector but rely on display
> drivers to take care of, which in this case is the VOP2 driver. However,
> it also handles some of the older SoCs relying on the non-QP variant of
> DW HDMI IP. Hence the existing dw-hdmi driver would be also impacted in
> order to come up with a proper solution.
> 
> A quick check shows there are several users of this IP:
> 
> $ git grep -E '= dw_hdmi_(bind|probe)\('
> drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx.c:    hdmi->dw_hdmi = dw_hdmi_probe(pdev, plat_data);
> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c:      hdmi = dw_hdmi_probe(pdev, plat_data);
> drivers/gpu/drm/imx/ipuv3/dw_hdmi-imx.c:        hdmi->hdmi = dw_hdmi_probe(pdev, match->data);
> drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c:      hdmi = dw_hdmi_probe(pdev, &ingenic_dw_hdmi_plat_data);
> drivers/gpu/drm/meson/meson_dw_hdmi.c:  meson_dw_hdmi->hdmi = dw_hdmi_probe(pdev, &meson_dw_hdmi->dw_plat_data);
> drivers/gpu/drm/renesas/rcar-du/rcar_dw_hdmi.c: hdmi = dw_hdmi_probe(pdev, &rcar_dw_hdmi_plat_data);
> drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c:            hdmi->hdmi = dw_hdmi_bind(pdev, encoder, plat_data);
> drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c:  hdmi->hdmi = dw_hdmi_bind(pdev, encoder, plat_data);
> 
> I didn't check which display drivers would be involved, I'd guess there
> are quite a few of them as well. So it seems this ends up being a pretty
> complex task.

If this would be a brand new driver, then it should only support DRM_BRIDGE_ATTACH_NO_CONNECTOR,
so you should not create a connector from the driver.

The fact dw-hdmi accepts an attach without the flag is for legacy purpose
since some DRM drivers haven't switched to DRM_BRIDGE_ATTACH_NO_CONNECTOR yes,
but it's a requirement for new bridges so at some point you'll need to make
sure the rockchip glue and drm driver supports DRM_BRIDGE_ATTACH_NO_CONNECTOR.

This will greatly simplify the driver!

Neil

> 
> Cristian


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 13/14] drm/bridge: synopsys: Add DW HDMI QP TX controller driver

[Cristian Ciocaltea]

On 6/5/24 2:48 PM, Neil Armstrong wrote:
> On 05/06/2024 12:11, Cristian Ciocaltea wrote:
>> On 6/5/24 12:34 AM, Cristian Ciocaltea wrote:
>>> On 6/4/24 11:41 PM, Sam Ravnborg wrote:
>>>> Hi Cristian.
>>>>
>>>> On Tue, Jun 04, 2024 at 10:32:04PM +0300, Cristian Ciocaltea wrote:
>>>>> Hi Sam,
>>>>>
>>>>> On 6/1/24 5:32 PM, Sam Ravnborg wrote:
>>>>>> Hi Cristian,
>>>>>>
>>>>>> a few drive-by comments below.
>>>>>>
>>>>>>     Sam
>>>>>>
>>>>>>
>>>>>>> +
>>>>>>> +static const struct drm_connector_funcs
>>>>>>> dw_hdmi_qp_connector_funcs = {
>>>>>>> +    .fill_modes = drm_helper_probe_single_connector_modes,
>>>>>>> +    .detect = dw_hdmi_connector_detect,
>>>>>>> +    .destroy = drm_connector_cleanup,
>>>>>>> +    .force = dw_hdmi_qp_connector_force,
>>>>>>> +    .reset = drm_atomic_helper_connector_reset,
>>>>>>> +    .atomic_duplicate_state =
>>>>>>> drm_atomic_helper_connector_duplicate_state,
>>>>>>> +    .atomic_destroy_state =
>>>>>>> drm_atomic_helper_connector_destroy_state,
>>>>>>> +};
>>>>>>> +
>>>>>>> +static int dw_hdmi_qp_bridge_attach(struct drm_bridge *bridge,
>>>>>>> +                    enum drm_bridge_attach_flags flags)
>>>>>>> +{
>>>>>>> +    struct dw_hdmi *hdmi = bridge->driver_private;
>>>>>>> +
>>>>>>> +    if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)
>>>>>>> +        return drm_bridge_attach(bridge->encoder,
>>>>>>> hdmi->next_bridge,
>>>>>>> +                     bridge, flags);
>>>>>>> +
>>>>>>> +    return dw_hdmi_connector_create(hdmi,
>>>>>>> &dw_hdmi_qp_connector_funcs);
>>>>>>> +}
>>>>>>
>>>>>> Are there any users left that requires the display driver to
>>>>>> create the
>>>>>> connector?
>>>>>> In other words - could this driver fail if
>>>>>> DRM_BRIDGE_ATTACH_NO_CONNECTOR
>>>>>> is not passed and drop dw_hdmi_connector_create()?
>>>>>>
>>>>>> I did not try to verify this - just a naive question.
>>>>>
>>>>> I've just tested this and it doesn't work - dw_hdmi_connector_create()
>>>>> is still needed.
>>>>
>>>> Hmm, seems the display driver or some other bridge driver fails to
>>>> support "DRM_BRIDGE_ATTACH_NO_CONNECTOR".
>>>> what other drivers are involved?
>>>
>>> Could it be related to the glue driver (updated in the next patch) which
>>> is also responsible for setting up the encoder?
>>>
>>>> Note that my comments here should be seen as potential future
>>>> improvements, and do not block the patch from being used.
>>>
>>> Thanks for the heads up! Will try to get back to this soon and
>>> investigate.
>>   IIUC, modern bridges should not create the connector but rely on
>> display
>> drivers to take care of, which in this case is the VOP2 driver. However,
>> it also handles some of the older SoCs relying on the non-QP variant of
>> DW HDMI IP. Hence the existing dw-hdmi driver would be also impacted in
>> order to come up with a proper solution.
>>
>> A quick check shows there are several users of this IP:
>>
>> $ git grep -E '= dw_hdmi_(bind|probe)\('
>> drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx.c:    hdmi->dw_hdmi =
>> dw_hdmi_probe(pdev, plat_data);
>> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c:      hdmi =
>> dw_hdmi_probe(pdev, plat_data);
>> drivers/gpu/drm/imx/ipuv3/dw_hdmi-imx.c:        hdmi->hdmi =
>> dw_hdmi_probe(pdev, match->data);
>> drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c:      hdmi =
>> dw_hdmi_probe(pdev, &ingenic_dw_hdmi_plat_data);
>> drivers/gpu/drm/meson/meson_dw_hdmi.c:  meson_dw_hdmi->hdmi =
>> dw_hdmi_probe(pdev, &meson_dw_hdmi->dw_plat_data);
>> drivers/gpu/drm/renesas/rcar-du/rcar_dw_hdmi.c: hdmi =
>> dw_hdmi_probe(pdev, &rcar_dw_hdmi_plat_data);
>> drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c:            hdmi->hdmi =
>> dw_hdmi_bind(pdev, encoder, plat_data);
>> drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c:  hdmi->hdmi =
>> dw_hdmi_bind(pdev, encoder, plat_data);
>>
>> I didn't check which display drivers would be involved, I'd guess there
>> are quite a few of them as well. So it seems this ends up being a pretty
>> complex task.
> 
> If this would be a brand new driver, then it should only support
> DRM_BRIDGE_ATTACH_NO_CONNECTOR,
> so you should not create a connector from the driver.
> 
> The fact dw-hdmi accepts an attach without the flag is for legacy purpose
> since some DRM drivers haven't switched to
> DRM_BRIDGE_ATTACH_NO_CONNECTOR yes,
> but it's a requirement for new bridges so at some point you'll need to make
> sure the rockchip glue and drm driver supports
> DRM_BRIDGE_ATTACH_NO_CONNECTOR.
> 
> This will greatly simplify the driver!

Got it, thanks for the clarifications!

Cristian

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 13/14] drm/bridge: synopsys: Add DW HDMI QP TX controller driver

[Heiko Stübner]

Am Samstag, 1. Juni 2024, 15:12:35 CEST schrieb Cristian Ciocaltea:
> The Synopsys DesignWare HDMI 2.1 Quad-Pixel (QP) TX controller supports
> the following features, among others:
> 
> * Fixed Rate Link (FRL)
> * 4K@120Hz and 8K@60Hz video modes
> * Variable Refresh Rate (VRR) including Quick Media Switching (QMS), aka
>   Cinema VRR
> * Fast Vactive (FVA), aka Quick Frame Transport (QFT)
> * SCDC I2C DDC access
> * TMDS Scrambler enabling 2160p@60Hz with RGB/YCbCr4:4:4
> * YCbCr4:2:0 enabling 2160p@60Hz at lower HDMI link speeds
> * Multi-stream audio
> * Enhanced Audio Return Channel (EARC)
> 
> Add driver to enable basic support, i.e. RGB output up to 4K@60Hz,
> without audio, CEC or any HDMI 2.1 specific features.
> 
> Co-developed-by: Algea Cao <algea.cao@rock-chips.com>
> Signed-off-by: Algea Cao <algea.cao@rock-chips.com>
> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
> ---
>  drivers/gpu/drm/bridge/synopsys/Makefile     |   2 +-
>  drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c | 787 +++++++++++++++++++++++++
>  drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.h | 831 +++++++++++++++++++++++++++
>  include/drm/bridge/dw_hdmi.h                 |   8 +
>  4 files changed, 1627 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/bridge/synopsys/Makefile b/drivers/gpu/drm/bridge/synopsys/Makefile
> index ce715562e9e5..8354e4879f70 100644
> --- a/drivers/gpu/drm/bridge/synopsys/Makefile
> +++ b/drivers/gpu/drm/bridge/synopsys/Makefile

> +static int dw_hdmi_qp_i2c_read(struct dw_hdmi *hdmi,
> +			       unsigned char *buf, unsigned int length)
> +{
> +	struct dw_hdmi_i2c *i2c = hdmi->i2c;
> +	int stat;
> +
> +	if (!i2c->is_regaddr) {
> +		dev_dbg(hdmi->dev, "set read register address to 0\n");
> +		i2c->slave_reg = 0x00;
> +		i2c->is_regaddr = true;
> +	}
> +
> +	while (length--) {
> +		reinit_completion(&i2c->cmp);
> +
> +		dw_hdmi_qp_mod(hdmi, i2c->slave_reg++ << 12, I2CM_ADDR,
> +			       I2CM_INTERFACE_CONTROL0);
> +
> +		dw_hdmi_qp_mod(hdmi, I2CM_FM_READ, I2CM_WR_MASK,
> +			       I2CM_INTERFACE_CONTROL0);

Somehow the segment handling is present in the rest of the i2c code here, but
not the actual handling for reads.

The vendor-kernel does:

-               dw_hdmi_qp_mod(hdmi, I2CM_FM_READ, I2CM_WR_MASK,
-                              I2CM_INTERFACE_CONTROL0);
+               if (i2c->is_segment)
+                       dw_hdmi_qp_mod(hdmi, I2CM_EXT_READ, I2CM_WR_MASK,
+                                      I2CM_INTERFACE_CONTROL0);
+               else
+                       dw_hdmi_qp_mod(hdmi, I2CM_FM_READ, I2CM_WR_MASK,
+                                      I2CM_INTERFACE_CONTROL0);

Without this change, connecting to a DVI display does not work, and
reading the EDID ends in the "i2c read error" below.

Adding the segment handling as above makes the DVI connection
work (as it does in the vendor-kernel).

So it would be nice if you could maybe incorporate this in the next version?


Thanks
Heiko


> +
> +		stat = wait_for_completion_timeout(&i2c->cmp, HZ / 10);
> +		if (!stat) {
> +			dev_err(hdmi->dev, "i2c read timed out\n");
> +			dw_hdmi_qp_write(hdmi, 0x01, I2CM_CONTROL0);
> +			return -EAGAIN;
> +		}
> +
> +		/* Check for error condition on the bus */
> +		if (i2c->stat & I2CM_NACK_RCVD_IRQ) {
> +			dev_err(hdmi->dev, "i2c read error\n");
> +			dw_hdmi_qp_write(hdmi, 0x01, I2CM_CONTROL0);
> +			return -EIO;
> +		}
> +
> +		*buf++ = dw_hdmi_qp_read(hdmi, I2CM_INTERFACE_RDDATA_0_3) & 0xff;
> +		dw_hdmi_qp_mod(hdmi, 0, I2CM_WR_MASK, I2CM_INTERFACE_CONTROL0);
> +	}
> +
> +	i2c->is_segment = false;
> +
> +	return 0;
> +}




_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 13/14] drm/bridge: synopsys: Add DW HDMI QP TX controller driver

[Luis de Arquer]

On 6/5/24 16:48, Heiko Stübner wrote:
> Without this change, connecting to a DVI display does not work, and
> reading the EDID ends in the "i2c read error" below.

I had a lot of problems initially with the vendor driver on my DVI 
display, and am aware that several changes were required.

However, I tested Cristian patch and worked fine. All modes were 
apparently detected from the display and they all worked. But maybe I 
was just lucky and it was using a somehow cached table, I can't say.

This is an AOC DVI display from 2011 with a passive adapter.



Luis

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 13/14] drm/bridge: synopsys: Add DW HDMI QP TX controller driver

[Heiko Stübner]

Am Mittwoch, 5. Juni 2024, 21:58:23 CEST schrieb Luis de Arquer:
> On 6/5/24 16:48, Heiko Stübner wrote:
> > Without this change, connecting to a DVI display does not work, and
> > reading the EDID ends in the "i2c read error" below.
> 
> I had a lot of problems initially with the vendor driver on my DVI 
> display, and am aware that several changes were required.
> 
> However, I tested Cristian patch and worked fine. All modes were 
> apparently detected from the display and they all worked. But maybe I 
> was just lucky and it was using a somehow cached table, I can't say.
> 
> This is an AOC DVI display from 2011 with a passive adapter.

For me it is an LG IPS235. On its native hdmi input I always get regular
1080p output. But on its DVI input I always ran into the i2c read error
before adding that change.

I guess I should determine which reads actually fail.



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 12/14] dt-bindings: display: rockchip,dw-hdmi: Add compatible for RK3588

[Rob Herring]

On Sat, Jun 01, 2024 at 04:12:34PM +0300, Cristian Ciocaltea wrote:
> Document the Synopsys DesignWare HDMI 2.1 Quad-Pixel (QP) TX controller
> found on Rockchip RK3588 SoC family.
> 
> Since RK3588 uses different clocks than previous Rockchip SoCs and also
> requires a couple of reset lines and some additional properties, provide
> the required changes in the binding to accommodate all variants.
> 
> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
> ---
>  .../display/rockchip/rockchip,dw-hdmi.yaml         | 127 +++++++++++++++------
>  1 file changed, 90 insertions(+), 37 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
> index 2aac62219ff6..60d6b815227f 100644
> --- a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
> +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
> @@ -10,12 +10,10 @@ maintainers:
>    - Mark Yao <markyao0591@gmail.com>
>  
>  description: |
> -  The HDMI transmitter is a Synopsys DesignWare HDMI 1.4 TX controller IP
> -  with a companion PHY IP.
> -
> -allOf:
> -  - $ref: ../bridge/synopsys,dw-hdmi.yaml#
> -  - $ref: /schemas/sound/dai-common.yaml#
> +  For SoCs up to RK3568, the HDMI transmitter is a Synopsys DesignWare
> +  HDMI 1.4 TX controller IP with a companion PHY IP.
> +  The RK3588 SoC integrates the Synopsys DesignWare HDMI 2.1 Quad-Pixel (QP)
> +  TX controller IP and a HDMI/eDP TX Combo PHY based on a Samsung IP block.
>  
>  properties:
>    compatible:
> @@ -25,6 +23,7 @@ properties:
>        - rockchip,rk3328-dw-hdmi
>        - rockchip,rk3399-dw-hdmi
>        - rockchip,rk3568-dw-hdmi
> +      - rockchip,rk3588-dw-hdmi
>  
>    reg-io-width:
>      const: 4
> @@ -40,36 +39,6 @@ properties:
>        A 1.8V supply that powers up the SoC internal circuitry. The pin name on the
>        SoC usually is HDMI_TX_AVDD_1V8.
>  
> -  clocks:
> -    minItems: 2
> -    items:
> -      - {}
> -      - {}
> -      # The next three clocks are all optional, but shall be specified in this
> -      # order when present.
> -      - description: The HDMI CEC controller main clock
> -      - description: Power for GRF IO
> -      - description: External clock for some HDMI PHY (old clock name, deprecated)
> -      - description: External clock for some HDMI PHY (new name)
> -
> -  clock-names:
> -    minItems: 2
> -    items:
> -      - {}
> -      - {}
> -      - enum:
> -          - cec
> -          - grf
> -          - vpll
> -          - ref
> -      - enum:
> -          - grf
> -          - vpll
> -          - ref
> -      - enum:
> -          - vpll
> -          - ref
> -
>    ddc-i2c-bus:
>      $ref: /schemas/types.yaml#/definitions/phandle
>      description:
> @@ -131,13 +100,97 @@ properties:
>  required:
>    - compatible
>    - reg
> -  - reg-io-width
>    - clocks
>    - clock-names
>    - interrupts
>    - ports
>    - rockchip,grf
>  
> +allOf:
> +  - $ref: /schemas/sound/dai-common.yaml#
> +  - if:
> +      properties:
> +        compatible:
> +          contains:
> +            enum:
> +              - rockchip,rk3588-dw-hdmi
> +    then:
> +      properties:
> +        reg:
> +          maxItems: 1
> +
> +        clocks:
> +          minItems: 1
> +          items:
> +            - description: APB system interface clock
> +            # The next clocks are optional, but shall be specified in this
> +            # order when present.
> +            - description: TMDS/FRL link clock
> +            - description: EARC RX biphase clock
> +            - description: Reference clock
> +            - description: Audio interface clock
> +            - description: Video datapath clock
> +
> +        clock-names:
> +          minItems: 1
> +          items:
> +            - const: pclk
> +            - enum: [hdp, earc, ref, aud, hclk_vo1]
> +            - enum: [earc, ref, aud, hclk_vo1]
> +            - enum: [ref, aud, hclk_vo1]
> +            - enum: [aud, hclk_vo1]
> +            - const: hclk_vo1
> +
> +        resets:
> +          minItems: 2
> +          maxItems: 2
> +
> +        reset-names:
> +          items:
> +            - const: ref
> +            - const: hdp
> +
> +        interrupts:
> +          minItems: 1
> +          maxItems: 5
> +
> +        rockchip,vo1_grf:
> +          $ref: /schemas/types.yaml#/definitions/phandle
> +          description: Some QP related data is accessed through VO1 GRF regs
> +
> +      required:
> +        - resets
> +        - reset-names
> +        - rockchip,vo1_grf
> +
> +    else:
> +      $ref: ../bridge/synopsys,dw-hdmi.yaml#

This is odd... With this plus the amount of conditional schema, I think 
this should be a new schema doc. Doesn't have to have a common 
schema. You can let the 2nd user of this IP block do that. Though if you 
have the Synopsys spec, then it would be good to use it and be sure the 
binding corresponds to it.

Rob

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 13/14] drm/bridge: synopsys: Add DW HDMI QP TX controller driver

[Cristian Ciocaltea]

On 6/5/24 5:48 PM, Heiko Stübner wrote:
> Am Samstag, 1. Juni 2024, 15:12:35 CEST schrieb Cristian Ciocaltea:
>> The Synopsys DesignWare HDMI 2.1 Quad-Pixel (QP) TX controller supports
>> the following features, among others:
>>
>> * Fixed Rate Link (FRL)
>> * 4K@120Hz and 8K@60Hz video modes
>> * Variable Refresh Rate (VRR) including Quick Media Switching (QMS), aka
>>   Cinema VRR
>> * Fast Vactive (FVA), aka Quick Frame Transport (QFT)
>> * SCDC I2C DDC access
>> * TMDS Scrambler enabling 2160p@60Hz with RGB/YCbCr4:4:4
>> * YCbCr4:2:0 enabling 2160p@60Hz at lower HDMI link speeds
>> * Multi-stream audio
>> * Enhanced Audio Return Channel (EARC)
>>
>> Add driver to enable basic support, i.e. RGB output up to 4K@60Hz,
>> without audio, CEC or any HDMI 2.1 specific features.
>>
>> Co-developed-by: Algea Cao <algea.cao@rock-chips.com>
>> Signed-off-by: Algea Cao <algea.cao@rock-chips.com>
>> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
>> ---
>>  drivers/gpu/drm/bridge/synopsys/Makefile     |   2 +-
>>  drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c | 787 +++++++++++++++++++++++++
>>  drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.h | 831 +++++++++++++++++++++++++++
>>  include/drm/bridge/dw_hdmi.h                 |   8 +
>>  4 files changed, 1627 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/bridge/synopsys/Makefile b/drivers/gpu/drm/bridge/synopsys/Makefile
>> index ce715562e9e5..8354e4879f70 100644
>> --- a/drivers/gpu/drm/bridge/synopsys/Makefile
>> +++ b/drivers/gpu/drm/bridge/synopsys/Makefile
> 
>> +static int dw_hdmi_qp_i2c_read(struct dw_hdmi *hdmi,
>> +			       unsigned char *buf, unsigned int length)
>> +{
>> +	struct dw_hdmi_i2c *i2c = hdmi->i2c;
>> +	int stat;
>> +
>> +	if (!i2c->is_regaddr) {
>> +		dev_dbg(hdmi->dev, "set read register address to 0\n");
>> +		i2c->slave_reg = 0x00;
>> +		i2c->is_regaddr = true;
>> +	}
>> +
>> +	while (length--) {
>> +		reinit_completion(&i2c->cmp);
>> +
>> +		dw_hdmi_qp_mod(hdmi, i2c->slave_reg++ << 12, I2CM_ADDR,
>> +			       I2CM_INTERFACE_CONTROL0);
>> +
>> +		dw_hdmi_qp_mod(hdmi, I2CM_FM_READ, I2CM_WR_MASK,
>> +			       I2CM_INTERFACE_CONTROL0);
> 
> Somehow the segment handling is present in the rest of the i2c code here, but
> not the actual handling for reads.
> 
> The vendor-kernel does:
> 
> -               dw_hdmi_qp_mod(hdmi, I2CM_FM_READ, I2CM_WR_MASK,
> -                              I2CM_INTERFACE_CONTROL0);
> +               if (i2c->is_segment)
> +                       dw_hdmi_qp_mod(hdmi, I2CM_EXT_READ, I2CM_WR_MASK,
> +                                      I2CM_INTERFACE_CONTROL0);
> +               else
> +                       dw_hdmi_qp_mod(hdmi, I2CM_FM_READ, I2CM_WR_MASK,
> +                                      I2CM_INTERFACE_CONTROL0);

Hmm, for some reason this is not present in the stable-5.10-rock5 branch 
I've been using as an implementation reference:

https://github.com/radxa/kernel/blob/stable-5.10-rock5/drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c#L760

Is there an updated fork?

> Without this change, connecting to a DVI display does not work, and
> reading the EDID ends in the "i2c read error" below.
> 
> Adding the segment handling as above makes the DVI connection
> work (as it does in the vendor-kernel).
> 
> So it would be nice if you could maybe incorporate this in the next version?

Sure, thanks for pointing this out!

Cristian

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 13/14] drm/bridge: synopsys: Add DW HDMI QP TX controller driver

[Heiko Stübner]

Am Donnerstag, 6. Juni 2024, 11:53:23 CEST schrieb Cristian Ciocaltea:
> On 6/5/24 5:48 PM, Heiko Stübner wrote:
> > Am Samstag, 1. Juni 2024, 15:12:35 CEST schrieb Cristian Ciocaltea:
> >> The Synopsys DesignWare HDMI 2.1 Quad-Pixel (QP) TX controller supports
> >> the following features, among others:
> >>
> >> * Fixed Rate Link (FRL)
> >> * 4K@120Hz and 8K@60Hz video modes
> >> * Variable Refresh Rate (VRR) including Quick Media Switching (QMS), aka
> >>   Cinema VRR
> >> * Fast Vactive (FVA), aka Quick Frame Transport (QFT)
> >> * SCDC I2C DDC access
> >> * TMDS Scrambler enabling 2160p@60Hz with RGB/YCbCr4:4:4
> >> * YCbCr4:2:0 enabling 2160p@60Hz at lower HDMI link speeds
> >> * Multi-stream audio
> >> * Enhanced Audio Return Channel (EARC)
> >>
> >> Add driver to enable basic support, i.e. RGB output up to 4K@60Hz,
> >> without audio, CEC or any HDMI 2.1 specific features.
> >>
> >> Co-developed-by: Algea Cao <algea.cao@rock-chips.com>
> >> Signed-off-by: Algea Cao <algea.cao@rock-chips.com>
> >> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
> >> ---
> >>  drivers/gpu/drm/bridge/synopsys/Makefile     |   2 +-
> >>  drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c | 787 +++++++++++++++++++++++++
> >>  drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.h | 831 +++++++++++++++++++++++++++
> >>  include/drm/bridge/dw_hdmi.h                 |   8 +
> >>  4 files changed, 1627 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/gpu/drm/bridge/synopsys/Makefile b/drivers/gpu/drm/bridge/synopsys/Makefile
> >> index ce715562e9e5..8354e4879f70 100644
> >> --- a/drivers/gpu/drm/bridge/synopsys/Makefile
> >> +++ b/drivers/gpu/drm/bridge/synopsys/Makefile
> > 
> >> +static int dw_hdmi_qp_i2c_read(struct dw_hdmi *hdmi,
> >> +			       unsigned char *buf, unsigned int length)
> >> +{
> >> +	struct dw_hdmi_i2c *i2c = hdmi->i2c;
> >> +	int stat;
> >> +
> >> +	if (!i2c->is_regaddr) {
> >> +		dev_dbg(hdmi->dev, "set read register address to 0\n");
> >> +		i2c->slave_reg = 0x00;
> >> +		i2c->is_regaddr = true;
> >> +	}
> >> +
> >> +	while (length--) {
> >> +		reinit_completion(&i2c->cmp);
> >> +
> >> +		dw_hdmi_qp_mod(hdmi, i2c->slave_reg++ << 12, I2CM_ADDR,
> >> +			       I2CM_INTERFACE_CONTROL0);
> >> +
> >> +		dw_hdmi_qp_mod(hdmi, I2CM_FM_READ, I2CM_WR_MASK,
> >> +			       I2CM_INTERFACE_CONTROL0);
> > 
> > Somehow the segment handling is present in the rest of the i2c code here, but
> > not the actual handling for reads.
> > 
> > The vendor-kernel does:
> > 
> > -               dw_hdmi_qp_mod(hdmi, I2CM_FM_READ, I2CM_WR_MASK,
> > -                              I2CM_INTERFACE_CONTROL0);
> > +               if (i2c->is_segment)
> > +                       dw_hdmi_qp_mod(hdmi, I2CM_EXT_READ, I2CM_WR_MASK,
> > +                                      I2CM_INTERFACE_CONTROL0);
> > +               else
> > +                       dw_hdmi_qp_mod(hdmi, I2CM_FM_READ, I2CM_WR_MASK,
> > +                                      I2CM_INTERFACE_CONTROL0);
> 
> Hmm, for some reason this is not present in the stable-5.10-rock5 branch 
> I've been using as an implementation reference:
> 
> https://github.com/radxa/kernel/blob/stable-5.10-rock5/drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c#L760
> 
> Is there an updated fork?

I think the radxa code-base is quite old in terms of sdk-version it's based on.
Grabbing a 6.1 branch from Radxa shows it in:
https://github.com/radxa/kernel/blob/linux-6.1-stan-rkr1/drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c#L995

> > Without this change, connecting to a DVI display does not work, and
> > reading the EDID ends in the "i2c read error" below.
> > 
> > Adding the segment handling as above makes the DVI connection
> > work (as it does in the vendor-kernel).
> > 
> > So it would be nice if you could maybe incorporate this in the next version?
> 
> Sure, thanks for pointing this out!
> 
> Cristian
> 





_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 13/14] drm/bridge: synopsys: Add DW HDMI QP TX controller driver

[Cristian Ciocaltea]

On 6/6/24 1:16 PM, Heiko Stübner wrote:
> Am Donnerstag, 6. Juni 2024, 11:53:23 CEST schrieb Cristian Ciocaltea:
>> On 6/5/24 5:48 PM, Heiko Stübner wrote:
>>> Am Samstag, 1. Juni 2024, 15:12:35 CEST schrieb Cristian Ciocaltea:
>>>> The Synopsys DesignWare HDMI 2.1 Quad-Pixel (QP) TX controller supports
>>>> the following features, among others:
>>>>
>>>> * Fixed Rate Link (FRL)
>>>> * 4K@120Hz and 8K@60Hz video modes
>>>> * Variable Refresh Rate (VRR) including Quick Media Switching (QMS), aka
>>>>   Cinema VRR
>>>> * Fast Vactive (FVA), aka Quick Frame Transport (QFT)
>>>> * SCDC I2C DDC access
>>>> * TMDS Scrambler enabling 2160p@60Hz with RGB/YCbCr4:4:4
>>>> * YCbCr4:2:0 enabling 2160p@60Hz at lower HDMI link speeds
>>>> * Multi-stream audio
>>>> * Enhanced Audio Return Channel (EARC)
>>>>
>>>> Add driver to enable basic support, i.e. RGB output up to 4K@60Hz,
>>>> without audio, CEC or any HDMI 2.1 specific features.
>>>>
>>>> Co-developed-by: Algea Cao <algea.cao@rock-chips.com>
>>>> Signed-off-by: Algea Cao <algea.cao@rock-chips.com>
>>>> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
>>>> ---
>>>>  drivers/gpu/drm/bridge/synopsys/Makefile     |   2 +-
>>>>  drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c | 787 +++++++++++++++++++++++++
>>>>  drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.h | 831 +++++++++++++++++++++++++++
>>>>  include/drm/bridge/dw_hdmi.h                 |   8 +
>>>>  4 files changed, 1627 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/gpu/drm/bridge/synopsys/Makefile b/drivers/gpu/drm/bridge/synopsys/Makefile
>>>> index ce715562e9e5..8354e4879f70 100644
>>>> --- a/drivers/gpu/drm/bridge/synopsys/Makefile
>>>> +++ b/drivers/gpu/drm/bridge/synopsys/Makefile
>>>
>>>> +static int dw_hdmi_qp_i2c_read(struct dw_hdmi *hdmi,
>>>> +			       unsigned char *buf, unsigned int length)
>>>> +{
>>>> +	struct dw_hdmi_i2c *i2c = hdmi->i2c;
>>>> +	int stat;
>>>> +
>>>> +	if (!i2c->is_regaddr) {
>>>> +		dev_dbg(hdmi->dev, "set read register address to 0\n");
>>>> +		i2c->slave_reg = 0x00;
>>>> +		i2c->is_regaddr = true;
>>>> +	}
>>>> +
>>>> +	while (length--) {
>>>> +		reinit_completion(&i2c->cmp);
>>>> +
>>>> +		dw_hdmi_qp_mod(hdmi, i2c->slave_reg++ << 12, I2CM_ADDR,
>>>> +			       I2CM_INTERFACE_CONTROL0);
>>>> +
>>>> +		dw_hdmi_qp_mod(hdmi, I2CM_FM_READ, I2CM_WR_MASK,
>>>> +			       I2CM_INTERFACE_CONTROL0);
>>>
>>> Somehow the segment handling is present in the rest of the i2c code here, but
>>> not the actual handling for reads.
>>>
>>> The vendor-kernel does:
>>>
>>> -               dw_hdmi_qp_mod(hdmi, I2CM_FM_READ, I2CM_WR_MASK,
>>> -                              I2CM_INTERFACE_CONTROL0);
>>> +               if (i2c->is_segment)
>>> +                       dw_hdmi_qp_mod(hdmi, I2CM_EXT_READ, I2CM_WR_MASK,
>>> +                                      I2CM_INTERFACE_CONTROL0);
>>> +               else
>>> +                       dw_hdmi_qp_mod(hdmi, I2CM_FM_READ, I2CM_WR_MASK,
>>> +                                      I2CM_INTERFACE_CONTROL0);
>>
>> Hmm, for some reason this is not present in the stable-5.10-rock5 branch 
>> I've been using as an implementation reference:
>>
>> https://github.com/radxa/kernel/blob/stable-5.10-rock5/drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c#L760
>>
>> Is there an updated fork?
> 
> I think the radxa code-base is quite old in terms of sdk-version it's based on.
> Grabbing a 6.1 branch from Radxa shows it in:
> https://github.com/radxa/kernel/blob/linux-6.1-stan-rkr1/drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c#L995

Indeed, I should have switched to using this one as it seems to include 
quite a few potentially interesting updates (will check in detail for v2).

For now, we miss cdc0984c90dc ("drm/bridge: synopsys: dw-hdmi-qp: Support 
read ext block edid"), which provides an additional change:

@@ -1086,7 +1090,7 @@ static int dw_hdmi_i2c_xfer(struct i2c_adapter *adap,
                        i2c->is_segment = true;
                        hdmi_modb(hdmi, DDC_SEGMENT_ADDR, I2CM_SEG_ADDR,
                                  I2CM_INTERFACE_CONTROL1);
-                       hdmi_modb(hdmi, *msgs[i].buf, I2CM_SEG_PTR,
+                       hdmi_modb(hdmi, *msgs[i].buf << 7, I2CM_SEG_PTR,
                                  I2CM_INTERFACE_CONTROL1);
                } else {
                        if (msgs[i].flags & I2C_M_RD)

Will try to grab some more displays to improve testing on my end.

Thanks,
Cristian

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 12/14] dt-bindings: display: rockchip,dw-hdmi: Add compatible for RK3588

[Cristian Ciocaltea]

On 6/6/24 2:22 AM, Rob Herring wrote:
> On Sat, Jun 01, 2024 at 04:12:34PM +0300, Cristian Ciocaltea wrote:
>> Document the Synopsys DesignWare HDMI 2.1 Quad-Pixel (QP) TX controller
>> found on Rockchip RK3588 SoC family.
>>
>> Since RK3588 uses different clocks than previous Rockchip SoCs and also
>> requires a couple of reset lines and some additional properties, provide
>> the required changes in the binding to accommodate all variants.
>>
>> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
>> ---
>>  .../display/rockchip/rockchip,dw-hdmi.yaml         | 127 +++++++++++++++------
>>  1 file changed, 90 insertions(+), 37 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
>> index 2aac62219ff6..60d6b815227f 100644
>> --- a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
>> +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
>> @@ -10,12 +10,10 @@ maintainers:
>>    - Mark Yao <markyao0591@gmail.com>
>>  
>>  description: |
>> -  The HDMI transmitter is a Synopsys DesignWare HDMI 1.4 TX controller IP
>> -  with a companion PHY IP.
>> -
>> -allOf:
>> -  - $ref: ../bridge/synopsys,dw-hdmi.yaml#
>> -  - $ref: /schemas/sound/dai-common.yaml#
>> +  For SoCs up to RK3568, the HDMI transmitter is a Synopsys DesignWare
>> +  HDMI 1.4 TX controller IP with a companion PHY IP.
>> +  The RK3588 SoC integrates the Synopsys DesignWare HDMI 2.1 Quad-Pixel (QP)
>> +  TX controller IP and a HDMI/eDP TX Combo PHY based on a Samsung IP block.
>>  
>>  properties:
>>    compatible:
>> @@ -25,6 +23,7 @@ properties:
>>        - rockchip,rk3328-dw-hdmi
>>        - rockchip,rk3399-dw-hdmi
>>        - rockchip,rk3568-dw-hdmi
>> +      - rockchip,rk3588-dw-hdmi
>>  
>>    reg-io-width:
>>      const: 4
>> @@ -40,36 +39,6 @@ properties:
>>        A 1.8V supply that powers up the SoC internal circuitry. The pin name on the
>>        SoC usually is HDMI_TX_AVDD_1V8.
>>  
>> -  clocks:
>> -    minItems: 2
>> -    items:
>> -      - {}
>> -      - {}
>> -      # The next three clocks are all optional, but shall be specified in this
>> -      # order when present.
>> -      - description: The HDMI CEC controller main clock
>> -      - description: Power for GRF IO
>> -      - description: External clock for some HDMI PHY (old clock name, deprecated)
>> -      - description: External clock for some HDMI PHY (new name)
>> -
>> -  clock-names:
>> -    minItems: 2
>> -    items:
>> -      - {}
>> -      - {}
>> -      - enum:
>> -          - cec
>> -          - grf
>> -          - vpll
>> -          - ref
>> -      - enum:
>> -          - grf
>> -          - vpll
>> -          - ref
>> -      - enum:
>> -          - vpll
>> -          - ref
>> -
>>    ddc-i2c-bus:
>>      $ref: /schemas/types.yaml#/definitions/phandle
>>      description:
>> @@ -131,13 +100,97 @@ properties:
>>  required:
>>    - compatible
>>    - reg
>> -  - reg-io-width
>>    - clocks
>>    - clock-names
>>    - interrupts
>>    - ports
>>    - rockchip,grf
>>  
>> +allOf:
>> +  - $ref: /schemas/sound/dai-common.yaml#
>> +  - if:
>> +      properties:
>> +        compatible:
>> +          contains:
>> +            enum:
>> +              - rockchip,rk3588-dw-hdmi
>> +    then:
>> +      properties:
>> +        reg:
>> +          maxItems: 1
>> +
>> +        clocks:
>> +          minItems: 1
>> +          items:
>> +            - description: APB system interface clock
>> +            # The next clocks are optional, but shall be specified in this
>> +            # order when present.
>> +            - description: TMDS/FRL link clock
>> +            - description: EARC RX biphase clock
>> +            - description: Reference clock
>> +            - description: Audio interface clock
>> +            - description: Video datapath clock
>> +
>> +        clock-names:
>> +          minItems: 1
>> +          items:
>> +            - const: pclk
>> +            - enum: [hdp, earc, ref, aud, hclk_vo1]
>> +            - enum: [earc, ref, aud, hclk_vo1]
>> +            - enum: [ref, aud, hclk_vo1]
>> +            - enum: [aud, hclk_vo1]
>> +            - const: hclk_vo1
>> +
>> +        resets:
>> +          minItems: 2
>> +          maxItems: 2
>> +
>> +        reset-names:
>> +          items:
>> +            - const: ref
>> +            - const: hdp
>> +
>> +        interrupts:
>> +          minItems: 1
>> +          maxItems: 5
>> +
>> +        rockchip,vo1_grf:
>> +          $ref: /schemas/types.yaml#/definitions/phandle
>> +          description: Some QP related data is accessed through VO1 GRF regs
>> +
>> +      required:
>> +        - resets
>> +        - reset-names
>> +        - rockchip,vo1_grf
>> +
>> +    else:
>> +      $ref: ../bridge/synopsys,dw-hdmi.yaml#
> 
> This is odd... With this plus the amount of conditional schema, I think 
> this should be a new schema doc. Doesn't have to have a common 
> schema. You can let the 2nd user of this IP block do that. 

Yes, v2 is going to be a completely separated driver implementation.

> Though if you 
> have the Synopsys spec, then it would be good to use it and be sure the 
> binding corresponds to it.

Unfortunately I don't have it.

@Andy: Could you please help identifying the properties which should
belong to a common synopsys,dw-hdmi-qp schema?

Thanks,
Cristian

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 12/14] dt-bindings: display: rockchip,dw-hdmi: Add compatible for RK3588

[Rob Herring]

On Thu, Jun 6, 2024 at 5:51 AM Cristian Ciocaltea
<cristian.ciocaltea@collabora.com> wrote:
>
> On 6/6/24 2:22 AM, Rob Herring wrote:
> > On Sat, Jun 01, 2024 at 04:12:34PM +0300, Cristian Ciocaltea wrote:
> >> Document the Synopsys DesignWare HDMI 2.1 Quad-Pixel (QP) TX controller
> >> found on Rockchip RK3588 SoC family.
> >>
> >> Since RK3588 uses different clocks than previous Rockchip SoCs and also
> >> requires a couple of reset lines and some additional properties, provide
> >> the required changes in the binding to accommodate all variants.
> >>
> >> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
> >> ---
> >>  .../display/rockchip/rockchip,dw-hdmi.yaml         | 127 +++++++++++++++------
> >>  1 file changed, 90 insertions(+), 37 deletions(-)
> >>
> >> diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
> >> index 2aac62219ff6..60d6b815227f 100644
> >> --- a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
> >> +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
> >> @@ -10,12 +10,10 @@ maintainers:
> >>    - Mark Yao <markyao0591@gmail.com>
> >>
> >>  description: |
> >> -  The HDMI transmitter is a Synopsys DesignWare HDMI 1.4 TX controller IP
> >> -  with a companion PHY IP.
> >> -
> >> -allOf:
> >> -  - $ref: ../bridge/synopsys,dw-hdmi.yaml#
> >> -  - $ref: /schemas/sound/dai-common.yaml#
> >> +  For SoCs up to RK3568, the HDMI transmitter is a Synopsys DesignWare
> >> +  HDMI 1.4 TX controller IP with a companion PHY IP.
> >> +  The RK3588 SoC integrates the Synopsys DesignWare HDMI 2.1 Quad-Pixel (QP)
> >> +  TX controller IP and a HDMI/eDP TX Combo PHY based on a Samsung IP block.
> >>
> >>  properties:
> >>    compatible:
> >> @@ -25,6 +23,7 @@ properties:
> >>        - rockchip,rk3328-dw-hdmi
> >>        - rockchip,rk3399-dw-hdmi
> >>        - rockchip,rk3568-dw-hdmi
> >> +      - rockchip,rk3588-dw-hdmi
> >>
> >>    reg-io-width:
> >>      const: 4
> >> @@ -40,36 +39,6 @@ properties:
> >>        A 1.8V supply that powers up the SoC internal circuitry. The pin name on the
> >>        SoC usually is HDMI_TX_AVDD_1V8.
> >>
> >> -  clocks:
> >> -    minItems: 2
> >> -    items:
> >> -      - {}
> >> -      - {}
> >> -      # The next three clocks are all optional, but shall be specified in this
> >> -      # order when present.
> >> -      - description: The HDMI CEC controller main clock
> >> -      - description: Power for GRF IO
> >> -      - description: External clock for some HDMI PHY (old clock name, deprecated)
> >> -      - description: External clock for some HDMI PHY (new name)
> >> -
> >> -  clock-names:
> >> -    minItems: 2
> >> -    items:
> >> -      - {}
> >> -      - {}
> >> -      - enum:
> >> -          - cec
> >> -          - grf
> >> -          - vpll
> >> -          - ref
> >> -      - enum:
> >> -          - grf
> >> -          - vpll
> >> -          - ref
> >> -      - enum:
> >> -          - vpll
> >> -          - ref
> >> -
> >>    ddc-i2c-bus:
> >>      $ref: /schemas/types.yaml#/definitions/phandle
> >>      description:
> >> @@ -131,13 +100,97 @@ properties:
> >>  required:
> >>    - compatible
> >>    - reg
> >> -  - reg-io-width
> >>    - clocks
> >>    - clock-names
> >>    - interrupts
> >>    - ports
> >>    - rockchip,grf
> >>
> >> +allOf:
> >> +  - $ref: /schemas/sound/dai-common.yaml#
> >> +  - if:
> >> +      properties:
> >> +        compatible:
> >> +          contains:
> >> +            enum:
> >> +              - rockchip,rk3588-dw-hdmi
> >> +    then:
> >> +      properties:
> >> +        reg:
> >> +          maxItems: 1
> >> +
> >> +        clocks:
> >> +          minItems: 1
> >> +          items:
> >> +            - description: APB system interface clock
> >> +            # The next clocks are optional, but shall be specified in this
> >> +            # order when present.
> >> +            - description: TMDS/FRL link clock
> >> +            - description: EARC RX biphase clock
> >> +            - description: Reference clock
> >> +            - description: Audio interface clock
> >> +            - description: Video datapath clock
> >> +
> >> +        clock-names:
> >> +          minItems: 1
> >> +          items:
> >> +            - const: pclk
> >> +            - enum: [hdp, earc, ref, aud, hclk_vo1]
> >> +            - enum: [earc, ref, aud, hclk_vo1]
> >> +            - enum: [ref, aud, hclk_vo1]
> >> +            - enum: [aud, hclk_vo1]
> >> +            - const: hclk_vo1
> >> +
> >> +        resets:
> >> +          minItems: 2
> >> +          maxItems: 2
> >> +
> >> +        reset-names:
> >> +          items:
> >> +            - const: ref
> >> +            - const: hdp
> >> +
> >> +        interrupts:
> >> +          minItems: 1
> >> +          maxItems: 5
> >> +
> >> +        rockchip,vo1_grf:
> >> +          $ref: /schemas/types.yaml#/definitions/phandle
> >> +          description: Some QP related data is accessed through VO1 GRF regs
> >> +
> >> +      required:
> >> +        - resets
> >> +        - reset-names
> >> +        - rockchip,vo1_grf
> >> +
> >> +    else:
> >> +      $ref: ../bridge/synopsys,dw-hdmi.yaml#
> >
> > This is odd... With this plus the amount of conditional schema, I think
> > this should be a new schema doc. Doesn't have to have a common
> > schema. You can let the 2nd user of this IP block do that.
>
> Yes, v2 is going to be a completely separated driver implementation.

That actually has nothing to do with the decision here. Bindings are
separate from drivers.

Rob

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 12/14] dt-bindings: display: rockchip,dw-hdmi: Add compatible for RK3588

[Cristian Ciocaltea]

On 6/6/24 5:58 PM, Rob Herring wrote:
> On Thu, Jun 6, 2024 at 5:51 AM Cristian Ciocaltea
> <cristian.ciocaltea@collabora.com> wrote:
>>
>> On 6/6/24 2:22 AM, Rob Herring wrote:
>>> On Sat, Jun 01, 2024 at 04:12:34PM +0300, Cristian Ciocaltea wrote:
>>>> Document the Synopsys DesignWare HDMI 2.1 Quad-Pixel (QP) TX controller
>>>> found on Rockchip RK3588 SoC family.
>>>>
>>>> Since RK3588 uses different clocks than previous Rockchip SoCs and also
>>>> requires a couple of reset lines and some additional properties, provide
>>>> the required changes in the binding to accommodate all variants.
>>>>
>>>> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
>>>> ---
>>>>  .../display/rockchip/rockchip,dw-hdmi.yaml         | 127 +++++++++++++++------
>>>>  1 file changed, 90 insertions(+), 37 deletions(-)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
>>>> index 2aac62219ff6..60d6b815227f 100644
>>>> --- a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
>>>> +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
>>>> @@ -10,12 +10,10 @@ maintainers:
>>>>    - Mark Yao <markyao0591@gmail.com>
>>>>
>>>>  description: |
>>>> -  The HDMI transmitter is a Synopsys DesignWare HDMI 1.4 TX controller IP
>>>> -  with a companion PHY IP.
>>>> -
>>>> -allOf:
>>>> -  - $ref: ../bridge/synopsys,dw-hdmi.yaml#
>>>> -  - $ref: /schemas/sound/dai-common.yaml#
>>>> +  For SoCs up to RK3568, the HDMI transmitter is a Synopsys DesignWare
>>>> +  HDMI 1.4 TX controller IP with a companion PHY IP.
>>>> +  The RK3588 SoC integrates the Synopsys DesignWare HDMI 2.1 Quad-Pixel (QP)
>>>> +  TX controller IP and a HDMI/eDP TX Combo PHY based on a Samsung IP block.
>>>>
>>>>  properties:
>>>>    compatible:
>>>> @@ -25,6 +23,7 @@ properties:
>>>>        - rockchip,rk3328-dw-hdmi
>>>>        - rockchip,rk3399-dw-hdmi
>>>>        - rockchip,rk3568-dw-hdmi
>>>> +      - rockchip,rk3588-dw-hdmi
>>>>
>>>>    reg-io-width:
>>>>      const: 4
>>>> @@ -40,36 +39,6 @@ properties:
>>>>        A 1.8V supply that powers up the SoC internal circuitry. The pin name on the
>>>>        SoC usually is HDMI_TX_AVDD_1V8.
>>>>
>>>> -  clocks:
>>>> -    minItems: 2
>>>> -    items:
>>>> -      - {}
>>>> -      - {}
>>>> -      # The next three clocks are all optional, but shall be specified in this
>>>> -      # order when present.
>>>> -      - description: The HDMI CEC controller main clock
>>>> -      - description: Power for GRF IO
>>>> -      - description: External clock for some HDMI PHY (old clock name, deprecated)
>>>> -      - description: External clock for some HDMI PHY (new name)
>>>> -
>>>> -  clock-names:
>>>> -    minItems: 2
>>>> -    items:
>>>> -      - {}
>>>> -      - {}
>>>> -      - enum:
>>>> -          - cec
>>>> -          - grf
>>>> -          - vpll
>>>> -          - ref
>>>> -      - enum:
>>>> -          - grf
>>>> -          - vpll
>>>> -          - ref
>>>> -      - enum:
>>>> -          - vpll
>>>> -          - ref
>>>> -
>>>>    ddc-i2c-bus:
>>>>      $ref: /schemas/types.yaml#/definitions/phandle
>>>>      description:
>>>> @@ -131,13 +100,97 @@ properties:
>>>>  required:
>>>>    - compatible
>>>>    - reg
>>>> -  - reg-io-width
>>>>    - clocks
>>>>    - clock-names
>>>>    - interrupts
>>>>    - ports
>>>>    - rockchip,grf
>>>>
>>>> +allOf:
>>>> +  - $ref: /schemas/sound/dai-common.yaml#
>>>> +  - if:
>>>> +      properties:
>>>> +        compatible:
>>>> +          contains:
>>>> +            enum:
>>>> +              - rockchip,rk3588-dw-hdmi
>>>> +    then:
>>>> +      properties:
>>>> +        reg:
>>>> +          maxItems: 1
>>>> +
>>>> +        clocks:
>>>> +          minItems: 1
>>>> +          items:
>>>> +            - description: APB system interface clock
>>>> +            # The next clocks are optional, but shall be specified in this
>>>> +            # order when present.
>>>> +            - description: TMDS/FRL link clock
>>>> +            - description: EARC RX biphase clock
>>>> +            - description: Reference clock
>>>> +            - description: Audio interface clock
>>>> +            - description: Video datapath clock
>>>> +
>>>> +        clock-names:
>>>> +          minItems: 1
>>>> +          items:
>>>> +            - const: pclk
>>>> +            - enum: [hdp, earc, ref, aud, hclk_vo1]
>>>> +            - enum: [earc, ref, aud, hclk_vo1]
>>>> +            - enum: [ref, aud, hclk_vo1]
>>>> +            - enum: [aud, hclk_vo1]
>>>> +            - const: hclk_vo1
>>>> +
>>>> +        resets:
>>>> +          minItems: 2
>>>> +          maxItems: 2
>>>> +
>>>> +        reset-names:
>>>> +          items:
>>>> +            - const: ref
>>>> +            - const: hdp
>>>> +
>>>> +        interrupts:
>>>> +          minItems: 1
>>>> +          maxItems: 5
>>>> +
>>>> +        rockchip,vo1_grf:
>>>> +          $ref: /schemas/types.yaml#/definitions/phandle
>>>> +          description: Some QP related data is accessed through VO1 GRF regs
>>>> +
>>>> +      required:
>>>> +        - resets
>>>> +        - reset-names
>>>> +        - rockchip,vo1_grf
>>>> +
>>>> +    else:
>>>> +      $ref: ../bridge/synopsys,dw-hdmi.yaml#
>>>
>>> This is odd... With this plus the amount of conditional schema, I think
>>> this should be a new schema doc. Doesn't have to have a common
>>> schema. You can let the 2nd user of this IP block do that.
>>
>> Yes, v2 is going to be a completely separated driver implementation.
> 
> That actually has nothing to do with the decision here. Bindings are
> separate from drivers.

Right, I should have properly explained that initially this QP
controller has been handled more like another variant of those found in
the older SoCs, rather than a totally new one. It doesn't really have
anything in common, except that the IP comes from Synopsys, hence it
makes sense to also have a dedicated schema.

Thanks,
Cristian

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re:Re: [PATCH 13/14] drm/bridge: synopsys: Add DW HDMI QP TX controller driver

[Andy Yan]

Hi Neil，

At 2024-06-05 19:48:09, "Neil Armstrong" <neil.armstrong@linaro.org> wrote:
>On 05/06/2024 12:11, Cristian Ciocaltea wrote:
>> On 6/5/24 12:34 AM, Cristian Ciocaltea wrote:
>>> On 6/4/24 11:41 PM, Sam Ravnborg wrote:
>>>> Hi Cristian.
>>>>
>>>> On Tue, Jun 04, 2024 at 10:32:04PM +0300, Cristian Ciocaltea wrote:
>>>>> Hi Sam,
>>>>>
>>>>> On 6/1/24 5:32 PM, Sam Ravnborg wrote:
>>>>>> Hi Cristian,
>>>>>>
>>>>>> a few drive-by comments below.
>>>>>>
>>>>>> 	Sam
>>>>>>
>>>>>>
>>>>>>> +
>>>>>>> +static const struct drm_connector_funcs dw_hdmi_qp_connector_funcs = {
>>>>>>> +	.fill_modes = drm_helper_probe_single_connector_modes,
>>>>>>> +	.detect = dw_hdmi_connector_detect,
>>>>>>> +	.destroy = drm_connector_cleanup,
>>>>>>> +	.force = dw_hdmi_qp_connector_force,
>>>>>>> +	.reset = drm_atomic_helper_connector_reset,
>>>>>>> +	.atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
>>>>>>> +	.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
>>>>>>> +};
>>>>>>> +
>>>>>>> +static int dw_hdmi_qp_bridge_attach(struct drm_bridge *bridge,
>>>>>>> +				    enum drm_bridge_attach_flags flags)
>>>>>>> +{
>>>>>>> +	struct dw_hdmi *hdmi = bridge->driver_private;
>>>>>>> +
>>>>>>> +	if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)
>>>>>>> +		return drm_bridge_attach(bridge->encoder, hdmi->next_bridge,
>>>>>>> +					 bridge, flags);
>>>>>>> +
>>>>>>> +	return dw_hdmi_connector_create(hdmi, &dw_hdmi_qp_connector_funcs);
>>>>>>> +}
>>>>>>
>>>>>> Are there any users left that requires the display driver to create the
>>>>>> connector?
>>>>>> In other words - could this driver fail if DRM_BRIDGE_ATTACH_NO_CONNECTOR
>>>>>> is not passed and drop dw_hdmi_connector_create()?
>>>>>>
>>>>>> I did not try to verify this - just a naive question.
>>>>>
>>>>> I've just tested this and it doesn't work - dw_hdmi_connector_create()
>>>>> is still needed.
>>>>
>>>> Hmm, seems the display driver or some other bridge driver fails to
>>>> support "DRM_BRIDGE_ATTACH_NO_CONNECTOR".
>>>> what other drivers are involved?
>>>
>>> Could it be related to the glue driver (updated in the next patch) which
>>> is also responsible for setting up the encoder?
>>>
>>>> Note that my comments here should be seen as potential future
>>>> improvements, and do not block the patch from being used.
>>>
>>> Thanks for the heads up! Will try to get back to this soon and investigate.
>>   
>> IIUC, modern bridges should not create the connector but rely on display
>> drivers to take care of, which in this case is the VOP2 driver. However,
>> it also handles some of the older SoCs relying on the non-QP variant of
>> DW HDMI IP. Hence the existing dw-hdmi driver would be also impacted in
>> order to come up with a proper solution.
>> 
>> A quick check shows there are several users of this IP:
>> 
>> $ git grep -E '= dw_hdmi_(bind|probe)\('
>> drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx.c:    hdmi->dw_hdmi = dw_hdmi_probe(pdev, plat_data);
>> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c:      hdmi = dw_hdmi_probe(pdev, plat_data);
>> drivers/gpu/drm/imx/ipuv3/dw_hdmi-imx.c:        hdmi->hdmi = dw_hdmi_probe(pdev, match->data);
>> drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c:      hdmi = dw_hdmi_probe(pdev, &ingenic_dw_hdmi_plat_data);
>> drivers/gpu/drm/meson/meson_dw_hdmi.c:  meson_dw_hdmi->hdmi = dw_hdmi_probe(pdev, &meson_dw_hdmi->dw_plat_data);
>> drivers/gpu/drm/renesas/rcar-du/rcar_dw_hdmi.c: hdmi = dw_hdmi_probe(pdev, &rcar_dw_hdmi_plat_data);
>> drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c:            hdmi->hdmi = dw_hdmi_bind(pdev, encoder, plat_data);
>> drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c:  hdmi->hdmi = dw_hdmi_bind(pdev, encoder, plat_data);
>> 
>> I didn't check which display drivers would be involved, I'd guess there
>> are quite a few of them as well. So it seems this ends up being a pretty
>> complex task.
>
>If this would be a brand new driver, then it should only support DRM_BRIDGE_ATTACH_NO_CONNECTOR,
>so you should not create a connector from the driver.
>
>The fact dw-hdmi accepts an attach without the flag is for legacy purpose
>since some DRM drivers haven't switched to DRM_BRIDGE_ATTACH_NO_CONNECTOR yes,
>but it's a requirement for new bridges so at some point you'll need to make
>sure the rockchip glue and drm driver supports DRM_BRIDGE_ATTACH_NO_CONNECTOR.
>
>This will greatly simplify the driver!

Based on the previous discussion， the DW HDMI QP drivers will be implemented like this：

Core bridge library： 
 drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c
Rockchip platform specific glue：
drivers/gpu/drm/rockchip/dw_hdmi_qp-rockchip.c

As a new bridge driver should only support DRM_BRIDGE_ATTACH_NO_CONNECTOR, 
Is it acceptable if we implement the connector at  the rockchip glue dw_hdmi_qp-rockchip.c ？

Our current combination is a bit complex：
The display controller driver is  drivers/gpu/drm/rockchip/rockchip_drm_vop2.c ，which shared
by rk3568， rk3588 and some upcoming soc like rk3528/rk3562.

For rk3588， we have totally new HDMI、DP、DSI2  IP， they need brand new bridge driver that
should only support DRM_BRIDGE_ATTACH_NO_CONNECTOR， and there is also an eDP on rk3588
use analogix_dp_core.c that create connector by analogix_dp bridge。

For  rk3568， the HDMI/eDP/DSI IP are based on old IP， the corresponding drivers are dw-hdmi，analogix_dp
and dw-mipi-dsi, they both create drm connector by it's bridge driver. And rk3528/rk3562 are like this too。

So if we can create drm_connector at glue side (such as dw_hdmi_qp-rockchip.c), let the interface driver decide
if it should create drm_connector or not will make the vop2 driver simpler。





>
>Neil
>
>> 
>> Cristian

Re: [PATCH 13/14] drm/bridge: synopsys: Add DW HDMI QP TX controller driver

[Maxime Ripard]

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

Hi,

On Fri, Jun 14, 2024 at 02:56:00PM GMT, Andy Yan wrote:
> At 2024-06-05 19:48:09, "Neil Armstrong" <neil.armstrong@linaro.org> wrote:
> >On 05/06/2024 12:11, Cristian Ciocaltea wrote:
> >> On 6/5/24 12:34 AM, Cristian Ciocaltea wrote:
> >>> On 6/4/24 11:41 PM, Sam Ravnborg wrote:
> >>>> Hi Cristian.
> >>>>
> >>>> On Tue, Jun 04, 2024 at 10:32:04PM +0300, Cristian Ciocaltea wrote:
> >>>>> Hi Sam,
> >>>>>
> >>>>> On 6/1/24 5:32 PM, Sam Ravnborg wrote:
> >>>>>> Hi Cristian,
> >>>>>>
> >>>>>> a few drive-by comments below.
> >>>>>>
> >>>>>> 	Sam
> >>>>>>
> >>>>>>
> >>>>>>> +
> >>>>>>> +static const struct drm_connector_funcs dw_hdmi_qp_connector_funcs = {
> >>>>>>> +	.fill_modes = drm_helper_probe_single_connector_modes,
> >>>>>>> +	.detect = dw_hdmi_connector_detect,
> >>>>>>> +	.destroy = drm_connector_cleanup,
> >>>>>>> +	.force = dw_hdmi_qp_connector_force,
> >>>>>>> +	.reset = drm_atomic_helper_connector_reset,
> >>>>>>> +	.atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
> >>>>>>> +	.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
> >>>>>>> +};
> >>>>>>> +
> >>>>>>> +static int dw_hdmi_qp_bridge_attach(struct drm_bridge *bridge,
> >>>>>>> +				    enum drm_bridge_attach_flags flags)
> >>>>>>> +{
> >>>>>>> +	struct dw_hdmi *hdmi = bridge->driver_private;
> >>>>>>> +
> >>>>>>> +	if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)
> >>>>>>> +		return drm_bridge_attach(bridge->encoder, hdmi->next_bridge,
> >>>>>>> +					 bridge, flags);
> >>>>>>> +
> >>>>>>> +	return dw_hdmi_connector_create(hdmi, &dw_hdmi_qp_connector_funcs);
> >>>>>>> +}
> >>>>>>
> >>>>>> Are there any users left that requires the display driver to create the
> >>>>>> connector?
> >>>>>> In other words - could this driver fail if DRM_BRIDGE_ATTACH_NO_CONNECTOR
> >>>>>> is not passed and drop dw_hdmi_connector_create()?
> >>>>>>
> >>>>>> I did not try to verify this - just a naive question.
> >>>>>
> >>>>> I've just tested this and it doesn't work - dw_hdmi_connector_create()
> >>>>> is still needed.
> >>>>
> >>>> Hmm, seems the display driver or some other bridge driver fails to
> >>>> support "DRM_BRIDGE_ATTACH_NO_CONNECTOR".
> >>>> what other drivers are involved?
> >>>
> >>> Could it be related to the glue driver (updated in the next patch) which
> >>> is also responsible for setting up the encoder?
> >>>
> >>>> Note that my comments here should be seen as potential future
> >>>> improvements, and do not block the patch from being used.
> >>>
> >>> Thanks for the heads up! Will try to get back to this soon and investigate.
> >>   
> >> IIUC, modern bridges should not create the connector but rely on display
> >> drivers to take care of, which in this case is the VOP2 driver. However,
> >> it also handles some of the older SoCs relying on the non-QP variant of
> >> DW HDMI IP. Hence the existing dw-hdmi driver would be also impacted in
> >> order to come up with a proper solution.
> >> 
> >> A quick check shows there are several users of this IP:
> >> 
> >> $ git grep -E '= dw_hdmi_(bind|probe)\('
> >> drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx.c:    hdmi->dw_hdmi = dw_hdmi_probe(pdev, plat_data);
> >> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c:      hdmi = dw_hdmi_probe(pdev, plat_data);
> >> drivers/gpu/drm/imx/ipuv3/dw_hdmi-imx.c:        hdmi->hdmi = dw_hdmi_probe(pdev, match->data);
> >> drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c:      hdmi = dw_hdmi_probe(pdev, &ingenic_dw_hdmi_plat_data);
> >> drivers/gpu/drm/meson/meson_dw_hdmi.c:  meson_dw_hdmi->hdmi = dw_hdmi_probe(pdev, &meson_dw_hdmi->dw_plat_data);
> >> drivers/gpu/drm/renesas/rcar-du/rcar_dw_hdmi.c: hdmi = dw_hdmi_probe(pdev, &rcar_dw_hdmi_plat_data);
> >> drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c:            hdmi->hdmi = dw_hdmi_bind(pdev, encoder, plat_data);
> >> drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c:  hdmi->hdmi = dw_hdmi_bind(pdev, encoder, plat_data);
> >> 
> >> I didn't check which display drivers would be involved, I'd guess there
> >> are quite a few of them as well. So it seems this ends up being a pretty
> >> complex task.
> >
> >If this would be a brand new driver, then it should only support DRM_BRIDGE_ATTACH_NO_CONNECTOR,
> >so you should not create a connector from the driver.
> >
> >The fact dw-hdmi accepts an attach without the flag is for legacy purpose
> >since some DRM drivers haven't switched to DRM_BRIDGE_ATTACH_NO_CONNECTOR yes,
> >but it's a requirement for new bridges so at some point you'll need to make
> >sure the rockchip glue and drm driver supports DRM_BRIDGE_ATTACH_NO_CONNECTOR.
> >
> >This will greatly simplify the driver!
> 
> Based on the previous discussion， the DW HDMI QP drivers will be implemented like this：
> 
> Core bridge library： 
>  drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c
> Rockchip platform specific glue：
> drivers/gpu/drm/rockchip/dw_hdmi_qp-rockchip.c

Note that the bridge HDMI helpers Dmitry was mentioning have now been
merged, so I'd expect the core bridge library to be fairly minimal. And
the new driver should obviously use it as much as it can.

Maxime

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

Re: [PATCH 13/14] drm/bridge: synopsys: Add DW HDMI QP TX controller driver

[neil.armstrong]

On 14/06/2024 08:56, Andy Yan wrote:
> 
> 
> 
> 
> 
> 
> 
> Hi Neil，
> 
> At 2024-06-05 19:48:09, "Neil Armstrong" <neil.armstrong@linaro.org> wrote:
>> On 05/06/2024 12:11, Cristian Ciocaltea wrote:
>>> On 6/5/24 12:34 AM, Cristian Ciocaltea wrote:
>>>> On 6/4/24 11:41 PM, Sam Ravnborg wrote:
>>>>> Hi Cristian.
>>>>>
>>>>> On Tue, Jun 04, 2024 at 10:32:04PM +0300, Cristian Ciocaltea wrote:
>>>>>> Hi Sam,
>>>>>>
>>>>>> On 6/1/24 5:32 PM, Sam Ravnborg wrote:
>>>>>>> Hi Cristian,
>>>>>>>
>>>>>>> a few drive-by comments below.
>>>>>>>
>>>>>>> 	Sam
>>>>>>>
>>>>>>>
>>>>>>>> +
>>>>>>>> +static const struct drm_connector_funcs dw_hdmi_qp_connector_funcs = {
>>>>>>>> +	.fill_modes = drm_helper_probe_single_connector_modes,
>>>>>>>> +	.detect = dw_hdmi_connector_detect,
>>>>>>>> +	.destroy = drm_connector_cleanup,
>>>>>>>> +	.force = dw_hdmi_qp_connector_force,
>>>>>>>> +	.reset = drm_atomic_helper_connector_reset,
>>>>>>>> +	.atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
>>>>>>>> +	.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
>>>>>>>> +};
>>>>>>>> +
>>>>>>>> +static int dw_hdmi_qp_bridge_attach(struct drm_bridge *bridge,
>>>>>>>> +				    enum drm_bridge_attach_flags flags)
>>>>>>>> +{
>>>>>>>> +	struct dw_hdmi *hdmi = bridge->driver_private;
>>>>>>>> +
>>>>>>>> +	if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)
>>>>>>>> +		return drm_bridge_attach(bridge->encoder, hdmi->next_bridge,
>>>>>>>> +					 bridge, flags);
>>>>>>>> +
>>>>>>>> +	return dw_hdmi_connector_create(hdmi, &dw_hdmi_qp_connector_funcs);
>>>>>>>> +}
>>>>>>>
>>>>>>> Are there any users left that requires the display driver to create the
>>>>>>> connector?
>>>>>>> In other words - could this driver fail if DRM_BRIDGE_ATTACH_NO_CONNECTOR
>>>>>>> is not passed and drop dw_hdmi_connector_create()?
>>>>>>>
>>>>>>> I did not try to verify this - just a naive question.
>>>>>>
>>>>>> I've just tested this and it doesn't work - dw_hdmi_connector_create()
>>>>>> is still needed.
>>>>>
>>>>> Hmm, seems the display driver or some other bridge driver fails to
>>>>> support "DRM_BRIDGE_ATTACH_NO_CONNECTOR".
>>>>> what other drivers are involved?
>>>>
>>>> Could it be related to the glue driver (updated in the next patch) which
>>>> is also responsible for setting up the encoder?
>>>>
>>>>> Note that my comments here should be seen as potential future
>>>>> improvements, and do not block the patch from being used.
>>>>
>>>> Thanks for the heads up! Will try to get back to this soon and investigate.
>>>    
>>> IIUC, modern bridges should not create the connector but rely on display
>>> drivers to take care of, which in this case is the VOP2 driver. However,
>>> it also handles some of the older SoCs relying on the non-QP variant of
>>> DW HDMI IP. Hence the existing dw-hdmi driver would be also impacted in
>>> order to come up with a proper solution.
>>>
>>> A quick check shows there are several users of this IP:
>>>
>>> $ git grep -E '= dw_hdmi_(bind|probe)\('
>>> drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx.c:    hdmi->dw_hdmi = dw_hdmi_probe(pdev, plat_data);
>>> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c:      hdmi = dw_hdmi_probe(pdev, plat_data);
>>> drivers/gpu/drm/imx/ipuv3/dw_hdmi-imx.c:        hdmi->hdmi = dw_hdmi_probe(pdev, match->data);
>>> drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c:      hdmi = dw_hdmi_probe(pdev, &ingenic_dw_hdmi_plat_data);
>>> drivers/gpu/drm/meson/meson_dw_hdmi.c:  meson_dw_hdmi->hdmi = dw_hdmi_probe(pdev, &meson_dw_hdmi->dw_plat_data);
>>> drivers/gpu/drm/renesas/rcar-du/rcar_dw_hdmi.c: hdmi = dw_hdmi_probe(pdev, &rcar_dw_hdmi_plat_data);
>>> drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c:            hdmi->hdmi = dw_hdmi_bind(pdev, encoder, plat_data);
>>> drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c:  hdmi->hdmi = dw_hdmi_bind(pdev, encoder, plat_data);
>>>
>>> I didn't check which display drivers would be involved, I'd guess there
>>> are quite a few of them as well. So it seems this ends up being a pretty
>>> complex task.
>>
>> If this would be a brand new driver, then it should only support DRM_BRIDGE_ATTACH_NO_CONNECTOR,
>> so you should not create a connector from the driver.
>>
>> The fact dw-hdmi accepts an attach without the flag is for legacy purpose
>> since some DRM drivers haven't switched to DRM_BRIDGE_ATTACH_NO_CONNECTOR yes,
>> but it's a requirement for new bridges so at some point you'll need to make
>> sure the rockchip glue and drm driver supports DRM_BRIDGE_ATTACH_NO_CONNECTOR.
>>
>> This will greatly simplify the driver!
> 
> Based on the previous discussion， the DW HDMI QP drivers will be implemented like this：
> 
> Core bridge library：
>   drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c
> Rockchip platform specific glue：
> drivers/gpu/drm/rockchip/dw_hdmi_qp-rockchip.c
> 
> As a new bridge driver should only support DRM_BRIDGE_ATTACH_NO_CONNECTOR,
> Is it acceptable if we implement the connector at  the rockchip glue dw_hdmi_qp-rockchip.c ？
> 
> Our current combination is a bit complex：
> The display controller driver is  drivers/gpu/drm/rockchip/rockchip_drm_vop2.c ，which shared
> by rk3568， rk3588 and some upcoming soc like rk3528/rk3562.
> 
> For rk3588， we have totally new HDMI、DP、DSI2  IP， they need brand new bridge driver that
> should only support DRM_BRIDGE_ATTACH_NO_CONNECTOR， and there is also an eDP on rk3588
> use analogix_dp_core.c that create connector by analogix_dp bridge。
> 
> For  rk3568， the HDMI/eDP/DSI IP are based on old IP， the corresponding drivers are dw-hdmi，analogix_dp
> and dw-mipi-dsi, they both create drm connector by it's bridge driver. And rk3528/rk3562 are like this too。
> 
> So if we can create drm_connector at glue side (such as dw_hdmi_qp-rockchip.c), let the interface driver decide
> if it should create drm_connector or not will make the vop2 driver simpler。

I think you should start migration to drm_bridge_connector instead of hacking dw_hdmi_qp-rockchip.c into
fitting into DRM_BRIDGE_ATTACH_NO_CONNECTOR.

You'll add technical dept, and the migration will be even harder afterwards.

But in any case, bridge/synopsys/dw-hdmi-qp.c and rockchip/dw_hdmi_qp-rockchip.c should be send
in two separate patchsets, so how rockchip DRM_BRIDGE_ATTACH_NO_CONNECTOR is a different story.

Neil

> 
> 
> 
> 
> 
>>
>> Neil
>>
>>>
>>> Cristian

Re: [PATCH 00/14] Add initial support for the Rockchip RK3588 HDMI TX Controller

[Piotr Oniszczuk]

Cristian,

I'm hacking with adding cec support for rk3588 hdmi on 6.10-rc7 mainline. 

Cec kernel module is my backport from bsp. 
Module loads. Cec line (observed on osciloscope) has pulses when i'm issuing i.e. cec-ctl -d /dev/cec0 --phys-addr=1.0.0.0 —playback 

My issue is that timings are 2,9 times longer that should be (start bit is 10,7mS instead of 3.6; zero is 4.4 instead 1.5 while one is 1,7 instead of 0.6).

This suggests me issue is cec clock isn't? 

Looking on bsp code https://github.com/radxa/kernel/blob/linux-6.1-stan-rkr1/drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp-cec.c#L186 there is nothing with clock. 

So probably issue is in 3588 clk code, or……
Maybe you have some hints how to move forward with this issue?


> Wiadomość napisana przez Cristian Ciocaltea <cristian.ciocaltea@collabora.com> w dniu 01.06.2024, o godz. 15:12:
> 
> The RK3588 SoC family integrates a Quad-Pixel (QP) variant of the
> Synopsys DesignWare HDMI TX controller used in the previous SoCs.
> 
> It is HDMI 2.1 compliant and supports the following features, among
> others:
> 
> * Fixed Rate Link (FRL)
> * 4K@120Hz and 8K@60Hz video modes
> * Variable Refresh Rate (VRR) including Quick Media Switching (QMS)
> * Fast Vactive (FVA)
> * SCDC I2C DDC access
> * TMDS Scrambler enabling 2160p@60Hz with RGB/YCbCr4:4:4
> * YCbCr4:2:0 enabling 2160p@60Hz at lower HDMI link speeds
> * Multi-stream audio
> * Enhanced Audio Return Channel (EARC)
> 
> This is the last required component that needs to be supported in order
> to enable the HDMI output functionality on the RK3588 based SBCs, such
> as the RADXA Rock 5B. The other components are the Video Output
> Processor (VOP2) and the Samsung IP based HDMI/eDP TX Combo PHY, for
> which basic support has been already made available via [1] and [2],
> respectively.
> 
> The patches are grouped as follows:
> * PATCH 1..7: DW HDMI TX driver refactor to minimize code duplication in
>  the new QP driver (no functional changes intended)
> 
> * PATCH 8..11: Rockchip DW HDMI glue driver cleanup/improvements (no
>  functional changes intended)
> 
> * PATCH 12..13: The new DW HDMI QP TX driver reusing the previously
>  exported functions and structs from existing DW HDMI TX driver
> 
> * PATCH 14: Rockchip DW HDMI glue driver update to support RK3588 and
>  make use of DW HDMI QP TX
> 
> They provide just the basic HDMI support for now, i.e. RGB output up to
> 4K@60Hz, without audio, CEC or any of the HDMI 2.1 specific features.
> Also note the vop2 driver is currently not able to properly handle all
> display modes supported by the connected screens, e.g. it doesn't cope
> with non-integer refresh rates.
> 
> A possible workaround consists of enabling the display controller to
> make use of the clock provided by the HDMI PHY PLL. This is still work
> in progress and will be submitted later, as well as the required DTS
> updates.
> 
> To facilitate testing and experimentation, all HDMI output related
> patches, including those part of this series, are available at [3].
> So far I could only verify this on the RADXA Rock 3A and 5B boards.
> 
> Thanks,
> Cristian
> 
> [1]: 5a028e8f062f ("drm/rockchip: vop2: Add support for rk3588")
> [2]: 553be2830c5f ("phy: rockchip: Add Samsung HDMI/eDP Combo PHY driver")
> [3]: https://gitlab.collabora.com/hardware-enablement/rockchip-3588/linux/-/commits/rk3588-hdmi-bridge-v6.10-rc1
> 
> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
> ---
> Cristian Ciocaltea (14):
>      drm/bridge: dw-hdmi: Simplify clock handling
>      drm/bridge: dw-hdmi: Add dw-hdmi-common.h header
>      drm/bridge: dw-hdmi: Commonize dw_hdmi_i2c_adapter()
>      drm/bridge: dw-hdmi: Factor out AVI infoframe setup
>      drm/bridge: dw-hdmi: Factor out vmode setup
>      drm/bridge: dw-hdmi: Factor out hdmi_data_info setup
>      drm/bridge: dw-hdmi: Commonize dw_hdmi_connector_create()
>      drm/rockchip: dw_hdmi: Use modern drm_device based logging
>      drm/rockchip: dw_hdmi: Simplify clock handling
>      drm/rockchip: dw_hdmi: Use devm_regulator_get_enable()
>      drm/rockchip: dw_hdmi: Drop superfluous assignments of mpll_cfg, cur_ctr and phy_config
>      dt-bindings: display: rockchip,dw-hdmi: Add compatible for RK3588
>      drm/bridge: synopsys: Add DW HDMI QP TX controller driver
>      drm/rockchip: dw_hdmi: Add basic RK3588 support
> 
> .../display/rockchip/rockchip,dw-hdmi.yaml         | 127 +++-
> drivers/gpu/drm/bridge/synopsys/Makefile           |   2 +-
> drivers/gpu/drm/bridge/synopsys/dw-hdmi-common.h   | 179 +++++
> drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c       | 787 +++++++++++++++++++
> drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.h       | 831 +++++++++++++++++++++
> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c          | 353 +++------
> drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c        | 351 +++++++--
> include/drm/bridge/dw_hdmi.h                       |   8 +
> 8 files changed, 2290 insertions(+), 348 deletions(-)
> ---
> base-commit: 1613e604df0cd359cf2a7fbd9be7a0bcfacfabd0
> change-id: 20240601-b4-rk3588-bridge-upstream-a27baff1b8fc
> 
> 
> _______________________________________________
> Linux-rockchip mailing list
> Linux-rockchip@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip

Re: [PATCH 12/14] dt-bindings: display: rockchip,dw-hdmi: Add compatible for RK3588

[Andy Yan]

Hi Cristian,

On 6/6/24 19:51, Cristian Ciocaltea wrote:
> On 6/6/24 2:22 AM, Rob Herring wrote:
>> On Sat, Jun 01, 2024 at 04:12:34PM +0300, Cristian Ciocaltea wrote:
>>> Document the Synopsys DesignWare HDMI 2.1 Quad-Pixel (QP) TX controller
>>> found on Rockchip RK3588 SoC family.
>>>
>>> Since RK3588 uses different clocks than previous Rockchip SoCs and also
>>> requires a couple of reset lines and some additional properties, provide
>>> the required changes in the binding to accommodate all variants.
>>>
>>> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
>>> ---
>>>   .../display/rockchip/rockchip,dw-hdmi.yaml         | 127 +++++++++++++++------
>>>   1 file changed, 90 insertions(+), 37 deletions(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
>>> index 2aac62219ff6..60d6b815227f 100644
>>> --- a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
>>> +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
>>> @@ -10,12 +10,10 @@ maintainers:
>>>     - Mark Yao <markyao0591@gmail.com>
>>>   
>>>   description: |
>>> -  The HDMI transmitter is a Synopsys DesignWare HDMI 1.4 TX controller IP
>>> -  with a companion PHY IP.
>>> -
>>> -allOf:
>>> -  - $ref: ../bridge/synopsys,dw-hdmi.yaml#
>>> -  - $ref: /schemas/sound/dai-common.yaml#
>>> +  For SoCs up to RK3568, the HDMI transmitter is a Synopsys DesignWare
>>> +  HDMI 1.4 TX controller IP with a companion PHY IP.
>>> +  The RK3588 SoC integrates the Synopsys DesignWare HDMI 2.1 Quad-Pixel (QP)
>>> +  TX controller IP and a HDMI/eDP TX Combo PHY based on a Samsung IP block.
>>>   
>>>   properties:
>>>     compatible:
>>> @@ -25,6 +23,7 @@ properties:
>>>         - rockchip,rk3328-dw-hdmi
>>>         - rockchip,rk3399-dw-hdmi
>>>         - rockchip,rk3568-dw-hdmi
>>> +      - rockchip,rk3588-dw-hdmi
>>>   
>>>     reg-io-width:
>>>       const: 4
>>> @@ -40,36 +39,6 @@ properties:
>>>         A 1.8V supply that powers up the SoC internal circuitry. The pin name on the
>>>         SoC usually is HDMI_TX_AVDD_1V8.
>>>   
>>> -  clocks:
>>> -    minItems: 2
>>> -    items:
>>> -      - {}
>>> -      - {}
>>> -      # The next three clocks are all optional, but shall be specified in this
>>> -      # order when present.
>>> -      - description: The HDMI CEC controller main clock
>>> -      - description: Power for GRF IO
>>> -      - description: External clock for some HDMI PHY (old clock name, deprecated)
>>> -      - description: External clock for some HDMI PHY (new name)
>>> -
>>> -  clock-names:
>>> -    minItems: 2
>>> -    items:
>>> -      - {}
>>> -      - {}
>>> -      - enum:
>>> -          - cec
>>> -          - grf
>>> -          - vpll
>>> -          - ref
>>> -      - enum:
>>> -          - grf
>>> -          - vpll
>>> -          - ref
>>> -      - enum:
>>> -          - vpll
>>> -          - ref
>>> -
>>>     ddc-i2c-bus:
>>>       $ref: /schemas/types.yaml#/definitions/phandle
>>>       description:
>>> @@ -131,13 +100,97 @@ properties:
>>>   required:
>>>     - compatible
>>>     - reg
>>> -  - reg-io-width
>>>     - clocks
>>>     - clock-names
>>>     - interrupts
>>>     - ports
>>>     - rockchip,grf
>>>   
>>> +allOf:
>>> +  - $ref: /schemas/sound/dai-common.yaml#
>>> +  - if:
>>> +      properties:
>>> +        compatible:
>>> +          contains:
>>> +            enum:
>>> +              - rockchip,rk3588-dw-hdmi
>>> +    then:
>>> +      properties:
>>> +        reg:
>>> +          maxItems: 1
>>> +
>>> +        clocks:
>>> +          minItems: 1
>>> +          items:
>>> +            - description: APB system interface clock
>>> +            # The next clocks are optional, but shall be specified in this
>>> +            # order when present.
>>> +            - description: TMDS/FRL link clock
>>> +            - description: EARC RX biphase clock
>>> +            - description: Reference clock
>>> +            - description: Audio interface clock
>>> +            - description: Video datapath clock
>>> +
>>> +        clock-names:
>>> +          minItems: 1
>>> +          items:
>>> +            - const: pclk
>>> +            - enum: [hdp, earc, ref, aud, hclk_vo1]
>>> +            - enum: [earc, ref, aud, hclk_vo1]
>>> +            - enum: [ref, aud, hclk_vo1]
>>> +            - enum: [aud, hclk_vo1]
>>> +            - const: hclk_vo1


For all of these clks:pclk, earc,ref, aud are common clk interface which are belong to synopsys,dw-hdmi-qp
hdp and hclk_vo are rockchip platform specific.

>>> +
>>> +        resets:
>>> +          minItems: 2
>>> +          maxItems: 2
>>> +
>>> +        reset-names:
>>> +          items:
>>> +            - const: ref
>>> +            - const: hdp
>>> +
>>> +        interrupts:
>>> +          minItems: 1
>>> +          maxItems: 5
>>> +
>>> +        rockchip,vo1_grf:
>>> +          $ref: /schemas/types.yaml#/definitions/phandle
>>> +          description: Some QP related data is accessed through VO1 GRF regs
>>> +
>>> +      required:
>>> +        - resets
>>> +        - reset-names
>>> +        - rockchip,vo1_grf
>>> +
>>> +    else:
>>> +      $ref: ../bridge/synopsys,dw-hdmi.yaml#
>>
>> This is odd... With this plus the amount of conditional schema, I think
>> this should be a new schema doc. Doesn't have to have a common
>> schema. You can let the 2nd user of this IP block do that.
> 
> Yes, v2 is going to be a completely separated driver implementation.
> 
>> Though if you
>> have the Synopsys spec, then it would be good to use it and be sure the
>> binding corresponds to it.
> 
> Unfortunately I don't have it.
> 
> @Andy: Could you please help identifying the properties which should
> belong to a common synopsys,dw-hdmi-qp schema?
> 
> Thanks,
> Cristian
> 
> _______________________________________________
> Linux-rockchip mailing list
> Linux-rockchip@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip