[Intel-gfx] [PATCH 2/5] drm: Set DRM connector link status property

Tue Nov 15 07:49:21 UTC 2016

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 at lists.freedesktop.org
> Cc: Jani Nikula <jani.nikula at linux.intel.com>
> Cc: Daniel Vetter <daniel.vetter at intel.com>
> Cc: Ville Syrjala <ville.syrjala at linux.intel.com>
> Signed-off-by: Manasi Navare <manasi.d.navare at 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.

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.

> + * 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:

"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."

> + *
> + * 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.

> + */
> +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

> +}
> +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 at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch