[PATCH] drm/dp: Service the CEC tunneling IRQ flags without CEC_IRQ in ESI1

[PATCH] drm/dp: Service the CEC tunneling IRQ flags without CEC_IRQ in ESI1

[Alexander Kaplan]

The DP standard requires a DP-to-HDMI protocol converter to assert
an IRQ_HPD pulse with the CEC_IRQ bit in the
DEVICE_SERVICE_IRQ_VECTOR_ESI1 register set whenever it sets a bit in
the CEC_TUNNELING_IRQ_FLAGS register (DP v2.0, Table 2-194, DPCD
address 3004h).

The Synaptics VMM7100 based DP-to-HDMI protocol converters get this
half right.
They assert an IRQ_HPD pulse for each CEC event, but never set the
CEC_IRQ bit.
ESI1 reads as 0 at the very moment CEC_TUNNELING_IRQ_FLAGS has the
corresponding TX/RX flags set.
drm_dp_cec_irq() trusts the bit and returns without servicing the
flags, so no transmit is ever completed and the CEC adapter is
unusable with these devices.
Every transmit times out, claiming a logical address fails and the
/dev/cecX device ends up unconfigured.
The converter's CEC engine itself works fine.
Driving the CEC tunneling DPCD registers manually shows the TV
ACKing the tunneled messages and sending requests of its own.

Demote the CEC_IRQ bit from a gate to an acknowledge hint: service
the CEC tunneling IRQ flags on every IRQ_HPD pulse, whether or not
the branch device set CEC_IRQ, and acknowledge CEC_IRQ in ESI1 only
when it was actually set.
Servicing is idempotent since every action is keyed to a
write-1-to-clear flag bit, so for branch devices with no pending CEC
event this amounts to one additional AUX read of the flags register,
and only on connectors that advertise the CEC tunneling capability
(without it no CEC adapter is registered and drm_dp_cec_irq()
returns early as before).
Devices that conformantly set CEC_IRQ are serviced exactly as before.

With this the CEC adapter of a VMM7100 based USB-C to HDMI adapter
configures and transmits successfully (verified against an LG OLED
TV with an Intel Panther Lake xe device, including TV power on/off
over CEC).

Fixes: 2c6d1fffa1d9 ("drm: add support for DisplayPort CEC-Tunneling-over-AUX")
Signed-off-by: Alexander Kaplan <alexander.kaplan@sms-medipool.de>
---
This patch is part of a set of independent fixes for the USB-C to DP
to HDMI 2.1 protocol converter (PCON) path, found and verified on an
ASUS NUC 16 Pro (Panther Lake, xe) with Synaptics VMM7100 based
adapters.
Each part stands on its own and can be merged independently.
The other parts:
[1] https://lore.kernel.org/r/20260610174413.5881-1-alexander.kaplan@sms-medipool.de
[2] https://lore.kernel.org/r/20260610174807.6231-1-alexander.kaplan@sms-medipool.de
[3] https://lore.kernel.org/r/20260610174819.6258-1-alexander.kaplan@sms-medipool.de
 drivers/gpu/drm/display/drm_dp_cec.c | 18 ++++++++++++++++--
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/display/drm_dp_cec.c b/drivers/gpu/drm/display/drm_dp_cec.c
index 436bfe9f9081..824a99f86a3d 100644
--- a/drivers/gpu/drm/display/drm_dp_cec.c
+++ b/drivers/gpu/drm/display/drm_dp_cec.c
@@ -218,6 +218,9 @@ static void drm_dp_cec_handle_irq(struct drm_dp_aux *aux)
 	if (drm_dp_dpcd_read_byte(aux, DP_CEC_TUNNELING_IRQ_FLAGS, &flags) < 0)
 		return;
 
+	if (!flags)
+		return;
+
 	if (flags & DP_CEC_RX_MESSAGE_INFO_VALID)
 		drm_dp_cec_received(aux);
 
@@ -255,11 +258,22 @@ void drm_dp_cec_irq(struct drm_dp_aux *aux)
 
 	ret = drm_dp_dpcd_read_byte(aux, DP_DEVICE_SERVICE_IRQ_VECTOR_ESI1,
 				    &cec_irq);
-	if (ret < 0 || !(cec_irq & DP_CEC_IRQ))
+	if (ret < 0)
 		goto unlock;
 
+	/*
+	 * Some branch devices, for instance the Synaptics VMM7100 based
+	 * DP-to-HDMI protocol converters, assert an IRQ_HPD pulse for each
+	 * CEC event, but never set the CEC_IRQ bit in the
+	 * DEVICE_SERVICE_IRQ_VECTOR_ESI1 register. Check the CEC tunneling
+	 * IRQ flags even without CEC_IRQ being set: servicing the flags is
+	 * idempotent and only costs one additional AUX read.
+	 */
 	drm_dp_cec_handle_irq(aux);
