Re: DisplayPort: handling of HPD events / link training

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]<

 



Hi

Am 16.07.24 um 18:35 schrieb Dmitry Baryshkov:
On Tue, 16 Jul 2024 at 18:58, Thomas Zimmermann <tzimmermann@xxxxxxx> wrote:
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.
Short answer: yes, the only proper place to do it is atomic_enable().

Thanks.


Long answer: I don't see a way to retrigger link training in ast_dp.c
Without such change you are just shifting things around. The
end-result of moving link-training to atomic_enable() is that each
enable can trigger link training, possibly lowering the link rate,
etc. if link training is just a status bit from the firmware that we
don't control, it doesn't make real-real sense to move it.

I have to think about what to do. People tend to copy existing drivers, which alone might be a good argument for using atomic_enable. The link training is indeed just a flag that is set by the firmware. I think it's possible to re-trigger training by powering the port down and up again. atomic_enable could likely do that. The hardware is also somewhat buggy and not fully standard conformant.

Best regards
Thomas


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)



--
--
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)




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux