Nouveau - Jul 2024 - DisplayPort: handling of HPD events / link training

Hello,

We are currently looking at checking and/or possibly redesigning the
way the MSM DRM driver handles the HPD events and link training.

After a quick glance at the drivers implementing DP support, I noticed
following main approaches:
- Perform link training at the atomic_enable time, don't report
failures (mtk, analogix, zynqmp, tegra, nouveau)
- Perform link training at the atomic_enable time, report errors using
link_status property (i915, mhdp8546)
- Perform link training on the plug event (msm, it8605).
- Perform link training from the DPMS handler, also calling it from
the enable callback (AMDGPU, radeon).

It looks like the majority wins and we should move HPD to
atomic_enable time. Is that assumption correct?

Also two related questions:
- Is there a plan to actually make use of the link_status property?
Intel presented it at FOSDEM 2018, but since that time it was not
picked up by other drivers.

- Is there any plan to create generic DP link training helpers? After
glancing through the DP drivers there is a lot of similar code in the
link training functions, with minor differences here and there. And
it's those minor differences that bug me. It means that drivers might
respond differently to similar devices. Or that there might be minor
bugs here and there.

-- 
With best wishes
Dmitry

Hi

Am 27.02.24 um 23:40 schrieb Dmitry Baryshkov:
> Hello,
>
> We are currently looking at checking and/or possibly redesigning the
> way the MSM DRM driver handles the HPD events and link training.
>
> After a quick glance at the drivers implementing DP support, I noticed
> following main approaches:
> - Perform link training at the atomic_enable time, don't report
> failures (mtk, analogix, zynqmp, tegra, nouveau)
> - Perform link training at the atomic_enable time, report errors using
> link_status property (i915, mhdp8546)
> - Perform link training on the plug event (msm, it8605).
> - Perform link training from the DPMS handler, also calling it from
> the enable callback (AMDGPU, radeon).
>
> It looks like the majority wins and we should move HPD to
> atomic_enable time. Is that assumption correct?
Did you ever receive an answer to this question? I currently investigate 
ast's DP code, which does link training as part of detecting the 
connector state (in detect_ctx). But most other drivers do this in 
atomic_enable. I wonder if ast should follow.

Best regards
Thomas
>
> Also two related questions:
> - Is there a plan to actually make use of the link_status property?
> Intel presented it at FOSDEM 2018, but since that time it was not
> picked up by other drivers.
>
> - Is there any plan to create generic DP link training helpers? After
> glancing through the DP drivers there is a lot of similar code in the
> link training functions, with minor differences here and there. And
> it's those minor differences that bug me. It means that drivers might
> respond differently to similar devices. Or that there might be minor
> bugs here and there.
>
-- 
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)