[PATCH 0/2] phy: hdmi: Add FRL TxFFE level control

[PATCH 0/2] phy: hdmi: Add FRL TxFFE level control

[Cristian Ciocaltea]

During HDMI 2.1 Fixed Rate Link training, the source and sink may
negotiate a Transmitter Feed Forward Equalizer (TxFFE) level to
compensate for signal quality degradation on the physical channel.  The
source starts at level 0 and may increment it up to a maximum agreed
upon during LTS3 in response to persistent link failures reported by the
sink.  TxFFE adjustment is optional and entirely independent of the FRL
rate and lane count selection.

Patch 1 extends the HDMI PHY configuration API with two new fields in
the frl sub-struct: ffe_level to carry the requested level, and a
set_ffe_level flag that switches the semantics of a phy_configure() call
to a pure equalizer update, leaving all other fields ignored.

Patch 2 implements the new interface in the Rockchip Samsung HDPTX PHY
driver.

The series depends on the "[PATCH 0/6] phy: rockchip: samsung-hdptx:
Clock fixes and API transition cleanups" patchset:

https://lore.kernel.org/all/20260227-hdptx-clk-fixes-v1-0-f998f2762d0f@collabora.com/

Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
---
Cristian Ciocaltea (2):
      phy: hdmi: Add optional FRL TxFFE config options
      phy: rockchip: samsung-hdptx: Add support for FRL TxFFE level control

 drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c | 74 +++++++++++++++++++++--
 include/linux/phy/phy-hdmi.h                      |  6 ++
 2 files changed, 75 insertions(+), 5 deletions(-)
---
base-commit: f7b64ed948718290209074a50bb0df17e5944873
change-id: 20260328-hdptx-ffe-a89c51e66904
prerequisite-change-id: 20260227-hdptx-clk-fixes-47426632f862:v1
prerequisite-patch-id: 5c1d442fae39103bb758f54738aff33d2491401d
prerequisite-patch-id: b86f30292308345387d2a6b50949ad040b931592
prerequisite-patch-id: b1335105db9177cb10c64ed1bf0867832e6aac2f
prerequisite-patch-id: 83db6603d13e19f239e89fde2b26366eb0106b7e
prerequisite-patch-id: b534395ad315811861f11859a3946f65c90c631a
prerequisite-patch-id: f9637e57c902f35218cda658397416f84f7285cb


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

[PATCH 1/2] phy: hdmi: Add optional FRL TxFFE config options

[Cristian Ciocaltea]

During HDMI 2.1 FRL link training, the source and sink can negotiate a
Transmitter Feed Forward Equalizer (TxFFE) level to compensate for
signal quality degradation.  Starting from zero, the source may
increment the TxFFE level up to a maximum agreed during the LTS3 stage
if the sink keeps reporting FLT failures.

It's worth noting TxFFE adjustment is optional and only attempted when
both the source and the connected sink support it.

Since the existing HDMI PHY configuration API covers the FRL rate/lane
selection only, provide the following fields to the frl sub-struct of
phy_configure_opts_hdmi:

* ffe_level: the TxFFE level to apply, only meaningful when
  set_ffe_level is set.

* set_ffe_level: a 1-bit flag that changes the semantics of the
  phy_configure() call, i.e. when set, the PHY driver must apply the new
  ffe_level and ignore the other frl related fields.

The flag-based approach reflects an important invariant in the link
training process: whenever the FRL rate or lane count changes, the TxFFE
level must be reset to zero.  A separate phy_configure() call with
set_ffe_level can only follow after the rate has been established,
making the two operations deliberately distinct.

Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
---
 include/linux/phy/phy-hdmi.h | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/include/linux/phy/phy-hdmi.h b/include/linux/phy/phy-hdmi.h
