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

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

[Jyri Sarha]

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@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Ilia Mirkin]

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.

Cheers,

  -ilia

On Sun, Aug 25, 2019 at 7:12 AM Jyri Sarha <jsarha@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@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: 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@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@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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: 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@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@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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel