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

[Tomi Valkeinen]

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.

We've got similar issue with HDMI too. If HPD first goes low, then high, 
but the userspace hasn't handled the HPD event in between, the 
userspaces I looked at just think that nothing has happened.

So maybe any time there's a HPD -> low, we should set link-status to 
bad, hope that userspace knows about the property, and at next modeset, 
set it back to good.

  Tomi

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