drm/bridge: dw-hdmi-qp: seamless handoff sets wrong tmds_char_rate, breaking audio on strict HDMI 2.1 sinks

drm/bridge: dw-hdmi-qp: seamless handoff sets wrong tmds_char_rate, breaking audio on strict HDMI 2.1 sinks

[Simon Wright]

[Resent in plain text — first attempt was rejected by the list's HTML filter.]

Hi,

I have tracked down a bug in dw-hdmi-qp that silences audio on strict
HDMI 2.1 sinks (tested: LG G3 OLED) when booting with HDMI seamless
handoff from U-Boot. HDMI 2.0 sinks are unaffected. The root cause is
a mismatch between the AVI InfoFrame colour depth and the ACR embedded
CTS value.

Hardware tested:
  Source:       ArmSoM Sige5 (Rockchip RK3576)
                Armbian-edge kernel 7.0.2 (Linux mainline v7.0 plus
                Armbian board-enable patches; not a BSP kernel)
  Failing sink: LG G3 OLED 4K (HDMI 2.1, strict embedded-CTS mode)
  Passing sink: Various HDMI 2.0 TVs (self-measuring CTS, unaffected)

The bug is structural and is expected to affect RK3588 under the same
boot sequence.


Root cause
----------

When the system boots with seamless handoff active, U-Boot has configured
the PHY for 8-bit 1080p60 (TMDS = 148,500,000 Hz). The DRM connector
state, negotiated from EDID, selects 10-bit deep colour (TMDS =
185,625,000 Hz). In dw_hdmi_qp_bridge_atomic_enable():

    hdmi->tmds_char_rate = conn_state->hdmi.tmds_char_rate;

This stores 185,625,000. The PHY ops->init() is called but the PHY is
already running at 148,500,000 from U-Boot and is not reconfigured.

The result is an inconsistency between what the sink is told over HDMI
and what the wire actually carries:

  AVI InfoFrame:     declares 10-bit deep colour at the connector-state
                     TMDS rate (185.625 MHz)
  ACR embedded CTS:  driver uses hdmi->tmds_char_rate = 185,625,000 Hz
                     to compute CTS via dw_hdmi_qp_set_sample_rate(),
                     producing CTS = 185,625 (internally consistent
                     with the AVI declaration)
  Wire TMDS clock:   PHY untouched from U-Boot, still running at
                     148,500,000 Hz (8-bit)

The dmesg signature (full pr_err output, lower in this report) confirms
both AVI and ACR are computed from the nominal 185.625 MHz value:
"tmds=185625000 ... cts=185625".

A standard HDMI 2.0 sink does not cross-check AVI against the wire TMDS
in any way that matters for audio, so the mismatch is harmless. A strict
HDMI 2.1 sink (LG G3) measures the wire TMDS and verifies it matches the
AVI declaration; with declared 185.625 MHz vs measured 148.5 MHz, the
check fails and audio is muted, permanently, until the next mode set.

The N/CTS values themselves are correct CEA-861 ratios. At a wire TMDS
of 148.5 MHz with N=6144, CTS=148,500 yields f_audio = 48 kHz; at a
wire TMDS of 185.625 MHz with N=6144, CTS=185,625 also yields f_audio
= 48 kHz. The driver picks one TMDS, computes a self-consistent N/CTS
pair, and embeds it. The bug is solely that the TMDS the driver picks
(connector-state nominal) differs from the TMDS on the wire (PHY
actual).


Dmesg diagnostic signature
--------------------------

Failing (seamless handoff, DRM selects 10-bit 1080p from EDID):

    dwhdmiqp-rockchip 27da0000.hdmi: atomic_enable: \
        tmds_candidate=185625000 is_hdmi=1
    DW_HDMI_QP set_sample_rate: tmds=185625000 sr=48000 n=6144 cts=185625
    [audio silent on LG G3]

Working (8-bit mode forced, see workaround below):

    dwhdmiqp-rockchip 27da0000.hdmi: atomic_enable: \
        tmds_candidate=148500000 is_hdmi=1
    DW_HDMI_QP set_sample_rate: tmds=148500000 sr=48000 n=6144 cts=148500
    [audio working on LG G3]

The difference is entirely in which tmds_char_rate bridge_atomic_enable()
receives. If the PHY and DRM state agree (both 148.5 MHz), audio works
because what the AVI declares matches what the wire carries. If they
disagree (DRM: 185.625 MHz, PHY: 148.5 MHz), the AVI declares 185.625
but the wire carries 148.5, and any sink that cross-checks the wire
TMDS against the declared rate (e.g. LG G3 OLED) mutes audio.


Confirmed workaround
--------------------

In dw_hdmi_qp_bridge_tmds_char_rate_valid(), reject 185,625,000 Hz:

    if (rate == 185625000)
        return MODE_CLOCK_HIGH;

This forces DRM to select 8-bit mode (148,500,000 Hz). bridge_atomic_enable()
then stores the correct tmds_char_rate, the AVI InfoFrame declares 8-bit,
the ACR CTS is computed correctly, and the LG G3 produces audio.

Note: 185,625,000 Hz (1080p@60 10-bit) is only selected via EDID
negotiation during seamless handoff. A genuine modeset at that rate would
correctly reconfigure the PHY and the AVI/ACR inconsistency would not
arise. Blocking this rate in tmds_char_rate_valid() therefore has no
correct-use-case cost on RK3576 with the current BSP. 4K@60Hz (594 MHz)
is unaffected and continues to work correctly, including audio.


Proposed proper fix
-------------------

The fundamental issue is that bridge_atomic_enable() accepts
conn_state->hdmi.tmds_char_rate without verifying it against the PHY's
actual output frequency.

Option A (no display disruption):

  The HDPTX PHY PLL is already registered as a clock provider. On
  RK3576, rk3576.dtsi gives the hdptxphy node #clock-cells = <0>;
  VOP2 consumes it as "pll_hdmiphy0". If the bridge driver adds a
  new clk pointer (e.g. hdmi->tmds_clk) populated via
  devm_clk_get_optional() at probe and queries clk_get_rate()
  in bridge_atomic_enable(), it can detect the seamless-handoff
  mismatch and use the actual rate:

      /* hdmi->tmds_clk added in struct dw_hdmi_qp; populated at
       * probe via devm_clk_get_optional(dev, "tmds") or similar */
      actual_rate = hdmi->tmds_clk ? clk_get_rate(hdmi->tmds_clk) : 0;
      if (actual_rate && actual_rate != conn_state->hdmi.tmds_char_rate) {
          dev_warn(hdmi->dev,
              "seamless handoff: PHY at %lu Hz, DRM selected %llu Hz; "
              "using actual PHY rate for audio\n",
              actual_rate, conn_state->hdmi.tmds_char_rate);
          hdmi->tmds_char_rate = actual_rate;
      } else {
          hdmi->tmds_char_rate = conn_state->hdmi.tmds_char_rate;
      }

  This corrects the ACR CTS and AVI InfoFrame without touching the
  PHY configuration or causing a display blank.

Option B (correct but causes brief blank):

  If the driver detects a mismatch, call phy.ops->init() to bring
  the PHY into agreement with the DRM-negotiated state. All
  parameters become consistent at the cost of a single mode change
  on first enable after seamless handoff. This is arguably the more
  correct approach if the intent is to honour what the EDID reports.

Option A is preferred for a seamless user experience. Option B is
preferable if the seamless-handoff-inherited U-Boot mode is not
otherwise suitable for production use.


Relation to Collabora's HDMI 2.0 patch series
----------------------------------------------

The "Add HDMI 2.0 support to DW HDMI QP TX" series (v3, January 2026)
addresses high-TMDS-clock-ratio and scrambling. It does not appear to
address the seamless-handoff tmds_char_rate mismatch described here.
If a revision of that series reads PHY state at probe time it may
incidentally close this gap, but that is not a stated goal. Reviewers
may wish to verify the seamless-handoff path is exercised in testing.


Summary
-------

  Bug:        bridge_atomic_enable() takes EDID-negotiated
              tmds_char_rate (185,625,000) while PHY runs at U-Boot
              rate (148,500,000); the AVI InfoFrame and the ACR CTS
              both reflect the connector-state nominal value, but
              the wire TMDS clock disagrees with what AVI declares
  Symptom:    audio silent on any HDMI 2.1 sink that cross-checks
              wire TMDS against the AVI declaration; HDMI 2.0 sinks
              unaffected (no such cross-check)
  Scope:      RK3576 confirmed; RK3588 structurally identical
  Not a bug:  N/CTS table, IEC60958 channel status, ARC, ALSA path
  Workaround: reject 185,625,000 Hz in tmds_char_rate_valid() so
              DRM picks 8-bit 1080p (148,500,000 Hz) which matches
              the actual PHY rate
  Fix:        compare conn_state->hdmi.tmds_char_rate against actual
              PHY clock at bridge_atomic_enable() and use the
              measured rate when they disagree (Option A) or
              reconfigure the PHY (Option B)

I am happy to test patches on Sige5 + LG G3.

Regards,
Simon
Symple Solutions, Dunedin, New Zealand

_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

Re: drm/bridge: dw-hdmi-qp: seamless handoff sets wrong tmds_char_rate, breaking audio on strict HDMI 2.1 sinks

[Cristian Ciocaltea]

Hi Simon,

Thanks for the detailed bug report!

I submitted a while ago a patch series [1] providing clock fixes (among others)
to samsung-hdptx PHY driver, but sadly it hasn't been merged yet.

I think this should also address your audio issue, hence please give it a try
and let me know how it goes.

Regards,
Cristian

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

On 5/5/26 11:18 AM, Simon Wright wrote:
> [Resent in plain text — first attempt was rejected by the list's HTML filter.]
> 
> Hi,
> 
> I have tracked down a bug in dw-hdmi-qp that silences audio on strict
> HDMI 2.1 sinks (tested: LG G3 OLED) when booting with HDMI seamless
> handoff from U-Boot. HDMI 2.0 sinks are unaffected. The root cause is
> a mismatch between the AVI InfoFrame colour depth and the ACR embedded
> CTS value.
> 
> Hardware tested:
>   Source:       ArmSoM Sige5 (Rockchip RK3576)
>                 Armbian-edge kernel 7.0.2 (Linux mainline v7.0 plus
>                 Armbian board-enable patches; not a BSP kernel)
>   Failing sink: LG G3 OLED 4K (HDMI 2.1, strict embedded-CTS mode)
>   Passing sink: Various HDMI 2.0 TVs (self-measuring CTS, unaffected)
> 
> The bug is structural and is expected to affect RK3588 under the same
> boot sequence.
> 
> 
> Root cause
> ----------
> 
> When the system boots with seamless handoff active, U-Boot has configured
> the PHY for 8-bit 1080p60 (TMDS = 148,500,000 Hz). The DRM connector
> state, negotiated from EDID, selects 10-bit deep colour (TMDS =
> 185,625,000 Hz). In dw_hdmi_qp_bridge_atomic_enable():
> 
>     hdmi->tmds_char_rate = conn_state->hdmi.tmds_char_rate;
> 
> This stores 185,625,000. The PHY ops->init() is called but the PHY is
> already running at 148,500,000 from U-Boot and is not reconfigured.
> 
> The result is an inconsistency between what the sink is told over HDMI
> and what the wire actually carries:
> 
>   AVI InfoFrame:     declares 10-bit deep colour at the connector-state
>                      TMDS rate (185.625 MHz)
>   ACR embedded CTS:  driver uses hdmi->tmds_char_rate = 185,625,000 Hz
>                      to compute CTS via dw_hdmi_qp_set_sample_rate(),
>                      producing CTS = 185,625 (internally consistent
>                      with the AVI declaration)
>   Wire TMDS clock:   PHY untouched from U-Boot, still running at
>                      148,500,000 Hz (8-bit)
> 
> The dmesg signature (full pr_err output, lower in this report) confirms
> both AVI and ACR are computed from the nominal 185.625 MHz value:
> "tmds=185625000 ... cts=185625".
> 
> A standard HDMI 2.0 sink does not cross-check AVI against the wire TMDS
> in any way that matters for audio, so the mismatch is harmless. A strict
> HDMI 2.1 sink (LG G3) measures the wire TMDS and verifies it matches the
> AVI declaration; with declared 185.625 MHz vs measured 148.5 MHz, the
> check fails and audio is muted, permanently, until the next mode set.
> 
> The N/CTS values themselves are correct CEA-861 ratios. At a wire TMDS
> of 148.5 MHz with N=6144, CTS=148,500 yields f_audio = 48 kHz; at a
> wire TMDS of 185.625 MHz with N=6144, CTS=185,625 also yields f_audio
> = 48 kHz. The driver picks one TMDS, computes a self-consistent N/CTS
> pair, and embeds it. The bug is solely that the TMDS the driver picks
> (connector-state nominal) differs from the TMDS on the wire (PHY
> actual).
> 
> 
> Dmesg diagnostic signature
> --------------------------
> 
> Failing (seamless handoff, DRM selects 10-bit 1080p from EDID):
> 
>     dwhdmiqp-rockchip 27da0000.hdmi: atomic_enable: \
>         tmds_candidate=185625000 is_hdmi=1
>     DW_HDMI_QP set_sample_rate: tmds=185625000 sr=48000 n=6144 cts=185625
>     [audio silent on LG G3]
> 
> Working (8-bit mode forced, see workaround below):
> 
>     dwhdmiqp-rockchip 27da0000.hdmi: atomic_enable: \
>         tmds_candidate=148500000 is_hdmi=1
>     DW_HDMI_QP set_sample_rate: tmds=148500000 sr=48000 n=6144 cts=148500
>     [audio working on LG G3]
> 
> The difference is entirely in which tmds_char_rate bridge_atomic_enable()
> receives. If the PHY and DRM state agree (both 148.5 MHz), audio works
> because what the AVI declares matches what the wire carries. If they
> disagree (DRM: 185.625 MHz, PHY: 148.5 MHz), the AVI declares 185.625
> but the wire carries 148.5, and any sink that cross-checks the wire
> TMDS against the declared rate (e.g. LG G3 OLED) mutes audio.
> 
> 
> Confirmed workaround
> --------------------
> 
> In dw_hdmi_qp_bridge_tmds_char_rate_valid(), reject 185,625,000 Hz:
> 
>     if (rate == 185625000)
>         return MODE_CLOCK_HIGH;
> 
> This forces DRM to select 8-bit mode (148,500,000 Hz). bridge_atomic_enable()
> then stores the correct tmds_char_rate, the AVI InfoFrame declares 8-bit,
> the ACR CTS is computed correctly, and the LG G3 produces audio.
> 
> Note: 185,625,000 Hz (1080p@60 10-bit) is only selected via EDID
> negotiation during seamless handoff. A genuine modeset at that rate would
> correctly reconfigure the PHY and the AVI/ACR inconsistency would not
> arise. Blocking this rate in tmds_char_rate_valid() therefore has no
> correct-use-case cost on RK3576 with the current BSP. 4K@60Hz (594 MHz)
> is unaffected and continues to work correctly, including audio.
> 
> 
> Proposed proper fix
> -------------------
> 
> The fundamental issue is that bridge_atomic_enable() accepts
> conn_state->hdmi.tmds_char_rate without verifying it against the PHY's
> actual output frequency.
> 
> Option A (no display disruption):
> 
>   The HDPTX PHY PLL is already registered as a clock provider. On
>   RK3576, rk3576.dtsi gives the hdptxphy node #clock-cells = <0>;
>   VOP2 consumes it as "pll_hdmiphy0". If the bridge driver adds a
>   new clk pointer (e.g. hdmi->tmds_clk) populated via
>   devm_clk_get_optional() at probe and queries clk_get_rate()
>   in bridge_atomic_enable(), it can detect the seamless-handoff
>   mismatch and use the actual rate:
> 
>       /* hdmi->tmds_clk added in struct dw_hdmi_qp; populated at
>        * probe via devm_clk_get_optional(dev, "tmds") or similar */
>       actual_rate = hdmi->tmds_clk ? clk_get_rate(hdmi->tmds_clk) : 0;
>       if (actual_rate && actual_rate != conn_state->hdmi.tmds_char_rate) {
>           dev_warn(hdmi->dev,
>               "seamless handoff: PHY at %lu Hz, DRM selected %llu Hz; "
>               "using actual PHY rate for audio\n",
>               actual_rate, conn_state->hdmi.tmds_char_rate);
>           hdmi->tmds_char_rate = actual_rate;
>       } else {
>           hdmi->tmds_char_rate = conn_state->hdmi.tmds_char_rate;
>       }
> 
>   This corrects the ACR CTS and AVI InfoFrame without touching the
>   PHY configuration or causing a display blank.
> 
> Option B (correct but causes brief blank):
> 
>   If the driver detects a mismatch, call phy.ops->init() to bring
>   the PHY into agreement with the DRM-negotiated state. All
>   parameters become consistent at the cost of a single mode change
>   on first enable after seamless handoff. This is arguably the more
>   correct approach if the intent is to honour what the EDID reports.
> 
> Option A is preferred for a seamless user experience. Option B is
> preferable if the seamless-handoff-inherited U-Boot mode is not
> otherwise suitable for production use.
> 
> 
> Relation to Collabora's HDMI 2.0 patch series
> ----------------------------------------------
> 
> The "Add HDMI 2.0 support to DW HDMI QP TX" series (v3, January 2026)
> addresses high-TMDS-clock-ratio and scrambling. It does not appear to
> address the seamless-handoff tmds_char_rate mismatch described here.
> If a revision of that series reads PHY state at probe time it may
> incidentally close this gap, but that is not a stated goal. Reviewers
> may wish to verify the seamless-handoff path is exercised in testing.
> 
> 
> Summary
> -------
> 
>   Bug:        bridge_atomic_enable() takes EDID-negotiated
>               tmds_char_rate (185,625,000) while PHY runs at U-Boot
>               rate (148,500,000); the AVI InfoFrame and the ACR CTS
>               both reflect the connector-state nominal value, but
>               the wire TMDS clock disagrees with what AVI declares
>   Symptom:    audio silent on any HDMI 2.1 sink that cross-checks
>               wire TMDS against the AVI declaration; HDMI 2.0 sinks
>               unaffected (no such cross-check)
>   Scope:      RK3576 confirmed; RK3588 structurally identical
>   Not a bug:  N/CTS table, IEC60958 channel status, ARC, ALSA path
>   Workaround: reject 185,625,000 Hz in tmds_char_rate_valid() so
>               DRM picks 8-bit 1080p (148,500,000 Hz) which matches
>               the actual PHY rate
>   Fix:        compare conn_state->hdmi.tmds_char_rate against actual
>               PHY clock at bridge_atomic_enable() and use the
>               measured rate when they disagree (Option A) or
>               reconfigure the PHY (Option B)
> 
> I am happy to test patches on Sige5 + LG G3.
> 
> Regards,
> Simon
> Symple Solutions, Dunedin, New Zealand


_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

Re: drm/bridge: dw-hdmi-qp: seamless handoff sets wrong tmds_char_rate, breaking audio on strict HDMI 2.1 sinks

[Simon Wright]

Hi Cristian,

Thanks for the pointer. Quick test results before writing back.

Test rig: NanoPi R76S (RK3576) on Armbian-edge mainline 7.0.1, LG G3
OLED sink (the same strict HDMI 2.1 sink that surfaced the original
audio bug). Stack: hdptx-clk-fixes v1 + frl-enable-gpios v2 patch 3/13
+ SCDC v5 patch 5 (hand-ported to v7.0; `.detect` kept instead of
`.detect_ctx` so the OOT module loads against unpatched vmlinux).

Tested-by for hdptx-clk-fixes v1: dmesg shows phy_configure /
phy_power_on / atomic_enable consistent at rate=185625000 bpc=10 with
no recalc drift -- exactly what the cover letter promises. Happy to
add the trailer to the v1 cover and any individual patch.

That said, audio still mutes at high-bpc / high-TMDS rates on the
LG G3 even with your series applied:

    1080p60  8-bit (148.5  MHz): audio plays  -- already worked
    1080p60 10-bit (185.625 MHz): muted        -- original bug regime
    4K@60   8-bit (594.0  MHz):  muted        -- production cast path

The "muted" rates are precisely those not in `common_tmds_cts_table[]`.
For those, `dw_hdmi_qp_find_cts()` returns 0, the override path is
skipped, and the QP IP falls back to its auto-CTS measurement -- which
the LG G3 cross-check rejects. The BSP-derived dw-hdmi-qp.c
(develop-6.6) carries an in-source comment attributing this to the
auto-circuit measuring at half the actual TMDS rate; I haven't read
that register out myself to confirm the specific value, so I can only
report that empirically the override path with explicit CTS works on
the LG G3 and the bare auto path doesn't.

The fix is to compute CTS from N when the table misses, and feed it
through the standard override path. Six lines + comment in
`dw_hdmi_qp_set_sample_rate()`, between find_cts() and set_cts_n():

    /*
     * When no CTS table entry exists for the given TMDS rate, compute
     * CTS from N rather than relying on the IP's auto-measure path,
     * which mis-measures on this controller at high TMDS rates and
     * produces incorrect ACR timing on strict HDMI 2.1 sinks.
     * Computed CTS = (TMDS * N) / (128 * Fs) per HDMI spec.
     */
    if (!cts && n) {
        u64 computed = (u64)tmds_char_rate * n;
        do_div(computed, 128ULL * sample_rate);
        cts = (unsigned int)computed;
    }

With this on top of your series, all three regimes above play audio
cleanly -- including the 1080p 10-bit case from my original bug
report and the 4K@60 path on our production cast rig.

That makes my earlier rate-block patch
(linux-rockchip 2026-May/070673) redundant -- I'm happy to withdraw
it on its thread once you've decided where the CTS-from-N fix should
land.

Two questions:

1. Where would you like the CTS-from-N fix? Its own small thread, a
   trailer on hdptx-clk-fixes, or folded into the SCDC series --
   whichever fits your workflow.

2. The kernel 7.0 announcement flagged controller-side FRL as "not
   yet landed". Is that still on Collabora's roadmap, or open for me
   to send a develop-6.6-derived prototype as RFC once I've ported it
   to mainline? Happy to wait if you have a series in flight.

Reproducer for the audio fix is the stack above plus a small libdrm
helper to hold the mode against fbcon (modetest releases DRM master
on exit). I can share the helper if useful.

Sige5/Sige7 DTS follow-ups to your frl-enable-gpios v2 series are in
draft against the schematics; both boards are on order so I'll
validate on my own hardware before sending. I'll start a separate
thread on the v2 series for those rather than burying them here.

Thanks again -- the pointer saved a lot of parallel debug time, and
the controller-side gap was small once pinned down.

Regards,
Simon
Symple Solutions, Dunedin, New Zealand


________________________________________
From: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Sent: Wednesday, 6 May 2026 8:01 am
To: Simon Wright <Simon@symple.nz>; linux-rockchip@lists.infradead.org <linux-rockchip@lists.infradead.org>
Cc: dri-devel@lists.freedesktop.org <dri-devel@lists.freedesktop.org>; kernel@collabora.com <kernel@collabora.com>
Subject: Re: drm/bridge: dw-hdmi-qp: seamless handoff sets wrong tmds_char_rate, breaking audio on strict HDMI 2.1 sinks
 
Hi Simon,

Thanks for the detailed bug report!

I submitted a while ago a patch series [1] providing clock fixes (among others)
to samsung-hdptx PHY driver, but sadly it hasn't been merged yet.

I think this should also address your audio issue, hence please give it a try
and let me know how it goes.

Regards,
Cristian

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

On 5/5/26 11:18 AM, Simon Wright wrote:
> [Resent in plain text — first attempt was rejected by the list's HTML filter.]
>
> Hi,
>
> I have tracked down a bug in dw-hdmi-qp that silences audio on strict
> HDMI 2.1 sinks (tested: LG G3 OLED) when booting with HDMI seamless
> handoff from U-Boot. HDMI 2.0 sinks are unaffected. The root cause is
> a mismatch between the AVI InfoFrame colour depth and the ACR embedded
> CTS value.
>
> Hardware tested:
>   Source:       ArmSoM Sige5 (Rockchip RK3576)
>                 Armbian-edge kernel 7.0.2 (Linux mainline v7.0 plus
>                 Armbian board-enable patches; not a BSP kernel)
>   Failing sink: LG G3 OLED 4K (HDMI 2.1, strict embedded-CTS mode)
>   Passing sink: Various HDMI 2.0 TVs (self-measuring CTS, unaffected)
>
> The bug is structural and is expected to affect RK3588 under the same
> boot sequence.
>
>
> Root cause
> ----------
>
> When the system boots with seamless handoff active, U-Boot has configured
> the PHY for 8-bit 1080p60 (TMDS = 148,500,000 Hz). The DRM connector
> state, negotiated from EDID, selects 10-bit deep colour (TMDS =
> 185,625,000 Hz). In dw_hdmi_qp_bridge_atomic_enable():
>
>     hdmi->tmds_char_rate = conn_state->hdmi.tmds_char_rate;
>
> This stores 185,625,000. The PHY ops->init() is called but the PHY is
> already running at 148,500,000 from U-Boot and is not reconfigured.
>
> The result is an inconsistency between what the sink is told over HDMI
> and what the wire actually carries:
>
>   AVI InfoFrame:     declares 10-bit deep colour at the connector-state
>                      TMDS rate (185.625 MHz)
>   ACR embedded CTS:  driver uses hdmi->tmds_char_rate = 185,625,000 Hz
>                      to compute CTS via dw_hdmi_qp_set_sample_rate(),
>                      producing CTS = 185,625 (internally consistent
>                      with the AVI declaration)
>   Wire TMDS clock:   PHY untouched from U-Boot, still running at
>                      148,500,000 Hz (8-bit)
>
> The dmesg signature (full pr_err output, lower in this report) confirms
> both AVI and ACR are computed from the nominal 185.625 MHz value:
> "tmds=185625000 ... cts=185625".
>
> A standard HDMI 2.0 sink does not cross-check AVI against the wire TMDS
> in any way that matters for audio, so the mismatch is harmless. A strict
> HDMI 2.1 sink (LG G3) measures the wire TMDS and verifies it matches the
> AVI declaration; with declared 185.625 MHz vs measured 148.5 MHz, the
> check fails and audio is muted, permanently, until the next mode set.
>
> The N/CTS values themselves are correct CEA-861 ratios. At a wire TMDS
> of 148.5 MHz with N=6144, CTS=148,500 yields f_audio = 48 kHz; at a
> wire TMDS of 185.625 MHz with N=6144, CTS=185,625 also yields f_audio
> = 48 kHz. The driver picks one TMDS, computes a self-consistent N/CTS
> pair, and embeds it. The bug is solely that the TMDS the driver picks
> (connector-state nominal) differs from the TMDS on the wire (PHY
> actual).
>
>
> Dmesg diagnostic signature
> --------------------------
>
> Failing (seamless handoff, DRM selects 10-bit 1080p from EDID):
>
>     dwhdmiqp-rockchip 27da0000.hdmi: atomic_enable: \
>         tmds_candidate=185625000 is_hdmi=1
>     DW_HDMI_QP set_sample_rate: tmds=185625000 sr=48000 n=6144 cts=185625
>     [audio silent on LG G3]
>
> Working (8-bit mode forced, see workaround below):
>
>     dwhdmiqp-rockchip 27da0000.hdmi: atomic_enable: \
>         tmds_candidate=148500000 is_hdmi=1
>     DW_HDMI_QP set_sample_rate: tmds=148500000 sr=48000 n=6144 cts=148500
>     [audio working on LG G3]
>
> The difference is entirely in which tmds_char_rate bridge_atomic_enable()
> receives. If the PHY and DRM state agree (both 148.5 MHz), audio works
> because what the AVI declares matches what the wire carries. If they
> disagree (DRM: 185.625 MHz, PHY: 148.5 MHz), the AVI declares 185.625
> but the wire carries 148.5, and any sink that cross-checks the wire
> TMDS against the declared rate (e.g. LG G3 OLED) mutes audio.
>
>
> Confirmed workaround
> --------------------
>
> In dw_hdmi_qp_bridge_tmds_char_rate_valid(), reject 185,625,000 Hz:
>
>     if (rate == 185625000)
>         return MODE_CLOCK_HIGH;
>
> This forces DRM to select 8-bit mode (148,500,000 Hz). bridge_atomic_enable()
> then stores the correct tmds_char_rate, the AVI InfoFrame declares 8-bit,
> the ACR CTS is computed correctly, and the LG G3 produces audio.
>
> Note: 185,625,000 Hz (1080p@60 10-bit) is only selected via EDID
> negotiation during seamless handoff. A genuine modeset at that rate would
> correctly reconfigure the PHY and the AVI/ACR inconsistency would not
> arise. Blocking this rate in tmds_char_rate_valid() therefore has no
> correct-use-case cost on RK3576 with the current BSP. 4K@60Hz (594 MHz)
> is unaffected and continues to work correctly, including audio.
>
>
> Proposed proper fix
> -------------------
>
> The fundamental issue is that bridge_atomic_enable() accepts
> conn_state->hdmi.tmds_char_rate without verifying it against the PHY's
> actual output frequency.
>
> Option A (no display disruption):
>
>   The HDPTX PHY PLL is already registered as a clock provider. On
>   RK3576, rk3576.dtsi gives the hdptxphy node #clock-cells = <0>;
>   VOP2 consumes it as "pll_hdmiphy0". If the bridge driver adds a
>   new clk pointer (e.g. hdmi->tmds_clk) populated via
>   devm_clk_get_optional() at probe and queries clk_get_rate()
>   in bridge_atomic_enable(), it can detect the seamless-handoff
>   mismatch and use the actual rate:
>
>       /* hdmi->tmds_clk added in struct dw_hdmi_qp; populated at
>        * probe via devm_clk_get_optional(dev, "tmds") or similar */
>       actual_rate = hdmi->tmds_clk ? clk_get_rate(hdmi->tmds_clk) : 0;
>       if (actual_rate && actual_rate != conn_state->hdmi.tmds_char_rate) {
>           dev_warn(hdmi->dev,
>               "seamless handoff: PHY at %lu Hz, DRM selected %llu Hz; "
>               "using actual PHY rate for audio\n",
>               actual_rate, conn_state->hdmi.tmds_char_rate);
>           hdmi->tmds_char_rate = actual_rate;
>       } else {
>           hdmi->tmds_char_rate = conn_state->hdmi.tmds_char_rate;
>       }
>
>   This corrects the ACR CTS and AVI InfoFrame without touching the
>   PHY configuration or causing a display blank.
>
> Option B (correct but causes brief blank):
>
>   If the driver detects a mismatch, call phy.ops->init() to bring
>   the PHY into agreement with the DRM-negotiated state. All
>   parameters become consistent at the cost of a single mode change
>   on first enable after seamless handoff. This is arguably the more
>   correct approach if the intent is to honour what the EDID reports.
>
> Option A is preferred for a seamless user experience. Option B is
> preferable if the seamless-handoff-inherited U-Boot mode is not
> otherwise suitable for production use.
>
>
> Relation to Collabora's HDMI 2.0 patch series
> ----------------------------------------------
>
> The "Add HDMI 2.0 support to DW HDMI QP TX" series (v3, January 2026)
> addresses high-TMDS-clock-ratio and scrambling. It does not appear to
> address the seamless-handoff tmds_char_rate mismatch described here.
> If a revision of that series reads PHY state at probe time it may
> incidentally close this gap, but that is not a stated goal. Reviewers
> may wish to verify the seamless-handoff path is exercised in testing.
>
>
> Summary
> -------
>
>   Bug:        bridge_atomic_enable() takes EDID-negotiated
>               tmds_char_rate (185,625,000) while PHY runs at U-Boot
>               rate (148,500,000); the AVI InfoFrame and the ACR CTS
>               both reflect the connector-state nominal value, but
>               the wire TMDS clock disagrees with what AVI declares
>   Symptom:    audio silent on any HDMI 2.1 sink that cross-checks
>               wire TMDS against the AVI declaration; HDMI 2.0 sinks
>               unaffected (no such cross-check)
>   Scope:      RK3576 confirmed; RK3588 structurally identical
>   Not a bug:  N/CTS table, IEC60958 channel status, ARC, ALSA path
>   Workaround: reject 185,625,000 Hz in tmds_char_rate_valid() so
>               DRM picks 8-bit 1080p (148,500,000 Hz) which matches
>               the actual PHY rate
>   Fix:        compare conn_state->hdmi.tmds_char_rate against actual
>               PHY clock at bridge_atomic_enable() and use the
>               measured rate when they disagree (Option A) or
>               reconfigure the PHY (Option B)
>
> I am happy to test patches on Sige5 + LG G3.
>
> Regards,
> Simon
> Symple Solutions, Dunedin, New Zealand

_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

Re: drm/bridge: dw-hdmi-qp: seamless handoff sets wrong tmds_char_rate, breaking audio on strict HDMI 2.1 sinks

[Cristian Ciocaltea]

Hi Simon,

On 5/7/26 1:39 PM, Simon Wright wrote:
> Hi Cristian,
> 
> Thanks for the pointer. Quick test results before writing back.
> 
> Test rig: NanoPi R76S (RK3576) on Armbian-edge mainline 7.0.1, LG G3
> OLED sink (the same strict HDMI 2.1 sink that surfaced the original
> audio bug). Stack: hdptx-clk-fixes v1 + frl-enable-gpios v2 patch 3/13
> + SCDC v5 patch 5 (hand-ported to v7.0; `.detect` kept instead of
> `.detect_ctx` so the OOT module loads against unpatched vmlinux).
> 
> Tested-by for hdptx-clk-fixes v1: dmesg shows phy_configure /
> phy_power_on / atomic_enable consistent at rate=185625000 bpc=10 with
> no recalc drift -- exactly what the cover letter promises. Happy to
> add the trailer to the v1 cover and any individual patch.

Please provide the trailer and maybe also a kind reminder for the maintainers to
get the series applied.. :-)

> 
> That said, audio still mutes at high-bpc / high-TMDS rates on the
> LG G3 even with your series applied:
> 
>     1080p60  8-bit (148.5  MHz): audio plays  -- already worked
>     1080p60 10-bit (185.625 MHz): muted        -- original bug regime
>     4K@60   8-bit (594.0  MHz):  muted        -- production cast path
> 
> The "muted" rates are precisely those not in `common_tmds_cts_table[]`.
> For those, `dw_hdmi_qp_find_cts()` returns 0, the override path is
> skipped, and the QP IP falls back to its auto-CTS measurement -- which
> the LG G3 cross-check rejects. The BSP-derived dw-hdmi-qp.c
> (develop-6.6) carries an in-source comment attributing this to the
> auto-circuit measuring at half the actual TMDS rate; I haven't read
> that register out myself to confirm the specific value, so I can only
> report that empirically the override path with explicit CTS works on
> the LG G3 and the bare auto path doesn't.
> 
> The fix is to compute CTS from N when the table misses, and feed it
> through the standard override path. Six lines + comment in
> `dw_hdmi_qp_set_sample_rate()`, between find_cts() and set_cts_n():
> 
>     /*
>      * When no CTS table entry exists for the given TMDS rate, compute
>      * CTS from N rather than relying on the IP's auto-measure path,
>      * which mis-measures on this controller at high TMDS rates and
>      * produces incorrect ACR timing on strict HDMI 2.1 sinks.
>      * Computed CTS = (TMDS * N) / (128 * Fs) per HDMI spec.
>      */
>     if (!cts && n) {
>         u64 computed = (u64)tmds_char_rate * n;
>         do_div(computed, 128ULL * sample_rate);
>         cts = (unsigned int)computed;
>     }
> 
> With this on top of your series, all three regimes above play audio
> cleanly -- including the 1080p 10-bit case from my original bug
> report and the 4K@60 path on our production cast rig.
> 
> That makes my earlier rate-block patch
> (linux-rockchip 2026-May/070673) redundant -- I'm happy to withdraw
> it on its thread once you've decided where the CTS-from-N fix should
> land.

Nice catch, will try to reproduce this on my end. 

Regardless, the fix should be submitted as a separate patch, as it's not
(directly) related to any of the existing serieses posted on ML. 
I.e. you mentioned "... mis-measures on this controller at high TMDS rates", but
the 1080p60 10-bit (185.625 MHz) use case falls under HDMI 1.4, hence the
problem doesn't seem to be limited to HDMI 2.x.

> 
> Two questions:
> 
> 1. Where would you like the CTS-from-N fix? Its own small thread, 

Yep, dedicated submission, per the above.

a
>    trailer on hdptx-clk-fixes, or folded into the SCDC series --
>    whichever fits your workflow.
> 
> 2. The kernel 7.0 announcement flagged controller-side FRL as "not
>    yet landed". Is that still on Collabora's roadmap

Yes, I'm currently preparing a new revision of the HDMI 2.0 patchset, then I
will focus on the HDMI 2.1 FRL support. The latest version of these patches is
already available in our rockchip-devel branch, which contains all the
necessary dependencies:

 https://gitlab.collabora.com/hardware-enablement/rockchip-3588/linux/-/commits/rockchip-devel?ref_type=heads

> , or open for me
>    to send a develop-6.6-derived prototype as RFC once I've ported it
>    to mainline? Happy to wait if you have a series in flight.
> 
> Reproducer for the audio fix is the stack above plus a small libdrm
> helper to hold the mode against fbcon (modetest releases DRM master
> on exit). I can share the helper if useful.

Yes, please detail the reproducer steps.  So far, I've only tried playing audio
using speaker-test while switching the modes via modetest and it works as
expected.

> 
> Sige5/Sige7 DTS follow-ups to your frl-enable-gpios v2 series are in
> draft against the schematics; both boards are on order so I'll
> validate on my own hardware before sending. I'll start a separate
> thread on the v2 series for those rather than burying them here.

That series has been applied and is available in linux-next since next-20260506.
It also handles the rk3576-armsom-sige5 board, do you need anything else for
this particular one?

Regards,
Cristian

_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

Re: drm/bridge: dw-hdmi-qp: seamless handoff sets wrong tmds_char_rate, breaking audio on strict HDMI 2.1 sinks

[Simon Wright]

Hi Cristian,

Thanks for the pointers -- I should have checked rockchip-devel
before the previous reply. Three things to clean up:

* Sige5 in linux-next and Sige7 in rockchip-devel both match what I'd
  derived from the schematics -- dropping the DTS follow-ups I had
  drafted.

* Your FRL work in rockchip-devel supersedes the BSP-derived prototype
  I was going to port. Standing down on that; happy to Tested-by the
  series once it's posted.

* Acknowledged on the HDMI 1.4 vs 2.x framing.

Tested-by: Simon Wright <simon@symple.nz>

Heiko, Vinod -- any chance hdptx-clk-fixes v1 can be applied? It
cleanly addresses the high-bpc rate recalculation and uncommitted PHY
config issues on RK3576 hdptx, and Tested-by results on real hardware
(R76S + LG G3 OLED) match the cover letter.

Reproducer for the audio mute:

  1. mainline 7.0 + hdptx-clk-fixes v1 applied (or rockchip-devel HEAD
     -- same code path).
  2. Sink that doesn't tolerate incorrect ACR CTS values -- LG G3 OLED
     is the canonical case, LG C4 OLED behaves identically. More-
     permissive sinks play audio regardless and won't surface the bug.
  3. Set a mode whose tmds_char_rate is NOT in common_tmds_cts_table[].
     Affected rates we tested: 1920x1080@60 bpc=10 (185.625 MHz, the
     original-bug regime -- requires max_bpc=10 set on the connector
     property), 3840x2160@30 8-bit (297 MHz), and 3840x2160@60 8-bit
     (594 MHz).
  4. The mode must be held for the duration of the audio test --
     `modetest -s` releases DRM master on exit and fbcon reverts to
     an in-table mode, which would explain audio playing in your
     test path.
  5. speaker-test -D hw:0,0 -c 2 -t sine -f 440 -- mutes without the
     fix, plays with it.

I'll send the CTS-from-N change as a separate patch against
rockchip-devel, and withdraw the rate-block patch
(linux-rockchip 2026-May/070673) once it's accepted in some form.

Regards,
Simon
Symple Solutions, Dunedin, New Zealand

________________________________________
From: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Sent: Friday, 8 May 2026 6:03 am
To: Simon Wright <Simon@symple.nz>; linux-rockchip@lists.infradead.org <linux-rockchip@lists.infradead.org>
Cc: dri-devel@lists.freedesktop.org <dri-devel@lists.freedesktop.org>; kernel@collabora.com <kernel@collabora.com>
Subject: Re: drm/bridge: dw-hdmi-qp: seamless handoff sets wrong tmds_char_rate, breaking audio on strict HDMI 2.1 sinks
 
Hi Simon,

On 5/7/26 1:39 PM, Simon Wright wrote:
> Hi Cristian,
>
> Thanks for the pointer. Quick test results before writing back.
>
> Test rig: NanoPi R76S (RK3576) on Armbian-edge mainline 7.0.1, LG G3
> OLED sink (the same strict HDMI 2.1 sink that surfaced the original
> audio bug). Stack: hdptx-clk-fixes v1 + frl-enable-gpios v2 patch 3/13
> + SCDC v5 patch 5 (hand-ported to v7.0; `.detect` kept instead of
> `.detect_ctx` so the OOT module loads against unpatched vmlinux).
>
> Tested-by for hdptx-clk-fixes v1: dmesg shows phy_configure /
> phy_power_on / atomic_enable consistent at rate=185625000 bpc=10 with
> no recalc drift -- exactly what the cover letter promises. Happy to
> add the trailer to the v1 cover and any individual patch.

Please provide the trailer and maybe also a kind reminder for the maintainers to
get the series applied.. :-)

>
> That said, audio still mutes at high-bpc / high-TMDS rates on the
> LG G3 even with your series applied:
>
>     1080p60  8-bit (148.5  MHz): audio plays  -- already worked
>     1080p60 10-bit (185.625 MHz): muted        -- original bug regime
>     4K@60   8-bit (594.0  MHz):  muted        -- production cast path
>
> The "muted" rates are precisely those not in `common_tmds_cts_table[]`.
> For those, `dw_hdmi_qp_find_cts()` returns 0, the override path is
> skipped, and the QP IP falls back to its auto-CTS measurement -- which
> the LG G3 cross-check rejects. The BSP-derived dw-hdmi-qp.c
> (develop-6.6) carries an in-source comment attributing this to the
> auto-circuit measuring at half the actual TMDS rate; I haven't read
> that register out myself to confirm the specific value, so I can only
> report that empirically the override path with explicit CTS works on
> the LG G3 and the bare auto path doesn't.
>
> The fix is to compute CTS from N when the table misses, and feed it
> through the standard override path. Six lines + comment in
> `dw_hdmi_qp_set_sample_rate()`, between find_cts() and set_cts_n():
>
>     /*
>      * When no CTS table entry exists for the given TMDS rate, compute
>      * CTS from N rather than relying on the IP's auto-measure path,
>      * which mis-measures on this controller at high TMDS rates and
>      * produces incorrect ACR timing on strict HDMI 2.1 sinks.
>      * Computed CTS = (TMDS * N) / (128 * Fs) per HDMI spec.
>      */
>     if (!cts && n) {
>         u64 computed = (u64)tmds_char_rate * n;
>         do_div(computed, 128ULL * sample_rate);
>         cts = (unsigned int)computed;
>     }
>
> With this on top of your series, all three regimes above play audio
> cleanly -- including the 1080p 10-bit case from my original bug
> report and the 4K@60 path on our production cast rig.
>
> That makes my earlier rate-block patch
> (linux-rockchip 2026-May/070673) redundant -- I'm happy to withdraw
> it on its thread once you've decided where the CTS-from-N fix should
> land.

Nice catch, will try to reproduce this on my end.

Regardless, the fix should be submitted as a separate patch, as it's not
(directly) related to any of the existing serieses posted on ML.
I.e. you mentioned "... mis-measures on this controller at high TMDS rates", but
the 1080p60 10-bit (185.625 MHz) use case falls under HDMI 1.4, hence the
problem doesn't seem to be limited to HDMI 2.x.

>
> Two questions:
>
> 1. Where would you like the CTS-from-N fix? Its own small thread,

Yep, dedicated submission, per the above.

a
>    trailer on hdptx-clk-fixes, or folded into the SCDC series --
>    whichever fits your workflow.
>
> 2. The kernel 7.0 announcement flagged controller-side FRL as "not
>    yet landed". Is that still on Collabora's roadmap

Yes, I'm currently preparing a new revision of the HDMI 2.0 patchset, then I
will focus on the HDMI 2.1 FRL support. The latest version of these patches is
already available in our rockchip-devel branch, which contains all the
necessary dependencies:

 https://gitlab.collabora.com/hardware-enablement/rockchip-3588/linux/-/commits/rockchip-devel?ref_type=heads

> , or open for me
>    to send a develop-6.6-derived prototype as RFC once I've ported it
>    to mainline? Happy to wait if you have a series in flight.
>
> Reproducer for the audio fix is the stack above plus a small libdrm
> helper to hold the mode against fbcon (modetest releases DRM master
> on exit). I can share the helper if useful.

Yes, please detail the reproducer steps.  So far, I've only tried playing audio
using speaker-test while switching the modes via modetest and it works as
expected.

>
> Sige5/Sige7 DTS follow-ups to your frl-enable-gpios v2 series are in
> draft against the schematics; both boards are on order so I'll
> validate on my own hardware before sending. I'll start a separate
> thread on the v2 series for those rather than burying them here.

That series has been applied and is available in linux-next since next-20260506.
It also handles the rk3576-armsom-sige5 board, do you need anything else for
this particular one?

Regards,
Cristian
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

Re: drm/bridge: dw-hdmi-qp: seamless handoff sets wrong tmds_char_rate, breaking audio on strict HDMI 2.1 sinks

[Cristian Ciocaltea]

Hi Simon,

On 5/8/26 8:53 AM, Simon Wright wrote:
> Hi Cristian,
> 
> Thanks for the pointers -- I should have checked rockchip-devel
> before the previous reply. Three things to clean up:
> 
> * Sige5 in linux-next and Sige7 in rockchip-devel both match what I'd
>   derived from the schematics -- dropping the DTS follow-ups I had
>   drafted.
> 
> * Your FRL work in rockchip-devel supersedes the BSP-derived prototype
>   I was going to port. Standing down on that; happy to Tested-by the
>   series once it's posted.
> 
> * Acknowledged on the HDMI 1.4 vs 2.x framing.
> 
> Tested-by: Simon Wright <simon@symple.nz>

The trailer must be added by replying to the series containing the patches, i.e.
see the "Reply instructions" at the bottom of:

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

> 
> Heiko, Vinod -- any chance hdptx-clk-fixes v1 can be applied? It
> cleanly addresses the high-bpc rate recalculation and uncommitted PHY
> config issues on RK3576 hdptx, and Tested-by results on real hardware
> (R76S + LG G3 OLED) match the cover letter.

This should also go with the reply above.

> 
> Reproducer for the audio mute:
> 
>   1. mainline 7.0 + hdptx-clk-fixes v1 applied (or rockchip-devel HEAD
>      -- same code path).
>   2. Sink that doesn't tolerate incorrect ACR CTS values -- LG G3 OLED
>      is the canonical case, LG C4 OLED behaves identically. More-
>      permissive sinks play audio regardless and won't surface the bug.
>   3. Set a mode whose tmds_char_rate is NOT in common_tmds_cts_table[].
>      Affected rates we tested: 1920x1080@60 bpc=10 (185.625 MHz, the
>      original-bug regime -- requires max_bpc=10 set on the connector
>      property), 3840x2160@30 8-bit (297 MHz), and 3840x2160@60 8-bit
>      (594 MHz).
>   4. The mode must be held for the duration of the audio test --
>      `modetest -s` releases DRM master on exit and fbcon reverts to
>      an in-table mode, which would explain audio playing in your
>      test path.
>   5. speaker-test -D hw:0,0 -c 2 -t sine -f 440 -- mutes without the
>      fix, plays with it.
> 
> I'll send the CTS-from-N change as a separate patch against
> rockchip-devel, 

Any submitted patches must be based on a recent enough upstream branch or tag -
in this case either v7.1-rc2 [1], next-20260507 [2] or drm-misc-next [3].

[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v7.1-rc2
[2] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tag/?h=next-20260507
[3] https://gitlab.freedesktop.org/drm/misc/kernel/-/commits/drm-misc-next?ref_type=heads

Regards,
Cristian

_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip