All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: Ramalingam C <ramalingam.c@intel.com>
Cc: intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v5 08/12] drm: uevent for connector status change
Date: Mon, 29 Apr 2019 09:33:36 +0200	[thread overview]
Message-ID: <20190429073336.GF3271@phenom.ffwll.local> (raw)
In-Reply-To: <20190418085805.5648-9-ramalingam.c@intel.com>

On Thu, Apr 18, 2019 at 02:28:01PM +0530, Ramalingam C wrote:
> DRM API for generating uevent for a status changes of connector's
> property.
> 
> This uevent will have following details related to the status change:
> 
>   HOTPLUG=1, CONNECTOR=<connector_id> and PROPERTY=<property_id>
> v2:
>   Minor fixes at KDoc comments [Daniel]
> 
> Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
> ---
>  drivers/gpu/drm/drm_sysfs.c | 31 +++++++++++++++++++++++++++++++
>  include/drm/drm_sysfs.h     |  5 ++++-
>  2 files changed, 35 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
> index 18b1ac442997..e8f1fd73677f 100644
> --- a/drivers/gpu/drm/drm_sysfs.c
> +++ b/drivers/gpu/drm/drm_sysfs.c
> @@ -320,6 +320,9 @@ void drm_sysfs_lease_event(struct drm_device *dev)
>   * Send a uevent for the DRM device specified by @dev.  Currently we only
>   * set HOTPLUG=1 in the uevent environment, but this could be expanded to
>   * deal with other types of events.
> + *
> + * Any new uapi should be using the drm_sysfs_connector_status_event()
> + * for uevents on connector status change.
>   */
>  void drm_sysfs_hotplug_event(struct drm_device *dev)
>  {
> @@ -332,6 +335,34 @@ void drm_sysfs_hotplug_event(struct drm_device *dev)
>  }
>  EXPORT_SYMBOL(drm_sysfs_hotplug_event);
>  
> +/**
> + * drm_sysfs_connector_status_event - generate a DRM uevent for connector
> + * property status change
> + * @connector: connector on which property status changed
> + * @property: connector property whoes status changed.
> + *
> + * Send a uevent for the DRM device specified by @dev.  Currently we
> + * set HOTPLUG=1 and connector id along with the attached property id
> + * related to the status change.
> + */
> +void drm_sysfs_connector_status_event(struct drm_connector *connector,
> +				      struct drm_property *property)
> +{
> +	struct drm_device *dev = connector->dev;
> +	char hotplug_str[] = "HOTPLUG=1", conn_id[30], prop_id[30];
> +	char *envp[4] = { hotplug_str, conn_id, prop_id, NULL };
> +
> +	snprintf(conn_id, ARRAY_SIZE(conn_id),
> +		 "CONNECTOR=%u", connector->base.id);
> +	snprintf(prop_id, ARRAY_SIZE(prop_id),
> +		 "PROPERTY=%u", property->base.id);

Maybe double-check that property is attached to connector, and WARN if
not? Just to catch mistakes in driver programming.

With that: Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>


> +
> +	DRM_DEBUG("generating connector status event\n");
> +
> +	kobject_uevent_env(&dev->primary->kdev->kobj, KOBJ_CHANGE, envp);
> +}
> +EXPORT_SYMBOL(drm_sysfs_connector_status_event);
> +
>  static void drm_sysfs_release(struct device *dev)
>  {
>  	kfree(dev);
> diff --git a/include/drm/drm_sysfs.h b/include/drm/drm_sysfs.h
> index 4f311e836cdc..d454ef617b2c 100644
> --- a/include/drm/drm_sysfs.h
> +++ b/include/drm/drm_sysfs.h
> @@ -4,10 +4,13 @@
>  
>  struct drm_device;
>  struct device;
> +struct drm_connector;
> +struct drm_property;
>  
>  int drm_class_device_register(struct device *dev);
>  void drm_class_device_unregister(struct device *dev);
>  
>  void drm_sysfs_hotplug_event(struct drm_device *dev);
> -
> +void drm_sysfs_connector_status_event(struct drm_connector *connector,
> +				      struct drm_property *property);
>  #endif
> -- 
> 2.19.1
> 

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

  reply	other threads:[~2019-04-29  7:33 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-18  8:57 [PATCH v5 00/12] HDCP2.2 Phase II Ramalingam C
2019-04-18  8:57 ` [PATCH v5 01/12] drm: move content protection property to mode_config Ramalingam C
2019-04-23  7:38   ` Daniel Vetter
2019-04-18  8:57 ` [PATCH v5 02/12] drm/i915: debugfs: HDCP2.2 capability read Ramalingam C
2019-04-18  8:57 ` [PATCH v5 03/12] drm: Add Content protection type property Ramalingam C
2019-04-23  7:44   ` Daniel Vetter
2019-04-18  8:57 ` [PATCH v5 04/12] drm/i915: Attach content " Ramalingam C
2019-04-23  8:11   ` Daniel Vetter
2019-04-23 11:17     ` Ramalingam C
2019-04-23 12:10       ` Daniel Vetter
2019-04-18  8:57 ` [PATCH v5 05/12] drm: revocation check at drm subsystem Ramalingam C
2019-04-29  7:26   ` Daniel Vetter
2019-04-29  7:30     ` Daniel Vetter
2019-04-18  8:57 ` [PATCH v5 06/12] drm/i915: SRM revocation check for HDCP1.4 and 2.2 Ramalingam C
2019-04-29  7:28   ` Daniel Vetter
2019-04-18  8:58 ` [PATCH v5 07/12] drm/hdcp: gathering hdcp related code into drm_hdcp.c Ramalingam C
2019-04-29  7:31   ` Daniel Vetter
2019-04-18  8:58 ` [PATCH v5 08/12] drm: uevent for connector status change Ramalingam C
2019-04-29  7:33   ` Daniel Vetter [this message]
2019-04-18  8:58 ` [PATCH v5 09/12] drm/hdcp: update content protection property with uevent Ramalingam C
2019-04-29  7:35   ` Daniel Vetter
2019-04-18  8:58 ` [PATCH v5 10/12] drm/i915: update the hdcp state " Ramalingam C
2019-04-29  7:35   ` Daniel Vetter
2019-04-18  8:58 ` [PATCH v5 11/12] drm: Add CP downstream_info property Ramalingam C
2019-04-29  7:38   ` Daniel Vetter
2019-04-29 14:46     ` Ramalingam C
2019-04-18  8:58 ` [PATCH v5 12/12] drm/i915: Populate downstream info for HDCP Ramalingam C
2019-04-18 10:35 ` ✗ Fi.CI.CHECKPATCH: warning for HDCP2.2 Phase II (rev6) Patchwork
2019-04-18 10:43 ` ✗ Fi.CI.SPARSE: " Patchwork
2019-04-18 11:17 ` ✗ Fi.CI.CHECKPATCH: warning for HDCP2.2 Phase II (rev7) Patchwork
2019-04-18 11:25 ` ✗ Fi.CI.SPARSE: " Patchwork
2019-04-18 11:45 ` ✓ Fi.CI.BAT: success " Patchwork
2019-04-18 13:51 ` ✓ Fi.CI.IGT: " Patchwork

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=20190429073336.GF3271@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=ramalingam.c@intel.com \
    /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.