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