On 2026-11-03 13:45 -0600, [email protected] wrote:
Can a separate plug or unplug event still be dropped if it arrives
while an
earlier NVIF_CONN_EVENT_V0_IRQ is already pending for the same
connector?
[...]
Should nv_connector->hpd_pending |= bits be moved outside the
if (!(drm->hpd_pending & mask)) check in nouveau_connector_hpd()?
Yes. Since 016dacb60e6d ("drm/nouveau/kms: pass event mask to hpd
handler") put the event bits under that check, any event that arrives
between scheduling the HPD worker and the worker clearing
drm->hpd_pending is lost, and the worker can sit in
pm_runtime_get_sync() for some time first. That predates this patch,
but it's the same problem from the other side, so v2 will add a patch
that always records the bits and only schedules the worker under the
check.
Would it be better to always run nouveau_dp_link_check(nv_connector)
when
NVIF_CONN_EVENT_V0_IRQ is set, and only guard the continue statement
with
!(bits & (NVIF_CONN_EVENT_V0_PLUG | NVIF_CONN_EVENT_V0_UNPLUG))?
I'd rather keep it as it is, but I welcome feedback from the
maintainers. With only this series applied, skipping the link check
loses nothing: nv_connector->dp_encoder is never set on nv50+, so
nouveau_dp_link_check() returns true without looking at the link. The
follow-up series that makes the link check work again [1] also restarts
an active DP link with a full modeset whenever the sink drops or
reasserts HPD, which covers a plug or unplug that comes in with an
IRQ_HPD. Running the link check as well would only add a second
retrain, or AUX reads from a sink that has just gone away.
[1]
https://lore.kernel.org/r/[email protected]
