Re: [PATCH 2/5] drm: Set DRM connector link status property

[Manasi Navare <manasi.d.navare@intel.com>]

On Tue, Nov 15, 2016 at 08:49:21AM +0100, Daniel Vetter wrote:
> On Mon, Nov 14, 2016 at 07:13:20PM -0800, Manasi Navare wrote:
> > In the usual working scenarios, this property is "Good".
> > If something fails during modeset, the DRM driver can
> > set the link status to "Bad", prune the mode list based on the
> > link rate/lane count fallback values and send  hotplug uevent
> > so that userspace that is aware of this property can take an
> > appropriate action by reprobing connectors and re triggering
> > a modeset to improve user experience and avoid black screens.
> > In case of userspace that is not aware of this link status
> > property, the user experience will be unchanged.
> > 
> > The reason for adding the property is to handle link training failures,
> > but it is not limited to DP or link training. For example, if we
> > implement asynchronous setcrtc, we can use this to report any failures
> > in that.
> > 
> > Cc: dri-devel@lists.freedesktop.org
> > Cc: Jani Nikula <jani.nikula@linux.intel.com>
> > Cc: Daniel Vetter <daniel.vetter@intel.com>
> > Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
> > Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
> > ---
> >  drivers/gpu/drm/drm_connector.c | 38 ++++++++++++++++++++++++++++++++++++++
> >  include/drm/drm_connector.h     |  2 ++
> >  2 files changed, 40 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> > index d4e852f..09f4093 100644
> > --- a/drivers/gpu/drm/drm_connector.c
> > +++ b/drivers/gpu/drm/drm_connector.c
> > @@ -968,6 +968,44 @@ int drm_mode_connector_update_edid_property(struct drm_connector *connector,
> >  }
> >  EXPORT_SYMBOL(drm_mode_connector_update_edid_property);
> >  
> > +/**
> > + * drm_mode_connector_set_link_status_property - Set the link status property of
> > + * a connector to indicate status of link as a result of link training.
> 
> iirc this continuation upsets kernel-doc. Did you build the docs and
> review them? You need to indent the 2nd line.
>

I built the docs and didnt see any issue with the docs, but I will shorten
the description.

 
> Also, might just shorten it to "set link status for a connector", details
> are for the text below.
> 
> > + * @connector: drm connector
> > + * @link_status: new value of link status property (0: Good, 1: Bad)
> > + *
> > + * In usual working scenario, this link status property will always be set to
> > + * "GOOD".
> 
> Unecessary linebbreak. Either make a full paragraph (empty line) or
> reflow, this here won't survivie kernel-doc formatting.
>

Agree, will fix this.

 
> > + * If something fails during or after a mode set, the kernel driver can set this
> > + * link status to "BAD", prune the mode list based on new information and send a
> 
> First need to prune the mode list, then set the property. Please reorder
> in your text.
> 
> > + * hotplug uevent for userspace to have it re-check the valid modes through
> > + * Get_connector and try again.
> 
> s/Get_connector/GET_CONNECTOR IOCTL/ is the more usual style.
> 
> > + *
> > + * If userspace is not aware of this property, the user experience is the same
> > + * as it currently is. If the userspace is aware of the property, it has a chance
> > + * to improve user experience by handling link training failures, avoiding black
> > + * screens. The DRM driver can chose to not modify property and keep link status
> > + * as "GOOD" always to keep the user experience same as it currently is.
> 
> Imo this paragraph isn't needed. Maybe just mention that old userspace
> exists:
>

I think keeping this paragraph is important to give the readers good idea of how this
will affect the user experience.
 
> "Note that a lot of existing userspace doesn't handle this property.
> Drivers can therefore not rely on userspace to fix up everything and
> should try to handle issues (like just re-training a link) without
> userspace's intervention. This should only be used when the current mode
> doesn't work any more, and userspace must select a different display
> mode."
>

But atleast the way i915 uses this is in both cases where current mode
does not get pruned but need sto be retried and also when current mode
is no longer valid and gets pruned and modeset is done at a lower mode.
But in either case if link training fails, this property is set to BAD.

Manasi 
> > + *
> > + * The reason for adding this property is to handle link training failures, but
> > + * it is not limited to DP or link training. For example, if we implement
> > + * asynchronous setcrtc, this property can be used to reportany failures in that.
> 
> s/reportany/report/
> 
> > + *
> > + * This function must be called from asynchronous work item.
> 
> This isn't true - it doesn't require an asynchronous work item, but the
> locking rules mean that it.
> 
> > + * Returns zero on success and negative errrno on failure.
> 
> Hm, why can this ever fail? Intuitively this should never fail, and hence
> we shouldn't need an error return value.
> 

Ok, yes agree will change it to return void.

> > + */
> > +int drm_mode_connector_set_link_status_property(struct drm_connector *connector,
> > +						uint64_t link_status)
> > +{
> > +	struct drm_device *dev = connector->dev;
> > +
> > +	connector->link_status = link_status;
> > +	return drm_object_property_set_value(&connector->base,
> > +					     dev->mode_config.link_status_property,
> > +					     link_status);
> 
> This misses the hotplug_event call from my proposal.  Intentionally? Why?
> 
> Also: With the current code you require that mode_config.mutex is held by
> the caller. Every time you add a library/core function which requires
> certain locks to be held, please check that with something like
> lockdep_assert_held or similar. Leaking locking rules to callers like this
> should be the exception, not the rule.
> 
> But with my proposal this function here would grab all necessary locks,
> solving that problem, too.
> -Daniel
>

As per our IRC chat, I am going to leave ueventc calling to the caller
of this function.

 
> > +}
> > +EXPORT_SYMBOL(drm_mode_connector_set_link_status_property);
> > +
> >  int drm_mode_connector_set_obj_prop(struct drm_mode_object *obj,
> >  				    struct drm_property *property,
> >  				    uint64_t value)
> > diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> > index ad5c8b0..ac76469 100644
> > --- a/include/drm/drm_connector.h
> > +++ b/include/drm/drm_connector.h
> > @@ -778,6 +778,8 @@ int drm_mode_connector_set_path_property(struct drm_connector *connector,
> >  int drm_mode_connector_set_tile_property(struct drm_connector *connector);
> >  int drm_mode_connector_update_edid_property(struct drm_connector *connector,
> >  					    const struct edid *edid);
> > +int drm_mode_connector_set_link_status_property(struct drm_connector *connector,
> > +						uint64_t link_status);
> >  
> >  /**
> >   * drm_for_each_connector - iterate over all connectors
> > -- 
> > 1.9.1
> > 
> > _______________________________________________
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx