* [PATCH 0/9] drm: Add privacy-screen class and connector properties
@ 2021-09-06 7:35 ` Hans de Goede
0 siblings, 0 replies; 84+ 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] 84+ messages in thread
* [Intel-gfx] [PATCH 0/9] drm: Add privacy-screen class and connector properties
@ 2021-09-06 7:35 ` Hans de Goede
0 siblings, 0 replies; 84+ 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] 84+ messages in thread
* [PATCH 1/9] drm/connector: Add support for privacy-screen properties (v4)
2021-09-06 7:35 ` [Intel-gfx] " Hans de Goede
@ 2021-09-06 7:35 ` Hans de Goede
-1 siblings, 0 replies; 84+ 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, Mario Limonciello
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>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.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 1ef7951ded5e..d14bf1c35d7e 100644
--- a/Documentation/gpu/drm-kms.rst
+++ b/Documentation/gpu/drm-kms.rst
@@ -506,6 +506,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 909f31833181..cdd31fc78bfc 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -797,6 +797,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);
@@ -874,6 +876,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 e0a30e0ee86a..dd1ca68881ba 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1264,6 +1264,46 @@ static const struct drm_prop_enum_list dp_colorspaces[] = {
* For DVI-I and TVout there is also a matching property "select subconnector"
* allowing to switch between signal types.
* DP subconnector corresponds to a downstream port.
+ *
+ * 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)
@@ -2341,6 +2381,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 79fa34e5ccdb..1acbcf0626ce 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -320,6 +320,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
@@ -781,6 +805,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
@@ -1409,6 +1439,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)
@@ -1732,6 +1774,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.31.1
^ permalink raw reply related [flat|nested] 84+ messages in thread
* [Intel-gfx] [PATCH 1/9] drm/connector: Add support for privacy-screen properties (v4)
@ 2021-09-06 7:35 ` Hans de Goede
0 siblings, 0 replies; 84+ 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, Mario Limonciello
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>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.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 1ef7951ded5e..d14bf1c35d7e 100644
--- a/Documentation/gpu/drm-kms.rst
+++ b/Documentation/gpu/drm-kms.rst
@@ -506,6 +506,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 909f31833181..cdd31fc78bfc 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -797,6 +797,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);
@@ -874,6 +876,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 e0a30e0ee86a..dd1ca68881ba 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1264,6 +1264,46 @@ static const struct drm_prop_enum_list dp_colorspaces[] = {
* For DVI-I and TVout there is also a matching property "select subconnector"
* allowing to switch between signal types.
* DP subconnector corresponds to a downstream port.
+ *
+ * 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)
@@ -2341,6 +2381,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 79fa34e5ccdb..1acbcf0626ce 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -320,6 +320,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
@@ -781,6 +805,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
@@ -1409,6 +1439,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)
@@ -1732,6 +1774,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.31.1
^ permalink raw reply related [flat|nested] 84+ messages in thread
* [PATCH 2/9] drm: Add privacy-screen class (v3)
2021-09-06 7:35 ` [Intel-gfx] " Hans de Goede
@ 2021-09-06 7:35 ` Hans de Goede
-1 siblings, 0 replies; 84+ 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
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.
Changes in v2:
- Make CONFIG_DRM_PRIVACY_SCREEN a bool which controls if the drm_privacy
code gets built as part of the main drm module rather then making it
a tristate which builds its own module.
- Add a #if IS_ENABLED(CONFIG_DRM_PRIVACY_SCREEN) check to
drm_privacy_screen_consumer.h and define stubs when the check fails.
Together these 2 changes fix several dependency issues.
- Remove module related code now that this is part of the main drm.ko
- Use drm_class as class for the privacy-screen devices instead of
adding a separate class for this
Changes in v3:
- Make the static inline drm_privacy_screen_get_state() stub set sw_state
and hw_state to PRIVACY_SCREEN_DISABLED to squelch an uninitialized
variable warning when CONFIG_DRM_PRIVICAY_SCREEN is not set
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
Documentation/gpu/drm-kms-helpers.rst | 15 +
MAINTAINERS | 8 +
drivers/gpu/drm/Kconfig | 4 +
drivers/gpu/drm/Makefile | 1 +
drivers/gpu/drm/drm_drv.c | 4 +
drivers/gpu/drm/drm_privacy_screen.c | 401 ++++++++++++++++++++++
include/drm/drm_privacy_screen_consumer.h | 50 +++
include/drm/drm_privacy_screen_driver.h | 80 +++++
include/drm/drm_privacy_screen_machine.h | 41 +++
9 files changed, 604 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 389892f36185..5d8715d2f998 100644
--- a/Documentation/gpu/drm-kms-helpers.rst
+++ b/Documentation/gpu/drm-kms-helpers.rst
@@ -423,3 +423,18 @@ Legacy CRTC/Modeset Helper Functions Reference
.. kernel-doc:: drivers/gpu/drm/drm_crtc_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 ede4a37a53b3..a272ca600f98 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6376,6 +6376,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 b17e231ca6f7..7249b010ab90 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -481,3 +481,7 @@ config DRM_PANEL_ORIENTATION_QUIRKS
config DRM_LIB_RANDOM
bool
default n
+
+config DRM_PRIVACY_SCREEN
+ bool
+ default n
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 0dff40bb863c..788fc37096f6 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -32,6 +32,7 @@ drm-$(CONFIG_OF) += drm_of.o
drm-$(CONFIG_PCI) += drm_pci.o
drm-$(CONFIG_DEBUG_FS) += drm_debugfs.o drm_debugfs_crc.o
drm-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
+drm-$(CONFIG_DRM_PRIVACY_SCREEN) += drm_privacy_screen.o
obj-$(CONFIG_DRM_DP_AUX_BUS) += drm_dp_aux_bus.o
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 7a5097467ba5..dc293b771c3f 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -43,6 +43,7 @@
#include <drm/drm_managed.h>
#include <drm/drm_mode_object.h>
#include <drm/drm_print.h>
+#include <drm/drm_privacy_screen_machine.h>
#include "drm_crtc_internal.h"
#include "drm_internal.h"
@@ -1029,6 +1030,7 @@ static const struct file_operations drm_stub_fops = {
static void drm_core_exit(void)
{
+ drm_privacy_screen_lookup_exit();
unregister_chrdev(DRM_MAJOR, "drm");
debugfs_remove(drm_debugfs_root);
drm_sysfs_destroy();
@@ -1056,6 +1058,8 @@ static int __init drm_core_init(void)
if (ret < 0)
goto error;
+ drm_privacy_screen_lookup_init();
+
drm_core_init_complete = true;
DRM_DEBUG("Initialized\n");
diff --git a/drivers/gpu/drm/drm_privacy_screen.c b/drivers/gpu/drm/drm_privacy_screen.c
new file mode 100644
index 000000000000..294a09194bfb
--- /dev/null
+++ b/drivers/gpu/drm/drm_privacy_screen.c
@@ -0,0 +1,401 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright (C) 2020 - 2021 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>
+#include "drm_internal.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 device_type drm_privacy_screen_type = {
+ .name = "privacy_screen",
+ .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_class;
+ priv->dev.type = &drm_privacy_screen_type;
+ priv->dev.parent = parent;
+ priv->dev.release = drm_privacy_screen_device_release;
+ dev_set_name(&priv->dev, "privacy_screen-%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);
diff --git a/include/drm/drm_privacy_screen_consumer.h b/include/drm/drm_privacy_screen_consumer.h
new file mode 100644
index 000000000000..0cbd23b0453d
--- /dev/null
+++ b/include/drm/drm_privacy_screen_consumer.h
@@ -0,0 +1,50 @@
+/* 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;
+
+#if IS_ENABLED(CONFIG_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);
+#else
+static inline struct drm_privacy_screen *drm_privacy_screen_get(struct device *dev,
+ const char *con_id)
+{
+ return ERR_PTR(-ENODEV);
+}
+static inline void drm_privacy_screen_put(struct drm_privacy_screen *priv)
+{
+}
+static inline int drm_privacy_screen_set_sw_state(struct drm_privacy_screen *priv,
+ enum drm_privacy_screen_status sw_state)
+{
+ return -ENODEV;
+}
+static inline 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)
+{
+ *sw_state_ret = PRIVACY_SCREEN_DISABLED;
+ *hw_state_ret = PRIVACY_SCREEN_DISABLED;
+}
+#endif
+
+#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..aaa0d38cce92
--- /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_lookup_init(void)
+{
+}
+static inline void drm_privacy_screen_lookup_exit(void)
+{
+}
+
+#endif
--
2.31.1
^ permalink raw reply related [flat|nested] 84+ messages in thread
* [Intel-gfx] [PATCH 2/9] drm: Add privacy-screen class (v3)
@ 2021-09-06 7:35 ` Hans de Goede
0 siblings, 0 replies; 84+ 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
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.
Changes in v2:
- Make CONFIG_DRM_PRIVACY_SCREEN a bool which controls if the drm_privacy
code gets built as part of the main drm module rather then making it
a tristate which builds its own module.
- Add a #if IS_ENABLED(CONFIG_DRM_PRIVACY_SCREEN) check to
drm_privacy_screen_consumer.h and define stubs when the check fails.
Together these 2 changes fix several dependency issues.
- Remove module related code now that this is part of the main drm.ko
- Use drm_class as class for the privacy-screen devices instead of
adding a separate class for this
Changes in v3:
- Make the static inline drm_privacy_screen_get_state() stub set sw_state
and hw_state to PRIVACY_SCREEN_DISABLED to squelch an uninitialized
variable warning when CONFIG_DRM_PRIVICAY_SCREEN is not set
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
Documentation/gpu/drm-kms-helpers.rst | 15 +
MAINTAINERS | 8 +
drivers/gpu/drm/Kconfig | 4 +
drivers/gpu/drm/Makefile | 1 +
drivers/gpu/drm/drm_drv.c | 4 +
drivers/gpu/drm/drm_privacy_screen.c | 401 ++++++++++++++++++++++
include/drm/drm_privacy_screen_consumer.h | 50 +++
include/drm/drm_privacy_screen_driver.h | 80 +++++
include/drm/drm_privacy_screen_machine.h | 41 +++
9 files changed, 604 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 389892f36185..5d8715d2f998 100644
--- a/Documentation/gpu/drm-kms-helpers.rst
+++ b/Documentation/gpu/drm-kms-helpers.rst
@@ -423,3 +423,18 @@ Legacy CRTC/Modeset Helper Functions Reference
.. kernel-doc:: drivers/gpu/drm/drm_crtc_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 ede4a37a53b3..a272ca600f98 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6376,6 +6376,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 b17e231ca6f7..7249b010ab90 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -481,3 +481,7 @@ config DRM_PANEL_ORIENTATION_QUIRKS
config DRM_LIB_RANDOM
bool
default n
+
+config DRM_PRIVACY_SCREEN
+ bool
+ default n
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 0dff40bb863c..788fc37096f6 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -32,6 +32,7 @@ drm-$(CONFIG_OF) += drm_of.o
drm-$(CONFIG_PCI) += drm_pci.o
drm-$(CONFIG_DEBUG_FS) += drm_debugfs.o drm_debugfs_crc.o
drm-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
+drm-$(CONFIG_DRM_PRIVACY_SCREEN) += drm_privacy_screen.o
obj-$(CONFIG_DRM_DP_AUX_BUS) += drm_dp_aux_bus.o
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 7a5097467ba5..dc293b771c3f 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -43,6 +43,7 @@
#include <drm/drm_managed.h>
#include <drm/drm_mode_object.h>
#include <drm/drm_print.h>
+#include <drm/drm_privacy_screen_machine.h>
#include "drm_crtc_internal.h"
#include "drm_internal.h"
@@ -1029,6 +1030,7 @@ static const struct file_operations drm_stub_fops = {
static void drm_core_exit(void)
{
+ drm_privacy_screen_lookup_exit();
unregister_chrdev(DRM_MAJOR, "drm");
debugfs_remove(drm_debugfs_root);
drm_sysfs_destroy();
@@ -1056,6 +1058,8 @@ static int __init drm_core_init(void)
if (ret < 0)
goto error;
+ drm_privacy_screen_lookup_init();
+
drm_core_init_complete = true;
DRM_DEBUG("Initialized\n");
diff --git a/drivers/gpu/drm/drm_privacy_screen.c b/drivers/gpu/drm/drm_privacy_screen.c
new file mode 100644
index 000000000000..294a09194bfb
--- /dev/null
+++ b/drivers/gpu/drm/drm_privacy_screen.c
@@ -0,0 +1,401 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright (C) 2020 - 2021 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>
+#include "drm_internal.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 device_type drm_privacy_screen_type = {
+ .name = "privacy_screen",
+ .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_class;
+ priv->dev.type = &drm_privacy_screen_type;
+ priv->dev.parent = parent;
+ priv->dev.release = drm_privacy_screen_device_release;
+ dev_set_name(&priv->dev, "privacy_screen-%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);
diff --git a/include/drm/drm_privacy_screen_consumer.h b/include/drm/drm_privacy_screen_consumer.h
new file mode 100644
index 000000000000..0cbd23b0453d
--- /dev/null
+++ b/include/drm/drm_privacy_screen_consumer.h
@@ -0,0 +1,50 @@
+/* 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;
+
+#if IS_ENABLED(CONFIG_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);
+#else
+static inline struct drm_privacy_screen *drm_privacy_screen_get(struct device *dev,
+ const char *con_id)
+{
+ return ERR_PTR(-ENODEV);
+}
+static inline void drm_privacy_screen_put(struct drm_privacy_screen *priv)
+{
+}
+static inline int drm_privacy_screen_set_sw_state(struct drm_privacy_screen *priv,
+ enum drm_privacy_screen_status sw_state)
+{
+ return -ENODEV;
+}
+static inline 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)
+{
+ *sw_state_ret = PRIVACY_SCREEN_DISABLED;
+ *hw_state_ret = PRIVACY_SCREEN_DISABLED;
+}
+#endif
+
+#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..aaa0d38cce92
--- /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_lookup_init(void)
+{
+}
+static inline void drm_privacy_screen_lookup_exit(void)
+{
+}
+
+#endif
--
2.31.1
^ permalink raw reply related [flat|nested] 84+ messages in thread
* [PATCH 3/9] drm/privacy-screen: Add X86 specific arch init code
2021-09-06 7:35 ` [Intel-gfx] " Hans de Goede
@ 2021-09-06 7:35 ` Hans de Goede
-1 siblings, 0 replies; 84+ 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
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.
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
drivers/gpu/drm/Makefile | 2 +-
drivers/gpu/drm/drm_privacy_screen_x86.c | 86 ++++++++++++++++++++++++
include/drm/drm_privacy_screen_machine.h | 5 ++
3 files changed, 92 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 788fc37096f6..12997ca5670d 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -32,7 +32,7 @@ drm-$(CONFIG_OF) += drm_of.o
drm-$(CONFIG_PCI) += drm_pci.o
drm-$(CONFIG_DEBUG_FS) += drm_debugfs.o drm_debugfs_crc.o
drm-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
-drm-$(CONFIG_DRM_PRIVACY_SCREEN) += drm_privacy_screen.o
+drm-$(CONFIG_DRM_PRIVACY_SCREEN) += drm_privacy_screen.o drm_privacy_screen_x86.o
obj-$(CONFIG_DRM_DP_AUX_BUS) += drm_dp_aux_bus.o
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..a2cafb294ca6
--- /dev/null
+++ b/drivers/gpu/drm/drm_privacy_screen_x86.c
@@ -0,0 +1,86 @@
+// 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>
+
+#ifdef CONFIG_X86
+static struct drm_privacy_screen_lookup arch_lookup;
+
+struct arch_init_data {
+ struct drm_privacy_screen_lookup lookup;
+ bool (*detect)(void);
+};
+
+#if IS_ENABLED(CONFIG_THINKPAD_ACPI)
+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;
+}
+#endif
+
+static const struct arch_init_data arch_init_data[] __initconst = {
+#if IS_ENABLED(CONFIG_THINKPAD_ACPI)
+ {
+ .lookup = {
+ .dev_id = NULL,
+ .con_id = NULL,
+ .provider = "privacy_screen-thinkpad_acpi",
+ },
+ .detect = detect_thinkpad_privacy_screen,
+ },
+#endif
+};
+
+void __init drm_privacy_screen_lookup_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 drm_privacy_screen_lookup_exit(void)
+{
+ if (arch_lookup.provider)
+ drm_privacy_screen_lookup_remove(&arch_lookup);
+}
+#endif /* ifdef CONFIG_X86 */
diff --git a/include/drm/drm_privacy_screen_machine.h b/include/drm/drm_privacy_screen_machine.h
index aaa0d38cce92..02e5371904d3 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);
+#if IS_ENABLED(CONFIG_DRM_PRIVACY_SCREEN) && IS_ENABLED(CONFIG_X86)
+void drm_privacy_screen_lookup_init(void);
+void drm_privacy_screen_lookup_exit(void);
+#else
static inline void drm_privacy_screen_lookup_init(void)
{
}
static inline void drm_privacy_screen_lookup_exit(void)
{
}
+#endif
#endif
--
2.31.1
^ permalink raw reply related [flat|nested] 84+ messages in thread
* [Intel-gfx] [PATCH 3/9] drm/privacy-screen: Add X86 specific arch init code
@ 2021-09-06 7:35 ` Hans de Goede
0 siblings, 0 replies; 84+ 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
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.
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
drivers/gpu/drm/Makefile | 2 +-
drivers/gpu/drm/drm_privacy_screen_x86.c | 86 ++++++++++++++++++++++++
include/drm/drm_privacy_screen_machine.h | 5 ++
3 files changed, 92 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 788fc37096f6..12997ca5670d 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -32,7 +32,7 @@ drm-$(CONFIG_OF) += drm_of.o
drm-$(CONFIG_PCI) += drm_pci.o
drm-$(CONFIG_DEBUG_FS) += drm_debugfs.o drm_debugfs_crc.o
drm-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
-drm-$(CONFIG_DRM_PRIVACY_SCREEN) += drm_privacy_screen.o
+drm-$(CONFIG_DRM_PRIVACY_SCREEN) += drm_privacy_screen.o drm_privacy_screen_x86.o
obj-$(CONFIG_DRM_DP_AUX_BUS) += drm_dp_aux_bus.o
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..a2cafb294ca6
--- /dev/null
+++ b/drivers/gpu/drm/drm_privacy_screen_x86.c
@@ -0,0 +1,86 @@
+// 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>
+
+#ifdef CONFIG_X86
+static struct drm_privacy_screen_lookup arch_lookup;
+
+struct arch_init_data {
+ struct drm_privacy_screen_lookup lookup;
+ bool (*detect)(void);
+};
+
+#if IS_ENABLED(CONFIG_THINKPAD_ACPI)
+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;
+}
+#endif
+
+static const struct arch_init_data arch_init_data[] __initconst = {
+#if IS_ENABLED(CONFIG_THINKPAD_ACPI)
+ {
+ .lookup = {
+ .dev_id = NULL,
+ .con_id = NULL,
+ .provider = "privacy_screen-thinkpad_acpi",
+ },
+ .detect = detect_thinkpad_privacy_screen,
+ },
+#endif
+};
+
+void __init drm_privacy_screen_lookup_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 drm_privacy_screen_lookup_exit(void)
+{
+ if (arch_lookup.provider)
+ drm_privacy_screen_lookup_remove(&arch_lookup);
+}
+#endif /* ifdef CONFIG_X86 */
diff --git a/include/drm/drm_privacy_screen_machine.h b/include/drm/drm_privacy_screen_machine.h
index aaa0d38cce92..02e5371904d3 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);
+#if IS_ENABLED(CONFIG_DRM_PRIVACY_SCREEN) && IS_ENABLED(CONFIG_X86)
+void drm_privacy_screen_lookup_init(void);
+void drm_privacy_screen_lookup_exit(void);
+#else
static inline void drm_privacy_screen_lookup_init(void)
{
}
static inline void drm_privacy_screen_lookup_exit(void)
{
}
+#endif
#endif
--
2.31.1
^ permalink raw reply related [flat|nested] 84+ messages in thread
* [Intel-gfx] [PATCH 4/9] drm/privacy-screen: Add notifier support
2021-09-06 7:35 ` [Intel-gfx] " Hans de Goede
@ 2021-09-06 7:35 ` Hans de Goede
-1 siblings, 0 replies; 84+ 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
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.
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
drivers/gpu/drm/drm_privacy_screen.c | 67 +++++++++++++++++++++++
include/drm/drm_privacy_screen_consumer.h | 15 +++++
include/drm/drm_privacy_screen_driver.h | 4 ++
3 files changed, 86 insertions(+)
diff --git a/drivers/gpu/drm/drm_privacy_screen.c b/drivers/gpu/drm/drm_privacy_screen.c
index 294a09194bfb..7a5f878c3171 100644
--- a/drivers/gpu/drm/drm_privacy_screen.c
+++ b/drivers/gpu/drm/drm_privacy_screen.c
@@ -255,6 +255,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_class;
priv->dev.type = &drm_privacy_screen_type;
@@ -399,3 +443,26 @@ void drm_privacy_screen_unregister(struct drm_privacy_screen *priv)
device_unregister(&priv->dev);
}
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);
diff --git a/include/drm/drm_privacy_screen_consumer.h b/include/drm/drm_privacy_screen_consumer.h
index 0cbd23b0453d..7f66a90d15b7 100644
--- a/include/drm/drm_privacy_screen_consumer.h
+++ b/include/drm/drm_privacy_screen_consumer.h
@@ -24,6 +24,11 @@ int drm_privacy_screen_set_sw_state(struct drm_privacy_screen *priv,
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);
#else
static inline struct drm_privacy_screen *drm_privacy_screen_get(struct device *dev,
const char *con_id)
@@ -45,6 +50,16 @@ static inline void drm_privacy_screen_get_state(struct drm_privacy_screen *priv,
*sw_state_ret = PRIVACY_SCREEN_DISABLED;
*hw_state_ret = PRIVACY_SCREEN_DISABLED;
}
+static inline int drm_privacy_screen_register_notifier(struct drm_privacy_screen *priv,
+ struct notifier_block *nb)
+{
+ return -ENODEV;
+}
+static inline int drm_privacy_screen_unregister_notifier(struct drm_privacy_screen *priv,
+ struct notifier_block *nb)
+{
+ return -ENODEV;
+}
#endif
#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.31.1
^ permalink raw reply related [flat|nested] 84+ messages in thread
* [PATCH 4/9] drm/privacy-screen: Add notifier support
@ 2021-09-06 7:35 ` Hans de Goede
0 siblings, 0 replies; 84+ 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
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.
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
drivers/gpu/drm/drm_privacy_screen.c | 67 +++++++++++++++++++++++
include/drm/drm_privacy_screen_consumer.h | 15 +++++
include/drm/drm_privacy_screen_driver.h | 4 ++
3 files changed, 86 insertions(+)
diff --git a/drivers/gpu/drm/drm_privacy_screen.c b/drivers/gpu/drm/drm_privacy_screen.c
index 294a09194bfb..7a5f878c3171 100644
--- a/drivers/gpu/drm/drm_privacy_screen.c
+++ b/drivers/gpu/drm/drm_privacy_screen.c
@@ -255,6 +255,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_class;
priv->dev.type = &drm_privacy_screen_type;
@@ -399,3 +443,26 @@ void drm_privacy_screen_unregister(struct drm_privacy_screen *priv)
device_unregister(&priv->dev);
}
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);
diff --git a/include/drm/drm_privacy_screen_consumer.h b/include/drm/drm_privacy_screen_consumer.h
index 0cbd23b0453d..7f66a90d15b7 100644
--- a/include/drm/drm_privacy_screen_consumer.h
+++ b/include/drm/drm_privacy_screen_consumer.h
@@ -24,6 +24,11 @@ int drm_privacy_screen_set_sw_state(struct drm_privacy_screen *priv,
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);
#else
static inline struct drm_privacy_screen *drm_privacy_screen_get(struct device *dev,
const char *con_id)
@@ -45,6 +50,16 @@ static inline void drm_privacy_screen_get_state(struct drm_privacy_screen *priv,
*sw_state_ret = PRIVACY_SCREEN_DISABLED;
*hw_state_ret = PRIVACY_SCREEN_DISABLED;
}
+static inline int drm_privacy_screen_register_notifier(struct drm_privacy_screen *priv,
+ struct notifier_block *nb)
+{
+ return -ENODEV;
+}
+static inline int drm_privacy_screen_unregister_notifier(struct drm_privacy_screen *priv,
+ struct notifier_block *nb)
+{
+ return -ENODEV;
+}
#endif
#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.31.1
^ permalink raw reply related [flat|nested] 84+ messages in thread
* [PATCH 5/9] drm/connector: Add a drm_connector privacy-screen helper functions
2021-09-06 7:35 ` [Intel-gfx] " Hans de Goede
@ 2021-09-06 7:35 ` Hans de Goede
-1 siblings, 0 replies; 84+ 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
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.
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
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 dd1ca68881ba..8af678652e69 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -21,6 +21,7 @@
*/
#include <drm/drm_auth.h>
+#include <drm/drm_atomic.h>
#include <drm/drm_connector.h>
#include <drm/drm_edid.h>
#include <drm/drm_encoder.h>
@@ -28,6 +29,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>
@@ -462,6 +464,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;
@@ -543,6 +550,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);
+
mutex_lock(&connector_list_lock);
list_add_tail(&connector->global_connector_list_entry, &connector_list);
mutex_unlock(&connector_list_lock);
@@ -578,6 +589,11 @@ void drm_connector_unregister(struct drm_connector *connector)
list_del_init(&connector->global_connector_list_entry);
mutex_unlock(&connector_list_lock);
+ 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);
@@ -2442,6 +2458,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 1acbcf0626ce..2e6cd8a1749a 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;
@@ -1439,6 +1441,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.
@@ -1776,6 +1784,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.31.1
^ permalink raw reply related [flat|nested] 84+ messages in thread
* [Intel-gfx] [PATCH 5/9] drm/connector: Add a drm_connector privacy-screen helper functions
@ 2021-09-06 7:35 ` Hans de Goede
0 siblings, 0 replies; 84+ 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
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.
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
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 dd1ca68881ba..8af678652e69 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -21,6 +21,7 @@
*/
#include <drm/drm_auth.h>
+#include <drm/drm_atomic.h>
#include <drm/drm_connector.h>
#include <drm/drm_edid.h>
#include <drm/drm_encoder.h>
@@ -28,6 +29,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>
@@ -462,6 +464,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;
@@ -543,6 +550,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);
+
mutex_lock(&connector_list_lock);
list_add_tail(&connector->global_connector_list_entry, &connector_list);
mutex_unlock(&connector_list_lock);
@@ -578,6 +589,11 @@ void drm_connector_unregister(struct drm_connector *connector)
list_del_init(&connector->global_connector_list_entry);
mutex_unlock(&connector_list_lock);
+ 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);
@@ -2442,6 +2458,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 1acbcf0626ce..2e6cd8a1749a 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;
@@ -1439,6 +1441,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.
@@ -1776,6 +1784,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.31.1
^ permalink raw reply related [flat|nested] 84+ messages in thread
* [PATCH 6/9] platform/x86: thinkpad_acpi: Add hotkey_notify_extended_hotkey() helper
2021-09-06 7:35 ` [Intel-gfx] " Hans de Goede
@ 2021-09-06 7:35 ` Hans de Goede
-1 siblings, 0 replies; 84+ 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
Factor the extended hotkey handling out of hotkey_notify_hotkey() and
into a new hotkey_notify_extended_hotkey() helper.
This is a preparation patch for adding support the privacy-screen hotkey
toggle (which needs some special handling, it should NOT send an evdev
key-event to userspace...).
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
drivers/platform/x86/thinkpad_acpi.c | 30 ++++++++++++++++++----------
1 file changed, 19 insertions(+), 11 deletions(-)
diff --git a/drivers/platform/x86/thinkpad_acpi.c b/drivers/platform/x86/thinkpad_acpi.c
index 50ff04c84650..83c88a8ebaf2 100644
--- a/drivers/platform/x86/thinkpad_acpi.c
+++ b/drivers/platform/x86/thinkpad_acpi.c
@@ -3885,6 +3885,24 @@ static bool adaptive_keyboard_hotkey_notify_hotkey(unsigned int scancode)
}
}
+static bool hotkey_notify_extended_hotkey(const u32 hkey)
+{
+ unsigned int scancode;
+
+ /* Extended keycodes start at 0x300 and our offset into the map
+ * TP_ACPI_HOTKEYSCAN_EXTENDED_START. The calculated scancode
+ * will be positive, but might not be in the correct range.
+ */
+ scancode = (hkey & 0xfff) - (0x300 - TP_ACPI_HOTKEYSCAN_EXTENDED_START);
+ if (scancode >= TP_ACPI_HOTKEYSCAN_EXTENDED_START &&
+ scancode < TPACPI_HOTKEY_MAP_LEN) {
+ tpacpi_input_send_key(scancode);
+ return true;
+ }
+
+ return false;
+}
+
static bool hotkey_notify_hotkey(const u32 hkey,
bool *send_acpi_ev,
bool *ignore_acpi_ev)
@@ -3919,17 +3937,7 @@ static bool hotkey_notify_hotkey(const u32 hkey,
return adaptive_keyboard_hotkey_notify_hotkey(scancode);
case 3:
- /* Extended keycodes start at 0x300 and our offset into the map
- * TP_ACPI_HOTKEYSCAN_EXTENDED_START. The calculated scancode
- * will be positive, but might not be in the correct range.
- */
- scancode -= (0x300 - TP_ACPI_HOTKEYSCAN_EXTENDED_START);
- if (scancode >= TP_ACPI_HOTKEYSCAN_EXTENDED_START &&
- scancode < TPACPI_HOTKEY_MAP_LEN) {
- tpacpi_input_send_key(scancode);
- return true;
- }
- break;
+ return hotkey_notify_extended_hotkey(hkey);
}
return false;
--
2.31.1
^ permalink raw reply related [flat|nested] 84+ messages in thread
* [Intel-gfx] [PATCH 6/9] platform/x86: thinkpad_acpi: Add hotkey_notify_extended_hotkey() helper
@ 2021-09-06 7:35 ` Hans de Goede
0 siblings, 0 replies; 84+ 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
Factor the extended hotkey handling out of hotkey_notify_hotkey() and
into a new hotkey_notify_extended_hotkey() helper.
This is a preparation patch for adding support the privacy-screen hotkey
toggle (which needs some special handling, it should NOT send an evdev
key-event to userspace...).
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
drivers/platform/x86/thinkpad_acpi.c | 30 ++++++++++++++++++----------
1 file changed, 19 insertions(+), 11 deletions(-)
diff --git a/drivers/platform/x86/thinkpad_acpi.c b/drivers/platform/x86/thinkpad_acpi.c
index 50ff04c84650..83c88a8ebaf2 100644
--- a/drivers/platform/x86/thinkpad_acpi.c
+++ b/drivers/platform/x86/thinkpad_acpi.c
@@ -3885,6 +3885,24 @@ static bool adaptive_keyboard_hotkey_notify_hotkey(unsigned int scancode)
}
}
+static bool hotkey_notify_extended_hotkey(const u32 hkey)
+{
+ unsigned int scancode;
+
+ /* Extended keycodes start at 0x300 and our offset into the map
+ * TP_ACPI_HOTKEYSCAN_EXTENDED_START. The calculated scancode
+ * will be positive, but might not be in the correct range.
+ */
+ scancode = (hkey & 0xfff) - (0x300 - TP_ACPI_HOTKEYSCAN_EXTENDED_START);
+ if (scancode >= TP_ACPI_HOTKEYSCAN_EXTENDED_START &&
+ scancode < TPACPI_HOTKEY_MAP_LEN) {
+ tpacpi_input_send_key(scancode);
+ return true;
+ }
+
+ return false;
+}
+
static bool hotkey_notify_hotkey(const u32 hkey,
bool *send_acpi_ev,
bool *ignore_acpi_ev)
@@ -3919,17 +3937,7 @@ static bool hotkey_notify_hotkey(const u32 hkey,
return adaptive_keyboard_hotkey_notify_hotkey(scancode);
case 3:
- /* Extended keycodes start at 0x300 and our offset into the map
- * TP_ACPI_HOTKEYSCAN_EXTENDED_START. The calculated scancode
- * will be positive, but might not be in the correct range.
- */
- scancode -= (0x300 - TP_ACPI_HOTKEYSCAN_EXTENDED_START);
- if (scancode >= TP_ACPI_HOTKEYSCAN_EXTENDED_START &&
- scancode < TPACPI_HOTKEY_MAP_LEN) {
- tpacpi_input_send_key(scancode);
- return true;
- }
- break;
+ return hotkey_notify_extended_hotkey(hkey);
}
return false;
--
2.31.1
^ permalink raw reply related [flat|nested] 84+ messages in thread
* [PATCH 7/9] platform/x86: thinkpad_acpi: Get privacy-screen / lcdshadow ACPI handles only once
2021-09-06 7:35 ` [Intel-gfx] " Hans de Goede
@ 2021-09-06 7:35 ` Hans de Goede
-1 siblings, 0 replies; 84+ 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
Get the privacy-screen / lcdshadow ACPI handles once and cache them,
instead of retrieving them every time we need them.
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
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 83c88a8ebaf2..b8f2556c4797 100644
--- a/drivers/platform/x86/thinkpad_acpi.c
+++ b/drivers/platform/x86/thinkpad_acpi.c
@@ -9819,19 +9819,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;
@@ -9849,15 +9845,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.31.1
^ permalink raw reply related [flat|nested] 84+ messages in thread
* [Intel-gfx] [PATCH 7/9] platform/x86: thinkpad_acpi: Get privacy-screen / lcdshadow ACPI handles only once
@ 2021-09-06 7:35 ` Hans de Goede
0 siblings, 0 replies; 84+ 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
Get the privacy-screen / lcdshadow ACPI handles once and cache them,
instead of retrieving them every time we need them.
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
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 83c88a8ebaf2..b8f2556c4797 100644
--- a/drivers/platform/x86/thinkpad_acpi.c
+++ b/drivers/platform/x86/thinkpad_acpi.c
@@ -9819,19 +9819,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;
@@ -9849,15 +9845,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.31.1
^ permalink raw reply related [flat|nested] 84+ messages in thread
* [PATCH 8/9] platform/x86: thinkpad_acpi: Register a privacy-screen device
2021-09-06 7:35 ` [Intel-gfx] " Hans de Goede
@ 2021-09-06 7:35 ` Hans de Goede
-1 siblings, 0 replies; 84+ 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
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.
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
Changes in v2:
- Make the new lcdshadow_set_sw_state, lcdshadow_get_hw_state and
lcdshadow_ops symbols static
- Update state and call drm_privacy_screen_call_notifier_chain()
when the state is changed by pressing the Fn + D hotkey combo
---
drivers/platform/x86/Kconfig | 2 +
drivers/platform/x86/thinkpad_acpi.c | 91 ++++++++++++++++++++--------
2 files changed, 68 insertions(+), 25 deletions(-)
diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index d12db6c316ea..ae00a27f9f95 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -509,7 +509,9 @@ config THINKPAD_ACPI
depends on ACPI_VIDEO || ACPI_VIDEO = n
depends on BACKLIGHT_CLASS_DEVICE
depends on I2C
+ depends on DRM
select ACPI_PLATFORM_PROFILE
+ 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 b8f2556c4797..044b238730ba 100644
--- a/drivers/platform/x86/thinkpad_acpi.c
+++ b/drivers/platform/x86/thinkpad_acpi.c
@@ -73,6 +73,7 @@
#include <linux/uaccess.h>
#include <acpi/battery.h>
#include <acpi/video.h>
+#include <drm/drm_privacy_screen_driver.h>
#include "dual_accel_detect.h"
/* ThinkPad CMOS commands */
@@ -157,6 +158,7 @@ enum tpacpi_hkey_event_t {
TP_HKEY_EV_VOL_UP = 0x1015, /* Volume up or unmute */
TP_HKEY_EV_VOL_DOWN = 0x1016, /* Volume down or unmute */
TP_HKEY_EV_VOL_MUTE = 0x1017, /* Mixer output mute */
+ TP_HKEY_EV_PRIVACYGUARD_TOGGLE = 0x130f, /* Toggle priv.guard on/off */
/* Reasons for waking up from S3/S4 */
TP_HKEY_EV_WKUP_S3_UNDOCK = 0x2304, /* undock requested, S3 */
@@ -3889,6 +3891,12 @@ static bool hotkey_notify_extended_hotkey(const u32 hkey)
{
unsigned int scancode;
+ switch (hkey) {
+ case TP_HKEY_EV_PRIVACYGUARD_TOGGLE:
+ tpacpi_driver_event(hkey);
+ return true;
+ }
+
/* Extended keycodes start at 0x300 and our offset into the map
* TP_ACPI_HOTKEYSCAN_EXTENDED_START. The calculated scancode
* will be positive, but might not be in the correct range.
@@ -9819,30 +9827,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)
+static 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)
+static 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;
}
+static 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;
@@ -9850,36 +9868,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");
}
@@ -9891,7 +9917,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, ","))) {
@@ -9903,11 +9929,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,
@@ -10717,6 +10750,14 @@ static void tpacpi_driver_event(const unsigned int hkey_event)
if (!atomic_add_unless(&dytc_ignore_event, -1, 0))
dytc_profile_refresh();
}
+
+ if (lcdshadow_dev && hkey_event == TP_HKEY_EV_PRIVACYGUARD_TOGGLE) {
+ mutex_lock(&lcdshadow_dev->lock);
+ lcdshadow_get_hw_state(lcdshadow_dev);
+ mutex_unlock(&lcdshadow_dev->lock);
+
+ drm_privacy_screen_call_notifier_chain(lcdshadow_dev);
+ }
}
static void hotkey_driver_event(const unsigned int scancode)
--
2.31.1
^ permalink raw reply related [flat|nested] 84+ messages in thread
* [Intel-gfx] [PATCH 8/9] platform/x86: thinkpad_acpi: Register a privacy-screen device
@ 2021-09-06 7:35 ` Hans de Goede
0 siblings, 0 replies; 84+ 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
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.
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
Changes in v2:
- Make the new lcdshadow_set_sw_state, lcdshadow_get_hw_state and
lcdshadow_ops symbols static
- Update state and call drm_privacy_screen_call_notifier_chain()
when the state is changed by pressing the Fn + D hotkey combo
---
drivers/platform/x86/Kconfig | 2 +
drivers/platform/x86/thinkpad_acpi.c | 91 ++++++++++++++++++++--------
2 files changed, 68 insertions(+), 25 deletions(-)
diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index d12db6c316ea..ae00a27f9f95 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -509,7 +509,9 @@ config THINKPAD_ACPI
depends on ACPI_VIDEO || ACPI_VIDEO = n
depends on BACKLIGHT_CLASS_DEVICE
depends on I2C
+ depends on DRM
select ACPI_PLATFORM_PROFILE
+ 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 b8f2556c4797..044b238730ba 100644
--- a/drivers/platform/x86/thinkpad_acpi.c
+++ b/drivers/platform/x86/thinkpad_acpi.c
@@ -73,6 +73,7 @@
#include <linux/uaccess.h>
#include <acpi/battery.h>
#include <acpi/video.h>
+#include <drm/drm_privacy_screen_driver.h>
#include "dual_accel_detect.h"
/* ThinkPad CMOS commands */
@@ -157,6 +158,7 @@ enum tpacpi_hkey_event_t {
TP_HKEY_EV_VOL_UP = 0x1015, /* Volume up or unmute */
TP_HKEY_EV_VOL_DOWN = 0x1016, /* Volume down or unmute */
TP_HKEY_EV_VOL_MUTE = 0x1017, /* Mixer output mute */
+ TP_HKEY_EV_PRIVACYGUARD_TOGGLE = 0x130f, /* Toggle priv.guard on/off */
/* Reasons for waking up from S3/S4 */
TP_HKEY_EV_WKUP_S3_UNDOCK = 0x2304, /* undock requested, S3 */
@@ -3889,6 +3891,12 @@ static bool hotkey_notify_extended_hotkey(const u32 hkey)
{
unsigned int scancode;
+ switch (hkey) {
+ case TP_HKEY_EV_PRIVACYGUARD_TOGGLE:
+ tpacpi_driver_event(hkey);
+ return true;
+ }
+
/* Extended keycodes start at 0x300 and our offset into the map
* TP_ACPI_HOTKEYSCAN_EXTENDED_START. The calculated scancode
* will be positive, but might not be in the correct range.
@@ -9819,30 +9827,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)
+static 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)
+static 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;
}
+static 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;
@@ -9850,36 +9868,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");
}
@@ -9891,7 +9917,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, ","))) {
@@ -9903,11 +9929,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,
@@ -10717,6 +10750,14 @@ static void tpacpi_driver_event(const unsigned int hkey_event)
if (!atomic_add_unless(&dytc_ignore_event, -1, 0))
dytc_profile_refresh();
}
+
+ if (lcdshadow_dev && hkey_event == TP_HKEY_EV_PRIVACYGUARD_TOGGLE) {
+ mutex_lock(&lcdshadow_dev->lock);
+ lcdshadow_get_hw_state(lcdshadow_dev);
+ mutex_unlock(&lcdshadow_dev->lock);
+
+ drm_privacy_screen_call_notifier_chain(lcdshadow_dev);
+ }
}
static void hotkey_driver_event(const unsigned int scancode)
--
2.31.1
^ permalink raw reply related [flat|nested] 84+ messages in thread
* [PATCH 9/9] drm/i915: Add privacy-screen support
2021-09-06 7:35 ` [Intel-gfx] " Hans de Goede
@ 2021-09-06 7:35 ` Hans de Goede
-1 siblings, 0 replies; 84+ 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
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.
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
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 5560d2f4c352..7285873d329a 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -10140,6 +10140,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;
@@ -10237,6 +10239,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 7f8e8865048f..3aa2072cccf6 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -37,6 +37,7 @@
#include <drm/drm_crtc.h>
#include <drm/drm_dp_helper.h>
#include <drm/drm_edid.h>
+#include <drm/drm_privacy_screen_consumer.h>
#include <drm/drm_probe_helper.h>
#include "g4x_dp.h"
@@ -5217,6 +5218,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;
struct edid *edid;
@@ -5308,6 +5310,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->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 146f7e39182a..d6913f567a1c 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -25,6 +25,7 @@
#include <linux/vga_switcheroo.h>
#include <drm/drm_drv.h>
+#include <drm/drm_privacy_screen_consumer.h>
#include <drm/i915_pciids.h>
#include "i915_drv.h"
@@ -1167,6 +1168,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 &&
@@ -1195,7 +1197,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.31.1
^ permalink raw reply related [flat|nested] 84+ messages in thread
* [Intel-gfx] [PATCH 9/9] drm/i915: Add privacy-screen support
@ 2021-09-06 7:35 ` Hans de Goede
0 siblings, 0 replies; 84+ 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
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.
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
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 5560d2f4c352..7285873d329a 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -10140,6 +10140,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;
@@ -10237,6 +10239,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 7f8e8865048f..3aa2072cccf6 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -37,6 +37,7 @@
#include <drm/drm_crtc.h>
#include <drm/drm_dp_helper.h>
#include <drm/drm_edid.h>
+#include <drm/drm_privacy_screen_consumer.h>
#include <drm/drm_probe_helper.h>
#include "g4x_dp.h"
@@ -5217,6 +5218,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;
struct edid *edid;
@@ -5308,6 +5310,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->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 146f7e39182a..d6913f567a1c 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -25,6 +25,7 @@
#include <linux/vga_switcheroo.h>
#include <drm/drm_drv.h>
+#include <drm/drm_privacy_screen_consumer.h>
#include <drm/i915_pciids.h>
#include "i915_drv.h"
@@ -1167,6 +1168,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 &&
@@ -1195,7 +1197,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.31.1
^ permalink raw reply related [flat|nested] 84+ messages in thread
* [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm: Add privacy-screen class and connector properties (rev4)
2021-09-06 7:35 ` [Intel-gfx] " Hans de Goede
` (9 preceding siblings ...)
(?)
@ 2021-09-06 8:46 ` Patchwork
-1 siblings, 0 replies; 84+ messages in thread
From: Patchwork @ 2021-09-06 8:46 UTC (permalink / raw)
To: Hans de Goede; +Cc: intel-gfx
== Series Details ==
Series: drm: Add privacy-screen class and connector properties (rev4)
URL : https://patchwork.freedesktop.org/series/79259/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
bc1b50a446f7 drm/connector: Add support for privacy-screen properties (v4)
-:30: WARNING:BAD_SIGN_OFF: Non-standard signature: Co-authored-by:
#30:
Co-authored-by: Hans de Goede <hdegoede@redhat.com>
-:150: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#150: FILE: drivers/gpu/drm/drm_connector.c:2408:
+ drm_property_create_enum(connector->dev, DRM_MODE_PROP_ENUM,
+ "privacy-screen sw-state",
-:155: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#155: FILE: drivers/gpu/drm/drm_connector.c:2413:
+ drm_property_create_enum(connector->dev,
+ DRM_MODE_PROP_IMMUTABLE | DRM_MODE_PROP_ENUM,
total: 0 errors, 1 warnings, 2 checks, 205 lines checked
103f4901ff19 drm: Add privacy-screen class (v3)
-:131: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating?
#131:
new file mode 100644
-:168: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'dev' - possible side-effects?
#168: FILE: drivers/gpu/drm/drm_privacy_screen.c:33:
+#define to_drm_privacy_screen(dev) \
+ container_of(dev, struct drm_privacy_screen, dev)
-:216: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#216: FILE: drivers/gpu/drm/drm_privacy_screen.c:81:
+static struct drm_privacy_screen *drm_privacy_screen_get_by_name(
-:417: CHECK:LINE_SPACING: Please use a blank line after function/struct/union/enum declarations
#417: FILE: drivers/gpu/drm/drm_privacy_screen.c:282:
+}
+/*
-:479: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#479: FILE: drivers/gpu/drm/drm_privacy_screen.c:344:
+struct drm_privacy_screen *drm_privacy_screen_register(
-:575: CHECK:LINE_SPACING: Please use a blank line after function/struct/union/enum declarations
#575: FILE: include/drm/drm_privacy_screen_consumer.h:33:
+}
+static inline void drm_privacy_screen_put(struct drm_privacy_screen *priv)
-:578: CHECK:LINE_SPACING: Please use a blank line after function/struct/union/enum declarations
#578: FILE: include/drm/drm_privacy_screen_consumer.h:36:
+}
+static inline int drm_privacy_screen_set_sw_state(struct drm_privacy_screen *priv,
-:583: CHECK:LINE_SPACING: Please use a blank line after function/struct/union/enum declarations
#583: FILE: include/drm/drm_privacy_screen_consumer.h:41:
+}
+static inline void drm_privacy_screen_get_state(struct drm_privacy_screen *priv,
-:674: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#674: FILE: include/drm/drm_privacy_screen_driver.h:76:
+struct drm_privacy_screen *drm_privacy_screen_register(
-:721: CHECK:LINE_SPACING: Please use a blank line after function/struct/union/enum declarations
#721: FILE: include/drm/drm_privacy_screen_machine.h:37:
+}
+static inline void drm_privacy_screen_lookup_exit(void)
total: 0 errors, 1 warnings, 9 checks, 640 lines checked
4c5269c0a347 drm/privacy-screen: Add X86 specific arch init code
-:30: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating?
#30:
new file mode 100644
total: 0 errors, 1 warnings, 0 checks, 110 lines checked
5112840ff391 drm/privacy-screen: Add notifier support
-:122: CHECK:LINE_SPACING: Please use a blank line after function/struct/union/enum declarations
#122: FILE: include/drm/drm_privacy_screen_consumer.h:53:
}
+static inline int drm_privacy_screen_register_notifier(struct drm_privacy_screen *priv,
-:127: CHECK:LINE_SPACING: Please use a blank line after function/struct/union/enum declarations
#127: FILE: include/drm/drm_privacy_screen_consumer.h:58:
+}
+static inline int drm_privacy_screen_unregister_notifier(struct drm_privacy_screen *priv,
total: 0 errors, 0 warnings, 2 checks, 123 lines checked
016dd07be125 drm/connector: Add a drm_connector privacy-screen helper functions
-:59: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#59: FILE: drivers/gpu/drm/drm_connector.c:555:
+ drm_privacy_screen_register_notifier(connector->privacy_screen,
+ &connector->privacy_screen_notifier);
-:69: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#69: FILE: drivers/gpu/drm/drm_connector.c:593:
+ drm_privacy_screen_unregister_notifier(
-:80: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#80: FILE: drivers/gpu/drm/drm_connector.c:2461:
+static void drm_connector_update_privacy_screen_properties(
-:90: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#90: FILE: drivers/gpu/drm/drm_connector.c:2471:
+ drm_object_property_set_value(&connector->base,
+ connector->privacy_screen_hw_state_property, hw_state);
-:93: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#93: FILE: drivers/gpu/drm/drm_connector.c:2474:
+static int drm_connector_privacy_screen_notifier(
-:105: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#105: FILE: drivers/gpu/drm/drm_connector.c:2486:
+ drm_sysfs_connector_status_event(connector,
+ connector->privacy_screen_sw_state_property);
-:107: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#107: FILE: drivers/gpu/drm/drm_connector.c:2488:
+ drm_sysfs_connector_status_event(connector,
+ connector->privacy_screen_hw_state_property);
-:124: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#124: FILE: drivers/gpu/drm/drm_connector.c:2505:
+void drm_connector_attach_privacy_screen_provider(
-:166: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#166: FILE: drivers/gpu/drm/drm_connector.c:2547:
+ ret = drm_privacy_screen_set_sw_state(connector->privacy_screen,
+ new_connector_state->privacy_screen_sw_state);
-:217: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#217: FILE: include/drm/drm_connector.h:1787:
+void drm_connector_attach_privacy_screen_provider(
total: 0 errors, 0 warnings, 10 checks, 185 lines checked
dbce67d00f3d platform/x86: thinkpad_acpi: Add hotkey_notify_extended_hotkey() helper
4493056b11ea platform/x86: thinkpad_acpi: Get privacy-screen / lcdshadow ACPI handles only once
d68628f78bef platform/x86: thinkpad_acpi: Register a privacy-screen device
-:90: CHECK:MULTIPLE_ASSIGNMENTS: multiple assignments should be avoided
#90: FILE: drivers/platform/x86/thinkpad_acpi.c:9845:
+ priv->hw_state = priv->sw_state = state;
-:107: CHECK:MULTIPLE_ASSIGNMENTS: multiple assignments should be avoided
#107: FILE: drivers/platform/x86/thinkpad_acpi.c:9856:
+ priv->hw_state = priv->sw_state = output & 0x1;
total: 0 errors, 0 warnings, 2 checks, 183 lines checked
ff55a0aefb53 drm/i915: Add privacy-screen support
^ permalink raw reply [flat|nested] 84+ messages in thread
* [Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm: Add privacy-screen class and connector properties (rev4)
2021-09-06 7:35 ` [Intel-gfx] " Hans de Goede
` (10 preceding siblings ...)
(?)
@ 2021-09-06 8:49 ` Patchwork
-1 siblings, 0 replies; 84+ messages in thread
From: Patchwork @ 2021-09-06 8:49 UTC (permalink / raw)
To: Hans de Goede; +Cc: intel-gfx
== Series Details ==
Series: drm: Add privacy-screen class and connector properties (rev4)
URL : https://patchwork.freedesktop.org/series/79259/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
-
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:316:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:1345:25: error: incompatible types in comparison expression (different address spaces):
+drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:1345:25: struct dma_fence *
+drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:1345:25: struct dma_fence [noderef] __rcu *
+drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:1346:17: error: incompatible types in comparison expression (different address spaces):
+drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:1346:17: struct dma_fence *
+drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:1346:17: struct dma_fence [noderef] __rcu *
+drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:1405:17: error: incompatible types in comparison expression (different address spaces):
+drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:1405:17: struct dma_fence *
+drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:1405:17: struct dma_fence [noderef] __rcu *
+drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:354:16: error: incompatible types in comparison expression (different type sizes):
+drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:354:16: unsigned long *
+drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:354:16: unsigned long long *
+drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:4483:31: error: incompatible types in comparison expression (different address spaces):
+drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:4483:31: struct dma_fence *
+drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:4483:31: struct dma_fence [noderef] __rcu *
+drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:4485:33: error: incompatible types in comparison expression (different address spaces):
+drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:4485:33: struct dma_fence *
+drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:4485:33: struct dma_fence [noderef] __rcu *
+drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c:294:25: error: incompatible types in comparison expression (different address spaces):
+drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c:294:25: struct dma_fence *
+drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c:294:25: struct dma_fence [noderef] __rcu *
+drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c:295:17: error: incompatible types in comparison expression (different address spaces):
+drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c:295:17: struct dma_fence *
+drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c:295:17: struct dma_fence [noderef] __rcu *
+drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c:344:17: error: incompatible types in comparison expression (different address spaces):
+drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c:344:17: struct dma_fence *
+drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c:344:17: struct dma_fence [noderef] __rcu *
+drivers/gpu/drm/amd/amdgpu/amdgpu_mca.c:117:1: warning: no newline at end of file
+drivers/gpu/drm/amd/amdgpu/amdgpu_ras_eeprom.h:123:51: error: marked inline, but without a definition
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2p
^ permalink raw reply [flat|nested] 84+ messages in thread
* [Intel-gfx] ✓ Fi.CI.BAT: success for drm: Add privacy-screen class and connector properties (rev4)
2021-09-06 7:35 ` [Intel-gfx] " Hans de Goede
` (11 preceding siblings ...)
(?)
@ 2021-09-06 9:17 ` Patchwork
-1 siblings, 0 replies; 84+ messages in thread
From: Patchwork @ 2021-09-06 9:17 UTC (permalink / raw)
To: Hans de Goede; +Cc: intel-gfx
[-- Attachment #1: Type: text/plain, Size: 5473 bytes --]
== Series Details ==
Series: drm: Add privacy-screen class and connector properties (rev4)
URL : https://patchwork.freedesktop.org/series/79259/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10552 -> Patchwork_20965
====================================================
Summary
-------
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/index.html
Known issues
------------
Here are the changes found in Patchwork_20965 that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@amdgpu/amd_basic@query-info:
- fi-tgl-y: NOTRUN -> [SKIP][1] ([fdo#109315])
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/fi-tgl-y/igt@amdgpu/amd_basic@query-info.html
* igt@amdgpu/amd_cs_nop@fork-gfx0:
- fi-tgl-y: NOTRUN -> [SKIP][2] ([fdo#109315] / [i915#2575]) +16 similar issues
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/fi-tgl-y/igt@amdgpu/amd_cs_nop@fork-gfx0.html
* igt@i915_selftest@live@hangcheck:
- fi-snb-2600: [PASS][3] -> [INCOMPLETE][4] ([i915#3921])
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10552/fi-snb-2600/igt@i915_selftest@live@hangcheck.html
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/fi-snb-2600/igt@i915_selftest@live@hangcheck.html
* igt@i915_selftest@live@late_gt_pm:
- fi-bsw-n3050: [PASS][5] -> [DMESG-FAIL][6] ([i915#2927] / [i915#3428])
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10552/fi-bsw-n3050/igt@i915_selftest@live@late_gt_pm.html
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/fi-bsw-n3050/igt@i915_selftest@live@late_gt_pm.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-icl-u2: [PASS][7] -> [DMESG-WARN][8] ([i915#2203] / [i915#2868])
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10552/fi-icl-u2/igt@kms_chamelium@hdmi-hpd-fast.html
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/fi-icl-u2/igt@kms_chamelium@hdmi-hpd-fast.html
* igt@runner@aborted:
- fi-bsw-n3050: NOTRUN -> [FAIL][9] ([fdo#109271] / [i915#1436] / [i915#3428])
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/fi-bsw-n3050/igt@runner@aborted.html
#### Possible fixes ####
* igt@gem_exec_suspend@basic-s0:
- fi-tgl-1115g4: [FAIL][10] ([i915#1888]) -> [PASS][11]
[10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10552/fi-tgl-1115g4/igt@gem_exec_suspend@basic-s0.html
[11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/fi-tgl-1115g4/igt@gem_exec_suspend@basic-s0.html
* igt@i915_selftest@live@execlists:
- fi-icl-y: [DMESG-FAIL][12] ([i915#1993]) -> [PASS][13]
[12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10552/fi-icl-y/igt@i915_selftest@live@execlists.html
[13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/fi-icl-y/igt@i915_selftest@live@execlists.html
* igt@i915_selftest@live@gt_lrc:
- fi-rkl-guc: [DMESG-WARN][14] ([i915#3958]) -> [PASS][15]
[14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10552/fi-rkl-guc/igt@i915_selftest@live@gt_lrc.html
[15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/fi-rkl-guc/igt@i915_selftest@live@gt_lrc.html
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
[i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436
[i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888
[i915#1993]: https://gitlab.freedesktop.org/drm/intel/issues/1993
[i915#2203]: https://gitlab.freedesktop.org/drm/intel/issues/2203
[i915#2575]: https://gitlab.freedesktop.org/drm/intel/issues/2575
[i915#2868]: https://gitlab.freedesktop.org/drm/intel/issues/2868
[i915#2927]: https://gitlab.freedesktop.org/drm/intel/issues/2927
[i915#3428]: https://gitlab.freedesktop.org/drm/intel/issues/3428
[i915#3921]: https://gitlab.freedesktop.org/drm/intel/issues/3921
[i915#3958]: https://gitlab.freedesktop.org/drm/intel/issues/3958
Participating hosts (46 -> 37)
------------------------------
Missing (9): fi-kbl-soraka bat-adls-5 bat-dg1-6 bat-dg1-5 fi-bsw-cyan bat-adlp-4 fi-kbl-guc fi-bdw-samus bat-jsl-1
Build changes
-------------
* Linux: CI_DRM_10552 -> Patchwork_20965
CI-20190529: 20190529
CI_DRM_10552: 931230aae7f70bb270bb3a50b160a765699f87c2 @ git://anongit.freedesktop.org/gfx-ci/linux
IGT_6197: 40888f97a6ad219f4ed48a1830d0ef3c9617d006 @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_20965: ff55a0aefb5373fb248923443c4b42003c5e3f6d @ git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
ff55a0aefb53 drm/i915: Add privacy-screen support
d68628f78bef platform/x86: thinkpad_acpi: Register a privacy-screen device
4493056b11ea platform/x86: thinkpad_acpi: Get privacy-screen / lcdshadow ACPI handles only once
dbce67d00f3d platform/x86: thinkpad_acpi: Add hotkey_notify_extended_hotkey() helper
016dd07be125 drm/connector: Add a drm_connector privacy-screen helper functions
5112840ff391 drm/privacy-screen: Add notifier support
4c5269c0a347 drm/privacy-screen: Add X86 specific arch init code
103f4901ff19 drm: Add privacy-screen class (v3)
bc1b50a446f7 drm/connector: Add support for privacy-screen properties (v4)
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/index.html
[-- Attachment #2: Type: text/html, Size: 6463 bytes --]
^ permalink raw reply [flat|nested] 84+ messages in thread
* [Intel-gfx] ✗ Fi.CI.IGT: failure for drm: Add privacy-screen class and connector properties (rev4)
2021-09-06 7:35 ` [Intel-gfx] " Hans de Goede
` (12 preceding siblings ...)
(?)
@ 2021-09-06 11:16 ` Patchwork
-1 siblings, 0 replies; 84+ messages in thread
From: Patchwork @ 2021-09-06 11:16 UTC (permalink / raw)
To: Hans de Goede; +Cc: intel-gfx
[-- Attachment #1: Type: text/plain, Size: 30284 bytes --]
== Series Details ==
Series: drm: Add privacy-screen class and connector properties (rev4)
URL : https://patchwork.freedesktop.org/series/79259/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10552_full -> Patchwork_20965_full
====================================================
Summary
-------
**FAILURE**
Serious unknown changes coming with Patchwork_20965_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_20965_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
Possible new issues
-------------------
Here are the unknown changes that may have been introduced in Patchwork_20965_full:
### IGT changes ###
#### Possible regressions ####
* igt@gem_userptr_blits@huge-split:
- shard-snb: [PASS][1] -> [FAIL][2]
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10552/shard-snb5/igt@gem_userptr_blits@huge-split.html
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-snb7/igt@gem_userptr_blits@huge-split.html
* igt@gem_workarounds@basic-read-fd:
- shard-snb: NOTRUN -> [TIMEOUT][3]
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-snb2/igt@gem_workarounds@basic-read-fd.html
#### Suppressed ####
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_pm_rps@reset:
- {shard-rkl}: [PASS][4] -> [FAIL][5]
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10552/shard-rkl-2/igt@i915_pm_rps@reset.html
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-rkl-6/igt@i915_pm_rps@reset.html
Known issues
------------
Here are the changes found in Patchwork_20965_full that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@feature_discovery@chamelium:
- shard-tglb: NOTRUN -> [SKIP][6] ([fdo#111827])
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-tglb6/igt@feature_discovery@chamelium.html
* igt@gem_create@create-massive:
- shard-apl: NOTRUN -> [DMESG-WARN][7] ([i915#3002])
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-apl6/igt@gem_create@create-massive.html
* igt@gem_ctx_persistence@legacy-engines-mixed:
- shard-snb: NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#1099]) +5 similar issues
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-snb5/igt@gem_ctx_persistence@legacy-engines-mixed.html
* igt@gem_eio@unwedge-stress:
- shard-snb: NOTRUN -> [FAIL][9] ([i915#3354])
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-snb5/igt@gem_eio@unwedge-stress.html
* igt@gem_exec_fair@basic-flow@rcs0:
- shard-skl: NOTRUN -> [SKIP][10] ([fdo#109271]) +155 similar issues
[10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-skl7/igt@gem_exec_fair@basic-flow@rcs0.html
* igt@gem_exec_fair@basic-none-share@rcs0:
- shard-tglb: [PASS][11] -> [FAIL][12] ([i915#2842])
[11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10552/shard-tglb1/igt@gem_exec_fair@basic-none-share@rcs0.html
[12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-tglb6/igt@gem_exec_fair@basic-none-share@rcs0.html
- shard-apl: [PASS][13] -> [SKIP][14] ([fdo#109271])
[13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10552/shard-apl8/igt@gem_exec_fair@basic-none-share@rcs0.html
[14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-apl1/igt@gem_exec_fair@basic-none-share@rcs0.html
* igt@gem_exec_fair@basic-none@vcs1:
- shard-iclb: NOTRUN -> [FAIL][15] ([i915#2842])
[15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-iclb1/igt@gem_exec_fair@basic-none@vcs1.html
* igt@gem_exec_fair@basic-pace@vecs0:
- shard-kbl: [PASS][16] -> [FAIL][17] ([i915#2842]) +1 similar issue
[16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10552/shard-kbl7/igt@gem_exec_fair@basic-pace@vecs0.html
[17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-kbl6/igt@gem_exec_fair@basic-pace@vecs0.html
* igt@gem_huc_copy@huc-copy:
- shard-apl: NOTRUN -> [SKIP][18] ([fdo#109271] / [i915#2190])
[18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-apl7/igt@gem_huc_copy@huc-copy.html
* igt@gem_pread@exhaustion:
- shard-apl: NOTRUN -> [WARN][19] ([i915#2658])
[19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-apl2/igt@gem_pread@exhaustion.html
- shard-snb: NOTRUN -> [WARN][20] ([i915#2658])
[20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-snb6/igt@gem_pread@exhaustion.html
* igt@gem_userptr_blits@dmabuf-sync:
- shard-apl: NOTRUN -> [SKIP][21] ([fdo#109271] / [i915#3323])
[21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-apl1/igt@gem_userptr_blits@dmabuf-sync.html
- shard-skl: NOTRUN -> [SKIP][22] ([fdo#109271] / [i915#3323])
[22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-skl7/igt@gem_userptr_blits@dmabuf-sync.html
- shard-glk: NOTRUN -> [SKIP][23] ([fdo#109271] / [i915#3323])
[23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-glk1/igt@gem_userptr_blits@dmabuf-sync.html
* igt@gem_userptr_blits@input-checking:
- shard-snb: NOTRUN -> [DMESG-WARN][24] ([i915#3002])
[24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-snb5/igt@gem_userptr_blits@input-checking.html
* igt@gem_userptr_blits@vma-merge:
- shard-snb: NOTRUN -> [FAIL][25] ([i915#2724])
[25]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-snb2/igt@gem_userptr_blits@vma-merge.html
- shard-apl: NOTRUN -> [FAIL][26] ([i915#3318])
[26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-apl1/igt@gem_userptr_blits@vma-merge.html
- shard-glk: NOTRUN -> [FAIL][27] ([i915#3318])
[27]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-glk1/igt@gem_userptr_blits@vma-merge.html
- shard-skl: NOTRUN -> [FAIL][28] ([i915#3318])
[28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-skl7/igt@gem_userptr_blits@vma-merge.html
* igt@i915_pm_rc6_residency@rc6-fence:
- shard-iclb: NOTRUN -> [WARN][29] ([i915#1804] / [i915#2684])
[29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-iclb3/igt@i915_pm_rc6_residency@rc6-fence.html
* igt@i915_selftest@live@hangcheck:
- shard-snb: [PASS][30] -> [INCOMPLETE][31] ([i915#3921])
[30]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10552/shard-snb2/igt@i915_selftest@live@hangcheck.html
[31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-snb5/igt@i915_selftest@live@hangcheck.html
* igt@kms_big_fb@x-tiled-max-hw-stride-32bpp-rotate-180-hflip:
- shard-apl: NOTRUN -> [SKIP][32] ([fdo#109271] / [i915#3777]) +1 similar issue
[32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-apl7/igt@kms_big_fb@x-tiled-max-hw-stride-32bpp-rotate-180-hflip.html
* igt@kms_big_fb@yf-tiled-max-hw-stride-32bpp-rotate-180-hflip:
- shard-skl: NOTRUN -> [SKIP][33] ([fdo#109271] / [i915#3777])
[33]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-skl7/igt@kms_big_fb@yf-tiled-max-hw-stride-32bpp-rotate-180-hflip.html
* igt@kms_ccs@pipe-b-bad-pixel-format-y_tiled_ccs:
- shard-snb: NOTRUN -> [SKIP][34] ([fdo#109271]) +505 similar issues
[34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-snb2/igt@kms_ccs@pipe-b-bad-pixel-format-y_tiled_ccs.html
* igt@kms_ccs@pipe-b-bad-pixel-format-y_tiled_gen12_mc_ccs:
- shard-kbl: NOTRUN -> [SKIP][35] ([fdo#109271] / [i915#3886])
[35]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-kbl7/igt@kms_ccs@pipe-b-bad-pixel-format-y_tiled_gen12_mc_ccs.html
* igt@kms_ccs@pipe-b-ccs-on-another-bo-y_tiled_gen12_rc_ccs_cc:
- shard-skl: NOTRUN -> [SKIP][36] ([fdo#109271] / [i915#3886]) +6 similar issues
[36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-skl7/igt@kms_ccs@pipe-b-ccs-on-another-bo-y_tiled_gen12_rc_ccs_cc.html
* igt@kms_ccs@pipe-b-crc-sprite-planes-basic-y_tiled_gen12_rc_ccs_cc:
- shard-apl: NOTRUN -> [SKIP][37] ([fdo#109271] / [i915#3886]) +13 similar issues
[37]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-apl7/igt@kms_ccs@pipe-b-crc-sprite-planes-basic-y_tiled_gen12_rc_ccs_cc.html
* igt@kms_ccs@pipe-c-crc-primary-basic-yf_tiled_ccs:
- shard-tglb: NOTRUN -> [SKIP][38] ([i915#3689])
[38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-tglb6/igt@kms_ccs@pipe-c-crc-primary-basic-yf_tiled_ccs.html
* igt@kms_ccs@pipe-c-crc-primary-rotation-180-y_tiled_gen12_mc_ccs:
- shard-glk: NOTRUN -> [SKIP][39] ([fdo#109271] / [i915#3886]) +1 similar issue
[39]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-glk1/igt@kms_ccs@pipe-c-crc-primary-rotation-180-y_tiled_gen12_mc_ccs.html
* igt@kms_chamelium@dp-mode-timings:
- shard-apl: NOTRUN -> [SKIP][40] ([fdo#109271] / [fdo#111827]) +25 similar issues
[40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-apl7/igt@kms_chamelium@dp-mode-timings.html
* igt@kms_chamelium@hdmi-aspect-ratio:
- shard-skl: NOTRUN -> [SKIP][41] ([fdo#109271] / [fdo#111827]) +11 similar issues
[41]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-skl2/igt@kms_chamelium@hdmi-aspect-ratio.html
* igt@kms_color_chamelium@pipe-b-ctm-0-25:
- shard-snb: NOTRUN -> [SKIP][42] ([fdo#109271] / [fdo#111827]) +26 similar issues
[42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-snb5/igt@kms_color_chamelium@pipe-b-ctm-0-25.html
* igt@kms_color_chamelium@pipe-b-ctm-limited-range:
- shard-glk: NOTRUN -> [SKIP][43] ([fdo#109271] / [fdo#111827]) +2 similar issues
[43]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-glk1/igt@kms_color_chamelium@pipe-b-ctm-limited-range.html
* igt@kms_color_chamelium@pipe-b-ctm-negative:
- shard-tglb: NOTRUN -> [SKIP][44] ([fdo#109284] / [fdo#111827]) +1 similar issue
[44]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-tglb6/igt@kms_color_chamelium@pipe-b-ctm-negative.html
* igt@kms_content_protection@lic:
- shard-apl: NOTRUN -> [TIMEOUT][45] ([i915#1319]) +2 similar issues
[45]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-apl6/igt@kms_content_protection@lic.html
* igt@kms_content_protection@uevent:
- shard-apl: NOTRUN -> [FAIL][46] ([i915#2105])
[46]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-apl7/igt@kms_content_protection@uevent.html
* igt@kms_cursor_crc@pipe-b-cursor-max-size-sliding:
- shard-iclb: NOTRUN -> [SKIP][47] ([fdo#109278]) +2 similar issues
[47]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-iclb3/igt@kms_cursor_crc@pipe-b-cursor-max-size-sliding.html
* igt@kms_cursor_crc@pipe-d-cursor-256x256-rapid-movement:
- shard-kbl: NOTRUN -> [SKIP][48] ([fdo#109271]) +22 similar issues
[48]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-kbl1/igt@kms_cursor_crc@pipe-d-cursor-256x256-rapid-movement.html
* igt@kms_cursor_crc@pipe-d-cursor-max-size-sliding:
- shard-tglb: NOTRUN -> [SKIP][49] ([i915#3359])
[49]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-tglb6/igt@kms_cursor_crc@pipe-d-cursor-max-size-sliding.html
* igt@kms_cursor_legacy@cursora-vs-flipb-varying-size:
- shard-iclb: NOTRUN -> [SKIP][50] ([fdo#109274] / [fdo#109278])
[50]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-iclb7/igt@kms_cursor_legacy@cursora-vs-flipb-varying-size.html
* igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size:
- shard-skl: [PASS][51] -> [FAIL][52] ([i915#2346] / [i915#533])
[51]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10552/shard-skl3/igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size.html
[52]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-skl3/igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size.html
* igt@kms_cursor_legacy@pipe-d-torture-bo:
- shard-glk: NOTRUN -> [SKIP][53] ([fdo#109271] / [i915#533])
[53]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-glk1/igt@kms_cursor_legacy@pipe-d-torture-bo.html
- shard-skl: NOTRUN -> [SKIP][54] ([fdo#109271] / [i915#533]) +1 similar issue
[54]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-skl7/igt@kms_cursor_legacy@pipe-d-torture-bo.html
* igt@kms_fbcon_fbt@fbc-suspend:
- shard-apl: NOTRUN -> [INCOMPLETE][55] ([i915#180])
[55]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-apl2/igt@kms_fbcon_fbt@fbc-suspend.html
- shard-kbl: [PASS][56] -> [INCOMPLETE][57] ([i915#155] / [i915#180] / [i915#636])
[56]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10552/shard-kbl2/igt@kms_fbcon_fbt@fbc-suspend.html
[57]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-kbl4/igt@kms_fbcon_fbt@fbc-suspend.html
* igt@kms_flip@flip-vs-expired-vblank-interruptible@a-edp1:
- shard-skl: [PASS][58] -> [FAIL][59] ([i915#79])
[58]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10552/shard-skl6/igt@kms_flip@flip-vs-expired-vblank-interruptible@a-edp1.html
[59]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-skl5/igt@kms_flip@flip-vs-expired-vblank-interruptible@a-edp1.html
* igt@kms_flip@flip-vs-suspend@c-dp1:
- shard-apl: [PASS][60] -> [DMESG-WARN][61] ([i915#180]) +3 similar issues
[60]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10552/shard-apl1/igt@kms_flip@flip-vs-suspend@c-dp1.html
[61]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-apl2/igt@kms_flip@flip-vs-suspend@c-dp1.html
* igt@kms_flip@plain-flip-ts-check@c-edp1:
- shard-skl: [PASS][62] -> [FAIL][63] ([i915#2122])
[62]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10552/shard-skl3/igt@kms_flip@plain-flip-ts-check@c-edp1.html
[63]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-skl4/igt@kms_flip@plain-flip-ts-check@c-edp1.html
* igt@kms_flip_scaled_crc@flip-32bpp-ytile-to-32bpp-ytilegen12rcccs:
- shard-skl: NOTRUN -> [SKIP][64] ([fdo#109271] / [i915#2672])
[64]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-skl2/igt@kms_flip_scaled_crc@flip-32bpp-ytile-to-32bpp-ytilegen12rcccs.html
- shard-iclb: NOTRUN -> [SKIP][65] ([i915#2587])
[65]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-iclb7/igt@kms_flip_scaled_crc@flip-32bpp-ytile-to-32bpp-ytilegen12rcccs.html
* igt@kms_flip_scaled_crc@flip-32bpp-ytile-to-64bpp-ytile:
- shard-iclb: [PASS][66] -> [SKIP][67] ([i915#3701])
[66]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10552/shard-iclb4/igt@kms_flip_scaled_crc@flip-32bpp-ytile-to-64bpp-ytile.html
[67]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-iclb2/igt@kms_flip_scaled_crc@flip-32bpp-ytile-to-64bpp-ytile.html
* igt@kms_flip_scaled_crc@flip-64bpp-ytile-to-32bpp-ytilercccs:
- shard-apl: NOTRUN -> [SKIP][68] ([fdo#109271] / [i915#2672])
[68]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-apl7/igt@kms_flip_scaled_crc@flip-64bpp-ytile-to-32bpp-ytilercccs.html
* igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-indfb-pgflip-blt:
- shard-tglb: NOTRUN -> [SKIP][69] ([fdo#111825])
[69]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-tglb6/igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-indfb-pgflip-blt.html
* igt@kms_frontbuffer_tracking@fbcpsr-2p-scndscrn-indfb-pgflip-blt:
- shard-glk: NOTRUN -> [SKIP][70] ([fdo#109271]) +36 similar issues
[70]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-glk1/igt@kms_frontbuffer_tracking@fbcpsr-2p-scndscrn-indfb-pgflip-blt.html
* igt@kms_frontbuffer_tracking@psr-1p-primscrn-pri-indfb-draw-mmap-cpu:
- shard-skl: [PASS][71] -> [DMESG-WARN][72] ([i915#1982]) +1 similar issue
[71]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10552/shard-skl10/igt@kms_frontbuffer_tracking@psr-1p-primscrn-pri-indfb-draw-mmap-cpu.html
[72]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-skl1/igt@kms_frontbuffer_tracking@psr-1p-primscrn-pri-indfb-draw-mmap-cpu.html
* igt@kms_frontbuffer_tracking@psr-2p-scndscrn-spr-indfb-fullscreen:
- shard-iclb: NOTRUN -> [SKIP][73] ([fdo#109280])
[73]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-iclb7/igt@kms_frontbuffer_tracking@psr-2p-scndscrn-spr-indfb-fullscreen.html
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- shard-kbl: [PASS][74] -> [DMESG-WARN][75] ([i915#180]) +2 similar issues
[74]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10552/shard-kbl2/igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a.html
[75]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-kbl4/igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a.html
* igt@kms_plane_alpha_blend@pipe-a-alpha-7efc:
- shard-skl: NOTRUN -> [FAIL][76] ([fdo#108145] / [i915#265]) +1 similar issue
[76]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-skl2/igt@kms_plane_alpha_blend@pipe-a-alpha-7efc.html
* igt@kms_plane_alpha_blend@pipe-a-constant-alpha-max:
- shard-glk: NOTRUN -> [FAIL][77] ([fdo#108145] / [i915#265])
[77]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-glk1/igt@kms_plane_alpha_blend@pipe-a-constant-alpha-max.html
* igt@kms_plane_alpha_blend@pipe-b-alpha-opaque-fb:
- shard-apl: NOTRUN -> [FAIL][78] ([fdo#108145] / [i915#265]) +2 similar issues
[78]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-apl7/igt@kms_plane_alpha_blend@pipe-b-alpha-opaque-fb.html
* igt@kms_plane_alpha_blend@pipe-b-constant-alpha-min:
- shard-skl: [PASS][79] -> [FAIL][80] ([fdo#108145] / [i915#265])
[79]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10552/shard-skl2/igt@kms_plane_alpha_blend@pipe-b-constant-alpha-min.html
[80]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-skl6/igt@kms_plane_alpha_blend@pipe-b-constant-alpha-min.html
* igt@kms_plane_scaling@scaler-with-clipping-clamping@pipe-c-scaler-with-clipping-clamping:
- shard-skl: NOTRUN -> [SKIP][81] ([fdo#109271] / [i915#2733])
[81]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-skl7/igt@kms_plane_scaling@scaler-with-clipping-clamping@pipe-c-scaler-with-clipping-clamping.html
* igt@kms_psr2_sf@overlay-plane-update-sf-dmg-area-4:
- shard-apl: NOTRUN -> [SKIP][82] ([fdo#109271] / [i915#658]) +7 similar issues
[82]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-apl3/igt@kms_psr2_sf@overlay-plane-update-sf-dmg-area-4.html
* igt@kms_psr2_sf@primary-plane-update-sf-dmg-area-1:
- shard-skl: NOTRUN -> [SKIP][83] ([fdo#109271] / [i915#658]) +3 similar issues
[83]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-skl2/igt@kms_psr2_sf@primary-plane-update-sf-dmg-area-1.html
* igt@kms_psr2_su@page_flip:
- shard-glk: NOTRUN -> [SKIP][84] ([fdo#109271] / [i915#658]) +1 similar issue
[84]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-glk1/igt@kms_psr2_su@page_flip.html
* igt@kms_psr@psr2_sprite_mmap_gtt:
- shard-iclb: [PASS][85] -> [SKIP][86] ([fdo#109441]) +1 similar issue
[85]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10552/shard-iclb2/igt@kms_psr@psr2_sprite_mmap_gtt.html
[86]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-iclb3/igt@kms_psr@psr2_sprite_mmap_gtt.html
* igt@kms_setmode@basic:
- shard-snb: NOTRUN -> [FAIL][87] ([i915#31])
[87]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-snb6/igt@kms_setmode@basic.html
* igt@kms_vblank@pipe-d-wait-idle:
- shard-apl: NOTRUN -> [SKIP][88] ([fdo#109271] / [i915#533]) +4 similar issues
[88]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-apl7/igt@kms_vblank@pipe-d-wait-idle.html
* igt@nouveau_crc@pipe-b-ctx-flip-skip-current-frame:
- shard-apl: NOTRUN -> [SKIP][89] ([fdo#109271]) +308 similar issues
[89]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-apl7/igt@nouveau_crc@pipe-b-ctx-flip-skip-current-frame.html
* igt@perf@polling:
- shard-skl: [PASS][90] -> [FAIL][91] ([i915#1542])
[90]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10552/shard-skl5/igt@perf@polling.html
[91]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-skl8/igt@perf@polling.html
* igt@prime_udl:
- shard-iclb: NOTRUN -> [SKIP][92] ([fdo#109291])
[92]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-iclb3/igt@prime_udl.html
* igt@sysfs_clients@fair-7:
- shard-apl: NOTRUN -> [SKIP][93] ([fdo#109271] / [i915#2994]) +8 similar issues
[93]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-apl2/igt@sysfs_clients@fair-7.html
* igt@sysfs_clients@recycle-many:
- shard-glk: NOTRUN -> [SKIP][94] ([fdo#109271] / [i915#2994]) +1 similar issue
[94]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-glk1/igt@sysfs_clients@recycle-many.html
- shard-skl: NOTRUN -> [SKIP][95] ([fdo#109271] / [i915#2994]) +1 similar issue
[95]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-skl7/igt@sysfs_clients@recycle-many.html
#### Possible fixes ####
* igt@fbdev@nullptr:
- {shard-rkl}: [SKIP][96] ([i915#2582]) -> [PASS][97]
[96]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10552/shard-rkl-1/igt@fbdev@nullptr.html
[97]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-rkl-6/igt@fbdev@nullptr.html
* igt@feature_discovery@psr2:
- shard-iclb: [SKIP][98] ([i915#658]) -> [PASS][99]
[98]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10552/shard-iclb4/igt@feature_discovery@psr2.html
[99]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-iclb2/igt@feature_discovery@psr2.html
* igt@gem_eio@hibernate:
- {shard-rkl}: [INCOMPLETE][100] ([i915#3189] / [i915#3811] / [i915#3833]) -> [PASS][101]
[100]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10552/shard-rkl-2/igt@gem_eio@hibernate.html
[101]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-rkl-6/igt@gem_eio@hibernate.html
* igt@gem_eio@unwedge-stress:
- shard-iclb: [TIMEOUT][102] ([i915#2369] / [i915#2481] / [i915#3070]) -> [PASS][103]
[102]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10552/shard-iclb5/igt@gem_eio@unwedge-stress.html
[103]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-iclb8/igt@gem_eio@unwedge-stress.html
* igt@gem_exec_fair@basic-flow@rcs0:
- shard-tglb: [FAIL][104] ([i915#2842]) -> [PASS][105] +1 similar issue
[104]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10552/shard-tglb7/igt@gem_exec_fair@basic-flow@rcs0.html
[105]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-tglb7/igt@gem_exec_fair@basic-flow@rcs0.html
* igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-glk: [FAIL][106] ([i915#2842]) -> [PASS][107]
[106]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10552/shard-glk3/igt@gem_exec_fair@basic-pace-share@rcs0.html
[107]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-glk7/igt@gem_exec_fair@basic-pace-share@rcs0.html
* igt@gem_exec_fair@basic-pace@vcs1:
- shard-kbl: [FAIL][108] ([i915#2842]) -> [PASS][109] +2 similar issues
[108]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10552/shard-kbl7/igt@gem_exec_fair@basic-pace@vcs1.html
[109]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-kbl6/igt@gem_exec_fair@basic-pace@vcs1.html
* igt@gem_exec_fair@basic-throttle@rcs0:
- {shard-rkl}: [FAIL][110] ([i915#2842]) -> [PASS][111] +2 similar issues
[110]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10552/shard-rkl-6/igt@gem_exec_fair@basic-throttle@rcs0.html
[111]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-rkl-2/igt@gem_exec_fair@basic-throttle@rcs0.html
- shard-iclb: [FAIL][112] ([i915#2842]) -> [PASS][113]
[112]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10552/shard-iclb3/igt@gem_exec_fair@basic-throttle@rcs0.html
[113]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-iclb2/igt@gem_exec_fair@basic-throttle@rcs0.html
* igt@gem_mmap_gtt@cpuset-big-copy-odd:
- shard-glk: [FAIL][114] ([i915#1888] / [i915#307]) -> [PASS][115]
[114]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10552/shard-glk1/igt@gem_mmap_gtt@cpuset-big-copy-odd.html
[115]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-glk2/igt@gem_mmap_gtt@cpuset-big-copy-odd.html
* igt@gen9_exec_parse@allowed-all:
- shard-glk: [DMESG-WARN][116] ([i915#1436] / [i915#716]) -> [PASS][117]
[116]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10552/shard-glk3/igt@gen9_exec_parse@allowed-all.html
[117]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-glk1/igt@gen9_exec_parse@allowed-all.html
* igt@i915_pm_backlight@fade_with_suspend:
- shard-skl: [INCOMPLETE][118] ([i915#198]) -> [PASS][119] +1 similar issue
[118]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10552/shard-skl8/igt@i915_pm_backlight@fade_with_suspend.html
[119]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-skl7/igt@i915_pm_backlight@fade_with_suspend.html
- {shard-rkl}: [SKIP][120] ([i915#3012]) -> [PASS][121]
[120]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10552/shard-rkl-1/igt@i915_pm_backlight@fade_with_suspend.html
[121]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-rkl-6/igt@i915_pm_backlight@fade_with_suspend.html
* igt@i915_pm_rpm@dpms-lpsp:
- {shard-rkl}: [SKIP][122] ([i915#1397]) -> [PASS][123]
[122]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10552/shard-rkl-1/igt@i915_pm_rpm@dpms-lpsp.html
[123]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-rkl-6/igt@i915_pm_rpm@dpms-lpsp.html
* igt@kms_big_fb@linear-8bpp-rotate-0:
- {shard-rkl}: [SKIP][124] ([i915#3638]) -> [PASS][125] +4 similar issues
[124]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10552/shard-rkl-1/igt@kms_big_fb@linear-8bpp-rotate-0.html
[125]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-rkl-6/igt@kms_big_fb@linear-8bpp-rotate-0.html
* igt@kms_big_fb@x-tiled-32bpp-rotate-180:
- shard-glk: [DMESG-WARN][126] ([i915#118] / [i915#95]) -> [PASS][127]
[126]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10552/shard-glk2/igt@kms_big_fb@x-tiled-32bpp-rotate-180.html
[127]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-glk5/igt@kms_big_fb@x-tiled-32bpp-rotate-180.html
* igt@kms_big_fb@x-tiled-max-hw-stride-32bpp-rotate-180-hflip-async-flip:
- {shard-rkl}: [SKIP][128] ([i915#3721]) -> [PASS][129] +6 similar issues
[128]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10552/shard-rkl-1/igt@kms_big_fb@x-tiled-max-hw-stride-32bpp-rotate-180-hflip-async-flip.html
[129]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-rkl-6/igt@kms_big_fb@x-tiled-max-hw-stride-32bpp-rotate-180-hflip-async-flip.html
* igt@kms_big_fb@x-tiled-max-hw-stride-64bpp-rotate-0-hflip-async-flip:
- shard-iclb: [DMESG-WARN][130] ([i915#3621]) -> [PASS][131]
[130]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10552/shard-iclb1/igt@kms_big_fb@x-tiled-max-hw-stride-64bpp-rotate-0-hflip-async-flip.html
[131]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-iclb7/igt@kms_big_fb@x-tiled-max-hw-stride-64bpp-rotate-0-hflip-async-flip.html
* igt@kms_ccs@pipe-a-crc-sprite-planes-basic-y_tiled_gen12_rc_ccs:
- {shard-rkl}: [SKIP][132] ([i915#1845]) -> [PASS][133] +25 similar issues
[132]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10552/shard-rkl-2/igt@kms_ccs@pipe-a-crc-sprite-planes-basic-y_tiled_gen12_rc_ccs.html
[133]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-rkl-6/igt@kms_ccs@pipe-a-crc-sprite-planes-basic-y_tiled_gen12_rc_ccs.html
* igt@kms_color@pipe-a-ctm-0-75:
- {shard-rkl}: [SKIP][134] ([i915#1149] / [i915#1849] / [i915#4070]) -> [PASS][135] +3 similar issues
[134]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10552/shard-rkl-2/igt@kms_color@pipe-a-ctm-0-75.html
[135]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-rkl-6/igt@kms_color@pipe-a-ctm-0-75.html
* igt@kms_concurrent@pipe-a:
- {shard-rkl}: [SKIP][136] ([i915#1845] / [i915#4070]) -> [PASS][137] +2 similar issues
[136]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10552/shard-rkl-2/igt@kms_concurrent@pipe-a.html
[137]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/shard-rkl-6/igt@kms_concurrent@pipe-a.html
* igt@kms_cursor_crc@pipe-b-cursor-64x21-random:
- {shard-rkl}: [SKIP][138] ([fdo#112022] / [i915#4070]) -> [PASS][139] +9 similar issues
[138]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10552/shard-rkl-2/igt@kms_cursor_crc@pipe-b-cursor-64x21-random.html
[139]: https://intel-gfx-ci.01.org/tree/drm-tip/Patch
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20965/index.html
[-- Attachment #2: Type: text/html, Size: 33550 bytes --]
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [PATCH 1/9] drm/connector: Add support for privacy-screen properties (v4)
2021-09-06 7:35 ` [Intel-gfx] " Hans de Goede
(?)
@ 2021-09-15 19:48 ` Lyude Paul
-1 siblings, 0 replies; 84+ messages in thread
From: Lyude Paul @ 2021-09-15 19:48 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, Mario Limonciello
On Mon, 2021-09-06 at 09:35 +0200, Hans de Goede wrote:
> 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>
> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.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 1ef7951ded5e..d14bf1c35d7e 100644
> --- a/Documentation/gpu/drm-kms.rst
> +++ b/Documentation/gpu/drm-kms.rst
> @@ -506,6 +506,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 909f31833181..cdd31fc78bfc 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -797,6 +797,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);
> @@ -874,6 +876,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 e0a30e0ee86a..dd1ca68881ba 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -1264,6 +1264,46 @@ static const struct drm_prop_enum_list
> dp_colorspaces[] = {
> * For DVI-I and TVout there is also a matching property "select
> subconnector"
> * allowing to switch between signal types.
> * DP subconnector corresponds to a downstream port.
> + *
> + * 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)
> @@ -2341,6 +2381,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 79fa34e5ccdb..1acbcf0626ce 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -320,6 +320,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
> @@ -781,6 +805,12 @@ struct drm_connector_state {
> */
> u8 max_bpc;
>
> + /**
> + * @privacy_screen_sw_state: See :ref:`Standard Connector
> + * Properties<standard_connector_properties>`
> + */
So THAT'S how you reference other sections. I've always wondered!
> + enum drm_privacy_screen_status privacy_screen_sw_state;
> +
> /**
> * @hdr_output_metadata:
> * DRM blob property for HDR output metadata
> @@ -1409,6 +1439,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)
> @@ -1732,6 +1774,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
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [PATCH 1/9] drm/connector: Add support for privacy-screen properties (v4)
@ 2021-09-15 19:48 ` Lyude Paul
0 siblings, 0 replies; 84+ messages in thread
From: Lyude Paul @ 2021-09-15 19:48 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, Mario Limonciello
On Mon, 2021-09-06 at 09:35 +0200, Hans de Goede wrote:
> 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>
> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.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 1ef7951ded5e..d14bf1c35d7e 100644
> --- a/Documentation/gpu/drm-kms.rst
> +++ b/Documentation/gpu/drm-kms.rst
> @@ -506,6 +506,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 909f31833181..cdd31fc78bfc 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -797,6 +797,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);
> @@ -874,6 +876,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 e0a30e0ee86a..dd1ca68881ba 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -1264,6 +1264,46 @@ static const struct drm_prop_enum_list
> dp_colorspaces[] = {
> * For DVI-I and TVout there is also a matching property "select
> subconnector"
> * allowing to switch between signal types.
> * DP subconnector corresponds to a downstream port.
> + *
> + * 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)
> @@ -2341,6 +2381,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 79fa34e5ccdb..1acbcf0626ce 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -320,6 +320,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
> @@ -781,6 +805,12 @@ struct drm_connector_state {
> */
> u8 max_bpc;
>
> + /**
> + * @privacy_screen_sw_state: See :ref:`Standard Connector
> + * Properties<standard_connector_properties>`
> + */
So THAT'S how you reference other sections. I've always wondered!
> + enum drm_privacy_screen_status privacy_screen_sw_state;
> +
> /**
> * @hdr_output_metadata:
> * DRM blob property for HDR output metadata
> @@ -1409,6 +1439,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)
> @@ -1732,6 +1774,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
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [Intel-gfx] [PATCH 1/9] drm/connector: Add support for privacy-screen properties (v4)
@ 2021-09-15 19:48 ` Lyude Paul
0 siblings, 0 replies; 84+ messages in thread
From: Lyude Paul @ 2021-09-15 19:48 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, Mario Limonciello
On Mon, 2021-09-06 at 09:35 +0200, Hans de Goede wrote:
> 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>
> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.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 1ef7951ded5e..d14bf1c35d7e 100644
> --- a/Documentation/gpu/drm-kms.rst
> +++ b/Documentation/gpu/drm-kms.rst
> @@ -506,6 +506,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 909f31833181..cdd31fc78bfc 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -797,6 +797,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);
> @@ -874,6 +876,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 e0a30e0ee86a..dd1ca68881ba 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -1264,6 +1264,46 @@ static const struct drm_prop_enum_list
> dp_colorspaces[] = {
> * For DVI-I and TVout there is also a matching property "select
> subconnector"
> * allowing to switch between signal types.
> * DP subconnector corresponds to a downstream port.
> + *
> + * 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)
> @@ -2341,6 +2381,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 79fa34e5ccdb..1acbcf0626ce 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -320,6 +320,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
> @@ -781,6 +805,12 @@ struct drm_connector_state {
> */
> u8 max_bpc;
>
> + /**
> + * @privacy_screen_sw_state: See :ref:`Standard Connector
> + * Properties<standard_connector_properties>`
> + */
So THAT'S how you reference other sections. I've always wondered!
> + enum drm_privacy_screen_status privacy_screen_sw_state;
> +
> /**
> * @hdr_output_metadata:
> * DRM blob property for HDR output metadata
> @@ -1409,6 +1439,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)
> @@ -1732,6 +1774,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
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [PATCH 2/9] drm: Add privacy-screen class (v3)
2021-09-06 7:35 ` [Intel-gfx] " Hans de Goede
(?)
@ 2021-09-15 20:01 ` Lyude Paul
-1 siblings, 0 replies; 84+ messages in thread
From: Lyude Paul @ 2021-09-15 20:01 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
On Mon, 2021-09-06 at 09:35 +0200, Hans de Goede wrote:
> 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.
>
> Changes in v2:
> - Make CONFIG_DRM_PRIVACY_SCREEN a bool which controls if the drm_privacy
> code gets built as part of the main drm module rather then making it
> a tristate which builds its own module.
> - Add a #if IS_ENABLED(CONFIG_DRM_PRIVACY_SCREEN) check to
> drm_privacy_screen_consumer.h and define stubs when the check fails.
> Together these 2 changes fix several dependency issues.
> - Remove module related code now that this is part of the main drm.ko
> - Use drm_class as class for the privacy-screen devices instead of
> adding a separate class for this
>
> Changes in v3:
> - Make the static inline drm_privacy_screen_get_state() stub set sw_state
> and hw_state to PRIVACY_SCREEN_DISABLED to squelch an uninitialized
> variable warning when CONFIG_DRM_PRIVICAY_SCREEN is not set
>
> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> ---
> Documentation/gpu/drm-kms-helpers.rst | 15 +
> MAINTAINERS | 8 +
> drivers/gpu/drm/Kconfig | 4 +
> drivers/gpu/drm/Makefile | 1 +
> drivers/gpu/drm/drm_drv.c | 4 +
> drivers/gpu/drm/drm_privacy_screen.c | 401 ++++++++++++++++++++++
> include/drm/drm_privacy_screen_consumer.h | 50 +++
> include/drm/drm_privacy_screen_driver.h | 80 +++++
> include/drm/drm_privacy_screen_machine.h | 41 +++
> 9 files changed, 604 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 389892f36185..5d8715d2f998 100644
> --- a/Documentation/gpu/drm-kms-helpers.rst
> +++ b/Documentation/gpu/drm-kms-helpers.rst
> @@ -423,3 +423,18 @@ Legacy CRTC/Modeset Helper Functions Reference
>
> .. kernel-doc:: drivers/gpu/drm/drm_crtc_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 ede4a37a53b3..a272ca600f98 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -6376,6 +6376,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 b17e231ca6f7..7249b010ab90 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -481,3 +481,7 @@ config DRM_PANEL_ORIENTATION_QUIRKS
> config DRM_LIB_RANDOM
> bool
> default n
> +
> +config DRM_PRIVACY_SCREEN
> + bool
> + default n
This is probably worth documenting for folks configuring their kernels to
explain what this actually does (something simple like "Controls programmable
privacy screens found on some devices, if unsure select Y" would probably be
fine)
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index 0dff40bb863c..788fc37096f6 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -32,6 +32,7 @@ drm-$(CONFIG_OF) += drm_of.o
> drm-$(CONFIG_PCI) += drm_pci.o
> drm-$(CONFIG_DEBUG_FS) += drm_debugfs.o drm_debugfs_crc.o
> drm-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
> +drm-$(CONFIG_DRM_PRIVACY_SCREEN) += drm_privacy_screen.o
>
> obj-$(CONFIG_DRM_DP_AUX_BUS) += drm_dp_aux_bus.o
>
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 7a5097467ba5..dc293b771c3f 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -43,6 +43,7 @@
> #include <drm/drm_managed.h>
> #include <drm/drm_mode_object.h>
> #include <drm/drm_print.h>
> +#include <drm/drm_privacy_screen_machine.h>
>
> #include "drm_crtc_internal.h"
> #include "drm_internal.h"
> @@ -1029,6 +1030,7 @@ static const struct file_operations drm_stub_fops = {
>
> static void drm_core_exit(void)
> {
> + drm_privacy_screen_lookup_exit();
> unregister_chrdev(DRM_MAJOR, "drm");
> debugfs_remove(drm_debugfs_root);
> drm_sysfs_destroy();
> @@ -1056,6 +1058,8 @@ static int __init drm_core_init(void)
> if (ret < 0)
> goto error;
>
> + drm_privacy_screen_lookup_init();
> +
> drm_core_init_complete = true;
>
> DRM_DEBUG("Initialized\n");
> diff --git a/drivers/gpu/drm/drm_privacy_screen.c
> b/drivers/gpu/drm/drm_privacy_screen.c
> new file mode 100644
> index 000000000000..294a09194bfb
> --- /dev/null
> +++ b/drivers/gpu/drm/drm_privacy_screen.c
> @@ -0,0 +1,401 @@
> +// SPDX-License-Identifier: MIT
> +/*
> + * Copyright (C) 2020 - 2021 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>
> +#include "drm_internal.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 device_type drm_privacy_screen_type = {
> + .name = "privacy_screen",
> + .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_class;
> + priv->dev.type = &drm_privacy_screen_type;
> + priv->dev.parent = parent;
> + priv->dev.release = drm_privacy_screen_device_release;
> + dev_set_name(&priv->dev, "privacy_screen-%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);
> diff --git a/include/drm/drm_privacy_screen_consumer.h
> b/include/drm/drm_privacy_screen_consumer.h
> new file mode 100644
> index 000000000000..0cbd23b0453d
> --- /dev/null
> +++ b/include/drm/drm_privacy_screen_consumer.h
> @@ -0,0 +1,50 @@
> +/* 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;
> +
> +#if IS_ENABLED(CONFIG_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);
> +#else
> +static inline struct drm_privacy_screen *drm_privacy_screen_get(struct
> device *dev,
> + const char
> *con_id)
> +{
> + return ERR_PTR(-ENODEV);
> +}
> +static inline void drm_privacy_screen_put(struct drm_privacy_screen *priv)
> +{
> +}
> +static inline int drm_privacy_screen_set_sw_state(struct drm_privacy_screen
> *priv,
> + enum
> drm_privacy_screen_status sw_state)
> +{
> + return -ENODEV;
> +}
> +static inline 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)
> +{
> + *sw_state_ret = PRIVACY_SCREEN_DISABLED;
> + *hw_state_ret = PRIVACY_SCREEN_DISABLED;
> +}
> +#endif
> +
> +#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..aaa0d38cce92
> --- /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. */
I think this patch mostly looks good, the one part that I'm a little confused
on here is the con_id. Perhaps I missed this when looking over this patch, but
what "connector name" are we referring to here - the DRM connector name (e.g.
eDP-1), or something else? The reason I ask is because I wonder if connector
names are really the way that we want to be looking DRM connectors up, since I
believe it's possible for two different GPUs to have DRM connectors with the
same name.
> + 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_lookup_init(void)
> +{
> +}
> +static inline void drm_privacy_screen_lookup_exit(void)
> +{
> +}
> +
> +#endif
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [PATCH 2/9] drm: Add privacy-screen class (v3)
@ 2021-09-15 20:01 ` Lyude Paul
0 siblings, 0 replies; 84+ messages in thread
From: Lyude Paul @ 2021-09-15 20:01 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
On Mon, 2021-09-06 at 09:35 +0200, Hans de Goede wrote:
> 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.
>
> Changes in v2:
> - Make CONFIG_DRM_PRIVACY_SCREEN a bool which controls if the drm_privacy
> code gets built as part of the main drm module rather then making it
> a tristate which builds its own module.
> - Add a #if IS_ENABLED(CONFIG_DRM_PRIVACY_SCREEN) check to
> drm_privacy_screen_consumer.h and define stubs when the check fails.
> Together these 2 changes fix several dependency issues.
> - Remove module related code now that this is part of the main drm.ko
> - Use drm_class as class for the privacy-screen devices instead of
> adding a separate class for this
>
> Changes in v3:
> - Make the static inline drm_privacy_screen_get_state() stub set sw_state
> and hw_state to PRIVACY_SCREEN_DISABLED to squelch an uninitialized
> variable warning when CONFIG_DRM_PRIVICAY_SCREEN is not set
>
> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> ---
> Documentation/gpu/drm-kms-helpers.rst | 15 +
> MAINTAINERS | 8 +
> drivers/gpu/drm/Kconfig | 4 +
> drivers/gpu/drm/Makefile | 1 +
> drivers/gpu/drm/drm_drv.c | 4 +
> drivers/gpu/drm/drm_privacy_screen.c | 401 ++++++++++++++++++++++
> include/drm/drm_privacy_screen_consumer.h | 50 +++
> include/drm/drm_privacy_screen_driver.h | 80 +++++
> include/drm/drm_privacy_screen_machine.h | 41 +++
> 9 files changed, 604 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 389892f36185..5d8715d2f998 100644
> --- a/Documentation/gpu/drm-kms-helpers.rst
> +++ b/Documentation/gpu/drm-kms-helpers.rst
> @@ -423,3 +423,18 @@ Legacy CRTC/Modeset Helper Functions Reference
>
> .. kernel-doc:: drivers/gpu/drm/drm_crtc_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 ede4a37a53b3..a272ca600f98 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -6376,6 +6376,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 b17e231ca6f7..7249b010ab90 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -481,3 +481,7 @@ config DRM_PANEL_ORIENTATION_QUIRKS
> config DRM_LIB_RANDOM
> bool
> default n
> +
> +config DRM_PRIVACY_SCREEN
> + bool
> + default n
This is probably worth documenting for folks configuring their kernels to
explain what this actually does (something simple like "Controls programmable
privacy screens found on some devices, if unsure select Y" would probably be
fine)
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index 0dff40bb863c..788fc37096f6 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -32,6 +32,7 @@ drm-$(CONFIG_OF) += drm_of.o
> drm-$(CONFIG_PCI) += drm_pci.o
> drm-$(CONFIG_DEBUG_FS) += drm_debugfs.o drm_debugfs_crc.o
> drm-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
> +drm-$(CONFIG_DRM_PRIVACY_SCREEN) += drm_privacy_screen.o
>
> obj-$(CONFIG_DRM_DP_AUX_BUS) += drm_dp_aux_bus.o
>
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 7a5097467ba5..dc293b771c3f 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -43,6 +43,7 @@
> #include <drm/drm_managed.h>
> #include <drm/drm_mode_object.h>
> #include <drm/drm_print.h>
> +#include <drm/drm_privacy_screen_machine.h>
>
> #include "drm_crtc_internal.h"
> #include "drm_internal.h"
> @@ -1029,6 +1030,7 @@ static const struct file_operations drm_stub_fops = {
>
> static void drm_core_exit(void)
> {
> + drm_privacy_screen_lookup_exit();
> unregister_chrdev(DRM_MAJOR, "drm");
> debugfs_remove(drm_debugfs_root);
> drm_sysfs_destroy();
> @@ -1056,6 +1058,8 @@ static int __init drm_core_init(void)
> if (ret < 0)
> goto error;
>
> + drm_privacy_screen_lookup_init();
> +
> drm_core_init_complete = true;
>
> DRM_DEBUG("Initialized\n");
> diff --git a/drivers/gpu/drm/drm_privacy_screen.c
> b/drivers/gpu/drm/drm_privacy_screen.c
> new file mode 100644
> index 000000000000..294a09194bfb
> --- /dev/null
> +++ b/drivers/gpu/drm/drm_privacy_screen.c
> @@ -0,0 +1,401 @@
> +// SPDX-License-Identifier: MIT
> +/*
> + * Copyright (C) 2020 - 2021 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>
> +#include "drm_internal.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 device_type drm_privacy_screen_type = {
> + .name = "privacy_screen",
> + .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_class;
> + priv->dev.type = &drm_privacy_screen_type;
> + priv->dev.parent = parent;
> + priv->dev.release = drm_privacy_screen_device_release;
> + dev_set_name(&priv->dev, "privacy_screen-%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);
> diff --git a/include/drm/drm_privacy_screen_consumer.h
> b/include/drm/drm_privacy_screen_consumer.h
> new file mode 100644
> index 000000000000..0cbd23b0453d
> --- /dev/null
> +++ b/include/drm/drm_privacy_screen_consumer.h
> @@ -0,0 +1,50 @@
> +/* 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;
> +
> +#if IS_ENABLED(CONFIG_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);
> +#else
> +static inline struct drm_privacy_screen *drm_privacy_screen_get(struct
> device *dev,
> + const char
> *con_id)
> +{
> + return ERR_PTR(-ENODEV);
> +}
> +static inline void drm_privacy_screen_put(struct drm_privacy_screen *priv)
> +{
> +}
> +static inline int drm_privacy_screen_set_sw_state(struct drm_privacy_screen
> *priv,
> + enum
> drm_privacy_screen_status sw_state)
> +{
> + return -ENODEV;
> +}
> +static inline 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)
> +{
> + *sw_state_ret = PRIVACY_SCREEN_DISABLED;
> + *hw_state_ret = PRIVACY_SCREEN_DISABLED;
> +}
> +#endif
> +
> +#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..aaa0d38cce92
> --- /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. */
I think this patch mostly looks good, the one part that I'm a little confused
on here is the con_id. Perhaps I missed this when looking over this patch, but
what "connector name" are we referring to here - the DRM connector name (e.g.
eDP-1), or something else? The reason I ask is because I wonder if connector
names are really the way that we want to be looking DRM connectors up, since I
believe it's possible for two different GPUs to have DRM connectors with the
same name.
> + 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_lookup_init(void)
> +{
> +}
> +static inline void drm_privacy_screen_lookup_exit(void)
> +{
> +}
> +
> +#endif
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [Intel-gfx] [PATCH 2/9] drm: Add privacy-screen class (v3)
@ 2021-09-15 20:01 ` Lyude Paul
0 siblings, 0 replies; 84+ messages in thread
From: Lyude Paul @ 2021-09-15 20:01 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
On Mon, 2021-09-06 at 09:35 +0200, Hans de Goede wrote:
> 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.
>
> Changes in v2:
> - Make CONFIG_DRM_PRIVACY_SCREEN a bool which controls if the drm_privacy
> code gets built as part of the main drm module rather then making it
> a tristate which builds its own module.
> - Add a #if IS_ENABLED(CONFIG_DRM_PRIVACY_SCREEN) check to
> drm_privacy_screen_consumer.h and define stubs when the check fails.
> Together these 2 changes fix several dependency issues.
> - Remove module related code now that this is part of the main drm.ko
> - Use drm_class as class for the privacy-screen devices instead of
> adding a separate class for this
>
> Changes in v3:
> - Make the static inline drm_privacy_screen_get_state() stub set sw_state
> and hw_state to PRIVACY_SCREEN_DISABLED to squelch an uninitialized
> variable warning when CONFIG_DRM_PRIVICAY_SCREEN is not set
>
> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> ---
> Documentation/gpu/drm-kms-helpers.rst | 15 +
> MAINTAINERS | 8 +
> drivers/gpu/drm/Kconfig | 4 +
> drivers/gpu/drm/Makefile | 1 +
> drivers/gpu/drm/drm_drv.c | 4 +
> drivers/gpu/drm/drm_privacy_screen.c | 401 ++++++++++++++++++++++
> include/drm/drm_privacy_screen_consumer.h | 50 +++
> include/drm/drm_privacy_screen_driver.h | 80 +++++
> include/drm/drm_privacy_screen_machine.h | 41 +++
> 9 files changed, 604 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 389892f36185..5d8715d2f998 100644
> --- a/Documentation/gpu/drm-kms-helpers.rst
> +++ b/Documentation/gpu/drm-kms-helpers.rst
> @@ -423,3 +423,18 @@ Legacy CRTC/Modeset Helper Functions Reference
>
> .. kernel-doc:: drivers/gpu/drm/drm_crtc_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 ede4a37a53b3..a272ca600f98 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -6376,6 +6376,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 b17e231ca6f7..7249b010ab90 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -481,3 +481,7 @@ config DRM_PANEL_ORIENTATION_QUIRKS
> config DRM_LIB_RANDOM
> bool
> default n
> +
> +config DRM_PRIVACY_SCREEN
> + bool
> + default n
This is probably worth documenting for folks configuring their kernels to
explain what this actually does (something simple like "Controls programmable
privacy screens found on some devices, if unsure select Y" would probably be
fine)
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index 0dff40bb863c..788fc37096f6 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -32,6 +32,7 @@ drm-$(CONFIG_OF) += drm_of.o
> drm-$(CONFIG_PCI) += drm_pci.o
> drm-$(CONFIG_DEBUG_FS) += drm_debugfs.o drm_debugfs_crc.o
> drm-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
> +drm-$(CONFIG_DRM_PRIVACY_SCREEN) += drm_privacy_screen.o
>
> obj-$(CONFIG_DRM_DP_AUX_BUS) += drm_dp_aux_bus.o
>
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 7a5097467ba5..dc293b771c3f 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -43,6 +43,7 @@
> #include <drm/drm_managed.h>
> #include <drm/drm_mode_object.h>
> #include <drm/drm_print.h>
> +#include <drm/drm_privacy_screen_machine.h>
>
> #include "drm_crtc_internal.h"
> #include "drm_internal.h"
> @@ -1029,6 +1030,7 @@ static const struct file_operations drm_stub_fops = {
>
> static void drm_core_exit(void)
> {
> + drm_privacy_screen_lookup_exit();
> unregister_chrdev(DRM_MAJOR, "drm");
> debugfs_remove(drm_debugfs_root);
> drm_sysfs_destroy();
> @@ -1056,6 +1058,8 @@ static int __init drm_core_init(void)
> if (ret < 0)
> goto error;
>
> + drm_privacy_screen_lookup_init();
> +
> drm_core_init_complete = true;
>
> DRM_DEBUG("Initialized\n");
> diff --git a/drivers/gpu/drm/drm_privacy_screen.c
> b/drivers/gpu/drm/drm_privacy_screen.c
> new file mode 100644
> index 000000000000..294a09194bfb
> --- /dev/null
> +++ b/drivers/gpu/drm/drm_privacy_screen.c
> @@ -0,0 +1,401 @@
> +// SPDX-License-Identifier: MIT
> +/*
> + * Copyright (C) 2020 - 2021 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>
> +#include "drm_internal.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 device_type drm_privacy_screen_type = {
> + .name = "privacy_screen",
> + .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_class;
> + priv->dev.type = &drm_privacy_screen_type;
> + priv->dev.parent = parent;
> + priv->dev.release = drm_privacy_screen_device_release;
> + dev_set_name(&priv->dev, "privacy_screen-%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);
> diff --git a/include/drm/drm_privacy_screen_consumer.h
> b/include/drm/drm_privacy_screen_consumer.h
> new file mode 100644
> index 000000000000..0cbd23b0453d
> --- /dev/null
> +++ b/include/drm/drm_privacy_screen_consumer.h
> @@ -0,0 +1,50 @@
> +/* 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;
> +
> +#if IS_ENABLED(CONFIG_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);
> +#else
> +static inline struct drm_privacy_screen *drm_privacy_screen_get(struct
> device *dev,
> + const char
> *con_id)
> +{
> + return ERR_PTR(-ENODEV);
> +}
> +static inline void drm_privacy_screen_put(struct drm_privacy_screen *priv)
> +{
> +}
> +static inline int drm_privacy_screen_set_sw_state(struct drm_privacy_screen
> *priv,
> + enum
> drm_privacy_screen_status sw_state)
> +{
> + return -ENODEV;
> +}
> +static inline 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)
> +{
> + *sw_state_ret = PRIVACY_SCREEN_DISABLED;
> + *hw_state_ret = PRIVACY_SCREEN_DISABLED;
> +}
> +#endif
> +
> +#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..aaa0d38cce92
> --- /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. */
I think this patch mostly looks good, the one part that I'm a little confused
on here is the con_id. Perhaps I missed this when looking over this patch, but
what "connector name" are we referring to here - the DRM connector name (e.g.
eDP-1), or something else? The reason I ask is because I wonder if connector
names are really the way that we want to be looking DRM connectors up, since I
believe it's possible for two different GPUs to have DRM connectors with the
same name.
> + 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_lookup_init(void)
> +{
> +}
> +static inline void drm_privacy_screen_lookup_exit(void)
> +{
> +}
> +
> +#endif
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [PATCH 4/9] drm/privacy-screen: Add notifier support
2021-09-06 7:35 ` Hans de Goede
(?)
@ 2021-09-15 20:26 ` Lyude Paul
-1 siblings, 0 replies; 84+ messages in thread
From: Lyude Paul @ 2021-09-15 20:26 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
On Mon, 2021-09-06 at 09:35 +0200, Hans de Goede wrote:
> 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.
>
> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> ---
> drivers/gpu/drm/drm_privacy_screen.c | 67 +++++++++++++++++++++++
> include/drm/drm_privacy_screen_consumer.h | 15 +++++
> include/drm/drm_privacy_screen_driver.h | 4 ++
> 3 files changed, 86 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_privacy_screen.c
> b/drivers/gpu/drm/drm_privacy_screen.c
> index 294a09194bfb..7a5f878c3171 100644
> --- a/drivers/gpu/drm/drm_privacy_screen.c
> +++ b/drivers/gpu/drm/drm_privacy_screen.c
> @@ -255,6 +255,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_class;
> priv->dev.type = &drm_privacy_screen_type;
> @@ -399,3 +443,26 @@ void drm_privacy_screen_unregister(struct
> drm_privacy_screen *priv)
> device_unregister(&priv->dev);
> }
> 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;
Are we sure about this check? mutex_is_locked() checks whether a mutex is
locked by anyone, not just us. So this seems like it would cause us to
WARN_ON() and abort if anyone else (not just ourselves) is holding the lock to
read the privacy screen state.
> +
> + blocking_notifier_call_chain(&priv->notifier_head, 0, priv);
> +}
> +EXPORT_SYMBOL(drm_privacy_screen_call_notifier_chain);
> diff --git a/include/drm/drm_privacy_screen_consumer.h
> b/include/drm/drm_privacy_screen_consumer.h
> index 0cbd23b0453d..7f66a90d15b7 100644
> --- a/include/drm/drm_privacy_screen_consumer.h
> +++ b/include/drm/drm_privacy_screen_consumer.h
> @@ -24,6 +24,11 @@ int drm_privacy_screen_set_sw_state(struct
> drm_privacy_screen *priv,
> 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);
> #else
> static inline struct drm_privacy_screen *drm_privacy_screen_get(struct
> device *dev,
> const char
> *con_id)
> @@ -45,6 +50,16 @@ static inline void drm_privacy_screen_get_state(struct
> drm_privacy_screen *priv,
> *sw_state_ret = PRIVACY_SCREEN_DISABLED;
> *hw_state_ret = PRIVACY_SCREEN_DISABLED;
> }
> +static inline int drm_privacy_screen_register_notifier(struct
> drm_privacy_screen *priv,
> + struct notifier_block
> *nb)
> +{
> + return -ENODEV;
> +}
> +static inline int drm_privacy_screen_unregister_notifier(struct
> drm_privacy_screen *priv,
> + struct
> notifier_block *nb)
> +{
> + return -ENODEV;
> +}
> #endif
>
> #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
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [Intel-gfx] [PATCH 4/9] drm/privacy-screen: Add notifier support
@ 2021-09-15 20:26 ` Lyude Paul
0 siblings, 0 replies; 84+ messages in thread
From: Lyude Paul @ 2021-09-15 20:26 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
On Mon, 2021-09-06 at 09:35 +0200, Hans de Goede wrote:
> 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.
>
> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> ---
> drivers/gpu/drm/drm_privacy_screen.c | 67 +++++++++++++++++++++++
> include/drm/drm_privacy_screen_consumer.h | 15 +++++
> include/drm/drm_privacy_screen_driver.h | 4 ++
> 3 files changed, 86 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_privacy_screen.c
> b/drivers/gpu/drm/drm_privacy_screen.c
> index 294a09194bfb..7a5f878c3171 100644
> --- a/drivers/gpu/drm/drm_privacy_screen.c
> +++ b/drivers/gpu/drm/drm_privacy_screen.c
> @@ -255,6 +255,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_class;
> priv->dev.type = &drm_privacy_screen_type;
> @@ -399,3 +443,26 @@ void drm_privacy_screen_unregister(struct
> drm_privacy_screen *priv)
> device_unregister(&priv->dev);
> }
> 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;
Are we sure about this check? mutex_is_locked() checks whether a mutex is
locked by anyone, not just us. So this seems like it would cause us to
WARN_ON() and abort if anyone else (not just ourselves) is holding the lock to
read the privacy screen state.
> +
> + blocking_notifier_call_chain(&priv->notifier_head, 0, priv);
> +}
> +EXPORT_SYMBOL(drm_privacy_screen_call_notifier_chain);
> diff --git a/include/drm/drm_privacy_screen_consumer.h
> b/include/drm/drm_privacy_screen_consumer.h
> index 0cbd23b0453d..7f66a90d15b7 100644
> --- a/include/drm/drm_privacy_screen_consumer.h
> +++ b/include/drm/drm_privacy_screen_consumer.h
> @@ -24,6 +24,11 @@ int drm_privacy_screen_set_sw_state(struct
> drm_privacy_screen *priv,
> 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);
> #else
> static inline struct drm_privacy_screen *drm_privacy_screen_get(struct
> device *dev,
> const char
> *con_id)
> @@ -45,6 +50,16 @@ static inline void drm_privacy_screen_get_state(struct
> drm_privacy_screen *priv,
> *sw_state_ret = PRIVACY_SCREEN_DISABLED;
> *hw_state_ret = PRIVACY_SCREEN_DISABLED;
> }
> +static inline int drm_privacy_screen_register_notifier(struct
> drm_privacy_screen *priv,
> + struct notifier_block
> *nb)
> +{
> + return -ENODEV;
> +}
> +static inline int drm_privacy_screen_unregister_notifier(struct
> drm_privacy_screen *priv,
> + struct
> notifier_block *nb)
> +{
> + return -ENODEV;
> +}
> #endif
>
> #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
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [PATCH 4/9] drm/privacy-screen: Add notifier support
@ 2021-09-15 20:26 ` Lyude Paul
0 siblings, 0 replies; 84+ messages in thread
From: Lyude Paul @ 2021-09-15 20:26 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
On Mon, 2021-09-06 at 09:35 +0200, Hans de Goede wrote:
> 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.
>
> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> ---
> drivers/gpu/drm/drm_privacy_screen.c | 67 +++++++++++++++++++++++
> include/drm/drm_privacy_screen_consumer.h | 15 +++++
> include/drm/drm_privacy_screen_driver.h | 4 ++
> 3 files changed, 86 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_privacy_screen.c
> b/drivers/gpu/drm/drm_privacy_screen.c
> index 294a09194bfb..7a5f878c3171 100644
> --- a/drivers/gpu/drm/drm_privacy_screen.c
> +++ b/drivers/gpu/drm/drm_privacy_screen.c
> @@ -255,6 +255,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_class;
> priv->dev.type = &drm_privacy_screen_type;
> @@ -399,3 +443,26 @@ void drm_privacy_screen_unregister(struct
> drm_privacy_screen *priv)
> device_unregister(&priv->dev);
> }
> 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;
Are we sure about this check? mutex_is_locked() checks whether a mutex is
locked by anyone, not just us. So this seems like it would cause us to
WARN_ON() and abort if anyone else (not just ourselves) is holding the lock to
read the privacy screen state.
> +
> + blocking_notifier_call_chain(&priv->notifier_head, 0, priv);
> +}
> +EXPORT_SYMBOL(drm_privacy_screen_call_notifier_chain);
> diff --git a/include/drm/drm_privacy_screen_consumer.h
> b/include/drm/drm_privacy_screen_consumer.h
> index 0cbd23b0453d..7f66a90d15b7 100644
> --- a/include/drm/drm_privacy_screen_consumer.h
> +++ b/include/drm/drm_privacy_screen_consumer.h
> @@ -24,6 +24,11 @@ int drm_privacy_screen_set_sw_state(struct
> drm_privacy_screen *priv,
> 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);
> #else
> static inline struct drm_privacy_screen *drm_privacy_screen_get(struct
> device *dev,
> const char
> *con_id)
> @@ -45,6 +50,16 @@ static inline void drm_privacy_screen_get_state(struct
> drm_privacy_screen *priv,
> *sw_state_ret = PRIVACY_SCREEN_DISABLED;
> *hw_state_ret = PRIVACY_SCREEN_DISABLED;
> }
> +static inline int drm_privacy_screen_register_notifier(struct
> drm_privacy_screen *priv,
> + struct notifier_block
> *nb)
> +{
> + return -ENODEV;
> +}
> +static inline int drm_privacy_screen_unregister_notifier(struct
> drm_privacy_screen *priv,
> + struct
> notifier_block *nb)
> +{
> + return -ENODEV;
> +}
> #endif
>
> #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
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [PATCH 8/9] platform/x86: thinkpad_acpi: Register a privacy-screen device
2021-09-06 7:35 ` [Intel-gfx] " Hans de Goede
(?)
@ 2021-09-15 20:55 ` Lyude Paul
-1 siblings, 0 replies; 84+ messages in thread
From: Lyude Paul @ 2021-09-15 20:55 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
On Mon, 2021-09-06 at 09:35 +0200, Hans de Goede wrote:
> 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
Looks like a typo here ------------------------------^
> interface which all user-space code should use to query and control
> the privacy-screen.
>
> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> ---
> Changes in v2:
> - Make the new lcdshadow_set_sw_state, lcdshadow_get_hw_state and
> lcdshadow_ops symbols static
> - Update state and call drm_privacy_screen_call_notifier_chain()
> when the state is changed by pressing the Fn + D hotkey combo
> ---
> drivers/platform/x86/Kconfig | 2 +
> drivers/platform/x86/thinkpad_acpi.c | 91 ++++++++++++++++++++--------
> 2 files changed, 68 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
> index d12db6c316ea..ae00a27f9f95 100644
> --- a/drivers/platform/x86/Kconfig
> +++ b/drivers/platform/x86/Kconfig
> @@ -509,7 +509,9 @@ config THINKPAD_ACPI
> depends on ACPI_VIDEO || ACPI_VIDEO = n
> depends on BACKLIGHT_CLASS_DEVICE
> depends on I2C
> + depends on DRM
> select ACPI_PLATFORM_PROFILE
> + 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 b8f2556c4797..044b238730ba 100644
> --- a/drivers/platform/x86/thinkpad_acpi.c
> +++ b/drivers/platform/x86/thinkpad_acpi.c
> @@ -73,6 +73,7 @@
> #include <linux/uaccess.h>
> #include <acpi/battery.h>
> #include <acpi/video.h>
> +#include <drm/drm_privacy_screen_driver.h>
> #include "dual_accel_detect.h"
>
> /* ThinkPad CMOS commands */
> @@ -157,6 +158,7 @@ enum tpacpi_hkey_event_t {
> TP_HKEY_EV_VOL_UP = 0x1015, /* Volume up or unmute */
> TP_HKEY_EV_VOL_DOWN = 0x1016, /* Volume down or unmute
> */
> TP_HKEY_EV_VOL_MUTE = 0x1017, /* Mixer output mute */
> + TP_HKEY_EV_PRIVACYGUARD_TOGGLE = 0x130f, /* Toggle priv.guard
> on/off */
>
> /* Reasons for waking up from S3/S4 */
> TP_HKEY_EV_WKUP_S3_UNDOCK = 0x2304, /* undock requested, S3 */
> @@ -3889,6 +3891,12 @@ static bool hotkey_notify_extended_hotkey(const u32
> hkey)
> {
> unsigned int scancode;
>
> + switch (hkey) {
> + case TP_HKEY_EV_PRIVACYGUARD_TOGGLE:
> + tpacpi_driver_event(hkey);
> + return true;
> + }
> +
> /* Extended keycodes start at 0x300 and our offset into the map
> * TP_ACPI_HOTKEYSCAN_EXTENDED_START. The calculated scancode
> * will be positive, but might not be in the correct range.
> @@ -9819,30 +9827,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)
> +static 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)
> +static 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;
> }
>
> +static 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;
> @@ -9850,36 +9868,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);
> }
>
For privacy screens provided by x86 platform drivers this is -probably-
correct, but only so long as we're confident that the privacy screen is always
going to be controllable regardless of the power state of the actual LCD
panel.
I'd think we would need to handle suspend/resume in the atomic commit though
if we ever have to support systems where the two are dependent on one another,
but, that's a simple enough change to do later if it arises that I think we
can ignore it for now.
> 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");
> }
>
> @@ -9891,7 +9917,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, ","))) {
> @@ -9903,11 +9929,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,
> @@ -10717,6 +10750,14 @@ static void tpacpi_driver_event(const unsigned int
> hkey_event)
> if (!atomic_add_unless(&dytc_ignore_event, -1, 0))
> dytc_profile_refresh();
> }
> +
> + if (lcdshadow_dev && hkey_event == TP_HKEY_EV_PRIVACYGUARD_TOGGLE) {
> + mutex_lock(&lcdshadow_dev->lock);
> + lcdshadow_get_hw_state(lcdshadow_dev);
> + mutex_unlock(&lcdshadow_dev->lock);
> +
> + drm_privacy_screen_call_notifier_chain(lcdshadow_dev);
> + }
> }
>
> static void hotkey_driver_event(const unsigned int scancode)
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [PATCH 8/9] platform/x86: thinkpad_acpi: Register a privacy-screen device
@ 2021-09-15 20:55 ` Lyude Paul
0 siblings, 0 replies; 84+ messages in thread
From: Lyude Paul @ 2021-09-15 20:55 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
On Mon, 2021-09-06 at 09:35 +0200, Hans de Goede wrote:
> 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
Looks like a typo here ------------------------------^
> interface which all user-space code should use to query and control
> the privacy-screen.
>
> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> ---
> Changes in v2:
> - Make the new lcdshadow_set_sw_state, lcdshadow_get_hw_state and
> lcdshadow_ops symbols static
> - Update state and call drm_privacy_screen_call_notifier_chain()
> when the state is changed by pressing the Fn + D hotkey combo
> ---
> drivers/platform/x86/Kconfig | 2 +
> drivers/platform/x86/thinkpad_acpi.c | 91 ++++++++++++++++++++--------
> 2 files changed, 68 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
> index d12db6c316ea..ae00a27f9f95 100644
> --- a/drivers/platform/x86/Kconfig
> +++ b/drivers/platform/x86/Kconfig
> @@ -509,7 +509,9 @@ config THINKPAD_ACPI
> depends on ACPI_VIDEO || ACPI_VIDEO = n
> depends on BACKLIGHT_CLASS_DEVICE
> depends on I2C
> + depends on DRM
> select ACPI_PLATFORM_PROFILE
> + 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 b8f2556c4797..044b238730ba 100644
> --- a/drivers/platform/x86/thinkpad_acpi.c
> +++ b/drivers/platform/x86/thinkpad_acpi.c
> @@ -73,6 +73,7 @@
> #include <linux/uaccess.h>
> #include <acpi/battery.h>
> #include <acpi/video.h>
> +#include <drm/drm_privacy_screen_driver.h>
> #include "dual_accel_detect.h"
>
> /* ThinkPad CMOS commands */
> @@ -157,6 +158,7 @@ enum tpacpi_hkey_event_t {
> TP_HKEY_EV_VOL_UP = 0x1015, /* Volume up or unmute */
> TP_HKEY_EV_VOL_DOWN = 0x1016, /* Volume down or unmute
> */
> TP_HKEY_EV_VOL_MUTE = 0x1017, /* Mixer output mute */
> + TP_HKEY_EV_PRIVACYGUARD_TOGGLE = 0x130f, /* Toggle priv.guard
> on/off */
>
> /* Reasons for waking up from S3/S4 */
> TP_HKEY_EV_WKUP_S3_UNDOCK = 0x2304, /* undock requested, S3 */
> @@ -3889,6 +3891,12 @@ static bool hotkey_notify_extended_hotkey(const u32
> hkey)
> {
> unsigned int scancode;
>
> + switch (hkey) {
> + case TP_HKEY_EV_PRIVACYGUARD_TOGGLE:
> + tpacpi_driver_event(hkey);
> + return true;
> + }
> +
> /* Extended keycodes start at 0x300 and our offset into the map
> * TP_ACPI_HOTKEYSCAN_EXTENDED_START. The calculated scancode
> * will be positive, but might not be in the correct range.
> @@ -9819,30 +9827,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)
> +static 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)
> +static 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;
> }
>
> +static 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;
> @@ -9850,36 +9868,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);
> }
>
For privacy screens provided by x86 platform drivers this is -probably-
correct, but only so long as we're confident that the privacy screen is always
going to be controllable regardless of the power state of the actual LCD
panel.
I'd think we would need to handle suspend/resume in the atomic commit though
if we ever have to support systems where the two are dependent on one another,
but, that's a simple enough change to do later if it arises that I think we
can ignore it for now.
> 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");
> }
>
> @@ -9891,7 +9917,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, ","))) {
> @@ -9903,11 +9929,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,
> @@ -10717,6 +10750,14 @@ static void tpacpi_driver_event(const unsigned int
> hkey_event)
> if (!atomic_add_unless(&dytc_ignore_event, -1, 0))
> dytc_profile_refresh();
> }
> +
> + if (lcdshadow_dev && hkey_event == TP_HKEY_EV_PRIVACYGUARD_TOGGLE) {
> + mutex_lock(&lcdshadow_dev->lock);
> + lcdshadow_get_hw_state(lcdshadow_dev);
> + mutex_unlock(&lcdshadow_dev->lock);
> +
> + drm_privacy_screen_call_notifier_chain(lcdshadow_dev);
> + }
> }
>
> static void hotkey_driver_event(const unsigned int scancode)
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [Intel-gfx] [PATCH 8/9] platform/x86: thinkpad_acpi: Register a privacy-screen device
@ 2021-09-15 20:55 ` Lyude Paul
0 siblings, 0 replies; 84+ messages in thread
From: Lyude Paul @ 2021-09-15 20:55 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
On Mon, 2021-09-06 at 09:35 +0200, Hans de Goede wrote:
> 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
Looks like a typo here ------------------------------^
> interface which all user-space code should use to query and control
> the privacy-screen.
>
> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> ---
> Changes in v2:
> - Make the new lcdshadow_set_sw_state, lcdshadow_get_hw_state and
> lcdshadow_ops symbols static
> - Update state and call drm_privacy_screen_call_notifier_chain()
> when the state is changed by pressing the Fn + D hotkey combo
> ---
> drivers/platform/x86/Kconfig | 2 +
> drivers/platform/x86/thinkpad_acpi.c | 91 ++++++++++++++++++++--------
> 2 files changed, 68 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
> index d12db6c316ea..ae00a27f9f95 100644
> --- a/drivers/platform/x86/Kconfig
> +++ b/drivers/platform/x86/Kconfig
> @@ -509,7 +509,9 @@ config THINKPAD_ACPI
> depends on ACPI_VIDEO || ACPI_VIDEO = n
> depends on BACKLIGHT_CLASS_DEVICE
> depends on I2C
> + depends on DRM
> select ACPI_PLATFORM_PROFILE
> + 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 b8f2556c4797..044b238730ba 100644
> --- a/drivers/platform/x86/thinkpad_acpi.c
> +++ b/drivers/platform/x86/thinkpad_acpi.c
> @@ -73,6 +73,7 @@
> #include <linux/uaccess.h>
> #include <acpi/battery.h>
> #include <acpi/video.h>
> +#include <drm/drm_privacy_screen_driver.h>
> #include "dual_accel_detect.h"
>
> /* ThinkPad CMOS commands */
> @@ -157,6 +158,7 @@ enum tpacpi_hkey_event_t {
> TP_HKEY_EV_VOL_UP = 0x1015, /* Volume up or unmute */
> TP_HKEY_EV_VOL_DOWN = 0x1016, /* Volume down or unmute
> */
> TP_HKEY_EV_VOL_MUTE = 0x1017, /* Mixer output mute */
> + TP_HKEY_EV_PRIVACYGUARD_TOGGLE = 0x130f, /* Toggle priv.guard
> on/off */
>
> /* Reasons for waking up from S3/S4 */
> TP_HKEY_EV_WKUP_S3_UNDOCK = 0x2304, /* undock requested, S3 */
> @@ -3889,6 +3891,12 @@ static bool hotkey_notify_extended_hotkey(const u32
> hkey)
> {
> unsigned int scancode;
>
> + switch (hkey) {
> + case TP_HKEY_EV_PRIVACYGUARD_TOGGLE:
> + tpacpi_driver_event(hkey);
> + return true;
> + }
> +
> /* Extended keycodes start at 0x300 and our offset into the map
> * TP_ACPI_HOTKEYSCAN_EXTENDED_START. The calculated scancode
> * will be positive, but might not be in the correct range.
> @@ -9819,30 +9827,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)
> +static 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)
> +static 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;
> }
>
> +static 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;
> @@ -9850,36 +9868,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);
> }
>
For privacy screens provided by x86 platform drivers this is -probably-
correct, but only so long as we're confident that the privacy screen is always
going to be controllable regardless of the power state of the actual LCD
panel.
I'd think we would need to handle suspend/resume in the atomic commit though
if we ever have to support systems where the two are dependent on one another,
but, that's a simple enough change to do later if it arises that I think we
can ignore it for now.
> 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");
> }
>
> @@ -9891,7 +9917,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, ","))) {
> @@ -9903,11 +9929,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,
> @@ -10717,6 +10750,14 @@ static void tpacpi_driver_event(const unsigned int
> hkey_event)
> if (!atomic_add_unless(&dytc_ignore_event, -1, 0))
> dytc_profile_refresh();
> }
> +
> + if (lcdshadow_dev && hkey_event == TP_HKEY_EV_PRIVACYGUARD_TOGGLE) {
> + mutex_lock(&lcdshadow_dev->lock);
> + lcdshadow_get_hw_state(lcdshadow_dev);
> + mutex_unlock(&lcdshadow_dev->lock);
> +
> + drm_privacy_screen_call_notifier_chain(lcdshadow_dev);
> + }
> }
>
> static void hotkey_driver_event(const unsigned int scancode)
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [PATCH 9/9] drm/i915: Add privacy-screen support
2021-09-06 7:35 ` [Intel-gfx] " Hans de Goede
(?)
@ 2021-09-15 21:11 ` Lyude Paul
-1 siblings, 0 replies; 84+ messages in thread
From: Lyude Paul @ 2021-09-15 21:11 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
On Mon, 2021-09-06 at 09:35 +0200, Hans de Goede wrote:
> 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.
I was going to suggest that you workaround this simply by adding a variable
that corresponds to the most recently committed privacy screen state somewhere
in a driver private structure. But, then I realized that's basically the same
as what you're doing now except that your current solution stores said state
in a shared struct. So, I think you probably do have the right idea here as
long as we don't get any non-ACPI providers in the future. This also seems
like something that wouldn't be difficult to fixup down the line if that ends
up changing.
>
> 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.
>
> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
> 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 5560d2f4c352..7285873d329a 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -10140,6 +10140,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;
> @@ -10237,6 +10239,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 7f8e8865048f..3aa2072cccf6 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -37,6 +37,7 @@
> #include <drm/drm_crtc.h>
> #include <drm/drm_dp_helper.h>
> #include <drm/drm_edid.h>
> +#include <drm/drm_privacy_screen_consumer.h>
> #include <drm/drm_probe_helper.h>
>
> #include "g4x_dp.h"
> @@ -5217,6 +5218,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;
> struct edid *edid;
> @@ -5308,6 +5310,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->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 146f7e39182a..d6913f567a1c 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -25,6 +25,7 @@
> #include <linux/vga_switcheroo.h>
>
> #include <drm/drm_drv.h>
> +#include <drm/drm_privacy_screen_consumer.h>
> #include <drm/i915_pciids.h>
>
> #include "i915_drv.h"
> @@ -1167,6 +1168,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 &&
> @@ -1195,7 +1197,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;
>
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [PATCH 9/9] drm/i915: Add privacy-screen support
@ 2021-09-15 21:11 ` Lyude Paul
0 siblings, 0 replies; 84+ messages in thread
From: Lyude Paul @ 2021-09-15 21:11 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
On Mon, 2021-09-06 at 09:35 +0200, Hans de Goede wrote:
> 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.
I was going to suggest that you workaround this simply by adding a variable
that corresponds to the most recently committed privacy screen state somewhere
in a driver private structure. But, then I realized that's basically the same
as what you're doing now except that your current solution stores said state
in a shared struct. So, I think you probably do have the right idea here as
long as we don't get any non-ACPI providers in the future. This also seems
like something that wouldn't be difficult to fixup down the line if that ends
up changing.
>
> 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.
>
> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
> 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 5560d2f4c352..7285873d329a 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -10140,6 +10140,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;
> @@ -10237,6 +10239,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 7f8e8865048f..3aa2072cccf6 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -37,6 +37,7 @@
> #include <drm/drm_crtc.h>
> #include <drm/drm_dp_helper.h>
> #include <drm/drm_edid.h>
> +#include <drm/drm_privacy_screen_consumer.h>
> #include <drm/drm_probe_helper.h>
>
> #include "g4x_dp.h"
> @@ -5217,6 +5218,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;
> struct edid *edid;
> @@ -5308,6 +5310,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->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 146f7e39182a..d6913f567a1c 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -25,6 +25,7 @@
> #include <linux/vga_switcheroo.h>
>
> #include <drm/drm_drv.h>
> +#include <drm/drm_privacy_screen_consumer.h>
> #include <drm/i915_pciids.h>
>
> #include "i915_drv.h"
> @@ -1167,6 +1168,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 &&
> @@ -1195,7 +1197,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;
>
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [Intel-gfx] [PATCH 9/9] drm/i915: Add privacy-screen support
@ 2021-09-15 21:11 ` Lyude Paul
0 siblings, 0 replies; 84+ messages in thread
From: Lyude Paul @ 2021-09-15 21:11 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
On Mon, 2021-09-06 at 09:35 +0200, Hans de Goede wrote:
> 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.
I was going to suggest that you workaround this simply by adding a variable
that corresponds to the most recently committed privacy screen state somewhere
in a driver private structure. But, then I realized that's basically the same
as what you're doing now except that your current solution stores said state
in a shared struct. So, I think you probably do have the right idea here as
long as we don't get any non-ACPI providers in the future. This also seems
like something that wouldn't be difficult to fixup down the line if that ends
up changing.
>
> 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.
>
> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
> 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 5560d2f4c352..7285873d329a 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -10140,6 +10140,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;
> @@ -10237,6 +10239,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 7f8e8865048f..3aa2072cccf6 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -37,6 +37,7 @@
> #include <drm/drm_crtc.h>
> #include <drm/drm_dp_helper.h>
> #include <drm/drm_edid.h>
> +#include <drm/drm_privacy_screen_consumer.h>
> #include <drm/drm_probe_helper.h>
>
> #include "g4x_dp.h"
> @@ -5217,6 +5218,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;
> struct edid *edid;
> @@ -5308,6 +5310,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->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 146f7e39182a..d6913f567a1c 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -25,6 +25,7 @@
> #include <linux/vga_switcheroo.h>
>
> #include <drm/drm_drv.h>
> +#include <drm/drm_privacy_screen_consumer.h>
> #include <drm/i915_pciids.h>
>
> #include "i915_drv.h"
> @@ -1167,6 +1168,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 &&
> @@ -1195,7 +1197,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;
>
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [PATCH 0/9] drm: Add privacy-screen class and connector properties
2021-09-06 7:35 ` [Intel-gfx] " Hans de Goede
(?)
@ 2021-09-15 21:12 ` Lyude Paul
-1 siblings, 0 replies; 84+ 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] 84+ 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; 84+ 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] 84+ messages in thread
* Re: [Intel-gfx] [PATCH 0/9] drm: Add privacy-screen class and connector properties
@ 2021-09-15 21:12 ` Lyude Paul
0 siblings, 0 replies; 84+ 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] 84+ messages in thread
* Re: [PATCH 1/9] drm/connector: Add support for privacy-screen properties (v4)
2021-09-15 19:48 ` Lyude Paul
@ 2021-09-16 8:26 ` Jani Nikula
-1 siblings, 0 replies; 84+ messages in thread
From: Jani Nikula @ 2021-09-16 8:26 UTC (permalink / raw)
To: Lyude Paul, Hans de Goede, 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, Mario Limonciello
On Wed, 15 Sep 2021, Lyude Paul <lyude@redhat.com> wrote:
> On Mon, 2021-09-06 at 09:35 +0200, Hans de Goede wrote:
>>
>> + /**
>> + * @privacy_screen_sw_state: See :ref:`Standard Connector
>> + * Properties<standard_connector_properties>`
>> + */
>
> So THAT'S how you reference other sections. I've always wondered!
You may find this helpful:
https://www.sphinx-doc.org/en/master/usage/restructuredtext/roles.html
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [Intel-gfx] [PATCH 1/9] drm/connector: Add support for privacy-screen properties (v4)
@ 2021-09-16 8:26 ` Jani Nikula
0 siblings, 0 replies; 84+ messages in thread
From: Jani Nikula @ 2021-09-16 8:26 UTC (permalink / raw)
To: Lyude Paul, Hans de Goede, 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, Mario Limonciello
On Wed, 15 Sep 2021, Lyude Paul <lyude@redhat.com> wrote:
> On Mon, 2021-09-06 at 09:35 +0200, Hans de Goede wrote:
>>
>> + /**
>> + * @privacy_screen_sw_state: See :ref:`Standard Connector
>> + * Properties<standard_connector_properties>`
>> + */
>
> So THAT'S how you reference other sections. I've always wondered!
You may find this helpful:
https://www.sphinx-doc.org/en/master/usage/restructuredtext/roles.html
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [PATCH 2/9] drm: Add privacy-screen class (v3)
2021-09-15 20:01 ` Lyude Paul
@ 2021-09-16 8:49 ` Hans de Goede
-1 siblings, 0 replies; 84+ messages in thread
From: Hans de Goede @ 2021-09-16 8:49 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 Lyude,
Thank you very much for the review of this series.
On 9/15/21 10:01 PM, Lyude Paul wrote:
> On Mon, 2021-09-06 at 09:35 +0200, Hans de Goede wrote:
>> 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.
>>
>> Changes in v2:
>> - Make CONFIG_DRM_PRIVACY_SCREEN a bool which controls if the drm_privacy
>> code gets built as part of the main drm module rather then making it
>> a tristate which builds its own module.
>> - Add a #if IS_ENABLED(CONFIG_DRM_PRIVACY_SCREEN) check to
>> drm_privacy_screen_consumer.h and define stubs when the check fails.
>> Together these 2 changes fix several dependency issues.
>> - Remove module related code now that this is part of the main drm.ko
>> - Use drm_class as class for the privacy-screen devices instead of
>> adding a separate class for this
>>
>> Changes in v3:
>> - Make the static inline drm_privacy_screen_get_state() stub set sw_state
>> and hw_state to PRIVACY_SCREEN_DISABLED to squelch an uninitialized
>> variable warning when CONFIG_DRM_PRIVICAY_SCREEN is not set
>>
>> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>> ---
>> Documentation/gpu/drm-kms-helpers.rst | 15 +
>> MAINTAINERS | 8 +
>> drivers/gpu/drm/Kconfig | 4 +
>> drivers/gpu/drm/Makefile | 1 +
>> drivers/gpu/drm/drm_drv.c | 4 +
>> drivers/gpu/drm/drm_privacy_screen.c | 401 ++++++++++++++++++++++
>> include/drm/drm_privacy_screen_consumer.h | 50 +++
>> include/drm/drm_privacy_screen_driver.h | 80 +++++
>> include/drm/drm_privacy_screen_machine.h | 41 +++
>> 9 files changed, 604 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 389892f36185..5d8715d2f998 100644
>> --- a/Documentation/gpu/drm-kms-helpers.rst
>> +++ b/Documentation/gpu/drm-kms-helpers.rst
>> @@ -423,3 +423,18 @@ Legacy CRTC/Modeset Helper Functions Reference
>>
>> .. kernel-doc:: drivers/gpu/drm/drm_crtc_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 ede4a37a53b3..a272ca600f98 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -6376,6 +6376,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 b17e231ca6f7..7249b010ab90 100644
>> --- a/drivers/gpu/drm/Kconfig
>> +++ b/drivers/gpu/drm/Kconfig
>> @@ -481,3 +481,7 @@ config DRM_PANEL_ORIENTATION_QUIRKS
>> config DRM_LIB_RANDOM
>> bool
>> default n
>> +
>> +config DRM_PRIVACY_SCREEN
>> + bool
>> + default n
>
> This is probably worth documenting for folks configuring their kernels to
> explain what this actually does (something simple like "Controls programmable
> privacy screens found on some devices, if unsure select Y" would probably be
> fine)
Like the "config DRM_LIB_RANDOM" above it, this is not user selectable,
(notice there is no text after the "bool"), this is selected by drivers
which implement drm-privacy-screen control, such as the thinkpad_acpi
driver.
If no such drivers is selected and thus CONFIG_DRM_PRIVACY_SCREEN is
not enabled then include/drm/drm_privacy_screen_consumer.h
and drm_privacy_screen_machine.h provide no-op stubs so that the
integration with the drm-core still builds without needing #ifdef-s
in the drm-core.
>
>> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
>> index 0dff40bb863c..788fc37096f6 100644
>> --- a/drivers/gpu/drm/Makefile
>> +++ b/drivers/gpu/drm/Makefile
>> @@ -32,6 +32,7 @@ drm-$(CONFIG_OF) += drm_of.o
>> drm-$(CONFIG_PCI) += drm_pci.o
>> drm-$(CONFIG_DEBUG_FS) += drm_debugfs.o drm_debugfs_crc.o
>> drm-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
>> +drm-$(CONFIG_DRM_PRIVACY_SCREEN) += drm_privacy_screen.o
>>
>> obj-$(CONFIG_DRM_DP_AUX_BUS) += drm_dp_aux_bus.o
>>
>> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
>> index 7a5097467ba5..dc293b771c3f 100644
>> --- a/drivers/gpu/drm/drm_drv.c
>> +++ b/drivers/gpu/drm/drm_drv.c
>> @@ -43,6 +43,7 @@
>> #include <drm/drm_managed.h>
>> #include <drm/drm_mode_object.h>
>> #include <drm/drm_print.h>
>> +#include <drm/drm_privacy_screen_machine.h>
>>
>> #include "drm_crtc_internal.h"
>> #include "drm_internal.h"
>> @@ -1029,6 +1030,7 @@ static const struct file_operations drm_stub_fops = {
>>
>> static void drm_core_exit(void)
>> {
>> + drm_privacy_screen_lookup_exit();
>> unregister_chrdev(DRM_MAJOR, "drm");
>> debugfs_remove(drm_debugfs_root);
>> drm_sysfs_destroy();
>> @@ -1056,6 +1058,8 @@ static int __init drm_core_init(void)
>> if (ret < 0)
>> goto error;
>>
>> + drm_privacy_screen_lookup_init();
>> +
>> drm_core_init_complete = true;
>>
>> DRM_DEBUG("Initialized\n");
>> diff --git a/drivers/gpu/drm/drm_privacy_screen.c
>> b/drivers/gpu/drm/drm_privacy_screen.c
>> new file mode 100644
>> index 000000000000..294a09194bfb
>> --- /dev/null
>> +++ b/drivers/gpu/drm/drm_privacy_screen.c
>> @@ -0,0 +1,401 @@
>> +// SPDX-License-Identifier: MIT
>> +/*
>> + * Copyright (C) 2020 - 2021 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>
>> +#include "drm_internal.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 device_type drm_privacy_screen_type = {
>> + .name = "privacy_screen",
>> + .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_class;
>> + priv->dev.type = &drm_privacy_screen_type;
>> + priv->dev.parent = parent;
>> + priv->dev.release = drm_privacy_screen_device_release;
>> + dev_set_name(&priv->dev, "privacy_screen-%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);
>> diff --git a/include/drm/drm_privacy_screen_consumer.h
>> b/include/drm/drm_privacy_screen_consumer.h
>> new file mode 100644
>> index 000000000000..0cbd23b0453d
>> --- /dev/null
>> +++ b/include/drm/drm_privacy_screen_consumer.h
>> @@ -0,0 +1,50 @@
>> +/* 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;
>> +
>> +#if IS_ENABLED(CONFIG_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);
>> +#else
>> +static inline struct drm_privacy_screen *drm_privacy_screen_get(struct
>> device *dev,
>> + const char
>> *con_id)
>> +{
>> + return ERR_PTR(-ENODEV);
>> +}
>> +static inline void drm_privacy_screen_put(struct drm_privacy_screen *priv)
>> +{
>> +}
>> +static inline int drm_privacy_screen_set_sw_state(struct drm_privacy_screen
>> *priv,
>> + enum
>> drm_privacy_screen_status sw_state)
>> +{
>> + return -ENODEV;
>> +}
>> +static inline 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)
>> +{
>> + *sw_state_ret = PRIVACY_SCREEN_DISABLED;
>> + *hw_state_ret = PRIVACY_SCREEN_DISABLED;
>> +}
>> +#endif
>> +
>> +#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..aaa0d38cce92
>> --- /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. */
>
> I think this patch mostly looks good, the one part that I'm a little confused
> on here is the con_id. Perhaps I missed this when looking over this patch, but
> what "connector name" are we referring to here - the DRM connector name (e.g.
> eDP-1), or something else?
Yes con_id refers to the DRM connector name.
> The reason I ask is because I wonder if connector
> names are really the way that we want to be looking DRM connectors up, since I
> believe it's possible for two different GPUs to have DRM connectors with the
> same name.
Right this is why the lookup matches on both the GPU's (consumer's (1))
dev_name and the con_id, the combination of these should always by
unique.
I hope this helps explain how this is intended to work
(and works on the ThinkPad T14 gen 1 which I have tested this on).
Regards,
Hans
1) The consumer is the GPU device/driver which wants to tie a
drm-privacy-screen control provider to a LCD-panel output.
>
>> + 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_lookup_init(void)
>> +{
>> +}
>> +static inline void drm_privacy_screen_lookup_exit(void)
>> +{
>> +}
>> +
>> +#endif
>
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [Intel-gfx] [PATCH 2/9] drm: Add privacy-screen class (v3)
@ 2021-09-16 8:49 ` Hans de Goede
0 siblings, 0 replies; 84+ messages in thread
From: Hans de Goede @ 2021-09-16 8:49 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 Lyude,
Thank you very much for the review of this series.
On 9/15/21 10:01 PM, Lyude Paul wrote:
> On Mon, 2021-09-06 at 09:35 +0200, Hans de Goede wrote:
>> 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.
>>
>> Changes in v2:
>> - Make CONFIG_DRM_PRIVACY_SCREEN a bool which controls if the drm_privacy
>> code gets built as part of the main drm module rather then making it
>> a tristate which builds its own module.
>> - Add a #if IS_ENABLED(CONFIG_DRM_PRIVACY_SCREEN) check to
>> drm_privacy_screen_consumer.h and define stubs when the check fails.
>> Together these 2 changes fix several dependency issues.
>> - Remove module related code now that this is part of the main drm.ko
>> - Use drm_class as class for the privacy-screen devices instead of
>> adding a separate class for this
>>
>> Changes in v3:
>> - Make the static inline drm_privacy_screen_get_state() stub set sw_state
>> and hw_state to PRIVACY_SCREEN_DISABLED to squelch an uninitialized
>> variable warning when CONFIG_DRM_PRIVICAY_SCREEN is not set
>>
>> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>> ---
>> Documentation/gpu/drm-kms-helpers.rst | 15 +
>> MAINTAINERS | 8 +
>> drivers/gpu/drm/Kconfig | 4 +
>> drivers/gpu/drm/Makefile | 1 +
>> drivers/gpu/drm/drm_drv.c | 4 +
>> drivers/gpu/drm/drm_privacy_screen.c | 401 ++++++++++++++++++++++
>> include/drm/drm_privacy_screen_consumer.h | 50 +++
>> include/drm/drm_privacy_screen_driver.h | 80 +++++
>> include/drm/drm_privacy_screen_machine.h | 41 +++
>> 9 files changed, 604 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 389892f36185..5d8715d2f998 100644
>> --- a/Documentation/gpu/drm-kms-helpers.rst
>> +++ b/Documentation/gpu/drm-kms-helpers.rst
>> @@ -423,3 +423,18 @@ Legacy CRTC/Modeset Helper Functions Reference
>>
>> .. kernel-doc:: drivers/gpu/drm/drm_crtc_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 ede4a37a53b3..a272ca600f98 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -6376,6 +6376,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 b17e231ca6f7..7249b010ab90 100644
>> --- a/drivers/gpu/drm/Kconfig
>> +++ b/drivers/gpu/drm/Kconfig
>> @@ -481,3 +481,7 @@ config DRM_PANEL_ORIENTATION_QUIRKS
>> config DRM_LIB_RANDOM
>> bool
>> default n
>> +
>> +config DRM_PRIVACY_SCREEN
>> + bool
>> + default n
>
> This is probably worth documenting for folks configuring their kernels to
> explain what this actually does (something simple like "Controls programmable
> privacy screens found on some devices, if unsure select Y" would probably be
> fine)
Like the "config DRM_LIB_RANDOM" above it, this is not user selectable,
(notice there is no text after the "bool"), this is selected by drivers
which implement drm-privacy-screen control, such as the thinkpad_acpi
driver.
If no such drivers is selected and thus CONFIG_DRM_PRIVACY_SCREEN is
not enabled then include/drm/drm_privacy_screen_consumer.h
and drm_privacy_screen_machine.h provide no-op stubs so that the
integration with the drm-core still builds without needing #ifdef-s
in the drm-core.
>
>> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
>> index 0dff40bb863c..788fc37096f6 100644
>> --- a/drivers/gpu/drm/Makefile
>> +++ b/drivers/gpu/drm/Makefile
>> @@ -32,6 +32,7 @@ drm-$(CONFIG_OF) += drm_of.o
>> drm-$(CONFIG_PCI) += drm_pci.o
>> drm-$(CONFIG_DEBUG_FS) += drm_debugfs.o drm_debugfs_crc.o
>> drm-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
>> +drm-$(CONFIG_DRM_PRIVACY_SCREEN) += drm_privacy_screen.o
>>
>> obj-$(CONFIG_DRM_DP_AUX_BUS) += drm_dp_aux_bus.o
>>
>> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
>> index 7a5097467ba5..dc293b771c3f 100644
>> --- a/drivers/gpu/drm/drm_drv.c
>> +++ b/drivers/gpu/drm/drm_drv.c
>> @@ -43,6 +43,7 @@
>> #include <drm/drm_managed.h>
>> #include <drm/drm_mode_object.h>
>> #include <drm/drm_print.h>
>> +#include <drm/drm_privacy_screen_machine.h>
>>
>> #include "drm_crtc_internal.h"
>> #include "drm_internal.h"
>> @@ -1029,6 +1030,7 @@ static const struct file_operations drm_stub_fops = {
>>
>> static void drm_core_exit(void)
>> {
>> + drm_privacy_screen_lookup_exit();
>> unregister_chrdev(DRM_MAJOR, "drm");
>> debugfs_remove(drm_debugfs_root);
>> drm_sysfs_destroy();
>> @@ -1056,6 +1058,8 @@ static int __init drm_core_init(void)
>> if (ret < 0)
>> goto error;
>>
>> + drm_privacy_screen_lookup_init();
>> +
>> drm_core_init_complete = true;
>>
>> DRM_DEBUG("Initialized\n");
>> diff --git a/drivers/gpu/drm/drm_privacy_screen.c
>> b/drivers/gpu/drm/drm_privacy_screen.c
>> new file mode 100644
>> index 000000000000..294a09194bfb
>> --- /dev/null
>> +++ b/drivers/gpu/drm/drm_privacy_screen.c
>> @@ -0,0 +1,401 @@
>> +// SPDX-License-Identifier: MIT
>> +/*
>> + * Copyright (C) 2020 - 2021 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>
>> +#include "drm_internal.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 device_type drm_privacy_screen_type = {
>> + .name = "privacy_screen",
>> + .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_class;
>> + priv->dev.type = &drm_privacy_screen_type;
>> + priv->dev.parent = parent;
>> + priv->dev.release = drm_privacy_screen_device_release;
>> + dev_set_name(&priv->dev, "privacy_screen-%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);
>> diff --git a/include/drm/drm_privacy_screen_consumer.h
>> b/include/drm/drm_privacy_screen_consumer.h
>> new file mode 100644
>> index 000000000000..0cbd23b0453d
>> --- /dev/null
>> +++ b/include/drm/drm_privacy_screen_consumer.h
>> @@ -0,0 +1,50 @@
>> +/* 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;
>> +
>> +#if IS_ENABLED(CONFIG_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);
>> +#else
>> +static inline struct drm_privacy_screen *drm_privacy_screen_get(struct
>> device *dev,
>> + const char
>> *con_id)
>> +{
>> + return ERR_PTR(-ENODEV);
>> +}
>> +static inline void drm_privacy_screen_put(struct drm_privacy_screen *priv)
>> +{
>> +}
>> +static inline int drm_privacy_screen_set_sw_state(struct drm_privacy_screen
>> *priv,
>> + enum
>> drm_privacy_screen_status sw_state)
>> +{
>> + return -ENODEV;
>> +}
>> +static inline 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)
>> +{
>> + *sw_state_ret = PRIVACY_SCREEN_DISABLED;
>> + *hw_state_ret = PRIVACY_SCREEN_DISABLED;
>> +}
>> +#endif
>> +
>> +#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..aaa0d38cce92
>> --- /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. */
>
> I think this patch mostly looks good, the one part that I'm a little confused
> on here is the con_id. Perhaps I missed this when looking over this patch, but
> what "connector name" are we referring to here - the DRM connector name (e.g.
> eDP-1), or something else?
Yes con_id refers to the DRM connector name.
> The reason I ask is because I wonder if connector
> names are really the way that we want to be looking DRM connectors up, since I
> believe it's possible for two different GPUs to have DRM connectors with the
> same name.
Right this is why the lookup matches on both the GPU's (consumer's (1))
dev_name and the con_id, the combination of these should always by
unique.
I hope this helps explain how this is intended to work
(and works on the ThinkPad T14 gen 1 which I have tested this on).
Regards,
Hans
1) The consumer is the GPU device/driver which wants to tie a
drm-privacy-screen control provider to a LCD-panel output.
>
>> + 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_lookup_init(void)
>> +{
>> +}
>> +static inline void drm_privacy_screen_lookup_exit(void)
>> +{
>> +}
>> +
>> +#endif
>
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [PATCH 3/9] drm/privacy-screen: Add X86 specific arch init code
2021-09-06 7:35 ` [Intel-gfx] " Hans de Goede
@ 2021-09-16 8:51 ` Jani Nikula
-1 siblings, 0 replies; 84+ messages in thread
From: Jani Nikula @ 2021-09-16 8:51 UTC (permalink / raw)
To: Hans de Goede, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rajat Jain, 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
On Mon, 06 Sep 2021, Hans de Goede <hdegoede@redhat.com> wrote:
> 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.
>
> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> ---
> drivers/gpu/drm/Makefile | 2 +-
> drivers/gpu/drm/drm_privacy_screen_x86.c | 86 ++++++++++++++++++++++++
> include/drm/drm_privacy_screen_machine.h | 5 ++
> 3 files changed, 92 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 788fc37096f6..12997ca5670d 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -32,7 +32,7 @@ drm-$(CONFIG_OF) += drm_of.o
> drm-$(CONFIG_PCI) += drm_pci.o
> drm-$(CONFIG_DEBUG_FS) += drm_debugfs.o drm_debugfs_crc.o
> drm-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
> -drm-$(CONFIG_DRM_PRIVACY_SCREEN) += drm_privacy_screen.o
> +drm-$(CONFIG_DRM_PRIVACY_SCREEN) += drm_privacy_screen.o drm_privacy_screen_x86.o
Would be nice to avoid building drm_privacy_screen_x86.o altogether for
CONFIG_X86=n, and avoid...
>
> obj-$(CONFIG_DRM_DP_AUX_BUS) += drm_dp_aux_bus.o
>
> 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..a2cafb294ca6
> --- /dev/null
> +++ b/drivers/gpu/drm/drm_privacy_screen_x86.c
> @@ -0,0 +1,86 @@
> +// 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>
> +
> +#ifdef CONFIG_X86
...ifdefs that cover the entire file. This can be a future improvement,
though.
> +static struct drm_privacy_screen_lookup arch_lookup;
> +
> +struct arch_init_data {
> + struct drm_privacy_screen_lookup lookup;
> + bool (*detect)(void);
> +};
> +
> +#if IS_ENABLED(CONFIG_THINKPAD_ACPI)
> +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;
> +}
> +#endif
> +
> +static const struct arch_init_data arch_init_data[] __initconst = {
> +#if IS_ENABLED(CONFIG_THINKPAD_ACPI)
> + {
> + .lookup = {
> + .dev_id = NULL,
> + .con_id = NULL,
> + .provider = "privacy_screen-thinkpad_acpi",
> + },
> + .detect = detect_thinkpad_privacy_screen,
> + },
> +#endif
> +};
> +
> +void __init drm_privacy_screen_lookup_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 drm_privacy_screen_lookup_exit(void)
> +{
> + if (arch_lookup.provider)
> + drm_privacy_screen_lookup_remove(&arch_lookup);
> +}
> +#endif /* ifdef CONFIG_X86 */
> diff --git a/include/drm/drm_privacy_screen_machine.h b/include/drm/drm_privacy_screen_machine.h
> index aaa0d38cce92..02e5371904d3 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);
>
> +#if IS_ENABLED(CONFIG_DRM_PRIVACY_SCREEN) && IS_ENABLED(CONFIG_X86)
> +void drm_privacy_screen_lookup_init(void);
> +void drm_privacy_screen_lookup_exit(void);
> +#else
> static inline void drm_privacy_screen_lookup_init(void)
> {
> }
> static inline void drm_privacy_screen_lookup_exit(void)
> {
> }
> +#endif
>
> #endif
--
Jani Nikula, Intel Open Source Graphics Center
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [Intel-gfx] [PATCH 3/9] drm/privacy-screen: Add X86 specific arch init code
@ 2021-09-16 8:51 ` Jani Nikula
0 siblings, 0 replies; 84+ messages in thread
From: Jani Nikula @ 2021-09-16 8:51 UTC (permalink / raw)
To: Hans de Goede, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rajat Jain, 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
On Mon, 06 Sep 2021, Hans de Goede <hdegoede@redhat.com> wrote:
> 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.
>
> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> ---
> drivers/gpu/drm/Makefile | 2 +-
> drivers/gpu/drm/drm_privacy_screen_x86.c | 86 ++++++++++++++++++++++++
> include/drm/drm_privacy_screen_machine.h | 5 ++
> 3 files changed, 92 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 788fc37096f6..12997ca5670d 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -32,7 +32,7 @@ drm-$(CONFIG_OF) += drm_of.o
> drm-$(CONFIG_PCI) += drm_pci.o
> drm-$(CONFIG_DEBUG_FS) += drm_debugfs.o drm_debugfs_crc.o
> drm-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
> -drm-$(CONFIG_DRM_PRIVACY_SCREEN) += drm_privacy_screen.o
> +drm-$(CONFIG_DRM_PRIVACY_SCREEN) += drm_privacy_screen.o drm_privacy_screen_x86.o
Would be nice to avoid building drm_privacy_screen_x86.o altogether for
CONFIG_X86=n, and avoid...
>
> obj-$(CONFIG_DRM_DP_AUX_BUS) += drm_dp_aux_bus.o
>
> 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..a2cafb294ca6
> --- /dev/null
> +++ b/drivers/gpu/drm/drm_privacy_screen_x86.c
> @@ -0,0 +1,86 @@
> +// 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>
> +
> +#ifdef CONFIG_X86
...ifdefs that cover the entire file. This can be a future improvement,
though.
> +static struct drm_privacy_screen_lookup arch_lookup;
> +
> +struct arch_init_data {
> + struct drm_privacy_screen_lookup lookup;
> + bool (*detect)(void);
> +};
> +
> +#if IS_ENABLED(CONFIG_THINKPAD_ACPI)
> +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;
> +}
> +#endif
> +
> +static const struct arch_init_data arch_init_data[] __initconst = {
> +#if IS_ENABLED(CONFIG_THINKPAD_ACPI)
> + {
> + .lookup = {
> + .dev_id = NULL,
> + .con_id = NULL,
> + .provider = "privacy_screen-thinkpad_acpi",
> + },
> + .detect = detect_thinkpad_privacy_screen,
> + },
> +#endif
> +};
> +
> +void __init drm_privacy_screen_lookup_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 drm_privacy_screen_lookup_exit(void)
> +{
> + if (arch_lookup.provider)
> + drm_privacy_screen_lookup_remove(&arch_lookup);
> +}
> +#endif /* ifdef CONFIG_X86 */
> diff --git a/include/drm/drm_privacy_screen_machine.h b/include/drm/drm_privacy_screen_machine.h
> index aaa0d38cce92..02e5371904d3 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);
>
> +#if IS_ENABLED(CONFIG_DRM_PRIVACY_SCREEN) && IS_ENABLED(CONFIG_X86)
> +void drm_privacy_screen_lookup_init(void);
> +void drm_privacy_screen_lookup_exit(void);
> +#else
> static inline void drm_privacy_screen_lookup_init(void)
> {
> }
> static inline void drm_privacy_screen_lookup_exit(void)
> {
> }
> +#endif
>
> #endif
--
Jani Nikula, Intel Open Source Graphics Center
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [PATCH 4/9] drm/privacy-screen: Add notifier support
2021-09-15 20:26 ` [Intel-gfx] " Lyude Paul
@ 2021-09-16 9:06 ` Hans de Goede
-1 siblings, 0 replies; 84+ messages in thread
From: Hans de Goede @ 2021-09-16 9:06 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 10:26 PM, Lyude Paul wrote:
> On Mon, 2021-09-06 at 09:35 +0200, Hans de Goede wrote:
>> 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.
>>
>> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>> ---
>> drivers/gpu/drm/drm_privacy_screen.c | 67 +++++++++++++++++++++++
>> include/drm/drm_privacy_screen_consumer.h | 15 +++++
>> include/drm/drm_privacy_screen_driver.h | 4 ++
>> 3 files changed, 86 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_privacy_screen.c
>> b/drivers/gpu/drm/drm_privacy_screen.c
>> index 294a09194bfb..7a5f878c3171 100644
>> --- a/drivers/gpu/drm/drm_privacy_screen.c
>> +++ b/drivers/gpu/drm/drm_privacy_screen.c
>> @@ -255,6 +255,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_class;
>> priv->dev.type = &drm_privacy_screen_type;
>> @@ -399,3 +443,26 @@ void drm_privacy_screen_unregister(struct
>> drm_privacy_screen *priv)
>> device_unregister(&priv->dev);
>> }
>> 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;
>
> Are we sure about this check? mutex_is_locked() checks whether a mutex is
> locked by anyone, not just us. So this seems like it would cause us to
> WARN_ON() and abort if anyone else (not just ourselves) is holding the lock to
> read the privacy screen state.
Thank you for catching this, yes this check indeed is wrong. AFAIK
there is no way to check that the mutex has been locked by us, so this
extra sanity check simply needs to be removed.
I'll drop the check before pushing this to drm-misc-next (more on
that in a reply to the cover letter), if that is ok with you.
Or do you want me to do a new version addressing this?
Regards,
Hans
>
>> +
>> + blocking_notifier_call_chain(&priv->notifier_head, 0, priv);
>> +}
>> +EXPORT_SYMBOL(drm_privacy_screen_call_notifier_chain);
>> diff --git a/include/drm/drm_privacy_screen_consumer.h
>> b/include/drm/drm_privacy_screen_consumer.h
>> index 0cbd23b0453d..7f66a90d15b7 100644
>> --- a/include/drm/drm_privacy_screen_consumer.h
>> +++ b/include/drm/drm_privacy_screen_consumer.h
>> @@ -24,6 +24,11 @@ int drm_privacy_screen_set_sw_state(struct
>> drm_privacy_screen *priv,
>> 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);
>> #else
>> static inline struct drm_privacy_screen *drm_privacy_screen_get(struct
>> device *dev,
>> const char
>> *con_id)
>> @@ -45,6 +50,16 @@ static inline void drm_privacy_screen_get_state(struct
>> drm_privacy_screen *priv,
>> *sw_state_ret = PRIVACY_SCREEN_DISABLED;
>> *hw_state_ret = PRIVACY_SCREEN_DISABLED;
>> }
>> +static inline int drm_privacy_screen_register_notifier(struct
>> drm_privacy_screen *priv,
>> + struct notifier_block
>> *nb)
>> +{
>> + return -ENODEV;
>> +}
>> +static inline int drm_privacy_screen_unregister_notifier(struct
>> drm_privacy_screen *priv,
>> + struct
>> notifier_block *nb)
>> +{
>> + return -ENODEV;
>> +}
>> #endif
>>
>> #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
>
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [Intel-gfx] [PATCH 4/9] drm/privacy-screen: Add notifier support
@ 2021-09-16 9:06 ` Hans de Goede
0 siblings, 0 replies; 84+ messages in thread
From: Hans de Goede @ 2021-09-16 9:06 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 10:26 PM, Lyude Paul wrote:
> On Mon, 2021-09-06 at 09:35 +0200, Hans de Goede wrote:
>> 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.
>>
>> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>> ---
>> drivers/gpu/drm/drm_privacy_screen.c | 67 +++++++++++++++++++++++
>> include/drm/drm_privacy_screen_consumer.h | 15 +++++
>> include/drm/drm_privacy_screen_driver.h | 4 ++
>> 3 files changed, 86 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_privacy_screen.c
>> b/drivers/gpu/drm/drm_privacy_screen.c
>> index 294a09194bfb..7a5f878c3171 100644
>> --- a/drivers/gpu/drm/drm_privacy_screen.c
>> +++ b/drivers/gpu/drm/drm_privacy_screen.c
>> @@ -255,6 +255,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_class;
>> priv->dev.type = &drm_privacy_screen_type;
>> @@ -399,3 +443,26 @@ void drm_privacy_screen_unregister(struct
>> drm_privacy_screen *priv)
>> device_unregister(&priv->dev);
>> }
>> 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;
>
> Are we sure about this check? mutex_is_locked() checks whether a mutex is
> locked by anyone, not just us. So this seems like it would cause us to
> WARN_ON() and abort if anyone else (not just ourselves) is holding the lock to
> read the privacy screen state.
Thank you for catching this, yes this check indeed is wrong. AFAIK
there is no way to check that the mutex has been locked by us, so this
extra sanity check simply needs to be removed.
I'll drop the check before pushing this to drm-misc-next (more on
that in a reply to the cover letter), if that is ok with you.
Or do you want me to do a new version addressing this?
Regards,
Hans
>
>> +
>> + blocking_notifier_call_chain(&priv->notifier_head, 0, priv);
>> +}
>> +EXPORT_SYMBOL(drm_privacy_screen_call_notifier_chain);
>> diff --git a/include/drm/drm_privacy_screen_consumer.h
>> b/include/drm/drm_privacy_screen_consumer.h
>> index 0cbd23b0453d..7f66a90d15b7 100644
>> --- a/include/drm/drm_privacy_screen_consumer.h
>> +++ b/include/drm/drm_privacy_screen_consumer.h
>> @@ -24,6 +24,11 @@ int drm_privacy_screen_set_sw_state(struct
>> drm_privacy_screen *priv,
>> 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);
>> #else
>> static inline struct drm_privacy_screen *drm_privacy_screen_get(struct
>> device *dev,
>> const char
>> *con_id)
>> @@ -45,6 +50,16 @@ static inline void drm_privacy_screen_get_state(struct
>> drm_privacy_screen *priv,
>> *sw_state_ret = PRIVACY_SCREEN_DISABLED;
>> *hw_state_ret = PRIVACY_SCREEN_DISABLED;
>> }
>> +static inline int drm_privacy_screen_register_notifier(struct
>> drm_privacy_screen *priv,
>> + struct notifier_block
>> *nb)
>> +{
>> + return -ENODEV;
>> +}
>> +static inline int drm_privacy_screen_unregister_notifier(struct
>> drm_privacy_screen *priv,
>> + struct
>> notifier_block *nb)
>> +{
>> + return -ENODEV;
>> +}
>> #endif
>>
>> #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
>
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [PATCH 8/9] platform/x86: thinkpad_acpi: Register a privacy-screen device
2021-09-15 20:55 ` Lyude Paul
@ 2021-09-16 9:09 ` Hans de Goede
-1 siblings, 0 replies; 84+ messages in thread
From: Hans de Goede @ 2021-09-16 9:09 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 10:55 PM, Lyude Paul wrote:
> On Mon, 2021-09-06 at 09:35 +0200, Hans de Goede wrote:
>> 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
>
> Looks like a typo here ------------------------------^
Ack I will fix this before pushing this out.
>
>> interface which all user-space code should use to query and control
>> the privacy-screen.
>>
>> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>> ---
>> Changes in v2:
>> - Make the new lcdshadow_set_sw_state, lcdshadow_get_hw_state and
>> lcdshadow_ops symbols static
>> - Update state and call drm_privacy_screen_call_notifier_chain()
>> when the state is changed by pressing the Fn + D hotkey combo
>> ---
>> drivers/platform/x86/Kconfig | 2 +
>> drivers/platform/x86/thinkpad_acpi.c | 91 ++++++++++++++++++++--------
>> 2 files changed, 68 insertions(+), 25 deletions(-)
>>
>> diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
>> index d12db6c316ea..ae00a27f9f95 100644
>> --- a/drivers/platform/x86/Kconfig
>> +++ b/drivers/platform/x86/Kconfig
>> @@ -509,7 +509,9 @@ config THINKPAD_ACPI
>> depends on ACPI_VIDEO || ACPI_VIDEO = n
>> depends on BACKLIGHT_CLASS_DEVICE
>> depends on I2C
>> + depends on DRM
>> select ACPI_PLATFORM_PROFILE
>> + 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 b8f2556c4797..044b238730ba 100644
>> --- a/drivers/platform/x86/thinkpad_acpi.c
>> +++ b/drivers/platform/x86/thinkpad_acpi.c
>> @@ -73,6 +73,7 @@
>> #include <linux/uaccess.h>
>> #include <acpi/battery.h>
>> #include <acpi/video.h>
>> +#include <drm/drm_privacy_screen_driver.h>
>> #include "dual_accel_detect.h"
>>
>> /* ThinkPad CMOS commands */
>> @@ -157,6 +158,7 @@ enum tpacpi_hkey_event_t {
>> TP_HKEY_EV_VOL_UP = 0x1015, /* Volume up or unmute */
>> TP_HKEY_EV_VOL_DOWN = 0x1016, /* Volume down or unmute
>> */
>> TP_HKEY_EV_VOL_MUTE = 0x1017, /* Mixer output mute */
>> + TP_HKEY_EV_PRIVACYGUARD_TOGGLE = 0x130f, /* Toggle priv.guard
>> on/off */
>>
>> /* Reasons for waking up from S3/S4 */
>> TP_HKEY_EV_WKUP_S3_UNDOCK = 0x2304, /* undock requested, S3 */
>> @@ -3889,6 +3891,12 @@ static bool hotkey_notify_extended_hotkey(const u32
>> hkey)
>> {
>> unsigned int scancode;
>>
>> + switch (hkey) {
>> + case TP_HKEY_EV_PRIVACYGUARD_TOGGLE:
>> + tpacpi_driver_event(hkey);
>> + return true;
>> + }
>> +
>> /* Extended keycodes start at 0x300 and our offset into the map
>> * TP_ACPI_HOTKEYSCAN_EXTENDED_START. The calculated scancode
>> * will be positive, but might not be in the correct range.
>> @@ -9819,30 +9827,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)
>> +static 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)
>> +static 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;
>> }
>>
>> +static 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;
>> @@ -9850,36 +9868,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);
>> }
>>
>
> For privacy screens provided by x86 platform drivers this is -probably-
> correct, but only so long as we're confident that the privacy screen is always
> going to be controllable regardless of the power state of the actual LCD
> panel.
Right, in this case the privacy-screen control is entirely independent
of the actual LCD state. Also notice that this code does not introduce
the re-storing of the privacy-screen state, that was already there, it
merely changes it to go through the new drm_privacy_screen API.
> I'd think we would need to handle suspend/resume in the atomic commit though
> if we ever have to support systems where the two are dependent on one another,
> but, that's a simple enough change to do later if it arises that I think we
> can ignore it for now.
Ack.
Regards,
Hans
>
>> 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");
>> }
>>
>> @@ -9891,7 +9917,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, ","))) {
>> @@ -9903,11 +9929,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,
>> @@ -10717,6 +10750,14 @@ static void tpacpi_driver_event(const unsigned int
>> hkey_event)
>> if (!atomic_add_unless(&dytc_ignore_event, -1, 0))
>> dytc_profile_refresh();
>> }
>> +
>> + if (lcdshadow_dev && hkey_event == TP_HKEY_EV_PRIVACYGUARD_TOGGLE) {
>> + mutex_lock(&lcdshadow_dev->lock);
>> + lcdshadow_get_hw_state(lcdshadow_dev);
>> + mutex_unlock(&lcdshadow_dev->lock);
>> +
>> + drm_privacy_screen_call_notifier_chain(lcdshadow_dev);
>> + }
>> }
>>
>> static void hotkey_driver_event(const unsigned int scancode)
>
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [Intel-gfx] [PATCH 8/9] platform/x86: thinkpad_acpi: Register a privacy-screen device
@ 2021-09-16 9:09 ` Hans de Goede
0 siblings, 0 replies; 84+ messages in thread
From: Hans de Goede @ 2021-09-16 9:09 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 10:55 PM, Lyude Paul wrote:
> On Mon, 2021-09-06 at 09:35 +0200, Hans de Goede wrote:
>> 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
>
> Looks like a typo here ------------------------------^
Ack I will fix this before pushing this out.
>
>> interface which all user-space code should use to query and control
>> the privacy-screen.
>>
>> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>> ---
>> Changes in v2:
>> - Make the new lcdshadow_set_sw_state, lcdshadow_get_hw_state and
>> lcdshadow_ops symbols static
>> - Update state and call drm_privacy_screen_call_notifier_chain()
>> when the state is changed by pressing the Fn + D hotkey combo
>> ---
>> drivers/platform/x86/Kconfig | 2 +
>> drivers/platform/x86/thinkpad_acpi.c | 91 ++++++++++++++++++++--------
>> 2 files changed, 68 insertions(+), 25 deletions(-)
>>
>> diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
>> index d12db6c316ea..ae00a27f9f95 100644
>> --- a/drivers/platform/x86/Kconfig
>> +++ b/drivers/platform/x86/Kconfig
>> @@ -509,7 +509,9 @@ config THINKPAD_ACPI
>> depends on ACPI_VIDEO || ACPI_VIDEO = n
>> depends on BACKLIGHT_CLASS_DEVICE
>> depends on I2C
>> + depends on DRM
>> select ACPI_PLATFORM_PROFILE
>> + 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 b8f2556c4797..044b238730ba 100644
>> --- a/drivers/platform/x86/thinkpad_acpi.c
>> +++ b/drivers/platform/x86/thinkpad_acpi.c
>> @@ -73,6 +73,7 @@
>> #include <linux/uaccess.h>
>> #include <acpi/battery.h>
>> #include <acpi/video.h>
>> +#include <drm/drm_privacy_screen_driver.h>
>> #include "dual_accel_detect.h"
>>
>> /* ThinkPad CMOS commands */
>> @@ -157,6 +158,7 @@ enum tpacpi_hkey_event_t {
>> TP_HKEY_EV_VOL_UP = 0x1015, /* Volume up or unmute */
>> TP_HKEY_EV_VOL_DOWN = 0x1016, /* Volume down or unmute
>> */
>> TP_HKEY_EV_VOL_MUTE = 0x1017, /* Mixer output mute */
>> + TP_HKEY_EV_PRIVACYGUARD_TOGGLE = 0x130f, /* Toggle priv.guard
>> on/off */
>>
>> /* Reasons for waking up from S3/S4 */
>> TP_HKEY_EV_WKUP_S3_UNDOCK = 0x2304, /* undock requested, S3 */
>> @@ -3889,6 +3891,12 @@ static bool hotkey_notify_extended_hotkey(const u32
>> hkey)
>> {
>> unsigned int scancode;
>>
>> + switch (hkey) {
>> + case TP_HKEY_EV_PRIVACYGUARD_TOGGLE:
>> + tpacpi_driver_event(hkey);
>> + return true;
>> + }
>> +
>> /* Extended keycodes start at 0x300 and our offset into the map
>> * TP_ACPI_HOTKEYSCAN_EXTENDED_START. The calculated scancode
>> * will be positive, but might not be in the correct range.
>> @@ -9819,30 +9827,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)
>> +static 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)
>> +static 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;
>> }
>>
>> +static 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;
>> @@ -9850,36 +9868,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);
>> }
>>
>
> For privacy screens provided by x86 platform drivers this is -probably-
> correct, but only so long as we're confident that the privacy screen is always
> going to be controllable regardless of the power state of the actual LCD
> panel.
Right, in this case the privacy-screen control is entirely independent
of the actual LCD state. Also notice that this code does not introduce
the re-storing of the privacy-screen state, that was already there, it
merely changes it to go through the new drm_privacy_screen API.
> I'd think we would need to handle suspend/resume in the atomic commit though
> if we ever have to support systems where the two are dependent on one another,
> but, that's a simple enough change to do later if it arises that I think we
> can ignore it for now.
Ack.
Regards,
Hans
>
>> 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");
>> }
>>
>> @@ -9891,7 +9917,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, ","))) {
>> @@ -9903,11 +9929,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,
>> @@ -10717,6 +10750,14 @@ static void tpacpi_driver_event(const unsigned int
>> hkey_event)
>> if (!atomic_add_unless(&dytc_ignore_event, -1, 0))
>> dytc_profile_refresh();
>> }
>> +
>> + if (lcdshadow_dev && hkey_event == TP_HKEY_EV_PRIVACYGUARD_TOGGLE) {
>> + mutex_lock(&lcdshadow_dev->lock);
>> + lcdshadow_get_hw_state(lcdshadow_dev);
>> + mutex_unlock(&lcdshadow_dev->lock);
>> +
>> + drm_privacy_screen_call_notifier_chain(lcdshadow_dev);
>> + }
>> }
>>
>> static void hotkey_driver_event(const unsigned int scancode)
>
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [PATCH 9/9] drm/i915: Add privacy-screen support
2021-09-15 21:11 ` Lyude Paul
@ 2021-09-16 9:12 ` Hans de Goede
-1 siblings, 0 replies; 84+ messages in thread
From: Hans de Goede @ 2021-09-16 9:12 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:11 PM, Lyude Paul wrote:
> On Mon, 2021-09-06 at 09:35 +0200, Hans de Goede wrote:
>> 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.
>
> I was going to suggest that you workaround this simply by adding a variable
> that corresponds to the most recently committed privacy screen state somewhere
> in a driver private structure. But, then I realized that's basically the same
> as what you're doing now except that your current solution stores said state
> in a shared struct. So, I think you probably do have the right idea here as
> long as we don't get any non-ACPI providers in the future. This also seems
> like something that wouldn't be difficult to fixup down the line if that ends
> up changing.
Ack, this is all kernel internal stuff so we can always rework it if necessary.
Regards,
Hans
>
>>
>> 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.
>>
>> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
>> 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 5560d2f4c352..7285873d329a 100644
>> --- a/drivers/gpu/drm/i915/display/intel_display.c
>> +++ b/drivers/gpu/drm/i915/display/intel_display.c
>> @@ -10140,6 +10140,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;
>> @@ -10237,6 +10239,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 7f8e8865048f..3aa2072cccf6 100644
>> --- a/drivers/gpu/drm/i915/display/intel_dp.c
>> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
>> @@ -37,6 +37,7 @@
>> #include <drm/drm_crtc.h>
>> #include <drm/drm_dp_helper.h>
>> #include <drm/drm_edid.h>
>> +#include <drm/drm_privacy_screen_consumer.h>
>> #include <drm/drm_probe_helper.h>
>>
>> #include "g4x_dp.h"
>> @@ -5217,6 +5218,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;
>> struct edid *edid;
>> @@ -5308,6 +5310,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->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 146f7e39182a..d6913f567a1c 100644
>> --- a/drivers/gpu/drm/i915/i915_pci.c
>> +++ b/drivers/gpu/drm/i915/i915_pci.c
>> @@ -25,6 +25,7 @@
>> #include <linux/vga_switcheroo.h>
>>
>> #include <drm/drm_drv.h>
>> +#include <drm/drm_privacy_screen_consumer.h>
>> #include <drm/i915_pciids.h>
>>
>> #include "i915_drv.h"
>> @@ -1167,6 +1168,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 &&
>> @@ -1195,7 +1197,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;
>>
>
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [Intel-gfx] [PATCH 9/9] drm/i915: Add privacy-screen support
@ 2021-09-16 9:12 ` Hans de Goede
0 siblings, 0 replies; 84+ messages in thread
From: Hans de Goede @ 2021-09-16 9:12 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:11 PM, Lyude Paul wrote:
> On Mon, 2021-09-06 at 09:35 +0200, Hans de Goede wrote:
>> 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.
>
> I was going to suggest that you workaround this simply by adding a variable
> that corresponds to the most recently committed privacy screen state somewhere
> in a driver private structure. But, then I realized that's basically the same
> as what you're doing now except that your current solution stores said state
> in a shared struct. So, I think you probably do have the right idea here as
> long as we don't get any non-ACPI providers in the future. This also seems
> like something that wouldn't be difficult to fixup down the line if that ends
> up changing.
Ack, this is all kernel internal stuff so we can always rework it if necessary.
Regards,
Hans
>
>>
>> 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.
>>
>> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
>> 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 5560d2f4c352..7285873d329a 100644
>> --- a/drivers/gpu/drm/i915/display/intel_display.c
>> +++ b/drivers/gpu/drm/i915/display/intel_display.c
>> @@ -10140,6 +10140,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;
>> @@ -10237,6 +10239,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 7f8e8865048f..3aa2072cccf6 100644
>> --- a/drivers/gpu/drm/i915/display/intel_dp.c
>> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
>> @@ -37,6 +37,7 @@
>> #include <drm/drm_crtc.h>
>> #include <drm/drm_dp_helper.h>
>> #include <drm/drm_edid.h>
>> +#include <drm/drm_privacy_screen_consumer.h>
>> #include <drm/drm_probe_helper.h>
>>
>> #include "g4x_dp.h"
>> @@ -5217,6 +5218,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;
>> struct edid *edid;
>> @@ -5308,6 +5310,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->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 146f7e39182a..d6913f567a1c 100644
>> --- a/drivers/gpu/drm/i915/i915_pci.c
>> +++ b/drivers/gpu/drm/i915/i915_pci.c
>> @@ -25,6 +25,7 @@
>> #include <linux/vga_switcheroo.h>
>>
>> #include <drm/drm_drv.h>
>> +#include <drm/drm_privacy_screen_consumer.h>
>> #include <drm/i915_pciids.h>
>>
>> #include "i915_drv.h"
>> @@ -1167,6 +1168,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 &&
>> @@ -1195,7 +1197,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;
>>
>
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [PATCH 3/9] drm/privacy-screen: Add X86 specific arch init code
2021-09-16 8:51 ` [Intel-gfx] " Jani Nikula
@ 2021-09-16 9:18 ` Hans de Goede
-1 siblings, 0 replies; 84+ messages in thread
From: Hans de Goede @ 2021-09-16 9:18 UTC (permalink / raw)
To: Jani Nikula, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Rajat Jain, Lyude, 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/16/21 10:51 AM, Jani Nikula wrote:
> On Mon, 06 Sep 2021, Hans de Goede <hdegoede@redhat.com> wrote:
>> 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.
>>
>> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>> ---
>> drivers/gpu/drm/Makefile | 2 +-
>> drivers/gpu/drm/drm_privacy_screen_x86.c | 86 ++++++++++++++++++++++++
>> include/drm/drm_privacy_screen_machine.h | 5 ++
>> 3 files changed, 92 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 788fc37096f6..12997ca5670d 100644
>> --- a/drivers/gpu/drm/Makefile
>> +++ b/drivers/gpu/drm/Makefile
>> @@ -32,7 +32,7 @@ drm-$(CONFIG_OF) += drm_of.o
>> drm-$(CONFIG_PCI) += drm_pci.o
>> drm-$(CONFIG_DEBUG_FS) += drm_debugfs.o drm_debugfs_crc.o
>> drm-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
>> -drm-$(CONFIG_DRM_PRIVACY_SCREEN) += drm_privacy_screen.o
>> +drm-$(CONFIG_DRM_PRIVACY_SCREEN) += drm_privacy_screen.o drm_privacy_screen_x86.o
>
> Would be nice to avoid building drm_privacy_screen_x86.o altogether for
> CONFIG_X86=n, and avoid...
Right unfortunately AFAIK I cannot write something like:
drm-$(CONFIG_DRM_PRIVACY_SCREEN && CONFIG_X86) += drm_privacy_screen_x86.o
So this would require adding a (non user selectable)
CONFIG_DRM_PRIVACY_SCREEN_X86 in Kconfig looking something
like this:
config DRM_PRIVACY_SCREEN
bool
default n
select DRM_PRIVACY_SCREEN_X86 if X86
config DRM_PRIVACY_SCREEN_X86
bool
default n
Which is also not really pretty.
>> obj-$(CONFIG_DRM_DP_AUX_BUS) += drm_dp_aux_bus.o
>>
>> 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..a2cafb294ca6
>> --- /dev/null
>> +++ b/drivers/gpu/drm/drm_privacy_screen_x86.c
>> @@ -0,0 +1,86 @@
>> +// 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>
>> +
>> +#ifdef CONFIG_X86
>
> ...ifdefs that cover the entire file. This can be a future improvement,
> though.
Thanks I would be happy to do a follow-up patch if we can come-up with
a better solution which we all like.
For now I would indeed prefer to move forward with this patch-set as is
because it has been rather long in the making, so it will be good if
I can finally get it upstream.
Regards,
Hans
>
>> +static struct drm_privacy_screen_lookup arch_lookup;
>> +
>> +struct arch_init_data {
>> + struct drm_privacy_screen_lookup lookup;
>> + bool (*detect)(void);
>> +};
>> +
>> +#if IS_ENABLED(CONFIG_THINKPAD_ACPI)
>> +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;
>> +}
>> +#endif
>> +
>> +static const struct arch_init_data arch_init_data[] __initconst = {
>> +#if IS_ENABLED(CONFIG_THINKPAD_ACPI)
>> + {
>> + .lookup = {
>> + .dev_id = NULL,
>> + .con_id = NULL,
>> + .provider = "privacy_screen-thinkpad_acpi",
>> + },
>> + .detect = detect_thinkpad_privacy_screen,
>> + },
>> +#endif
>> +};
>> +
>> +void __init drm_privacy_screen_lookup_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 drm_privacy_screen_lookup_exit(void)
>> +{
>> + if (arch_lookup.provider)
>> + drm_privacy_screen_lookup_remove(&arch_lookup);
>> +}
>> +#endif /* ifdef CONFIG_X86 */
>> diff --git a/include/drm/drm_privacy_screen_machine.h b/include/drm/drm_privacy_screen_machine.h
>> index aaa0d38cce92..02e5371904d3 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);
>>
>> +#if IS_ENABLED(CONFIG_DRM_PRIVACY_SCREEN) && IS_ENABLED(CONFIG_X86)
>> +void drm_privacy_screen_lookup_init(void);
>> +void drm_privacy_screen_lookup_exit(void);
>> +#else
>> static inline void drm_privacy_screen_lookup_init(void)
>> {
>> }
>> static inline void drm_privacy_screen_lookup_exit(void)
>> {
>> }
>> +#endif
>>
>> #endif
>
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [Intel-gfx] [PATCH 3/9] drm/privacy-screen: Add X86 specific arch init code
@ 2021-09-16 9:18 ` Hans de Goede
0 siblings, 0 replies; 84+ messages in thread
From: Hans de Goede @ 2021-09-16 9:18 UTC (permalink / raw)
To: Jani Nikula, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Rajat Jain, Lyude, 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/16/21 10:51 AM, Jani Nikula wrote:
> On Mon, 06 Sep 2021, Hans de Goede <hdegoede@redhat.com> wrote:
>> 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.
>>
>> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>> ---
>> drivers/gpu/drm/Makefile | 2 +-
>> drivers/gpu/drm/drm_privacy_screen_x86.c | 86 ++++++++++++++++++++++++
>> include/drm/drm_privacy_screen_machine.h | 5 ++
>> 3 files changed, 92 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 788fc37096f6..12997ca5670d 100644
>> --- a/drivers/gpu/drm/Makefile
>> +++ b/drivers/gpu/drm/Makefile
>> @@ -32,7 +32,7 @@ drm-$(CONFIG_OF) += drm_of.o
>> drm-$(CONFIG_PCI) += drm_pci.o
>> drm-$(CONFIG_DEBUG_FS) += drm_debugfs.o drm_debugfs_crc.o
>> drm-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
>> -drm-$(CONFIG_DRM_PRIVACY_SCREEN) += drm_privacy_screen.o
>> +drm-$(CONFIG_DRM_PRIVACY_SCREEN) += drm_privacy_screen.o drm_privacy_screen_x86.o
>
> Would be nice to avoid building drm_privacy_screen_x86.o altogether for
> CONFIG_X86=n, and avoid...
Right unfortunately AFAIK I cannot write something like:
drm-$(CONFIG_DRM_PRIVACY_SCREEN && CONFIG_X86) += drm_privacy_screen_x86.o
So this would require adding a (non user selectable)
CONFIG_DRM_PRIVACY_SCREEN_X86 in Kconfig looking something
like this:
config DRM_PRIVACY_SCREEN
bool
default n
select DRM_PRIVACY_SCREEN_X86 if X86
config DRM_PRIVACY_SCREEN_X86
bool
default n
Which is also not really pretty.
>> obj-$(CONFIG_DRM_DP_AUX_BUS) += drm_dp_aux_bus.o
>>
>> 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..a2cafb294ca6
>> --- /dev/null
>> +++ b/drivers/gpu/drm/drm_privacy_screen_x86.c
>> @@ -0,0 +1,86 @@
>> +// 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>
>> +
>> +#ifdef CONFIG_X86
>
> ...ifdefs that cover the entire file. This can be a future improvement,
> though.
Thanks I would be happy to do a follow-up patch if we can come-up with
a better solution which we all like.
For now I would indeed prefer to move forward with this patch-set as is
because it has been rather long in the making, so it will be good if
I can finally get it upstream.
Regards,
Hans
>
>> +static struct drm_privacy_screen_lookup arch_lookup;
>> +
>> +struct arch_init_data {
>> + struct drm_privacy_screen_lookup lookup;
>> + bool (*detect)(void);
>> +};
>> +
>> +#if IS_ENABLED(CONFIG_THINKPAD_ACPI)
>> +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;
>> +}
>> +#endif
>> +
>> +static const struct arch_init_data arch_init_data[] __initconst = {
>> +#if IS_ENABLED(CONFIG_THINKPAD_ACPI)
>> + {
>> + .lookup = {
>> + .dev_id = NULL,
>> + .con_id = NULL,
>> + .provider = "privacy_screen-thinkpad_acpi",
>> + },
>> + .detect = detect_thinkpad_privacy_screen,
>> + },
>> +#endif
>> +};
>> +
>> +void __init drm_privacy_screen_lookup_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 drm_privacy_screen_lookup_exit(void)
>> +{
>> + if (arch_lookup.provider)
>> + drm_privacy_screen_lookup_remove(&arch_lookup);
>> +}
>> +#endif /* ifdef CONFIG_X86 */
>> diff --git a/include/drm/drm_privacy_screen_machine.h b/include/drm/drm_privacy_screen_machine.h
>> index aaa0d38cce92..02e5371904d3 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);
>>
>> +#if IS_ENABLED(CONFIG_DRM_PRIVACY_SCREEN) && IS_ENABLED(CONFIG_X86)
>> +void drm_privacy_screen_lookup_init(void);
>> +void drm_privacy_screen_lookup_exit(void);
>> +#else
>> static inline void drm_privacy_screen_lookup_init(void)
>> {
>> }
>> static inline void drm_privacy_screen_lookup_exit(void)
>> {
>> }
>> +#endif
>>
>> #endif
>
^ permalink raw reply [flat|nested] 84+ 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
-1 siblings, 0 replies; 84+ 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] 84+ messages in thread
* Re: [Intel-gfx] [PATCH 0/9] drm: Add privacy-screen class and connector properties
@ 2021-09-16 9:30 ` Hans de Goede
0 siblings, 0 replies; 84+ 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] 84+ messages in thread
* Re: [PATCH 9/9] drm/i915: Add privacy-screen support
2021-09-06 7:35 ` [Intel-gfx] " Hans de Goede
@ 2021-09-16 9:40 ` Jani Nikula
-1 siblings, 0 replies; 84+ messages in thread
From: Jani Nikula @ 2021-09-16 9:40 UTC (permalink / raw)
To: Hans de Goede, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rajat Jain, Lyude, Joonas Lahtinen,
Rodrigo Vivi, Mark Gross, Andy Shevchenko,
Ville Syrjälä
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
Cc: Ville for input here, see question inline.
On Mon, 06 Sep 2021, Hans de Goede <hdegoede@redhat.com> wrote:
> 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.
>
> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
> 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 5560d2f4c352..7285873d329a 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -10140,6 +10140,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;
> @@ -10237,6 +10239,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 7f8e8865048f..3aa2072cccf6 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -37,6 +37,7 @@
> #include <drm/drm_crtc.h>
> #include <drm/drm_dp_helper.h>
> #include <drm/drm_edid.h>
> +#include <drm/drm_privacy_screen_consumer.h>
> #include <drm/drm_probe_helper.h>
>
> #include "g4x_dp.h"
> @@ -5217,6 +5218,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;
> struct edid *edid;
> @@ -5308,6 +5310,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->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 146f7e39182a..d6913f567a1c 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -25,6 +25,7 @@
> #include <linux/vga_switcheroo.h>
>
> #include <drm/drm_drv.h>
> +#include <drm/drm_privacy_screen_consumer.h>
> #include <drm/i915_pciids.h>
>
> #include "i915_drv.h"
> @@ -1167,6 +1168,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 &&
> @@ -1195,7 +1197,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;
Ideally, neither i915_pci_probe() nor i915_driver_probe() should assume
we have display. We might not. We should not wait if we are never going
to initialize display.
Alas, we'll only know after i915_driver_probe() ->
i915_driver_mmio_probe() -> intel_device_info_runtime_init(), which
modifies ->pipe_mask, which is the single point of truth. See
HAS_DISPLAY().
We do have tests for failing probe at various points (see the
i915_inject_probe_failure() calls) to stress the cleanup paths in
CI. Part of the point was to prepare us for -EPROBE_DEFER returns.
Looks like the earliest/cleanest point for checking this is in
intel_modeset_init_noirq(), i.e. first display init call. But I admit it
gives me an uneasy feeling to return -EPROBE_DEFER at that stage. The
only -EPROBE_DEFER return we currently have is the vga switcheroo stuff
you see in the patch context, and most platforms never return that.
Ville, I'd like to get your thoughts on that.
Anyway, even if we decide not to, err, defer returning -EPROBE_DEFER, I
think we should abstract this better. For example, add a
intel_modeset_probe_defer() function in intel_display.c that checks
this, and call that as the first thing in i915_driver_probe(). Just to
keep the display specific code out of the high level functions, even if
that is functionally the same as what you're doing here.
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [Intel-gfx] [PATCH 9/9] drm/i915: Add privacy-screen support
@ 2021-09-16 9:40 ` Jani Nikula
0 siblings, 0 replies; 84+ messages in thread
From: Jani Nikula @ 2021-09-16 9:40 UTC (permalink / raw)
To: Hans de Goede, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rajat Jain, Lyude, Joonas Lahtinen,
Rodrigo Vivi, Mark Gross, Andy Shevchenko,
Ville Syrjälä
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
Cc: Ville for input here, see question inline.
On Mon, 06 Sep 2021, Hans de Goede <hdegoede@redhat.com> wrote:
> 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.
>
> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
> 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 5560d2f4c352..7285873d329a 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -10140,6 +10140,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;
> @@ -10237,6 +10239,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 7f8e8865048f..3aa2072cccf6 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -37,6 +37,7 @@
> #include <drm/drm_crtc.h>
> #include <drm/drm_dp_helper.h>
> #include <drm/drm_edid.h>
> +#include <drm/drm_privacy_screen_consumer.h>
> #include <drm/drm_probe_helper.h>
>
> #include "g4x_dp.h"
> @@ -5217,6 +5218,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;
> struct edid *edid;
> @@ -5308,6 +5310,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->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 146f7e39182a..d6913f567a1c 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -25,6 +25,7 @@
> #include <linux/vga_switcheroo.h>
>
> #include <drm/drm_drv.h>
> +#include <drm/drm_privacy_screen_consumer.h>
> #include <drm/i915_pciids.h>
>
> #include "i915_drv.h"
> @@ -1167,6 +1168,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 &&
> @@ -1195,7 +1197,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;
Ideally, neither i915_pci_probe() nor i915_driver_probe() should assume
we have display. We might not. We should not wait if we are never going
to initialize display.
Alas, we'll only know after i915_driver_probe() ->
i915_driver_mmio_probe() -> intel_device_info_runtime_init(), which
modifies ->pipe_mask, which is the single point of truth. See
HAS_DISPLAY().
We do have tests for failing probe at various points (see the
i915_inject_probe_failure() calls) to stress the cleanup paths in
CI. Part of the point was to prepare us for -EPROBE_DEFER returns.
Looks like the earliest/cleanest point for checking this is in
intel_modeset_init_noirq(), i.e. first display init call. But I admit it
gives me an uneasy feeling to return -EPROBE_DEFER at that stage. The
only -EPROBE_DEFER return we currently have is the vga switcheroo stuff
you see in the patch context, and most platforms never return that.
Ville, I'd like to get your thoughts on that.
Anyway, even if we decide not to, err, defer returning -EPROBE_DEFER, I
think we should abstract this better. For example, add a
intel_modeset_probe_defer() function in intel_display.c that checks
this, and call that as the first thing in i915_driver_probe(). Just to
keep the display specific code out of the high level functions, even if
that is functionally the same as what you're doing here.
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [PATCH 0/9] drm: Add privacy-screen class and connector properties
2021-09-16 9:30 ` [Intel-gfx] " Hans de Goede
@ 2021-09-16 10:14 ` Jani Nikula
-1 siblings, 0 replies; 84+ 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] 84+ messages in thread
* Re: [Intel-gfx] [PATCH 0/9] drm: Add privacy-screen class and connector properties
@ 2021-09-16 10:14 ` Jani Nikula
0 siblings, 0 replies; 84+ 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] 84+ messages in thread
* Re: [PATCH 9/9] drm/i915: Add privacy-screen support
2021-09-16 9:40 ` [Intel-gfx] " Jani Nikula
@ 2021-09-16 10:32 ` Hans de Goede
-1 siblings, 0 replies; 84+ messages in thread
From: Hans de Goede @ 2021-09-16 10:32 UTC (permalink / raw)
To: Jani Nikula, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Rajat Jain, Lyude, Joonas Lahtinen, Rodrigo Vivi, Mark Gross,
Andy Shevchenko, Ville Syrjälä
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/16/21 11:40 AM, Jani Nikula wrote:
>
> Cc: Ville for input here, see question inline.
>
> On Mon, 06 Sep 2021, Hans de Goede <hdegoede@redhat.com> wrote:
>> 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.
>>
>> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
>> 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 5560d2f4c352..7285873d329a 100644
>> --- a/drivers/gpu/drm/i915/display/intel_display.c
>> +++ b/drivers/gpu/drm/i915/display/intel_display.c
>> @@ -10140,6 +10140,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;
>> @@ -10237,6 +10239,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 7f8e8865048f..3aa2072cccf6 100644
>> --- a/drivers/gpu/drm/i915/display/intel_dp.c
>> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
>> @@ -37,6 +37,7 @@
>> #include <drm/drm_crtc.h>
>> #include <drm/drm_dp_helper.h>
>> #include <drm/drm_edid.h>
>> +#include <drm/drm_privacy_screen_consumer.h>
>> #include <drm/drm_probe_helper.h>
>>
>> #include "g4x_dp.h"
>> @@ -5217,6 +5218,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;
>> struct edid *edid;
>> @@ -5308,6 +5310,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->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 146f7e39182a..d6913f567a1c 100644
>> --- a/drivers/gpu/drm/i915/i915_pci.c
>> +++ b/drivers/gpu/drm/i915/i915_pci.c
>> @@ -25,6 +25,7 @@
>> #include <linux/vga_switcheroo.h>
>>
>> #include <drm/drm_drv.h>
>> +#include <drm/drm_privacy_screen_consumer.h>
>> #include <drm/i915_pciids.h>
>>
>> #include "i915_drv.h"
>> @@ -1167,6 +1168,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 &&
>> @@ -1195,7 +1197,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;
>
> Ideally, neither i915_pci_probe() nor i915_driver_probe() should assume
> we have display. We might not. We should not wait if we are never going
> to initialize display.
Good point.
> Alas, we'll only know after i915_driver_probe() ->
> i915_driver_mmio_probe() -> intel_device_info_runtime_init(), which
> modifies ->pipe_mask, which is the single point of truth. See
> HAS_DISPLAY().
>
> We do have tests for failing probe at various points (see the
> i915_inject_probe_failure() calls) to stress the cleanup paths in
> CI. Part of the point was to prepare us for -EPROBE_DEFER returns.
>
> Looks like the earliest/cleanest point for checking this is in
> intel_modeset_init_noirq(), i.e. first display init call. But I admit it
> gives me an uneasy feeling to return -EPROBE_DEFER at that stage.
Ack, this is why I added the get + put here. Theoretically I could also
just have put the return -EPROBE_DEFER inside intel_edp_init_connector()
(changing its return type) but I did not feel comfortable with doing
that...
I think that just leaving this functionally as is, with the refactor
which you suggest below is best for now. drm_privacy_screen_get() will
only return -EPROBE_DEFER if there is an entry in the lookup-table
which the drm_privacy class code keeps this lookup table matches
on the dev_name() of the GPU's PCI-device. So assuming the lookup
table contains the correct dev_name() then there should be no match
for any GPU-s without a display.
Note ATM this is not true since the lookup added for the thinkpad_acpi
providing privacy-screen support case specifies NULL as dev_name,
which gets interpreted as a wildcard, but I can easily replace that
with "0000:00:02.0" before pushing this out. Which at least avoids
delaying probing of any discrete Intel GPUs which I guess may not
have displays.
That does still leave the case of a hybrid GPU laptop where all
displays are connected to the discrete-GPU and the iGPU is only
left enabled for quick-sync functionality. But I'm not sure if
that case is even detected by HAS_DISPLAY(), since the hw then
still has display-pipes.
Worst case scenario here is that we delay i915 binding to the device
until thinkpad_acpi loads, which I think is not too bad.
Note a downside of replace the NULL devname in the lookup with
"0000:00:02.0" is that that will not work for hybrid-gfx laptops
with the panel connected to the discrete-GPU atm this is not supported
anyways since amdgpu and nouveau lack a patch similar to this one.
But the plan was for this to work automatically as soon as nouveau /
amdgpu get support assuming that e.g. only either i915 or nouveau would
see the LCD panel and thus would trigger the code in e.g.
intel_edp_init_connector().
But if you feel more comfortable about this if I change the dev_name
in the lookup to "0000:00:02.0" I can do that and we can cross the
hybrid-gfx case when we hit that. The whole need to tie a random
vendor ACPI interface for privacy-screen control together with the
drm-subsys is a bit messy anyways, so some of this we (I?) will need
to figure out as we go.
> The
> only -EPROBE_DEFER return we currently have is the vga switcheroo stuff
> you see in the patch context, and most platforms never return that.
>
> Ville, I'd like to get your thoughts on that.
>
> Anyway, even if we decide not to, err, defer returning -EPROBE_DEFER, I
> think we should abstract this better. For example, add a
> intel_modeset_probe_defer() function in intel_display.c that checks
> this, and call that as the first thing in i915_driver_probe(). Just to
> keep the display specific code out of the high level functions, even if
> that is functionally the same as what you're doing here.
I'm fine with refactoring this a bit and adding
an intel_modeset_probe_defer() helper for this, I assume I should also
move the vga_switcheroo_client_probe_defer(pdev) check there?
As you suggested yourself in your reply to the coverletter I will
push out the rest of the series to drm-misc-next while we figure this
out. Assuming Lyude is happy with the answers which I gave to her
remarks about some of the other patches.
Regards,
Hans
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [Intel-gfx] [PATCH 9/9] drm/i915: Add privacy-screen support
@ 2021-09-16 10:32 ` Hans de Goede
0 siblings, 0 replies; 84+ messages in thread
From: Hans de Goede @ 2021-09-16 10:32 UTC (permalink / raw)
To: Jani Nikula, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Rajat Jain, Lyude, Joonas Lahtinen, Rodrigo Vivi, Mark Gross,
Andy Shevchenko, Ville Syrjälä
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/16/21 11:40 AM, Jani Nikula wrote:
>
> Cc: Ville for input here, see question inline.
>
> On Mon, 06 Sep 2021, Hans de Goede <hdegoede@redhat.com> wrote:
>> 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.
>>
>> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
>> 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 5560d2f4c352..7285873d329a 100644
>> --- a/drivers/gpu/drm/i915/display/intel_display.c
>> +++ b/drivers/gpu/drm/i915/display/intel_display.c
>> @@ -10140,6 +10140,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;
>> @@ -10237,6 +10239,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 7f8e8865048f..3aa2072cccf6 100644
>> --- a/drivers/gpu/drm/i915/display/intel_dp.c
>> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
>> @@ -37,6 +37,7 @@
>> #include <drm/drm_crtc.h>
>> #include <drm/drm_dp_helper.h>
>> #include <drm/drm_edid.h>
>> +#include <drm/drm_privacy_screen_consumer.h>
>> #include <drm/drm_probe_helper.h>
>>
>> #include "g4x_dp.h"
>> @@ -5217,6 +5218,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;
>> struct edid *edid;
>> @@ -5308,6 +5310,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->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 146f7e39182a..d6913f567a1c 100644
>> --- a/drivers/gpu/drm/i915/i915_pci.c
>> +++ b/drivers/gpu/drm/i915/i915_pci.c
>> @@ -25,6 +25,7 @@
>> #include <linux/vga_switcheroo.h>
>>
>> #include <drm/drm_drv.h>
>> +#include <drm/drm_privacy_screen_consumer.h>
>> #include <drm/i915_pciids.h>
>>
>> #include "i915_drv.h"
>> @@ -1167,6 +1168,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 &&
>> @@ -1195,7 +1197,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;
>
> Ideally, neither i915_pci_probe() nor i915_driver_probe() should assume
> we have display. We might not. We should not wait if we are never going
> to initialize display.
Good point.
> Alas, we'll only know after i915_driver_probe() ->
> i915_driver_mmio_probe() -> intel_device_info_runtime_init(), which
> modifies ->pipe_mask, which is the single point of truth. See
> HAS_DISPLAY().
>
> We do have tests for failing probe at various points (see the
> i915_inject_probe_failure() calls) to stress the cleanup paths in
> CI. Part of the point was to prepare us for -EPROBE_DEFER returns.
>
> Looks like the earliest/cleanest point for checking this is in
> intel_modeset_init_noirq(), i.e. first display init call. But I admit it
> gives me an uneasy feeling to return -EPROBE_DEFER at that stage.
Ack, this is why I added the get + put here. Theoretically I could also
just have put the return -EPROBE_DEFER inside intel_edp_init_connector()
(changing its return type) but I did not feel comfortable with doing
that...
I think that just leaving this functionally as is, with the refactor
which you suggest below is best for now. drm_privacy_screen_get() will
only return -EPROBE_DEFER if there is an entry in the lookup-table
which the drm_privacy class code keeps this lookup table matches
on the dev_name() of the GPU's PCI-device. So assuming the lookup
table contains the correct dev_name() then there should be no match
for any GPU-s without a display.
Note ATM this is not true since the lookup added for the thinkpad_acpi
providing privacy-screen support case specifies NULL as dev_name,
which gets interpreted as a wildcard, but I can easily replace that
with "0000:00:02.0" before pushing this out. Which at least avoids
delaying probing of any discrete Intel GPUs which I guess may not
have displays.
That does still leave the case of a hybrid GPU laptop where all
displays are connected to the discrete-GPU and the iGPU is only
left enabled for quick-sync functionality. But I'm not sure if
that case is even detected by HAS_DISPLAY(), since the hw then
still has display-pipes.
Worst case scenario here is that we delay i915 binding to the device
until thinkpad_acpi loads, which I think is not too bad.
Note a downside of replace the NULL devname in the lookup with
"0000:00:02.0" is that that will not work for hybrid-gfx laptops
with the panel connected to the discrete-GPU atm this is not supported
anyways since amdgpu and nouveau lack a patch similar to this one.
But the plan was for this to work automatically as soon as nouveau /
amdgpu get support assuming that e.g. only either i915 or nouveau would
see the LCD panel and thus would trigger the code in e.g.
intel_edp_init_connector().
But if you feel more comfortable about this if I change the dev_name
in the lookup to "0000:00:02.0" I can do that and we can cross the
hybrid-gfx case when we hit that. The whole need to tie a random
vendor ACPI interface for privacy-screen control together with the
drm-subsys is a bit messy anyways, so some of this we (I?) will need
to figure out as we go.
> The
> only -EPROBE_DEFER return we currently have is the vga switcheroo stuff
> you see in the patch context, and most platforms never return that.
>
> Ville, I'd like to get your thoughts on that.
>
> Anyway, even if we decide not to, err, defer returning -EPROBE_DEFER, I
> think we should abstract this better. For example, add a
> intel_modeset_probe_defer() function in intel_display.c that checks
> this, and call that as the first thing in i915_driver_probe(). Just to
> keep the display specific code out of the high level functions, even if
> that is functionally the same as what you're doing here.
I'm fine with refactoring this a bit and adding
an intel_modeset_probe_defer() helper for this, I assume I should also
move the vga_switcheroo_client_probe_defer(pdev) check there?
As you suggested yourself in your reply to the coverletter I will
push out the rest of the series to drm-misc-next while we figure this
out. Assuming Lyude is happy with the answers which I gave to her
remarks about some of the other patches.
Regards,
Hans
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [PATCH 9/9] drm/i915: Add privacy-screen support
2021-09-06 7:35 ` [Intel-gfx] " Hans de Goede
@ 2021-09-16 13:45 ` Ville Syrjälä
-1 siblings, 0 replies; 84+ messages in thread
From: Ville Syrjälä @ 2021-09-16 13:45 UTC (permalink / raw)
To: Hans de Goede
Cc: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rajat Jain,
Jani Nikula, Lyude, Joonas Lahtinen, Rodrigo Vivi, Mark Gross,
Andy Shevchenko, Daniel Vetter, David Airlie, Pekka Paalanen,
Mario Limonciello, Mark Pearson, Sebastien Bacher,
Marco Trevisan, Emil Velikov, intel-gfx, dri-devel,
platform-driver-x86
On Mon, Sep 06, 2021 at 09:35:19AM +0200, Hans de Goede wrote:
> 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.
Pretty sure the full atomic state is plumbed all the way
down these days.
>
> 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.
I doubt anyone is going to care about a bit of overhead for a modeset.
The usual rule is that a modeset doesn't skip anything. That way we
can be 100% sure we remeber to update everythinbg. For fastsets I guess
one could argue skipping it if not needed, but not sure even that is
warranted.
The current code you have in there is cettainly 110% dodgy. Since the
sw_state is stored in the connector state I presume it's at least
trying to be an atomic property, which means you shouldn't go poking
at it after the swap_state ever. swap_state just swaps the pointers
which is all that you need. So at least that part should get nuked.
The immutable hw_state I guess should get updated when we program the
actual hw.
--
Ville Syrjälä
Intel
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [Intel-gfx] [PATCH 9/9] drm/i915: Add privacy-screen support
@ 2021-09-16 13:45 ` Ville Syrjälä
0 siblings, 0 replies; 84+ messages in thread
From: Ville Syrjälä @ 2021-09-16 13:45 UTC (permalink / raw)
To: Hans de Goede
Cc: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rajat Jain,
Jani Nikula, Lyude, Joonas Lahtinen, Rodrigo Vivi, Mark Gross,
Andy Shevchenko, Daniel Vetter, David Airlie, Pekka Paalanen,
Mario Limonciello, Mark Pearson, Sebastien Bacher,
Marco Trevisan, Emil Velikov, intel-gfx, dri-devel,
platform-driver-x86
On Mon, Sep 06, 2021 at 09:35:19AM +0200, Hans de Goede wrote:
> 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.
Pretty sure the full atomic state is plumbed all the way
down these days.
>
> 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.
I doubt anyone is going to care about a bit of overhead for a modeset.
The usual rule is that a modeset doesn't skip anything. That way we
can be 100% sure we remeber to update everythinbg. For fastsets I guess
one could argue skipping it if not needed, but not sure even that is
warranted.
The current code you have in there is cettainly 110% dodgy. Since the
sw_state is stored in the connector state I presume it's at least
trying to be an atomic property, which means you shouldn't go poking
at it after the swap_state ever. swap_state just swaps the pointers
which is all that you need. So at least that part should get nuked.
The immutable hw_state I guess should get updated when we program the
actual hw.
--
Ville Syrjälä
Intel
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [PATCH 9/9] drm/i915: Add privacy-screen support
2021-09-16 9:40 ` [Intel-gfx] " Jani Nikula
@ 2021-09-16 14:04 ` Ville Syrjälä
-1 siblings, 0 replies; 84+ messages in thread
From: Ville Syrjälä @ 2021-09-16 14:04 UTC (permalink / raw)
To: Jani Nikula
Cc: Hans de Goede, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rajat Jain, Lyude, Joonas Lahtinen,
Rodrigo Vivi, Mark Gross, Andy Shevchenko, 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, Sep 16, 2021 at 12:40:11PM +0300, Jani Nikula wrote:
>
> Cc: Ville for input here, see question inline.
>
> On Mon, 06 Sep 2021, Hans de Goede <hdegoede@redhat.com> wrote:
> > 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.
> >
> > Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
> > 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 5560d2f4c352..7285873d329a 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -10140,6 +10140,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;
> > @@ -10237,6 +10239,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 7f8e8865048f..3aa2072cccf6 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > @@ -37,6 +37,7 @@
> > #include <drm/drm_crtc.h>
> > #include <drm/drm_dp_helper.h>
> > #include <drm/drm_edid.h>
> > +#include <drm/drm_privacy_screen_consumer.h>
> > #include <drm/drm_probe_helper.h>
> >
> > #include "g4x_dp.h"
> > @@ -5217,6 +5218,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;
> > struct edid *edid;
> > @@ -5308,6 +5310,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->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 146f7e39182a..d6913f567a1c 100644
> > --- a/drivers/gpu/drm/i915/i915_pci.c
> > +++ b/drivers/gpu/drm/i915/i915_pci.c
> > @@ -25,6 +25,7 @@
> > #include <linux/vga_switcheroo.h>
> >
> > #include <drm/drm_drv.h>
> > +#include <drm/drm_privacy_screen_consumer.h>
> > #include <drm/i915_pciids.h>
> >
> > #include "i915_drv.h"
> > @@ -1167,6 +1168,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 &&
> > @@ -1195,7 +1197,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;
>
> Ideally, neither i915_pci_probe() nor i915_driver_probe() should assume
> we have display. We might not. We should not wait if we are never going
> to initialize display.
>
> Alas, we'll only know after i915_driver_probe() ->
> i915_driver_mmio_probe() -> intel_device_info_runtime_init(), which
> modifies ->pipe_mask, which is the single point of truth. See
> HAS_DISPLAY().
>
> We do have tests for failing probe at various points (see the
> i915_inject_probe_failure() calls) to stress the cleanup paths in
> CI. Part of the point was to prepare us for -EPROBE_DEFER returns.
>
> Looks like the earliest/cleanest point for checking this is in
> intel_modeset_init_noirq(), i.e. first display init call. But I admit it
> gives me an uneasy feeling to return -EPROBE_DEFER at that stage. The
> only -EPROBE_DEFER return we currently have is the vga switcheroo stuff
> you see in the patch context, and most platforms never return that.
>
> Ville, I'd like to get your thoughts on that.
I'm just scaread about everything to do with deferred probing.
For example, I don't even know what would happen if you have some kind
of mismatch betwen i915 and thinkpad_acpi y/m/n? Or you have one but not
the other in the initrd? Is the machine at least guaranteed to boot
properly and light up the display at some point?
But yeah, failing the probe at some stage when we've already clobbered
a bunch of things sounds like an "interesting" idea. I don't think we've
given the error paths any real though beyond the "ci+error injection
seems to not explode too badly" approach.
> Anyway, even if we decide not to, err, defer returning -EPROBE_DEFER, I
> think we should abstract this better. For example, add a
> intel_modeset_probe_defer() function in intel_display.c that checks
> this, and call that as the first thing in i915_driver_probe(). Just to
> keep the display specific code out of the high level functions, even if
> that is functionally the same as what you're doing here.
Yeah, I guess something like that could be the safest option
for the moment.
--
Ville Syrjälä
Intel
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [Intel-gfx] [PATCH 9/9] drm/i915: Add privacy-screen support
@ 2021-09-16 14:04 ` Ville Syrjälä
0 siblings, 0 replies; 84+ messages in thread
From: Ville Syrjälä @ 2021-09-16 14:04 UTC (permalink / raw)
To: Jani Nikula
Cc: Hans de Goede, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rajat Jain, Lyude, Joonas Lahtinen,
Rodrigo Vivi, Mark Gross, Andy Shevchenko, 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, Sep 16, 2021 at 12:40:11PM +0300, Jani Nikula wrote:
>
> Cc: Ville for input here, see question inline.
>
> On Mon, 06 Sep 2021, Hans de Goede <hdegoede@redhat.com> wrote:
> > 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.
> >
> > Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
> > 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 5560d2f4c352..7285873d329a 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -10140,6 +10140,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;
> > @@ -10237,6 +10239,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 7f8e8865048f..3aa2072cccf6 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > @@ -37,6 +37,7 @@
> > #include <drm/drm_crtc.h>
> > #include <drm/drm_dp_helper.h>
> > #include <drm/drm_edid.h>
> > +#include <drm/drm_privacy_screen_consumer.h>
> > #include <drm/drm_probe_helper.h>
> >
> > #include "g4x_dp.h"
> > @@ -5217,6 +5218,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;
> > struct edid *edid;
> > @@ -5308,6 +5310,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->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 146f7e39182a..d6913f567a1c 100644
> > --- a/drivers/gpu/drm/i915/i915_pci.c
> > +++ b/drivers/gpu/drm/i915/i915_pci.c
> > @@ -25,6 +25,7 @@
> > #include <linux/vga_switcheroo.h>
> >
> > #include <drm/drm_drv.h>
> > +#include <drm/drm_privacy_screen_consumer.h>
> > #include <drm/i915_pciids.h>
> >
> > #include "i915_drv.h"
> > @@ -1167,6 +1168,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 &&
> > @@ -1195,7 +1197,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;
>
> Ideally, neither i915_pci_probe() nor i915_driver_probe() should assume
> we have display. We might not. We should not wait if we are never going
> to initialize display.
>
> Alas, we'll only know after i915_driver_probe() ->
> i915_driver_mmio_probe() -> intel_device_info_runtime_init(), which
> modifies ->pipe_mask, which is the single point of truth. See
> HAS_DISPLAY().
>
> We do have tests for failing probe at various points (see the
> i915_inject_probe_failure() calls) to stress the cleanup paths in
> CI. Part of the point was to prepare us for -EPROBE_DEFER returns.
>
> Looks like the earliest/cleanest point for checking this is in
> intel_modeset_init_noirq(), i.e. first display init call. But I admit it
> gives me an uneasy feeling to return -EPROBE_DEFER at that stage. The
> only -EPROBE_DEFER return we currently have is the vga switcheroo stuff
> you see in the patch context, and most platforms never return that.
>
> Ville, I'd like to get your thoughts on that.
I'm just scaread about everything to do with deferred probing.
For example, I don't even know what would happen if you have some kind
of mismatch betwen i915 and thinkpad_acpi y/m/n? Or you have one but not
the other in the initrd? Is the machine at least guaranteed to boot
properly and light up the display at some point?
But yeah, failing the probe at some stage when we've already clobbered
a bunch of things sounds like an "interesting" idea. I don't think we've
given the error paths any real though beyond the "ci+error injection
seems to not explode too badly" approach.
> Anyway, even if we decide not to, err, defer returning -EPROBE_DEFER, I
> think we should abstract this better. For example, add a
> intel_modeset_probe_defer() function in intel_display.c that checks
> this, and call that as the first thing in i915_driver_probe(). Just to
> keep the display specific code out of the high level functions, even if
> that is functionally the same as what you're doing here.
Yeah, I guess something like that could be the safest option
for the moment.
--
Ville Syrjälä
Intel
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [PATCH 4/9] drm/privacy-screen: Add notifier support
2021-09-16 9:06 ` [Intel-gfx] " Hans de Goede
(?)
@ 2021-09-16 16:50 ` Lyude Paul
-1 siblings, 0 replies; 84+ messages in thread
From: Lyude Paul @ 2021-09-16 16:50 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
On Thu, 2021-09-16 at 11:06 +0200, Hans de Goede wrote:
> Hi,
>
> On 9/15/21 10:26 PM, Lyude Paul wrote:
> > On Mon, 2021-09-06 at 09:35 +0200, Hans de Goede wrote:
> > > 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.
> > >
> > > Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
> > > Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> > > ---
> > > drivers/gpu/drm/drm_privacy_screen.c | 67 +++++++++++++++++++++++
> > > include/drm/drm_privacy_screen_consumer.h | 15 +++++
> > > include/drm/drm_privacy_screen_driver.h | 4 ++
> > > 3 files changed, 86 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/drm_privacy_screen.c
> > > b/drivers/gpu/drm/drm_privacy_screen.c
> > > index 294a09194bfb..7a5f878c3171 100644
> > > --- a/drivers/gpu/drm/drm_privacy_screen.c
> > > +++ b/drivers/gpu/drm/drm_privacy_screen.c
> > > @@ -255,6 +255,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_class;
> > > priv->dev.type = &drm_privacy_screen_type;
> > > @@ -399,3 +443,26 @@ void drm_privacy_screen_unregister(struct
> > > drm_privacy_screen *priv)
> > > device_unregister(&priv->dev);
> > > }
> > > 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;
> >
> > Are we sure about this check? mutex_is_locked() checks whether a mutex is
> > locked by anyone, not just us. So this seems like it would cause us to
> > WARN_ON() and abort if anyone else (not just ourselves) is holding the
> > lock to
> > read the privacy screen state.
>
> Thank you for catching this, yes this check indeed is wrong. AFAIK
> there is no way to check that the mutex has been locked by us, so this
> extra sanity check simply needs to be removed.
>
> I'll drop the check before pushing this to drm-misc-next (more on
> that in a reply to the cover letter), if that is ok with you.
Sounds fine to me!
>
> Or do you want me to do a new version addressing this?
>
> Regards,
>
> Hans
>
>
>
> >
> > > +
> > > + blocking_notifier_call_chain(&priv->notifier_head, 0, priv);
> > > +}
> > > +EXPORT_SYMBOL(drm_privacy_screen_call_notifier_chain);
> > > diff --git a/include/drm/drm_privacy_screen_consumer.h
> > > b/include/drm/drm_privacy_screen_consumer.h
> > > index 0cbd23b0453d..7f66a90d15b7 100644
> > > --- a/include/drm/drm_privacy_screen_consumer.h
> > > +++ b/include/drm/drm_privacy_screen_consumer.h
> > > @@ -24,6 +24,11 @@ int drm_privacy_screen_set_sw_state(struct
> > > drm_privacy_screen *priv,
> > > 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);
> > > #else
> > > static inline struct drm_privacy_screen *drm_privacy_screen_get(struct
> > > device *dev,
> > > const
> > > char
> > > *con_id)
> > > @@ -45,6 +50,16 @@ static inline void
> > > drm_privacy_screen_get_state(struct
> > > drm_privacy_screen *priv,
> > > *sw_state_ret = PRIVACY_SCREEN_DISABLED;
> > > *hw_state_ret = PRIVACY_SCREEN_DISABLED;
> > > }
> > > +static inline int drm_privacy_screen_register_notifier(struct
> > > drm_privacy_screen *priv,
> > > + struct
> > > notifier_block
> > > *nb)
> > > +{
> > > + return -ENODEV;
> > > +}
> > > +static inline int drm_privacy_screen_unregister_notifier(struct
> > > drm_privacy_screen *priv,
> > > + struct
> > > notifier_block *nb)
> > > +{
> > > + return -ENODEV;
> > > +}
> > > #endif
> > >
> > > #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
> >
>
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [Intel-gfx] [PATCH 4/9] drm/privacy-screen: Add notifier support
@ 2021-09-16 16:50 ` Lyude Paul
0 siblings, 0 replies; 84+ messages in thread
From: Lyude Paul @ 2021-09-16 16:50 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
On Thu, 2021-09-16 at 11:06 +0200, Hans de Goede wrote:
> Hi,
>
> On 9/15/21 10:26 PM, Lyude Paul wrote:
> > On Mon, 2021-09-06 at 09:35 +0200, Hans de Goede wrote:
> > > 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.
> > >
> > > Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
> > > Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> > > ---
> > > drivers/gpu/drm/drm_privacy_screen.c | 67 +++++++++++++++++++++++
> > > include/drm/drm_privacy_screen_consumer.h | 15 +++++
> > > include/drm/drm_privacy_screen_driver.h | 4 ++
> > > 3 files changed, 86 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/drm_privacy_screen.c
> > > b/drivers/gpu/drm/drm_privacy_screen.c
> > > index 294a09194bfb..7a5f878c3171 100644
> > > --- a/drivers/gpu/drm/drm_privacy_screen.c
> > > +++ b/drivers/gpu/drm/drm_privacy_screen.c
> > > @@ -255,6 +255,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_class;
> > > priv->dev.type = &drm_privacy_screen_type;
> > > @@ -399,3 +443,26 @@ void drm_privacy_screen_unregister(struct
> > > drm_privacy_screen *priv)
> > > device_unregister(&priv->dev);
> > > }
> > > 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;
> >
> > Are we sure about this check? mutex_is_locked() checks whether a mutex is
> > locked by anyone, not just us. So this seems like it would cause us to
> > WARN_ON() and abort if anyone else (not just ourselves) is holding the
> > lock to
> > read the privacy screen state.
>
> Thank you for catching this, yes this check indeed is wrong. AFAIK
> there is no way to check that the mutex has been locked by us, so this
> extra sanity check simply needs to be removed.
>
> I'll drop the check before pushing this to drm-misc-next (more on
> that in a reply to the cover letter), if that is ok with you.
Sounds fine to me!
>
> Or do you want me to do a new version addressing this?
>
> Regards,
>
> Hans
>
>
>
> >
> > > +
> > > + blocking_notifier_call_chain(&priv->notifier_head, 0, priv);
> > > +}
> > > +EXPORT_SYMBOL(drm_privacy_screen_call_notifier_chain);
> > > diff --git a/include/drm/drm_privacy_screen_consumer.h
> > > b/include/drm/drm_privacy_screen_consumer.h
> > > index 0cbd23b0453d..7f66a90d15b7 100644
> > > --- a/include/drm/drm_privacy_screen_consumer.h
> > > +++ b/include/drm/drm_privacy_screen_consumer.h
> > > @@ -24,6 +24,11 @@ int drm_privacy_screen_set_sw_state(struct
> > > drm_privacy_screen *priv,
> > > 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);
> > > #else
> > > static inline struct drm_privacy_screen *drm_privacy_screen_get(struct
> > > device *dev,
> > > const
> > > char
> > > *con_id)
> > > @@ -45,6 +50,16 @@ static inline void
> > > drm_privacy_screen_get_state(struct
> > > drm_privacy_screen *priv,
> > > *sw_state_ret = PRIVACY_SCREEN_DISABLED;
> > > *hw_state_ret = PRIVACY_SCREEN_DISABLED;
> > > }
> > > +static inline int drm_privacy_screen_register_notifier(struct
> > > drm_privacy_screen *priv,
> > > + struct
> > > notifier_block
> > > *nb)
> > > +{
> > > + return -ENODEV;
> > > +}
> > > +static inline int drm_privacy_screen_unregister_notifier(struct
> > > drm_privacy_screen *priv,
> > > + struct
> > > notifier_block *nb)
> > > +{
> > > + return -ENODEV;
> > > +}
> > > #endif
> > >
> > > #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
> >
>
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [PATCH 4/9] drm/privacy-screen: Add notifier support
@ 2021-09-16 16:50 ` Lyude Paul
0 siblings, 0 replies; 84+ messages in thread
From: Lyude Paul @ 2021-09-16 16:50 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
On Thu, 2021-09-16 at 11:06 +0200, Hans de Goede wrote:
> Hi,
>
> On 9/15/21 10:26 PM, Lyude Paul wrote:
> > On Mon, 2021-09-06 at 09:35 +0200, Hans de Goede wrote:
> > > 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.
> > >
> > > Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
> > > Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> > > ---
> > > drivers/gpu/drm/drm_privacy_screen.c | 67 +++++++++++++++++++++++
> > > include/drm/drm_privacy_screen_consumer.h | 15 +++++
> > > include/drm/drm_privacy_screen_driver.h | 4 ++
> > > 3 files changed, 86 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/drm_privacy_screen.c
> > > b/drivers/gpu/drm/drm_privacy_screen.c
> > > index 294a09194bfb..7a5f878c3171 100644
> > > --- a/drivers/gpu/drm/drm_privacy_screen.c
> > > +++ b/drivers/gpu/drm/drm_privacy_screen.c
> > > @@ -255,6 +255,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_class;
> > > priv->dev.type = &drm_privacy_screen_type;
> > > @@ -399,3 +443,26 @@ void drm_privacy_screen_unregister(struct
> > > drm_privacy_screen *priv)
> > > device_unregister(&priv->dev);
> > > }
> > > 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;
> >
> > Are we sure about this check? mutex_is_locked() checks whether a mutex is
> > locked by anyone, not just us. So this seems like it would cause us to
> > WARN_ON() and abort if anyone else (not just ourselves) is holding the
> > lock to
> > read the privacy screen state.
>
> Thank you for catching this, yes this check indeed is wrong. AFAIK
> there is no way to check that the mutex has been locked by us, so this
> extra sanity check simply needs to be removed.
>
> I'll drop the check before pushing this to drm-misc-next (more on
> that in a reply to the cover letter), if that is ok with you.
Sounds fine to me!
>
> Or do you want me to do a new version addressing this?
>
> Regards,
>
> Hans
>
>
>
> >
> > > +
> > > + blocking_notifier_call_chain(&priv->notifier_head, 0, priv);
> > > +}
> > > +EXPORT_SYMBOL(drm_privacy_screen_call_notifier_chain);
> > > diff --git a/include/drm/drm_privacy_screen_consumer.h
> > > b/include/drm/drm_privacy_screen_consumer.h
> > > index 0cbd23b0453d..7f66a90d15b7 100644
> > > --- a/include/drm/drm_privacy_screen_consumer.h
> > > +++ b/include/drm/drm_privacy_screen_consumer.h
> > > @@ -24,6 +24,11 @@ int drm_privacy_screen_set_sw_state(struct
> > > drm_privacy_screen *priv,
> > > 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);
> > > #else
> > > static inline struct drm_privacy_screen *drm_privacy_screen_get(struct
> > > device *dev,
> > > const
> > > char
> > > *con_id)
> > > @@ -45,6 +50,16 @@ static inline void
> > > drm_privacy_screen_get_state(struct
> > > drm_privacy_screen *priv,
> > > *sw_state_ret = PRIVACY_SCREEN_DISABLED;
> > > *hw_state_ret = PRIVACY_SCREEN_DISABLED;
> > > }
> > > +static inline int drm_privacy_screen_register_notifier(struct
> > > drm_privacy_screen *priv,
> > > + struct
> > > notifier_block
> > > *nb)
> > > +{
> > > + return -ENODEV;
> > > +}
> > > +static inline int drm_privacy_screen_unregister_notifier(struct
> > > drm_privacy_screen *priv,
> > > + struct
> > > notifier_block *nb)
> > > +{
> > > + return -ENODEV;
> > > +}
> > > #endif
> > >
> > > #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
> >
>
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [PATCH 9/9] drm/i915: Add privacy-screen support
2021-09-16 14:04 ` [Intel-gfx] " Ville Syrjälä
@ 2021-09-17 14:23 ` Hans de Goede
-1 siblings, 0 replies; 84+ messages in thread
From: Hans de Goede @ 2021-09-17 14:23 UTC (permalink / raw)
To: Ville Syrjälä, Jani Nikula
Cc: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rajat Jain,
Lyude, Joonas Lahtinen, Rodrigo Vivi, Mark Gross,
Andy Shevchenko, 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/16/21 4:04 PM, Ville Syrjälä wrote:
> On Thu, Sep 16, 2021 at 12:40:11PM +0300, Jani Nikula wrote:
>>
>> Cc: Ville for input here, see question inline.
>>
>> On Mon, 06 Sep 2021, Hans de Goede <hdegoede@redhat.com> wrote:
>>> 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.
>>>
>>> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
>>> 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 5560d2f4c352..7285873d329a 100644
>>> --- a/drivers/gpu/drm/i915/display/intel_display.c
>>> +++ b/drivers/gpu/drm/i915/display/intel_display.c
>>> @@ -10140,6 +10140,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;
>>> @@ -10237,6 +10239,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 7f8e8865048f..3aa2072cccf6 100644
>>> --- a/drivers/gpu/drm/i915/display/intel_dp.c
>>> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
>>> @@ -37,6 +37,7 @@
>>> #include <drm/drm_crtc.h>
>>> #include <drm/drm_dp_helper.h>
>>> #include <drm/drm_edid.h>
>>> +#include <drm/drm_privacy_screen_consumer.h>
>>> #include <drm/drm_probe_helper.h>
>>>
>>> #include "g4x_dp.h"
>>> @@ -5217,6 +5218,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;
>>> struct edid *edid;
>>> @@ -5308,6 +5310,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->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 146f7e39182a..d6913f567a1c 100644
>>> --- a/drivers/gpu/drm/i915/i915_pci.c
>>> +++ b/drivers/gpu/drm/i915/i915_pci.c
>>> @@ -25,6 +25,7 @@
>>> #include <linux/vga_switcheroo.h>
>>>
>>> #include <drm/drm_drv.h>
>>> +#include <drm/drm_privacy_screen_consumer.h>
>>> #include <drm/i915_pciids.h>
>>>
>>> #include "i915_drv.h"
>>> @@ -1167,6 +1168,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 &&
>>> @@ -1195,7 +1197,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;
>>
>> Ideally, neither i915_pci_probe() nor i915_driver_probe() should assume
>> we have display. We might not. We should not wait if we are never going
>> to initialize display.
>>
>> Alas, we'll only know after i915_driver_probe() ->
>> i915_driver_mmio_probe() -> intel_device_info_runtime_init(), which
>> modifies ->pipe_mask, which is the single point of truth. See
>> HAS_DISPLAY().
>>
>> We do have tests for failing probe at various points (see the
>> i915_inject_probe_failure() calls) to stress the cleanup paths in
>> CI. Part of the point was to prepare us for -EPROBE_DEFER returns.
>>
>> Looks like the earliest/cleanest point for checking this is in
>> intel_modeset_init_noirq(), i.e. first display init call. But I admit it
>> gives me an uneasy feeling to return -EPROBE_DEFER at that stage. The
>> only -EPROBE_DEFER return we currently have is the vga switcheroo stuff
>> you see in the patch context, and most platforms never return that.
>>
>> Ville, I'd like to get your thoughts on that.
>
> I'm just scaread about everything to do with deferred probing.
>
> For example, I don't even know what would happen if you have some kind
> of mismatch betwen i915 and thinkpad_acpi y/m/n? Or you have one but not
> the other in the initrd? Is the machine at least guaranteed to boot
> properly and light up the display at some point?
If i915 us builtin and thinkpad_acpi is m and the machine is a ThinkPad
with a privacy-screen then the i915 driver's probe won't get past
the added check until the thinkpad_acpi driver has loaded.
Same for i915 being in the initrd and thinkpad_acpi not, then
the i915 driver's probe won't get past
the added check until we've pivoted to the real root and the
thinkpad_acpi module is loaded from the real-root.
Note that the boot will otherwise continue normally and we will
still have console output (and even e.g. a plymouth splash after
a timeout) on the efifb.
>
> But yeah, failing the probe at some stage when we've already clobbered
> a bunch of things sounds like an "interesting" idea. I don't think we've
> given the error paths any real though beyond the "ci+error injection
> seems to not explode too badly" approach.
>
>> Anyway, even if we decide not to, err, defer returning -EPROBE_DEFER, I
>> think we should abstract this better. For example, add a
>> intel_modeset_probe_defer() function in intel_display.c that checks
>> this, and call that as the first thing in i915_driver_probe(). Just to
>> keep the display specific code out of the high level functions, even if
>> that is functionally the same as what you're doing here.
>
> Yeah, I guess something like that could be the safest option
> for the moment.
Ack I will go with that then.
Regards,
Hans
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [Intel-gfx] [PATCH 9/9] drm/i915: Add privacy-screen support
@ 2021-09-17 14:23 ` Hans de Goede
0 siblings, 0 replies; 84+ messages in thread
From: Hans de Goede @ 2021-09-17 14:23 UTC (permalink / raw)
To: Ville Syrjälä, Jani Nikula
Cc: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rajat Jain,
Lyude, Joonas Lahtinen, Rodrigo Vivi, Mark Gross,
Andy Shevchenko, 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/16/21 4:04 PM, Ville Syrjälä wrote:
> On Thu, Sep 16, 2021 at 12:40:11PM +0300, Jani Nikula wrote:
>>
>> Cc: Ville for input here, see question inline.
>>
>> On Mon, 06 Sep 2021, Hans de Goede <hdegoede@redhat.com> wrote:
>>> 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.
>>>
>>> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
>>> 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 5560d2f4c352..7285873d329a 100644
>>> --- a/drivers/gpu/drm/i915/display/intel_display.c
>>> +++ b/drivers/gpu/drm/i915/display/intel_display.c
>>> @@ -10140,6 +10140,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;
>>> @@ -10237,6 +10239,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 7f8e8865048f..3aa2072cccf6 100644
>>> --- a/drivers/gpu/drm/i915/display/intel_dp.c
>>> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
>>> @@ -37,6 +37,7 @@
>>> #include <drm/drm_crtc.h>
>>> #include <drm/drm_dp_helper.h>
>>> #include <drm/drm_edid.h>
>>> +#include <drm/drm_privacy_screen_consumer.h>
>>> #include <drm/drm_probe_helper.h>
>>>
>>> #include "g4x_dp.h"
>>> @@ -5217,6 +5218,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;
>>> struct edid *edid;
>>> @@ -5308,6 +5310,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->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 146f7e39182a..d6913f567a1c 100644
>>> --- a/drivers/gpu/drm/i915/i915_pci.c
>>> +++ b/drivers/gpu/drm/i915/i915_pci.c
>>> @@ -25,6 +25,7 @@
>>> #include <linux/vga_switcheroo.h>
>>>
>>> #include <drm/drm_drv.h>
>>> +#include <drm/drm_privacy_screen_consumer.h>
>>> #include <drm/i915_pciids.h>
>>>
>>> #include "i915_drv.h"
>>> @@ -1167,6 +1168,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 &&
>>> @@ -1195,7 +1197,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;
>>
>> Ideally, neither i915_pci_probe() nor i915_driver_probe() should assume
>> we have display. We might not. We should not wait if we are never going
>> to initialize display.
>>
>> Alas, we'll only know after i915_driver_probe() ->
>> i915_driver_mmio_probe() -> intel_device_info_runtime_init(), which
>> modifies ->pipe_mask, which is the single point of truth. See
>> HAS_DISPLAY().
>>
>> We do have tests for failing probe at various points (see the
>> i915_inject_probe_failure() calls) to stress the cleanup paths in
>> CI. Part of the point was to prepare us for -EPROBE_DEFER returns.
>>
>> Looks like the earliest/cleanest point for checking this is in
>> intel_modeset_init_noirq(), i.e. first display init call. But I admit it
>> gives me an uneasy feeling to return -EPROBE_DEFER at that stage. The
>> only -EPROBE_DEFER return we currently have is the vga switcheroo stuff
>> you see in the patch context, and most platforms never return that.
>>
>> Ville, I'd like to get your thoughts on that.
>
> I'm just scaread about everything to do with deferred probing.
>
> For example, I don't even know what would happen if you have some kind
> of mismatch betwen i915 and thinkpad_acpi y/m/n? Or you have one but not
> the other in the initrd? Is the machine at least guaranteed to boot
> properly and light up the display at some point?
If i915 us builtin and thinkpad_acpi is m and the machine is a ThinkPad
with a privacy-screen then the i915 driver's probe won't get past
the added check until the thinkpad_acpi driver has loaded.
Same for i915 being in the initrd and thinkpad_acpi not, then
the i915 driver's probe won't get past
the added check until we've pivoted to the real root and the
thinkpad_acpi module is loaded from the real-root.
Note that the boot will otherwise continue normally and we will
still have console output (and even e.g. a plymouth splash after
a timeout) on the efifb.
>
> But yeah, failing the probe at some stage when we've already clobbered
> a bunch of things sounds like an "interesting" idea. I don't think we've
> given the error paths any real though beyond the "ci+error injection
> seems to not explode too badly" approach.
>
>> Anyway, even if we decide not to, err, defer returning -EPROBE_DEFER, I
>> think we should abstract this better. For example, add a
>> intel_modeset_probe_defer() function in intel_display.c that checks
>> this, and call that as the first thing in i915_driver_probe(). Just to
>> keep the display specific code out of the high level functions, even if
>> that is functionally the same as what you're doing here.
>
> Yeah, I guess something like that could be the safest option
> for the moment.
Ack I will go with that then.
Regards,
Hans
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [PATCH 9/9] drm/i915: Add privacy-screen support
2021-09-16 13:45 ` [Intel-gfx] " Ville Syrjälä
@ 2021-09-17 14:37 ` Hans de Goede
-1 siblings, 0 replies; 84+ messages in thread
From: Hans de Goede @ 2021-09-17 14:37 UTC (permalink / raw)
To: Ville Syrjälä
Cc: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rajat Jain,
Jani Nikula, Lyude, Joonas Lahtinen, Rodrigo Vivi, Mark Gross,
Andy Shevchenko, 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/16/21 3:45 PM, Ville Syrjälä wrote:
> On Mon, Sep 06, 2021 at 09:35:19AM +0200, Hans de Goede wrote:
>> 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.
>
> Pretty sure the full atomic state is plumbed all the way
> down these days.
Including the old state? AFAICT the old-state is being thrown away
from drm_atomic_helper_swap_state(), so if we do this in a different
place then we don't have access to the old-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.
>
> I doubt anyone is going to care about a bit of overhead for a modeset.
But this is not a modeset, this is more like changing the backlight brightness,
atm the code does not set the needs_modeset when only the privacy-screen
sw-state has changed.
Also in my experience the firmware (AML) code which we end up calling
for this is not the highest quality code, often it has interesting
issues / unhandled corner cases. So in my experience with ACPI we
really should try to avoid these calls unless we absolutely must make them,
but I guess not making unnecessary calls is something which could be handled
inside the actual privacy-screen driver instead.
> The usual rule is that a modeset doesn't skip anything. That way we
> can be 100% sure we remeber to update everythinbg. For fastsets I guess
> one could argue skipping it if not needed, but not sure even that is
> warranted.
Right, but again this is not a full modeset.
>
> The current code you have in there is cettainly 110% dodgy. Since the
> sw_state is stored in the connector state I presume it's at least
> trying to be an atomic property, which means you shouldn't go poking
> at it after the swap_state ever.
It is not being poked, it is only being read, also this is happening
before swap_state.
Note I'm open for suggestions to handle this differently,
including changing the drm_connector_update_privacy_screen()
helper which currently relies on being passed the state before swap_state
is called:
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;
}
So if you have any suggestions how to do this differently, please let me know
and I will take a shot at implementing those suggestions.
Please keep in mind that the drm_privacy_screen_set_sw_state() call also
needs to happens when just the connector_state->privacy_screen_sw_state changes,
which is not a reason to do a full modeset (iow needs_modeset maybe 0 during
the commit)
Regards,
Hans
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [Intel-gfx] [PATCH 9/9] drm/i915: Add privacy-screen support
@ 2021-09-17 14:37 ` Hans de Goede
0 siblings, 0 replies; 84+ messages in thread
From: Hans de Goede @ 2021-09-17 14:37 UTC (permalink / raw)
To: Ville Syrjälä
Cc: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rajat Jain,
Jani Nikula, Lyude, Joonas Lahtinen, Rodrigo Vivi, Mark Gross,
Andy Shevchenko, 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/16/21 3:45 PM, Ville Syrjälä wrote:
> On Mon, Sep 06, 2021 at 09:35:19AM +0200, Hans de Goede wrote:
>> 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.
>
> Pretty sure the full atomic state is plumbed all the way
> down these days.
Including the old state? AFAICT the old-state is being thrown away
from drm_atomic_helper_swap_state(), so if we do this in a different
place then we don't have access to the old-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.
>
> I doubt anyone is going to care about a bit of overhead for a modeset.
But this is not a modeset, this is more like changing the backlight brightness,
atm the code does not set the needs_modeset when only the privacy-screen
sw-state has changed.
Also in my experience the firmware (AML) code which we end up calling
for this is not the highest quality code, often it has interesting
issues / unhandled corner cases. So in my experience with ACPI we
really should try to avoid these calls unless we absolutely must make them,
but I guess not making unnecessary calls is something which could be handled
inside the actual privacy-screen driver instead.
> The usual rule is that a modeset doesn't skip anything. That way we
> can be 100% sure we remeber to update everythinbg. For fastsets I guess
> one could argue skipping it if not needed, but not sure even that is
> warranted.
Right, but again this is not a full modeset.
>
> The current code you have in there is cettainly 110% dodgy. Since the
> sw_state is stored in the connector state I presume it's at least
> trying to be an atomic property, which means you shouldn't go poking
> at it after the swap_state ever.
It is not being poked, it is only being read, also this is happening
before swap_state.
Note I'm open for suggestions to handle this differently,
including changing the drm_connector_update_privacy_screen()
helper which currently relies on being passed the state before swap_state
is called:
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;
}
So if you have any suggestions how to do this differently, please let me know
and I will take a shot at implementing those suggestions.
Please keep in mind that the drm_privacy_screen_set_sw_state() call also
needs to happens when just the connector_state->privacy_screen_sw_state changes,
which is not a reason to do a full modeset (iow needs_modeset maybe 0 during
the commit)
Regards,
Hans
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [PATCH 9/9] drm/i915: Add privacy-screen support
2021-09-17 14:37 ` [Intel-gfx] " Hans de Goede
@ 2021-09-17 16:25 ` Ville Syrjälä
-1 siblings, 0 replies; 84+ messages in thread
From: Ville Syrjälä @ 2021-09-17 16:25 UTC (permalink / raw)
To: Hans de Goede
Cc: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rajat Jain,
Jani Nikula, Lyude, Joonas Lahtinen, Rodrigo Vivi, Mark Gross,
Andy Shevchenko, Daniel Vetter, David Airlie, Pekka Paalanen,
Mario Limonciello, Mark Pearson, Sebastien Bacher,
Marco Trevisan, Emil Velikov, intel-gfx, dri-devel,
platform-driver-x86
On Fri, Sep 17, 2021 at 04:37:14PM +0200, Hans de Goede wrote:
> Hi,
>
> On 9/16/21 3:45 PM, Ville Syrjälä wrote:
> > On Mon, Sep 06, 2021 at 09:35:19AM +0200, Hans de Goede wrote:
> >> 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.
> >
> > Pretty sure the full atomic state is plumbed all the way
> > down these days.
>
> Including the old state? AFAICT the old-state is being thrown away
> from drm_atomic_helper_swap_state(),
No. That's just when those annoying foo_state->state pointers get
clobbered. We've been moving away from using those and just
plumbing the entire atomic state everywhere.
Nothing actually gets freed until the whole drm_atomic_state gets
nuked after the commit is done.
> so if we do this in a different
> place then we don't have access to the old-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.
> >
> > I doubt anyone is going to care about a bit of overhead for a modeset.
>
> But this is not a modeset, this is more like changing the backlight brightness,
> atm the code does not set the needs_modeset when only the privacy-screen
> sw-state has changed.
>
> Also in my experience the firmware (AML) code which we end up calling
> for this is not the highest quality code, often it has interesting
> issues / unhandled corner cases. So in my experience with ACPI we
> really should try to avoid these calls unless we absolutely must make them,
> but I guess not making unnecessary calls is something which could be handled
> inside the actual privacy-screen driver instead.
>
> > The usual rule is that a modeset doesn't skip anything. That way we
> > can be 100% sure we remeber to update everythinbg. For fastsets I guess
> > one could argue skipping it if not needed, but not sure even that is
> > warranted.
>
> Right, but again this is not a full modeset.
In general fastset is is just an optimized modeset. Userspace asked
for a modeset, but we noticed it doesn't need it. I don't think
there is a particular expectation that it's super fast.
But if this is really annoyingly slow in some actual usecase then
one way to avoid that need to compare against the old state is just
introduce another foo_changed flag.
>
> >
> > The current code you have in there is cettainly 110% dodgy. Since the
> > sw_state is stored in the connector state I presume it's at least
> > trying to be an atomic property, which means you shouldn't go poking
> > at it after the swap_state ever.
>
> It is not being poked, it is only being read, also this is happening
> before swap_state.
>
> Note I'm open for suggestions to handle this differently,
> including changing the drm_connector_update_privacy_screen()
> helper which currently relies on being passed the state before swap_state
> is called:
>
> 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;
> }
>
> So if you have any suggestions how to do this differently, please let me know
> and I will take a shot at implementing those suggestions.
You cut the code too soon. Just after this you call the other
update_privacy_screen() thing which does poke at
connector->state->stuff AFAICS.
>
> Please keep in mind that the drm_privacy_screen_set_sw_state() call also
> needs to happens when just the connector_state->privacy_screen_sw_state changes,
> which is not a reason to do a full modeset (iow needs_modeset maybe 0 during
> the commit)
>
> Regards,
>
> Hans
>
>
--
Ville Syrjälä
Intel
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [Intel-gfx] [PATCH 9/9] drm/i915: Add privacy-screen support
@ 2021-09-17 16:25 ` Ville Syrjälä
0 siblings, 0 replies; 84+ messages in thread
From: Ville Syrjälä @ 2021-09-17 16:25 UTC (permalink / raw)
To: Hans de Goede
Cc: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rajat Jain,
Jani Nikula, Lyude, Joonas Lahtinen, Rodrigo Vivi, Mark Gross,
Andy Shevchenko, Daniel Vetter, David Airlie, Pekka Paalanen,
Mario Limonciello, Mark Pearson, Sebastien Bacher,
Marco Trevisan, Emil Velikov, intel-gfx, dri-devel,
platform-driver-x86
On Fri, Sep 17, 2021 at 04:37:14PM +0200, Hans de Goede wrote:
> Hi,
>
> On 9/16/21 3:45 PM, Ville Syrjälä wrote:
> > On Mon, Sep 06, 2021 at 09:35:19AM +0200, Hans de Goede wrote:
> >> 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.
> >
> > Pretty sure the full atomic state is plumbed all the way
> > down these days.
>
> Including the old state? AFAICT the old-state is being thrown away
> from drm_atomic_helper_swap_state(),
No. That's just when those annoying foo_state->state pointers get
clobbered. We've been moving away from using those and just
plumbing the entire atomic state everywhere.
Nothing actually gets freed until the whole drm_atomic_state gets
nuked after the commit is done.
> so if we do this in a different
> place then we don't have access to the old-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.
> >
> > I doubt anyone is going to care about a bit of overhead for a modeset.
>
> But this is not a modeset, this is more like changing the backlight brightness,
> atm the code does not set the needs_modeset when only the privacy-screen
> sw-state has changed.
>
> Also in my experience the firmware (AML) code which we end up calling
> for this is not the highest quality code, often it has interesting
> issues / unhandled corner cases. So in my experience with ACPI we
> really should try to avoid these calls unless we absolutely must make them,
> but I guess not making unnecessary calls is something which could be handled
> inside the actual privacy-screen driver instead.
>
> > The usual rule is that a modeset doesn't skip anything. That way we
> > can be 100% sure we remeber to update everythinbg. For fastsets I guess
> > one could argue skipping it if not needed, but not sure even that is
> > warranted.
>
> Right, but again this is not a full modeset.
In general fastset is is just an optimized modeset. Userspace asked
for a modeset, but we noticed it doesn't need it. I don't think
there is a particular expectation that it's super fast.
But if this is really annoyingly slow in some actual usecase then
one way to avoid that need to compare against the old state is just
introduce another foo_changed flag.
>
> >
> > The current code you have in there is cettainly 110% dodgy. Since the
> > sw_state is stored in the connector state I presume it's at least
> > trying to be an atomic property, which means you shouldn't go poking
> > at it after the swap_state ever.
>
> It is not being poked, it is only being read, also this is happening
> before swap_state.
>
> Note I'm open for suggestions to handle this differently,
> including changing the drm_connector_update_privacy_screen()
> helper which currently relies on being passed the state before swap_state
> is called:
>
> 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;
> }
>
> So if you have any suggestions how to do this differently, please let me know
> and I will take a shot at implementing those suggestions.
You cut the code too soon. Just after this you call the other
update_privacy_screen() thing which does poke at
connector->state->stuff AFAICS.
>
> Please keep in mind that the drm_privacy_screen_set_sw_state() call also
> needs to happens when just the connector_state->privacy_screen_sw_state changes,
> which is not a reason to do a full modeset (iow needs_modeset maybe 0 during
> the commit)
>
> Regards,
>
> Hans
>
>
--
Ville Syrjälä
Intel
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [PATCH 9/9] drm/i915: Add privacy-screen support
2021-09-17 16:25 ` [Intel-gfx] " Ville Syrjälä
@ 2021-09-17 16:42 ` Hans de Goede
-1 siblings, 0 replies; 84+ messages in thread
From: Hans de Goede @ 2021-09-17 16:42 UTC (permalink / raw)
To: Ville Syrjälä
Cc: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rajat Jain,
Jani Nikula, Lyude, Joonas Lahtinen, Rodrigo Vivi, Mark Gross,
Andy Shevchenko, 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/17/21 6:25 PM, Ville Syrjälä wrote:
> On Fri, Sep 17, 2021 at 04:37:14PM +0200, Hans de Goede wrote:
>> Hi,
>>
>> On 9/16/21 3:45 PM, Ville Syrjälä wrote:
>>> On Mon, Sep 06, 2021 at 09:35:19AM +0200, Hans de Goede wrote:
>>>> 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.
>>>
>>> Pretty sure the full atomic state is plumbed all the way
>>> down these days.
>>
>> Including the old state? AFAICT the old-state is being thrown away
>> from drm_atomic_helper_swap_state(),
>
> No. That's just when those annoying foo_state->state pointers get
> clobbered. We've been moving away from using those and just
> plumbing the entire atomic state everywhere.
>
> Nothing actually gets freed until the whole drm_atomic_state gets
> nuked after the commit is done.
>
>> so if we do this in a different
>> place then we don't have access to the old-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.
>>>
>>> I doubt anyone is going to care about a bit of overhead for a modeset.
>>
>> But this is not a modeset, this is more like changing the backlight brightness,
>> atm the code does not set the needs_modeset when only the privacy-screen
>> sw-state has changed.
>>
>> Also in my experience the firmware (AML) code which we end up calling
>> for this is not the highest quality code, often it has interesting
>> issues / unhandled corner cases. So in my experience with ACPI we
>> really should try to avoid these calls unless we absolutely must make them,
>> but I guess not making unnecessary calls is something which could be handled
>> inside the actual privacy-screen driver instead.
>>
>>> The usual rule is that a modeset doesn't skip anything. That way we
>>> can be 100% sure we remeber to update everythinbg. For fastsets I guess
>>> one could argue skipping it if not needed, but not sure even that is
>>> warranted.
>>
>> Right, but again this is not a full modeset.
>
> In general fastset is is just an optimized modeset. Userspace asked
> for a modeset, but we noticed it doesn't need it. I don't think
> there is a particular expectation that it's super fast.
>
> But if this is really annoyingly slow in some actual usecase
Yeah these acpi-calls might take like a 100 ms easily, so
we really want to avoid it if it is not necessary.
> then
> one way to avoid that need to compare against the old state is just
> introduce another foo_changed flag.
Ok, so I have the feeling that you have an idea of how you think this
should be done / how this code should look instead of what I have
currently.
Can you perhaps provide a rough sketch / description of how you
think this should be done (instead of the current implementation) ?
Should I do the update from the the encoder update_pipe (for fast-sets)
and enable (for full modesets) callbacks instead as I mention in
the commit message ?
And since I still only want to do the call if there is an actual
change, where could I best do the old / new sw_state change cmp to
set the new foo_changed flag?
>
>>
>>>
>>> The current code you have in there is cettainly 110% dodgy. Since the
>>> sw_state is stored in the connector state I presume it's at least
>>> trying to be an atomic property, which means you shouldn't go poking
>>> at it after the swap_state ever.
>>
>> It is not being poked, it is only being read, also this is happening
>> before swap_state.
>>
>> Note I'm open for suggestions to handle this differently,
>> including changing the drm_connector_update_privacy_screen()
>> helper which currently relies on being passed the state before swap_state
>> is called:
>>
>> 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;
>> }
>>
>> So if you have any suggestions how to do this differently, please let me know
>> and I will take a shot at implementing those suggestions.
>
> You cut the code too soon. Just after this you call the other
> update_privacy_screen() thing which does poke at
> connector->state->stuff AFAICS.
True, the idea here is to only update the hw_state, the returned sw_state
should always be the one which we just set. But I agree it would be better to
change the code here so that drm_connector_update_privacy_screen() only
updates privacy_screen_hw_state I will change the code to do this in the
next version of this patch-set.
Regards,
Hans
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [Intel-gfx] [PATCH 9/9] drm/i915: Add privacy-screen support
@ 2021-09-17 16:42 ` Hans de Goede
0 siblings, 0 replies; 84+ messages in thread
From: Hans de Goede @ 2021-09-17 16:42 UTC (permalink / raw)
To: Ville Syrjälä
Cc: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rajat Jain,
Jani Nikula, Lyude, Joonas Lahtinen, Rodrigo Vivi, Mark Gross,
Andy Shevchenko, 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/17/21 6:25 PM, Ville Syrjälä wrote:
> On Fri, Sep 17, 2021 at 04:37:14PM +0200, Hans de Goede wrote:
>> Hi,
>>
>> On 9/16/21 3:45 PM, Ville Syrjälä wrote:
>>> On Mon, Sep 06, 2021 at 09:35:19AM +0200, Hans de Goede wrote:
>>>> 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.
>>>
>>> Pretty sure the full atomic state is plumbed all the way
>>> down these days.
>>
>> Including the old state? AFAICT the old-state is being thrown away
>> from drm_atomic_helper_swap_state(),
>
> No. That's just when those annoying foo_state->state pointers get
> clobbered. We've been moving away from using those and just
> plumbing the entire atomic state everywhere.
>
> Nothing actually gets freed until the whole drm_atomic_state gets
> nuked after the commit is done.
>
>> so if we do this in a different
>> place then we don't have access to the old-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.
>>>
>>> I doubt anyone is going to care about a bit of overhead for a modeset.
>>
>> But this is not a modeset, this is more like changing the backlight brightness,
>> atm the code does not set the needs_modeset when only the privacy-screen
>> sw-state has changed.
>>
>> Also in my experience the firmware (AML) code which we end up calling
>> for this is not the highest quality code, often it has interesting
>> issues / unhandled corner cases. So in my experience with ACPI we
>> really should try to avoid these calls unless we absolutely must make them,
>> but I guess not making unnecessary calls is something which could be handled
>> inside the actual privacy-screen driver instead.
>>
>>> The usual rule is that a modeset doesn't skip anything. That way we
>>> can be 100% sure we remeber to update everythinbg. For fastsets I guess
>>> one could argue skipping it if not needed, but not sure even that is
>>> warranted.
>>
>> Right, but again this is not a full modeset.
>
> In general fastset is is just an optimized modeset. Userspace asked
> for a modeset, but we noticed it doesn't need it. I don't think
> there is a particular expectation that it's super fast.
>
> But if this is really annoyingly slow in some actual usecase
Yeah these acpi-calls might take like a 100 ms easily, so
we really want to avoid it if it is not necessary.
> then
> one way to avoid that need to compare against the old state is just
> introduce another foo_changed flag.
Ok, so I have the feeling that you have an idea of how you think this
should be done / how this code should look instead of what I have
currently.
Can you perhaps provide a rough sketch / description of how you
think this should be done (instead of the current implementation) ?
Should I do the update from the the encoder update_pipe (for fast-sets)
and enable (for full modesets) callbacks instead as I mention in
the commit message ?
And since I still only want to do the call if there is an actual
change, where could I best do the old / new sw_state change cmp to
set the new foo_changed flag?
>
>>
>>>
>>> The current code you have in there is cettainly 110% dodgy. Since the
>>> sw_state is stored in the connector state I presume it's at least
>>> trying to be an atomic property, which means you shouldn't go poking
>>> at it after the swap_state ever.
>>
>> It is not being poked, it is only being read, also this is happening
>> before swap_state.
>>
>> Note I'm open for suggestions to handle this differently,
>> including changing the drm_connector_update_privacy_screen()
>> helper which currently relies on being passed the state before swap_state
>> is called:
>>
>> 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;
>> }
>>
>> So if you have any suggestions how to do this differently, please let me know
>> and I will take a shot at implementing those suggestions.
>
> You cut the code too soon. Just after this you call the other
> update_privacy_screen() thing which does poke at
> connector->state->stuff AFAICS.
True, the idea here is to only update the hw_state, the returned sw_state
should always be the one which we just set. But I agree it would be better to
change the code here so that drm_connector_update_privacy_screen() only
updates privacy_screen_hw_state I will change the code to do this in the
next version of this patch-set.
Regards,
Hans
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [PATCH 9/9] drm/i915: Add privacy-screen support
2021-09-17 16:42 ` [Intel-gfx] " Hans de Goede
@ 2021-09-17 17:04 ` Ville Syrjälä
-1 siblings, 0 replies; 84+ messages in thread
From: Ville Syrjälä @ 2021-09-17 17:04 UTC (permalink / raw)
To: Hans de Goede
Cc: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rajat Jain,
Jani Nikula, Lyude, Joonas Lahtinen, Rodrigo Vivi, Mark Gross,
Andy Shevchenko, Daniel Vetter, David Airlie, Pekka Paalanen,
Mario Limonciello, Mark Pearson, Sebastien Bacher,
Marco Trevisan, Emil Velikov, intel-gfx, dri-devel,
platform-driver-x86
On Fri, Sep 17, 2021 at 06:42:04PM +0200, Hans de Goede wrote:
> Hi,
>
> On 9/17/21 6:25 PM, Ville Syrjälä wrote:
> > On Fri, Sep 17, 2021 at 04:37:14PM +0200, Hans de Goede wrote:
> >> Hi,
> >>
> >> On 9/16/21 3:45 PM, Ville Syrjälä wrote:
> >>> On Mon, Sep 06, 2021 at 09:35:19AM +0200, Hans de Goede wrote:
> >>>> 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.
> >>>
> >>> Pretty sure the full atomic state is plumbed all the way
> >>> down these days.
> >>
> >> Including the old state? AFAICT the old-state is being thrown away
> >> from drm_atomic_helper_swap_state(),
> >
> > No. That's just when those annoying foo_state->state pointers get
> > clobbered. We've been moving away from using those and just
> > plumbing the entire atomic state everywhere.
> >
> > Nothing actually gets freed until the whole drm_atomic_state gets
> > nuked after the commit is done.
> >
> >> so if we do this in a different
> >> place then we don't have access to the old-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.
> >>>
> >>> I doubt anyone is going to care about a bit of overhead for a modeset.
> >>
> >> But this is not a modeset, this is more like changing the backlight brightness,
> >> atm the code does not set the needs_modeset when only the privacy-screen
> >> sw-state has changed.
> >>
> >> Also in my experience the firmware (AML) code which we end up calling
> >> for this is not the highest quality code, often it has interesting
> >> issues / unhandled corner cases. So in my experience with ACPI we
> >> really should try to avoid these calls unless we absolutely must make them,
> >> but I guess not making unnecessary calls is something which could be handled
> >> inside the actual privacy-screen driver instead.
> >>
> >>> The usual rule is that a modeset doesn't skip anything. That way we
> >>> can be 100% sure we remeber to update everythinbg. For fastsets I guess
> >>> one could argue skipping it if not needed, but not sure even that is
> >>> warranted.
> >>
> >> Right, but again this is not a full modeset.
> >
> > In general fastset is is just an optimized modeset. Userspace asked
> > for a modeset, but we noticed it doesn't need it. I don't think
> > there is a particular expectation that it's super fast.
> >
> > But if this is really annoyingly slow in some actual usecase
>
> Yeah these acpi-calls might take like a 100 ms easily, so
> we really want to avoid it if it is not necessary.
>
> > then
> > one way to avoid that need to compare against the old state is just
> > introduce another foo_changed flag.
>
> Ok, so I have the feeling that you have an idea of how you think this
> should be done / how this code should look instead of what I have
> currently.
>
> Can you perhaps provide a rough sketch / description of how you
> think this should be done (instead of the current implementation) ?
>
> Should I do the update from the the encoder update_pipe (for fast-sets)
> and enable (for full modesets) callbacks instead as I mention in
> the commit message ?
>
> And since I still only want to do the call if there is an actual
> change, where could I best do the old / new sw_state change cmp to
> set the new foo_changed flag?
>
I guess it could be just something like this:
intel_digital_connector_duplicate_state()
{
foo_changed = false;
}
intel_digital_connector_atomic_check()
{
if (old_foo != new_foo) {
mode_changed = true;
foo_changed = true;
}
}
update_pipe()
{
if (foo_changed)
update_foo();
}
--
Ville Syrjälä
Intel
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [Intel-gfx] [PATCH 9/9] drm/i915: Add privacy-screen support
@ 2021-09-17 17:04 ` Ville Syrjälä
0 siblings, 0 replies; 84+ messages in thread
From: Ville Syrjälä @ 2021-09-17 17:04 UTC (permalink / raw)
To: Hans de Goede
Cc: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rajat Jain,
Jani Nikula, Lyude, Joonas Lahtinen, Rodrigo Vivi, Mark Gross,
Andy Shevchenko, Daniel Vetter, David Airlie, Pekka Paalanen,
Mario Limonciello, Mark Pearson, Sebastien Bacher,
Marco Trevisan, Emil Velikov, intel-gfx, dri-devel,
platform-driver-x86
On Fri, Sep 17, 2021 at 06:42:04PM +0200, Hans de Goede wrote:
> Hi,
>
> On 9/17/21 6:25 PM, Ville Syrjälä wrote:
> > On Fri, Sep 17, 2021 at 04:37:14PM +0200, Hans de Goede wrote:
> >> Hi,
> >>
> >> On 9/16/21 3:45 PM, Ville Syrjälä wrote:
> >>> On Mon, Sep 06, 2021 at 09:35:19AM +0200, Hans de Goede wrote:
> >>>> 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.
> >>>
> >>> Pretty sure the full atomic state is plumbed all the way
> >>> down these days.
> >>
> >> Including the old state? AFAICT the old-state is being thrown away
> >> from drm_atomic_helper_swap_state(),
> >
> > No. That's just when those annoying foo_state->state pointers get
> > clobbered. We've been moving away from using those and just
> > plumbing the entire atomic state everywhere.
> >
> > Nothing actually gets freed until the whole drm_atomic_state gets
> > nuked after the commit is done.
> >
> >> so if we do this in a different
> >> place then we don't have access to the old-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.
> >>>
> >>> I doubt anyone is going to care about a bit of overhead for a modeset.
> >>
> >> But this is not a modeset, this is more like changing the backlight brightness,
> >> atm the code does not set the needs_modeset when only the privacy-screen
> >> sw-state has changed.
> >>
> >> Also in my experience the firmware (AML) code which we end up calling
> >> for this is not the highest quality code, often it has interesting
> >> issues / unhandled corner cases. So in my experience with ACPI we
> >> really should try to avoid these calls unless we absolutely must make them,
> >> but I guess not making unnecessary calls is something which could be handled
> >> inside the actual privacy-screen driver instead.
> >>
> >>> The usual rule is that a modeset doesn't skip anything. That way we
> >>> can be 100% sure we remeber to update everythinbg. For fastsets I guess
> >>> one could argue skipping it if not needed, but not sure even that is
> >>> warranted.
> >>
> >> Right, but again this is not a full modeset.
> >
> > In general fastset is is just an optimized modeset. Userspace asked
> > for a modeset, but we noticed it doesn't need it. I don't think
> > there is a particular expectation that it's super fast.
> >
> > But if this is really annoyingly slow in some actual usecase
>
> Yeah these acpi-calls might take like a 100 ms easily, so
> we really want to avoid it if it is not necessary.
>
> > then
> > one way to avoid that need to compare against the old state is just
> > introduce another foo_changed flag.
>
> Ok, so I have the feeling that you have an idea of how you think this
> should be done / how this code should look instead of what I have
> currently.
>
> Can you perhaps provide a rough sketch / description of how you
> think this should be done (instead of the current implementation) ?
>
> Should I do the update from the the encoder update_pipe (for fast-sets)
> and enable (for full modesets) callbacks instead as I mention in
> the commit message ?
>
> And since I still only want to do the call if there is an actual
> change, where could I best do the old / new sw_state change cmp to
> set the new foo_changed flag?
>
I guess it could be just something like this:
intel_digital_connector_duplicate_state()
{
foo_changed = false;
}
intel_digital_connector_atomic_check()
{
if (old_foo != new_foo) {
mode_changed = true;
foo_changed = true;
}
}
update_pipe()
{
if (foo_changed)
update_foo();
}
--
Ville Syrjälä
Intel
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [PATCH 9/9] drm/i915: Add privacy-screen support
2021-09-16 10:32 ` [Intel-gfx] " Hans de Goede
(?)
@ 2021-09-20 21:06 ` Lyude Paul
-1 siblings, 0 replies; 84+ messages in thread
From: Lyude Paul @ 2021-09-20 21:06 UTC (permalink / raw)
To: Hans de Goede, Jani Nikula, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rajat Jain, Joonas Lahtinen, Rodrigo Vivi,
Mark Gross, Andy Shevchenko, Ville Syrjälä
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, 2021-09-16 at 12:32 +0200, Hans de Goede wrote:
>
> I'm fine with refactoring this a bit and adding
> an intel_modeset_probe_defer() helper for this, I assume I should also
> move the vga_switcheroo_client_probe_defer(pdev) check there?
>
> As you suggested yourself in your reply to the coverletter I will
> push out the rest of the series to drm-misc-next while we figure this
> out. Assuming Lyude is happy with the answers which I gave to her
> remarks about some of the other patches.
I am, btw!
>
> Regards,
>
> Hans
>
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [Intel-gfx] [PATCH 9/9] drm/i915: Add privacy-screen support
@ 2021-09-20 21:06 ` Lyude Paul
0 siblings, 0 replies; 84+ messages in thread
From: Lyude Paul @ 2021-09-20 21:06 UTC (permalink / raw)
To: Hans de Goede, Jani Nikula, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rajat Jain, Joonas Lahtinen, Rodrigo Vivi,
Mark Gross, Andy Shevchenko, Ville Syrjälä
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, 2021-09-16 at 12:32 +0200, Hans de Goede wrote:
>
> I'm fine with refactoring this a bit and adding
> an intel_modeset_probe_defer() helper for this, I assume I should also
> move the vga_switcheroo_client_probe_defer(pdev) check there?
>
> As you suggested yourself in your reply to the coverletter I will
> push out the rest of the series to drm-misc-next while we figure this
> out. Assuming Lyude is happy with the answers which I gave to her
> remarks about some of the other patches.
I am, btw!
>
> Regards,
>
> Hans
>
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [PATCH 9/9] drm/i915: Add privacy-screen support
@ 2021-09-20 21:06 ` Lyude Paul
0 siblings, 0 replies; 84+ messages in thread
From: Lyude Paul @ 2021-09-20 21:06 UTC (permalink / raw)
To: Hans de Goede, Jani Nikula, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rajat Jain, Joonas Lahtinen, Rodrigo Vivi,
Mark Gross, Andy Shevchenko, Ville Syrjälä
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, 2021-09-16 at 12:32 +0200, Hans de Goede wrote:
>
> I'm fine with refactoring this a bit and adding
> an intel_modeset_probe_defer() helper for this, I assume I should also
> move the vga_switcheroo_client_probe_defer(pdev) check there?
>
> As you suggested yourself in your reply to the coverletter I will
> push out the rest of the series to drm-misc-next while we figure this
> out. Assuming Lyude is happy with the answers which I gave to her
> remarks about some of the other patches.
I am, btw!
>
> Regards,
>
> Hans
>
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
^ permalink raw reply [flat|nested] 84+ messages in thread
end of thread, other threads:[~2021-09-20 21:08 UTC | newest]
Thread overview: 84+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-09-06 7:35 [PATCH 0/9] drm: Add privacy-screen class and connector properties Hans de Goede
2021-09-06 7:35 ` [Intel-gfx] " Hans de Goede
2021-09-06 7:35 ` [PATCH 1/9] drm/connector: Add support for privacy-screen properties (v4) Hans de Goede
2021-09-06 7:35 ` [Intel-gfx] " Hans de Goede
2021-09-15 19:48 ` Lyude Paul
2021-09-15 19:48 ` [Intel-gfx] " Lyude Paul
2021-09-15 19:48 ` Lyude Paul
2021-09-16 8:26 ` Jani Nikula
2021-09-16 8:26 ` [Intel-gfx] " Jani Nikula
2021-09-06 7:35 ` [PATCH 2/9] drm: Add privacy-screen class (v3) Hans de Goede
2021-09-06 7:35 ` [Intel-gfx] " Hans de Goede
2021-09-15 20:01 ` Lyude Paul
2021-09-15 20:01 ` [Intel-gfx] " Lyude Paul
2021-09-15 20:01 ` Lyude Paul
2021-09-16 8:49 ` Hans de Goede
2021-09-16 8:49 ` [Intel-gfx] " Hans de Goede
2021-09-06 7:35 ` [PATCH 3/9] drm/privacy-screen: Add X86 specific arch init code Hans de Goede
2021-09-06 7:35 ` [Intel-gfx] " Hans de Goede
2021-09-16 8:51 ` Jani Nikula
2021-09-16 8:51 ` [Intel-gfx] " Jani Nikula
2021-09-16 9:18 ` Hans de Goede
2021-09-16 9:18 ` [Intel-gfx] " Hans de Goede
2021-09-06 7:35 ` [Intel-gfx] [PATCH 4/9] drm/privacy-screen: Add notifier support Hans de Goede
2021-09-06 7:35 ` Hans de Goede
2021-09-15 20:26 ` Lyude Paul
2021-09-15 20:26 ` Lyude Paul
2021-09-15 20:26 ` [Intel-gfx] " Lyude Paul
2021-09-16 9:06 ` Hans de Goede
2021-09-16 9:06 ` [Intel-gfx] " Hans de Goede
2021-09-16 16:50 ` Lyude Paul
2021-09-16 16:50 ` Lyude Paul
2021-09-16 16:50 ` [Intel-gfx] " Lyude Paul
2021-09-06 7:35 ` [PATCH 5/9] drm/connector: Add a drm_connector privacy-screen helper functions Hans de Goede
2021-09-06 7:35 ` [Intel-gfx] " Hans de Goede
2021-09-06 7:35 ` [PATCH 6/9] platform/x86: thinkpad_acpi: Add hotkey_notify_extended_hotkey() helper Hans de Goede
2021-09-06 7:35 ` [Intel-gfx] " Hans de Goede
2021-09-06 7:35 ` [PATCH 7/9] platform/x86: thinkpad_acpi: Get privacy-screen / lcdshadow ACPI handles only once Hans de Goede
2021-09-06 7:35 ` [Intel-gfx] " Hans de Goede
2021-09-06 7:35 ` [PATCH 8/9] platform/x86: thinkpad_acpi: Register a privacy-screen device Hans de Goede
2021-09-06 7:35 ` [Intel-gfx] " Hans de Goede
2021-09-15 20:55 ` Lyude Paul
2021-09-15 20:55 ` [Intel-gfx] " Lyude Paul
2021-09-15 20:55 ` Lyude Paul
2021-09-16 9:09 ` Hans de Goede
2021-09-16 9:09 ` [Intel-gfx] " Hans de Goede
2021-09-06 7:35 ` [PATCH 9/9] drm/i915: Add privacy-screen support Hans de Goede
2021-09-06 7:35 ` [Intel-gfx] " Hans de Goede
2021-09-15 21:11 ` Lyude Paul
2021-09-15 21:11 ` [Intel-gfx] " Lyude Paul
2021-09-15 21:11 ` Lyude Paul
2021-09-16 9:12 ` Hans de Goede
2021-09-16 9:12 ` [Intel-gfx] " Hans de Goede
2021-09-16 9:40 ` Jani Nikula
2021-09-16 9:40 ` [Intel-gfx] " Jani Nikula
2021-09-16 10:32 ` Hans de Goede
2021-09-16 10:32 ` [Intel-gfx] " Hans de Goede
2021-09-20 21:06 ` Lyude Paul
2021-09-20 21:06 ` Lyude Paul
2021-09-20 21:06 ` [Intel-gfx] " Lyude Paul
2021-09-16 14:04 ` Ville Syrjälä
2021-09-16 14:04 ` [Intel-gfx] " Ville Syrjälä
2021-09-17 14:23 ` Hans de Goede
2021-09-17 14:23 ` [Intel-gfx] " Hans de Goede
2021-09-16 13:45 ` Ville Syrjälä
2021-09-16 13:45 ` [Intel-gfx] " Ville Syrjälä
2021-09-17 14:37 ` Hans de Goede
2021-09-17 14:37 ` [Intel-gfx] " Hans de Goede
2021-09-17 16:25 ` Ville Syrjälä
2021-09-17 16:25 ` [Intel-gfx] " Ville Syrjälä
2021-09-17 16:42 ` Hans de Goede
2021-09-17 16:42 ` [Intel-gfx] " Hans de Goede
2021-09-17 17:04 ` Ville Syrjälä
2021-09-17 17:04 ` [Intel-gfx] " Ville Syrjälä
2021-09-06 8:46 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm: Add privacy-screen class and connector properties (rev4) Patchwork
2021-09-06 8:49 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2021-09-06 9:17 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2021-09-06 11:16 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
2021-09-15 21:12 ` [PATCH 0/9] drm: Add privacy-screen class and connector properties Lyude Paul
2021-09-15 21:12 ` [Intel-gfx] " Lyude Paul
2021-09-15 21:12 ` Lyude Paul
2021-09-16 9:30 ` Hans de Goede
2021-09-16 9:30 ` [Intel-gfx] " Hans de Goede
2021-09-16 10:14 ` Jani Nikula
2021-09-16 10:14 ` [Intel-gfx] " 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.