Re: [BUG] DP-CEC wake NACKs after S3 with UGREEN DP-to-HDMI adapter

[Hans Verkuil <hverkuil+cisco@kernel.org>]

Hi Jason,

On 08/09/2026 17:59, jason.boukheir wrote:
> Hi Hans,
> 
> I'm reporting a CEC resume problem on my desktop and would appreciate help identifying the right subsystem and next diagnostic steps.
> 
> AI disclosure: I used OpenAI Codex to inspect retained local logs and kernel source and prepare this report. The observations below come from those logs; the proposed cause is AI-assisted analysis,
> not an independently confirmed diagnoses. The attached local patch is an experimental workaround without independent upstream review, not a merge-ready submission.
> 
> Hardware/setup:
> - Sapphire Pulse Radeon RX 9070 XT (Navi 48), amdgpu.
> - GPU DP-1 -> UGREEN 8K@60Hz Active DisplayPort to HDMI Unidirectional Adapter, 0.66FT -> Samsung QBQ90S TV, HDMI 2.
> - Exact adapter SKU, chipset, and firmware are unknown.
> - NixOS, locally customized CachyOS-derived kernels; deep / ACPI S3 sleep.
> 
> In a July 31 capture (CEC driver version 7.1.5), the TV replied to power status queries before suspend. After S3, the adapter still reported physical address 2.0.0.0 and Playback logical address 8,
> but all 30 directed Image View On attempts to the TV returned "Not Acknowledged ... Max Retries". The kernel journal independently confirms S3 entry and exit.
> 
> A later setup with a local kernel patch plus separate cecd retry changes logged restored CEC tunneling state, TV wake ACKs, and an active-source announcement after resume. It did not receive a
> confirmed TV power-status reply. This is not a controlled comparison: the kernel version and userspace both changed, and another CEC wake service ran during the baseline capture. I have not reproduced
> this on current vanilla mainline.
> 
> The suspected mechanism is converter CEC state becoming lost or stale while Linux retains its enabled adapter state. The patch checks the tunneling-control and logical-address-mask registers during
> unchanged adapter attachment and replays cached state if needed. However, we have no raw register capture proving state loss, and the normal EDID removal path should invalidate the physical address
> and trigger reconfiguration.
> 
> Would you recommend investigating the common DP-CEC helper or the amdgpu resume/HPD lifecycle first? Which tracepoints or register captures would best distinguish these possibilities? No known-good
> kernel has been established, so I'm not claiming a regression.
> 
> Attached are selected log excerpts, detailed investigation notes (including limitations), and the experimental patch for context.

After reading the long, rambling AI generated report I conclude that it boils down
to the fact that after suspending, then resuming the video source, the CEC adapter
no longer works because it has lost all state.

I don't think I ever tested this scenario, although I'm not sure about that since it's
a long time ago that I worked on this. Most likely, when suspended the 5V line of the
HDMI output is pulled low, and the DP-to-HDMI adapter loses power.

I will debug this, but it may take a few weeks before I get around to it. I'm not
very familiar with how suspend/resume works in drm: after resume, does it assume
the same display is still connected, or does it do a full 'discover what displays
there are' process? It depends a bit on how it works to determine the right solution.
Your patch may actually be on the right track.

Regards,

	Hans

> 
> Thanks,
> Jason