[Intel-gfx] [PATCH 1/2] drm: Add a new connector property for link status

Chris Wilson chris at chris-wilson.co.uk
Wed Oct 26 13:11:00 UTC 2016


On Wed, Oct 26, 2016 at 02:17:16PM +0300, Ville Syrjälä wrote:
> On Wed, Oct 26, 2016 at 12:51:41PM +0300, Jani Nikula wrote:
> > On Wed, 26 Oct 2016, Chris Wilson <chris at chris-wilson.co.uk> wrote:
> > > On Wed, Oct 26, 2016 at 07:52:26AM +0200, Daniel Vetter wrote:
> > >> I'd go further and just always create this as one of the standard
> > >> properties (and always attach it to the connector, like edid), and only
> > >> expose helpers to set the link status to good or bad.
> > >
> > > One of the sketches for this idea was that this could serve as the
> > > failure notification path for nonblocking modesets (well modesets in
> > > general since it appears returning the error is not going to happen).
> > 
> > In nonblocking modesets, when should we change the status from bad to
> > good? If the setcrtc returns and userspace looks at link status and sees
> > it's still bad (because the kernel hasn't gotten around to enabling the
> > link yet, or whatever), userspace might think it would have to try
> > again. Do we set it to good immediately on setcrtc ioctl, or add a
> > "pending" status? Or something better?
> 
> I was thinking it'd start out as "good" and only change to something
> else when things actually go south.
> 
> Not sure if we should also want "off" as one of the values, for when
> it's really off at the request of the user.

That's something the user knows. At least, if the ddx has output->crtc
set and sees that link-status=off the response is to say "that can't be
me!" and reapply the desired mode, i.e. same response as if the
link-status was bad. Maybe useful for someone else to differentiate?
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre


More information about the Intel-gfx mailing list