All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 0/9] drm: Add privacy-screen class and connector properties
@ 2020-07-08 16:43 ` Hans de Goede
  0 siblings, 0 replies; 44+ messages in thread
From: Hans de Goede @ 2020-07-08 16:43 UTC (permalink / raw)
  To: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
	Daniel Vetter, David Airlie, Jani Nikula, Joonas Lahtinen,
	Rodrigo Vivi
  Cc: Hans de Goede, intel-gfx, dri-devel, Sebastien Bacher, Marco Trevisan

Hi All,

Here is the privacy-screen related code which we discussed a while ago.
This series consists of a number of different parts:

1. A new version of Rajat's privacy-screen connector properties patch,
this adds new userspace API in the form of new properties

2. Since on most devices the privacy screen is actually controlled by
some vendor specific ACPI/WMI interface which has a driver under
drivers/platform/x86, we need some "glue" code to make this functionality
available to KMS drivers. Patches 3-5 add a new privacy-screen class for
this, which allows non KMS drivers (and possibly KMS drivers too) to
register a privacy-screen device and also adds an interface for KMS drivers
to get access to the privacy-screen associated with a specific connector.
This is modelled similar to how we deal with e.g. PWMs and GPIOs in the
kernel, including separate includes for consumers and providers(drivers).

3. Some drm_connector helper functions to keep the actual changes needed
for this in individual KMS drivers as small as possible (patch 6).

4. Make the thinkpad_acpi code register a privacy-screen device on
ThinkPads with a privacy-screen (patches 7-8)

5. Make the i915 driver export the privacy-screen functionality through
the connector properties on the eDP connector.

I was a bit in doubt if I should calls this series a RFC, or just call
it v1, since there is no real userspace code using this yet. It was
tested using xrandr property access and udevadm event monitoring.
I do expect / hope we will have patches for a userspace consumer of the
new properties (mutter) ready soon.

But since the code is completely ready, including API documentation,
I've decided to just call this v1. Hopefully we can get patches for the
first userspace consumer of this ready during the review of this.

Regards,

Hans

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 44+ messages in thread

* [Intel-gfx] [PATCH 0/9] drm: Add privacy-screen class and connector properties
@ 2020-07-08 16:43 ` Hans de Goede
  0 siblings, 0 replies; 44+ messages in thread
From: Hans de Goede @ 2020-07-08 16:43 UTC (permalink / raw)
  To: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
	Daniel Vetter, David Airlie, Jani Nikula, Joonas Lahtinen,
	Rodrigo Vivi
  Cc: intel-gfx, dri-devel, Sebastien Bacher, Marco Trevisan

Hi All,

Here is the privacy-screen related code which we discussed a while ago.
This series consists of a number of different parts:

1. A new version of Rajat's privacy-screen connector properties patch,
this adds new userspace API in the form of new properties

2. Since on most devices the privacy screen is actually controlled by
some vendor specific ACPI/WMI interface which has a driver under
drivers/platform/x86, we need some "glue" code to make this functionality
available to KMS drivers. Patches 3-5 add a new privacy-screen class for
this, which allows non KMS drivers (and possibly KMS drivers too) to
register a privacy-screen device and also adds an interface for KMS drivers
to get access to the privacy-screen associated with a specific connector.
This is modelled similar to how we deal with e.g. PWMs and GPIOs in the
kernel, including separate includes for consumers and providers(drivers).

3. Some drm_connector helper functions to keep the actual changes needed
for this in individual KMS drivers as small as possible (patch 6).

4. Make the thinkpad_acpi code register a privacy-screen device on
ThinkPads with a privacy-screen (patches 7-8)

5. Make the i915 driver export the privacy-screen functionality through
the connector properties on the eDP connector.

I was a bit in doubt if I should calls this series a RFC, or just call
it v1, since there is no real userspace code using this yet. It was
tested using xrandr property access and udevadm event monitoring.
I do expect / hope we will have patches for a userspace consumer of the
new properties (mutter) ready soon.

But since the code is completely ready, including API documentation,
I've decided to just call this v1. Hopefully we can get patches for the
first userspace consumer of this ready during the review of this.

Regards,

Hans

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 44+ messages in thread

* [PATCH 1/9] drm/connector: Fix kerneldoc warning
  2020-07-08 16:43 ` [Intel-gfx] " Hans de Goede
@ 2020-07-08 16:43   ` Hans de Goede
  -1 siblings, 0 replies; 44+ messages in thread
From: Hans de Goede @ 2020-07-08 16:43 UTC (permalink / raw)
  To: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
	Daniel Vetter, David Airlie, Jani Nikula, Joonas Lahtinen,
	Rodrigo Vivi
  Cc: Hans de Goede, intel-gfx, dri-devel, Sebastien Bacher, Marco Trevisan

Fix the following kerneldoc warning:

drivers/gpu/drm/drm_connector.c:2189:
warning: missing initial short description on line

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
 drivers/gpu/drm/drm_connector.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index d877ddc6dc57..543086533850 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -2130,8 +2130,8 @@ int drm_connector_set_panel_orientation(
 EXPORT_SYMBOL(drm_connector_set_panel_orientation);
 
 /**
- * drm_connector_set_panel_orientation_with_quirk -
- *	set the connecter's panel_orientation after checking for quirks
+ * drm_connector_set_panel_orientation_with_quirk - set the connecter's
+ *    panel_orientation after checking for quirks
  * @connector: connector for which to init the panel-orientation property.
  * @panel_orientation: drm_panel_orientation value to set
  * @width: width in pixels of the panel, used for panel quirk detection
-- 
2.26.2

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply related	[flat|nested] 44+ messages in thread

* [Intel-gfx] [PATCH 1/9] drm/connector: Fix kerneldoc warning
@ 2020-07-08 16:43   ` Hans de Goede
  0 siblings, 0 replies; 44+ messages in thread
From: Hans de Goede @ 2020-07-08 16:43 UTC (permalink / raw)
  To: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
	Daniel Vetter, David Airlie, Jani Nikula, Joonas Lahtinen,
	Rodrigo Vivi
  Cc: intel-gfx, dri-devel, Sebastien Bacher, Marco Trevisan

Fix the following kerneldoc warning:

drivers/gpu/drm/drm_connector.c:2189:
warning: missing initial short description on line

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
 drivers/gpu/drm/drm_connector.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index d877ddc6dc57..543086533850 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -2130,8 +2130,8 @@ int drm_connector_set_panel_orientation(
 EXPORT_SYMBOL(drm_connector_set_panel_orientation);
 
 /**
- * drm_connector_set_panel_orientation_with_quirk -
- *	set the connecter's panel_orientation after checking for quirks
+ * drm_connector_set_panel_orientation_with_quirk - set the connecter's
+ *    panel_orientation after checking for quirks
  * @connector: connector for which to init the panel-orientation property.
  * @panel_orientation: drm_panel_orientation value to set
  * @width: width in pixels of the panel, used for panel quirk detection
-- 
2.26.2

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply related	[flat|nested] 44+ messages in thread

* [PATCH 2/9] drm/connector: Add support for privacy-screen properties (v4)
  2020-07-08 16:43 ` [Intel-gfx] " Hans de Goede
@ 2020-07-08 16:43   ` Hans de Goede
  -1 siblings, 0 replies; 44+ messages in thread
From: Hans de Goede @ 2020-07-08 16:43 UTC (permalink / raw)
  To: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
	Daniel Vetter, David Airlie, Jani Nikula, Joonas Lahtinen,
	Rodrigo Vivi
  Cc: Marco Trevisan, Pekka Paalanen, Sebastien Bacher,
	Mario Limonciello, intel-gfx, dri-devel, Hans de Goede,
	Rajat Jain

From: Rajat Jain <rajatja@google.com>

Add support for generic electronic privacy screen properties, that
can be added by systems that have an integrated EPS.

Changes in v2 (Hans de Goede)
- Create 2 properties, "privacy-screen sw-state" and
  "privacy-screen hw-state", to deal with devices where the OS might be
  locked out of making state changes
- Write kerneldoc explaining how the 2 properties work together, what
  happens when changes to the state are made outside of the DRM code's
  control, etc.

Changes in v3 (Hans de Goede)
- Some small tweaks to the kerneldoc describing the 2 properties

Changes in v4 (Hans de Goede)
- Change the "Enabled, locked" and "Disabled, locked" hw-state enum value
  names to "Enabled-locked" and "Disabled-locked". The xrandr command shows
  all possible enum values separated by commas in its output, so having a
  comma in an enum name is not a good idea.
- Do not add a privacy_screen_hw_state member to drm_connector_state
  since this property is immutable its value must be directly stored in the
  obj->properties->values array

Signed-off-by: Rajat Jain <rajatja@google.com>
Co-authored-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Reviewed-by: Mario Limonciello <Mario.limonciello@dell.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
 Documentation/gpu/drm-kms.rst     |   2 +
 drivers/gpu/drm/drm_atomic_uapi.c |   4 ++
 drivers/gpu/drm/drm_connector.c   | 101 ++++++++++++++++++++++++++++++
 include/drm/drm_connector.h       |  44 +++++++++++++
 4 files changed, 151 insertions(+)

diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
index 397314d08f77..30d5781d99b1 100644
--- a/Documentation/gpu/drm-kms.rst
+++ b/Documentation/gpu/drm-kms.rst
@@ -448,6 +448,8 @@ Property Types and Blob Property Support
 .. kernel-doc:: drivers/gpu/drm/drm_property.c
    :export:
 
+.. _standard_connector_properties:
+
 Standard Connector Properties
 -----------------------------
 
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c b/drivers/gpu/drm/drm_atomic_uapi.c
index a1e5e262bae2..2bf2dbe3ea6f 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -766,6 +766,8 @@ static int drm_atomic_connector_set_property(struct drm_connector *connector,
 						   fence_ptr);
 	} else if (property == connector->max_bpc_property) {
 		state->max_requested_bpc = val;
+	} else if (property == connector->privacy_screen_sw_state_property) {
+		state->privacy_screen_sw_state = val;
 	} else if (connector->funcs->atomic_set_property) {
 		return connector->funcs->atomic_set_property(connector,
 				state, property, val);
@@ -842,6 +844,8 @@ drm_atomic_connector_get_property(struct drm_connector *connector,
 		*val = 0;
 	} else if (property == connector->max_bpc_property) {
 		*val = state->max_requested_bpc;
+	} else if (property == connector->privacy_screen_sw_state_property) {
+		*val = state->privacy_screen_sw_state;
 	} else if (connector->funcs->atomic_get_property) {
 		return connector->funcs->atomic_get_property(connector,
 				state, property, val);
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 543086533850..bce5e0cc5884 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1191,6 +1191,46 @@ static const struct drm_prop_enum_list dp_colorspaces[] = {
  *	can also expose this property to external outputs, in which case they
  *	must support "None", which should be the default (since external screens
  *	have a built-in scaler).
+ *
+ * privacy-screen sw-state, privacy-screen hw-state:
+ *	These 2 optional properties can be used to query the state of the
+ *	electronic privacy screen that is available on some displays; and in
+ *	some cases also control the state. If a driver implements these
+ *	properties then both properties must be present.
+ *
+ *	"privacy-screen hw-state" is read-only and reflects the actual state
+ *	of the privacy-screen, possible values: "Enabled", "Disabled,
+ *	"Enabled, locked", "Disabled, locked". The locked states indicate
+ *	that the state cannot be changed through the DRM API. E.g. there
+ *	might be devices where the firmware-setup options, or a hardware
+ *	slider-switch, offer always on / off modes.
+ *
+ *	"privacy-screen sw-state" can be set to change the privacy-screen state
+ *	when not locked. In this case the driver must update the hw-state
+ *	property to reflect the new state on completion of the commit of the
+ *	sw-state property. Setting the sw-state property when the hw-state is
+ *	locked must be interpreted by the driver as a request to change the
+ *	state to the set state when the hw-state becomes unlocked. E.g. if
+ *	"privacy-screen hw-state" is "Enabled, locked" and the sw-state
+ *	gets set to "Disabled" followed by the user unlocking the state by
+ *	changing the slider-switch position, then the driver must set the
+ *	state to "Disabled" upon receiving the unlock event.
+ *
+ *	In some cases the privacy-screen's actual state might change outside of
+ *	control of the DRM code. E.g. there might be a firmware handled hotkey
+ *	which toggles the actual state, or the actual state might be changed
+ *	through another userspace API such as writing /proc/acpi/ibm/lcdshadow.
+ *	In this case the driver must update both the hw-state and the sw-state
+ *	to reflect the new value, overwriting any pending state requests in the
+ *	sw-state. Any pending sw-state requests are thus discarded.
+ *
+ *	Note that the ability for the state to change outside of control of
+ *	the DRM master process means that userspace must not cache the value
+ *	of the sw-state. Caching the sw-state value and including it in later
+ *	atomic commits may lead to overriding a state change done through e.g.
+ *	a firmware handled hotkey. Therefor userspace must not include the
+ *	privacy-screen sw-state in an atomic commit unless it wants to change
+ *	its value.
  */
 
 int drm_connector_create_standard_properties(struct drm_device *dev)
@@ -2159,6 +2199,67 @@ int drm_connector_set_panel_orientation_with_quirk(
 }
 EXPORT_SYMBOL(drm_connector_set_panel_orientation_with_quirk);
 
+static const struct drm_prop_enum_list privacy_screen_enum[] = {
+	{ PRIVACY_SCREEN_DISABLED,		"Disabled" },
+	{ PRIVACY_SCREEN_ENABLED,		"Enabled" },
+	{ PRIVACY_SCREEN_DISABLED_LOCKED,	"Disabled-locked" },
+	{ PRIVACY_SCREEN_ENABLED_LOCKED,	"Enabled-locked" },
+};
+
+/**
+ * drm_connector_create_privacy_screen_properties - create the drm connecter's
+ *    privacy-screen properties.
+ * @connector: connector for which to create the privacy-screen properties
+ *
+ * This function creates the "privacy-screen sw-state" and "privacy-screen
+ * hw-state" properties for the connector. They are not attached.
+ */
+void
+drm_connector_create_privacy_screen_properties(struct drm_connector *connector)
+{
+	if (connector->privacy_screen_sw_state_property)
+		return;
+
+	/* Note sw-state only supports the first 2 values of the enum */
+	connector->privacy_screen_sw_state_property =
+		drm_property_create_enum(connector->dev, DRM_MODE_PROP_ENUM,
+				"privacy-screen sw-state",
+				privacy_screen_enum, 2);
+
+	connector->privacy_screen_hw_state_property =
+		drm_property_create_enum(connector->dev,
+				DRM_MODE_PROP_IMMUTABLE | DRM_MODE_PROP_ENUM,
+				"privacy-screen hw-state",
+				privacy_screen_enum,
+				ARRAY_SIZE(privacy_screen_enum));
+}
+EXPORT_SYMBOL(drm_connector_create_privacy_screen_properties);
+
+/**
+ * drm_connector_attach_privacy_screen_properties - attach the drm connecter's
+ *    privacy-screen properties.
+ * @connector: connector on which to attach the privacy-screen properties
+ *
+ * This function attaches the "privacy-screen sw-state" and "privacy-screen
+ * hw-state" properties to the connector. The initial state of both is set
+ * to "Disabled".
+ */
+void
+drm_connector_attach_privacy_screen_properties(struct drm_connector *connector)
+{
+	if (!connector->privacy_screen_sw_state_property)
+		return;
+
+	drm_object_attach_property(&connector->base,
+				   connector->privacy_screen_sw_state_property,
+				   PRIVACY_SCREEN_DISABLED);
+
+	drm_object_attach_property(&connector->base,
+				   connector->privacy_screen_hw_state_property,
+				   PRIVACY_SCREEN_DISABLED);
+}
+EXPORT_SYMBOL(drm_connector_attach_privacy_screen_properties);
+
 int drm_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 fd543d1db9b2..9c77865e4093 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -271,6 +271,30 @@ struct drm_monitor_range_info {
 	u8 max_vfreq;
 };
 
+/**
+ * enum drm_privacy_screen_status - privacy screen status
+ *
+ * This enum is used to track and control the state of the integrated privacy
+ * screen present on some display panels, via the "privacy-screen sw-state"
+ * and "privacy-screen hw-state" properties. Note the _LOCKED enum values
+ * are only valid for the "privacy-screen hw-state" property.
+ *
+ * @PRIVACY_SCREEN_DISABLED:
+ *  The privacy-screen on the panel is disabled
+ * @PRIVACY_SCREEN_ENABLED:
+ *  The privacy-screen on the panel is enabled
+ * @PRIVACY_SCREEN_DISABLED_LOCKED:
+ *  The privacy-screen on the panel is disabled and locked (cannot be changed)
+ * @PRIVACY_SCREEN_ENABLED_LOCKED:
+ *  The privacy-screen on the panel is enabled and locked (cannot be changed)
+ */
+enum drm_privacy_screen_status {
+	PRIVACY_SCREEN_DISABLED = 0,
+	PRIVACY_SCREEN_ENABLED,
+	PRIVACY_SCREEN_DISABLED_LOCKED,
+	PRIVACY_SCREEN_ENABLED_LOCKED,
+};
+
 /*
  * This is a consolidated colorimetry list supported by HDMI and
  * DP protocol standard. The respective connectors will register
@@ -686,6 +710,12 @@ struct drm_connector_state {
 	 */
 	u8 max_bpc;
 
+	/**
+	 * @privacy_screen_sw_state: See :ref:`Standard Connector
+	 * Properties<standard_connector_properties>`
+	 */
+	enum drm_privacy_screen_status privacy_screen_sw_state;
+
 	/**
 	 * @hdr_output_metadata:
 	 * DRM blob property for HDR output metadata
@@ -1285,6 +1315,18 @@ struct drm_connector {
 	 */
 	struct drm_property *max_bpc_property;
 
+	/**
+	 * @privacy_screen_sw_state_property: Optional atomic property for the
+	 * connector to control the integrated privacy screen.
+	 */
+	struct drm_property *privacy_screen_sw_state_property;
+
+	/**
+	 * @privacy_screen_hw_state_property: Optional atomic property for the
+	 * connector to report the actual integrated privacy screen state.
+	 */
+	struct drm_property *privacy_screen_hw_state_property;
+
 #define DRM_CONNECTOR_POLL_HPD (1 << 0)
 #define DRM_CONNECTOR_POLL_CONNECT (1 << 1)
 #define DRM_CONNECTOR_POLL_DISCONNECT (1 << 2)
@@ -1598,6 +1640,8 @@ int drm_connector_set_panel_orientation_with_quirk(
 	int width, int height);
 int drm_connector_attach_max_bpc_property(struct drm_connector *connector,
 					  int min, int max);
+void drm_connector_create_privacy_screen_properties(struct drm_connector *conn);
+void drm_connector_attach_privacy_screen_properties(struct drm_connector *conn);
 
 /**
  * struct drm_tile_group - Tile group metadata
-- 
2.26.2

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply related	[flat|nested] 44+ messages in thread

* [Intel-gfx] [PATCH 2/9] drm/connector: Add support for privacy-screen properties (v4)
@ 2020-07-08 16:43   ` Hans de Goede
  0 siblings, 0 replies; 44+ messages in thread
From: Hans de Goede @ 2020-07-08 16:43 UTC (permalink / raw)
  To: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
	Daniel Vetter, David Airlie, Jani Nikula, Joonas Lahtinen,
	Rodrigo Vivi
  Cc: Marco Trevisan, Pekka Paalanen, Sebastien Bacher,
	Mario Limonciello, intel-gfx, dri-devel

From: Rajat Jain <rajatja@google.com>

Add support for generic electronic privacy screen properties, that
can be added by systems that have an integrated EPS.

Changes in v2 (Hans de Goede)
- Create 2 properties, "privacy-screen sw-state" and
  "privacy-screen hw-state", to deal with devices where the OS might be
  locked out of making state changes
- Write kerneldoc explaining how the 2 properties work together, what
  happens when changes to the state are made outside of the DRM code's
  control, etc.

Changes in v3 (Hans de Goede)
- Some small tweaks to the kerneldoc describing the 2 properties

Changes in v4 (Hans de Goede)
- Change the "Enabled, locked" and "Disabled, locked" hw-state enum value
  names to "Enabled-locked" and "Disabled-locked". The xrandr command shows
  all possible enum values separated by commas in its output, so having a
  comma in an enum name is not a good idea.
- Do not add a privacy_screen_hw_state member to drm_connector_state
  since this property is immutable its value must be directly stored in the
  obj->properties->values array

Signed-off-by: Rajat Jain <rajatja@google.com>
Co-authored-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Reviewed-by: Mario Limonciello <Mario.limonciello@dell.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
 Documentation/gpu/drm-kms.rst     |   2 +
 drivers/gpu/drm/drm_atomic_uapi.c |   4 ++
 drivers/gpu/drm/drm_connector.c   | 101 ++++++++++++++++++++++++++++++
 include/drm/drm_connector.h       |  44 +++++++++++++
 4 files changed, 151 insertions(+)

diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
index 397314d08f77..30d5781d99b1 100644
--- a/Documentation/gpu/drm-kms.rst
+++ b/Documentation/gpu/drm-kms.rst
@@ -448,6 +448,8 @@ Property Types and Blob Property Support
 .. kernel-doc:: drivers/gpu/drm/drm_property.c
    :export:
 
+.. _standard_connector_properties:
+
 Standard Connector Properties
 -----------------------------
 
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c b/drivers/gpu/drm/drm_atomic_uapi.c
index a1e5e262bae2..2bf2dbe3ea6f 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -766,6 +766,8 @@ static int drm_atomic_connector_set_property(struct drm_connector *connector,
 						   fence_ptr);
 	} else if (property == connector->max_bpc_property) {
 		state->max_requested_bpc = val;
+	} else if (property == connector->privacy_screen_sw_state_property) {
+		state->privacy_screen_sw_state = val;
 	} else if (connector->funcs->atomic_set_property) {
 		return connector->funcs->atomic_set_property(connector,
 				state, property, val);
@@ -842,6 +844,8 @@ drm_atomic_connector_get_property(struct drm_connector *connector,
 		*val = 0;
 	} else if (property == connector->max_bpc_property) {
 		*val = state->max_requested_bpc;
+	} else if (property == connector->privacy_screen_sw_state_property) {
+		*val = state->privacy_screen_sw_state;
 	} else if (connector->funcs->atomic_get_property) {
 		return connector->funcs->atomic_get_property(connector,
 				state, property, val);
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 543086533850..bce5e0cc5884 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1191,6 +1191,46 @@ static const struct drm_prop_enum_list dp_colorspaces[] = {
  *	can also expose this property to external outputs, in which case they
  *	must support "None", which should be the default (since external screens
  *	have a built-in scaler).
+ *
+ * privacy-screen sw-state, privacy-screen hw-state:
+ *	These 2 optional properties can be used to query the state of the
+ *	electronic privacy screen that is available on some displays; and in
+ *	some cases also control the state. If a driver implements these
+ *	properties then both properties must be present.
+ *
+ *	"privacy-screen hw-state" is read-only and reflects the actual state
+ *	of the privacy-screen, possible values: "Enabled", "Disabled,
+ *	"Enabled, locked", "Disabled, locked". The locked states indicate
+ *	that the state cannot be changed through the DRM API. E.g. there
+ *	might be devices where the firmware-setup options, or a hardware
+ *	slider-switch, offer always on / off modes.
+ *
+ *	"privacy-screen sw-state" can be set to change the privacy-screen state
+ *	when not locked. In this case the driver must update the hw-state
+ *	property to reflect the new state on completion of the commit of the
+ *	sw-state property. Setting the sw-state property when the hw-state is
+ *	locked must be interpreted by the driver as a request to change the
+ *	state to the set state when the hw-state becomes unlocked. E.g. if
+ *	"privacy-screen hw-state" is "Enabled, locked" and the sw-state
+ *	gets set to "Disabled" followed by the user unlocking the state by
+ *	changing the slider-switch position, then the driver must set the
+ *	state to "Disabled" upon receiving the unlock event.
+ *
+ *	In some cases the privacy-screen's actual state might change outside of
+ *	control of the DRM code. E.g. there might be a firmware handled hotkey
+ *	which toggles the actual state, or the actual state might be changed
+ *	through another userspace API such as writing /proc/acpi/ibm/lcdshadow.
+ *	In this case the driver must update both the hw-state and the sw-state
+ *	to reflect the new value, overwriting any pending state requests in the
+ *	sw-state. Any pending sw-state requests are thus discarded.
+ *
+ *	Note that the ability for the state to change outside of control of
+ *	the DRM master process means that userspace must not cache the value
+ *	of the sw-state. Caching the sw-state value and including it in later
+ *	atomic commits may lead to overriding a state change done through e.g.
+ *	a firmware handled hotkey. Therefor userspace must not include the
+ *	privacy-screen sw-state in an atomic commit unless it wants to change
+ *	its value.
  */
 
 int drm_connector_create_standard_properties(struct drm_device *dev)
@@ -2159,6 +2199,67 @@ int drm_connector_set_panel_orientation_with_quirk(
 }
 EXPORT_SYMBOL(drm_connector_set_panel_orientation_with_quirk);
 
+static const struct drm_prop_enum_list privacy_screen_enum[] = {
+	{ PRIVACY_SCREEN_DISABLED,		"Disabled" },
+	{ PRIVACY_SCREEN_ENABLED,		"Enabled" },
+	{ PRIVACY_SCREEN_DISABLED_LOCKED,	"Disabled-locked" },
+	{ PRIVACY_SCREEN_ENABLED_LOCKED,	"Enabled-locked" },
+};
+
+/**
+ * drm_connector_create_privacy_screen_properties - create the drm connecter's
+ *    privacy-screen properties.
+ * @connector: connector for which to create the privacy-screen properties
+ *
+ * This function creates the "privacy-screen sw-state" and "privacy-screen
+ * hw-state" properties for the connector. They are not attached.
+ */
+void
+drm_connector_create_privacy_screen_properties(struct drm_connector *connector)
+{
+	if (connector->privacy_screen_sw_state_property)
+		return;
+
+	/* Note sw-state only supports the first 2 values of the enum */
+	connector->privacy_screen_sw_state_property =
+		drm_property_create_enum(connector->dev, DRM_MODE_PROP_ENUM,
+				"privacy-screen sw-state",
+				privacy_screen_enum, 2);
+
+	connector->privacy_screen_hw_state_property =
+		drm_property_create_enum(connector->dev,
+				DRM_MODE_PROP_IMMUTABLE | DRM_MODE_PROP_ENUM,
+				"privacy-screen hw-state",
+				privacy_screen_enum,
+				ARRAY_SIZE(privacy_screen_enum));
+}
+EXPORT_SYMBOL(drm_connector_create_privacy_screen_properties);
+
+/**
+ * drm_connector_attach_privacy_screen_properties - attach the drm connecter's
+ *    privacy-screen properties.
+ * @connector: connector on which to attach the privacy-screen properties
+ *
+ * This function attaches the "privacy-screen sw-state" and "privacy-screen
+ * hw-state" properties to the connector. The initial state of both is set
+ * to "Disabled".
+ */
+void
+drm_connector_attach_privacy_screen_properties(struct drm_connector *connector)
+{
+	if (!connector->privacy_screen_sw_state_property)
+		return;
+
+	drm_object_attach_property(&connector->base,
+				   connector->privacy_screen_sw_state_property,
+				   PRIVACY_SCREEN_DISABLED);
+
+	drm_object_attach_property(&connector->base,
+				   connector->privacy_screen_hw_state_property,
+				   PRIVACY_SCREEN_DISABLED);
+}
+EXPORT_SYMBOL(drm_connector_attach_privacy_screen_properties);
+
 int drm_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 fd543d1db9b2..9c77865e4093 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -271,6 +271,30 @@ struct drm_monitor_range_info {
 	u8 max_vfreq;
 };
 
+/**
+ * enum drm_privacy_screen_status - privacy screen status
+ *
+ * This enum is used to track and control the state of the integrated privacy
+ * screen present on some display panels, via the "privacy-screen sw-state"
+ * and "privacy-screen hw-state" properties. Note the _LOCKED enum values
+ * are only valid for the "privacy-screen hw-state" property.
+ *
+ * @PRIVACY_SCREEN_DISABLED:
+ *  The privacy-screen on the panel is disabled
+ * @PRIVACY_SCREEN_ENABLED:
+ *  The privacy-screen on the panel is enabled
+ * @PRIVACY_SCREEN_DISABLED_LOCKED:
+ *  The privacy-screen on the panel is disabled and locked (cannot be changed)
+ * @PRIVACY_SCREEN_ENABLED_LOCKED:
+ *  The privacy-screen on the panel is enabled and locked (cannot be changed)
+ */
+enum drm_privacy_screen_status {
+	PRIVACY_SCREEN_DISABLED = 0,
+	PRIVACY_SCREEN_ENABLED,
+	PRIVACY_SCREEN_DISABLED_LOCKED,
+	PRIVACY_SCREEN_ENABLED_LOCKED,
+};
+
 /*
  * This is a consolidated colorimetry list supported by HDMI and
  * DP protocol standard. The respective connectors will register
@@ -686,6 +710,12 @@ struct drm_connector_state {
 	 */
 	u8 max_bpc;
 
+	/**
+	 * @privacy_screen_sw_state: See :ref:`Standard Connector
+	 * Properties<standard_connector_properties>`
+	 */
+	enum drm_privacy_screen_status privacy_screen_sw_state;
+
 	/**
 	 * @hdr_output_metadata:
 	 * DRM blob property for HDR output metadata
@@ -1285,6 +1315,18 @@ struct drm_connector {
 	 */
 	struct drm_property *max_bpc_property;
 
+	/**
+	 * @privacy_screen_sw_state_property: Optional atomic property for the
+	 * connector to control the integrated privacy screen.
+	 */
+	struct drm_property *privacy_screen_sw_state_property;
+
+	/**
+	 * @privacy_screen_hw_state_property: Optional atomic property for the
+	 * connector to report the actual integrated privacy screen state.
+	 */
+	struct drm_property *privacy_screen_hw_state_property;
+
 #define DRM_CONNECTOR_POLL_HPD (1 << 0)
 #define DRM_CONNECTOR_POLL_CONNECT (1 << 1)
 #define DRM_CONNECTOR_POLL_DISCONNECT (1 << 2)
@@ -1598,6 +1640,8 @@ int drm_connector_set_panel_orientation_with_quirk(
 	int width, int height);
 int drm_connector_attach_max_bpc_property(struct drm_connector *connector,
 					  int min, int max);
+void drm_connector_create_privacy_screen_properties(struct drm_connector *conn);
+void drm_connector_attach_privacy_screen_properties(struct drm_connector *conn);
 
 /**
  * struct drm_tile_group - Tile group metadata
-- 
2.26.2

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply related	[flat|nested] 44+ messages in thread

* [PATCH 3/9] drm: Add privacy-screen class
  2020-07-08 16:43 ` [Intel-gfx] " Hans de Goede
@ 2020-07-08 16:43   ` Hans de Goede
  -1 siblings, 0 replies; 44+ messages in thread
From: Hans de Goede @ 2020-07-08 16:43 UTC (permalink / raw)
  To: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
	Daniel Vetter, David Airlie, Jani Nikula, Joonas Lahtinen,
	Rodrigo Vivi
  Cc: Hans de Goede, intel-gfx, dri-devel, Sebastien Bacher, Marco Trevisan

On some new laptops the LCD panel has a builtin electronic privacy-screen.
We want to export this functionality as a property on the drm connector
object. But often this functionality is not exposed on the GPU but on some
other (ACPI) device.

This commit adds a privacy-screen class allowing the driver for these
other devices to register themselves as a privacy-screen provider; and
allowing the drm/kms code to get a privacy-screen provider associated
with a specific GPU/connector combo.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
 Documentation/gpu/drm-kms-helpers.rst     |  15 +
 MAINTAINERS                               |   8 +
 drivers/gpu/drm/Kconfig                   |   5 +
 drivers/gpu/drm/Makefile                  |   1 +
 drivers/gpu/drm/drm_privacy_screen.c      | 426 ++++++++++++++++++++++
 include/drm/drm_privacy_screen_consumer.h |  27 ++
 include/drm/drm_privacy_screen_driver.h   |  80 ++++
 include/drm/drm_privacy_screen_machine.h  |  41 +++
 8 files changed, 603 insertions(+)
 create mode 100644 drivers/gpu/drm/drm_privacy_screen.c
 create mode 100644 include/drm/drm_privacy_screen_consumer.h
 create mode 100644 include/drm/drm_privacy_screen_driver.h
 create mode 100644 include/drm/drm_privacy_screen_machine.h

diff --git a/Documentation/gpu/drm-kms-helpers.rst b/Documentation/gpu/drm-kms-helpers.rst
index b411adb98960..8ce74f3f41d0 100644
--- a/Documentation/gpu/drm-kms-helpers.rst
+++ b/Documentation/gpu/drm-kms-helpers.rst
@@ -424,3 +424,18 @@ SHMEM GEM Helper Reference
 
 .. kernel-doc:: drivers/gpu/drm/drm_gem_shmem_helper.c
    :export:
+
+Privacy-screen class
+====================
+
+.. kernel-doc:: drivers/gpu/drm/drm_privacy_screen.c
+   :doc: overview
+
+.. kernel-doc:: include/drm/drm_privacy_screen_driver.h
+   :internal:
+
+.. kernel-doc:: include/drm/drm_privacy_screen_machine.h
+   :internal:
+
+.. kernel-doc:: drivers/gpu/drm/drm_privacy_screen.c
+   :export:
diff --git a/MAINTAINERS b/MAINTAINERS
index f465eb96c303..9434f67e3c0b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5862,6 +5862,14 @@ F:	drivers/gpu/drm/drm_panel.c
 F:	drivers/gpu/drm/panel/
 F:	include/drm/drm_panel.h
 
+DRM PRIVACY-SCREEN CLASS
+M:	Hans de Goede <hdegoede@redhat.com>
+L:	dri-devel@lists.freedesktop.org
+S:	Maintained
+T:	git git://anongit.freedesktop.org/drm/drm-misc
+F:	drivers/gpu/drm/drm_privacy_screen*
+F:	include/drm/drm_privacy_screen*
+
 DRM TTM SUBSYSTEM
 M:	Christian Koenig <christian.koenig@amd.com>
 M:	Huang Rui <ray.huang@amd.com>
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index c4fd57d8b717..5dbfabad1050 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -475,3 +475,8 @@ config DRM_PANEL_ORIENTATION_QUIRKS
 config DRM_LIB_RANDOM
 	bool
 	default n
+
+# Separate option, used by drivers outside of drivers/gpu/drm
+config DRM_PRIVACY_SCREEN
+	tristate
+	default n
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 2c0e5a7e5953..621afac6e447 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -61,6 +61,7 @@ obj-$(CONFIG_DRM)	+= drm.o
 obj-$(CONFIG_DRM_MIPI_DBI) += drm_mipi_dbi.o
 obj-$(CONFIG_DRM_MIPI_DSI) += drm_mipi_dsi.o
 obj-$(CONFIG_DRM_PANEL_ORIENTATION_QUIRKS) += drm_panel_orientation_quirks.o
+obj-$(CONFIG_DRM_PRIVACY_SCREEN) += drm_privacy_screen.o
 obj-y			+= arm/
 obj-$(CONFIG_DRM_TTM)	+= ttm/
 obj-$(CONFIG_DRM_SCHED)	+= scheduler/
diff --git a/drivers/gpu/drm/drm_privacy_screen.c b/drivers/gpu/drm/drm_privacy_screen.c
new file mode 100644
index 000000000000..6296fd46156c
--- /dev/null
+++ b/drivers/gpu/drm/drm_privacy_screen.c
@@ -0,0 +1,426 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright (C) 2020 Red Hat, Inc.
+ *
+ * Authors:
+ * Hans de Goede <hdegoede@redhat.com>
+ */
+
+#include <linux/device.h>
+#include <linux/kernel.h>
+#include <linux/list.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/slab.h>
+#include <drm/drm_privacy_screen_machine.h>
+#include <drm/drm_privacy_screen_consumer.h>
+#include <drm/drm_privacy_screen_driver.h>
+
+/**
+ * DOC: overview
+ *
+ * This class allows non KMS drivers, from e.g. drivers/platform/x86 to
+ * register a privacy-screen device, which the KMS drivers can then use
+ * to implement the standard privacy-screen properties, see
+ * :ref:`Standard Connector Properties<standard_connector_properties>`.
+ *
+ * KMS drivers using a privacy-screen class device are advised to use the
+ * drm_connector_attach_privacy_screen_provider() and
+ * drm_connector_update_privacy_screen() helpers for dealing with this.
+ */
+
+#define to_drm_privacy_screen(dev) \
+	container_of(dev, struct drm_privacy_screen, dev)
+
+static DEFINE_MUTEX(drm_privacy_screen_lookup_lock);
+static LIST_HEAD(drm_privacy_screen_lookup_list);
+
+static DEFINE_MUTEX(drm_privacy_screen_devs_lock);
+static LIST_HEAD(drm_privacy_screen_devs);
+
+/*** drm_privacy_screen_machine.h functions ***/
+
+/**
+ * drm_privacy_screen_lookup_add - add an entry to the static privacy-screen
+ *    lookup list
+ * @lookup: lookup list entry to add
+ *
+ * Add an entry to the static privacy-screen lookup list. Note the
+ * &struct list_head which is part of the &struct drm_privacy_screen_lookup
+ * gets added to a list owned by the privacy-screen core. So the passed in
+ * &struct drm_privacy_screen_lookup must not be free-ed until it is removed
+ * from the lookup list by calling drm_privacy_screen_lookup_remove().
+ */
+void drm_privacy_screen_lookup_add(struct drm_privacy_screen_lookup *lookup)
+{
+	mutex_lock(&drm_privacy_screen_lookup_lock);
+	list_add(&lookup->list, &drm_privacy_screen_lookup_list);
+	mutex_unlock(&drm_privacy_screen_lookup_lock);
+}
+EXPORT_SYMBOL(drm_privacy_screen_lookup_add);
+
+/**
+ * drm_privacy_screen_lookup_remove - remove an entry to the static
+ *    privacy-screen lookup list
+ * @lookup: lookup list entry to remove
+ *
+ * Remove an entry previously added with drm_privacy_screen_lookup_add()
+ * from the static privacy-screen lookup list.
+ */
+void drm_privacy_screen_lookup_remove(struct drm_privacy_screen_lookup *lookup)
+{
+	mutex_lock(&drm_privacy_screen_lookup_lock);
+	list_del(&lookup->list);
+	mutex_unlock(&drm_privacy_screen_lookup_lock);
+}
+EXPORT_SYMBOL(drm_privacy_screen_lookup_remove);
+
+/*** drm_privacy_screen_consumer.h functions ***/
+
+static struct drm_privacy_screen *drm_privacy_screen_get_by_name(
+	const char *name)
+{
+	struct drm_privacy_screen *priv;
+	struct device *dev = NULL;
+
+	mutex_lock(&drm_privacy_screen_devs_lock);
+
+	list_for_each_entry(priv, &drm_privacy_screen_devs, list) {
+		if (strcmp(dev_name(&priv->dev), name) == 0) {
+			dev = get_device(&priv->dev);
+			break;
+		}
+	}
+
+	mutex_unlock(&drm_privacy_screen_devs_lock);
+
+	return dev ? to_drm_privacy_screen(dev) : NULL;
+}
+
+/**
+ * drm_privacy_screen_get - get a privacy-screen provider
+ * @dev: consumer-device for which to get a privacy-screen provider
+ * @con_id: (video)connector name for which to get a privacy-screen provider
+ *
+ * Get a privacy-screen provider for a privacy-screen attached to the
+ * display described by the @dev and @con_id parameters.
+ *
+ * Return:
+ * * A pointer to a &struct drm_privacy_screen on success.
+ * * ERR_PTR(-ENODEV) if no matching privacy-screen is found
+ * * ERR_PTR(-EPROBE_DEFER) if there is a matching privacy-screen,
+ *                          but it has not been registered yet.
+ */
+struct drm_privacy_screen *drm_privacy_screen_get(struct device *dev,
+						  const char *con_id)
+{
+	const char *dev_id = dev ? dev_name(dev) : NULL;
+	struct drm_privacy_screen_lookup *l;
+	struct drm_privacy_screen *priv;
+	const char *provider = NULL;
+	int match, best = -1;
+
+	/*
+	 * For now we only support using a static lookup table, which is
+	 * populated by the drm_privacy_screen_arch_init() call. This should
+	 * be extended with device-tree / fw_node lookup when support is added
+	 * for device-tree using hardware with a privacy-screen.
+	 *
+	 * The lookup algorithm was shamelessly taken from the clock
+	 * framework:
+	 *
+	 * We do slightly fuzzy matching here:
+	 *  An entry with a NULL ID is assumed to be a wildcard.
+	 *  If an entry has a device ID, it must match
+	 *  If an entry has a connection ID, it must match
+	 * Then we take the most specific entry - with the following order
+	 * of precedence: dev+con > dev only > con only.
+	 */
+	mutex_lock(&drm_privacy_screen_lookup_lock);
+
+	list_for_each_entry(l, &drm_privacy_screen_lookup_list, list) {
+		match = 0;
+
+		if (l->dev_id) {
+			if (!dev_id || strcmp(l->dev_id, dev_id))
+				continue;
+
+			match += 2;
+		}
+
+		if (l->con_id) {
+			if (!con_id || strcmp(l->con_id, con_id))
+				continue;
+
+			match += 1;
+		}
+
+		if (match > best) {
+			provider = l->provider;
+			best = match;
+		}
+	}
+
+	mutex_unlock(&drm_privacy_screen_lookup_lock);
+
+	if (!provider)
+		return ERR_PTR(-ENODEV);
+
+	priv = drm_privacy_screen_get_by_name(provider);
+	if (!priv)
+		return ERR_PTR(-EPROBE_DEFER);
+
+	return priv;
+}
+EXPORT_SYMBOL(drm_privacy_screen_get);
+
+/**
+ * drm_privacy_screen_put - release a privacy-screen reference
+ * @priv: privacy screen reference to release
+ *
+ * Release a privacy-screen provider reference gotten through
+ * drm_privacy_screen_get(). May be called with a NULL or ERR_PTR,
+ * in which case it is a no-op.
+ */
+void drm_privacy_screen_put(struct drm_privacy_screen *priv)
+{
+	if (IS_ERR_OR_NULL(priv))
+		return;
+
+	put_device(&priv->dev);
+}
+EXPORT_SYMBOL(drm_privacy_screen_put);
+
+/**
+ * drm_privacy_screen_set_sw_state - set a privacy-screen's sw-state
+ * @priv: privacy screen to set the sw-state for
+ * @sw_state: new sw-state value to set
+ *
+ * Set the sw-state of a privacy screen. If the privacy-screen is not
+ * in a locked hw-state, then the actual and hw-state of the privacy-screen
+ * will be immediately updated to the new value. If the privacy-screen is
+ * in a locked hw-state, then the new sw-state will be remembered as the
+ * requested state to put the privacy-screen in when it becomes unlocked.
+ *
+ * Return: 0 on success, negative error code on failure.
+ */
+int drm_privacy_screen_set_sw_state(struct drm_privacy_screen *priv,
+				    enum drm_privacy_screen_status sw_state)
+{
+	int ret = 0;
+
+	mutex_lock(&priv->lock);
+
+	if (!priv->ops) {
+		ret = -ENODEV;
+		goto out;
+	}
+
+	/*
+	 * As per the DRM connector properties documentation, setting the
+	 * sw_state while the hw_state is locked is allowed. In this case
+	 * it is a no-op other then storing the new sw_state so that it
+	 * can be honored when the state gets unlocked.
+	 */
+	if (priv->hw_state >= PRIVACY_SCREEN_DISABLED_LOCKED) {
+		priv->sw_state = sw_state;
+		goto out;
+	}
+
+	ret = priv->ops->set_sw_state(priv, sw_state);
+out:
+	mutex_unlock(&priv->lock);
+	return ret;
+}
+EXPORT_SYMBOL(drm_privacy_screen_set_sw_state);
+
+/**
+ * drm_privacy_screen_get_state - get privacy-screen's current state
+ * @priv: privacy screen to get the state for
+ * @sw_state_ret: address where to store the privacy-screens current sw-state
+ * @hw_state_ret: address where to store the privacy-screens current hw-state
+ *
+ * Get the current state of a privacy-screen, both the sw-state and the
+ * hw-state.
+ */
+void drm_privacy_screen_get_state(struct drm_privacy_screen *priv,
+				  enum drm_privacy_screen_status *sw_state_ret,
+				  enum drm_privacy_screen_status *hw_state_ret)
+{
+	mutex_lock(&priv->lock);
+	*sw_state_ret = priv->sw_state;
+	*hw_state_ret = priv->hw_state;
+	mutex_unlock(&priv->lock);
+}
+EXPORT_SYMBOL(drm_privacy_screen_get_state);
+
+/*** drm_privacy_screen_driver.h functions ***/
+
+static ssize_t sw_state_show(struct device *dev,
+			     struct device_attribute *attr, char *buf)
+{
+	struct drm_privacy_screen *priv = to_drm_privacy_screen(dev);
+	const char * const sw_state_names[] = {
+		"Disabled",
+		"Enabled",
+	};
+	ssize_t ret;
+
+	mutex_lock(&priv->lock);
+
+	if (!priv->ops)
+		ret = -ENODEV;
+	else if (WARN_ON(priv->sw_state >= ARRAY_SIZE(sw_state_names)))
+		ret = -ENXIO;
+	else
+		ret = sprintf(buf, "%s\n", sw_state_names[priv->sw_state]);
+
+	mutex_unlock(&priv->lock);
+	return ret;
+}
+/*
+ * RO: Do not allow setting the sw_state through sysfs, this MUST be done
+ * through the drm_properties on the drm_connector.
+ */
+static DEVICE_ATTR_RO(sw_state);
+
+static ssize_t hw_state_show(struct device *dev,
+			     struct device_attribute *attr, char *buf)
+{
+	struct drm_privacy_screen *priv = to_drm_privacy_screen(dev);
+	const char * const hw_state_names[] = {
+		"Disabled",
+		"Enabled",
+		"Disabled, locked",
+		"Enabled, locked",
+	};
+	ssize_t ret;
+
+	mutex_lock(&priv->lock);
+
+	if (!priv->ops)
+		ret = -ENODEV;
+	else if (WARN_ON(priv->hw_state >= ARRAY_SIZE(hw_state_names)))
+		ret = -ENXIO;
+	else
+		ret = sprintf(buf, "%s\n", hw_state_names[priv->hw_state]);
+
+	mutex_unlock(&priv->lock);
+	return ret;
+}
+static DEVICE_ATTR_RO(hw_state);
+
+static struct attribute *drm_privacy_screen_attrs[] = {
+	&dev_attr_sw_state.attr,
+	&dev_attr_hw_state.attr,
+	NULL
+};
+ATTRIBUTE_GROUPS(drm_privacy_screen);
+
+static struct class drm_privacy_screen_class = {
+	.name = "privacy_screen",
+	.owner = THIS_MODULE,
+	.dev_groups = drm_privacy_screen_groups,
+};
+
+static void drm_privacy_screen_device_release(struct device *dev)
+{
+	struct drm_privacy_screen *priv = to_drm_privacy_screen(dev);
+
+	kfree(priv);
+}
+
+/**
+ * drm_privacy_screen_register - register a privacy-screen
+ * @parent: parent-device for the privacy-screen
+ * @ops: &struct drm_privacy_screen_ops pointer with ops for the privacy-screen
+ *
+ * Create and register a privacy-screen.
+ *
+ * Return:
+ * * A pointer to the created privacy-screen on success.
+ * * An ERR_PTR(errno) on failure.
+ */
+struct drm_privacy_screen *drm_privacy_screen_register(
+	struct device *parent, const struct drm_privacy_screen_ops *ops)
+{
+	struct drm_privacy_screen *priv;
+	int ret;
+
+	priv = kzalloc(sizeof(*priv), GFP_KERNEL);
+	if (!priv)
+		return ERR_PTR(-ENOMEM);
+
+	mutex_init(&priv->lock);
+
+	priv->dev.class = &drm_privacy_screen_class;
+	priv->dev.parent = parent;
+	priv->dev.release = drm_privacy_screen_device_release;
+	dev_set_name(&priv->dev, "%s", dev_name(parent));
+	priv->ops = ops;
+
+	priv->ops->get_hw_state(priv);
+
+	ret = device_register(&priv->dev);
+	if (ret) {
+		put_device(&priv->dev);
+		return ERR_PTR(ret);
+	}
+
+	mutex_lock(&drm_privacy_screen_devs_lock);
+	list_add(&priv->list, &drm_privacy_screen_devs);
+	mutex_unlock(&drm_privacy_screen_devs_lock);
+
+	return priv;
+}
+EXPORT_SYMBOL(drm_privacy_screen_register);
+
+/**
+ * drm_privacy_screen_unregister - unregister privacy-screen
+ * @priv: privacy-screen to unregister
+ *
+ * Unregister a privacy-screen registered with drm_privacy_screen_register().
+ * May be called with a NULL or ERR_PTR, in which case it is a no-op.
+ */
+void drm_privacy_screen_unregister(struct drm_privacy_screen *priv)
+{
+	if (IS_ERR_OR_NULL(priv))
+		return;
+
+	mutex_lock(&drm_privacy_screen_devs_lock);
+	list_del(&priv->list);
+	mutex_unlock(&drm_privacy_screen_devs_lock);
+
+	mutex_lock(&priv->lock);
+	priv->ops = NULL;
+	mutex_unlock(&priv->lock);
+
+	device_unregister(&priv->dev);
+}
+EXPORT_SYMBOL(drm_privacy_screen_unregister);
+
+static int __init drm_privacy_screen_init(void)
+{
+	int ret;
+
+	ret = class_register(&drm_privacy_screen_class);
+	if (ret)
+		return ret;
+
+	drm_privacy_screen_arch_init();
+
+	return 0;
+}
+
+static void __exit drm_privacy_screen_exit(void)
+{
+	drm_privacy_screen_arch_exit();
+	class_unregister(&drm_privacy_screen_class);
+}
+
+subsys_initcall(drm_privacy_screen_init);
+module_exit(drm_privacy_screen_exit);
+
+MODULE_AUTHOR("Hans de Goede");
+MODULE_DESCRIPTION("DRM privacy-screen class");
+MODULE_LICENSE("GPL and additional rights");
diff --git a/include/drm/drm_privacy_screen_consumer.h b/include/drm/drm_privacy_screen_consumer.h
new file mode 100644
index 000000000000..169ba72bd60d
--- /dev/null
+++ b/include/drm/drm_privacy_screen_consumer.h
@@ -0,0 +1,27 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright (C) 2020 Red Hat, Inc.
+ *
+ * Authors:
+ * Hans de Goede <hdegoede@redhat.com>
+ */
+
+#ifndef __DRM_PRIVACY_SCREEN_CONSUMER_H__
+#define __DRM_PRIVACY_SCREEN_CONSUMER_H__
+
+#include <linux/device.h>
+#include <drm/drm_connector.h>
+
+struct drm_privacy_screen;
+
+struct drm_privacy_screen *drm_privacy_screen_get(struct device *dev,
+						  const char *con_id);
+void drm_privacy_screen_put(struct drm_privacy_screen *priv);
+
+int drm_privacy_screen_set_sw_state(struct drm_privacy_screen *priv,
+				    enum drm_privacy_screen_status sw_state);
+void drm_privacy_screen_get_state(struct drm_privacy_screen *priv,
+				  enum drm_privacy_screen_status *sw_state_ret,
+				  enum drm_privacy_screen_status *hw_state_ret);
+
+#endif
diff --git a/include/drm/drm_privacy_screen_driver.h b/include/drm/drm_privacy_screen_driver.h
new file mode 100644
index 000000000000..5187ae52eb03
--- /dev/null
+++ b/include/drm/drm_privacy_screen_driver.h
@@ -0,0 +1,80 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright (C) 2020 Red Hat, Inc.
+ *
+ * Authors:
+ * Hans de Goede <hdegoede@redhat.com>
+ */
+
+#ifndef __DRM_PRIVACY_SCREEN_DRIVER_H__
+#define __DRM_PRIVACY_SCREEN_DRIVER_H__
+
+#include <linux/device.h>
+#include <linux/list.h>
+#include <linux/mutex.h>
+#include <drm/drm_connector.h>
+
+struct drm_privacy_screen;
+
+/**
+ * struct drm_privacy_screen_ops - drm_privacy_screen operations
+ *
+ * Defines the operations which the privacy-screen class code may call.
+ * These functions should be implemented by the privacy-screen driver.
+ */
+struct drm_privacy_screen_ops {
+	/**
+	 * @set_sw_state: Called to request a change of the privacy-screen
+	 * state. The privacy-screen class code contains a check to avoid this
+	 * getting called when the hw_state reports the state is locked.
+	 * It is the driver's responsibility to update sw_state and hw_state.
+	 * This is always called with the drm_privacy_screen's lock held.
+	 */
+	int (*set_sw_state)(struct drm_privacy_screen *priv,
+			    enum drm_privacy_screen_status sw_state);
+	/**
+	 * @get_hw_state: Called to request that the driver gets the current
+	 * privacy-screen state from the hardware and then updates sw_state and
+	 * hw_state accordingly. This will be called by the core just before
+	 * the privacy-screen is registered in sysfs.
+	 */
+	void (*get_hw_state)(struct drm_privacy_screen *priv);
+};
+
+/**
+ * struct drm_privacy_screen - central privacy-screen structure
+ *
+ * Central privacy-screen structure, this contains the struct device used
+ * to register the screen in sysfs, the screen's state, ops, etc.
+ */
+struct drm_privacy_screen {
+	/** @dev: device used to register the privacy-screen in sysfs. */
+	struct device dev;
+	/** @lock: mutex protection all fields in this struct. */
+	struct mutex lock;
+	/** @list: privacy-screen devices list list-entry. */
+	struct list_head list;
+	/**
+	 * @ops: &struct drm_privacy_screen_ops for this privacy-screen.
+	 * This is NULL if the driver has unregistered the privacy-screen.
+	 */
+	const struct drm_privacy_screen_ops *ops;
+	/**
+	 * @sw_state: The privacy-screen's software state, see
+	 * :ref:`Standard Connector Properties<standard_connector_properties>`
+	 * for more info.
+	 */
+	enum drm_privacy_screen_status sw_state;
+	/**
+	 * @hw_state: The privacy-screen's hardware state, see
+	 * :ref:`Standard Connector Properties<standard_connector_properties>`
+	 * for more info.
+	 */
+	enum drm_privacy_screen_status hw_state;
+};
+
+struct drm_privacy_screen *drm_privacy_screen_register(
+	struct device *parent, const struct drm_privacy_screen_ops *ops);
+void drm_privacy_screen_unregister(struct drm_privacy_screen *priv);
+
+#endif
diff --git a/include/drm/drm_privacy_screen_machine.h b/include/drm/drm_privacy_screen_machine.h
new file mode 100644
index 000000000000..55f4b4fd8e4e
--- /dev/null
+++ b/include/drm/drm_privacy_screen_machine.h
@@ -0,0 +1,41 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright (C) 2020 Red Hat, Inc.
+ *
+ * Authors:
+ * Hans de Goede <hdegoede@redhat.com>
+ */
+
+#ifndef __DRM_PRIVACY_SCREEN_MACHINE_H__
+#define __DRM_PRIVACY_SCREEN_MACHINE_H__
+
+#include <linux/list.h>
+
+/**
+ * struct drm_privacy_screen_lookup -  static privacy-screen lookup list entry
+ *
+ * Used for the static lookup-list for mapping privacy-screen consumer
+ * dev-connector pairs to a privacy-screen provider.
+ */
+struct drm_privacy_screen_lookup {
+	/** @list: Lookup list list-entry. */
+	struct list_head list;
+	/** @dev_id: Consumer device name or NULL to match all devices. */
+	const char *dev_id;
+	/** @con_id: Consumer connector name or NULL to match all connectors. */
+	const char *con_id;
+	/** @provider: dev_name() of the privacy_screen provider. */
+	const char *provider;
+};
+
+void drm_privacy_screen_lookup_add(struct drm_privacy_screen_lookup *lookup);
+void drm_privacy_screen_lookup_remove(struct drm_privacy_screen_lookup *lookup);
+
+static inline void drm_privacy_screen_arch_init(void)
+{
+}
+static inline void drm_privacy_screen_arch_exit(void)
+{
+}
+
+#endif
-- 
2.26.2

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply related	[flat|nested] 44+ messages in thread

* [Intel-gfx] [PATCH 3/9] drm: Add privacy-screen class
@ 2020-07-08 16:43   ` Hans de Goede
  0 siblings, 0 replies; 44+ messages in thread
From: Hans de Goede @ 2020-07-08 16:43 UTC (permalink / raw)
  To: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
	Daniel Vetter, David Airlie, Jani Nikula, Joonas Lahtinen,
	Rodrigo Vivi
  Cc: intel-gfx, dri-devel, Sebastien Bacher, Marco Trevisan

On some new laptops the LCD panel has a builtin electronic privacy-screen.
We want to export this functionality as a property on the drm connector
object. But often this functionality is not exposed on the GPU but on some
other (ACPI) device.

This commit adds a privacy-screen class allowing the driver for these
other devices to register themselves as a privacy-screen provider; and
allowing the drm/kms code to get a privacy-screen provider associated
with a specific GPU/connector combo.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
 Documentation/gpu/drm-kms-helpers.rst     |  15 +
 MAINTAINERS                               |   8 +
 drivers/gpu/drm/Kconfig                   |   5 +
 drivers/gpu/drm/Makefile                  |   1 +
 drivers/gpu/drm/drm_privacy_screen.c      | 426 ++++++++++++++++++++++
 include/drm/drm_privacy_screen_consumer.h |  27 ++
 include/drm/drm_privacy_screen_driver.h   |  80 ++++
 include/drm/drm_privacy_screen_machine.h  |  41 +++
 8 files changed, 603 insertions(+)
 create mode 100644 drivers/gpu/drm/drm_privacy_screen.c
 create mode 100644 include/drm/drm_privacy_screen_consumer.h
 create mode 100644 include/drm/drm_privacy_screen_driver.h
 create mode 100644 include/drm/drm_privacy_screen_machine.h

diff --git a/Documentation/gpu/drm-kms-helpers.rst b/Documentation/gpu/drm-kms-helpers.rst
index b411adb98960..8ce74f3f41d0 100644
--- a/Documentation/gpu/drm-kms-helpers.rst
+++ b/Documentation/gpu/drm-kms-helpers.rst
@@ -424,3 +424,18 @@ SHMEM GEM Helper Reference
 
 .. kernel-doc:: drivers/gpu/drm/drm_gem_shmem_helper.c
    :export:
+
+Privacy-screen class
+====================
+
+.. kernel-doc:: drivers/gpu/drm/drm_privacy_screen.c
+   :doc: overview
+
+.. kernel-doc:: include/drm/drm_privacy_screen_driver.h
+   :internal:
+
+.. kernel-doc:: include/drm/drm_privacy_screen_machine.h
+   :internal:
+
+.. kernel-doc:: drivers/gpu/drm/drm_privacy_screen.c
+   :export:
diff --git a/MAINTAINERS b/MAINTAINERS
index f465eb96c303..9434f67e3c0b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5862,6 +5862,14 @@ F:	drivers/gpu/drm/drm_panel.c
 F:	drivers/gpu/drm/panel/
 F:	include/drm/drm_panel.h
 
+DRM PRIVACY-SCREEN CLASS
+M:	Hans de Goede <hdegoede@redhat.com>
+L:	dri-devel@lists.freedesktop.org
+S:	Maintained
+T:	git git://anongit.freedesktop.org/drm/drm-misc
+F:	drivers/gpu/drm/drm_privacy_screen*
+F:	include/drm/drm_privacy_screen*
+
 DRM TTM SUBSYSTEM
 M:	Christian Koenig <christian.koenig@amd.com>
 M:	Huang Rui <ray.huang@amd.com>
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index c4fd57d8b717..5dbfabad1050 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -475,3 +475,8 @@ config DRM_PANEL_ORIENTATION_QUIRKS
 config DRM_LIB_RANDOM
 	bool
 	default n
+
+# Separate option, used by drivers outside of drivers/gpu/drm
+config DRM_PRIVACY_SCREEN
+	tristate
+	default n
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 2c0e5a7e5953..621afac6e447 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -61,6 +61,7 @@ obj-$(CONFIG_DRM)	+= drm.o
 obj-$(CONFIG_DRM_MIPI_DBI) += drm_mipi_dbi.o
 obj-$(CONFIG_DRM_MIPI_DSI) += drm_mipi_dsi.o
 obj-$(CONFIG_DRM_PANEL_ORIENTATION_QUIRKS) += drm_panel_orientation_quirks.o
+obj-$(CONFIG_DRM_PRIVACY_SCREEN) += drm_privacy_screen.o
 obj-y			+= arm/
 obj-$(CONFIG_DRM_TTM)	+= ttm/
 obj-$(CONFIG_DRM_SCHED)	+= scheduler/
diff --git a/drivers/gpu/drm/drm_privacy_screen.c b/drivers/gpu/drm/drm_privacy_screen.c
new file mode 100644
index 000000000000..6296fd46156c
--- /dev/null
+++ b/drivers/gpu/drm/drm_privacy_screen.c
@@ -0,0 +1,426 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright (C) 2020 Red Hat, Inc.
+ *
+ * Authors:
+ * Hans de Goede <hdegoede@redhat.com>
+ */
+
+#include <linux/device.h>
+#include <linux/kernel.h>
+#include <linux/list.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/slab.h>
+#include <drm/drm_privacy_screen_machine.h>
+#include <drm/drm_privacy_screen_consumer.h>
+#include <drm/drm_privacy_screen_driver.h>
+
+/**
+ * DOC: overview
+ *
+ * This class allows non KMS drivers, from e.g. drivers/platform/x86 to
+ * register a privacy-screen device, which the KMS drivers can then use
+ * to implement the standard privacy-screen properties, see
+ * :ref:`Standard Connector Properties<standard_connector_properties>`.
+ *
+ * KMS drivers using a privacy-screen class device are advised to use the
+ * drm_connector_attach_privacy_screen_provider() and
+ * drm_connector_update_privacy_screen() helpers for dealing with this.
+ */
+
+#define to_drm_privacy_screen(dev) \
+	container_of(dev, struct drm_privacy_screen, dev)
+
+static DEFINE_MUTEX(drm_privacy_screen_lookup_lock);
+static LIST_HEAD(drm_privacy_screen_lookup_list);
+
+static DEFINE_MUTEX(drm_privacy_screen_devs_lock);
+static LIST_HEAD(drm_privacy_screen_devs);
+
+/*** drm_privacy_screen_machine.h functions ***/
+
+/**
+ * drm_privacy_screen_lookup_add - add an entry to the static privacy-screen
+ *    lookup list
+ * @lookup: lookup list entry to add
+ *
+ * Add an entry to the static privacy-screen lookup list. Note the
+ * &struct list_head which is part of the &struct drm_privacy_screen_lookup
+ * gets added to a list owned by the privacy-screen core. So the passed in
+ * &struct drm_privacy_screen_lookup must not be free-ed until it is removed
+ * from the lookup list by calling drm_privacy_screen_lookup_remove().
+ */
+void drm_privacy_screen_lookup_add(struct drm_privacy_screen_lookup *lookup)
+{
+	mutex_lock(&drm_privacy_screen_lookup_lock);
+	list_add(&lookup->list, &drm_privacy_screen_lookup_list);
+	mutex_unlock(&drm_privacy_screen_lookup_lock);
+}
+EXPORT_SYMBOL(drm_privacy_screen_lookup_add);
+
+/**
+ * drm_privacy_screen_lookup_remove - remove an entry to the static
+ *    privacy-screen lookup list
+ * @lookup: lookup list entry to remove
+ *
+ * Remove an entry previously added with drm_privacy_screen_lookup_add()
+ * from the static privacy-screen lookup list.
+ */
+void drm_privacy_screen_lookup_remove(struct drm_privacy_screen_lookup *lookup)
+{
+	mutex_lock(&drm_privacy_screen_lookup_lock);
+	list_del(&lookup->list);
+	mutex_unlock(&drm_privacy_screen_lookup_lock);
+}
+EXPORT_SYMBOL(drm_privacy_screen_lookup_remove);
+
+/*** drm_privacy_screen_consumer.h functions ***/
+
+static struct drm_privacy_screen *drm_privacy_screen_get_by_name(
+	const char *name)
+{
+	struct drm_privacy_screen *priv;
+	struct device *dev = NULL;
+
+	mutex_lock(&drm_privacy_screen_devs_lock);
+
+	list_for_each_entry(priv, &drm_privacy_screen_devs, list) {
+		if (strcmp(dev_name(&priv->dev), name) == 0) {
+			dev = get_device(&priv->dev);
+			break;
+		}
+	}
+
+	mutex_unlock(&drm_privacy_screen_devs_lock);
+
+	return dev ? to_drm_privacy_screen(dev) : NULL;
+}
+
+/**
+ * drm_privacy_screen_get - get a privacy-screen provider
+ * @dev: consumer-device for which to get a privacy-screen provider
+ * @con_id: (video)connector name for which to get a privacy-screen provider
+ *
+ * Get a privacy-screen provider for a privacy-screen attached to the
+ * display described by the @dev and @con_id parameters.
+ *
+ * Return:
+ * * A pointer to a &struct drm_privacy_screen on success.
+ * * ERR_PTR(-ENODEV) if no matching privacy-screen is found
+ * * ERR_PTR(-EPROBE_DEFER) if there is a matching privacy-screen,
+ *                          but it has not been registered yet.
+ */
+struct drm_privacy_screen *drm_privacy_screen_get(struct device *dev,
+						  const char *con_id)
+{
+	const char *dev_id = dev ? dev_name(dev) : NULL;
+	struct drm_privacy_screen_lookup *l;
+	struct drm_privacy_screen *priv;
+	const char *provider = NULL;
+	int match, best = -1;
+
+	/*
+	 * For now we only support using a static lookup table, which is
+	 * populated by the drm_privacy_screen_arch_init() call. This should
+	 * be extended with device-tree / fw_node lookup when support is added
+	 * for device-tree using hardware with a privacy-screen.
+	 *
+	 * The lookup algorithm was shamelessly taken from the clock
+	 * framework:
+	 *
+	 * We do slightly fuzzy matching here:
+	 *  An entry with a NULL ID is assumed to be a wildcard.
+	 *  If an entry has a device ID, it must match
+	 *  If an entry has a connection ID, it must match
+	 * Then we take the most specific entry - with the following order
+	 * of precedence: dev+con > dev only > con only.
+	 */
+	mutex_lock(&drm_privacy_screen_lookup_lock);
+
+	list_for_each_entry(l, &drm_privacy_screen_lookup_list, list) {
+		match = 0;
+
+		if (l->dev_id) {
+			if (!dev_id || strcmp(l->dev_id, dev_id))
+				continue;
+
+			match += 2;
+		}
+
+		if (l->con_id) {
+			if (!con_id || strcmp(l->con_id, con_id))
+				continue;
+
+			match += 1;
+		}
+
+		if (match > best) {
+			provider = l->provider;
+			best = match;
+		}
+	}
+
+	mutex_unlock(&drm_privacy_screen_lookup_lock);
+
+	if (!provider)
+		return ERR_PTR(-ENODEV);
+
+	priv = drm_privacy_screen_get_by_name(provider);
+	if (!priv)
+		return ERR_PTR(-EPROBE_DEFER);
+
+	return priv;
+}
+EXPORT_SYMBOL(drm_privacy_screen_get);
+
+/**
+ * drm_privacy_screen_put - release a privacy-screen reference
+ * @priv: privacy screen reference to release
+ *
+ * Release a privacy-screen provider reference gotten through
+ * drm_privacy_screen_get(). May be called with a NULL or ERR_PTR,
+ * in which case it is a no-op.
+ */
+void drm_privacy_screen_put(struct drm_privacy_screen *priv)
+{
+	if (IS_ERR_OR_NULL(priv))
+		return;
+
+	put_device(&priv->dev);
+}
+EXPORT_SYMBOL(drm_privacy_screen_put);
+
+/**
+ * drm_privacy_screen_set_sw_state - set a privacy-screen's sw-state
+ * @priv: privacy screen to set the sw-state for
+ * @sw_state: new sw-state value to set
+ *
+ * Set the sw-state of a privacy screen. If the privacy-screen is not
+ * in a locked hw-state, then the actual and hw-state of the privacy-screen
+ * will be immediately updated to the new value. If the privacy-screen is
+ * in a locked hw-state, then the new sw-state will be remembered as the
+ * requested state to put the privacy-screen in when it becomes unlocked.
+ *
+ * Return: 0 on success, negative error code on failure.
+ */
+int drm_privacy_screen_set_sw_state(struct drm_privacy_screen *priv,
+				    enum drm_privacy_screen_status sw_state)
+{
+	int ret = 0;
+
+	mutex_lock(&priv->lock);
+
+	if (!priv->ops) {
+		ret = -ENODEV;
+		goto out;
+	}
+
+	/*
+	 * As per the DRM connector properties documentation, setting the
+	 * sw_state while the hw_state is locked is allowed. In this case
+	 * it is a no-op other then storing the new sw_state so that it
+	 * can be honored when the state gets unlocked.
+	 */
+	if (priv->hw_state >= PRIVACY_SCREEN_DISABLED_LOCKED) {
+		priv->sw_state = sw_state;
+		goto out;
+	}
+
+	ret = priv->ops->set_sw_state(priv, sw_state);
+out:
+	mutex_unlock(&priv->lock);
+	return ret;
+}
+EXPORT_SYMBOL(drm_privacy_screen_set_sw_state);
+
+/**
+ * drm_privacy_screen_get_state - get privacy-screen's current state
+ * @priv: privacy screen to get the state for
+ * @sw_state_ret: address where to store the privacy-screens current sw-state
+ * @hw_state_ret: address where to store the privacy-screens current hw-state
+ *
+ * Get the current state of a privacy-screen, both the sw-state and the
+ * hw-state.
+ */
+void drm_privacy_screen_get_state(struct drm_privacy_screen *priv,
+				  enum drm_privacy_screen_status *sw_state_ret,
+				  enum drm_privacy_screen_status *hw_state_ret)
+{
+	mutex_lock(&priv->lock);
+	*sw_state_ret = priv->sw_state;
+	*hw_state_ret = priv->hw_state;
+	mutex_unlock(&priv->lock);
+}
+EXPORT_SYMBOL(drm_privacy_screen_get_state);
+
+/*** drm_privacy_screen_driver.h functions ***/
+
+static ssize_t sw_state_show(struct device *dev,
+			     struct device_attribute *attr, char *buf)
+{
+	struct drm_privacy_screen *priv = to_drm_privacy_screen(dev);
+	const char * const sw_state_names[] = {
+		"Disabled",
+		"Enabled",
+	};
+	ssize_t ret;
+
+	mutex_lock(&priv->lock);
+
+	if (!priv->ops)
+		ret = -ENODEV;
+	else if (WARN_ON(priv->sw_state >= ARRAY_SIZE(sw_state_names)))
+		ret = -ENXIO;
+	else
+		ret = sprintf(buf, "%s\n", sw_state_names[priv->sw_state]);
+
+	mutex_unlock(&priv->lock);
+	return ret;
+}
+/*
+ * RO: Do not allow setting the sw_state through sysfs, this MUST be done
+ * through the drm_properties on the drm_connector.
+ */
+static DEVICE_ATTR_RO(sw_state);
+
+static ssize_t hw_state_show(struct device *dev,
+			     struct device_attribute *attr, char *buf)
+{
+	struct drm_privacy_screen *priv = to_drm_privacy_screen(dev);
+	const char * const hw_state_names[] = {
+		"Disabled",
+		"Enabled",
+		"Disabled, locked",
+		"Enabled, locked",
+	};
+	ssize_t ret;
+
+	mutex_lock(&priv->lock);
+
+	if (!priv->ops)
+		ret = -ENODEV;
+	else if (WARN_ON(priv->hw_state >= ARRAY_SIZE(hw_state_names)))
+		ret = -ENXIO;
+	else
+		ret = sprintf(buf, "%s\n", hw_state_names[priv->hw_state]);
+
+	mutex_unlock(&priv->lock);
+	return ret;
+}
+static DEVICE_ATTR_RO(hw_state);
+
+static struct attribute *drm_privacy_screen_attrs[] = {
+	&dev_attr_sw_state.attr,
+	&dev_attr_hw_state.attr,
+	NULL
+};
+ATTRIBUTE_GROUPS(drm_privacy_screen);
+
+static struct class drm_privacy_screen_class = {
+	.name = "privacy_screen",
+	.owner = THIS_MODULE,
+	.dev_groups = drm_privacy_screen_groups,
+};
+
+static void drm_privacy_screen_device_release(struct device *dev)
+{
+	struct drm_privacy_screen *priv = to_drm_privacy_screen(dev);
+
+	kfree(priv);
+}
+
+/**
+ * drm_privacy_screen_register - register a privacy-screen
+ * @parent: parent-device for the privacy-screen
+ * @ops: &struct drm_privacy_screen_ops pointer with ops for the privacy-screen
+ *
+ * Create and register a privacy-screen.
+ *
+ * Return:
+ * * A pointer to the created privacy-screen on success.
+ * * An ERR_PTR(errno) on failure.
+ */
+struct drm_privacy_screen *drm_privacy_screen_register(
+	struct device *parent, const struct drm_privacy_screen_ops *ops)
+{
+	struct drm_privacy_screen *priv;
+	int ret;
+
+	priv = kzalloc(sizeof(*priv), GFP_KERNEL);
+	if (!priv)
+		return ERR_PTR(-ENOMEM);
+
+	mutex_init(&priv->lock);
+
+	priv->dev.class = &drm_privacy_screen_class;
+	priv->dev.parent = parent;
+	priv->dev.release = drm_privacy_screen_device_release;
+	dev_set_name(&priv->dev, "%s", dev_name(parent));
+	priv->ops = ops;
+
+	priv->ops->get_hw_state(priv);
+
+	ret = device_register(&priv->dev);
+	if (ret) {
+		put_device(&priv->dev);
+		return ERR_PTR(ret);
+	}
+
+	mutex_lock(&drm_privacy_screen_devs_lock);
+	list_add(&priv->list, &drm_privacy_screen_devs);
+	mutex_unlock(&drm_privacy_screen_devs_lock);
+
+	return priv;
+}
+EXPORT_SYMBOL(drm_privacy_screen_register);
+
+/**
+ * drm_privacy_screen_unregister - unregister privacy-screen
+ * @priv: privacy-screen to unregister
+ *
+ * Unregister a privacy-screen registered with drm_privacy_screen_register().
+ * May be called with a NULL or ERR_PTR, in which case it is a no-op.
+ */
+void drm_privacy_screen_unregister(struct drm_privacy_screen *priv)
+{
+	if (IS_ERR_OR_NULL(priv))
+		return;
+
+	mutex_lock(&drm_privacy_screen_devs_lock);
+	list_del(&priv->list);
+	mutex_unlock(&drm_privacy_screen_devs_lock);
+
+	mutex_lock(&priv->lock);
+	priv->ops = NULL;
+	mutex_unlock(&priv->lock);
+
+	device_unregister(&priv->dev);
+}
+EXPORT_SYMBOL(drm_privacy_screen_unregister);
+
+static int __init drm_privacy_screen_init(void)
+{
+	int ret;
+
+	ret = class_register(&drm_privacy_screen_class);
+	if (ret)
+		return ret;
+
+	drm_privacy_screen_arch_init();
+
+	return 0;
+}
+
+static void __exit drm_privacy_screen_exit(void)
+{
+	drm_privacy_screen_arch_exit();
+	class_unregister(&drm_privacy_screen_class);
+}
+
+subsys_initcall(drm_privacy_screen_init);
+module_exit(drm_privacy_screen_exit);
+
+MODULE_AUTHOR("Hans de Goede");
+MODULE_DESCRIPTION("DRM privacy-screen class");
+MODULE_LICENSE("GPL and additional rights");
diff --git a/include/drm/drm_privacy_screen_consumer.h b/include/drm/drm_privacy_screen_consumer.h
new file mode 100644
index 000000000000..169ba72bd60d
--- /dev/null
+++ b/include/drm/drm_privacy_screen_consumer.h
@@ -0,0 +1,27 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright (C) 2020 Red Hat, Inc.
+ *
+ * Authors:
+ * Hans de Goede <hdegoede@redhat.com>
+ */
+
+#ifndef __DRM_PRIVACY_SCREEN_CONSUMER_H__
+#define __DRM_PRIVACY_SCREEN_CONSUMER_H__
+
+#include <linux/device.h>
+#include <drm/drm_connector.h>
+
+struct drm_privacy_screen;
+
+struct drm_privacy_screen *drm_privacy_screen_get(struct device *dev,
+						  const char *con_id);
+void drm_privacy_screen_put(struct drm_privacy_screen *priv);
+
+int drm_privacy_screen_set_sw_state(struct drm_privacy_screen *priv,
+				    enum drm_privacy_screen_status sw_state);
+void drm_privacy_screen_get_state(struct drm_privacy_screen *priv,
+				  enum drm_privacy_screen_status *sw_state_ret,
+				  enum drm_privacy_screen_status *hw_state_ret);
+
+#endif
diff --git a/include/drm/drm_privacy_screen_driver.h b/include/drm/drm_privacy_screen_driver.h
new file mode 100644
index 000000000000..5187ae52eb03
--- /dev/null
+++ b/include/drm/drm_privacy_screen_driver.h
@@ -0,0 +1,80 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright (C) 2020 Red Hat, Inc.
+ *
+ * Authors:
+ * Hans de Goede <hdegoede@redhat.com>
+ */
+
+#ifndef __DRM_PRIVACY_SCREEN_DRIVER_H__
+#define __DRM_PRIVACY_SCREEN_DRIVER_H__
+
+#include <linux/device.h>
+#include <linux/list.h>
+#include <linux/mutex.h>
+#include <drm/drm_connector.h>
+
+struct drm_privacy_screen;
+
+/**
+ * struct drm_privacy_screen_ops - drm_privacy_screen operations
+ *
+ * Defines the operations which the privacy-screen class code may call.
+ * These functions should be implemented by the privacy-screen driver.
+ */
+struct drm_privacy_screen_ops {
+	/**
+	 * @set_sw_state: Called to request a change of the privacy-screen
+	 * state. The privacy-screen class code contains a check to avoid this
+	 * getting called when the hw_state reports the state is locked.
+	 * It is the driver's responsibility to update sw_state and hw_state.
+	 * This is always called with the drm_privacy_screen's lock held.
+	 */
+	int (*set_sw_state)(struct drm_privacy_screen *priv,
+			    enum drm_privacy_screen_status sw_state);
+	/**
+	 * @get_hw_state: Called to request that the driver gets the current
+	 * privacy-screen state from the hardware and then updates sw_state and
+	 * hw_state accordingly. This will be called by the core just before
+	 * the privacy-screen is registered in sysfs.
+	 */
+	void (*get_hw_state)(struct drm_privacy_screen *priv);
+};
+
+/**
+ * struct drm_privacy_screen - central privacy-screen structure
+ *
+ * Central privacy-screen structure, this contains the struct device used
+ * to register the screen in sysfs, the screen's state, ops, etc.
+ */
+struct drm_privacy_screen {
+	/** @dev: device used to register the privacy-screen in sysfs. */
+	struct device dev;
+	/** @lock: mutex protection all fields in this struct. */
+	struct mutex lock;
+	/** @list: privacy-screen devices list list-entry. */
+	struct list_head list;
+	/**
+	 * @ops: &struct drm_privacy_screen_ops for this privacy-screen.
+	 * This is NULL if the driver has unregistered the privacy-screen.
+	 */
+	const struct drm_privacy_screen_ops *ops;
+	/**
+	 * @sw_state: The privacy-screen's software state, see
+	 * :ref:`Standard Connector Properties<standard_connector_properties>`
+	 * for more info.
+	 */
+	enum drm_privacy_screen_status sw_state;
+	/**
+	 * @hw_state: The privacy-screen's hardware state, see
+	 * :ref:`Standard Connector Properties<standard_connector_properties>`
+	 * for more info.
+	 */
+	enum drm_privacy_screen_status hw_state;
+};
+
+struct drm_privacy_screen *drm_privacy_screen_register(
+	struct device *parent, const struct drm_privacy_screen_ops *ops);
+void drm_privacy_screen_unregister(struct drm_privacy_screen *priv);
+
+#endif
diff --git a/include/drm/drm_privacy_screen_machine.h b/include/drm/drm_privacy_screen_machine.h
new file mode 100644
index 000000000000..55f4b4fd8e4e
--- /dev/null
+++ b/include/drm/drm_privacy_screen_machine.h
@@ -0,0 +1,41 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright (C) 2020 Red Hat, Inc.
+ *
+ * Authors:
+ * Hans de Goede <hdegoede@redhat.com>
+ */
+
+#ifndef __DRM_PRIVACY_SCREEN_MACHINE_H__
+#define __DRM_PRIVACY_SCREEN_MACHINE_H__
+
+#include <linux/list.h>
+
+/**
+ * struct drm_privacy_screen_lookup -  static privacy-screen lookup list entry
+ *
+ * Used for the static lookup-list for mapping privacy-screen consumer
+ * dev-connector pairs to a privacy-screen provider.
+ */
+struct drm_privacy_screen_lookup {
+	/** @list: Lookup list list-entry. */
+	struct list_head list;
+	/** @dev_id: Consumer device name or NULL to match all devices. */
+	const char *dev_id;
+	/** @con_id: Consumer connector name or NULL to match all connectors. */
+	const char *con_id;
+	/** @provider: dev_name() of the privacy_screen provider. */
+	const char *provider;
+};
+
+void drm_privacy_screen_lookup_add(struct drm_privacy_screen_lookup *lookup);
+void drm_privacy_screen_lookup_remove(struct drm_privacy_screen_lookup *lookup);
+
+static inline void drm_privacy_screen_arch_init(void)
+{
+}
+static inline void drm_privacy_screen_arch_exit(void)
+{
+}
+
+#endif
-- 
2.26.2

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply related	[flat|nested] 44+ messages in thread

* [PATCH 4/9] drm/privacy-screen: Add X86 specific arch init code
  2020-07-08 16:43 ` [Intel-gfx] " Hans de Goede
@ 2020-07-08 16:43   ` Hans de Goede
  -1 siblings, 0 replies; 44+ messages in thread
From: Hans de Goede @ 2020-07-08 16:43 UTC (permalink / raw)
  To: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
	Daniel Vetter, David Airlie, Jani Nikula, Joonas Lahtinen,
	Rodrigo Vivi
  Cc: Hans de Goede, intel-gfx, dri-devel, Sebastien Bacher, Marco Trevisan

Add X86 specific arch init code, which fills the privacy-screen lookup
table by checking for various vendor specific ACPI interfaces for
controlling the privacy-screen.

This initial version only checks for the Lenovo Thinkpad specific ACPI
methods for privacy-screen control.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
 drivers/gpu/drm/Makefile                 |  5 +-
 drivers/gpu/drm/drm_privacy_screen_x86.c | 82 ++++++++++++++++++++++++
 include/drm/drm_privacy_screen_machine.h |  5 ++
 3 files changed, 91 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/drm_privacy_screen_x86.c

diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 621afac6e447..d05fdf11d746 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -57,11 +57,14 @@ drm_kms_helper-$(CONFIG_DRM_DP_CEC) += drm_dp_cec.o
 obj-$(CONFIG_DRM_KMS_HELPER) += drm_kms_helper.o
 obj-$(CONFIG_DRM_DEBUG_SELFTEST) += selftests/
 
+drm_privacy_screen_helper-y := drm_privacy_screen.o
+drm_privacy_screen_helper-$(CONFIG_X86) += drm_privacy_screen_x86.o
+obj-$(CONFIG_DRM_PRIVACY_SCREEN) += drm_privacy_screen_helper.o
+
 obj-$(CONFIG_DRM)	+= drm.o
 obj-$(CONFIG_DRM_MIPI_DBI) += drm_mipi_dbi.o
 obj-$(CONFIG_DRM_MIPI_DSI) += drm_mipi_dsi.o
 obj-$(CONFIG_DRM_PANEL_ORIENTATION_QUIRKS) += drm_panel_orientation_quirks.o
-obj-$(CONFIG_DRM_PRIVACY_SCREEN) += drm_privacy_screen.o
 obj-y			+= arm/
 obj-$(CONFIG_DRM_TTM)	+= ttm/
 obj-$(CONFIG_DRM_SCHED)	+= scheduler/
diff --git a/drivers/gpu/drm/drm_privacy_screen_x86.c b/drivers/gpu/drm/drm_privacy_screen_x86.c
new file mode 100644
index 000000000000..f486d9087819
--- /dev/null
+++ b/drivers/gpu/drm/drm_privacy_screen_x86.c
@@ -0,0 +1,82 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright (C) 2020 Red Hat, Inc.
+ *
+ * Authors:
+ * Hans de Goede <hdegoede@redhat.com>
+ */
+
+#include <linux/acpi.h>
+#include <drm/drm_privacy_screen_machine.h>
+
+static struct drm_privacy_screen_lookup arch_lookup;
+
+struct arch_init_data {
+	struct drm_privacy_screen_lookup lookup;
+	bool (*detect)(void);
+};
+
+static acpi_status __init acpi_set_handle(acpi_handle handle, u32 level,
+					  void *context, void **return_value)
+{
+	*(acpi_handle *)return_value = handle;
+	return AE_CTRL_TERMINATE;
+}
+
+static bool __init detect_thinkpad_privacy_screen(void)
+{
+	union acpi_object obj = { .type = ACPI_TYPE_INTEGER };
+	struct acpi_object_list args = { .count = 1, .pointer = &obj, };
+	acpi_handle ec_handle = NULL;
+	unsigned long long output;
+	acpi_status status;
+
+	/* Get embedded-controller handle */
+	status = acpi_get_devices("PNP0C09", acpi_set_handle, NULL, &ec_handle);
+	if (ACPI_FAILURE(status) || !ec_handle)
+		return false;
+
+	/* And call the privacy-screen get-status method */
+	status = acpi_evaluate_integer(ec_handle, "HKEY.GSSS", &args, &output);
+	if (ACPI_FAILURE(status))
+		return false;
+
+	return (output & 0x10000) ? true : false;
+}
+
+static const struct arch_init_data arch_init_data[] __initconst = {
+#if IS_ENABLED(CONFIG_THINKPAD_ACPI)
+	{
+		.lookup = {
+			.dev_id = NULL,
+			.con_id = NULL,
+			.provider = "thinkpad_acpi",
+		},
+		.detect = detect_thinkpad_privacy_screen,
+	},
+#endif
+};
+
+void __init drm_privacy_screen_arch_init(void)
+{
+	int i;
+
+	for (i = 0; i < ARRAY_SIZE(arch_init_data); i++) {
+		if (!arch_init_data[i].detect())
+			continue;
+
+		pr_info("Found '%s' privacy-screen provider\n",
+			arch_init_data[i].lookup.provider);
+
+		/* Make a copy because arch_init_data is __initconst */
+		arch_lookup = arch_init_data[i].lookup;
+		drm_privacy_screen_lookup_add(&arch_lookup);
+		break;
+	}
+}
+
+void __exit drm_privacy_screen_arch_exit(void)
+{
+	if (arch_lookup.provider)
+		drm_privacy_screen_lookup_remove(&arch_lookup);
+}
diff --git a/include/drm/drm_privacy_screen_machine.h b/include/drm/drm_privacy_screen_machine.h
index 55f4b4fd8e4e..0d2f2a443e8c 100644
--- a/include/drm/drm_privacy_screen_machine.h
+++ b/include/drm/drm_privacy_screen_machine.h
@@ -31,11 +31,16 @@ struct drm_privacy_screen_lookup {
 void drm_privacy_screen_lookup_add(struct drm_privacy_screen_lookup *lookup);
 void drm_privacy_screen_lookup_remove(struct drm_privacy_screen_lookup *lookup);
 
+#ifdef CONFIG_X86
+void drm_privacy_screen_arch_init(void);
+void drm_privacy_screen_arch_exit(void);
+#else
 static inline void drm_privacy_screen_arch_init(void)
 {
 }
 static inline void drm_privacy_screen_arch_exit(void)
 {
 }
+#endif
 
 #endif
-- 
2.26.2

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply related	[flat|nested] 44+ messages in thread

* [Intel-gfx] [PATCH 4/9] drm/privacy-screen: Add X86 specific arch init code
@ 2020-07-08 16:43   ` Hans de Goede
  0 siblings, 0 replies; 44+ messages in thread
From: Hans de Goede @ 2020-07-08 16:43 UTC (permalink / raw)
  To: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
	Daniel Vetter, David Airlie, Jani Nikula, Joonas Lahtinen,
	Rodrigo Vivi
  Cc: intel-gfx, dri-devel, Sebastien Bacher, Marco Trevisan

Add X86 specific arch init code, which fills the privacy-screen lookup
table by checking for various vendor specific ACPI interfaces for
controlling the privacy-screen.

This initial version only checks for the Lenovo Thinkpad specific ACPI
methods for privacy-screen control.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
 drivers/gpu/drm/Makefile                 |  5 +-
 drivers/gpu/drm/drm_privacy_screen_x86.c | 82 ++++++++++++++++++++++++
 include/drm/drm_privacy_screen_machine.h |  5 ++
 3 files changed, 91 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/drm_privacy_screen_x86.c

diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 621afac6e447..d05fdf11d746 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -57,11 +57,14 @@ drm_kms_helper-$(CONFIG_DRM_DP_CEC) += drm_dp_cec.o
 obj-$(CONFIG_DRM_KMS_HELPER) += drm_kms_helper.o
 obj-$(CONFIG_DRM_DEBUG_SELFTEST) += selftests/
 
+drm_privacy_screen_helper-y := drm_privacy_screen.o
+drm_privacy_screen_helper-$(CONFIG_X86) += drm_privacy_screen_x86.o
+obj-$(CONFIG_DRM_PRIVACY_SCREEN) += drm_privacy_screen_helper.o
+
 obj-$(CONFIG_DRM)	+= drm.o
 obj-$(CONFIG_DRM_MIPI_DBI) += drm_mipi_dbi.o
 obj-$(CONFIG_DRM_MIPI_DSI) += drm_mipi_dsi.o
 obj-$(CONFIG_DRM_PANEL_ORIENTATION_QUIRKS) += drm_panel_orientation_quirks.o
-obj-$(CONFIG_DRM_PRIVACY_SCREEN) += drm_privacy_screen.o
 obj-y			+= arm/
 obj-$(CONFIG_DRM_TTM)	+= ttm/
 obj-$(CONFIG_DRM_SCHED)	+= scheduler/
diff --git a/drivers/gpu/drm/drm_privacy_screen_x86.c b/drivers/gpu/drm/drm_privacy_screen_x86.c
new file mode 100644
index 000000000000..f486d9087819
--- /dev/null
+++ b/drivers/gpu/drm/drm_privacy_screen_x86.c
@@ -0,0 +1,82 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright (C) 2020 Red Hat, Inc.
+ *
+ * Authors:
+ * Hans de Goede <hdegoede@redhat.com>
+ */
+
+#include <linux/acpi.h>
+#include <drm/drm_privacy_screen_machine.h>
+
+static struct drm_privacy_screen_lookup arch_lookup;
+
+struct arch_init_data {
+	struct drm_privacy_screen_lookup lookup;
+	bool (*detect)(void);
+};
+
+static acpi_status __init acpi_set_handle(acpi_handle handle, u32 level,
+					  void *context, void **return_value)
+{
+	*(acpi_handle *)return_value = handle;
+	return AE_CTRL_TERMINATE;
+}
+
+static bool __init detect_thinkpad_privacy_screen(void)
+{
+	union acpi_object obj = { .type = ACPI_TYPE_INTEGER };
+	struct acpi_object_list args = { .count = 1, .pointer = &obj, };
+	acpi_handle ec_handle = NULL;
+	unsigned long long output;
+	acpi_status status;
+
+	/* Get embedded-controller handle */
+	status = acpi_get_devices("PNP0C09", acpi_set_handle, NULL, &ec_handle);
+	if (ACPI_FAILURE(status) || !ec_handle)
+		return false;
+
+	/* And call the privacy-screen get-status method */
+	status = acpi_evaluate_integer(ec_handle, "HKEY.GSSS", &args, &output);
+	if (ACPI_FAILURE(status))
+		return false;
+
+	return (output & 0x10000) ? true : false;
+}
+
+static const struct arch_init_data arch_init_data[] __initconst = {
+#if IS_ENABLED(CONFIG_THINKPAD_ACPI)
+	{
+		.lookup = {
+			.dev_id = NULL,
+			.con_id = NULL,
+			.provider = "thinkpad_acpi",
+		},
+		.detect = detect_thinkpad_privacy_screen,
+	},
+#endif
+};
+
+void __init drm_privacy_screen_arch_init(void)
+{
+	int i;
+
+	for (i = 0; i < ARRAY_SIZE(arch_init_data); i++) {
+		if (!arch_init_data[i].detect())
+			continue;
+
+		pr_info("Found '%s' privacy-screen provider\n",
+			arch_init_data[i].lookup.provider);
+
+		/* Make a copy because arch_init_data is __initconst */
+		arch_lookup = arch_init_data[i].lookup;
+		drm_privacy_screen_lookup_add(&arch_lookup);
+		break;
+	}
+}
+
+void __exit drm_privacy_screen_arch_exit(void)
+{
+	if (arch_lookup.provider)
+		drm_privacy_screen_lookup_remove(&arch_lookup);
+}
diff --git a/include/drm/drm_privacy_screen_machine.h b/include/drm/drm_privacy_screen_machine.h
index 55f4b4fd8e4e..0d2f2a443e8c 100644
--- a/include/drm/drm_privacy_screen_machine.h
+++ b/include/drm/drm_privacy_screen_machine.h
@@ -31,11 +31,16 @@ struct drm_privacy_screen_lookup {
 void drm_privacy_screen_lookup_add(struct drm_privacy_screen_lookup *lookup);
 void drm_privacy_screen_lookup_remove(struct drm_privacy_screen_lookup *lookup);
 
+#ifdef CONFIG_X86
+void drm_privacy_screen_arch_init(void);
+void drm_privacy_screen_arch_exit(void);
+#else
 static inline void drm_privacy_screen_arch_init(void)
 {
 }
 static inline void drm_privacy_screen_arch_exit(void)
 {
 }
+#endif
 
 #endif
-- 
2.26.2

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply related	[flat|nested] 44+ messages in thread

* [PATCH 5/9] drm/privacy-screen: Add notifier support
  2020-07-08 16:43 ` [Intel-gfx] " Hans de Goede
@ 2020-07-08 16:43   ` Hans de Goede
  -1 siblings, 0 replies; 44+ messages in thread
From: Hans de Goede @ 2020-07-08 16:43 UTC (permalink / raw)
  To: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
	Daniel Vetter, David Airlie, Jani Nikula, Joonas Lahtinen,
	Rodrigo Vivi
  Cc: Hans de Goede, intel-gfx, dri-devel, Sebastien Bacher, Marco Trevisan

Add support for privacy-screen consumers to register a notifier to
be notified of external (e.g. done by the hw itself on a hotkey press)
state changes.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
 drivers/gpu/drm/drm_privacy_screen.c      | 67 +++++++++++++++++++++++
 include/drm/drm_privacy_screen_consumer.h |  5 ++
 include/drm/drm_privacy_screen_driver.h   |  4 ++
 3 files changed, 76 insertions(+)

diff --git a/drivers/gpu/drm/drm_privacy_screen.c b/drivers/gpu/drm/drm_privacy_screen.c
index 6296fd46156c..7e78b4068e8f 100644
--- a/drivers/gpu/drm/drm_privacy_screen.c
+++ b/drivers/gpu/drm/drm_privacy_screen.c
@@ -254,6 +254,49 @@ void drm_privacy_screen_get_state(struct drm_privacy_screen *priv,
 }
 EXPORT_SYMBOL(drm_privacy_screen_get_state);
 
+/**
+ * drm_privacy_screen_register_notifier - register a notifier
+ * @priv: Privacy screen to register the notifier with
+ * @nb: Notifier-block for the notifier to register
+ *
+ * Register a notifier with the privacy-screen to be notified of changes made
+ * to the privacy-screen state from outside of the privacy-screen class.
+ * E.g. the state may be changed by the hardware itself in response to a
+ * hotkey press.
+ *
+ * The notifier is called with no locks held. The new hw_state and sw_state
+ * can be retrieved using the drm_privacy_screen_get_state() function.
+ * A pointer to the drm_privacy_screen's struct is passed as the void *data
+ * argument of the notifier_block's notifier_call.
+ *
+ * The notifier will NOT be called when changes are made through
+ * drm_privacy_screen_set_sw_state(). It is only called for external changes.
+ *
+ * Return: 0 on success, negative error code on failure.
+ */
+int drm_privacy_screen_register_notifier(struct drm_privacy_screen *priv,
+					 struct notifier_block *nb)
+{
+	return blocking_notifier_chain_register(&priv->notifier_head, nb);
+}
+EXPORT_SYMBOL(drm_privacy_screen_register_notifier);
+
+/**
+ * drm_privacy_screen_unregister_notifier - unregister a notifier
+ * @priv: Privacy screen to register the notifier with
+ * @nb: Notifier-block for the notifier to register
+ *
+ * Unregister a notifier registered with drm_privacy_screen_register_notifier().
+ *
+ * Return: 0 on success, negative error code on failure.
+ */
+int drm_privacy_screen_unregister_notifier(struct drm_privacy_screen *priv,
+					   struct notifier_block *nb)
+{
+	return blocking_notifier_chain_unregister(&priv->notifier_head, nb);
+}
+EXPORT_SYMBOL(drm_privacy_screen_unregister_notifier);
+
 /*** drm_privacy_screen_driver.h functions ***/
 
 static ssize_t sw_state_show(struct device *dev,
@@ -352,6 +395,7 @@ struct drm_privacy_screen *drm_privacy_screen_register(
 		return ERR_PTR(-ENOMEM);
 
 	mutex_init(&priv->lock);
+	BLOCKING_INIT_NOTIFIER_HEAD(&priv->notifier_head);
 
 	priv->dev.class = &drm_privacy_screen_class;
 	priv->dev.parent = parent;
@@ -399,6 +443,29 @@ void drm_privacy_screen_unregister(struct drm_privacy_screen *priv)
 }
 EXPORT_SYMBOL(drm_privacy_screen_unregister);
 
+/**
+ * drm_privacy_screen_call_notifier_chain - notify consumers of state change
+ * @priv: Privacy screen to register the notifier with
+ *
+ * A privacy-screen provider driver can call this functions upon external
+ * changes to the privacy-screen state. E.g. the state may be changed by the
+ * hardware itself in response to a hotkey press.
+ * This function must be called without holding the privacy-screen lock.
+ * the driver must update sw_state and hw_state to reflect the new state before
+ * calling this function.
+ * The expected behavior from the driver upon receiving an external state
+ * change event is: 1. Take the lock; 2. Update sw_state and hw_state;
+ * 3. Release the lock. 4. Call drm_privacy_screen_call_notifier_chain().
+ */
+void drm_privacy_screen_call_notifier_chain(struct drm_privacy_screen *priv)
+{
+	if (WARN_ON(mutex_is_locked(&priv->lock)))
+		return;
+
+	blocking_notifier_call_chain(&priv->notifier_head, 0, priv);
+}
+EXPORT_SYMBOL(drm_privacy_screen_call_notifier_chain);
+
 static int __init drm_privacy_screen_init(void)
 {
 	int ret;
diff --git a/include/drm/drm_privacy_screen_consumer.h b/include/drm/drm_privacy_screen_consumer.h
index 169ba72bd60d..1f33dc1457ff 100644
--- a/include/drm/drm_privacy_screen_consumer.h
+++ b/include/drm/drm_privacy_screen_consumer.h
@@ -24,4 +24,9 @@ void drm_privacy_screen_get_state(struct drm_privacy_screen *priv,
 				  enum drm_privacy_screen_status *sw_state_ret,
 				  enum drm_privacy_screen_status *hw_state_ret);
 
+int drm_privacy_screen_register_notifier(struct drm_privacy_screen *priv,
+					 struct notifier_block *nb);
+int drm_privacy_screen_unregister_notifier(struct drm_privacy_screen *priv,
+					   struct notifier_block *nb);
+
 #endif
diff --git a/include/drm/drm_privacy_screen_driver.h b/include/drm/drm_privacy_screen_driver.h
index 5187ae52eb03..24591b607675 100644
--- a/include/drm/drm_privacy_screen_driver.h
+++ b/include/drm/drm_privacy_screen_driver.h
@@ -54,6 +54,8 @@ struct drm_privacy_screen {
 	struct mutex lock;
 	/** @list: privacy-screen devices list list-entry. */
 	struct list_head list;
+	/** @notifier_head: privacy-screen notifier head. */
+	struct blocking_notifier_head notifier_head;
 	/**
 	 * @ops: &struct drm_privacy_screen_ops for this privacy-screen.
 	 * This is NULL if the driver has unregistered the privacy-screen.
@@ -77,4 +79,6 @@ struct drm_privacy_screen *drm_privacy_screen_register(
 	struct device *parent, const struct drm_privacy_screen_ops *ops);
 void drm_privacy_screen_unregister(struct drm_privacy_screen *priv);
 
+void drm_privacy_screen_call_notifier_chain(struct drm_privacy_screen *priv);
+
 #endif
-- 
2.26.2

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply related	[flat|nested] 44+ messages in thread

* [Intel-gfx] [PATCH 5/9] drm/privacy-screen: Add notifier support
@ 2020-07-08 16:43   ` Hans de Goede
  0 siblings, 0 replies; 44+ messages in thread
From: Hans de Goede @ 2020-07-08 16:43 UTC (permalink / raw)
  To: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
	Daniel Vetter, David Airlie, Jani Nikula, Joonas Lahtinen,
	Rodrigo Vivi
  Cc: intel-gfx, dri-devel, Sebastien Bacher, Marco Trevisan

Add support for privacy-screen consumers to register a notifier to
be notified of external (e.g. done by the hw itself on a hotkey press)
state changes.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
 drivers/gpu/drm/drm_privacy_screen.c      | 67 +++++++++++++++++++++++
 include/drm/drm_privacy_screen_consumer.h |  5 ++
 include/drm/drm_privacy_screen_driver.h   |  4 ++
 3 files changed, 76 insertions(+)

diff --git a/drivers/gpu/drm/drm_privacy_screen.c b/drivers/gpu/drm/drm_privacy_screen.c
index 6296fd46156c..7e78b4068e8f 100644
--- a/drivers/gpu/drm/drm_privacy_screen.c
+++ b/drivers/gpu/drm/drm_privacy_screen.c
@@ -254,6 +254,49 @@ void drm_privacy_screen_get_state(struct drm_privacy_screen *priv,
 }
 EXPORT_SYMBOL(drm_privacy_screen_get_state);
 
+/**
+ * drm_privacy_screen_register_notifier - register a notifier
+ * @priv: Privacy screen to register the notifier with
+ * @nb: Notifier-block for the notifier to register
+ *
+ * Register a notifier with the privacy-screen to be notified of changes made
+ * to the privacy-screen state from outside of the privacy-screen class.
+ * E.g. the state may be changed by the hardware itself in response to a
+ * hotkey press.
+ *
+ * The notifier is called with no locks held. The new hw_state and sw_state
+ * can be retrieved using the drm_privacy_screen_get_state() function.
+ * A pointer to the drm_privacy_screen's struct is passed as the void *data
+ * argument of the notifier_block's notifier_call.
+ *
+ * The notifier will NOT be called when changes are made through
+ * drm_privacy_screen_set_sw_state(). It is only called for external changes.
+ *
+ * Return: 0 on success, negative error code on failure.
+ */
+int drm_privacy_screen_register_notifier(struct drm_privacy_screen *priv,
+					 struct notifier_block *nb)
+{
+	return blocking_notifier_chain_register(&priv->notifier_head, nb);
+}
+EXPORT_SYMBOL(drm_privacy_screen_register_notifier);
+
+/**
+ * drm_privacy_screen_unregister_notifier - unregister a notifier
+ * @priv: Privacy screen to register the notifier with
+ * @nb: Notifier-block for the notifier to register
+ *
+ * Unregister a notifier registered with drm_privacy_screen_register_notifier().
+ *
+ * Return: 0 on success, negative error code on failure.
+ */
+int drm_privacy_screen_unregister_notifier(struct drm_privacy_screen *priv,
+					   struct notifier_block *nb)
+{
+	return blocking_notifier_chain_unregister(&priv->notifier_head, nb);
+}
+EXPORT_SYMBOL(drm_privacy_screen_unregister_notifier);
+
 /*** drm_privacy_screen_driver.h functions ***/
 
 static ssize_t sw_state_show(struct device *dev,
@@ -352,6 +395,7 @@ struct drm_privacy_screen *drm_privacy_screen_register(
 		return ERR_PTR(-ENOMEM);
 
 	mutex_init(&priv->lock);
+	BLOCKING_INIT_NOTIFIER_HEAD(&priv->notifier_head);
 
 	priv->dev.class = &drm_privacy_screen_class;
 	priv->dev.parent = parent;
@@ -399,6 +443,29 @@ void drm_privacy_screen_unregister(struct drm_privacy_screen *priv)
 }
 EXPORT_SYMBOL(drm_privacy_screen_unregister);
 
+/**
+ * drm_privacy_screen_call_notifier_chain - notify consumers of state change
+ * @priv: Privacy screen to register the notifier with
+ *
+ * A privacy-screen provider driver can call this functions upon external
+ * changes to the privacy-screen state. E.g. the state may be changed by the
+ * hardware itself in response to a hotkey press.
+ * This function must be called without holding the privacy-screen lock.
+ * the driver must update sw_state and hw_state to reflect the new state before
+ * calling this function.
+ * The expected behavior from the driver upon receiving an external state
+ * change event is: 1. Take the lock; 2. Update sw_state and hw_state;
+ * 3. Release the lock. 4. Call drm_privacy_screen_call_notifier_chain().
+ */
+void drm_privacy_screen_call_notifier_chain(struct drm_privacy_screen *priv)
+{
+	if (WARN_ON(mutex_is_locked(&priv->lock)))
+		return;
+
+	blocking_notifier_call_chain(&priv->notifier_head, 0, priv);
+}
+EXPORT_SYMBOL(drm_privacy_screen_call_notifier_chain);
+
 static int __init drm_privacy_screen_init(void)
 {
 	int ret;
diff --git a/include/drm/drm_privacy_screen_consumer.h b/include/drm/drm_privacy_screen_consumer.h
index 169ba72bd60d..1f33dc1457ff 100644
--- a/include/drm/drm_privacy_screen_consumer.h
+++ b/include/drm/drm_privacy_screen_consumer.h
@@ -24,4 +24,9 @@ void drm_privacy_screen_get_state(struct drm_privacy_screen *priv,
 				  enum drm_privacy_screen_status *sw_state_ret,
 				  enum drm_privacy_screen_status *hw_state_ret);
 
+int drm_privacy_screen_register_notifier(struct drm_privacy_screen *priv,
+					 struct notifier_block *nb);
+int drm_privacy_screen_unregister_notifier(struct drm_privacy_screen *priv,
+					   struct notifier_block *nb);
+
 #endif
diff --git a/include/drm/drm_privacy_screen_driver.h b/include/drm/drm_privacy_screen_driver.h
index 5187ae52eb03..24591b607675 100644
--- a/include/drm/drm_privacy_screen_driver.h
+++ b/include/drm/drm_privacy_screen_driver.h
@@ -54,6 +54,8 @@ struct drm_privacy_screen {
 	struct mutex lock;
 	/** @list: privacy-screen devices list list-entry. */
 	struct list_head list;
+	/** @notifier_head: privacy-screen notifier head. */
+	struct blocking_notifier_head notifier_head;
 	/**
 	 * @ops: &struct drm_privacy_screen_ops for this privacy-screen.
 	 * This is NULL if the driver has unregistered the privacy-screen.
@@ -77,4 +79,6 @@ struct drm_privacy_screen *drm_privacy_screen_register(
 	struct device *parent, const struct drm_privacy_screen_ops *ops);
 void drm_privacy_screen_unregister(struct drm_privacy_screen *priv);
 
+void drm_privacy_screen_call_notifier_chain(struct drm_privacy_screen *priv);
+
 #endif
-- 
2.26.2

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply related	[flat|nested] 44+ messages in thread

* [PATCH 6/9] drm/connector: Add a drm_connector privacy-screen helper functions
  2020-07-08 16:43 ` [Intel-gfx] " Hans de Goede
@ 2020-07-08 16:43   ` Hans de Goede
  -1 siblings, 0 replies; 44+ messages in thread
From: Hans de Goede @ 2020-07-08 16:43 UTC (permalink / raw)
  To: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
	Daniel Vetter, David Airlie, Jani Nikula, Joonas Lahtinen,
	Rodrigo Vivi
  Cc: Hans de Goede, intel-gfx, dri-devel, Sebastien Bacher, Marco Trevisan

Add 2 drm_connector privacy-screen helper functions:

1. drm_connector_attach_privacy_screen_provider(), this function creates
and attaches the standard privacy-screen properties and registers a
generic notifier for generating sysfs-connector-status-events on external
changes to the privacy-screen status.

2. drm_connector_update_privacy_screen(), Check if the passed in atomic
state contains a privacy-screen sw_state change for the connector and if
it does, call drm_privacy_screen_set_sw_state() with the new sw_state.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
 drivers/gpu/drm/drm_connector.c | 113 ++++++++++++++++++++++++++++++++
 include/drm/drm_connector.h     |  12 ++++
 2 files changed, 125 insertions(+)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index bce5e0cc5884..37e985756890 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -20,6 +20,7 @@
  * OF THIS SOFTWARE.
  */
 
+#include <drm/drm_atomic.h>
 #include <drm/drm_connector.h>
 #include <drm/drm_edid.h>
 #include <drm/drm_encoder.h>
@@ -27,6 +28,7 @@
 #include <drm/drm_print.h>
 #include <drm/drm_drv.h>
 #include <drm/drm_file.h>
+#include <drm/drm_privacy_screen_consumer.h>
 #include <drm/drm_sysfs.h>
 
 #include <linux/uaccess.h>
@@ -449,6 +451,11 @@ void drm_connector_cleanup(struct drm_connector *connector)
 		    DRM_CONNECTOR_REGISTERED))
 		drm_connector_unregister(connector);
 
+	if (connector->privacy_screen) {
+		drm_privacy_screen_put(connector->privacy_screen);
+		connector->privacy_screen = NULL;
+	}
+
 	if (connector->tile_group) {
 		drm_mode_put_tile_group(dev, connector->tile_group);
 		connector->tile_group = NULL;
@@ -528,6 +535,10 @@ int drm_connector_register(struct drm_connector *connector)
 	/* Let userspace know we have a new connector */
 	drm_sysfs_hotplug_event(connector->dev);
 
+	if (connector->privacy_screen)
+		drm_privacy_screen_register_notifier(connector->privacy_screen,
+					   &connector->privacy_screen_notifier);
+
 	goto unlock;
 
 err_debugfs:
@@ -556,6 +567,11 @@ void drm_connector_unregister(struct drm_connector *connector)
 		return;
 	}
 
+	if (connector->privacy_screen)
+		drm_privacy_screen_unregister_notifier(
+					connector->privacy_screen,
+					&connector->privacy_screen_notifier);
+
 	if (connector->funcs->early_unregister)
 		connector->funcs->early_unregister(connector);
 
@@ -2260,6 +2276,103 @@ drm_connector_attach_privacy_screen_properties(struct drm_connector *connector)
 }
 EXPORT_SYMBOL(drm_connector_attach_privacy_screen_properties);
 
+static void drm_connector_update_privacy_screen_properties(
+	struct drm_connector *connector)
+{
+	enum drm_privacy_screen_status sw_state, hw_state;
+
+	drm_privacy_screen_get_state(connector->privacy_screen,
+				     &sw_state, &hw_state);
+
+	connector->state->privacy_screen_sw_state = sw_state;
+	drm_object_property_set_value(&connector->base,
+			connector->privacy_screen_hw_state_property, hw_state);
+}
+
+static int drm_connector_privacy_screen_notifier(
+	struct notifier_block *nb, unsigned long action, void *data)
+{
+	struct drm_connector *connector =
+		container_of(nb, struct drm_connector, privacy_screen_notifier);
+	struct drm_device *dev = connector->dev;
+
+	drm_modeset_lock(&dev->mode_config.connection_mutex, NULL);
+	drm_connector_update_privacy_screen_properties(connector);
+	drm_modeset_unlock(&dev->mode_config.connection_mutex);
+
+	drm_sysfs_connector_status_event(connector,
+				connector->privacy_screen_sw_state_property);
+	drm_sysfs_connector_status_event(connector,
+				connector->privacy_screen_hw_state_property);
+
+	return NOTIFY_DONE;
+}
+
+/**
+ * drm_connector_attach_privacy_screen_provider - attach a privacy-screen to
+ *    the connector
+ * @connector: connector to attach the privacy-screen to
+ * @priv: drm_privacy_screen to attach
+ *
+ * Create and attach the standard privacy-screen properties and register
+ * a generic notifier for generating sysfs-connector-status-events
+ * on external changes to the privacy-screen status.
+ * This function takes ownership of the passed in drm_privacy_screen and will
+ * call drm_privacy_screen_put() on it when the connector is destroyed.
+ */
+void drm_connector_attach_privacy_screen_provider(
+	struct drm_connector *connector, struct drm_privacy_screen *priv)
+{
+	connector->privacy_screen = priv;
+	connector->privacy_screen_notifier.notifier_call =
+		drm_connector_privacy_screen_notifier;
+
+	drm_connector_create_privacy_screen_properties(connector);
+	drm_connector_update_privacy_screen_properties(connector);
+	drm_connector_attach_privacy_screen_properties(connector);
+}
+EXPORT_SYMBOL(drm_connector_attach_privacy_screen_provider);
+
+/**
+ * drm_connector_update_privacy_screen - update connector's privacy-screen
+ *    state (if changed)
+ * @connector: connector to update the privacy-screen for
+ * @state: drm_atomic state describing the state change
+ *
+ * This function checks if the passed in connector has a privacy-screen
+ * attached and if it does, it checks if the
+ * drm_connector_state.privacy_screen_sw_state setting has changed.
+ * If both conditions are true it calls drm_privacy_screen_set_sw_state() on
+ * the connector's privacy-screen to update the privacy-screen's state.
+ */
+void drm_connector_update_privacy_screen(struct drm_connector *connector,
+					 struct drm_atomic_state *state)
+{
+	struct drm_connector_state *new_connector_state, *old_connector_state;
+	int ret;
+
+	if (!connector->privacy_screen)
+		return;
+
+	new_connector_state = drm_atomic_get_new_connector_state(state, connector);
+	old_connector_state = drm_atomic_get_old_connector_state(state, connector);
+
+	if (new_connector_state->privacy_screen_sw_state ==
+	    old_connector_state->privacy_screen_sw_state)
+		return;
+
+	ret = drm_privacy_screen_set_sw_state(connector->privacy_screen,
+				new_connector_state->privacy_screen_sw_state);
+	if (ret) {
+		drm_err(connector->dev, "Error updating privacy-screen sw_state\n");
+		return;
+	}
+
+	/* The hw_state property value may have changed, update the props. */
+	drm_connector_update_privacy_screen_properties(connector);
+}
+EXPORT_SYMBOL(drm_connector_update_privacy_screen);
+
 int drm_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 9c77865e4093..d7f4b8434df1 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -27,6 +27,7 @@
 #include <linux/llist.h>
 #include <linux/ctype.h>
 #include <linux/hdmi.h>
+#include <linux/notifier.h>
 #include <drm/drm_mode_object.h>
 #include <drm/drm_util.h>
 
@@ -40,6 +41,7 @@ struct drm_encoder;
 struct drm_property;
 struct drm_property_blob;
 struct drm_printer;
+struct drm_privacy_screen;
 struct edid;
 struct i2c_adapter;
 
@@ -1315,6 +1317,12 @@ struct drm_connector {
 	 */
 	struct drm_property *max_bpc_property;
 
+	/** @privacy_screen: drm_privacy_screen for this connector, or NULL. */
+	struct drm_privacy_screen *privacy_screen;
+
+	/** @privacy_screen_notifier: privacy-screen notifier_block */
+	struct notifier_block privacy_screen_notifier;
+
 	/**
 	 * @privacy_screen_sw_state_property: Optional atomic property for the
 	 * connector to control the integrated privacy screen.
@@ -1642,6 +1650,10 @@ int drm_connector_attach_max_bpc_property(struct drm_connector *connector,
 					  int min, int max);
 void drm_connector_create_privacy_screen_properties(struct drm_connector *conn);
 void drm_connector_attach_privacy_screen_properties(struct drm_connector *conn);
+void drm_connector_attach_privacy_screen_provider(
+	struct drm_connector *connector, struct drm_privacy_screen *priv);
+void drm_connector_update_privacy_screen(struct drm_connector *connector,
+					 struct drm_atomic_state *state);
 
 /**
  * struct drm_tile_group - Tile group metadata
-- 
2.26.2

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply related	[flat|nested] 44+ messages in thread

* [Intel-gfx] [PATCH 6/9] drm/connector: Add a drm_connector privacy-screen helper functions
@ 2020-07-08 16:43   ` Hans de Goede
  0 siblings, 0 replies; 44+ messages in thread
From: Hans de Goede @ 2020-07-08 16:43 UTC (permalink / raw)
  To: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
	Daniel Vetter, David Airlie, Jani Nikula, Joonas Lahtinen,
	Rodrigo Vivi
  Cc: intel-gfx, dri-devel, Sebastien Bacher, Marco Trevisan

Add 2 drm_connector privacy-screen helper functions:

1. drm_connector_attach_privacy_screen_provider(), this function creates
and attaches the standard privacy-screen properties and registers a
generic notifier for generating sysfs-connector-status-events on external
changes to the privacy-screen status.

2. drm_connector_update_privacy_screen(), Check if the passed in atomic
state contains a privacy-screen sw_state change for the connector and if
it does, call drm_privacy_screen_set_sw_state() with the new sw_state.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
 drivers/gpu/drm/drm_connector.c | 113 ++++++++++++++++++++++++++++++++
 include/drm/drm_connector.h     |  12 ++++
 2 files changed, 125 insertions(+)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index bce5e0cc5884..37e985756890 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -20,6 +20,7 @@
  * OF THIS SOFTWARE.
  */
 
+#include <drm/drm_atomic.h>
 #include <drm/drm_connector.h>
 #include <drm/drm_edid.h>
 #include <drm/drm_encoder.h>
@@ -27,6 +28,7 @@
 #include <drm/drm_print.h>
 #include <drm/drm_drv.h>
 #include <drm/drm_file.h>
+#include <drm/drm_privacy_screen_consumer.h>
 #include <drm/drm_sysfs.h>
 
 #include <linux/uaccess.h>
@@ -449,6 +451,11 @@ void drm_connector_cleanup(struct drm_connector *connector)
 		    DRM_CONNECTOR_REGISTERED))
 		drm_connector_unregister(connector);
 
+	if (connector->privacy_screen) {
+		drm_privacy_screen_put(connector->privacy_screen);
+		connector->privacy_screen = NULL;
+	}
+
 	if (connector->tile_group) {
 		drm_mode_put_tile_group(dev, connector->tile_group);
 		connector->tile_group = NULL;
@@ -528,6 +535,10 @@ int drm_connector_register(struct drm_connector *connector)
 	/* Let userspace know we have a new connector */
 	drm_sysfs_hotplug_event(connector->dev);
 
+	if (connector->privacy_screen)
+		drm_privacy_screen_register_notifier(connector->privacy_screen,
+					   &connector->privacy_screen_notifier);
+
 	goto unlock;
 
 err_debugfs:
@@ -556,6 +567,11 @@ void drm_connector_unregister(struct drm_connector *connector)
 		return;
 	}
 
+	if (connector->privacy_screen)
+		drm_privacy_screen_unregister_notifier(
+					connector->privacy_screen,
+					&connector->privacy_screen_notifier);
+
 	if (connector->funcs->early_unregister)
 		connector->funcs->early_unregister(connector);
 
@@ -2260,6 +2276,103 @@ drm_connector_attach_privacy_screen_properties(struct drm_connector *connector)
 }
 EXPORT_SYMBOL(drm_connector_attach_privacy_screen_properties);
 
+static void drm_connector_update_privacy_screen_properties(
+	struct drm_connector *connector)
+{
+	enum drm_privacy_screen_status sw_state, hw_state;
+
+	drm_privacy_screen_get_state(connector->privacy_screen,
+				     &sw_state, &hw_state);
+
+	connector->state->privacy_screen_sw_state = sw_state;
+	drm_object_property_set_value(&connector->base,
+			connector->privacy_screen_hw_state_property, hw_state);
+}
+
+static int drm_connector_privacy_screen_notifier(
+	struct notifier_block *nb, unsigned long action, void *data)
+{
+	struct drm_connector *connector =
+		container_of(nb, struct drm_connector, privacy_screen_notifier);
+	struct drm_device *dev = connector->dev;
+
+	drm_modeset_lock(&dev->mode_config.connection_mutex, NULL);
+	drm_connector_update_privacy_screen_properties(connector);
+	drm_modeset_unlock(&dev->mode_config.connection_mutex);
+
+	drm_sysfs_connector_status_event(connector,
+				connector->privacy_screen_sw_state_property);
+	drm_sysfs_connector_status_event(connector,
+				connector->privacy_screen_hw_state_property);
+
+	return NOTIFY_DONE;
+}
+
+/**
+ * drm_connector_attach_privacy_screen_provider - attach a privacy-screen to
+ *    the connector
+ * @connector: connector to attach the privacy-screen to
+ * @priv: drm_privacy_screen to attach
+ *
+ * Create and attach the standard privacy-screen properties and register
+ * a generic notifier for generating sysfs-connector-status-events
+ * on external changes to the privacy-screen status.
+ * This function takes ownership of the passed in drm_privacy_screen and will
+ * call drm_privacy_screen_put() on it when the connector is destroyed.
+ */
+void drm_connector_attach_privacy_screen_provider(
+	struct drm_connector *connector, struct drm_privacy_screen *priv)
+{
+	connector->privacy_screen = priv;
+	connector->privacy_screen_notifier.notifier_call =
+		drm_connector_privacy_screen_notifier;
+
+	drm_connector_create_privacy_screen_properties(connector);
+	drm_connector_update_privacy_screen_properties(connector);
+	drm_connector_attach_privacy_screen_properties(connector);
+}
+EXPORT_SYMBOL(drm_connector_attach_privacy_screen_provider);
+
+/**
+ * drm_connector_update_privacy_screen - update connector's privacy-screen
+ *    state (if changed)
+ * @connector: connector to update the privacy-screen for
+ * @state: drm_atomic state describing the state change
+ *
+ * This function checks if the passed in connector has a privacy-screen
+ * attached and if it does, it checks if the
+ * drm_connector_state.privacy_screen_sw_state setting has changed.
+ * If both conditions are true it calls drm_privacy_screen_set_sw_state() on
+ * the connector's privacy-screen to update the privacy-screen's state.
+ */
+void drm_connector_update_privacy_screen(struct drm_connector *connector,
+					 struct drm_atomic_state *state)
+{
+	struct drm_connector_state *new_connector_state, *old_connector_state;
+	int ret;
+
+	if (!connector->privacy_screen)
+		return;
+
+	new_connector_state = drm_atomic_get_new_connector_state(state, connector);
+	old_connector_state = drm_atomic_get_old_connector_state(state, connector);
+
+	if (new_connector_state->privacy_screen_sw_state ==
+	    old_connector_state->privacy_screen_sw_state)
+		return;
+
+	ret = drm_privacy_screen_set_sw_state(connector->privacy_screen,
+				new_connector_state->privacy_screen_sw_state);
+	if (ret) {
+		drm_err(connector->dev, "Error updating privacy-screen sw_state\n");
+		return;
+	}
+
+	/* The hw_state property value may have changed, update the props. */
+	drm_connector_update_privacy_screen_properties(connector);
+}
+EXPORT_SYMBOL(drm_connector_update_privacy_screen);
+
 int drm_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 9c77865e4093..d7f4b8434df1 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -27,6 +27,7 @@
 #include <linux/llist.h>
 #include <linux/ctype.h>
 #include <linux/hdmi.h>
+#include <linux/notifier.h>
 #include <drm/drm_mode_object.h>
 #include <drm/drm_util.h>
 
@@ -40,6 +41,7 @@ struct drm_encoder;
 struct drm_property;
 struct drm_property_blob;
 struct drm_printer;
+struct drm_privacy_screen;
 struct edid;
 struct i2c_adapter;
 
@@ -1315,6 +1317,12 @@ struct drm_connector {
 	 */
 	struct drm_property *max_bpc_property;
 
+	/** @privacy_screen: drm_privacy_screen for this connector, or NULL. */
+	struct drm_privacy_screen *privacy_screen;
+
+	/** @privacy_screen_notifier: privacy-screen notifier_block */
+	struct notifier_block privacy_screen_notifier;
+
 	/**
 	 * @privacy_screen_sw_state_property: Optional atomic property for the
 	 * connector to control the integrated privacy screen.
@@ -1642,6 +1650,10 @@ int drm_connector_attach_max_bpc_property(struct drm_connector *connector,
 					  int min, int max);
 void drm_connector_create_privacy_screen_properties(struct drm_connector *conn);
 void drm_connector_attach_privacy_screen_properties(struct drm_connector *conn);
+void drm_connector_attach_privacy_screen_provider(
+	struct drm_connector *connector, struct drm_privacy_screen *priv);
+void drm_connector_update_privacy_screen(struct drm_connector *connector,
+					 struct drm_atomic_state *state);
 
 /**
  * struct drm_tile_group - Tile group metadata
-- 
2.26.2

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply related	[flat|nested] 44+ messages in thread

* [PATCH 7/9] platform/x86: thinkpad_acpi: Get privacy-screen / lcdshadow ACPI handles only once
  2020-07-08 16:43 ` [Intel-gfx] " Hans de Goede
@ 2020-07-08 16:43   ` Hans de Goede
  -1 siblings, 0 replies; 44+ messages in thread
From: Hans de Goede @ 2020-07-08 16:43 UTC (permalink / raw)
  To: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
	Daniel Vetter, David Airlie, Jani Nikula, Joonas Lahtinen,
	Rodrigo Vivi
  Cc: Hans de Goede, intel-gfx, dri-devel, Sebastien Bacher, Marco Trevisan

Get the privacy-screen / lcdshadow ACPI handles once and cache them,
instead of retrieving them every time we need them.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
 drivers/platform/x86/thinkpad_acpi.c | 18 ++++++++----------
 1 file changed, 8 insertions(+), 10 deletions(-)

diff --git a/drivers/platform/x86/thinkpad_acpi.c b/drivers/platform/x86/thinkpad_acpi.c
index ff7f0a4f2475..782e74d3167f 100644
--- a/drivers/platform/x86/thinkpad_acpi.c
+++ b/drivers/platform/x86/thinkpad_acpi.c
@@ -9699,19 +9699,15 @@ static struct ibm_struct battery_driver_data = {
  * LCD Shadow subdriver, for the Lenovo PrivacyGuard feature
  */
 
+static acpi_handle lcdshadow_get_handle;
+static acpi_handle lcdshadow_set_handle;
 static int lcdshadow_state;
 
 static int lcdshadow_on_off(bool state)
 {
-	acpi_handle set_shadow_handle;
 	int output;
 
-	if (ACPI_FAILURE(acpi_get_handle(hkey_handle, "SSSS", &set_shadow_handle))) {
-		pr_warn("Thinkpad ACPI has no %s interface.\n", "SSSS");
-		return -EIO;
-	}
-
-	if (!acpi_evalf(set_shadow_handle, &output, NULL, "dd", (int)state))
+	if (!acpi_evalf(lcdshadow_set_handle, &output, NULL, "dd", (int)state))
 		return -EIO;
 
 	lcdshadow_state = state;
@@ -9729,15 +9725,17 @@ static int lcdshadow_set(bool on)
 
 static int tpacpi_lcdshadow_init(struct ibm_init_struct *iibm)
 {
-	acpi_handle get_shadow_handle;
+	acpi_status status1, status2;
 	int output;
 
-	if (ACPI_FAILURE(acpi_get_handle(hkey_handle, "GSSS", &get_shadow_handle))) {
+	status1 = acpi_get_handle(hkey_handle, "GSSS", &lcdshadow_get_handle);
+	status2 = acpi_get_handle(hkey_handle, "SSSS", &lcdshadow_set_handle);
+	if (ACPI_FAILURE(status1) || ACPI_FAILURE(status2)) {
 		lcdshadow_state = -ENODEV;
 		return 0;
 	}
 
-	if (!acpi_evalf(get_shadow_handle, &output, NULL, "dd", 0)) {
+	if (!acpi_evalf(lcdshadow_get_handle, &output, NULL, "dd", 0)) {
 		lcdshadow_state = -EIO;
 		return -EIO;
 	}
-- 
2.26.2

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply related	[flat|nested] 44+ messages in thread

* [Intel-gfx] [PATCH 7/9] platform/x86: thinkpad_acpi: Get privacy-screen / lcdshadow ACPI handles only once
@ 2020-07-08 16:43   ` Hans de Goede
  0 siblings, 0 replies; 44+ messages in thread
From: Hans de Goede @ 2020-07-08 16:43 UTC (permalink / raw)
  To: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
	Daniel Vetter, David Airlie, Jani Nikula, Joonas Lahtinen,
	Rodrigo Vivi
  Cc: intel-gfx, dri-devel, Sebastien Bacher, Marco Trevisan

Get the privacy-screen / lcdshadow ACPI handles once and cache them,
instead of retrieving them every time we need them.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
 drivers/platform/x86/thinkpad_acpi.c | 18 ++++++++----------
 1 file changed, 8 insertions(+), 10 deletions(-)

diff --git a/drivers/platform/x86/thinkpad_acpi.c b/drivers/platform/x86/thinkpad_acpi.c
index ff7f0a4f2475..782e74d3167f 100644
--- a/drivers/platform/x86/thinkpad_acpi.c
+++ b/drivers/platform/x86/thinkpad_acpi.c
@@ -9699,19 +9699,15 @@ static struct ibm_struct battery_driver_data = {
  * LCD Shadow subdriver, for the Lenovo PrivacyGuard feature
  */
 
+static acpi_handle lcdshadow_get_handle;
+static acpi_handle lcdshadow_set_handle;
 static int lcdshadow_state;
 
 static int lcdshadow_on_off(bool state)
 {
-	acpi_handle set_shadow_handle;
 	int output;
 
-	if (ACPI_FAILURE(acpi_get_handle(hkey_handle, "SSSS", &set_shadow_handle))) {
-		pr_warn("Thinkpad ACPI has no %s interface.\n", "SSSS");
-		return -EIO;
-	}
-
-	if (!acpi_evalf(set_shadow_handle, &output, NULL, "dd", (int)state))
+	if (!acpi_evalf(lcdshadow_set_handle, &output, NULL, "dd", (int)state))
 		return -EIO;
 
 	lcdshadow_state = state;
@@ -9729,15 +9725,17 @@ static int lcdshadow_set(bool on)
 
 static int tpacpi_lcdshadow_init(struct ibm_init_struct *iibm)
 {
-	acpi_handle get_shadow_handle;
+	acpi_status status1, status2;
 	int output;
 
-	if (ACPI_FAILURE(acpi_get_handle(hkey_handle, "GSSS", &get_shadow_handle))) {
+	status1 = acpi_get_handle(hkey_handle, "GSSS", &lcdshadow_get_handle);
+	status2 = acpi_get_handle(hkey_handle, "SSSS", &lcdshadow_set_handle);
+	if (ACPI_FAILURE(status1) || ACPI_FAILURE(status2)) {
 		lcdshadow_state = -ENODEV;
 		return 0;
 	}
 
-	if (!acpi_evalf(get_shadow_handle, &output, NULL, "dd", 0)) {
+	if (!acpi_evalf(lcdshadow_get_handle, &output, NULL, "dd", 0)) {
 		lcdshadow_state = -EIO;
 		return -EIO;
 	}
-- 
2.26.2

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply related	[flat|nested] 44+ messages in thread

* [PATCH 8/9] platform/x86: thinkpad_acpi: Register a privacy-screen device
  2020-07-08 16:43 ` [Intel-gfx] " Hans de Goede
@ 2020-07-08 16:43   ` Hans de Goede
  -1 siblings, 0 replies; 44+ messages in thread
From: Hans de Goede @ 2020-07-08 16:43 UTC (permalink / raw)
  To: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
	Daniel Vetter, David Airlie, Jani Nikula, Joonas Lahtinen,
	Rodrigo Vivi
  Cc: Hans de Goede, intel-gfx, dri-devel, Sebastien Bacher, Marco Trevisan

Register a privacy-screen device on laptops with a privacy-screen,
this exports the PrivacyGuard features to user-space using a
standardized vendor-agnostic sysfs interface. Note the sysfs interface
is read-only.

Registering a privacy-screen device with the new privacy-screen class
code will also allow the GPU driver to get a handle to it and export
the privacy-screen setting as a property on the DRM connector object
for the LCD panel. This DRM connector property is news standardized
interface which all user-space code should use to query and control
the privacy-screen.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
 drivers/platform/x86/Kconfig         |  1 +
 drivers/platform/x86/thinkpad_acpi.c | 76 +++++++++++++++++++---------
 2 files changed, 52 insertions(+), 25 deletions(-)

diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index 318e083f38b3..db427ab86292 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -617,6 +617,7 @@ config THINKPAD_ACPI
 	depends on RFKILL || RFKILL = n
 	depends on ACPI_VIDEO || ACPI_VIDEO = n
 	depends on BACKLIGHT_CLASS_DEVICE
+	select DRM_PRIVACY_SCREEN
 	select HWMON
 	select NVRAM
 	select NEW_LEDS
diff --git a/drivers/platform/x86/thinkpad_acpi.c b/drivers/platform/x86/thinkpad_acpi.c
index 782e74d3167f..7e7edac26f83 100644
--- a/drivers/platform/x86/thinkpad_acpi.c
+++ b/drivers/platform/x86/thinkpad_acpi.c
@@ -72,6 +72,7 @@
 #include <linux/uaccess.h>
 #include <acpi/battery.h>
 #include <acpi/video.h>
+#include <drm/drm_privacy_screen_driver.h>
 
 /* ThinkPad CMOS commands */
 #define TP_CMOS_VOLUME_DOWN	0
@@ -9699,30 +9700,40 @@ static struct ibm_struct battery_driver_data = {
  * LCD Shadow subdriver, for the Lenovo PrivacyGuard feature
  */
 
+static struct drm_privacy_screen *lcdshadow_dev;
 static acpi_handle lcdshadow_get_handle;
 static acpi_handle lcdshadow_set_handle;
-static int lcdshadow_state;
 
-static int lcdshadow_on_off(bool state)
+int lcdshadow_set_sw_state(struct drm_privacy_screen *priv,
+			   enum drm_privacy_screen_status state)
 {
 	int output;
 
+	if (WARN_ON(!mutex_is_locked(&priv->lock)))
+		return -EIO;
+
 	if (!acpi_evalf(lcdshadow_set_handle, &output, NULL, "dd", (int)state))
 		return -EIO;
 
-	lcdshadow_state = state;
+	priv->hw_state = priv->sw_state = state;
 	return 0;
 }
 
-static int lcdshadow_set(bool on)
+void lcdshadow_get_hw_state(struct drm_privacy_screen *priv)
 {
-	if (lcdshadow_state < 0)
-		return lcdshadow_state;
-	if (lcdshadow_state == on)
-		return 0;
-	return lcdshadow_on_off(on);
+	int output;
+
+	if (!acpi_evalf(lcdshadow_get_handle, &output, NULL, "dd", 0))
+		return;
+
+	priv->hw_state = priv->sw_state = output & 0x1;
 }
 
+const struct drm_privacy_screen_ops lcdshadow_ops = {
+	.set_sw_state = lcdshadow_set_sw_state,
+	.get_hw_state = lcdshadow_get_hw_state,
+};
+
 static int tpacpi_lcdshadow_init(struct ibm_init_struct *iibm)
 {
 	acpi_status status1, status2;
@@ -9730,36 +9741,44 @@ static int tpacpi_lcdshadow_init(struct ibm_init_struct *iibm)
 
 	status1 = acpi_get_handle(hkey_handle, "GSSS", &lcdshadow_get_handle);
 	status2 = acpi_get_handle(hkey_handle, "SSSS", &lcdshadow_set_handle);
-	if (ACPI_FAILURE(status1) || ACPI_FAILURE(status2)) {
-		lcdshadow_state = -ENODEV;
+	if (ACPI_FAILURE(status1) || ACPI_FAILURE(status2))
 		return 0;
-	}
 
-	if (!acpi_evalf(lcdshadow_get_handle, &output, NULL, "dd", 0)) {
-		lcdshadow_state = -EIO;
+	if (!acpi_evalf(lcdshadow_get_handle, &output, NULL, "dd", 0))
 		return -EIO;
-	}
-	if (!(output & 0x10000)) {
-		lcdshadow_state = -ENODEV;
+
+	if (!(output & 0x10000))
 		return 0;
-	}
-	lcdshadow_state = output & 0x1;
+
+	lcdshadow_dev = drm_privacy_screen_register(&tpacpi_pdev->dev,
+						    &lcdshadow_ops);
+	if (IS_ERR(lcdshadow_dev))
+		return PTR_ERR(lcdshadow_dev);
 
 	return 0;
 }
 
+static void lcdshadow_exit(void)
+{
+	drm_privacy_screen_unregister(lcdshadow_dev);
+}
+
 static void lcdshadow_resume(void)
 {
-	if (lcdshadow_state >= 0)
-		lcdshadow_on_off(lcdshadow_state);
+	if (!lcdshadow_dev)
+		return;
+
+	mutex_lock(&lcdshadow_dev->lock);
+	lcdshadow_set_sw_state(lcdshadow_dev, lcdshadow_dev->sw_state);
+	mutex_unlock(&lcdshadow_dev->lock);
 }
 
 static int lcdshadow_read(struct seq_file *m)
 {
-	if (lcdshadow_state < 0) {
+	if (!lcdshadow_dev) {
 		seq_puts(m, "status:\t\tnot supported\n");
 	} else {
-		seq_printf(m, "status:\t\t%d\n", lcdshadow_state);
+		seq_printf(m, "status:\t\t%d\n", lcdshadow_dev->hw_state);
 		seq_puts(m, "commands:\t0, 1\n");
 	}
 
@@ -9771,7 +9790,7 @@ static int lcdshadow_write(char *buf)
 	char *cmd;
 	int res, state = -EINVAL;
 
-	if (lcdshadow_state < 0)
+	if (!lcdshadow_dev)
 		return -ENODEV;
 
 	while ((cmd = strsep(&buf, ","))) {
@@ -9783,11 +9802,18 @@ static int lcdshadow_write(char *buf)
 	if (state >= 2 || state < 0)
 		return -EINVAL;
 
-	return lcdshadow_set(state);
+	mutex_lock(&lcdshadow_dev->lock);
+	res = lcdshadow_set_sw_state(lcdshadow_dev, state);
+	mutex_unlock(&lcdshadow_dev->lock);
+
+	drm_privacy_screen_call_notifier_chain(lcdshadow_dev);
+
+	return res;
 }
 
 static struct ibm_struct lcdshadow_driver_data = {
 	.name = "lcdshadow",
+	.exit = lcdshadow_exit,
 	.resume = lcdshadow_resume,
 	.read = lcdshadow_read,
 	.write = lcdshadow_write,
-- 
2.26.2

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply related	[flat|nested] 44+ messages in thread

* [Intel-gfx] [PATCH 8/9] platform/x86: thinkpad_acpi: Register a privacy-screen device
@ 2020-07-08 16:43   ` Hans de Goede
  0 siblings, 0 replies; 44+ messages in thread
From: Hans de Goede @ 2020-07-08 16:43 UTC (permalink / raw)
  To: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
	Daniel Vetter, David Airlie, Jani Nikula, Joonas Lahtinen,
	Rodrigo Vivi
  Cc: intel-gfx, dri-devel, Sebastien Bacher, Marco Trevisan

Register a privacy-screen device on laptops with a privacy-screen,
this exports the PrivacyGuard features to user-space using a
standardized vendor-agnostic sysfs interface. Note the sysfs interface
is read-only.

Registering a privacy-screen device with the new privacy-screen class
code will also allow the GPU driver to get a handle to it and export
the privacy-screen setting as a property on the DRM connector object
for the LCD panel. This DRM connector property is news standardized
interface which all user-space code should use to query and control
the privacy-screen.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
 drivers/platform/x86/Kconfig         |  1 +
 drivers/platform/x86/thinkpad_acpi.c | 76 +++++++++++++++++++---------
 2 files changed, 52 insertions(+), 25 deletions(-)

diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index 318e083f38b3..db427ab86292 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -617,6 +617,7 @@ config THINKPAD_ACPI
 	depends on RFKILL || RFKILL = n
 	depends on ACPI_VIDEO || ACPI_VIDEO = n
 	depends on BACKLIGHT_CLASS_DEVICE
+	select DRM_PRIVACY_SCREEN
 	select HWMON
 	select NVRAM
 	select NEW_LEDS
diff --git a/drivers/platform/x86/thinkpad_acpi.c b/drivers/platform/x86/thinkpad_acpi.c
index 782e74d3167f..7e7edac26f83 100644
--- a/drivers/platform/x86/thinkpad_acpi.c
+++ b/drivers/platform/x86/thinkpad_acpi.c
@@ -72,6 +72,7 @@
 #include <linux/uaccess.h>
 #include <acpi/battery.h>
 #include <acpi/video.h>
+#include <drm/drm_privacy_screen_driver.h>
 
 /* ThinkPad CMOS commands */
 #define TP_CMOS_VOLUME_DOWN	0
@@ -9699,30 +9700,40 @@ static struct ibm_struct battery_driver_data = {
  * LCD Shadow subdriver, for the Lenovo PrivacyGuard feature
  */
 
+static struct drm_privacy_screen *lcdshadow_dev;
 static acpi_handle lcdshadow_get_handle;
 static acpi_handle lcdshadow_set_handle;
-static int lcdshadow_state;
 
-static int lcdshadow_on_off(bool state)
+int lcdshadow_set_sw_state(struct drm_privacy_screen *priv,
+			   enum drm_privacy_screen_status state)
 {
 	int output;
 
+	if (WARN_ON(!mutex_is_locked(&priv->lock)))
+		return -EIO;
+
 	if (!acpi_evalf(lcdshadow_set_handle, &output, NULL, "dd", (int)state))
 		return -EIO;
 
-	lcdshadow_state = state;
+	priv->hw_state = priv->sw_state = state;
 	return 0;
 }
 
-static int lcdshadow_set(bool on)
+void lcdshadow_get_hw_state(struct drm_privacy_screen *priv)
 {
-	if (lcdshadow_state < 0)
-		return lcdshadow_state;
-	if (lcdshadow_state == on)
-		return 0;
-	return lcdshadow_on_off(on);
+	int output;
+
+	if (!acpi_evalf(lcdshadow_get_handle, &output, NULL, "dd", 0))
+		return;
+
+	priv->hw_state = priv->sw_state = output & 0x1;
 }
 
+const struct drm_privacy_screen_ops lcdshadow_ops = {
+	.set_sw_state = lcdshadow_set_sw_state,
+	.get_hw_state = lcdshadow_get_hw_state,
+};
+
 static int tpacpi_lcdshadow_init(struct ibm_init_struct *iibm)
 {
 	acpi_status status1, status2;
@@ -9730,36 +9741,44 @@ static int tpacpi_lcdshadow_init(struct ibm_init_struct *iibm)
 
 	status1 = acpi_get_handle(hkey_handle, "GSSS", &lcdshadow_get_handle);
 	status2 = acpi_get_handle(hkey_handle, "SSSS", &lcdshadow_set_handle);
-	if (ACPI_FAILURE(status1) || ACPI_FAILURE(status2)) {
-		lcdshadow_state = -ENODEV;
+	if (ACPI_FAILURE(status1) || ACPI_FAILURE(status2))
 		return 0;
-	}
 
-	if (!acpi_evalf(lcdshadow_get_handle, &output, NULL, "dd", 0)) {
-		lcdshadow_state = -EIO;
+	if (!acpi_evalf(lcdshadow_get_handle, &output, NULL, "dd", 0))
 		return -EIO;
-	}
-	if (!(output & 0x10000)) {
-		lcdshadow_state = -ENODEV;
+
+	if (!(output & 0x10000))
 		return 0;
-	}
-	lcdshadow_state = output & 0x1;
+
+	lcdshadow_dev = drm_privacy_screen_register(&tpacpi_pdev->dev,
+						    &lcdshadow_ops);
+	if (IS_ERR(lcdshadow_dev))
+		return PTR_ERR(lcdshadow_dev);
 
 	return 0;
 }
 
+static void lcdshadow_exit(void)
+{
+	drm_privacy_screen_unregister(lcdshadow_dev);
+}
+
 static void lcdshadow_resume(void)
 {
-	if (lcdshadow_state >= 0)
-		lcdshadow_on_off(lcdshadow_state);
+	if (!lcdshadow_dev)
+		return;
+
+	mutex_lock(&lcdshadow_dev->lock);
+	lcdshadow_set_sw_state(lcdshadow_dev, lcdshadow_dev->sw_state);
+	mutex_unlock(&lcdshadow_dev->lock);
 }
 
 static int lcdshadow_read(struct seq_file *m)
 {
-	if (lcdshadow_state < 0) {
+	if (!lcdshadow_dev) {
 		seq_puts(m, "status:\t\tnot supported\n");
 	} else {
-		seq_printf(m, "status:\t\t%d\n", lcdshadow_state);
+		seq_printf(m, "status:\t\t%d\n", lcdshadow_dev->hw_state);
 		seq_puts(m, "commands:\t0, 1\n");
 	}
 
@@ -9771,7 +9790,7 @@ static int lcdshadow_write(char *buf)
 	char *cmd;
 	int res, state = -EINVAL;
 
-	if (lcdshadow_state < 0)
+	if (!lcdshadow_dev)
 		return -ENODEV;
 
 	while ((cmd = strsep(&buf, ","))) {
@@ -9783,11 +9802,18 @@ static int lcdshadow_write(char *buf)
 	if (state >= 2 || state < 0)
 		return -EINVAL;
 
-	return lcdshadow_set(state);
+	mutex_lock(&lcdshadow_dev->lock);
+	res = lcdshadow_set_sw_state(lcdshadow_dev, state);
+	mutex_unlock(&lcdshadow_dev->lock);
+
+	drm_privacy_screen_call_notifier_chain(lcdshadow_dev);
+
+	return res;
 }
 
 static struct ibm_struct lcdshadow_driver_data = {
 	.name = "lcdshadow",
+	.exit = lcdshadow_exit,
 	.resume = lcdshadow_resume,
 	.read = lcdshadow_read,
 	.write = lcdshadow_write,
-- 
2.26.2

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply related	[flat|nested] 44+ messages in thread

* [PATCH 9/9] drm/i915: Add privacy-screen support
  2020-07-08 16:43 ` [Intel-gfx] " Hans de Goede
@ 2020-07-08 16:43   ` Hans de Goede
  -1 siblings, 0 replies; 44+ messages in thread
From: Hans de Goede @ 2020-07-08 16:43 UTC (permalink / raw)
  To: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
	Daniel Vetter, David Airlie, Jani Nikula, Joonas Lahtinen,
	Rodrigo Vivi
  Cc: Hans de Goede, intel-gfx, dri-devel, Sebastien Bacher, Marco Trevisan

Add support for eDP panels with a built-in privacy screen using the
new drm_privacy_screen class.

One thing which stands out here is the addition of these 2 lines to
intel_atomic_commit_tail:

	for_each_new_connector_in_state(&state->base, connector, ...
		drm_connector_update_privacy_screen(connector, state);

It may seem more logical to instead take care of updating the
privacy-screen state by marking the crtc as needing a modeset and then
do this in both the encoder update_pipe (for fast-sets) and enable
(for full modesets) callbacks. But ATM these callbacks only get passed
the new connector_state and these callbacks are all called after
drm_atomic_helper_swap_state() at which point there is no way to get
the old state from the new state.

Without access to the old state, we do not know if the sw_state of
the privacy-screen has changes so we would need to call
drm_privacy_screen_set_sw_state() unconditionally. This is undesirable
since all current known privacy-screen providers use ACPI calls which
are somewhat expensive to make.

Also, as all providers use ACPI calls, rather then poking GPU registers,
there is no need to order this together with other encoder operations.
Since no GPU poking is involved having this as a separate step of the
commit process actually is the logical thing to do.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
 drivers/gpu/drm/i915/display/intel_display.c |  5 +++++
 drivers/gpu/drm/i915/display/intel_dp.c      | 10 ++++++++++
 drivers/gpu/drm/i915/i915_pci.c              | 12 ++++++++++++
 3 files changed, 27 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c
index 9ea1a397d1b5..9e2b57e77118 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -15412,6 +15412,8 @@ static void intel_atomic_commit_tail(struct intel_atomic_state *state)
 	struct drm_device *dev = state->base.dev;
 	struct drm_i915_private *dev_priv = to_i915(dev);
 	struct intel_crtc_state *new_crtc_state, *old_crtc_state;
+	struct drm_connector_state *new_connector_state;
+	struct drm_connector *connector;
 	struct intel_crtc *crtc;
 	u64 put_domains[I915_MAX_PIPES] = {};
 	intel_wakeref_t wakeref = 0;
@@ -15501,6 +15503,9 @@ static void intel_atomic_commit_tail(struct intel_atomic_state *state)
 			intel_color_load_luts(new_crtc_state);
 	}
 
+	for_each_new_connector_in_state(&state->base, connector, new_connector_state, i)
+		drm_connector_update_privacy_screen(connector, &state->base);
+
 	/*
 	 * Now that the vblank has passed, we can go ahead and program the
 	 * optimal watermarks on platforms that need two-step watermark
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c
index ed9e53c373a7..6d4e0a5e054b 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -39,6 +39,7 @@
 #include <drm/drm_dp_helper.h>
 #include <drm/drm_edid.h>
 #include <drm/drm_hdcp.h>
+#include <drm/drm_privacy_screen_consumer.h>
 #include <drm/drm_probe_helper.h>
 
 #include "i915_debugfs.h"
@@ -8032,6 +8033,7 @@ static bool intel_edp_init_connector(struct intel_dp *intel_dp,
 	struct drm_connector *connector = &intel_connector->base;
 	struct drm_display_mode *fixed_mode = NULL;
 	struct drm_display_mode *downclock_mode = NULL;
+	struct drm_privacy_screen *privacy_screen;
 	bool has_dpcd;
 	enum pipe pipe = INVALID_PIPE;
 	intel_wakeref_t wakeref;
@@ -8129,6 +8131,14 @@ static bool intel_edp_init_connector(struct intel_dp *intel_dp,
 				fixed_mode->hdisplay, fixed_mode->vdisplay);
 	}
 
+	privacy_screen = drm_privacy_screen_get(&dev->pdev->dev, NULL);
+	if (!IS_ERR(privacy_screen)) {
+		drm_connector_attach_privacy_screen_provider(connector,
+							     privacy_screen);
+	} else if (PTR_ERR(privacy_screen) != -ENODEV) {
+		drm_warn(&dev_priv->drm, "Error getting privacy-screen\n");
+	}
+
 	return true;
 
 out_vdd_off:
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index eb0b5be7c35d..3604babc2ee7 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -26,6 +26,7 @@
 #include <linux/vga_switcheroo.h>
 
 #include <drm/drm_drv.h>
+#include <drm/drm_privacy_screen_consumer.h>
 #include <drm/i915_pciids.h>
 
 #include "display/intel_fbdev.h"
@@ -992,6 +993,7 @@ static int i915_pci_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
 {
 	struct intel_device_info *intel_info =
 		(struct intel_device_info *) ent->driver_data;
+	struct drm_privacy_screen *privacy_screen;
 	int err;
 
 	if (intel_info->require_force_probe &&
@@ -1020,7 +1022,17 @@ static int i915_pci_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
 	if (vga_switcheroo_client_probe_defer(pdev))
 		return -EPROBE_DEFER;
 
+	/*
+	 * We do not handle -EPROBE_DEFER further into the probe process, so
+	 * check if we have a laptop-panel privacy-screen for which the driver
+	 * has not loaded yet here.
+	 */
+	privacy_screen = drm_privacy_screen_get(&pdev->dev, NULL);
+	if (IS_ERR(privacy_screen) && PTR_ERR(privacy_screen) == -EPROBE_DEFER)
+		return -EPROBE_DEFER;
+
 	err = i915_driver_probe(pdev, ent);
+	drm_privacy_screen_put(privacy_screen);
 	if (err)
 		return err;
 
-- 
2.26.2

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply related	[flat|nested] 44+ messages in thread

* [Intel-gfx] [PATCH 9/9] drm/i915: Add privacy-screen support
@ 2020-07-08 16:43   ` Hans de Goede
  0 siblings, 0 replies; 44+ messages in thread
From: Hans de Goede @ 2020-07-08 16:43 UTC (permalink / raw)
  To: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
	Daniel Vetter, David Airlie, Jani Nikula, Joonas Lahtinen,
	Rodrigo Vivi
  Cc: intel-gfx, dri-devel, Sebastien Bacher, Marco Trevisan

Add support for eDP panels with a built-in privacy screen using the
new drm_privacy_screen class.

One thing which stands out here is the addition of these 2 lines to
intel_atomic_commit_tail:

	for_each_new_connector_in_state(&state->base, connector, ...
		drm_connector_update_privacy_screen(connector, state);

It may seem more logical to instead take care of updating the
privacy-screen state by marking the crtc as needing a modeset and then
do this in both the encoder update_pipe (for fast-sets) and enable
(for full modesets) callbacks. But ATM these callbacks only get passed
the new connector_state and these callbacks are all called after
drm_atomic_helper_swap_state() at which point there is no way to get
the old state from the new state.

Without access to the old state, we do not know if the sw_state of
the privacy-screen has changes so we would need to call
drm_privacy_screen_set_sw_state() unconditionally. This is undesirable
since all current known privacy-screen providers use ACPI calls which
are somewhat expensive to make.

Also, as all providers use ACPI calls, rather then poking GPU registers,
there is no need to order this together with other encoder operations.
Since no GPU poking is involved having this as a separate step of the
commit process actually is the logical thing to do.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
 drivers/gpu/drm/i915/display/intel_display.c |  5 +++++
 drivers/gpu/drm/i915/display/intel_dp.c      | 10 ++++++++++
 drivers/gpu/drm/i915/i915_pci.c              | 12 ++++++++++++
 3 files changed, 27 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c
index 9ea1a397d1b5..9e2b57e77118 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -15412,6 +15412,8 @@ static void intel_atomic_commit_tail(struct intel_atomic_state *state)
 	struct drm_device *dev = state->base.dev;
 	struct drm_i915_private *dev_priv = to_i915(dev);
 	struct intel_crtc_state *new_crtc_state, *old_crtc_state;
+	struct drm_connector_state *new_connector_state;
+	struct drm_connector *connector;
 	struct intel_crtc *crtc;
 	u64 put_domains[I915_MAX_PIPES] = {};
 	intel_wakeref_t wakeref = 0;
@@ -15501,6 +15503,9 @@ static void intel_atomic_commit_tail(struct intel_atomic_state *state)
 			intel_color_load_luts(new_crtc_state);
 	}
 
+	for_each_new_connector_in_state(&state->base, connector, new_connector_state, i)
+		drm_connector_update_privacy_screen(connector, &state->base);
+
 	/*
 	 * Now that the vblank has passed, we can go ahead and program the
 	 * optimal watermarks on platforms that need two-step watermark
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c
index ed9e53c373a7..6d4e0a5e054b 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -39,6 +39,7 @@
 #include <drm/drm_dp_helper.h>
 #include <drm/drm_edid.h>
 #include <drm/drm_hdcp.h>
+#include <drm/drm_privacy_screen_consumer.h>
 #include <drm/drm_probe_helper.h>
 
 #include "i915_debugfs.h"
@@ -8032,6 +8033,7 @@ static bool intel_edp_init_connector(struct intel_dp *intel_dp,
 	struct drm_connector *connector = &intel_connector->base;
 	struct drm_display_mode *fixed_mode = NULL;
 	struct drm_display_mode *downclock_mode = NULL;
+	struct drm_privacy_screen *privacy_screen;
 	bool has_dpcd;
 	enum pipe pipe = INVALID_PIPE;
 	intel_wakeref_t wakeref;
@@ -8129,6 +8131,14 @@ static bool intel_edp_init_connector(struct intel_dp *intel_dp,
 				fixed_mode->hdisplay, fixed_mode->vdisplay);
 	}
 
+	privacy_screen = drm_privacy_screen_get(&dev->pdev->dev, NULL);
+	if (!IS_ERR(privacy_screen)) {
+		drm_connector_attach_privacy_screen_provider(connector,
+							     privacy_screen);
+	} else if (PTR_ERR(privacy_screen) != -ENODEV) {
+		drm_warn(&dev_priv->drm, "Error getting privacy-screen\n");
+	}
+
 	return true;
 
 out_vdd_off:
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index eb0b5be7c35d..3604babc2ee7 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -26,6 +26,7 @@
 #include <linux/vga_switcheroo.h>
 
 #include <drm/drm_drv.h>
+#include <drm/drm_privacy_screen_consumer.h>
 #include <drm/i915_pciids.h>
 
 #include "display/intel_fbdev.h"
@@ -992,6 +993,7 @@ static int i915_pci_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
 {
 	struct intel_device_info *intel_info =
 		(struct intel_device_info *) ent->driver_data;
+	struct drm_privacy_screen *privacy_screen;
 	int err;
 
 	if (intel_info->require_force_probe &&
@@ -1020,7 +1022,17 @@ static int i915_pci_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
 	if (vga_switcheroo_client_probe_defer(pdev))
 		return -EPROBE_DEFER;
 
+	/*
+	 * We do not handle -EPROBE_DEFER further into the probe process, so
+	 * check if we have a laptop-panel privacy-screen for which the driver
+	 * has not loaded yet here.
+	 */
+	privacy_screen = drm_privacy_screen_get(&pdev->dev, NULL);
+	if (IS_ERR(privacy_screen) && PTR_ERR(privacy_screen) == -EPROBE_DEFER)
+		return -EPROBE_DEFER;
+
 	err = i915_driver_probe(pdev, ent);
+	drm_privacy_screen_put(privacy_screen);
 	if (err)
 		return err;
 
-- 
2.26.2

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply related	[flat|nested] 44+ messages in thread

* [Intel-gfx] ✗ Fi.CI.BUILD: failure for drm: Add privacy-screen class and connector properties
  2020-07-08 16:43 ` [Intel-gfx] " Hans de Goede
                   ` (9 preceding siblings ...)
  (?)
@ 2020-07-08 16:58 ` Patchwork
  2020-07-08 19:33   ` Hans de Goede
  -1 siblings, 1 reply; 44+ messages in thread
From: Patchwork @ 2020-07-08 16:58 UTC (permalink / raw)
  To: Hans de Goede; +Cc: intel-gfx

== Series Details ==

Series: drm: Add privacy-screen class and connector properties
URL   : https://patchwork.freedesktop.org/series/79259/
State : failure

== Summary ==

Applying: drm/connector: Fix kerneldoc warning
Using index info to reconstruct a base tree...
M	drivers/gpu/drm/drm_connector.c
Falling back to patching base and 3-way merge...
Auto-merging drivers/gpu/drm/drm_connector.c
CONFLICT (content): Merge conflict in drivers/gpu/drm/drm_connector.c
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Patch failed at 0001 drm/connector: Fix kerneldoc warning
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [Intel-gfx]  ✗ Fi.CI.BUILD: failure for drm: Add privacy-screen class and connector properties
  2020-07-08 16:58 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for drm: Add privacy-screen class and connector properties Patchwork
@ 2020-07-08 19:33   ` Hans de Goede
  0 siblings, 0 replies; 44+ messages in thread
From: Hans de Goede @ 2020-07-08 19:33 UTC (permalink / raw)
  To: intel-gfx

Hi,

On 7/8/20 6:58 PM, Patchwork wrote:
> == Series Details ==
> 
> Series: drm: Add privacy-screen class and connector properties
> URL   : https://patchwork.freedesktop.org/series/79259/
> State : failure
> 
> == Summary ==
> 
> Applying: drm/connector: Fix kerneldoc warning
> Using index info to reconstruct a base tree...
> M	drivers/gpu/drm/drm_connector.c
> Falling back to patching base and 3-way merge...
> Auto-merging drivers/gpu/drm/drm_connector.c
> CONFLICT (content): Merge conflict in drivers/gpu/drm/drm_connector.c

So I was testing on top of 5.8-rc4, I guess I need to rebase this
on dinq. But I'm sure that there will be review comments and my
main reason for posting this v1 was to get feedback, not to get
this CI-ed. So please do review this despite it not cleanly
applying on current dinq. If it not applying somehow impends
reviewing this, please let me know.

Regards,

Hans

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [Intel-gfx] [PATCH 6/9] drm/connector: Add a drm_connector privacy-screen helper functions
  2020-07-08 16:43   ` [Intel-gfx] " Hans de Goede
  (?)
@ 2020-07-08 20:15     ` kernel test robot
  -1 siblings, 0 replies; 44+ messages in thread
From: kernel test robot @ 2020-07-08 20:15 UTC (permalink / raw)
  To: Hans de Goede, Maarten Lankhorst, Maxime Ripard,
	Thomas Zimmermann, Daniel Vetter, David Airlie, Jani Nikula,
	Joonas Lahtinen, Rodrigo Vivi
  Cc: intel-gfx, kbuild-all, dri-devel

[-- Attachment #1: Type: text/plain, Size: 1766 bytes --]

Hi Hans,

I love your patch! Yet something to improve:

[auto build test ERROR on linus/master]
[also build test ERROR on v5.8-rc4]
[cannot apply to drm-intel/for-linux-next drm-tip/drm-tip next-20200708]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use  as documented in
https://git-scm.com/docs/git-format-patch]

url:    https://github.com/0day-ci/linux/commits/Hans-de-Goede/drm-Add-privacy-screen-class-and-connector-properties/20200709-004703
base:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git dcde237b9b0eb1d19306e6f48c0a4e058907619f
config: arc-axs103_smp_defconfig (attached as .config)
compiler: arc-elf-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=arc 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>

All errors (new ones prefixed by >>, old ones prefixed by <<):

>> ERROR: modpost: "drm_privacy_screen_register_notifier" [drivers/gpu/drm/drm.ko] undefined!
>> ERROR: modpost: "drm_privacy_screen_get_state" [drivers/gpu/drm/drm.ko] undefined!
>> ERROR: modpost: "drm_privacy_screen_unregister_notifier" [drivers/gpu/drm/drm.ko] undefined!
>> ERROR: modpost: "drm_privacy_screen_put" [drivers/gpu/drm/drm.ko] undefined!
>> ERROR: modpost: "drm_privacy_screen_set_sw_state" [drivers/gpu/drm/drm.ko] undefined!

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org

[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 15422 bytes --]

[-- Attachment #3: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [Intel-gfx] [PATCH 6/9] drm/connector: Add a drm_connector privacy-screen helper functions
@ 2020-07-08 20:15     ` kernel test robot
  0 siblings, 0 replies; 44+ messages in thread
From: kernel test robot @ 2020-07-08 20:15 UTC (permalink / raw)
  To: Hans de Goede, Maarten Lankhorst, Maxime Ripard,
	Thomas Zimmermann, Daniel Vetter, David Airlie, Jani Nikula,
	Joonas Lahtinen, Rodrigo Vivi
  Cc: intel-gfx, kbuild-all, dri-devel

[-- Attachment #1: Type: text/plain, Size: 1766 bytes --]

Hi Hans,

I love your patch! Yet something to improve:

[auto build test ERROR on linus/master]
[also build test ERROR on v5.8-rc4]
[cannot apply to drm-intel/for-linux-next drm-tip/drm-tip next-20200708]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use  as documented in
https://git-scm.com/docs/git-format-patch]

url:    https://github.com/0day-ci/linux/commits/Hans-de-Goede/drm-Add-privacy-screen-class-and-connector-properties/20200709-004703
base:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git dcde237b9b0eb1d19306e6f48c0a4e058907619f
config: arc-axs103_smp_defconfig (attached as .config)
compiler: arc-elf-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=arc 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>

All errors (new ones prefixed by >>, old ones prefixed by <<):

>> ERROR: modpost: "drm_privacy_screen_register_notifier" [drivers/gpu/drm/drm.ko] undefined!
>> ERROR: modpost: "drm_privacy_screen_get_state" [drivers/gpu/drm/drm.ko] undefined!
>> ERROR: modpost: "drm_privacy_screen_unregister_notifier" [drivers/gpu/drm/drm.ko] undefined!
>> ERROR: modpost: "drm_privacy_screen_put" [drivers/gpu/drm/drm.ko] undefined!
>> ERROR: modpost: "drm_privacy_screen_set_sw_state" [drivers/gpu/drm/drm.ko] undefined!

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org

[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 15422 bytes --]

[-- Attachment #3: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [Intel-gfx] [PATCH 6/9] drm/connector: Add a drm_connector privacy-screen helper functions
@ 2020-07-08 20:15     ` kernel test robot
  0 siblings, 0 replies; 44+ messages in thread
From: kernel test robot @ 2020-07-08 20:15 UTC (permalink / raw)
  To: kbuild-all

[-- Attachment #1: Type: text/plain, Size: 1803 bytes --]

Hi Hans,

I love your patch! Yet something to improve:

[auto build test ERROR on linus/master]
[also build test ERROR on v5.8-rc4]
[cannot apply to drm-intel/for-linux-next drm-tip/drm-tip next-20200708]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use  as documented in
https://git-scm.com/docs/git-format-patch]

url:    https://github.com/0day-ci/linux/commits/Hans-de-Goede/drm-Add-privacy-screen-class-and-connector-properties/20200709-004703
base:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git dcde237b9b0eb1d19306e6f48c0a4e058907619f
config: arc-axs103_smp_defconfig (attached as .config)
compiler: arc-elf-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=arc 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>

All errors (new ones prefixed by >>, old ones prefixed by <<):

>> ERROR: modpost: "drm_privacy_screen_register_notifier" [drivers/gpu/drm/drm.ko] undefined!
>> ERROR: modpost: "drm_privacy_screen_get_state" [drivers/gpu/drm/drm.ko] undefined!
>> ERROR: modpost: "drm_privacy_screen_unregister_notifier" [drivers/gpu/drm/drm.ko] undefined!
>> ERROR: modpost: "drm_privacy_screen_put" [drivers/gpu/drm/drm.ko] undefined!
>> ERROR: modpost: "drm_privacy_screen_set_sw_state" [drivers/gpu/drm/drm.ko] undefined!

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org

[-- Attachment #2: config.gz --]
[-- Type: application/gzip, Size: 15422 bytes --]

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [Intel-gfx] [PATCH 6/9] drm/connector: Add a drm_connector privacy-screen helper functions
  2020-07-08 16:43   ` [Intel-gfx] " Hans de Goede
  (?)
@ 2020-07-08 20:57     ` kernel test robot
  -1 siblings, 0 replies; 44+ messages in thread
From: kernel test robot @ 2020-07-08 20:57 UTC (permalink / raw)
  To: Hans de Goede, Maarten Lankhorst, Maxime Ripard,
	Thomas Zimmermann, Daniel Vetter, David Airlie, Jani Nikula,
	Joonas Lahtinen, Rodrigo Vivi
  Cc: intel-gfx, kbuild-all, dri-devel

[-- Attachment #1: Type: text/plain, Size: 9581 bytes --]

Hi Hans,

I love your patch! Yet something to improve:

[auto build test ERROR on linus/master]
[also build test ERROR on v5.8-rc4]
[cannot apply to drm-intel/for-linux-next drm-tip/drm-tip next-20200708]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use  as documented in
https://git-scm.com/docs/git-format-patch]

url:    https://github.com/0day-ci/linux/commits/Hans-de-Goede/drm-Add-privacy-screen-class-and-connector-properties/20200709-004703
base:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git dcde237b9b0eb1d19306e6f48c0a4e058907619f
config: riscv-randconfig-s031-20200708 (attached as .config)
compiler: riscv64-linux-gcc (GCC) 9.3.0
reproduce:
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # apt-get install sparse
        # sparse version: v0.6.2-37-gc9676a3b-dirty
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=riscv 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>

All errors (new ones prefixed by >>):

   riscv64-linux-ld: drivers/gpu/drm/drm_connector.o: in function `drm_connector_register':
>> drivers/gpu/drm/drm_connector.c:533: undefined reference to `drm_privacy_screen_register_notifier'
   riscv64-linux-ld: drivers/gpu/drm/drm_connector.o: in function `drm_connector_unregister':
>> drivers/gpu/drm/drm_connector.c:567: undefined reference to `drm_privacy_screen_unregister_notifier'
   riscv64-linux-ld: drivers/gpu/drm/drm_connector.o: in function `drm_connector_set_link_status_property':
>> drivers/gpu/drm/drm_connector.c:2076: undefined reference to `drm_privacy_screen_get_state'
   riscv64-linux-ld: drivers/gpu/drm/drm_connector.o: in function `drm_connector_privacy_screen_notifier':
>> drivers/gpu/drm/drm_connector.c:2299: undefined reference to `drm_privacy_screen_set_sw_state'
   riscv64-linux-ld: drivers/gpu/drm/drm_connector.o: in function `drm_tile_group_free':
>> drivers/gpu/drm/drm_connector.c:2586: undefined reference to `drm_privacy_screen_put'

vim +533 drivers/gpu/drm/drm_connector.c

52217195176115 Daniel Vetter      2016-08-12  495  
52217195176115 Daniel Vetter      2016-08-12  496  /**
52217195176115 Daniel Vetter      2016-08-12  497   * drm_connector_register - register a connector
52217195176115 Daniel Vetter      2016-08-12  498   * @connector: the connector to register
52217195176115 Daniel Vetter      2016-08-12  499   *
69b22f51e6644b Daniel Vetter      2019-09-17  500   * Register userspace interfaces for a connector. Only call this for connectors
69b22f51e6644b Daniel Vetter      2019-09-17  501   * which can be hotplugged after drm_dev_register() has been called already,
69b22f51e6644b Daniel Vetter      2019-09-17  502   * e.g. DP MST connectors. All other connectors will be registered automatically
69b22f51e6644b Daniel Vetter      2019-09-17  503   * when calling drm_dev_register().
52217195176115 Daniel Vetter      2016-08-12  504   *
52217195176115 Daniel Vetter      2016-08-12  505   * Returns:
52217195176115 Daniel Vetter      2016-08-12  506   * Zero on success, error code on failure.
52217195176115 Daniel Vetter      2016-08-12  507   */
52217195176115 Daniel Vetter      2016-08-12  508  int drm_connector_register(struct drm_connector *connector)
52217195176115 Daniel Vetter      2016-08-12  509  {
e73ab00e9a0f17 Daniel Vetter      2016-12-18  510  	int ret = 0;
52217195176115 Daniel Vetter      2016-08-12  511  
e6e7b48b295afa Daniel Vetter      2017-01-12  512  	if (!connector->dev->registered)
e6e7b48b295afa Daniel Vetter      2017-01-12  513  		return 0;
e6e7b48b295afa Daniel Vetter      2017-01-12  514  
e73ab00e9a0f17 Daniel Vetter      2016-12-18  515  	mutex_lock(&connector->mutex);
39b50c603878f4 Lyude Paul         2018-10-16  516  	if (connector->registration_state != DRM_CONNECTOR_INITIALIZING)
e73ab00e9a0f17 Daniel Vetter      2016-12-18  517  		goto unlock;
52217195176115 Daniel Vetter      2016-08-12  518  
52217195176115 Daniel Vetter      2016-08-12  519  	ret = drm_sysfs_connector_add(connector);
52217195176115 Daniel Vetter      2016-08-12  520  	if (ret)
e73ab00e9a0f17 Daniel Vetter      2016-12-18  521  		goto unlock;
52217195176115 Daniel Vetter      2016-08-12  522  
b792e64021ecde Greg Kroah-Hartman 2019-06-13  523  	drm_debugfs_connector_add(connector);
52217195176115 Daniel Vetter      2016-08-12  524  
52217195176115 Daniel Vetter      2016-08-12  525  	if (connector->funcs->late_register) {
52217195176115 Daniel Vetter      2016-08-12  526  		ret = connector->funcs->late_register(connector);
52217195176115 Daniel Vetter      2016-08-12  527  		if (ret)
52217195176115 Daniel Vetter      2016-08-12  528  			goto err_debugfs;
52217195176115 Daniel Vetter      2016-08-12  529  	}
52217195176115 Daniel Vetter      2016-08-12  530  
52217195176115 Daniel Vetter      2016-08-12  531  	drm_mode_object_register(connector->dev, &connector->base);
52217195176115 Daniel Vetter      2016-08-12  532  
39b50c603878f4 Lyude Paul         2018-10-16 @533  	connector->registration_state = DRM_CONNECTOR_REGISTERED;
968d81a64a883a Jeykumar Sankaran  2020-06-02  534  
968d81a64a883a Jeykumar Sankaran  2020-06-02  535  	/* Let userspace know we have a new connector */
968d81a64a883a Jeykumar Sankaran  2020-06-02  536  	drm_sysfs_hotplug_event(connector->dev);
968d81a64a883a Jeykumar Sankaran  2020-06-02  537  
3823adf8dc676e Hans de Goede      2020-07-08  538  	if (connector->privacy_screen)
3823adf8dc676e Hans de Goede      2020-07-08  539  		drm_privacy_screen_register_notifier(connector->privacy_screen,
3823adf8dc676e Hans de Goede      2020-07-08  540  					   &connector->privacy_screen_notifier);
3823adf8dc676e Hans de Goede      2020-07-08  541  
e73ab00e9a0f17 Daniel Vetter      2016-12-18  542  	goto unlock;
52217195176115 Daniel Vetter      2016-08-12  543  
52217195176115 Daniel Vetter      2016-08-12  544  err_debugfs:
52217195176115 Daniel Vetter      2016-08-12  545  	drm_debugfs_connector_remove(connector);
52217195176115 Daniel Vetter      2016-08-12  546  	drm_sysfs_connector_remove(connector);
e73ab00e9a0f17 Daniel Vetter      2016-12-18  547  unlock:
e73ab00e9a0f17 Daniel Vetter      2016-12-18  548  	mutex_unlock(&connector->mutex);
52217195176115 Daniel Vetter      2016-08-12  549  	return ret;
52217195176115 Daniel Vetter      2016-08-12  550  }
52217195176115 Daniel Vetter      2016-08-12  551  EXPORT_SYMBOL(drm_connector_register);
52217195176115 Daniel Vetter      2016-08-12  552  
52217195176115 Daniel Vetter      2016-08-12  553  /**
52217195176115 Daniel Vetter      2016-08-12  554   * drm_connector_unregister - unregister a connector
52217195176115 Daniel Vetter      2016-08-12  555   * @connector: the connector to unregister
52217195176115 Daniel Vetter      2016-08-12  556   *
69b22f51e6644b Daniel Vetter      2019-09-17  557   * Unregister userspace interfaces for a connector. Only call this for
69b22f51e6644b Daniel Vetter      2019-09-17  558   * connectors which have registered explicitly by calling drm_dev_register(),
69b22f51e6644b Daniel Vetter      2019-09-17  559   * since connectors are unregistered automatically when drm_dev_unregister() is
69b22f51e6644b Daniel Vetter      2019-09-17  560   * called.
52217195176115 Daniel Vetter      2016-08-12  561   */
52217195176115 Daniel Vetter      2016-08-12  562  void drm_connector_unregister(struct drm_connector *connector)
52217195176115 Daniel Vetter      2016-08-12  563  {
e73ab00e9a0f17 Daniel Vetter      2016-12-18  564  	mutex_lock(&connector->mutex);
39b50c603878f4 Lyude Paul         2018-10-16  565  	if (connector->registration_state != DRM_CONNECTOR_REGISTERED) {
e73ab00e9a0f17 Daniel Vetter      2016-12-18  566  		mutex_unlock(&connector->mutex);
52217195176115 Daniel Vetter      2016-08-12 @567  		return;
e73ab00e9a0f17 Daniel Vetter      2016-12-18  568  	}
52217195176115 Daniel Vetter      2016-08-12  569  
3823adf8dc676e Hans de Goede      2020-07-08  570  	if (connector->privacy_screen)
3823adf8dc676e Hans de Goede      2020-07-08  571  		drm_privacy_screen_unregister_notifier(
3823adf8dc676e Hans de Goede      2020-07-08  572  					connector->privacy_screen,
3823adf8dc676e Hans de Goede      2020-07-08  573  					&connector->privacy_screen_notifier);
3823adf8dc676e Hans de Goede      2020-07-08  574  
52217195176115 Daniel Vetter      2016-08-12  575  	if (connector->funcs->early_unregister)
52217195176115 Daniel Vetter      2016-08-12  576  		connector->funcs->early_unregister(connector);
52217195176115 Daniel Vetter      2016-08-12  577  
52217195176115 Daniel Vetter      2016-08-12  578  	drm_sysfs_connector_remove(connector);
52217195176115 Daniel Vetter      2016-08-12  579  	drm_debugfs_connector_remove(connector);
52217195176115 Daniel Vetter      2016-08-12  580  
39b50c603878f4 Lyude Paul         2018-10-16  581  	connector->registration_state = DRM_CONNECTOR_UNREGISTERED;
e73ab00e9a0f17 Daniel Vetter      2016-12-18  582  	mutex_unlock(&connector->mutex);
52217195176115 Daniel Vetter      2016-08-12  583  }
52217195176115 Daniel Vetter      2016-08-12  584  EXPORT_SYMBOL(drm_connector_unregister);
52217195176115 Daniel Vetter      2016-08-12  585  

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org

[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 29953 bytes --]

[-- Attachment #3: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [Intel-gfx] [PATCH 6/9] drm/connector: Add a drm_connector privacy-screen helper functions
@ 2020-07-08 20:57     ` kernel test robot
  0 siblings, 0 replies; 44+ messages in thread
From: kernel test robot @ 2020-07-08 20:57 UTC (permalink / raw)
  To: Hans de Goede, Maarten Lankhorst, Maxime Ripard,
	Thomas Zimmermann, Daniel Vetter, David Airlie, Jani Nikula,
	Joonas Lahtinen, Rodrigo Vivi
  Cc: intel-gfx, kbuild-all, dri-devel

[-- Attachment #1: Type: text/plain, Size: 9581 bytes --]

Hi Hans,

I love your patch! Yet something to improve:

[auto build test ERROR on linus/master]
[also build test ERROR on v5.8-rc4]
[cannot apply to drm-intel/for-linux-next drm-tip/drm-tip next-20200708]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use  as documented in
https://git-scm.com/docs/git-format-patch]

url:    https://github.com/0day-ci/linux/commits/Hans-de-Goede/drm-Add-privacy-screen-class-and-connector-properties/20200709-004703
base:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git dcde237b9b0eb1d19306e6f48c0a4e058907619f
config: riscv-randconfig-s031-20200708 (attached as .config)
compiler: riscv64-linux-gcc (GCC) 9.3.0
reproduce:
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # apt-get install sparse
        # sparse version: v0.6.2-37-gc9676a3b-dirty
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=riscv 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>

All errors (new ones prefixed by >>):

   riscv64-linux-ld: drivers/gpu/drm/drm_connector.o: in function `drm_connector_register':
>> drivers/gpu/drm/drm_connector.c:533: undefined reference to `drm_privacy_screen_register_notifier'
   riscv64-linux-ld: drivers/gpu/drm/drm_connector.o: in function `drm_connector_unregister':
>> drivers/gpu/drm/drm_connector.c:567: undefined reference to `drm_privacy_screen_unregister_notifier'
   riscv64-linux-ld: drivers/gpu/drm/drm_connector.o: in function `drm_connector_set_link_status_property':
>> drivers/gpu/drm/drm_connector.c:2076: undefined reference to `drm_privacy_screen_get_state'
   riscv64-linux-ld: drivers/gpu/drm/drm_connector.o: in function `drm_connector_privacy_screen_notifier':
>> drivers/gpu/drm/drm_connector.c:2299: undefined reference to `drm_privacy_screen_set_sw_state'
   riscv64-linux-ld: drivers/gpu/drm/drm_connector.o: in function `drm_tile_group_free':
>> drivers/gpu/drm/drm_connector.c:2586: undefined reference to `drm_privacy_screen_put'

vim +533 drivers/gpu/drm/drm_connector.c

52217195176115 Daniel Vetter      2016-08-12  495  
52217195176115 Daniel Vetter      2016-08-12  496  /**
52217195176115 Daniel Vetter      2016-08-12  497   * drm_connector_register - register a connector
52217195176115 Daniel Vetter      2016-08-12  498   * @connector: the connector to register
52217195176115 Daniel Vetter      2016-08-12  499   *
69b22f51e6644b Daniel Vetter      2019-09-17  500   * Register userspace interfaces for a connector. Only call this for connectors
69b22f51e6644b Daniel Vetter      2019-09-17  501   * which can be hotplugged after drm_dev_register() has been called already,
69b22f51e6644b Daniel Vetter      2019-09-17  502   * e.g. DP MST connectors. All other connectors will be registered automatically
69b22f51e6644b Daniel Vetter      2019-09-17  503   * when calling drm_dev_register().
52217195176115 Daniel Vetter      2016-08-12  504   *
52217195176115 Daniel Vetter      2016-08-12  505   * Returns:
52217195176115 Daniel Vetter      2016-08-12  506   * Zero on success, error code on failure.
52217195176115 Daniel Vetter      2016-08-12  507   */
52217195176115 Daniel Vetter      2016-08-12  508  int drm_connector_register(struct drm_connector *connector)
52217195176115 Daniel Vetter      2016-08-12  509  {
e73ab00e9a0f17 Daniel Vetter      2016-12-18  510  	int ret = 0;
52217195176115 Daniel Vetter      2016-08-12  511  
e6e7b48b295afa Daniel Vetter      2017-01-12  512  	if (!connector->dev->registered)
e6e7b48b295afa Daniel Vetter      2017-01-12  513  		return 0;
e6e7b48b295afa Daniel Vetter      2017-01-12  514  
e73ab00e9a0f17 Daniel Vetter      2016-12-18  515  	mutex_lock(&connector->mutex);
39b50c603878f4 Lyude Paul         2018-10-16  516  	if (connector->registration_state != DRM_CONNECTOR_INITIALIZING)
e73ab00e9a0f17 Daniel Vetter      2016-12-18  517  		goto unlock;
52217195176115 Daniel Vetter      2016-08-12  518  
52217195176115 Daniel Vetter      2016-08-12  519  	ret = drm_sysfs_connector_add(connector);
52217195176115 Daniel Vetter      2016-08-12  520  	if (ret)
e73ab00e9a0f17 Daniel Vetter      2016-12-18  521  		goto unlock;
52217195176115 Daniel Vetter      2016-08-12  522  
b792e64021ecde Greg Kroah-Hartman 2019-06-13  523  	drm_debugfs_connector_add(connector);
52217195176115 Daniel Vetter      2016-08-12  524  
52217195176115 Daniel Vetter      2016-08-12  525  	if (connector->funcs->late_register) {
52217195176115 Daniel Vetter      2016-08-12  526  		ret = connector->funcs->late_register(connector);
52217195176115 Daniel Vetter      2016-08-12  527  		if (ret)
52217195176115 Daniel Vetter      2016-08-12  528  			goto err_debugfs;
52217195176115 Daniel Vetter      2016-08-12  529  	}
52217195176115 Daniel Vetter      2016-08-12  530  
52217195176115 Daniel Vetter      2016-08-12  531  	drm_mode_object_register(connector->dev, &connector->base);
52217195176115 Daniel Vetter      2016-08-12  532  
39b50c603878f4 Lyude Paul         2018-10-16 @533  	connector->registration_state = DRM_CONNECTOR_REGISTERED;
968d81a64a883a Jeykumar Sankaran  2020-06-02  534  
968d81a64a883a Jeykumar Sankaran  2020-06-02  535  	/* Let userspace know we have a new connector */
968d81a64a883a Jeykumar Sankaran  2020-06-02  536  	drm_sysfs_hotplug_event(connector->dev);
968d81a64a883a Jeykumar Sankaran  2020-06-02  537  
3823adf8dc676e Hans de Goede      2020-07-08  538  	if (connector->privacy_screen)
3823adf8dc676e Hans de Goede      2020-07-08  539  		drm_privacy_screen_register_notifier(connector->privacy_screen,
3823adf8dc676e Hans de Goede      2020-07-08  540  					   &connector->privacy_screen_notifier);
3823adf8dc676e Hans de Goede      2020-07-08  541  
e73ab00e9a0f17 Daniel Vetter      2016-12-18  542  	goto unlock;
52217195176115 Daniel Vetter      2016-08-12  543  
52217195176115 Daniel Vetter      2016-08-12  544  err_debugfs:
52217195176115 Daniel Vetter      2016-08-12  545  	drm_debugfs_connector_remove(connector);
52217195176115 Daniel Vetter      2016-08-12  546  	drm_sysfs_connector_remove(connector);
e73ab00e9a0f17 Daniel Vetter      2016-12-18  547  unlock:
e73ab00e9a0f17 Daniel Vetter      2016-12-18  548  	mutex_unlock(&connector->mutex);
52217195176115 Daniel Vetter      2016-08-12  549  	return ret;
52217195176115 Daniel Vetter      2016-08-12  550  }
52217195176115 Daniel Vetter      2016-08-12  551  EXPORT_SYMBOL(drm_connector_register);
52217195176115 Daniel Vetter      2016-08-12  552  
52217195176115 Daniel Vetter      2016-08-12  553  /**
52217195176115 Daniel Vetter      2016-08-12  554   * drm_connector_unregister - unregister a connector
52217195176115 Daniel Vetter      2016-08-12  555   * @connector: the connector to unregister
52217195176115 Daniel Vetter      2016-08-12  556   *
69b22f51e6644b Daniel Vetter      2019-09-17  557   * Unregister userspace interfaces for a connector. Only call this for
69b22f51e6644b Daniel Vetter      2019-09-17  558   * connectors which have registered explicitly by calling drm_dev_register(),
69b22f51e6644b Daniel Vetter      2019-09-17  559   * since connectors are unregistered automatically when drm_dev_unregister() is
69b22f51e6644b Daniel Vetter      2019-09-17  560   * called.
52217195176115 Daniel Vetter      2016-08-12  561   */
52217195176115 Daniel Vetter      2016-08-12  562  void drm_connector_unregister(struct drm_connector *connector)
52217195176115 Daniel Vetter      2016-08-12  563  {
e73ab00e9a0f17 Daniel Vetter      2016-12-18  564  	mutex_lock(&connector->mutex);
39b50c603878f4 Lyude Paul         2018-10-16  565  	if (connector->registration_state != DRM_CONNECTOR_REGISTERED) {
e73ab00e9a0f17 Daniel Vetter      2016-12-18  566  		mutex_unlock(&connector->mutex);
52217195176115 Daniel Vetter      2016-08-12 @567  		return;
e73ab00e9a0f17 Daniel Vetter      2016-12-18  568  	}
52217195176115 Daniel Vetter      2016-08-12  569  
3823adf8dc676e Hans de Goede      2020-07-08  570  	if (connector->privacy_screen)
3823adf8dc676e Hans de Goede      2020-07-08  571  		drm_privacy_screen_unregister_notifier(
3823adf8dc676e Hans de Goede      2020-07-08  572  					connector->privacy_screen,
3823adf8dc676e Hans de Goede      2020-07-08  573  					&connector->privacy_screen_notifier);
3823adf8dc676e Hans de Goede      2020-07-08  574  
52217195176115 Daniel Vetter      2016-08-12  575  	if (connector->funcs->early_unregister)
52217195176115 Daniel Vetter      2016-08-12  576  		connector->funcs->early_unregister(connector);
52217195176115 Daniel Vetter      2016-08-12  577  
52217195176115 Daniel Vetter      2016-08-12  578  	drm_sysfs_connector_remove(connector);
52217195176115 Daniel Vetter      2016-08-12  579  	drm_debugfs_connector_remove(connector);
52217195176115 Daniel Vetter      2016-08-12  580  
39b50c603878f4 Lyude Paul         2018-10-16  581  	connector->registration_state = DRM_CONNECTOR_UNREGISTERED;
e73ab00e9a0f17 Daniel Vetter      2016-12-18  582  	mutex_unlock(&connector->mutex);
52217195176115 Daniel Vetter      2016-08-12  583  }
52217195176115 Daniel Vetter      2016-08-12  584  EXPORT_SYMBOL(drm_connector_unregister);
52217195176115 Daniel Vetter      2016-08-12  585  

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org

[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 29953 bytes --]

[-- Attachment #3: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [Intel-gfx] [PATCH 6/9] drm/connector: Add a drm_connector privacy-screen helper functions
@ 2020-07-08 20:57     ` kernel test robot
  0 siblings, 0 replies; 44+ messages in thread
From: kernel test robot @ 2020-07-08 20:57 UTC (permalink / raw)
  To: kbuild-all

[-- Attachment #1: Type: text/plain, Size: 9719 bytes --]

Hi Hans,

I love your patch! Yet something to improve:

[auto build test ERROR on linus/master]
[also build test ERROR on v5.8-rc4]
[cannot apply to drm-intel/for-linux-next drm-tip/drm-tip next-20200708]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use  as documented in
https://git-scm.com/docs/git-format-patch]

url:    https://github.com/0day-ci/linux/commits/Hans-de-Goede/drm-Add-privacy-screen-class-and-connector-properties/20200709-004703
base:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git dcde237b9b0eb1d19306e6f48c0a4e058907619f
config: riscv-randconfig-s031-20200708 (attached as .config)
compiler: riscv64-linux-gcc (GCC) 9.3.0
reproduce:
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # apt-get install sparse
        # sparse version: v0.6.2-37-gc9676a3b-dirty
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=riscv 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>

All errors (new ones prefixed by >>):

   riscv64-linux-ld: drivers/gpu/drm/drm_connector.o: in function `drm_connector_register':
>> drivers/gpu/drm/drm_connector.c:533: undefined reference to `drm_privacy_screen_register_notifier'
   riscv64-linux-ld: drivers/gpu/drm/drm_connector.o: in function `drm_connector_unregister':
>> drivers/gpu/drm/drm_connector.c:567: undefined reference to `drm_privacy_screen_unregister_notifier'
   riscv64-linux-ld: drivers/gpu/drm/drm_connector.o: in function `drm_connector_set_link_status_property':
>> drivers/gpu/drm/drm_connector.c:2076: undefined reference to `drm_privacy_screen_get_state'
   riscv64-linux-ld: drivers/gpu/drm/drm_connector.o: in function `drm_connector_privacy_screen_notifier':
>> drivers/gpu/drm/drm_connector.c:2299: undefined reference to `drm_privacy_screen_set_sw_state'
   riscv64-linux-ld: drivers/gpu/drm/drm_connector.o: in function `drm_tile_group_free':
>> drivers/gpu/drm/drm_connector.c:2586: undefined reference to `drm_privacy_screen_put'

vim +533 drivers/gpu/drm/drm_connector.c

52217195176115 Daniel Vetter      2016-08-12  495  
52217195176115 Daniel Vetter      2016-08-12  496  /**
52217195176115 Daniel Vetter      2016-08-12  497   * drm_connector_register - register a connector
52217195176115 Daniel Vetter      2016-08-12  498   * @connector: the connector to register
52217195176115 Daniel Vetter      2016-08-12  499   *
69b22f51e6644b Daniel Vetter      2019-09-17  500   * Register userspace interfaces for a connector. Only call this for connectors
69b22f51e6644b Daniel Vetter      2019-09-17  501   * which can be hotplugged after drm_dev_register() has been called already,
69b22f51e6644b Daniel Vetter      2019-09-17  502   * e.g. DP MST connectors. All other connectors will be registered automatically
69b22f51e6644b Daniel Vetter      2019-09-17  503   * when calling drm_dev_register().
52217195176115 Daniel Vetter      2016-08-12  504   *
52217195176115 Daniel Vetter      2016-08-12  505   * Returns:
52217195176115 Daniel Vetter      2016-08-12  506   * Zero on success, error code on failure.
52217195176115 Daniel Vetter      2016-08-12  507   */
52217195176115 Daniel Vetter      2016-08-12  508  int drm_connector_register(struct drm_connector *connector)
52217195176115 Daniel Vetter      2016-08-12  509  {
e73ab00e9a0f17 Daniel Vetter      2016-12-18  510  	int ret = 0;
52217195176115 Daniel Vetter      2016-08-12  511  
e6e7b48b295afa Daniel Vetter      2017-01-12  512  	if (!connector->dev->registered)
e6e7b48b295afa Daniel Vetter      2017-01-12  513  		return 0;
e6e7b48b295afa Daniel Vetter      2017-01-12  514  
e73ab00e9a0f17 Daniel Vetter      2016-12-18  515  	mutex_lock(&connector->mutex);
39b50c603878f4 Lyude Paul         2018-10-16  516  	if (connector->registration_state != DRM_CONNECTOR_INITIALIZING)
e73ab00e9a0f17 Daniel Vetter      2016-12-18  517  		goto unlock;
52217195176115 Daniel Vetter      2016-08-12  518  
52217195176115 Daniel Vetter      2016-08-12  519  	ret = drm_sysfs_connector_add(connector);
52217195176115 Daniel Vetter      2016-08-12  520  	if (ret)
e73ab00e9a0f17 Daniel Vetter      2016-12-18  521  		goto unlock;
52217195176115 Daniel Vetter      2016-08-12  522  
b792e64021ecde Greg Kroah-Hartman 2019-06-13  523  	drm_debugfs_connector_add(connector);
52217195176115 Daniel Vetter      2016-08-12  524  
52217195176115 Daniel Vetter      2016-08-12  525  	if (connector->funcs->late_register) {
52217195176115 Daniel Vetter      2016-08-12  526  		ret = connector->funcs->late_register(connector);
52217195176115 Daniel Vetter      2016-08-12  527  		if (ret)
52217195176115 Daniel Vetter      2016-08-12  528  			goto err_debugfs;
52217195176115 Daniel Vetter      2016-08-12  529  	}
52217195176115 Daniel Vetter      2016-08-12  530  
52217195176115 Daniel Vetter      2016-08-12  531  	drm_mode_object_register(connector->dev, &connector->base);
52217195176115 Daniel Vetter      2016-08-12  532  
39b50c603878f4 Lyude Paul         2018-10-16 @533  	connector->registration_state = DRM_CONNECTOR_REGISTERED;
968d81a64a883a Jeykumar Sankaran  2020-06-02  534  
968d81a64a883a Jeykumar Sankaran  2020-06-02  535  	/* Let userspace know we have a new connector */
968d81a64a883a Jeykumar Sankaran  2020-06-02  536  	drm_sysfs_hotplug_event(connector->dev);
968d81a64a883a Jeykumar Sankaran  2020-06-02  537  
3823adf8dc676e Hans de Goede      2020-07-08  538  	if (connector->privacy_screen)
3823adf8dc676e Hans de Goede      2020-07-08  539  		drm_privacy_screen_register_notifier(connector->privacy_screen,
3823adf8dc676e Hans de Goede      2020-07-08  540  					   &connector->privacy_screen_notifier);
3823adf8dc676e Hans de Goede      2020-07-08  541  
e73ab00e9a0f17 Daniel Vetter      2016-12-18  542  	goto unlock;
52217195176115 Daniel Vetter      2016-08-12  543  
52217195176115 Daniel Vetter      2016-08-12  544  err_debugfs:
52217195176115 Daniel Vetter      2016-08-12  545  	drm_debugfs_connector_remove(connector);
52217195176115 Daniel Vetter      2016-08-12  546  	drm_sysfs_connector_remove(connector);
e73ab00e9a0f17 Daniel Vetter      2016-12-18  547  unlock:
e73ab00e9a0f17 Daniel Vetter      2016-12-18  548  	mutex_unlock(&connector->mutex);
52217195176115 Daniel Vetter      2016-08-12  549  	return ret;
52217195176115 Daniel Vetter      2016-08-12  550  }
52217195176115 Daniel Vetter      2016-08-12  551  EXPORT_SYMBOL(drm_connector_register);
52217195176115 Daniel Vetter      2016-08-12  552  
52217195176115 Daniel Vetter      2016-08-12  553  /**
52217195176115 Daniel Vetter      2016-08-12  554   * drm_connector_unregister - unregister a connector
52217195176115 Daniel Vetter      2016-08-12  555   * @connector: the connector to unregister
52217195176115 Daniel Vetter      2016-08-12  556   *
69b22f51e6644b Daniel Vetter      2019-09-17  557   * Unregister userspace interfaces for a connector. Only call this for
69b22f51e6644b Daniel Vetter      2019-09-17  558   * connectors which have registered explicitly by calling drm_dev_register(),
69b22f51e6644b Daniel Vetter      2019-09-17  559   * since connectors are unregistered automatically when drm_dev_unregister() is
69b22f51e6644b Daniel Vetter      2019-09-17  560   * called.
52217195176115 Daniel Vetter      2016-08-12  561   */
52217195176115 Daniel Vetter      2016-08-12  562  void drm_connector_unregister(struct drm_connector *connector)
52217195176115 Daniel Vetter      2016-08-12  563  {
e73ab00e9a0f17 Daniel Vetter      2016-12-18  564  	mutex_lock(&connector->mutex);
39b50c603878f4 Lyude Paul         2018-10-16  565  	if (connector->registration_state != DRM_CONNECTOR_REGISTERED) {
e73ab00e9a0f17 Daniel Vetter      2016-12-18  566  		mutex_unlock(&connector->mutex);
52217195176115 Daniel Vetter      2016-08-12 @567  		return;
e73ab00e9a0f17 Daniel Vetter      2016-12-18  568  	}
52217195176115 Daniel Vetter      2016-08-12  569  
3823adf8dc676e Hans de Goede      2020-07-08  570  	if (connector->privacy_screen)
3823adf8dc676e Hans de Goede      2020-07-08  571  		drm_privacy_screen_unregister_notifier(
3823adf8dc676e Hans de Goede      2020-07-08  572  					connector->privacy_screen,
3823adf8dc676e Hans de Goede      2020-07-08  573  					&connector->privacy_screen_notifier);
3823adf8dc676e Hans de Goede      2020-07-08  574  
52217195176115 Daniel Vetter      2016-08-12  575  	if (connector->funcs->early_unregister)
52217195176115 Daniel Vetter      2016-08-12  576  		connector->funcs->early_unregister(connector);
52217195176115 Daniel Vetter      2016-08-12  577  
52217195176115 Daniel Vetter      2016-08-12  578  	drm_sysfs_connector_remove(connector);
52217195176115 Daniel Vetter      2016-08-12  579  	drm_debugfs_connector_remove(connector);
52217195176115 Daniel Vetter      2016-08-12  580  
39b50c603878f4 Lyude Paul         2018-10-16  581  	connector->registration_state = DRM_CONNECTOR_UNREGISTERED;
e73ab00e9a0f17 Daniel Vetter      2016-12-18  582  	mutex_unlock(&connector->mutex);
52217195176115 Daniel Vetter      2016-08-12  583  }
52217195176115 Daniel Vetter      2016-08-12  584  EXPORT_SYMBOL(drm_connector_unregister);
52217195176115 Daniel Vetter      2016-08-12  585  

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org

[-- Attachment #2: config.gz --]
[-- Type: application/gzip, Size: 29953 bytes --]

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [PATCH 0/9] drm: Add privacy-screen class and connector properties
  2020-07-08 16:43 ` [Intel-gfx] " Hans de Goede
@ 2020-07-08 21:25   ` Alex Deucher
  -1 siblings, 0 replies; 44+ messages in thread
From: Alex Deucher @ 2020-07-08 21:25 UTC (permalink / raw)
  To: Hans de Goede
  Cc: Maling list - DRI developers, Marco Trevisan, Thomas Zimmermann,
	Sebastien Bacher, David Airlie, intel-gfx, Rodrigo Vivi

On Wed, Jul 8, 2020 at 12:43 PM Hans de Goede <hdegoede@redhat.com> wrote:
>
> Hi All,
>
> Here is the privacy-screen related code which we discussed a while ago.
> This series consists of a number of different parts:
>
> 1. A new version of Rajat's privacy-screen connector properties patch,
> this adds new userspace API in the form of new properties
>
> 2. Since on most devices the privacy screen is actually controlled by
> some vendor specific ACPI/WMI interface which has a driver under
> drivers/platform/x86, we need some "glue" code to make this functionality
> available to KMS drivers. Patches 3-5 add a new privacy-screen class for
> this, which allows non KMS drivers (and possibly KMS drivers too) to
> register a privacy-screen device and also adds an interface for KMS drivers
> to get access to the privacy-screen associated with a specific connector.
> This is modelled similar to how we deal with e.g. PWMs and GPIOs in the
> kernel, including separate includes for consumers and providers(drivers).
>
> 3. Some drm_connector helper functions to keep the actual changes needed
> for this in individual KMS drivers as small as possible (patch 6).
>
> 4. Make the thinkpad_acpi code register a privacy-screen device on
> ThinkPads with a privacy-screen (patches 7-8)
>
> 5. Make the i915 driver export the privacy-screen functionality through
> the connector properties on the eDP connector.

Care to create a patch 10 for amdgpu?  Lenovo sells AMD thinkpads with
a privacy screen as well, presumably it works
the same way.

Alex

>
> I was a bit in doubt if I should calls this series a RFC, or just call
> it v1, since there is no real userspace code using this yet. It was
> tested using xrandr property access and udevadm event monitoring.
> I do expect / hope we will have patches for a userspace consumer of the
> new properties (mutter) ready soon.
>
> But since the code is completely ready, including API documentation,
> I've decided to just call this v1. Hopefully we can get patches for the
> first userspace consumer of this ready during the review of this.
>
> Regards,
>
> Hans
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [Intel-gfx] [PATCH 0/9] drm: Add privacy-screen class and connector properties
@ 2020-07-08 21:25   ` Alex Deucher
  0 siblings, 0 replies; 44+ messages in thread
From: Alex Deucher @ 2020-07-08 21:25 UTC (permalink / raw)
  To: Hans de Goede
  Cc: Maling list - DRI developers, Marco Trevisan, Thomas Zimmermann,
	Sebastien Bacher, David Airlie, intel-gfx, Maxime Ripard

On Wed, Jul 8, 2020 at 12:43 PM Hans de Goede <hdegoede@redhat.com> wrote:
>
> Hi All,
>
> Here is the privacy-screen related code which we discussed a while ago.
> This series consists of a number of different parts:
>
> 1. A new version of Rajat's privacy-screen connector properties patch,
> this adds new userspace API in the form of new properties
>
> 2. Since on most devices the privacy screen is actually controlled by
> some vendor specific ACPI/WMI interface which has a driver under
> drivers/platform/x86, we need some "glue" code to make this functionality
> available to KMS drivers. Patches 3-5 add a new privacy-screen class for
> this, which allows non KMS drivers (and possibly KMS drivers too) to
> register a privacy-screen device and also adds an interface for KMS drivers
> to get access to the privacy-screen associated with a specific connector.
> This is modelled similar to how we deal with e.g. PWMs and GPIOs in the
> kernel, including separate includes for consumers and providers(drivers).
>
> 3. Some drm_connector helper functions to keep the actual changes needed
> for this in individual KMS drivers as small as possible (patch 6).
>
> 4. Make the thinkpad_acpi code register a privacy-screen device on
> ThinkPads with a privacy-screen (patches 7-8)
>
> 5. Make the i915 driver export the privacy-screen functionality through
> the connector properties on the eDP connector.

Care to create a patch 10 for amdgpu?  Lenovo sells AMD thinkpads with
a privacy screen as well, presumably it works
the same way.

Alex

>
> I was a bit in doubt if I should calls this series a RFC, or just call
> it v1, since there is no real userspace code using this yet. It was
> tested using xrandr property access and udevadm event monitoring.
> I do expect / hope we will have patches for a userspace consumer of the
> new properties (mutter) ready soon.
>
> But since the code is completely ready, including API documentation,
> I've decided to just call this v1. Hopefully we can get patches for the
> first userspace consumer of this ready during the review of this.
>
> Regards,
>
> Hans
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [PATCH 1/9] drm/connector: Fix kerneldoc warning
  2020-07-08 16:43   ` [Intel-gfx] " Hans de Goede
@ 2020-07-08 21:26     ` Alex Deucher
  -1 siblings, 0 replies; 44+ messages in thread
From: Alex Deucher @ 2020-07-08 21:26 UTC (permalink / raw)
  To: Hans de Goede
  Cc: Maling list - DRI developers, Marco Trevisan, Thomas Zimmermann,
	Sebastien Bacher, David Airlie, intel-gfx, Rodrigo Vivi

On Wed, Jul 8, 2020 at 12:43 PM Hans de Goede <hdegoede@redhat.com> wrote:
>
> Fix the following kerneldoc warning:
>
> drivers/gpu/drm/drm_connector.c:2189:
> warning: missing initial short description on line
>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>

Acked-by: Alex Deucher <alexander.deucher@amd.com>

> ---
>  drivers/gpu/drm/drm_connector.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index d877ddc6dc57..543086533850 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -2130,8 +2130,8 @@ int drm_connector_set_panel_orientation(
>  EXPORT_SYMBOL(drm_connector_set_panel_orientation);
>
>  /**
> - * drm_connector_set_panel_orientation_with_quirk -
> - *     set the connecter's panel_orientation after checking for quirks
> + * drm_connector_set_panel_orientation_with_quirk - set the connecter's
> + *    panel_orientation after checking for quirks
>   * @connector: connector for which to init the panel-orientation property.
>   * @panel_orientation: drm_panel_orientation value to set
>   * @width: width in pixels of the panel, used for panel quirk detection
> --
> 2.26.2
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [Intel-gfx] [PATCH 1/9] drm/connector: Fix kerneldoc warning
@ 2020-07-08 21:26     ` Alex Deucher
  0 siblings, 0 replies; 44+ messages in thread
From: Alex Deucher @ 2020-07-08 21:26 UTC (permalink / raw)
  To: Hans de Goede
  Cc: Maling list - DRI developers, Marco Trevisan, Thomas Zimmermann,
	Sebastien Bacher, David Airlie, intel-gfx, Maxime Ripard

On Wed, Jul 8, 2020 at 12:43 PM Hans de Goede <hdegoede@redhat.com> wrote:
>
> Fix the following kerneldoc warning:
>
> drivers/gpu/drm/drm_connector.c:2189:
> warning: missing initial short description on line
>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>

Acked-by: Alex Deucher <alexander.deucher@amd.com>

> ---
>  drivers/gpu/drm/drm_connector.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index d877ddc6dc57..543086533850 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -2130,8 +2130,8 @@ int drm_connector_set_panel_orientation(
>  EXPORT_SYMBOL(drm_connector_set_panel_orientation);
>
>  /**
> - * drm_connector_set_panel_orientation_with_quirk -
> - *     set the connecter's panel_orientation after checking for quirks
> + * drm_connector_set_panel_orientation_with_quirk - set the connecter's
> + *    panel_orientation after checking for quirks
>   * @connector: connector for which to init the panel-orientation property.
>   * @panel_orientation: drm_panel_orientation value to set
>   * @width: width in pixels of the panel, used for panel quirk detection
> --
> 2.26.2
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [Intel-gfx] [PATCH 8/9] platform/x86: thinkpad_acpi: Register a privacy-screen device
  2020-07-08 16:43   ` [Intel-gfx] " Hans de Goede
  (?)
@ 2020-07-08 21:45     ` kernel test robot
  -1 siblings, 0 replies; 44+ messages in thread
From: kernel test robot @ 2020-07-08 21:45 UTC (permalink / raw)
  To: Hans de Goede, Maarten Lankhorst, Maxime Ripard,
	Thomas Zimmermann, Daniel Vetter, David Airlie, Jani Nikula,
	Joonas Lahtinen, Rodrigo Vivi
  Cc: intel-gfx, kbuild-all, dri-devel

[-- Attachment #1: Type: text/plain, Size: 2381 bytes --]

Hi Hans,

I love your patch! Perhaps something to improve:

[auto build test WARNING on linus/master]
[also build test WARNING on v5.8-rc4]
[cannot apply to drm-intel/for-linux-next drm-tip/drm-tip next-20200708]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use  as documented in
https://git-scm.com/docs/git-format-patch]

url:    https://github.com/0day-ci/linux/commits/Hans-de-Goede/drm-Add-privacy-screen-class-and-connector-properties/20200709-004703
base:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git dcde237b9b0eb1d19306e6f48c0a4e058907619f
config: i386-allyesconfig (attached as .config)
compiler: gcc-9 (Debian 9.3.0-14) 9.3.0
reproduce (this is a W=1 build):
        # save the attached .config to linux build tree
        make W=1 ARCH=i386 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>

All warnings (new ones prefixed by >>):

>> drivers/platform/x86/thinkpad_acpi.c:9707:5: warning: no previous prototype for 'lcdshadow_set_sw_state' [-Wmissing-prototypes]
    9707 | int lcdshadow_set_sw_state(struct drm_privacy_screen *priv,
         |     ^~~~~~~~~~~~~~~~~~~~~~
>> drivers/platform/x86/thinkpad_acpi.c:9722:6: warning: no previous prototype for 'lcdshadow_get_hw_state' [-Wmissing-prototypes]
    9722 | void lcdshadow_get_hw_state(struct drm_privacy_screen *priv)
         |      ^~~~~~~~~~~~~~~~~~~~~~

vim +/lcdshadow_set_sw_state +9707 drivers/platform/x86/thinkpad_acpi.c

  9706	
> 9707	int lcdshadow_set_sw_state(struct drm_privacy_screen *priv,
  9708				   enum drm_privacy_screen_status state)
  9709	{
  9710		int output;
  9711	
  9712		if (WARN_ON(!mutex_is_locked(&priv->lock)))
  9713			return -EIO;
  9714	
  9715		if (!acpi_evalf(lcdshadow_set_handle, &output, NULL, "dd", (int)state))
  9716			return -EIO;
  9717	
  9718		priv->hw_state = priv->sw_state = state;
  9719		return 0;
  9720	}
  9721	
> 9722	void lcdshadow_get_hw_state(struct drm_privacy_screen *priv)
  9723	{
  9724		int output;
  9725	
  9726		if (!acpi_evalf(lcdshadow_get_handle, &output, NULL, "dd", 0))
  9727			return;
  9728	
  9729		priv->hw_state = priv->sw_state = output & 0x1;
  9730	}
  9731	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org

[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 74103 bytes --]

[-- Attachment #3: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [Intel-gfx] [PATCH 8/9] platform/x86: thinkpad_acpi: Register a privacy-screen device
@ 2020-07-08 21:45     ` kernel test robot
  0 siblings, 0 replies; 44+ messages in thread
From: kernel test robot @ 2020-07-08 21:45 UTC (permalink / raw)
  To: Hans de Goede, Maarten Lankhorst, Maxime Ripard,
	Thomas Zimmermann, Daniel Vetter, David Airlie, Jani Nikula,
	Joonas Lahtinen, Rodrigo Vivi
  Cc: intel-gfx, kbuild-all, dri-devel

[-- Attachment #1: Type: text/plain, Size: 2381 bytes --]

Hi Hans,

I love your patch! Perhaps something to improve:

[auto build test WARNING on linus/master]
[also build test WARNING on v5.8-rc4]
[cannot apply to drm-intel/for-linux-next drm-tip/drm-tip next-20200708]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use  as documented in
https://git-scm.com/docs/git-format-patch]

url:    https://github.com/0day-ci/linux/commits/Hans-de-Goede/drm-Add-privacy-screen-class-and-connector-properties/20200709-004703
base:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git dcde237b9b0eb1d19306e6f48c0a4e058907619f
config: i386-allyesconfig (attached as .config)
compiler: gcc-9 (Debian 9.3.0-14) 9.3.0
reproduce (this is a W=1 build):
        # save the attached .config to linux build tree
        make W=1 ARCH=i386 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>

All warnings (new ones prefixed by >>):

>> drivers/platform/x86/thinkpad_acpi.c:9707:5: warning: no previous prototype for 'lcdshadow_set_sw_state' [-Wmissing-prototypes]
    9707 | int lcdshadow_set_sw_state(struct drm_privacy_screen *priv,
         |     ^~~~~~~~~~~~~~~~~~~~~~
>> drivers/platform/x86/thinkpad_acpi.c:9722:6: warning: no previous prototype for 'lcdshadow_get_hw_state' [-Wmissing-prototypes]
    9722 | void lcdshadow_get_hw_state(struct drm_privacy_screen *priv)
         |      ^~~~~~~~~~~~~~~~~~~~~~

vim +/lcdshadow_set_sw_state +9707 drivers/platform/x86/thinkpad_acpi.c

  9706	
> 9707	int lcdshadow_set_sw_state(struct drm_privacy_screen *priv,
  9708				   enum drm_privacy_screen_status state)
  9709	{
  9710		int output;
  9711	
  9712		if (WARN_ON(!mutex_is_locked(&priv->lock)))
  9713			return -EIO;
  9714	
  9715		if (!acpi_evalf(lcdshadow_set_handle, &output, NULL, "dd", (int)state))
  9716			return -EIO;
  9717	
  9718		priv->hw_state = priv->sw_state = state;
  9719		return 0;
  9720	}
  9721	
> 9722	void lcdshadow_get_hw_state(struct drm_privacy_screen *priv)
  9723	{
  9724		int output;
  9725	
  9726		if (!acpi_evalf(lcdshadow_get_handle, &output, NULL, "dd", 0))
  9727			return;
  9728	
  9729		priv->hw_state = priv->sw_state = output & 0x1;
  9730	}
  9731	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org

[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 74103 bytes --]

[-- Attachment #3: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [Intel-gfx] [PATCH 8/9] platform/x86: thinkpad_acpi: Register a privacy-screen device
@ 2020-07-08 21:45     ` kernel test robot
  0 siblings, 0 replies; 44+ messages in thread
From: kernel test robot @ 2020-07-08 21:45 UTC (permalink / raw)
  To: kbuild-all

[-- Attachment #1: Type: text/plain, Size: 2446 bytes --]

Hi Hans,

I love your patch! Perhaps something to improve:

[auto build test WARNING on linus/master]
[also build test WARNING on v5.8-rc4]
[cannot apply to drm-intel/for-linux-next drm-tip/drm-tip next-20200708]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use  as documented in
https://git-scm.com/docs/git-format-patch]

url:    https://github.com/0day-ci/linux/commits/Hans-de-Goede/drm-Add-privacy-screen-class-and-connector-properties/20200709-004703
base:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git dcde237b9b0eb1d19306e6f48c0a4e058907619f
config: i386-allyesconfig (attached as .config)
compiler: gcc-9 (Debian 9.3.0-14) 9.3.0
reproduce (this is a W=1 build):
        # save the attached .config to linux build tree
        make W=1 ARCH=i386 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>

All warnings (new ones prefixed by >>):

>> drivers/platform/x86/thinkpad_acpi.c:9707:5: warning: no previous prototype for 'lcdshadow_set_sw_state' [-Wmissing-prototypes]
    9707 | int lcdshadow_set_sw_state(struct drm_privacy_screen *priv,
         |     ^~~~~~~~~~~~~~~~~~~~~~
>> drivers/platform/x86/thinkpad_acpi.c:9722:6: warning: no previous prototype for 'lcdshadow_get_hw_state' [-Wmissing-prototypes]
    9722 | void lcdshadow_get_hw_state(struct drm_privacy_screen *priv)
         |      ^~~~~~~~~~~~~~~~~~~~~~

vim +/lcdshadow_set_sw_state +9707 drivers/platform/x86/thinkpad_acpi.c

  9706	
> 9707	int lcdshadow_set_sw_state(struct drm_privacy_screen *priv,
  9708				   enum drm_privacy_screen_status state)
  9709	{
  9710		int output;
  9711	
  9712		if (WARN_ON(!mutex_is_locked(&priv->lock)))
  9713			return -EIO;
  9714	
  9715		if (!acpi_evalf(lcdshadow_set_handle, &output, NULL, "dd", (int)state))
  9716			return -EIO;
  9717	
  9718		priv->hw_state = priv->sw_state = state;
  9719		return 0;
  9720	}
  9721	
> 9722	void lcdshadow_get_hw_state(struct drm_privacy_screen *priv)
  9723	{
  9724		int output;
  9725	
  9726		if (!acpi_evalf(lcdshadow_get_handle, &output, NULL, "dd", 0))
  9727			return;
  9728	
  9729		priv->hw_state = priv->sw_state = output & 0x1;
  9730	}
  9731	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org

[-- Attachment #2: config.gz --]
[-- Type: application/gzip, Size: 74103 bytes --]

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [PATCH 0/9] drm: Add privacy-screen class and connector properties
  2020-07-08 21:25   ` [Intel-gfx] " Alex Deucher
@ 2020-07-09 12:48     ` Hans de Goede
  -1 siblings, 0 replies; 44+ messages in thread
From: Hans de Goede @ 2020-07-09 12:48 UTC (permalink / raw)
  To: Alex Deucher
  Cc: Maling list - DRI developers, Marco Trevisan, Thomas Zimmermann,
	Sebastien Bacher, David Airlie, intel-gfx, Rodrigo Vivi

Hi,

On 7/8/20 11:25 PM, Alex Deucher wrote:
> On Wed, Jul 8, 2020 at 12:43 PM Hans de Goede <hdegoede@redhat.com> wrote:
>>
>> Hi All,
>>
>> Here is the privacy-screen related code which we discussed a while ago.
>> This series consists of a number of different parts:
>>
>> 1. A new version of Rajat's privacy-screen connector properties patch,
>> this adds new userspace API in the form of new properties
>>
>> 2. Since on most devices the privacy screen is actually controlled by
>> some vendor specific ACPI/WMI interface which has a driver under
>> drivers/platform/x86, we need some "glue" code to make this functionality
>> available to KMS drivers. Patches 3-5 add a new privacy-screen class for
>> this, which allows non KMS drivers (and possibly KMS drivers too) to
>> register a privacy-screen device and also adds an interface for KMS drivers
>> to get access to the privacy-screen associated with a specific connector.
>> This is modelled similar to how we deal with e.g. PWMs and GPIOs in the
>> kernel, including separate includes for consumers and providers(drivers).
>>
>> 3. Some drm_connector helper functions to keep the actual changes needed
>> for this in individual KMS drivers as small as possible (patch 6).
>>
>> 4. Make the thinkpad_acpi code register a privacy-screen device on
>> ThinkPads with a privacy-screen (patches 7-8)
>>
>> 5. Make the i915 driver export the privacy-screen functionality through
>> the connector properties on the eDP connector.
> 
> Care to create a patch 10 for amdgpu?  Lenovo sells AMD thinkpads with
> a privacy screen as well, presumably it works
> the same way.

Yes the AMD based Thinkpads should work the same way.

We will need similar changes for amdgpu and very likely also for
nouveau. The problem is I don't really have hw to test this.

Do you have access to a recent thinkpad with amdgpu ? It does not need
to have a privacy screen, as long as it is new enough that the ACPI
tables have the GSSS and SSSS methods you can test by ignoring
the presence bit for the privacy-screen, I use this little change for
that:

 From 9438bababe77dfccbade5c2377bdc7d6a777a6c6 Mon Sep 17 00:00:00 2001
From: Hans de Goede <hdegoede@redhat.com>
Date: Wed, 27 May 2020 14:38:42 +0200
Subject: [PATCH] platform/x86: thinkpad_acpi: Hack to allow testing
  on devices without a privacy-screen

Hack to allow testing on devices without a privacy-screen.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
  drivers/gpu/drm/drm_privacy_screen_x86.c | 4 ++++
  drivers/platform/x86/thinkpad_acpi.c     | 4 ++--
  2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_privacy_screen_x86.c b/drivers/gpu/drm/drm_privacy_screen_x86.c
index f486d9087819..87725766a90d 100644
--- a/drivers/gpu/drm/drm_privacy_screen_x86.c
+++ b/drivers/gpu/drm/drm_privacy_screen_x86.c
@@ -41,7 +41,11 @@ static bool __init detect_thinkpad_privacy_screen(void)
  	if (ACPI_FAILURE(status))
  		return false;

+#if 1
+	return true;
+#else
  	return (output & 0x10000) ? true : false;
+#endif
  }

  static const struct arch_init_data arch_init_data[] __initconst = {
diff --git a/drivers/platform/x86/thinkpad_acpi.c b/drivers/platform/x86/thinkpad_acpi.c
index 1583c18f7f77..92aad746d1f8 100644
--- a/drivers/platform/x86/thinkpad_acpi.c
+++ b/drivers/platform/x86/thinkpad_acpi.c
@@ -9747,8 +9747,8 @@ static int tpacpi_lcdshadow_init(struct ibm_init_struct *iibm)
  	if (!acpi_evalf(lcdshadow_get_handle, &output, NULL, "dd", 0))
  		return -EIO;

-	if (!(output & 0x10000))
-		return 0;
+//	if (!(output & 0x10000))
+//		return 0;

  	lcdshadow_dev = drm_privacy_screen_register(&tpacpi_pdev->dev,
  						    &lcdshadow_ops);
-- 
2.26.2


So if you have a machine with an AMDGPU and with the mentioned ACPI methods,
then you should be able to implement this yourself. You can read/write the new
props under X11 with xrandr. And you monitor if the changes make it to the
hardware by doing:

cat /proc/acpi/ibm/lcdshadow

And you can simulate external changes (like through a hotkey handled by the embedded-controller) by doing:

echo 0 > /proc/acpi/ibm/lcdshadow
echo 1 > /proc/acpi/ibm/lcdshadow

When you do this you should see udev change events for the properties, you
can test for those by doing:

sudo udevadm monitor -u -p

###

With all that said, I can take a shot at blindly implementing this for amdgpu
but I would greatly prefer an actually tested patch, even if it is tested in
the way described above. When the patch is ready you can just send it to me
and I'll add my s-o-b and add it as patch 10 in the patch-set for the next
version.

Regards,

Hans


>> I was a bit in doubt if I should calls this series a RFC, or just call
>> it v1, since there is no real userspace code using this yet. It was
>> tested using xrandr property access and udevadm event monitoring.
>> I do expect / hope we will have patches for a userspace consumer of the
>> new properties (mutter) ready soon.
>>
>> But since the code is completely ready, including API documentation,
>> I've decided to just call this v1. Hopefully we can get patches for the
>> first userspace consumer of this ready during the review of this.
>>
>> Regards,
>>
>> Hans
>>
>> _______________________________________________
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply related	[flat|nested] 44+ messages in thread

* Re: [Intel-gfx] [PATCH 0/9] drm: Add privacy-screen class and connector properties
@ 2020-07-09 12:48     ` Hans de Goede
  0 siblings, 0 replies; 44+ messages in thread
From: Hans de Goede @ 2020-07-09 12:48 UTC (permalink / raw)
  To: Alex Deucher
  Cc: Maling list - DRI developers, Marco Trevisan, Thomas Zimmermann,
	Sebastien Bacher, David Airlie, intel-gfx, Maxime Ripard

Hi,

On 7/8/20 11:25 PM, Alex Deucher wrote:
> On Wed, Jul 8, 2020 at 12:43 PM Hans de Goede <hdegoede@redhat.com> wrote:
>>
>> Hi All,
>>
>> Here is the privacy-screen related code which we discussed a while ago.
>> This series consists of a number of different parts:
>>
>> 1. A new version of Rajat's privacy-screen connector properties patch,
>> this adds new userspace API in the form of new properties
>>
>> 2. Since on most devices the privacy screen is actually controlled by
>> some vendor specific ACPI/WMI interface which has a driver under
>> drivers/platform/x86, we need some "glue" code to make this functionality
>> available to KMS drivers. Patches 3-5 add a new privacy-screen class for
>> this, which allows non KMS drivers (and possibly KMS drivers too) to
>> register a privacy-screen device and also adds an interface for KMS drivers
>> to get access to the privacy-screen associated with a specific connector.
>> This is modelled similar to how we deal with e.g. PWMs and GPIOs in the
>> kernel, including separate includes for consumers and providers(drivers).
>>
>> 3. Some drm_connector helper functions to keep the actual changes needed
>> for this in individual KMS drivers as small as possible (patch 6).
>>
>> 4. Make the thinkpad_acpi code register a privacy-screen device on
>> ThinkPads with a privacy-screen (patches 7-8)
>>
>> 5. Make the i915 driver export the privacy-screen functionality through
>> the connector properties on the eDP connector.
> 
> Care to create a patch 10 for amdgpu?  Lenovo sells AMD thinkpads with
> a privacy screen as well, presumably it works
> the same way.

Yes the AMD based Thinkpads should work the same way.

We will need similar changes for amdgpu and very likely also for
nouveau. The problem is I don't really have hw to test this.

Do you have access to a recent thinkpad with amdgpu ? It does not need
to have a privacy screen, as long as it is new enough that the ACPI
tables have the GSSS and SSSS methods you can test by ignoring
the presence bit for the privacy-screen, I use this little change for
that:

 From 9438bababe77dfccbade5c2377bdc7d6a777a6c6 Mon Sep 17 00:00:00 2001
From: Hans de Goede <hdegoede@redhat.com>
Date: Wed, 27 May 2020 14:38:42 +0200
Subject: [PATCH] platform/x86: thinkpad_acpi: Hack to allow testing
  on devices without a privacy-screen

Hack to allow testing on devices without a privacy-screen.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
  drivers/gpu/drm/drm_privacy_screen_x86.c | 4 ++++
  drivers/platform/x86/thinkpad_acpi.c     | 4 ++--
  2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_privacy_screen_x86.c b/drivers/gpu/drm/drm_privacy_screen_x86.c
index f486d9087819..87725766a90d 100644
--- a/drivers/gpu/drm/drm_privacy_screen_x86.c
+++ b/drivers/gpu/drm/drm_privacy_screen_x86.c
@@ -41,7 +41,11 @@ static bool __init detect_thinkpad_privacy_screen(void)
  	if (ACPI_FAILURE(status))
  		return false;

+#if 1
+	return true;
+#else
  	return (output & 0x10000) ? true : false;
+#endif
  }

  static const struct arch_init_data arch_init_data[] __initconst = {
diff --git a/drivers/platform/x86/thinkpad_acpi.c b/drivers/platform/x86/thinkpad_acpi.c
index 1583c18f7f77..92aad746d1f8 100644
--- a/drivers/platform/x86/thinkpad_acpi.c
+++ b/drivers/platform/x86/thinkpad_acpi.c
@@ -9747,8 +9747,8 @@ static int tpacpi_lcdshadow_init(struct ibm_init_struct *iibm)
  	if (!acpi_evalf(lcdshadow_get_handle, &output, NULL, "dd", 0))
  		return -EIO;

-	if (!(output & 0x10000))
-		return 0;
+//	if (!(output & 0x10000))
+//		return 0;

  	lcdshadow_dev = drm_privacy_screen_register(&tpacpi_pdev->dev,
  						    &lcdshadow_ops);
-- 
2.26.2


So if you have a machine with an AMDGPU and with the mentioned ACPI methods,
then you should be able to implement this yourself. You can read/write the new
props under X11 with xrandr. And you monitor if the changes make it to the
hardware by doing:

cat /proc/acpi/ibm/lcdshadow

And you can simulate external changes (like through a hotkey handled by the embedded-controller) by doing:

echo 0 > /proc/acpi/ibm/lcdshadow
echo 1 > /proc/acpi/ibm/lcdshadow

When you do this you should see udev change events for the properties, you
can test for those by doing:

sudo udevadm monitor -u -p

###

With all that said, I can take a shot at blindly implementing this for amdgpu
but I would greatly prefer an actually tested patch, even if it is tested in
the way described above. When the patch is ready you can just send it to me
and I'll add my s-o-b and add it as patch 10 in the patch-set for the next
version.

Regards,

Hans


>> I was a bit in doubt if I should calls this series a RFC, or just call
>> it v1, since there is no real userspace code using this yet. It was
>> tested using xrandr property access and udevadm event monitoring.
>> I do expect / hope we will have patches for a userspace consumer of the
>> new properties (mutter) ready soon.
>>
>> But since the code is completely ready, including API documentation,
>> I've decided to just call this v1. Hopefully we can get patches for the
>> first userspace consumer of this ready during the review of this.
>>
>> Regards,
>>
>> Hans
>>
>> _______________________________________________
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply related	[flat|nested] 44+ messages in thread

* Re: [PATCH 0/9] drm: Add privacy-screen class and connector properties
  2020-07-09 12:48     ` [Intel-gfx] " Hans de Goede
@ 2020-07-14 15:00       ` Alex Deucher
  -1 siblings, 0 replies; 44+ messages in thread
From: Alex Deucher @ 2020-07-14 15:00 UTC (permalink / raw)
  To: Hans de Goede
  Cc: Maling list - DRI developers, Marco Trevisan, Thomas Zimmermann,
	Sebastien Bacher, David Airlie, intel-gfx, Rodrigo Vivi

On Thu, Jul 9, 2020 at 8:48 AM Hans de Goede <hdegoede@redhat.com> wrote:
>
> Hi,
>
> On 7/8/20 11:25 PM, Alex Deucher wrote:
> > On Wed, Jul 8, 2020 at 12:43 PM Hans de Goede <hdegoede@redhat.com> wrote:
> >>
> >> Hi All,
> >>
> >> Here is the privacy-screen related code which we discussed a while ago.
> >> This series consists of a number of different parts:
> >>
> >> 1. A new version of Rajat's privacy-screen connector properties patch,
> >> this adds new userspace API in the form of new properties
> >>
> >> 2. Since on most devices the privacy screen is actually controlled by
> >> some vendor specific ACPI/WMI interface which has a driver under
> >> drivers/platform/x86, we need some "glue" code to make this functionality
> >> available to KMS drivers. Patches 3-5 add a new privacy-screen class for
> >> this, which allows non KMS drivers (and possibly KMS drivers too) to
> >> register a privacy-screen device and also adds an interface for KMS drivers
> >> to get access to the privacy-screen associated with a specific connector.
> >> This is modelled similar to how we deal with e.g. PWMs and GPIOs in the
> >> kernel, including separate includes for consumers and providers(drivers).
> >>
> >> 3. Some drm_connector helper functions to keep the actual changes needed
> >> for this in individual KMS drivers as small as possible (patch 6).
> >>
> >> 4. Make the thinkpad_acpi code register a privacy-screen device on
> >> ThinkPads with a privacy-screen (patches 7-8)
> >>
> >> 5. Make the i915 driver export the privacy-screen functionality through
> >> the connector properties on the eDP connector.
> >
> > Care to create a patch 10 for amdgpu?  Lenovo sells AMD thinkpads with
> > a privacy screen as well, presumably it works
> > the same way.
>
> Yes the AMD based Thinkpads should work the same way.
>
> We will need similar changes for amdgpu and very likely also for
> nouveau. The problem is I don't really have hw to test this.
>
> Do you have access to a recent thinkpad with amdgpu ? It does not need
> to have a privacy screen, as long as it is new enough that the ACPI
> tables have the GSSS and SSSS methods you can test by ignoring
> the presence bit for the privacy-screen, I use this little change for
> that:

Thanks for the hints Hans.  If I can find some time, I will give it a try.

Alex

>
>  From 9438bababe77dfccbade5c2377bdc7d6a777a6c6 Mon Sep 17 00:00:00 2001
> From: Hans de Goede <hdegoede@redhat.com>
> Date: Wed, 27 May 2020 14:38:42 +0200
> Subject: [PATCH] platform/x86: thinkpad_acpi: Hack to allow testing
>   on devices without a privacy-screen
>
> Hack to allow testing on devices without a privacy-screen.
>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> ---
>   drivers/gpu/drm/drm_privacy_screen_x86.c | 4 ++++
>   drivers/platform/x86/thinkpad_acpi.c     | 4 ++--
>   2 files changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_privacy_screen_x86.c b/drivers/gpu/drm/drm_privacy_screen_x86.c
> index f486d9087819..87725766a90d 100644
> --- a/drivers/gpu/drm/drm_privacy_screen_x86.c
> +++ b/drivers/gpu/drm/drm_privacy_screen_x86.c
> @@ -41,7 +41,11 @@ static bool __init detect_thinkpad_privacy_screen(void)
>         if (ACPI_FAILURE(status))
>                 return false;
>
> +#if 1
> +       return true;
> +#else
>         return (output & 0x10000) ? true : false;
> +#endif
>   }
>
>   static const struct arch_init_data arch_init_data[] __initconst = {
> diff --git a/drivers/platform/x86/thinkpad_acpi.c b/drivers/platform/x86/thinkpad_acpi.c
> index 1583c18f7f77..92aad746d1f8 100644
> --- a/drivers/platform/x86/thinkpad_acpi.c
> +++ b/drivers/platform/x86/thinkpad_acpi.c
> @@ -9747,8 +9747,8 @@ static int tpacpi_lcdshadow_init(struct ibm_init_struct *iibm)
>         if (!acpi_evalf(lcdshadow_get_handle, &output, NULL, "dd", 0))
>                 return -EIO;
>
> -       if (!(output & 0x10000))
> -               return 0;
> +//     if (!(output & 0x10000))
> +//             return 0;
>
>         lcdshadow_dev = drm_privacy_screen_register(&tpacpi_pdev->dev,
>                                                     &lcdshadow_ops);
> --
> 2.26.2
>
>
> So if you have a machine with an AMDGPU and with the mentioned ACPI methods,
> then you should be able to implement this yourself. You can read/write the new
> props under X11 with xrandr. And you monitor if the changes make it to the
> hardware by doing:
>
> cat /proc/acpi/ibm/lcdshadow
>
> And you can simulate external changes (like through a hotkey handled by the embedded-controller) by doing:
>
> echo 0 > /proc/acpi/ibm/lcdshadow
> echo 1 > /proc/acpi/ibm/lcdshadow
>
> When you do this you should see udev change events for the properties, you
> can test for those by doing:
>
> sudo udevadm monitor -u -p
>
> ###
>
> With all that said, I can take a shot at blindly implementing this for amdgpu
> but I would greatly prefer an actually tested patch, even if it is tested in
> the way described above. When the patch is ready you can just send it to me
> and I'll add my s-o-b and add it as patch 10 in the patch-set for the next
> version.
>
> Regards,
>
> Hans
>
>
> >> I was a bit in doubt if I should calls this series a RFC, or just call
> >> it v1, since there is no real userspace code using this yet. It was
> >> tested using xrandr property access and udevadm event monitoring.
> >> I do expect / hope we will have patches for a userspace consumer of the
> >> new properties (mutter) ready soon.
> >>
> >> But since the code is completely ready, including API documentation,
> >> I've decided to just call this v1. Hopefully we can get patches for the
> >> first userspace consumer of this ready during the review of this.
> >>
> >> Regards,
> >>
> >> Hans
> >>
> >> _______________________________________________
> >> dri-devel mailing list
> >> dri-devel@lists.freedesktop.org
> >> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> >
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [Intel-gfx] [PATCH 0/9] drm: Add privacy-screen class and connector properties
@ 2020-07-14 15:00       ` Alex Deucher
  0 siblings, 0 replies; 44+ messages in thread
From: Alex Deucher @ 2020-07-14 15:00 UTC (permalink / raw)
  To: Hans de Goede
  Cc: Maling list - DRI developers, Marco Trevisan, Thomas Zimmermann,
	Sebastien Bacher, David Airlie, intel-gfx, Maxime Ripard

On Thu, Jul 9, 2020 at 8:48 AM Hans de Goede <hdegoede@redhat.com> wrote:
>
> Hi,
>
> On 7/8/20 11:25 PM, Alex Deucher wrote:
> > On Wed, Jul 8, 2020 at 12:43 PM Hans de Goede <hdegoede@redhat.com> wrote:
> >>
> >> Hi All,
> >>
> >> Here is the privacy-screen related code which we discussed a while ago.
> >> This series consists of a number of different parts:
> >>
> >> 1. A new version of Rajat's privacy-screen connector properties patch,
> >> this adds new userspace API in the form of new properties
> >>
> >> 2. Since on most devices the privacy screen is actually controlled by
> >> some vendor specific ACPI/WMI interface which has a driver under
> >> drivers/platform/x86, we need some "glue" code to make this functionality
> >> available to KMS drivers. Patches 3-5 add a new privacy-screen class for
> >> this, which allows non KMS drivers (and possibly KMS drivers too) to
> >> register a privacy-screen device and also adds an interface for KMS drivers
> >> to get access to the privacy-screen associated with a specific connector.
> >> This is modelled similar to how we deal with e.g. PWMs and GPIOs in the
> >> kernel, including separate includes for consumers and providers(drivers).
> >>
> >> 3. Some drm_connector helper functions to keep the actual changes needed
> >> for this in individual KMS drivers as small as possible (patch 6).
> >>
> >> 4. Make the thinkpad_acpi code register a privacy-screen device on
> >> ThinkPads with a privacy-screen (patches 7-8)
> >>
> >> 5. Make the i915 driver export the privacy-screen functionality through
> >> the connector properties on the eDP connector.
> >
> > Care to create a patch 10 for amdgpu?  Lenovo sells AMD thinkpads with
> > a privacy screen as well, presumably it works
> > the same way.
>
> Yes the AMD based Thinkpads should work the same way.
>
> We will need similar changes for amdgpu and very likely also for
> nouveau. The problem is I don't really have hw to test this.
>
> Do you have access to a recent thinkpad with amdgpu ? It does not need
> to have a privacy screen, as long as it is new enough that the ACPI
> tables have the GSSS and SSSS methods you can test by ignoring
> the presence bit for the privacy-screen, I use this little change for
> that:

Thanks for the hints Hans.  If I can find some time, I will give it a try.

Alex

>
>  From 9438bababe77dfccbade5c2377bdc7d6a777a6c6 Mon Sep 17 00:00:00 2001
> From: Hans de Goede <hdegoede@redhat.com>
> Date: Wed, 27 May 2020 14:38:42 +0200
> Subject: [PATCH] platform/x86: thinkpad_acpi: Hack to allow testing
>   on devices without a privacy-screen
>
> Hack to allow testing on devices without a privacy-screen.
>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> ---
>   drivers/gpu/drm/drm_privacy_screen_x86.c | 4 ++++
>   drivers/platform/x86/thinkpad_acpi.c     | 4 ++--
>   2 files changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_privacy_screen_x86.c b/drivers/gpu/drm/drm_privacy_screen_x86.c
> index f486d9087819..87725766a90d 100644
> --- a/drivers/gpu/drm/drm_privacy_screen_x86.c
> +++ b/drivers/gpu/drm/drm_privacy_screen_x86.c
> @@ -41,7 +41,11 @@ static bool __init detect_thinkpad_privacy_screen(void)
>         if (ACPI_FAILURE(status))
>                 return false;
>
> +#if 1
> +       return true;
> +#else
>         return (output & 0x10000) ? true : false;
> +#endif
>   }
>
>   static const struct arch_init_data arch_init_data[] __initconst = {
> diff --git a/drivers/platform/x86/thinkpad_acpi.c b/drivers/platform/x86/thinkpad_acpi.c
> index 1583c18f7f77..92aad746d1f8 100644
> --- a/drivers/platform/x86/thinkpad_acpi.c
> +++ b/drivers/platform/x86/thinkpad_acpi.c
> @@ -9747,8 +9747,8 @@ static int tpacpi_lcdshadow_init(struct ibm_init_struct *iibm)
>         if (!acpi_evalf(lcdshadow_get_handle, &output, NULL, "dd", 0))
>                 return -EIO;
>
> -       if (!(output & 0x10000))
> -               return 0;
> +//     if (!(output & 0x10000))
> +//             return 0;
>
>         lcdshadow_dev = drm_privacy_screen_register(&tpacpi_pdev->dev,
>                                                     &lcdshadow_ops);
> --
> 2.26.2
>
>
> So if you have a machine with an AMDGPU and with the mentioned ACPI methods,
> then you should be able to implement this yourself. You can read/write the new
> props under X11 with xrandr. And you monitor if the changes make it to the
> hardware by doing:
>
> cat /proc/acpi/ibm/lcdshadow
>
> And you can simulate external changes (like through a hotkey handled by the embedded-controller) by doing:
>
> echo 0 > /proc/acpi/ibm/lcdshadow
> echo 1 > /proc/acpi/ibm/lcdshadow
>
> When you do this you should see udev change events for the properties, you
> can test for those by doing:
>
> sudo udevadm monitor -u -p
>
> ###
>
> With all that said, I can take a shot at blindly implementing this for amdgpu
> but I would greatly prefer an actually tested patch, even if it is tested in
> the way described above. When the patch is ready you can just send it to me
> and I'll add my s-o-b and add it as patch 10 in the patch-set for the next
> version.
>
> Regards,
>
> Hans
>
>
> >> I was a bit in doubt if I should calls this series a RFC, or just call
> >> it v1, since there is no real userspace code using this yet. It was
> >> tested using xrandr property access and udevadm event monitoring.
> >> I do expect / hope we will have patches for a userspace consumer of the
> >> new properties (mutter) ready soon.
> >>
> >> But since the code is completely ready, including API documentation,
> >> I've decided to just call this v1. Hopefully we can get patches for the
> >> first userspace consumer of this ready during the review of this.
> >>
> >> Regards,
> >>
> >> Hans
> >>
> >> _______________________________________________
> >> dri-devel mailing list
> >> dri-devel@lists.freedesktop.org
> >> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> >
>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [PATCH 0/9] drm: Add privacy-screen class and connector properties
  2021-09-16  9:30   ` Hans de Goede
@ 2021-09-16 10:14     ` Jani Nikula
  0 siblings, 0 replies; 44+ messages in thread
From: Jani Nikula @ 2021-09-16 10:14 UTC (permalink / raw)
  To: Hans de Goede, Lyude Paul, Maarten Lankhorst, Maxime Ripard,
	Thomas Zimmermann, Rajat Jain, Joonas Lahtinen, Rodrigo Vivi,
	Mark Gross, Andy Shevchenko
  Cc: Daniel Vetter, David Airlie, Pekka Paalanen, Mario Limonciello,
	Mark Pearson, Sebastien Bacher, Marco Trevisan, Emil Velikov,
	intel-gfx, dri-devel, platform-driver-x86

On Thu, 16 Sep 2021, Hans de Goede <hdegoede@redhat.com> wrote:
> Hi,
>
> On 9/15/21 11:12 PM, Lyude Paul wrote:
>> OK! Looked over all of these patches. Patches 2 and 4 have some comments that
>> should be addressed, but otherwise this series is:
>> 
>> Reviewed-by: Lyude Paul <lyude@redhat.com>
>
> Thank you!
>
>> Let me know when/if you need help pushing this upstream
>
> My plan was to just straight forward push the entire series to
> drm-misc-next. The only non drm bits are the drivers/platform/x86/thinkpad_acpi.c
> changes and I'm the drivers/platform/x86 subsys-maintainer and this
> plan has my blessing :)
>
> That only leaves the last patch in the series:
> "drm/i915: Add privacy-screen support" 
>
> As something which could potentially be troublesome. I can also
> leave that out, while pushing the test to drm-misc-next and then
> push the i915 patch after a drm-misc-next merge into drm-intel-next.
>
> Jani, how would you like to handle the single i915 patch in this
> series?

I think it's easiest to merge that via the same route as everything else
goes. It's a fairly small patch with not that much conflict potential.

That said, there are some issues in that patch I think still need
addressing. I've commented on the patch. I don't mind you pushing the
rest already, unless you think addressing the issues is easier by
modifying the other patches (I don't think so).


BR,
Jani.

>
> Regards,
>
> Hans
>
>
>
>
>
>> 
>> On Mon, 2021-09-06 at 09:35 +0200, Hans de Goede wrote:
>>> Hi all,
>>>
>>> Here is the privacy-screen related code which I last posted in April 2021
>>> To the best of my knowledge there is consensus about / everyone is in
>>> agreement with the new userspace API (2 connector properties) this
>>> patch-set add (patch 1 of the series).
>>>
>>> This is unchanged (except for a rebase on drm-tip), what has changed is
>>> that the first userspace consumer of the new properties is now fully ready
>>> for merging (it is just waiting for the kernel bits to land first):
>>>
>>>  -
>>> https://gitlab.gnome.org/GNOME/gsettings-desktop-schemas/-/merge_requests/49
>>>  - https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1952
>>>  - https://gitlab.gnome.org/GNOME/gnome-control-center/-/merge_requests/1032
>>>
>>> Having a userspace-consumer of the API fully ready for merging, clears the
>>> last blocker for this series. It has already has been reviewed before
>>> by Emil Velikov, but it could really do with another review.
>>>
>>> The new API works as designed and add the following features to GNOME:
>>>
>>> 1. Showing an OSD notification when the privacy-screen is toggled on/off
>>>    through hotkeys handled by the embedded-controller
>>> 2. Allowing control of the privacy-screen from the GNOME control-panel,
>>>    including the on/off slider shown there updating to match the hw-setting
>>>    when the setting is changed with the control-panel open.
>>> 3. Restoring the last user-setting at login
>>>
>>> This series consists of a number of different parts:
>>>
>>> 1. A new version of Rajat's privacy-screen connector properties patch,
>>> this adds new userspace API in the form of new properties
>>>
>>> 2. Since on most devices the privacy screen is actually controlled by
>>> some vendor specific ACPI/WMI interface which has a driver under
>>> drivers/platform/x86, we need some "glue" code to make this functionality
>>> available to KMS drivers. Patches 2-4 add a new privacy-screen class for
>>> this, which allows non KMS drivers (and possibly KMS drivers too) to
>>> register a privacy-screen device and also adds an interface for KMS drivers
>>> to get access to the privacy-screen associated with a specific connector.
>>> This is modelled similar to how we deal with e.g. PWMs and GPIOs in the
>>> kernel, including separate includes for consumers and providers(drivers).
>>>
>>> 3. Some drm_connector helper functions to keep the actual changes needed
>>> for this in individual KMS drivers as small as possible (patch 5).
>>>
>>> 4. Make the thinkpad_acpi code register a privacy-screen device on
>>> ThinkPads with a privacy-screen (patches 6-8)
>>>
>>> 5. Make the i915 driver export the privacy-screen functionality through
>>> the connector properties on the eDP connector.
>>>
>>> I believe that it would be best to merge the entire series, including
>>> the thinkpad_acpi changes through drm-misc in one go. As the pdx86
>>> subsys maintainer I hereby give my ack for merging the thinkpad_acpi
>>> changes through drm-misc.
>>>
>>> There is one small caveat with this series, which it is good to be
>>> aware of. The i915 driver will now return -EPROBE_DEFER on Thinkpads
>>> with an eprivacy screen, until the thinkpad_acpi driver is loaded.
>>> This means that initrd generation tools will need to be updated to
>>> include thinkpad_acpi when the i915 driver is added to the initrd.
>>> Without this the loading of the i915 driver will be delayed to after
>>> the switch to real rootfs.
>>>
>>> Regards,
>>>
>>> Hans
>>>
>>>
>>> Hans de Goede (8):
>>>   drm: Add privacy-screen class (v3)
>>>   drm/privacy-screen: Add X86 specific arch init code
>>>   drm/privacy-screen: Add notifier support
>>>   drm/connector: Add a drm_connector privacy-screen helper functions
>>>   platform/x86: thinkpad_acpi: Add hotkey_notify_extended_hotkey()
>>>     helper
>>>   platform/x86: thinkpad_acpi: Get privacy-screen / lcdshadow ACPI
>>>     handles only once
>>>   platform/x86: thinkpad_acpi: Register a privacy-screen device
>>>   drm/i915: Add privacy-screen support
>>>
>>> Rajat Jain (1):
>>>   drm/connector: Add support for privacy-screen properties (v4)
>>>
>>>  Documentation/gpu/drm-kms-helpers.rst        |  15 +
>>>  Documentation/gpu/drm-kms.rst                |   2 +
>>>  MAINTAINERS                                  |   8 +
>>>  drivers/gpu/drm/Kconfig                      |   4 +
>>>  drivers/gpu/drm/Makefile                     |   1 +
>>>  drivers/gpu/drm/drm_atomic_uapi.c            |   4 +
>>>  drivers/gpu/drm/drm_connector.c              | 214 +++++++++
>>>  drivers/gpu/drm/drm_drv.c                    |   4 +
>>>  drivers/gpu/drm/drm_privacy_screen.c         | 468 +++++++++++++++++++
>>>  drivers/gpu/drm/drm_privacy_screen_x86.c     |  86 ++++
>>>  drivers/gpu/drm/i915/display/intel_display.c |   5 +
>>>  drivers/gpu/drm/i915/display/intel_dp.c      |  10 +
>>>  drivers/gpu/drm/i915/i915_pci.c              |  12 +
>>>  drivers/platform/x86/Kconfig                 |   2 +
>>>  drivers/platform/x86/thinkpad_acpi.c         | 131 ++++--
>>>  include/drm/drm_connector.h                  |  56 +++
>>>  include/drm/drm_privacy_screen_consumer.h    |  65 +++
>>>  include/drm/drm_privacy_screen_driver.h      |  84 ++++
>>>  include/drm/drm_privacy_screen_machine.h     |  46 ++
>>>  19 files changed, 1175 insertions(+), 42 deletions(-)
>>>  create mode 100644 drivers/gpu/drm/drm_privacy_screen.c
>>>  create mode 100644 drivers/gpu/drm/drm_privacy_screen_x86.c
>>>  create mode 100644 include/drm/drm_privacy_screen_consumer.h
>>>  create mode 100644 include/drm/drm_privacy_screen_driver.h
>>>  create mode 100644 include/drm/drm_privacy_screen_machine.h
>>>
>> 
>

-- 
Jani Nikula, Intel Open Source Graphics Center

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [PATCH 0/9] drm: Add privacy-screen class and connector properties
  2021-09-15 21:12   ` Lyude Paul
  (?)
@ 2021-09-16  9:30   ` Hans de Goede
  2021-09-16 10:14     ` Jani Nikula
  -1 siblings, 1 reply; 44+ messages in thread
From: Hans de Goede @ 2021-09-16  9:30 UTC (permalink / raw)
  To: Lyude Paul, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
	Rajat Jain, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi,
	Mark Gross, Andy Shevchenko
  Cc: Daniel Vetter, David Airlie, Pekka Paalanen, Mario Limonciello,
	Mark Pearson, Sebastien Bacher, Marco Trevisan, Emil Velikov,
	intel-gfx, dri-devel, platform-driver-x86

Hi,

On 9/15/21 11:12 PM, Lyude Paul wrote:
> OK! Looked over all of these patches. Patches 2 and 4 have some comments that
> should be addressed, but otherwise this series is:
> 
> Reviewed-by: Lyude Paul <lyude@redhat.com>

Thank you!

> Let me know when/if you need help pushing this upstream

My plan was to just straight forward push the entire series to
drm-misc-next. The only non drm bits are the drivers/platform/x86/thinkpad_acpi.c
changes and I'm the drivers/platform/x86 subsys-maintainer and this
plan has my blessing :)

That only leaves the last patch in the series:
"drm/i915: Add privacy-screen support" 

As something which could potentially be troublesome. I can also
leave that out, while pushing the test to drm-misc-next and then
push the i915 patch after a drm-misc-next merge into drm-intel-next.

Jani, how would you like to handle the single i915 patch in this
series?

Regards,

Hans





> 
> On Mon, 2021-09-06 at 09:35 +0200, Hans de Goede wrote:
>> Hi all,
>>
>> Here is the privacy-screen related code which I last posted in April 2021
>> To the best of my knowledge there is consensus about / everyone is in
>> agreement with the new userspace API (2 connector properties) this
>> patch-set add (patch 1 of the series).
>>
>> This is unchanged (except for a rebase on drm-tip), what has changed is
>> that the first userspace consumer of the new properties is now fully ready
>> for merging (it is just waiting for the kernel bits to land first):
>>
>>  -
>> https://gitlab.gnome.org/GNOME/gsettings-desktop-schemas/-/merge_requests/49
>>  - https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1952
>>  - https://gitlab.gnome.org/GNOME/gnome-control-center/-/merge_requests/1032
>>
>> Having a userspace-consumer of the API fully ready for merging, clears the
>> last blocker for this series. It has already has been reviewed before
>> by Emil Velikov, but it could really do with another review.
>>
>> The new API works as designed and add the following features to GNOME:
>>
>> 1. Showing an OSD notification when the privacy-screen is toggled on/off
>>    through hotkeys handled by the embedded-controller
>> 2. Allowing control of the privacy-screen from the GNOME control-panel,
>>    including the on/off slider shown there updating to match the hw-setting
>>    when the setting is changed with the control-panel open.
>> 3. Restoring the last user-setting at login
>>
>> This series consists of a number of different parts:
>>
>> 1. A new version of Rajat's privacy-screen connector properties patch,
>> this adds new userspace API in the form of new properties
>>
>> 2. Since on most devices the privacy screen is actually controlled by
>> some vendor specific ACPI/WMI interface which has a driver under
>> drivers/platform/x86, we need some "glue" code to make this functionality
>> available to KMS drivers. Patches 2-4 add a new privacy-screen class for
>> this, which allows non KMS drivers (and possibly KMS drivers too) to
>> register a privacy-screen device and also adds an interface for KMS drivers
>> to get access to the privacy-screen associated with a specific connector.
>> This is modelled similar to how we deal with e.g. PWMs and GPIOs in the
>> kernel, including separate includes for consumers and providers(drivers).
>>
>> 3. Some drm_connector helper functions to keep the actual changes needed
>> for this in individual KMS drivers as small as possible (patch 5).
>>
>> 4. Make the thinkpad_acpi code register a privacy-screen device on
>> ThinkPads with a privacy-screen (patches 6-8)
>>
>> 5. Make the i915 driver export the privacy-screen functionality through
>> the connector properties on the eDP connector.
>>
>> I believe that it would be best to merge the entire series, including
>> the thinkpad_acpi changes through drm-misc in one go. As the pdx86
>> subsys maintainer I hereby give my ack for merging the thinkpad_acpi
>> changes through drm-misc.
>>
>> There is one small caveat with this series, which it is good to be
>> aware of. The i915 driver will now return -EPROBE_DEFER on Thinkpads
>> with an eprivacy screen, until the thinkpad_acpi driver is loaded.
>> This means that initrd generation tools will need to be updated to
>> include thinkpad_acpi when the i915 driver is added to the initrd.
>> Without this the loading of the i915 driver will be delayed to after
>> the switch to real rootfs.
>>
>> Regards,
>>
>> Hans
>>
>>
>> Hans de Goede (8):
>>   drm: Add privacy-screen class (v3)
>>   drm/privacy-screen: Add X86 specific arch init code
>>   drm/privacy-screen: Add notifier support
>>   drm/connector: Add a drm_connector privacy-screen helper functions
>>   platform/x86: thinkpad_acpi: Add hotkey_notify_extended_hotkey()
>>     helper
>>   platform/x86: thinkpad_acpi: Get privacy-screen / lcdshadow ACPI
>>     handles only once
>>   platform/x86: thinkpad_acpi: Register a privacy-screen device
>>   drm/i915: Add privacy-screen support
>>
>> Rajat Jain (1):
>>   drm/connector: Add support for privacy-screen properties (v4)
>>
>>  Documentation/gpu/drm-kms-helpers.rst        |  15 +
>>  Documentation/gpu/drm-kms.rst                |   2 +
>>  MAINTAINERS                                  |   8 +
>>  drivers/gpu/drm/Kconfig                      |   4 +
>>  drivers/gpu/drm/Makefile                     |   1 +
>>  drivers/gpu/drm/drm_atomic_uapi.c            |   4 +
>>  drivers/gpu/drm/drm_connector.c              | 214 +++++++++
>>  drivers/gpu/drm/drm_drv.c                    |   4 +
>>  drivers/gpu/drm/drm_privacy_screen.c         | 468 +++++++++++++++++++
>>  drivers/gpu/drm/drm_privacy_screen_x86.c     |  86 ++++
>>  drivers/gpu/drm/i915/display/intel_display.c |   5 +
>>  drivers/gpu/drm/i915/display/intel_dp.c      |  10 +
>>  drivers/gpu/drm/i915/i915_pci.c              |  12 +
>>  drivers/platform/x86/Kconfig                 |   2 +
>>  drivers/platform/x86/thinkpad_acpi.c         | 131 ++++--
>>  include/drm/drm_connector.h                  |  56 +++
>>  include/drm/drm_privacy_screen_consumer.h    |  65 +++
>>  include/drm/drm_privacy_screen_driver.h      |  84 ++++
>>  include/drm/drm_privacy_screen_machine.h     |  46 ++
>>  19 files changed, 1175 insertions(+), 42 deletions(-)
>>  create mode 100644 drivers/gpu/drm/drm_privacy_screen.c
>>  create mode 100644 drivers/gpu/drm/drm_privacy_screen_x86.c
>>  create mode 100644 include/drm/drm_privacy_screen_consumer.h
>>  create mode 100644 include/drm/drm_privacy_screen_driver.h
>>  create mode 100644 include/drm/drm_privacy_screen_machine.h
>>
> 


^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [PATCH 0/9] drm: Add privacy-screen class and connector properties
  2021-09-06  7:35 Hans de Goede
@ 2021-09-15 21:12   ` Lyude Paul
  0 siblings, 0 replies; 44+ messages in thread
From: Lyude Paul @ 2021-09-15 21:12 UTC (permalink / raw)
  To: Hans de Goede, Maarten Lankhorst, Maxime Ripard,
	Thomas Zimmermann, Rajat Jain, Jani Nikula, Joonas Lahtinen,
	Rodrigo Vivi, Mark Gross, Andy Shevchenko
  Cc: Daniel Vetter, David Airlie, Pekka Paalanen, Mario Limonciello,
	Mark Pearson, Sebastien Bacher, Marco Trevisan, Emil Velikov,
	intel-gfx, dri-devel, platform-driver-x86

OK! Looked over all of these patches. Patches 2 and 4 have some comments that
should be addressed, but otherwise this series is:

Reviewed-by: Lyude Paul <lyude@redhat.com>

Let me know when/if you need help pushing this upstream

On Mon, 2021-09-06 at 09:35 +0200, Hans de Goede wrote:
> Hi all,
> 
> Here is the privacy-screen related code which I last posted in April 2021
> To the best of my knowledge there is consensus about / everyone is in
> agreement with the new userspace API (2 connector properties) this
> patch-set add (patch 1 of the series).
> 
> This is unchanged (except for a rebase on drm-tip), what has changed is
> that the first userspace consumer of the new properties is now fully ready
> for merging (it is just waiting for the kernel bits to land first):
> 
>  -
> https://gitlab.gnome.org/GNOME/gsettings-desktop-schemas/-/merge_requests/49
>  - https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1952
>  - https://gitlab.gnome.org/GNOME/gnome-control-center/-/merge_requests/1032
> 
> Having a userspace-consumer of the API fully ready for merging, clears the
> last blocker for this series. It has already has been reviewed before
> by Emil Velikov, but it could really do with another review.
> 
> The new API works as designed and add the following features to GNOME:
> 
> 1. Showing an OSD notification when the privacy-screen is toggled on/off
>    through hotkeys handled by the embedded-controller
> 2. Allowing control of the privacy-screen from the GNOME control-panel,
>    including the on/off slider shown there updating to match the hw-setting
>    when the setting is changed with the control-panel open.
> 3. Restoring the last user-setting at login
> 
> This series consists of a number of different parts:
> 
> 1. A new version of Rajat's privacy-screen connector properties patch,
> this adds new userspace API in the form of new properties
> 
> 2. Since on most devices the privacy screen is actually controlled by
> some vendor specific ACPI/WMI interface which has a driver under
> drivers/platform/x86, we need some "glue" code to make this functionality
> available to KMS drivers. Patches 2-4 add a new privacy-screen class for
> this, which allows non KMS drivers (and possibly KMS drivers too) to
> register a privacy-screen device and also adds an interface for KMS drivers
> to get access to the privacy-screen associated with a specific connector.
> This is modelled similar to how we deal with e.g. PWMs and GPIOs in the
> kernel, including separate includes for consumers and providers(drivers).
> 
> 3. Some drm_connector helper functions to keep the actual changes needed
> for this in individual KMS drivers as small as possible (patch 5).
> 
> 4. Make the thinkpad_acpi code register a privacy-screen device on
> ThinkPads with a privacy-screen (patches 6-8)
> 
> 5. Make the i915 driver export the privacy-screen functionality through
> the connector properties on the eDP connector.
> 
> I believe that it would be best to merge the entire series, including
> the thinkpad_acpi changes through drm-misc in one go. As the pdx86
> subsys maintainer I hereby give my ack for merging the thinkpad_acpi
> changes through drm-misc.
> 
> There is one small caveat with this series, which it is good to be
> aware of. The i915 driver will now return -EPROBE_DEFER on Thinkpads
> with an eprivacy screen, until the thinkpad_acpi driver is loaded.
> This means that initrd generation tools will need to be updated to
> include thinkpad_acpi when the i915 driver is added to the initrd.
> Without this the loading of the i915 driver will be delayed to after
> the switch to real rootfs.
> 
> Regards,
> 
> Hans
> 
> 
> Hans de Goede (8):
>   drm: Add privacy-screen class (v3)
>   drm/privacy-screen: Add X86 specific arch init code
>   drm/privacy-screen: Add notifier support
>   drm/connector: Add a drm_connector privacy-screen helper functions
>   platform/x86: thinkpad_acpi: Add hotkey_notify_extended_hotkey()
>     helper
>   platform/x86: thinkpad_acpi: Get privacy-screen / lcdshadow ACPI
>     handles only once
>   platform/x86: thinkpad_acpi: Register a privacy-screen device
>   drm/i915: Add privacy-screen support
> 
> Rajat Jain (1):
>   drm/connector: Add support for privacy-screen properties (v4)
> 
>  Documentation/gpu/drm-kms-helpers.rst        |  15 +
>  Documentation/gpu/drm-kms.rst                |   2 +
>  MAINTAINERS                                  |   8 +
>  drivers/gpu/drm/Kconfig                      |   4 +
>  drivers/gpu/drm/Makefile                     |   1 +
>  drivers/gpu/drm/drm_atomic_uapi.c            |   4 +
>  drivers/gpu/drm/drm_connector.c              | 214 +++++++++
>  drivers/gpu/drm/drm_drv.c                    |   4 +
>  drivers/gpu/drm/drm_privacy_screen.c         | 468 +++++++++++++++++++
>  drivers/gpu/drm/drm_privacy_screen_x86.c     |  86 ++++
>  drivers/gpu/drm/i915/display/intel_display.c |   5 +
>  drivers/gpu/drm/i915/display/intel_dp.c      |  10 +
>  drivers/gpu/drm/i915/i915_pci.c              |  12 +
>  drivers/platform/x86/Kconfig                 |   2 +
>  drivers/platform/x86/thinkpad_acpi.c         | 131 ++++--
>  include/drm/drm_connector.h                  |  56 +++
>  include/drm/drm_privacy_screen_consumer.h    |  65 +++
>  include/drm/drm_privacy_screen_driver.h      |  84 ++++
>  include/drm/drm_privacy_screen_machine.h     |  46 ++
>  19 files changed, 1175 insertions(+), 42 deletions(-)
>  create mode 100644 drivers/gpu/drm/drm_privacy_screen.c
>  create mode 100644 drivers/gpu/drm/drm_privacy_screen_x86.c
>  create mode 100644 include/drm/drm_privacy_screen_consumer.h
>  create mode 100644 include/drm/drm_privacy_screen_driver.h
>  create mode 100644 include/drm/drm_privacy_screen_machine.h
> 

-- 
Cheers,
 Lyude Paul (she/her)
 Software Engineer at Red Hat


^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [PATCH 0/9] drm: Add privacy-screen class and connector properties
@ 2021-09-15 21:12   ` Lyude Paul
  0 siblings, 0 replies; 44+ messages in thread
From: Lyude Paul @ 2021-09-15 21:12 UTC (permalink / raw)
  To: Hans de Goede, Maarten Lankhorst, Maxime Ripard,
	Thomas Zimmermann, Rajat Jain, Jani Nikula, Joonas Lahtinen,
	Rodrigo Vivi, Mark Gross, Andy Shevchenko
  Cc: Daniel Vetter, David Airlie, Pekka Paalanen, Mario Limonciello,
	Mark Pearson, Sebastien Bacher, Marco Trevisan, Emil Velikov,
	intel-gfx, dri-devel, platform-driver-x86

OK! Looked over all of these patches. Patches 2 and 4 have some comments that
should be addressed, but otherwise this series is:

Reviewed-by: Lyude Paul <lyude@redhat.com>

Let me know when/if you need help pushing this upstream

On Mon, 2021-09-06 at 09:35 +0200, Hans de Goede wrote:
> Hi all,
> 
> Here is the privacy-screen related code which I last posted in April 2021
> To the best of my knowledge there is consensus about / everyone is in
> agreement with the new userspace API (2 connector properties) this
> patch-set add (patch 1 of the series).
> 
> This is unchanged (except for a rebase on drm-tip), what has changed is
> that the first userspace consumer of the new properties is now fully ready
> for merging (it is just waiting for the kernel bits to land first):
> 
>  -
> https://gitlab.gnome.org/GNOME/gsettings-desktop-schemas/-/merge_requests/49
>  - https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1952
>  - https://gitlab.gnome.org/GNOME/gnome-control-center/-/merge_requests/1032
> 
> Having a userspace-consumer of the API fully ready for merging, clears the
> last blocker for this series. It has already has been reviewed before
> by Emil Velikov, but it could really do with another review.
> 
> The new API works as designed and add the following features to GNOME:
> 
> 1. Showing an OSD notification when the privacy-screen is toggled on/off
>    through hotkeys handled by the embedded-controller
> 2. Allowing control of the privacy-screen from the GNOME control-panel,
>    including the on/off slider shown there updating to match the hw-setting
>    when the setting is changed with the control-panel open.
> 3. Restoring the last user-setting at login
> 
> This series consists of a number of different parts:
> 
> 1. A new version of Rajat's privacy-screen connector properties patch,
> this adds new userspace API in the form of new properties
> 
> 2. Since on most devices the privacy screen is actually controlled by
> some vendor specific ACPI/WMI interface which has a driver under
> drivers/platform/x86, we need some "glue" code to make this functionality
> available to KMS drivers. Patches 2-4 add a new privacy-screen class for
> this, which allows non KMS drivers (and possibly KMS drivers too) to
> register a privacy-screen device and also adds an interface for KMS drivers
> to get access to the privacy-screen associated with a specific connector.
> This is modelled similar to how we deal with e.g. PWMs and GPIOs in the
> kernel, including separate includes for consumers and providers(drivers).
> 
> 3. Some drm_connector helper functions to keep the actual changes needed
> for this in individual KMS drivers as small as possible (patch 5).
> 
> 4. Make the thinkpad_acpi code register a privacy-screen device on
> ThinkPads with a privacy-screen (patches 6-8)
> 
> 5. Make the i915 driver export the privacy-screen functionality through
> the connector properties on the eDP connector.
> 
> I believe that it would be best to merge the entire series, including
> the thinkpad_acpi changes through drm-misc in one go. As the pdx86
> subsys maintainer I hereby give my ack for merging the thinkpad_acpi
> changes through drm-misc.
> 
> There is one small caveat with this series, which it is good to be
> aware of. The i915 driver will now return -EPROBE_DEFER on Thinkpads
> with an eprivacy screen, until the thinkpad_acpi driver is loaded.
> This means that initrd generation tools will need to be updated to
> include thinkpad_acpi when the i915 driver is added to the initrd.
> Without this the loading of the i915 driver will be delayed to after
> the switch to real rootfs.
> 
> Regards,
> 
> Hans
> 
> 
> Hans de Goede (8):
>   drm: Add privacy-screen class (v3)
>   drm/privacy-screen: Add X86 specific arch init code
>   drm/privacy-screen: Add notifier support
>   drm/connector: Add a drm_connector privacy-screen helper functions
>   platform/x86: thinkpad_acpi: Add hotkey_notify_extended_hotkey()
>     helper
>   platform/x86: thinkpad_acpi: Get privacy-screen / lcdshadow ACPI
>     handles only once
>   platform/x86: thinkpad_acpi: Register a privacy-screen device
>   drm/i915: Add privacy-screen support
> 
> Rajat Jain (1):
>   drm/connector: Add support for privacy-screen properties (v4)
> 
>  Documentation/gpu/drm-kms-helpers.rst        |  15 +
>  Documentation/gpu/drm-kms.rst                |   2 +
>  MAINTAINERS                                  |   8 +
>  drivers/gpu/drm/Kconfig                      |   4 +
>  drivers/gpu/drm/Makefile                     |   1 +
>  drivers/gpu/drm/drm_atomic_uapi.c            |   4 +
>  drivers/gpu/drm/drm_connector.c              | 214 +++++++++
>  drivers/gpu/drm/drm_drv.c                    |   4 +
>  drivers/gpu/drm/drm_privacy_screen.c         | 468 +++++++++++++++++++
>  drivers/gpu/drm/drm_privacy_screen_x86.c     |  86 ++++
>  drivers/gpu/drm/i915/display/intel_display.c |   5 +
>  drivers/gpu/drm/i915/display/intel_dp.c      |  10 +
>  drivers/gpu/drm/i915/i915_pci.c              |  12 +
>  drivers/platform/x86/Kconfig                 |   2 +
>  drivers/platform/x86/thinkpad_acpi.c         | 131 ++++--
>  include/drm/drm_connector.h                  |  56 +++
>  include/drm/drm_privacy_screen_consumer.h    |  65 +++
>  include/drm/drm_privacy_screen_driver.h      |  84 ++++
>  include/drm/drm_privacy_screen_machine.h     |  46 ++
>  19 files changed, 1175 insertions(+), 42 deletions(-)
>  create mode 100644 drivers/gpu/drm/drm_privacy_screen.c
>  create mode 100644 drivers/gpu/drm/drm_privacy_screen_x86.c
>  create mode 100644 include/drm/drm_privacy_screen_consumer.h
>  create mode 100644 include/drm/drm_privacy_screen_driver.h
>  create mode 100644 include/drm/drm_privacy_screen_machine.h
> 

-- 
Cheers,
 Lyude Paul (she/her)
 Software Engineer at Red Hat


^ permalink raw reply	[flat|nested] 44+ messages in thread

* [PATCH 0/9] drm: Add privacy-screen class and connector properties
@ 2021-09-06  7:35 Hans de Goede
  2021-09-15 21:12   ` Lyude Paul
  0 siblings, 1 reply; 44+ messages in thread
From: Hans de Goede @ 2021-09-06  7:35 UTC (permalink / raw)
  To: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rajat Jain,
	Jani Nikula, Lyude, Joonas Lahtinen, Rodrigo Vivi, Mark Gross,
	Andy Shevchenko
  Cc: Hans de Goede, Daniel Vetter, David Airlie, Pekka Paalanen,
	Mario Limonciello, Mark Pearson, Sebastien Bacher,
	Marco Trevisan, Emil Velikov, intel-gfx, dri-devel,
	platform-driver-x86

Hi all,

Here is the privacy-screen related code which I last posted in April 2021
To the best of my knowledge there is consensus about / everyone is in
agreement with the new userspace API (2 connector properties) this
patch-set add (patch 1 of the series).

This is unchanged (except for a rebase on drm-tip), what has changed is
that the first userspace consumer of the new properties is now fully ready
for merging (it is just waiting for the kernel bits to land first):

 - https://gitlab.gnome.org/GNOME/gsettings-desktop-schemas/-/merge_requests/49
 - https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1952
 - https://gitlab.gnome.org/GNOME/gnome-control-center/-/merge_requests/1032

Having a userspace-consumer of the API fully ready for merging, clears the
last blocker for this series. It has already has been reviewed before
by Emil Velikov, but it could really do with another review.

The new API works as designed and add the following features to GNOME:

1. Showing an OSD notification when the privacy-screen is toggled on/off
   through hotkeys handled by the embedded-controller
2. Allowing control of the privacy-screen from the GNOME control-panel,
   including the on/off slider shown there updating to match the hw-setting
   when the setting is changed with the control-panel open.
3. Restoring the last user-setting at login

This series consists of a number of different parts:

1. A new version of Rajat's privacy-screen connector properties patch,
this adds new userspace API in the form of new properties

2. Since on most devices the privacy screen is actually controlled by
some vendor specific ACPI/WMI interface which has a driver under
drivers/platform/x86, we need some "glue" code to make this functionality
available to KMS drivers. Patches 2-4 add a new privacy-screen class for
this, which allows non KMS drivers (and possibly KMS drivers too) to
register a privacy-screen device and also adds an interface for KMS drivers
to get access to the privacy-screen associated with a specific connector.
This is modelled similar to how we deal with e.g. PWMs and GPIOs in the
kernel, including separate includes for consumers and providers(drivers).

3. Some drm_connector helper functions to keep the actual changes needed
for this in individual KMS drivers as small as possible (patch 5).

4. Make the thinkpad_acpi code register a privacy-screen device on
ThinkPads with a privacy-screen (patches 6-8)

5. Make the i915 driver export the privacy-screen functionality through
the connector properties on the eDP connector.

I believe that it would be best to merge the entire series, including
the thinkpad_acpi changes through drm-misc in one go. As the pdx86
subsys maintainer I hereby give my ack for merging the thinkpad_acpi
changes through drm-misc.

There is one small caveat with this series, which it is good to be
aware of. The i915 driver will now return -EPROBE_DEFER on Thinkpads
with an eprivacy screen, until the thinkpad_acpi driver is loaded.
This means that initrd generation tools will need to be updated to
include thinkpad_acpi when the i915 driver is added to the initrd.
Without this the loading of the i915 driver will be delayed to after
the switch to real rootfs.

Regards,

Hans


Hans de Goede (8):
  drm: Add privacy-screen class (v3)
  drm/privacy-screen: Add X86 specific arch init code
  drm/privacy-screen: Add notifier support
  drm/connector: Add a drm_connector privacy-screen helper functions
  platform/x86: thinkpad_acpi: Add hotkey_notify_extended_hotkey()
    helper
  platform/x86: thinkpad_acpi: Get privacy-screen / lcdshadow ACPI
    handles only once
  platform/x86: thinkpad_acpi: Register a privacy-screen device
  drm/i915: Add privacy-screen support

Rajat Jain (1):
  drm/connector: Add support for privacy-screen properties (v4)

 Documentation/gpu/drm-kms-helpers.rst        |  15 +
 Documentation/gpu/drm-kms.rst                |   2 +
 MAINTAINERS                                  |   8 +
 drivers/gpu/drm/Kconfig                      |   4 +
 drivers/gpu/drm/Makefile                     |   1 +
 drivers/gpu/drm/drm_atomic_uapi.c            |   4 +
 drivers/gpu/drm/drm_connector.c              | 214 +++++++++
 drivers/gpu/drm/drm_drv.c                    |   4 +
 drivers/gpu/drm/drm_privacy_screen.c         | 468 +++++++++++++++++++
 drivers/gpu/drm/drm_privacy_screen_x86.c     |  86 ++++
 drivers/gpu/drm/i915/display/intel_display.c |   5 +
 drivers/gpu/drm/i915/display/intel_dp.c      |  10 +
 drivers/gpu/drm/i915/i915_pci.c              |  12 +
 drivers/platform/x86/Kconfig                 |   2 +
 drivers/platform/x86/thinkpad_acpi.c         | 131 ++++--
 include/drm/drm_connector.h                  |  56 +++
 include/drm/drm_privacy_screen_consumer.h    |  65 +++
 include/drm/drm_privacy_screen_driver.h      |  84 ++++
 include/drm/drm_privacy_screen_machine.h     |  46 ++
 19 files changed, 1175 insertions(+), 42 deletions(-)
 create mode 100644 drivers/gpu/drm/drm_privacy_screen.c
 create mode 100644 drivers/gpu/drm/drm_privacy_screen_x86.c
 create mode 100644 include/drm/drm_privacy_screen_consumer.h
 create mode 100644 include/drm/drm_privacy_screen_driver.h
 create mode 100644 include/drm/drm_privacy_screen_machine.h

-- 
2.31.1


^ permalink raw reply	[flat|nested] 44+ messages in thread

end of thread, other threads:[~2021-09-16 10:14 UTC | newest]

Thread overview: 44+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-07-08 16:43 [PATCH 0/9] drm: Add privacy-screen class and connector properties Hans de Goede
2020-07-08 16:43 ` [Intel-gfx] " Hans de Goede
2020-07-08 16:43 ` [PATCH 1/9] drm/connector: Fix kerneldoc warning Hans de Goede
2020-07-08 16:43   ` [Intel-gfx] " Hans de Goede
2020-07-08 21:26   ` Alex Deucher
2020-07-08 21:26     ` [Intel-gfx] " Alex Deucher
2020-07-08 16:43 ` [PATCH 2/9] drm/connector: Add support for privacy-screen properties (v4) Hans de Goede
2020-07-08 16:43   ` [Intel-gfx] " Hans de Goede
2020-07-08 16:43 ` [PATCH 3/9] drm: Add privacy-screen class Hans de Goede
2020-07-08 16:43   ` [Intel-gfx] " Hans de Goede
2020-07-08 16:43 ` [PATCH 4/9] drm/privacy-screen: Add X86 specific arch init code Hans de Goede
2020-07-08 16:43   ` [Intel-gfx] " Hans de Goede
2020-07-08 16:43 ` [PATCH 5/9] drm/privacy-screen: Add notifier support Hans de Goede
2020-07-08 16:43   ` [Intel-gfx] " Hans de Goede
2020-07-08 16:43 ` [PATCH 6/9] drm/connector: Add a drm_connector privacy-screen helper functions Hans de Goede
2020-07-08 16:43   ` [Intel-gfx] " Hans de Goede
2020-07-08 20:15   ` kernel test robot
2020-07-08 20:15     ` kernel test robot
2020-07-08 20:15     ` kernel test robot
2020-07-08 20:57   ` kernel test robot
2020-07-08 20:57     ` kernel test robot
2020-07-08 20:57     ` kernel test robot
2020-07-08 16:43 ` [PATCH 7/9] platform/x86: thinkpad_acpi: Get privacy-screen / lcdshadow ACPI handles only once Hans de Goede
2020-07-08 16:43   ` [Intel-gfx] " Hans de Goede
2020-07-08 16:43 ` [PATCH 8/9] platform/x86: thinkpad_acpi: Register a privacy-screen device Hans de Goede
2020-07-08 16:43   ` [Intel-gfx] " Hans de Goede
2020-07-08 21:45   ` kernel test robot
2020-07-08 21:45     ` kernel test robot
2020-07-08 21:45     ` kernel test robot
2020-07-08 16:43 ` [PATCH 9/9] drm/i915: Add privacy-screen support Hans de Goede
2020-07-08 16:43   ` [Intel-gfx] " Hans de Goede
2020-07-08 16:58 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for drm: Add privacy-screen class and connector properties Patchwork
2020-07-08 19:33   ` Hans de Goede
2020-07-08 21:25 ` [PATCH 0/9] " Alex Deucher
2020-07-08 21:25   ` [Intel-gfx] " Alex Deucher
2020-07-09 12:48   ` Hans de Goede
2020-07-09 12:48     ` [Intel-gfx] " Hans de Goede
2020-07-14 15:00     ` Alex Deucher
2020-07-14 15:00       ` [Intel-gfx] " Alex Deucher
2021-09-06  7:35 Hans de Goede
2021-09-15 21:12 ` Lyude Paul
2021-09-15 21:12   ` Lyude Paul
2021-09-16  9:30   ` Hans de Goede
2021-09-16 10:14     ` Jani Nikula

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.