-	drm_dp_dpcd_write_byte(aux, DP_DEVICE_SERVICE_IRQ_VECTOR_ESI1, DP_CEC_IRQ);
+
+	if (cec_irq & DP_CEC_IRQ)
+		drm_dp_dpcd_write_byte(aux, DP_DEVICE_SERVICE_IRQ_VECTOR_ESI1,
+				       DP_CEC_IRQ);
 unlock:
 	mutex_unlock(&aux->cec.lock);
 }
-- 
2.54.0

✗ LGCI.VerificationFailed: failure for drm/dp: Service the CEC tunneling IRQ flags without CEC_IRQ in ESI1

[Patchwork]

== Series Details ==

Series: drm/dp: Service the CEC tunneling IRQ flags without CEC_IRQ in ESI1
URL   : https://patchwork.freedesktop.org/series/168283/
State : failure

== Summary ==

Series author address 'alexander.kaplan@sms-medipool.de' is not on the allowlist, which prevents CI from being automatically triggered.
If you want CI to run for this series, ask Patchwork project owners to click 'retest' on the series in Patchwork.
Exception occurred during validation, bailing out!
Build URL: http://gfx-ci.igk.intel.com:8080/job/CI_PW_kernel/179167/ (on built-in)

Re: [PATCH] drm/dp: Service the CEC tunneling IRQ flags without CEC_IRQ in ESI1

[Hans Verkuil]

Hi Alexander,

On 10/06/2026 19:48, Alexander Kaplan wrote:
> The DP standard requires a DP-to-HDMI protocol converter to assert
> an IRQ_HPD pulse with the CEC_IRQ bit in the
> DEVICE_SERVICE_IRQ_VECTOR_ESI1 register set whenever it sets a bit in
> the CEC_TUNNELING_IRQ_FLAGS register (DP v2.0, Table 2-194, DPCD
> address 3004h).
> 
> The Synaptics VMM7100 based DP-to-HDMI protocol converters get this
> half right.
> They assert an IRQ_HPD pulse for each CEC event, but never set the
> CEC_IRQ bit.
> ESI1 reads as 0 at the very moment CEC_TUNNELING_IRQ_FLAGS has the
> corresponding TX/RX flags set.
> drm_dp_cec_irq() trusts the bit and returns without servicing the
> flags, so no transmit is ever completed and the CEC adapter is
> unusable with these devices.
> Every transmit times out, claiming a logical address fails and the
> /dev/cecX device ends up unconfigured.
> The converter's CEC engine itself works fine.
> Driving the CEC tunneling DPCD registers manually shows the TV
> ACKing the tunneled messages and sending requests of its own.
> 
> Demote the CEC_IRQ bit from a gate to an acknowledge hint: service
> the CEC tunneling IRQ flags on every IRQ_HPD pulse, whether or not
> the branch device set CEC_IRQ, and acknowledge CEC_IRQ in ESI1 only
> when it was actually set.
> Servicing is idempotent since every action is keyed to a
> write-1-to-clear flag bit, so for branch devices with no pending CEC
> event this amounts to one additional AUX read of the flags register,
> and only on connectors that advertise the CEC tunneling capability
> (without it no CEC adapter is registered and drm_dp_cec_irq()
> returns early as before).
> Devices that conformantly set CEC_IRQ are serviced exactly as before.
> 
> With this the CEC adapter of a VMM7100 based USB-C to HDMI adapter
> configures and transmits successfully (verified against an LG OLED
> TV with an Intel Panther Lake xe device, including TV power on/off
> over CEC).
> 
> Fixes: 2c6d1fffa1d9 ("drm: add support for DisplayPort CEC-Tunneling-over-AUX")
> Signed-off-by: Alexander Kaplan <alexander.kaplan@sms-medipool.de>
> ---
> This patch is part of a set of independent fixes for the USB-C to DP
> to HDMI 2.1 protocol converter (PCON) path, found and verified on an
> ASUS NUC 16 Pro (Panther Lake, xe) with Synaptics VMM7100 based
> adapters.
> Each part stands on its own and can be merged independently.
> The other parts:
> [1] https://lore.kernel.org/r/20260610174413.5881-1-alexander.kaplan@sms-medipool.de
> [2] https://lore.kernel.org/r/20260610174807.6231-1-alexander.kaplan@sms-medipool.de
> [3] https://lore.kernel.org/r/20260610174819.6258-1-alexander.kaplan@sms-medipool.de
>  drivers/gpu/drm/display/drm_dp_cec.c | 18 ++++++++++++++++--
>  1 file changed, 16 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/display/drm_dp_cec.c b/drivers/gpu/drm/display/drm_dp_cec.c
> index 436bfe9f9081..824a99f86a3d 100644
> --- a/drivers/gpu/drm/display/drm_dp_cec.c
> +++ b/drivers/gpu/drm/display/drm_dp_cec.c
> @@ -218,6 +218,9 @@ static void drm_dp_cec_handle_irq(struct drm_dp_aux *aux)
>  	if (drm_dp_dpcd_read_byte(aux, DP_CEC_TUNNELING_IRQ_FLAGS, &flags) < 0)
>  		return;
>  
> +	if (!flags)
> +		return;
> +
>  	if (flags & DP_CEC_RX_MESSAGE_INFO_VALID)
>  		drm_dp_cec_received(aux);
>  
> @@ -255,11 +258,22 @@ void drm_dp_cec_irq(struct drm_dp_aux *aux)
>  
>  	ret = drm_dp_dpcd_read_byte(aux, DP_DEVICE_SERVICE_IRQ_VECTOR_ESI1,
>  				    &cec_irq);
> -	if (ret < 0 || !(cec_irq & DP_CEC_IRQ))
> +	if (ret < 0)
>  		goto unlock;

