Linux-PHY Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Cristian Ciocaltea" <cristian.ciocaltea@collabora.com>
Cc: vkoul@kernel.org, linux-phy@lists.infradead.org,
	olteanv@gmail.com, neil.armstrong@linaro.org
Subject: Re: [PATCH v5 06/10] phy: rockchip: samsung-hdptx: Drop TMDS rate setup workaround
Date: Thu, 23 Jul 2026 19:54:20 +0000	[thread overview]
Message-ID: <20260723195420.840511F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260723-hdptx-clk-fixes-v5-6-8e786067865f@collabora.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The commit claims to drop the TMDS rate setup workaround but fails to remove the corresponding CCF-based rate adjustment fallback, leaving the cleanup incomplete.
--

--- Patch [6]: [PATCH v5 06/10] phy: rockchip: samsung-hdptx: Drop TMDS rate setup workaround ---
commit 0f64c3b5ec0d09a00473e1362200c7598b861f9d
Author: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>

phy: rockchip: samsung-hdptx: Drop TMDS rate setup workaround

Since commit ba9c2fe18c17 ("drm/rockchip: dw_hdmi_qp: Switch to
phy_configure()") the TMDS rate setup doesn't rely anymore on the
unconventional usage of the bus width, instead it is managed exclusively
through the HDMI PHY configuration API.

Drop the now obsolete workaround to retrieve the TMDS character rate via
phy_get_bus_width() during power_on().

> diff --git a/drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c b/drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c
> index 792eb57755eb1..31abff5ada9e3 100644
> --- a/drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c
> +++ b/drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c
> @@ -1660,22 +1660,6 @@ static int rk_hdptx_phy_power_on(struct phy *phy)
>  	enum phy_mode mode = phy_get_mode(phy);
>  	int ret, lane;
>  
> -	if (mode != PHY_MODE_DP) {
> -		if (!hdptx->hdmi_cfg.rate && hdptx->hdmi_cfg.mode != PHY_HDMI_MODE_FRL) {
> -			/*
> -			 * FIXME: Temporary workaround to setup TMDS char rate
> -			 * from the RK DW HDMI QP bridge driver.
> -			 * Will be removed as soon the switch to the HDMI PHY
> -			 * configuration API has been completed on both ends.
> -			 */
> -			hdptx->hdmi_cfg.rate = phy_get_bus_width(hdptx->phy) & 0xfffffff;
> -			hdptx->hdmi_cfg.rate *= 100;
> -		}
> -

[Severity: Medium]
Since this patch drops the TMDS workaround here, should we also remove the
corresponding CCF-based rate adjustment fallback and the restrict_rate_change
state tracking?

Looking at rk_hdptx_phy_clk_determine_rate():

drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c:rk_hdptx_phy_clk_determine_rate() {
	...
	/*
	 * FIXME: Temporarily allow altering TMDS char rate via CCF.
	 * To be dropped as soon as the RK DW HDMI QP bridge driver
	 * switches to make use of phy_configure().
	 */
	if (!hdptx->restrict_rate_change && req->rate != hdptx->hdmi_cfg.rate) {
		struct phy_configure_opts_hdmi hdmi = {
			.tmds_char_rate = req->rate,
		};
	...
}

Leaving this block behind seems to leave dead code, as the removal condition
(the bridge driver switching to phy_configure()) has been met.

Does this cleanup belong in this patch as well to ensure the workaround is
fully removed?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260723-hdptx-clk-fixes-v5-0-8e786067865f@collabora.com?part=6

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

  reply	other threads:[~2026-07-23 19:54 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-23 19:41 [PATCH v5 00/10] phy: rockchip: samsung-hdptx: Clock fixes and API transition cleanups Cristian Ciocaltea
2026-07-23 19:41 ` [PATCH v5 01/10] phy: rockchip: samsung-hdptx: Fix rate recalculation for high bpc Cristian Ciocaltea
2026-07-23 19:41 ` [PATCH v5 02/10] phy: rockchip: samsung-hdptx: Prevent divide-by-zero when computing clk rate Cristian Ciocaltea
2026-07-23 19:55   ` sashiko-bot
2026-07-23 21:40     ` Cristian Ciocaltea
2026-07-23 19:41 ` [PATCH v5 03/10] phy: rockchip: samsung-hdptx: Guard against clk rate integer underflow Cristian Ciocaltea
2026-07-23 19:57   ` sashiko-bot
2026-07-23 21:22     ` Cristian Ciocaltea
2026-07-23 19:41 ` [PATCH v5 04/10] phy: rockchip: samsung-hdptx: Fix rate recalculation for 3.2GHz FRL Cristian Ciocaltea
2026-07-23 19:41 ` [PATCH v5 05/10] phy: rockchip: samsung-hdptx: Handle uncommitted PHY config changes Cristian Ciocaltea
2026-07-23 20:00   ` sashiko-bot
2026-07-23 21:48     ` Cristian Ciocaltea
2026-07-23 19:41 ` [PATCH v5 06/10] phy: rockchip: samsung-hdptx: Drop TMDS rate setup workaround Cristian Ciocaltea
2026-07-23 19:54   ` sashiko-bot [this message]
2026-07-23 20:50     ` Cristian Ciocaltea
2026-07-23 19:41 ` [PATCH v5 07/10] phy: rockchip: samsung-hdptx: Consolidate consumer_put on error path Cristian Ciocaltea
2026-07-23 19:41 ` [PATCH v5 08/10] phy: rockchip: samsung-hdptx: Drop restrict_rate_change handling Cristian Ciocaltea
2026-07-23 19:41 ` [PATCH v5 09/10] phy: rockchip: samsung-hdptx: Simplify GRF access with FIELD_PREP_WM16() Cristian Ciocaltea
2026-07-23 19:41 ` [PATCH v5 10/10] phy: rockchip: samsung-hdptx: Consistently use bitfield macros 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=20260723195420.840511F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=cristian.ciocaltea@collabora.com \
    --cc=linux-phy@lists.infradead.org \
    --cc=neil.armstrong@linaro.org \
    --cc=olteanv@gmail.com \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=vkoul@kernel.org \
    /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