On 3/30/26 11:57 AM, Vladimir Oltean wrote:

On Sat, Mar 28, 2026 at 03:54:53PM +0200, Cristian Ciocaltea wrote:

quoted

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/ (local)

Signed-off-by: Cristian Ciocaltea <redacted>
---
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.