index d4cf4430ee8f..1d4b62475079 100644
--- a/include/linux/phy/phy-hdmi.h
+++ b/include/linux/phy/phy-hdmi.h
@@ -19,6 +19,10 @@ enum phy_hdmi_mode {
  * @tmds_char_rate: HDMI TMDS Character Rate in Hertz.
  * @frl.rate_per_lane: HDMI FRL Rate per Lane in Gbps.
  * @frl.lanes: HDMI FRL lanes count.
+ * @frl.ffe_level: Transmitter Feed Forward Equalizer Level.
+ *	Optional, only meaningful when set_ffe_level flag is on.
+ * @frl.set_ffe_level: Flag indicating whether or not to reconfigure ffe_level.
+ *	All the other struct fields must be ignored when this is used.
  *
  * This structure is used to represent the configuration state of a HDMI phy.
  */
@@ -29,6 +33,8 @@ struct phy_configure_opts_hdmi {
 		struct {
 			u8 rate_per_lane;
 			u8 lanes;
+			u8 ffe_level;
+			u8 set_ffe_level : 1;
 		} frl;
 	};
 };

-- 
2.52.0


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

[PATCH 2/2] phy: rockchip: samsung-hdptx: Add support for FRL TxFFE level control

[Cristian Ciocaltea]

During HDMI 2.1 FRL link training, the source may need to incrementally
raise the TxFFE level in response to persistent link failures reported
by the sink during LTS3.  The phy_configure_opts_hdmi struct now carries
ffe_level and set_ffe_level fields to convey such an update
independently of a full rate reconfiguration.

Wire up the optional TxFFE control in the Samsung HDPTX PHY driver.

Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
---
 drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c | 74 +++++++++++++++++++++--
 1 file changed, 69 insertions(+), 5 deletions(-)

diff --git a/drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c b/drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c
index 3bde7fbb34b1..c4669853ad0e 100644
--- a/drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c
+++ b/drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c
@@ -333,6 +333,7 @@
 #define FRL_3G3L_RATE			900000000
 #define FRL_6G3L_RATE			1800000000
 #define FRL_8G4L_RATE			3200000000
