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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Nov 15, 2016 at 05:13:43PM -0800, Manasi Navare wrote:
> 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@xxxxxxxxxxxxxxxxxxxxx
> > > Cc: Jani Nikula <jani.nikula@xxxxxxxxxxxxxxx>
> > > Cc: Daniel Vetter <daniel.vetter@xxxxxxxxx>
> > > Cc: Ville Syrjala <ville.syrjala@xxxxxxxxxxxxxxx>
> > > Signed-off-by: Manasi Navare <manasi.d.navare@xxxxxxxxx>
> > 
> > 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

Yeah, none of the standard connector properties are currently documented.
I'll write a quick patch that you can then base yours on.
-Daniel

> 
> 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@xxxxxxxxxxxxxxxxxxxxx
> > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> > 
> > -- 
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > http://blog.ffwll.ch

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux