All of lore.kernel.org
 help / color / mirror / Atom feed
From: Manasi Navare <manasi.d.navare@intel.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: Daniel Vetter <daniel.vetter@intel.com>,
	intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 2/5] drm: Set DRM connector link status property
Date: Tue, 15 Nov 2016 17:13:43 -0800	[thread overview]
Message-ID: <20161116011343.GB29770@intel.com> (raw)
In-Reply-To: <20161115075327.235fxiouguhviffh@phenom.ffwll.local>

On Tue, Nov 15, 2016 at 08:53:27AM +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>
> 
> One more thing I've forgotten: Just adding the kernel-doc isn't enough
> yet, we need to link this new property into the overall property
> documentations.
> 
> We already have a section "KMS Properties" in
> Documentation/gpu/drm-kms.rst, I think adding a new sub-section called
> "Standard Connector Properties" there with a definition list pointing to
> this function here would be best.
> -Daniel
>

What about other standard proprties like EDID etc? And could you give an
example for writing out a definition list there pointing to this function?
This .rst file currently consists of kernel::doc:: and paths for .h files

Manasi
> > ---
> >  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.
> > + * @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 can set this
> > + * link status to "BAD", prune the mode list based on new information and send a
> > + * hotplug uevent for userspace to have it re-check the valid modes through
> > + * Get_connector and try again.
> > + *
> > + * 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.
> > + *
> > + * 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.
> > + *
> > + * This function must be called from asynchronous work item.
> > + * Returns zero on success and negative errrno on failure.
> > + */
> > +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);
> > +}
> > +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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2016-11-16  1:13 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-15  3:13 [PATCH 0/5] Handle link training failure during modeset Manasi Navare
2016-11-15  3:13 ` [PATCH 1/5] drm: Add a new connector property for link status Manasi Navare
2016-11-15  3:13 ` [PATCH 2/5] drm: Set DRM connector link status property Manasi Navare
2016-11-15  3:23   ` Manasi Navare
2016-11-15  7:50     ` Daniel Vetter
2016-11-15  7:49   ` [Intel-gfx] " Daniel Vetter
2016-11-15 23:56     ` Manasi Navare
2016-11-16  7:35       ` [Intel-gfx] " Daniel Vetter
2016-11-15  7:53   ` Daniel Vetter
2016-11-16  1:13     ` Manasi Navare [this message]
2016-11-16  7:29       ` Daniel Vetter
2016-11-16  1:58   ` [PATCH v2 " Manasi Navare
2016-11-15  3:13 ` [PATCH 3/5] drm/i915: Update CRTC state if connector link status property changed Manasi Navare
2016-11-15  3:13 ` [PATCH 4/5] drm/i915: Find fallback link rate/lane count Manasi Navare
2016-11-16 17:32   ` Manasi Navare
2016-11-17 12:58   ` Jani Nikula
2016-11-17 19:44     ` Manasi Navare
2016-11-15  3:13 ` [PATCH 5/5] drm/i915: Implement Link Rate fallback on Link training failure Manasi Navare
2016-11-16 17:34   ` Manasi Navare
2016-11-17 12:49   ` Jani Nikula
2016-11-17 19:55     ` Manasi Navare
2016-11-15  4:24 ` ✓ Fi.CI.BAT: success for Handle Link Training Failure during modeset (rev2) Patchwork
2016-11-17 12:29 ` [PATCH 0/5] Handle link training failure during modeset Jani Nikula
2016-11-17 19:48   ` Manasi Navare

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20161116011343.GB29770@intel.com \
    --to=manasi.d.navare@intel.com \
    --cc=daniel.vetter@intel.com \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.