[PATCH v2] drm: document how user-space should use link-status

Daniel Vetter daniel at ffwll.ch
Wed Jun 3 13:44:27 UTC 2020


On Wed, Jun 03, 2020 at 01:27:55PM +0000, Simon Ser wrote:
> > > + *      When user-space performs an atomic commit on a connector with a "BAD"
> > > + *      link-status without resetting the property to "GOOD", it gets
> > > + *      implicitly reset. This might make the atomic commit fail if the modeset
> > > + *      is unsuccessful.
> >
> > I think this was what Daniel was saying that the kernel should require
> > ALLOW_MODESET to be set for the automatic reset, right?
> 
> Actually this paragraph isn't true. link-status is only reset to GOOD for
> legacy modeset.
> 
> But right now this doesn't matter since no driver reads the link-status
> property value as far as I can tell. Note, only i915 sets link-status
> to BAD.

It's magic ... change in link status results in connectors_change (or
something like that), which forces the modeset (and first recomputation of
mode state) that fixes everything up.

But yeah I entirely missed that the autoreset to GOOD only happens in
legacy modeset.

I guess we might have some atomic compositors with slightly suboptimal
handling of link status failure :-/

> > I'm fine with how the doc is written now. But if ALLOW_MODESET becomes
> > a requirement for the automatic reset, I suspect there is a risk to
> > regress Weston, assuming the automatic reset used to be successful.
> 
> Right now a commit without ALLOW_MODESET won't reset link-status to GOOD,
> but also won't re-train the link on i915. So I think it's fine to require
> ALLOW_MODESET.
> 
> Should drivers read the value of the link-status property? Or should we
> ignore user-space writes to the property and only require ALLOW_MODESET
> to re-train the link?

Well without allow_modeset it'll fail, that's the problem. But since we
dont automatically restore, I think the only problem is that existing
atomic userspace might be stuck on a bad link for a while ...
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


More information about the dri-devel mailing list