I saw that you added a quirk for this device in this patch series:

https://lore.kernel.org/all/20260610174807.6231-2-alexander.kaplan@sms-medipool.de/

Should we add a quirk for this as well? It's not worth it if that's a lot of work,
but if it is easy to add, then I think that's the better approach for this.

Regards,

	Hans

>  
> +	/*
> +	 * Some branch devices, for instance the Synaptics VMM7100 based
> +	 * DP-to-HDMI protocol converters, assert an IRQ_HPD pulse for each
> +	 * CEC event, but never set the CEC_IRQ bit in the
> +	 * DEVICE_SERVICE_IRQ_VECTOR_ESI1 register. Check the CEC tunneling
> +	 * IRQ flags even without CEC_IRQ being set: servicing the flags is
> +	 * idempotent and only costs one additional AUX read.
> +	 */
>  	drm_dp_cec_handle_irq(aux);
> -	drm_dp_dpcd_write_byte(aux, DP_DEVICE_SERVICE_IRQ_VECTOR_ESI1, DP_CEC_IRQ);
> +
> +	if (cec_irq & DP_CEC_IRQ)
> +		drm_dp_dpcd_write_byte(aux, DP_DEVICE_SERVICE_IRQ_VECTOR_ESI1,
> +				       DP_CEC_IRQ);
>  unlock:
>  	mutex_unlock(&aux->cec.lock);
>  }

Re: [PATCH] drm/dp: Service the CEC tunneling IRQ flags without CEC_IRQ in ESI1

[Alexander Kaplan]

On 11/06/2026 09:01, Hans Verkuil wrote:
> I saw that you added a quirk for this device in this patch series:
>
> https://lore.kernel.org/all/20260610174807.6231-2-alexander.kaplan@sms-medipool.de/
>
> Should we add a quirk for this as well? It's not worth it if that's a lot of work,
> but if it is easy to add, then I think that's the better approach for this.

Hi Hans,

thanks for the suggestion. A quirk would indeed be easy to add.
drm_dp_cec.c already reads the branch ident for its status debugfs,
so gating the relaxed ESI check on a DPCD quirk entry is a handful
of lines.

However, while validating which devices such a quirk should cover,
I found a firmware problem that makes me withdraw this patch
instead.

I tested all three Synaptics VMM7100 based devices I have:

- Club3D CAC-2505 (branch ID "SYNAq", FW 7.1): CEC works with my
  patch. This is the device the patch was written for.
- A USB-C to HDMI dongle with the macOS 4K120 firmware (branch ID
  "SYNAq", FW 7.2): announces CEC capability but never services the
  tunneling registers. TX requests and incoming bus traffic are
  both ignored.
- A Thunderbolt 4 dock (branch ID "SYNAa", FW 6.5): same dead stub.

On the one working device the firmware causes an audible audio
dropout of roughly 100 ms for every CEC message it handles while
CEC tunneling is enabled.
This affects its own transmissions, directed traffic and even
broadcasts it does not ack.
My LG TV broadcasts its vendor ID and polls for playback devices
every 14 seconds, around the clock.
With a configured CEC adapter that means a dropout every few
seconds during audio playback.
I verified this by correlating heard dropouts against monitored
CEC messages, 9 out of 9 matched to the second with no false
positives.
With tunneling disabled the same bus traffic causes no dropouts
at all.

The dropout length matches the frame time on the CEC wire and AUX
stays fully responsive during the stall.
It also reproduces with the kernel completely uninvolved when I
drive the DPCD tunneling registers directly from userspace.
So the stall happens inside the dongle MCU while it bit-bangs the
CEC line and I see no host-reachable way to fix or mitigate it.

That changes the picture for the patch.
The only known device family with working CEC tunneling has this
defect.
Merging it would hand users working CEC plus broken audio, and
setups like Kodi configure CEC automatically, so exactly those
users would then have to disable CEC again to get clean audio.
That is a bad trade, even behind a quirk.

My guess is that Synaptics never shipped the CEC firmware glue
before.
The CAC-2505 is a recent product and probably carries the newest
firmware branch, the other two devices are older designs.
If a future firmware shows up with working CEC and without the
audio stall, I will resubmit this together with the device quirk
you suggested.

Sorry for the noise, and thanks for the review.

Alexander