+#define FRL_FFE_MAX_LEVEL		3
 
 enum dp_link_rate {
 	DP_BW_RBR,
@@ -466,6 +467,16 @@ static const struct ropll_config rk_hdptx_tmds_ropll_cfg[] = {
 	{  25175000ULL,   84,    84,    1,    1,   15,  1,  168,    1,  16,  4,   1,    1, },
 };
 
+static const struct ffe_config {
+	u8 pre_shoot;
+	u8 de_emphasis;
+} rk_hdptx_frl_ffe_cfg[FRL_FFE_MAX_LEVEL + 1] = {
+	{ 0x3, 0x4 },
+	{ 0x3, 0x6 },
+	{ 0x3, 0x8 },
+	{ 0x3, 0x9 },
+};
+
 static const struct reg_sequence rk_hdptx_common_cmn_init_seq[] = {
 	REG_SEQ0(CMN_REG(0009), 0x0c),
 	REG_SEQ0(CMN_REG(000a), 0x83),
@@ -1321,6 +1332,45 @@ static int rk_hdptx_tmds_ropll_mode_config(struct rk_hdptx_phy *hdptx)
 	return rk_hdptx_post_enable_lane(hdptx);
 }
 
+static int rk_hdptx_frl_ffe_config(struct rk_hdptx_phy *hdptx, u8 ffe_level)
+{
+	u8 val;
+
+	if (ffe_level > FRL_FFE_MAX_LEVEL)
+		return -EINVAL;
+
+	val = rk_hdptx_frl_ffe_cfg[ffe_level].pre_shoot;
+
+	regmap_update_bits(hdptx->regmap, LANE_REG(0305),
+			   LN_TX_DRV_PRE_LVL_CTRL_MASK,
+			   FIELD_PREP(LN_TX_DRV_PRE_LVL_CTRL_MASK, val));
+	regmap_update_bits(hdptx->regmap, LANE_REG(0405),
+			   LN_TX_DRV_PRE_LVL_CTRL_MASK,
+			   FIELD_PREP(LN_TX_DRV_PRE_LVL_CTRL_MASK, val));
+	regmap_update_bits(hdptx->regmap, LANE_REG(0505),
+			   LN_TX_DRV_PRE_LVL_CTRL_MASK,
+			   FIELD_PREP(LN_TX_DRV_PRE_LVL_CTRL_MASK, val));
+	regmap_update_bits(hdptx->regmap, LANE_REG(0605),
+			   LN_TX_DRV_PRE_LVL_CTRL_MASK,
+			   FIELD_PREP(LN_TX_DRV_PRE_LVL_CTRL_MASK, val));
+
+	val = rk_hdptx_frl_ffe_cfg[ffe_level].de_emphasis;
+
+	regmap_update_bits(hdptx->regmap, LANE_REG(0304),
+			   LN_TX_DRV_POST_LVL_CTRL_MASK,
+			   FIELD_PREP(LN_TX_DRV_POST_LVL_CTRL_MASK, val));
+	regmap_update_bits(hdptx->regmap, LANE_REG(0404),
+			   LN_TX_DRV_POST_LVL_CTRL_MASK,
+			   FIELD_PREP(LN_TX_DRV_POST_LVL_CTRL_MASK, val));
+	regmap_update_bits(hdptx->regmap, LANE_REG(0504),
+			   LN_TX_DRV_POST_LVL_CTRL_MASK,
+			   FIELD_PREP(LN_TX_DRV_POST_LVL_CTRL_MASK, val));
+	regmap_update_bits(hdptx->regmap, LANE_REG(0604),
+			   LN_TX_DRV_POST_LVL_CTRL_MASK,
+			   FIELD_PREP(LN_TX_DRV_POST_LVL_CTRL_MASK, val));
+	return 0;
+}
+
 static void rk_hdptx_dp_reset(struct rk_hdptx_phy *hdptx)
 {
 	reset_control_assert(hdptx->rsts[RST_LANE].rstc);
@@ -1730,6 +1780,13 @@ static int rk_hdptx_phy_verify_hdmi_config(struct rk_hdptx_phy *hdptx,
 		unsigned long long frl_rate = 100000000ULL * hdmi_in->frl.lanes *
 					      hdmi_in->frl.rate_per_lane;
 
+		if (hdmi_in->frl.set_ffe_level) {
+			if (hdmi_in->frl.ffe_level > FRL_FFE_MAX_LEVEL)
+				return -EINVAL;
+
+			return 0;
+		}
+
 		switch (hdmi_in->frl.rate_per_lane) {
 		case 3:
 		case 6:
@@ -2076,11 +2133,18 @@ static int rk_hdptx_phy_configure(struct phy *phy, union phy_configure_opts *opt
 		if (ret) {
 			dev_err(hdptx->dev, "invalid hdmi params for phy configure\n");
 		} else {
-			hdptx->pll_config_dirty = true;
-
-			dev_dbg(hdptx->dev, "%s %s rate=%llu bpc=%u\n", __func__,
-				hdptx->hdmi_cfg.mode ? "FRL" : "TMDS",
-				hdptx->hdmi_cfg.rate, hdptx->hdmi_cfg.bpc);
+			if (hdptx->hdmi_cfg.mode == PHY_HDMI_MODE_FRL &&
+			    opts->hdmi.frl.set_ffe_level) {
+				dev_dbg(hdptx->dev, "%s ffe_level=%u\n", __func__,
+					opts->hdmi.frl.ffe_level);
+				ret = rk_hdptx_frl_ffe_config(hdptx, opts->hdmi.frl.ffe_level);
+			} else {
+				hdptx->pll_config_dirty = true;
+
+				dev_dbg(hdptx->dev, "%s %s rate=%llu bpc=%u\n", __func__,
+					hdptx->hdmi_cfg.mode ? "FRL" : "TMDS",
+					hdptx->hdmi_cfg.rate, hdptx->hdmi_cfg.bpc);
+			}
 		}
 
 		return ret;

-- 
2.52.0


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

Re: [PATCH 0/2] phy: hdmi: Add FRL TxFFE level control

[Vladimir Oltean]

On Sat, Mar 28, 2026 at 03:54:53PM +0200, Cristian Ciocaltea wrote:
> During HDMI 2.1 Fixed Rate Link training, the source and sink may
> negotiate a Transmitter Feed Forward Equalizer (TxFFE) level to
> compensate for signal quality degradation on the physical channel.  The
> source starts at level 0 and may increment it up to a maximum agreed
> upon during LTS3 in response to persistent link failures reported by the
> sink.  TxFFE adjustment is optional and entirely independent of the FRL
> rate and lane count selection.
> 
> Patch 1 extends the HDMI PHY configuration API with two new fields in
> the frl sub-struct: ffe_level to carry the requested level, and a
> set_ffe_level flag that switches the semantics of a phy_configure() call
> to a pure equalizer update, leaving all other fields ignored.
> 
> Patch 2 implements the new interface in the Rockchip Samsung HDPTX PHY
> driver.
> 
> The series depends on the "[PATCH 0/6] phy: rockchip: samsung-hdptx:
> Clock fixes and API transition cleanups" patchset:
> 
> https://lore.kernel.org/all/20260227-hdptx-clk-fixes-v1-0-f998f2762d0f@collabora.com/
> 
> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
> ---
> Cristian Ciocaltea (2):
>       phy: hdmi: Add optional FRL TxFFE config options
>       phy: rockchip: samsung-hdptx: Add support for FRL TxFFE level control
> 
>  drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c | 74 +++++++++++++++++++++--
>  include/linux/phy/phy-hdmi.h                      |  6 ++
>  2 files changed, 75 insertions(+), 5 deletions(-)
> ---
> base-commit: f7b64ed948718290209074a50bb0df17e5944873
> change-id: 20260328-hdptx-ffe-a89c51e66904
> prerequisite-change-id: 20260227-hdptx-clk-fixes-47426632f862:v1
> prerequisite-patch-id: 5c1d442fae39103bb758f54738aff33d2491401d
> prerequisite-patch-id: b86f30292308345387d2a6b50949ad040b931592
> prerequisite-patch-id: b1335105db9177cb10c64ed1bf0867832e6aac2f
> prerequisite-patch-id: 83db6603d13e19f239e89fde2b26366eb0106b7e
> prerequisite-patch-id: b534395ad315811861f11859a3946f65c90c631a
> prerequisite-patch-id: f9637e57c902f35218cda658397416f84f7285cb

Sorry for my ignorance; who is supposed to act upon this git-format-patch
base tree information and in what way?

As things stand today, the build infrastructure we have in place will
not be able to apply and test your series unless it applies directly
onto the linux-phy/next branch.

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

Re: [PATCH 0/2] phy: hdmi: Add FRL TxFFE level control

[Cristian Ciocaltea]

On 3/30/26 11:57 AM, Vladimir Oltean wrote:
> On Sat, Mar 28, 2026 at 03:54:53PM +0200, Cristian Ciocaltea wrote:
>> During HDMI 2.1 Fixed Rate Link training, the source and sink may
>> negotiate a Transmitter Feed Forward Equalizer (TxFFE) level to
>> compensate for signal quality degradation on the physical channel.  The
>> source starts at level 0 and may increment it up to a maximum agreed
>> upon during LTS3 in response to persistent link failures reported by the
>> sink.  TxFFE adjustment is optional and entirely independent of the FRL
>> rate and lane count selection.
>>
>> Patch 1 extends the HDMI PHY configuration API with two new fields in
>> the frl sub-struct: ffe_level to carry the requested level, and a
>> set_ffe_level flag that switches the semantics of a phy_configure() call
>> to a pure equalizer update, leaving all other fields ignored.
>>
>> Patch 2 implements the new interface in the Rockchip Samsung HDPTX PHY
>> driver.
>>
>> The series depends on the "[PATCH 0/6] phy: rockchip: samsung-hdptx:
>> Clock fixes and API transition cleanups" patchset:
>>
>> https://lore.kernel.org/all/20260227-hdptx-clk-fixes-v1-0-f998f2762d0f@collabora.com/
>>
>> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
>> ---
>> Cristian Ciocaltea (2):
>>       phy: hdmi: Add optional FRL TxFFE config options
>>       phy: rockchip: samsung-hdptx: Add support for FRL TxFFE level control
>>
>>  drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c | 74 +++++++++++++++++++++--
>>  include/linux/phy/phy-hdmi.h                      |  6 ++
>>  2 files changed, 75 insertions(+), 5 deletions(-)
>> ---
>> base-commit: f7b64ed948718290209074a50bb0df17e5944873
>> change-id: 20260328-hdptx-ffe-a89c51e66904
>> prerequisite-change-id: 20260227-hdptx-clk-fixes-47426632f862:v1
>> prerequisite-patch-id: 5c1d442fae39103bb758f54738aff33d2491401d
>> prerequisite-patch-id: b86f30292308345387d2a6b50949ad040b931592
>> prerequisite-patch-id: b1335105db9177cb10c64ed1bf0867832e6aac2f
>> prerequisite-patch-id: 83db6603d13e19f239e89fde2b26366eb0106b7e
>> prerequisite-patch-id: b534395ad315811861f11859a3946f65c90c631a
>> prerequisite-patch-id: f9637e57c902f35218cda658397416f84f7285cb
> 
> Sorry for my ignorance; who is supposed to act upon this git-format-patch
> base tree information and in what way?
> 
> As things stand today, the build infrastructure we have in place will
> not be able to apply and test your series unless it applies directly
> onto the linux-phy/next branch.

Oh, I assumed that since b4 makes managing series dependencies straightforward
on the preparation/submission side, there would be similar tooling support on
the build/integration side as well.

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

Re: [PATCH 0/2] phy: hdmi: Add FRL TxFFE level control

[Vladimir Oltean]

On Tue, Mar 31, 2026 at 01:56:32AM +0300, Cristian Ciocaltea wrote:
> On 3/30/26 11:57 AM, Vladimir Oltean wrote:
> > On Sat, Mar 28, 2026 at 03:54:53PM +0200, Cristian Ciocaltea wrote:
> >> ---
> >> base-commit: f7b64ed948718290209074a50bb0df17e5944873
> >> change-id: 20260328-hdptx-ffe-a89c51e66904
> >> prerequisite-change-id: 20260227-hdptx-clk-fixes-47426632f862:v1
> >> prerequisite-patch-id: 5c1d442fae39103bb758f54738aff33d2491401d
> >> prerequisite-patch-id: b86f30292308345387d2a6b50949ad040b931592
> >> prerequisite-patch-id: b1335105db9177cb10c64ed1bf0867832e6aac2f
> >> prerequisite-patch-id: 83db6603d13e19f239e89fde2b26366eb0106b7e
> >> prerequisite-patch-id: b534395ad315811861f11859a3946f65c90c631a
> >> prerequisite-patch-id: f9637e57c902f35218cda658397416f84f7285cb
> > 
> > Sorry for my ignorance; who is supposed to act upon this git-format-patch
> > base tree information and in what way?
> > 
> > As things stand today, the build infrastructure we have in place will
> > not be able to apply and test your series unless it applies directly
> > onto the linux-phy/next branch.
> 
> Oh, I assumed that since b4 makes managing series dependencies straightforward
> on the preparation/submission side, there would be similar tooling support on
> the build/integration side as well.

Sorry to disappoint - linux-phy doesn't use b4 to build-test patches. It
gets them from Patchwork directly (as you'd get by clicking the 'diff' button),
then figures out whether to apply to the next or to the fixes branch
using the git-format-patch --subject-prefix string ('phy-next' or 'phy-fixes'),
then posts the checks back to Patchwork.

I can somehow imagine why no one rushed to improve this. While sometimes
somewhat useful, I can see the risk of such feature getting abused to
create a giant cobweb of dependencies that is suddenly no longer the
developer's problem, but passed on to somebody else.

In the future, please submit as RFC the patch sets that you know don't
directly apply, and mention that you're only posting them for early
feedback.

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