Display-Port HPD handling, link status, and bandwidth checks

[Jyri Sarha]

On 25/08/2019 23:23, Ilia Mirkin wrote:
> You'll probably get a more detailed reply during the week, but for now
> have a look at the "link-status" property, which was made for
> precisely this situation. I think basically the idea is to ignore link
> training as part of the modeset, and just return the link status
> depending on the success. (And you should filter out totally
> infeasible modes, i.e. outside the monitor's max lanes/bandwidth
> capabilities, which I believe are available via DPCD or EDID.)
> 
> See https://www.kernel.org/doc/html/latest/gpu/drm-kms.html for a bit
> more info as well.
> 

It looks like only i915 is really implementing the "link-status"
property (e.g. setting it to something else than "GOOD"). And it only
sets it in delayed work right after a failed link-training.

But it looks like setting "link-status" bad and calling
drm_kms_helper_hotplug_event() indeed triggers another modeset at least
from fbdev console.

I guess the correct way would be checking if the link is still up
after receiving an HPD short pulse and setting link-status bad and
calling drm_kms_helper_hotplug_event() if the link is down.

I just wonder if the real user space clients like Weston or X work the
same way as fbdev does.

Maybe my first question is now answered, but I am still wondering about
this:

>> 1. When should the link training happen?
>>    a) In connector detect()?
>>       - This would enable us to do mode filtering (in mode_valid())
>>         based on the established link band-width (then again
>>         mode_valid() documentation suggests that modes should only
>>         be filtered based on "configuration-invariant hardware
>>         constraints").
>>    b) In check phase (this would currently mean mode_fixup)?
>>       - This is the last point where we can reject a mode that can not
>>         be sent over the DP-link
>>    c) In commit phase (e.g. bridge enable())
>>       - This is bad since we should not fail any more in the commit
>>         phase

Thanks,
Jyri

> Cheers,
> 
>   -ilia
> 
> On Sun, Aug 25, 2019 at 7:12 AM Jyri Sarha <jsarha at ti.com> wrote:
>>
>> Hi,
>>
>> I am working on a new DisplayPort bridge-driver and there is a couple of
>> things that I do not know how to handle.
>>
>> 1. When should the link training happen?
>>    a) In connector detect()?
>>       - This would enable us to do mode filtering (in mode_valid())
>>         based on the established link band-width (then again
>>         mode_valid() documentation suggests that modes should only
>>         be filtered based on "configuration-invariant hardware
>>         constraints").
>>    b) In check phase (this would currently mean mode_fixup)?
>>       - This is the last point where we can reject a mode that can not
>>         be sent over the DP-link
>>    c) In commit phase (e.g. bridge enable())
>>       - This is bad since we should not fail any more in the commit
>>         phase
>>
>> 2. DP-link sometimes drops after a succesful link training and DP-sink
>>    is supposed to send short HPD pulse about it. What are the
>>    recommended ways to handle the situation?
>>
>>    a) Send hotplug event and let the DRM client deal with it?
>>       - This does not work too well because even if the client tries
>>         to restore the display by committing the same state again -
>>         like fbdev does - the bridge does not go trough disable-enable
>>         cycle, since display mode has not changed.
>>       - Despite it not working so well, this is what the most drivers
>>         appear to do.
>>
>>    b) Driver internally re-trains the link but send a hotplug event
>>       always after it?
>>       - This is what i915 does, if I read the code right.
>>       - How to treat a training failure? Sending hotplug event does not
>>         really help (see above).
>>
>>    c) Silently re-train the link if we were able to restore the link
>>       and the display mode, and send HPD only if something went wrong?
>>
>> Best regards,
>> Jyri
>>
>> --
>> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
>> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
>> _______________________________________________
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel


-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki