[RFC PATCH xserver] modesetting: re-set the crtc's mode when link-status goes BAD

[Daniel Vetter]

On Fri, Mar 31, 2017 at 05:22:09PM -0700, Eric Anholt wrote:
> Manasi Navare <manasi.d.navare at intel.com> writes:
> 
> > On Fri, Mar 31, 2017 at 01:08:41PM -0700, Eric Anholt wrote:
> >> Manasi Navare <manasi.d.navare at intel.com> writes:
> >> 
> >> > On Thu, Mar 30, 2017 at 05:37:55PM -0700, Eric Anholt wrote:
> >> >> Martin Peres <martin.peres at linux.intel.com> writes:
> >> >> 
> >> >> > On 26/01/17 14:37, Martin Peres wrote:
> >> >> >> Despite all the careful planing of the kernel, a link may become
> >> >> >> insufficient to handle the currently-set mode. At this point, the
> >> >> >> kernel should mark this particular configuration as being broken
> >> >> >> and potentially prune the mode before setting the offending connector's
> >> >> >> link-status to BAD and send the userspace a hotplug event. This may
> >> >> >> happen right after a modeset or later on.
> >> >> >>
> >> >> >> When available, we should use the link-status information to reset
> >> >> >> the wanted mode.
> >> >> >>
> >> >> >> Signed-off-by: Martin Peres <martin.peres at linux.intel.com>
> >> >> >
> >> >> > The relevant kernel patches have landed in drm-tip about a month ago.
> >> >> >
> >> >> > Eric, would you mind providing feedback on or merging this patch?
> >> >> 
> >> >> The later discussion has sounded like the kernel will (always) prune the
> >> >> mode when we re-query, meaning that it doesn't make any sense to try to
> >> >> re-set to the old mode.  Is this not the case?
> >> >
> >> >
> >> > No the kernel will simply send a hotplug with link status as bad
> >> > and then after that point its userspace driver's responsibility
> >> > to check if link status is BAD, retry the same mode and if it fails
> >> > then re probe.
> >> 
> >> So the kernel will sometimes allow the same mode to be re-set with the
> >> same bpp?
> >
> > So when userspace driver re-sets the same mode, the kernel will call the
> > mode valid function where it will see it can allow the sam mode perhaps
> > at a lower bpp now since the link parameters are lowered.
> > So the mode which failed at 30 bpp, might still work at 18bpp and is
> > better going to a lower resolution.
> 
> The question was whether the kernel will ever allow the same mode at the
> same bpp, since that's what this patch tries to do.

Yes, this can happen. Doing a full modeset with recomputing clocks and
everything behind userspace's back might not be something the kernel
driver can pull of with a reasonable amount of effort, hence why we punt
to userspace. The interface spec makes this a CAN, not WILL, to allow less
unreasonable hw to handle these cases directly in the kernel driver. E.g.
plain link-retraining is handled in i915.ko still.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch