From: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
To: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Cc: "Andrzej Hajda" <andrzej.hajda@intel.com>,
"Neil Armstrong" <neil.armstrong@linaro.org>,
"Robert Foss" <rfoss@kernel.org>,
"Laurent Pinchart" <Laurent.pinchart@ideasonboard.com>,
"Jonas Karlman" <jonas@kwiboo.se>,
"Jernej Skrabec" <jernej.skrabec@gmail.com>,
"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
"Maxime Ripard" <mripard@kernel.org>,
"Thomas Zimmermann" <tzimmermann@suse.de>,
"David Airlie" <airlied@gmail.com>,
"Simona Vetter" <simona@ffwll.ch>,
"Sandy Huang" <hjc@rock-chips.com>,
"Heiko Stübner" <heiko@sntech.de>,
"Andy Yan" <andy.yan@rock-chips.com>,
kernel@collabora.com, dri-devel@lists.freedesktop.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-rockchip@lists.infradead.org,
"Diederik de Haas" <diederik@cknow-tech.com>,
"Maud Spierings" <maud_spierings@hotmail.com>
Subject: Re: [PATCH v5 05/10] drm/bridge: dw-hdmi-qp: Add HDMI 2.0 SCDC scrambling and high TMDS clock ratio support
Date: Tue, 28 Apr 2026 16:51:46 +0300 [thread overview]
Message-ID: <539f1bb9-6509-40c7-8692-bb3cdee33f91@collabora.com> (raw)
In-Reply-To: <m5fxlfktxtvki5yaxhkx4h3hsjj5266stwvfdykhqkgcjbz5bk@s5gggcd45abm>
Hi Dmitry,
Thanks for taking the time to review the series!
On 4/28/26 4:38 AM, Dmitry Baryshkov wrote:
> On Sun, Apr 26, 2026 at 03:20:17AM +0300, Cristian Ciocaltea wrote:
>> Enable HDMI 2.0 display modes (e.g. 4K@60Hz) by adding SCDC management
>> for the high TMDS clock ratio and scrambling, required when the TMDS
>> character rate exceeds the 340 MHz HDMI 1.4b limit.
>>
>> A periodic work item monitors the sink's scrambling status to recover
>> from sink-side resets. On hotplug detect, if SCDC scrambling state is
>> out of sync with the driver, trigger a CRTC reset to re-establish the
>> link.
>>
>> Reject modes requiring TMDS rates above 600 MHz, as those fall in the
>> HDMI 2.1 FRL domain which is not supported. In no_hpd configurations,
>> further restrict to 340 MHz since SCDC requires a connected sink.
>>
>> Tested-by: Diederik de Haas <diederik@cknow-tech.com>
>> Tested-by: Maud Spierings <maud_spierings@hotmail.com>
>> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
>> ---
>> drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c | 188 ++++++++++++++++++++++++---
>> 1 file changed, 172 insertions(+), 16 deletions(-)
>
> My main issue with this patch (sorry) is that this adds yet another copy
> of SCDC-related helpers into the driver which already OP_HDMI and other
> helpers.
>
>> @@ -39,7 +42,9 @@
>> #define DDC_SEGMENT_ADDR 0x30
>>
>> #define HDMI14_MAX_TMDSCLK 340000000
>> +#define HDMI20_MAX_TMDSRATE 600000000
>>
>> +#define SCDC_MAX_SOURCE_VERSION 0x1
>> #define SCRAMB_POLL_DELAY_MS 3000
>>
>> /*
>> @@ -164,6 +169,11 @@ struct dw_hdmi_qp {
>> } phy;
>>
>> unsigned long ref_clk_rate;
>> +
>> + struct drm_connector *curr_conn;
>> + struct delayed_work scramb_work;
>> + bool scramb_enabled;
>
> s/scramb/scrambler/
>
> Can we move those two to the drm_connector_hdmi
Sure, will do.
>> +
>> struct regmap *regm;
>> int main_irq;
>>
>> @@ -749,28 +759,124 @@ static struct i2c_adapter *dw_hdmi_qp_i2c_adapter(struct dw_hdmi_qp *hdmi)
>> return adap;
>> }
>>
>> +static bool dw_hdmi_qp_supports_scrambling(struct drm_display_info *display)
>> +{
>> + if (!display->is_hdmi)
>> + return false;
>> +
>> + return display->hdmi.scdc.supported &&
>> + display->hdmi.scdc.scrambling.supported;
>> +}
>> +
>> +static int dw_hdmi_qp_set_scramb(struct dw_hdmi_qp *hdmi)
>> +{
>> + bool done;
>> +
>> + dev_dbg(hdmi->dev, "set scrambling\n");
>> +
>> + done = drm_scdc_set_high_tmds_clock_ratio(hdmi->curr_conn, true);
>> + if (!done)
>> + return -EIO;
>> +
>> + done = drm_scdc_set_scrambling(hdmi->curr_conn, true);
>> + if (!done) {
>> + drm_scdc_set_high_tmds_clock_ratio(hdmi->curr_conn, false);
>> + return -EIO;
>> + }
>> +
>> + schedule_delayed_work(&hdmi->scramb_work,
>> + msecs_to_jiffies(SCRAMB_POLL_DELAY_MS));
>> + return 0;
>> +}
>> +
>> +static void dw_hdmi_qp_scramb_work(struct work_struct *work)
>> +{
>> + struct dw_hdmi_qp *hdmi = container_of(to_delayed_work(work),
>> + struct dw_hdmi_qp,
>> + scramb_work);
>> + if (READ_ONCE(hdmi->scramb_enabled) &&
>> + !drm_scdc_get_scrambling_status(hdmi->curr_conn))
>> + dw_hdmi_qp_set_scramb(hdmi);
>> +}
>> +
>> +static void dw_hdmi_qp_enable_scramb(struct dw_hdmi_qp *hdmi)
>> +{
>> + int ret;
>> + u8 ver;
>> +
>> + if (!dw_hdmi_qp_supports_scrambling(&hdmi->curr_conn->display_info))
>> + return;
>> +
>> + ret = drm_scdc_readb(hdmi->bridge.ddc, SCDC_SINK_VERSION, &ver);
>> + if (ret) {
>> + dev_err(hdmi->dev, "Failed to read SCDC_SINK_VERSION: %d\n", ret);
>> + return;
>> + }
>> +
>> + ret = drm_scdc_writeb(hdmi->bridge.ddc, SCDC_SOURCE_VERSION,
>> + min_t(u8, ver, SCDC_MAX_SOURCE_VERSION));
>> + if (ret) {
>> + dev_err(hdmi->dev, "Failed to write SCDC_SOURCE_VERSION: %d\n", ret);
>> + return;
>> + }
>> +
>> + WRITE_ONCE(hdmi->scramb_enabled, true);
>> +
>> + ret = dw_hdmi_qp_set_scramb(hdmi);
>> + if (ret) {
>> + hdmi->scramb_enabled = false;
>> + return;
>> + }
>> +
>> + dw_hdmi_qp_write(hdmi, 1, SCRAMB_CONFIG0);
>> +
>> + /* Wait at least 1 ms before resuming TMDS transmission */
>> + usleep_range(1000, 5000);
>> +}
>> +
>> +static void dw_hdmi_qp_disable_scramb(struct dw_hdmi_qp *hdmi)
>> +{
>> + if (!hdmi->scramb_enabled)
>> + return;
>> +
>> + dev_dbg(hdmi->dev, "disable scrambling\n");
>> +
>> + WRITE_ONCE(hdmi->scramb_enabled, false);
>> + cancel_delayed_work_sync(&hdmi->scramb_work);
>> +
>> + dw_hdmi_qp_write(hdmi, 0, SCRAMB_CONFIG0);
>> +
>> + if (hdmi->curr_conn->status == connector_status_connected) {
>> + drm_scdc_set_scrambling(hdmi->curr_conn, false);
>> + drm_scdc_set_high_tmds_clock_ratio(hdmi->curr_conn, false);
>> + }
>> +}
>
> All of these feel like generic helpers.
I'll factor these out.
>> +
>> static void dw_hdmi_qp_bridge_atomic_enable(struct drm_bridge *bridge,
>> struct drm_atomic_state *state)
>> {
>> struct dw_hdmi_qp *hdmi = bridge->driver_private;
>> struct drm_connector_state *conn_state;
>> - struct drm_connector *connector;
>> unsigned int op_mode;
>>
>> - connector = drm_atomic_get_new_connector_for_encoder(state, bridge->encoder);
>> - if (WARN_ON(!connector))
>> + hdmi->curr_conn = drm_atomic_get_new_connector_for_encoder(state,
>> + bridge->encoder);
>> + if (WARN_ON(!hdmi->curr_conn))
>> return;
>>
>> - conn_state = drm_atomic_get_new_connector_state(state, connector);
>> + conn_state = drm_atomic_get_new_connector_state(state, hdmi->curr_conn);
>> if (WARN_ON(!conn_state))
>> return;
>>
>> - if (connector->display_info.is_hdmi) {
>> + if (hdmi->curr_conn->display_info.is_hdmi) {
>> dev_dbg(hdmi->dev, "%s mode=HDMI %s rate=%llu bpc=%u\n", __func__,
>> drm_hdmi_connector_get_output_format_name(conn_state->hdmi.output_format),
>> conn_state->hdmi.tmds_char_rate, conn_state->hdmi.output_bpc);
>> op_mode = 0;
>> hdmi->tmds_char_rate = conn_state->hdmi.tmds_char_rate;
>> +
>> + if (conn_state->hdmi.tmds_char_rate > HDMI14_MAX_TMDSCLK)
>> + dw_hdmi_qp_enable_scramb(hdmi);
>> } else {
>> dev_dbg(hdmi->dev, "%s mode=DVI\n", __func__);
>> op_mode = OPMODE_DVI;
>> @@ -781,7 +887,7 @@ static void dw_hdmi_qp_bridge_atomic_enable(struct drm_bridge *bridge,
>> dw_hdmi_qp_mod(hdmi, HDCP2_BYPASS, HDCP2_BYPASS, HDCP2LOGIC_CONFIG0);
>> dw_hdmi_qp_mod(hdmi, op_mode, OPMODE_DVI, LINK_CONFIG0);
>>
>> - drm_atomic_helper_connector_hdmi_update_infoframes(connector, state);
>> + drm_atomic_helper_connector_hdmi_update_infoframes(hdmi->curr_conn, state);
>> }
>>
>> static void dw_hdmi_qp_bridge_atomic_disable(struct drm_bridge *bridge,
>> @@ -791,14 +897,49 @@ static void dw_hdmi_qp_bridge_atomic_disable(struct drm_bridge *bridge,
>>
>> hdmi->tmds_char_rate = 0;
>>
>> + dw_hdmi_qp_disable_scramb(hdmi);
>> +
>> + hdmi->curr_conn = NULL;
>> hdmi->phy.ops->disable(hdmi, hdmi->phy.data);
>> }
>>
>> -static enum drm_connector_status
>> -dw_hdmi_qp_bridge_detect(struct drm_bridge *bridge, struct drm_connector *connector)
>> +static int dw_hdmi_qp_reset_crtc(struct dw_hdmi_qp *hdmi,
>> + struct drm_connector *connector,
>> + struct drm_modeset_acquire_ctx *ctx)
>> +{
>> + u8 config;
>> + int ret;
>> +
>> + ret = drm_scdc_readb(hdmi->bridge.ddc, SCDC_TMDS_CONFIG, &config);
>> + if (ret < 0) {
>> + dev_err(hdmi->dev, "Failed to read TMDS config: %d\n", ret);
>> + return ret;
>> + }
>> +
>> + if (!!(config & SCDC_SCRAMBLING_ENABLE) == hdmi->scramb_enabled)
>> + return 0;
>
> Also please check the high TMDS clock ration bit.
Ack.
>> +
>> + drm_atomic_helper_connector_hdmi_hotplug(connector,
>> + connector_status_connected);
>
> I don't see a forced hotplug event in the existing drivers. Why is it
> necessary? This function is being called from the detect() path.
For some reason, without it, the connector seems to lose its state after reset:
[ 2142.982967] dwhdmiqp-rockchip fde80000.hdmi: resetting crtc
[ 2142.994132] rockchip-drm display-subsystem: [drm] HDMI Sink doesn't support RGB, something's wrong.
[ 2143.140827] dwhdmiqp-rockchip fde80000.hdmi: dw_hdmi_qp_bridge_atomic_enable mode=DVI
Will recheck if that's still the case after the HPD handling rework.
>
>> + /*
>> + * Conform to HDMI 2.0 spec by ensuring scrambled data is not sent
>> + * before configuring the sink scrambling, as well as suspending any
>> + * TMDS transmission while changing the TMDS clock rate in the sink.
>> + */
>> +
>> + dev_dbg(hdmi->dev, "resetting crtc\n");
>> +
>> + return drm_bridge_helper_reset_crtc(&hdmi->bridge, ctx);
>> +}
>> +
>> +static int dw_hdmi_qp_bridge_detect_ctx(struct drm_bridge *bridge,
>> + struct drm_connector *connector,
>> + struct drm_modeset_acquire_ctx *ctx)
>> {
>> struct dw_hdmi_qp *hdmi = bridge->driver_private;
>> + enum drm_connector_status status;
>> const struct drm_edid *drm_edid;
>> + int ret;
>>
>> if (hdmi->no_hpd) {
>> drm_edid = drm_edid_read_ddc(connector, bridge->ddc);
>> @@ -808,7 +949,20 @@ dw_hdmi_qp_bridge_detect(struct drm_bridge *bridge, struct drm_connector *connec
>> return connector_status_disconnected;
>> }
>>
>> - return hdmi->phy.ops->read_hpd(hdmi, hdmi->phy.data);
>> + status = hdmi->phy.ops->read_hpd(hdmi, hdmi->phy.data);
>> +
>> + dev_dbg(hdmi->dev, "%s status=%d scramb=%d\n", __func__,
>> + status, hdmi->scramb_enabled);
>> +
>> + if (status == connector_status_connected && hdmi->scramb_enabled) {
>> + ret = dw_hdmi_qp_reset_crtc(hdmi, connector, ctx);
>> + if (ret == -EDEADLK)
>> + return ret;
>> + if (ret < 0)
>> + status = connector_status_unknown;
>
> Ideally this should go to the drm_atomic_helper_connector_hdmi_update().
> And once it goes, I don't think we'd need the detect_ctx() callback for
> bridges.
Ok, I'll try that.
Regards,
Cristian
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
next prev parent reply other threads:[~2026-04-28 13:52 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-26 0:20 [PATCH v5 00/10] Add HDMI 2.0 support to DW HDMI QP TX Cristian Ciocaltea
2026-04-26 0:20 ` [PATCH v5 01/10] drm/bridge: Remove redundant error check in drm_bridge_helper_reset_crtc() Cristian Ciocaltea
2026-04-27 21:46 ` Dmitry Baryshkov
2026-04-26 0:20 ` [PATCH v5 02/10] drm/bridge: Add detect_ctx hook and drm_bridge_detect_ctx() helper Cristian Ciocaltea
2026-04-27 11:00 ` Heiko Stuebner
2026-04-26 0:20 ` [PATCH v5 03/10] drm/bridge-connector: Use cached connector status in .get_modes() Cristian Ciocaltea
2026-04-27 21:52 ` Dmitry Baryshkov
2026-04-26 0:20 ` [PATCH v5 04/10] drm/bridge-connector: Switch to .detect_ctx() for connector detection Cristian Ciocaltea
2026-04-27 21:54 ` Dmitry Baryshkov
2026-04-26 0:20 ` [PATCH v5 05/10] drm/bridge: dw-hdmi-qp: Add HDMI 2.0 SCDC scrambling and high TMDS clock ratio support Cristian Ciocaltea
2026-04-27 10:49 ` Heiko Stuebner
2026-04-27 16:39 ` Cristian Ciocaltea
2026-04-27 19:09 ` Heiko Stuebner
2026-04-27 19:10 ` Heiko Stuebner
2026-04-28 1:38 ` Dmitry Baryshkov
2026-04-28 13:51 ` Cristian Ciocaltea [this message]
2026-04-26 0:20 ` [PATCH v5 06/10] drm/bridge: dw-hdmi-qp: Rate limit i2c read error messages Cristian Ciocaltea
2026-04-27 10:41 ` Heiko Stuebner
2026-04-26 0:20 ` [PATCH v5 07/10] drm/rockchip: dw_hdmi_qp: Add missing newlines in dev_err_probe() messages Cristian Ciocaltea
2026-04-27 10:39 ` Heiko Stuebner
2026-04-28 1:40 ` Dmitry Baryshkov
2026-04-26 0:20 ` [PATCH v5 08/10] drm/rockchip: dw_hdmi_qp: Use local dev variable consistently in bind() Cristian Ciocaltea
2026-04-27 10:39 ` Heiko Stuebner
2026-04-26 0:20 ` [PATCH v5 09/10] drm/rockchip: dw_hdmi_qp: Register HPD IRQ after connector setup Cristian Ciocaltea
2026-04-28 1:41 ` Dmitry Baryshkov
2026-04-28 13:58 ` Cristian Ciocaltea
2026-04-26 0:20 ` [PATCH v5 10/10] drm/rockchip: dw_hdmi_qp: Restrict HPD event to the affected connector Cristian Ciocaltea
2026-04-28 1:53 ` Dmitry Baryshkov
2026-04-28 14:10 ` Cristian Ciocaltea
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=539f1bb9-6509-40c7-8692-bb3cdee33f91@collabora.com \
--to=cristian.ciocaltea@collabora.com \
--cc=Laurent.pinchart@ideasonboard.com \
--cc=airlied@gmail.com \
--cc=andrzej.hajda@intel.com \
--cc=andy.yan@rock-chips.com \
--cc=diederik@cknow-tech.com \
--cc=dmitry.baryshkov@oss.qualcomm.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=heiko@sntech.de \
--cc=hjc@rock-chips.com \
--cc=jernej.skrabec@gmail.com \
--cc=jonas@kwiboo.se \
--cc=kernel@collabora.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=maud_spierings@hotmail.com \
--cc=mripard@kernel.org \
--cc=neil.armstrong@linaro.org \
--cc=rfoss@kernel.org \
--cc=simona@ffwll.ch \
--cc=tzimmermann@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox