On Fri, Nov 18, 2016 at 06:58:59PM -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.
>
> v3:
> * Updated kernel doc even more (Daniel Vetter)
> v2:
> * Update kernel doc, add lockdep_assert_held (Daniel Vetter)
> Cc: dri-de...@lists.freedesktop.org
> Cc: Jani Nikula <jani.nik...@linux.intel.com>
> Cc: Daniel Vetter <daniel.vet...@intel.com>
> Cc: Ville Syrjala <ville.syrj...@linux.intel.com>
> Signed-off-by: Manasi Navare <manasi.d.nav...@intel.com>
> ---
> drivers/gpu/drm/drm_connector.c | 37 +++++++++++++++++++++++++++++++++++++
> include/drm/drm_connector.h | 2 ++
> 2 files changed, 39 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index cfb5cf7..b5ca70f 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -1019,6 +1019,43 @@ 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 link status property of
> a connector
> + * @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". If something fails during or after a mode set, the kernel driver
> should
> + * set this link status property to "BAD" and prune the mode list based on
> new
> + * information. The caller then needs to send a hotplug uevent for userspace
> to
> + * re-check the valid modes through GET_CONNECTOR_IOCTL and retry modeset.
> + *
> + * Note that a lot of existing userspace do not 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
> + * fails and userspace must select a different display mode.
> + * 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.
> + *
> + * 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 report any failures in
> that.
> + */
> +void drm_mode_connector_set_link_status_property(struct drm_connector
> *connector,
> + uint64_t link_status)
> +{
> + struct drm_device *dev = connector->dev;
> +
> + /* Make sure the mutex is grabbed */
> + lockdep_assert_held(&dev->mode_config.mutex);
The comment is just duplicating the code; (i++; /* post-increment i */).
Comments are about why the code exists.
Common practice is to leave a blank line between function preconditions
and the body of actual code.
For example it might be worth explaining why link_status is duplicated
on the connector and in its property (i.e. that is near impossible to
retrieve the value from the property).
> + connector->link_status = link_status;
> + drm_object_property_set_value(&connector->base,
> + dev->mode_config.link_status_property,
> + link_status);
> +}
> +EXPORT_SYMBOL(drm_mode_connector_set_link_status_property);
--
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
