[PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Hsin-Yi Wang]

drm_dev_register() sets connector->registration_state to
DRM_CONNECTOR_REGISTERED and dev->registered to true. If
drm_connector_set_panel_orientation() is first called after
drm_dev_register(), it will fail several checks and results in following
warning.

Add a function to create panel orientation property and set default value
to UNKNOWN, so drivers can call this function to init the property earlier
, and let the panel set the real value later.

[    4.480976] ------------[ cut here ]------------
[    4.485603] WARNING: CPU: 5 PID: 369 at drivers/gpu/drm/drm_mode_object.c:45 __drm_mode_object_add+0xb4/0xbc
<snip>
[    4.609772] Call trace:
[    4.612208]  __drm_mode_object_add+0xb4/0xbc
[    4.616466]  drm_mode_object_add+0x20/0x2c
[    4.620552]  drm_property_create+0xdc/0x174
[    4.624723]  drm_property_create_enum+0x34/0x98
[    4.629241]  drm_connector_set_panel_orientation+0x64/0xa0
[    4.634716]  boe_panel_get_modes+0x88/0xd8
[    4.638802]  drm_panel_get_modes+0x2c/0x48
[    4.642887]  panel_bridge_get_modes+0x1c/0x28
[    4.647233]  drm_bridge_connector_get_modes+0xa0/0xd4
[    4.652273]  drm_helper_probe_single_connector_modes+0x218/0x700
[    4.658266]  drm_mode_getconnector+0x1b4/0x45c
[    4.662699]  drm_ioctl_kernel+0xac/0x128
[    4.666611]  drm_ioctl+0x268/0x410
[    4.670002]  drm_compat_ioctl+0xdc/0xf0
[    4.673829]  __arm64_compat_sys_ioctl+0xc8/0x100
[    4.678436]  el0_svc_common+0xf4/0x1c0
[    4.682174]  do_el0_svc_compat+0x28/0x3c
[    4.686088]  el0_svc_compat+0x10/0x1c
[    4.689738]  el0_sync_compat_handler+0xa8/0xcc
[    4.694171]  el0_sync_compat+0x178/0x180
[    4.698082] ---[ end trace b4f2db9d9c88610b ]---
[    4.702721] ------------[ cut here ]------------
[    4.707329] WARNING: CPU: 5 PID: 369 at drivers/gpu/drm/drm_mode_object.c:243 drm_object_attach_property+0x48/0xb8
<snip>
[    4.833830] Call trace:
[    4.836266]  drm_object_attach_property+0x48/0xb8
[    4.840958]  drm_connector_set_panel_orientation+0x84/0xa0
[    4.846432]  boe_panel_get_modes+0x88/0xd8
[    4.850516]  drm_panel_get_modes+0x2c/0x48
[    4.854600]  panel_bridge_get_modes+0x1c/0x28
[    4.858946]  drm_bridge_connector_get_modes+0xa0/0xd4
[    4.863984]  drm_helper_probe_single_connector_modes+0x218/0x700
[    4.869978]  drm_mode_getconnector+0x1b4/0x45c
[    4.874410]  drm_ioctl_kernel+0xac/0x128
[    4.878320]  drm_ioctl+0x268/0x410
[    4.881711]  drm_compat_ioctl+0xdc/0xf0
[    4.885536]  __arm64_compat_sys_ioctl+0xc8/0x100
[    4.890142]  el0_svc_common+0xf4/0x1c0
[    4.893879]  do_el0_svc_compat+0x28/0x3c
[    4.897791]  el0_svc_compat+0x10/0x1c
[    4.901441]  el0_sync_compat_handler+0xa8/0xcc
[    4.905873]  el0_sync_compat+0x178/0x180
[    4.909783] ---[ end trace b4f2db9d9c88610c ]---

Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
---
v7->v8:
- check if the prop is created to avoid leak issue when called multiple
  times.
- attempt to create prop in drm_connector_set_panel_orientation if prop
  is not created before, so driver don't need to call
  drm_connector_init_panel_orientation_property if they don't need to
  set the property earlier.
---
 drivers/gpu/drm/drm_connector.c | 62 ++++++++++++++++++++++++---------
 include/drm/drm_connector.h     |  2 ++
 2 files changed, 48 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index a50c82bc2b2fec..572ead7ac10690 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1252,7 +1252,7 @@ static const struct drm_prop_enum_list dp_colorspaces[] = {
  *	INPUT_PROP_DIRECT) will still map 1:1 to the actual LCD panel
  *	coordinates, so if userspace rotates the picture to adjust for
  *	the orientation it must also apply the same transformation to the
- *	touchscreen input coordinates. This property is initialized by calling
+ *	touchscreen input coordinates. This property value is set by calling
  *	drm_connector_set_panel_orientation() or
  *	drm_connector_set_panel_orientation_with_quirk()
  *
@@ -2341,8 +2341,8 @@ EXPORT_SYMBOL(drm_connector_set_vrr_capable_property);
  * @connector: connector for which to set the panel-orientation property.
  * @panel_orientation: drm_panel_orientation value to set
  *
- * This function sets the connector's panel_orientation and attaches
- * a "panel orientation" property to the connector.
+ * This function sets the connector's panel_orientation value. If the property
+ * doesn't exist, it will try to create one.
  *
  * Calling this function on a connector where the panel_orientation has
  * already been set is a no-op (e.g. the orientation has been overridden with
@@ -2373,19 +2373,12 @@ int drm_connector_set_panel_orientation(
 	info->panel_orientation = panel_orientation;
 
 	prop = dev->mode_config.panel_orientation_property;
-	if (!prop) {
-		prop = drm_property_create_enum(dev, DRM_MODE_PROP_IMMUTABLE,
-				"panel orientation",
-				drm_panel_orientation_enum_list,
-				ARRAY_SIZE(drm_panel_orientation_enum_list));
-		if (!prop)
-			return -ENOMEM;
-
-		dev->mode_config.panel_orientation_property = prop;
-	}
+	if (!prop &&
+	    drm_connector_init_panel_orientation_property(connector) < 0)
+		return -ENOMEM;
 
-	drm_object_attach_property(&connector->base, prop,
-				   info->panel_orientation);
+	drm_object_property_set_value(&connector->base, prop,
+				      info->panel_orientation);
 	return 0;
 }
 EXPORT_SYMBOL(drm_connector_set_panel_orientation);
@@ -2393,7 +2386,7 @@ EXPORT_SYMBOL(drm_connector_set_panel_orientation);
 /**
  * drm_connector_set_panel_orientation_with_quirk - set the
  *	connector's panel_orientation after checking for quirks
- * @connector: connector for which to init the panel-orientation property.
+ * @connector: connector for which to set the panel-orientation property.
  * @panel_orientation: drm_panel_orientation value to set
  * @width: width in pixels of the panel, used for panel quirk detection
  * @height: height in pixels of the panel, used for panel quirk detection
@@ -2420,6 +2413,43 @@ int drm_connector_set_panel_orientation_with_quirk(
 }
 EXPORT_SYMBOL(drm_connector_set_panel_orientation_with_quirk);
 
+/**
+ * drm_connector_init_panel_orientation_property -
+ * 	create the connector's panel orientation property
+ *
+ * This function attaches a "panel orientation" property to the connector
+ * and initializes its value to DRM_MODE_PANEL_ORIENTATION_UNKNOWN.
+ *
+ * The value of the property can be set by drm_connector_set_panel_orientation()
+ * or drm_connector_set_panel_orientation_with_quirk() later.
+ *
+ * Returns:
+ * Zero on success, negative errno on failure.
+ */
+int drm_connector_init_panel_orientation_property(
+	struct drm_connector *connector)
+{
+	struct drm_device *dev = connector->dev;
+	struct drm_property *prop;
+
+	if(dev->mode_config.panel_orientation_property)
+		return 0;
+
+	prop = drm_property_create_enum(dev, DRM_MODE_PROP_IMMUTABLE,
+			"panel orientation",
+			drm_panel_orientation_enum_list,
+			ARRAY_SIZE(drm_panel_orientation_enum_list));
+	if (!prop)
+		return -ENOMEM;
+
+	dev->mode_config.panel_orientation_property = prop;
+	drm_object_attach_property(&connector->base, prop,
+				   DRM_MODE_PANEL_ORIENTATION_UNKNOWN);
+
+	return 0;
+}
+EXPORT_SYMBOL(drm_connector_init_panel_orientation_property);
+
 static const struct drm_prop_enum_list privacy_screen_enum[] = {
 	{ PRIVACY_SCREEN_DISABLED,		"Disabled" },
 	{ PRIVACY_SCREEN_ENABLED,		"Enabled" },
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 64cf5f88c05b6a..d3448a71bb4d85 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -1798,6 +1798,8 @@ int drm_connector_set_panel_orientation_with_quirk(
 	struct drm_connector *connector,
 	enum drm_panel_orientation panel_orientation,
 	int width, int height);
+int drm_connector_init_panel_orientation_property(
+	struct drm_connector *connector);
 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);
-- 
2.35.0.263.gb82422642f-goog

[PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Hsin-Yi Wang]

drm_dev_register() sets connector->registration_state to
DRM_CONNECTOR_REGISTERED and dev->registered to true. If
drm_connector_set_panel_orientation() is first called after
drm_dev_register(), it will fail several checks and results in following
warning.

Add a function to create panel orientation property and set default value
to UNKNOWN, so drivers can call this function to init the property earlier
, and let the panel set the real value later.

[    4.480976] ------------[ cut here ]------------
[    4.485603] WARNING: CPU: 5 PID: 369 at drivers/gpu/drm/drm_mode_object.c:45 __drm_mode_object_add+0xb4/0xbc
<snip>
[    4.609772] Call trace:
[    4.612208]  __drm_mode_object_add+0xb4/0xbc
[    4.616466]  drm_mode_object_add+0x20/0x2c
[    4.620552]  drm_property_create+0xdc/0x174
[    4.624723]  drm_property_create_enum+0x34/0x98
[    4.629241]  drm_connector_set_panel_orientation+0x64/0xa0
[    4.634716]  boe_panel_get_modes+0x88/0xd8
[    4.638802]  drm_panel_get_modes+0x2c/0x48
[    4.642887]  panel_bridge_get_modes+0x1c/0x28
[    4.647233]  drm_bridge_connector_get_modes+0xa0/0xd4
[    4.652273]  drm_helper_probe_single_connector_modes+0x218/0x700
[    4.658266]  drm_mode_getconnector+0x1b4/0x45c
[    4.662699]  drm_ioctl_kernel+0xac/0x128
[    4.666611]  drm_ioctl+0x268/0x410
[    4.670002]  drm_compat_ioctl+0xdc/0xf0
[    4.673829]  __arm64_compat_sys_ioctl+0xc8/0x100
[    4.678436]  el0_svc_common+0xf4/0x1c0
[    4.682174]  do_el0_svc_compat+0x28/0x3c
[    4.686088]  el0_svc_compat+0x10/0x1c
[    4.689738]  el0_sync_compat_handler+0xa8/0xcc
[    4.694171]  el0_sync_compat+0x178/0x180
[    4.698082] ---[ end trace b4f2db9d9c88610b ]---
[    4.702721] ------------[ cut here ]------------
[    4.707329] WARNING: CPU: 5 PID: 369 at drivers/gpu/drm/drm_mode_object.c:243 drm_object_attach_property+0x48/0xb8
<snip>
[    4.833830] Call trace:
[    4.836266]  drm_object_attach_property+0x48/0xb8
[    4.840958]  drm_connector_set_panel_orientation+0x84/0xa0
[    4.846432]  boe_panel_get_modes+0x88/0xd8
[    4.850516]  drm_panel_get_modes+0x2c/0x48
[    4.854600]  panel_bridge_get_modes+0x1c/0x28
[    4.858946]  drm_bridge_connector_get_modes+0xa0/0xd4
[    4.863984]  drm_helper_probe_single_connector_modes+0x218/0x700
[    4.869978]  drm_mode_getconnector+0x1b4/0x45c
[    4.874410]  drm_ioctl_kernel+0xac/0x128
[    4.878320]  drm_ioctl+0x268/0x410
[    4.881711]  drm_compat_ioctl+0xdc/0xf0
[    4.885536]  __arm64_compat_sys_ioctl+0xc8/0x100
[    4.890142]  el0_svc_common+0xf4/0x1c0
[    4.893879]  do_el0_svc_compat+0x28/0x3c
[    4.897791]  el0_svc_compat+0x10/0x1c
[    4.901441]  el0_sync_compat_handler+0xa8/0xcc
[    4.905873]  el0_sync_compat+0x178/0x180
[    4.909783] ---[ end trace b4f2db9d9c88610c ]---

Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
---
v7->v8:
- check if the prop is created to avoid leak issue when called multiple
  times.
- attempt to create prop in drm_connector_set_panel_orientation if prop
  is not created before, so driver don't need to call
  drm_connector_init_panel_orientation_property if they don't need to
  set the property earlier.
---
 drivers/gpu/drm/drm_connector.c | 62 ++++++++++++++++++++++++---------
 include/drm/drm_connector.h     |  2 ++
 2 files changed, 48 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index a50c82bc2b2fec..572ead7ac10690 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1252,7 +1252,7 @@ static const struct drm_prop_enum_list dp_colorspaces[] = {
  *	INPUT_PROP_DIRECT) will still map 1:1 to the actual LCD panel
  *	coordinates, so if userspace rotates the picture to adjust for
  *	the orientation it must also apply the same transformation to the
- *	touchscreen input coordinates. This property is initialized by calling
+ *	touchscreen input coordinates. This property value is set by calling
  *	drm_connector_set_panel_orientation() or
  *	drm_connector_set_panel_orientation_with_quirk()
  *
@@ -2341,8 +2341,8 @@ EXPORT_SYMBOL(drm_connector_set_vrr_capable_property);
  * @connector: connector for which to set the panel-orientation property.
  * @panel_orientation: drm_panel_orientation value to set
  *
- * This function sets the connector's panel_orientation and attaches
- * a "panel orientation" property to the connector.
+ * This function sets the connector's panel_orientation value. If the property
+ * doesn't exist, it will try to create one.
  *
  * Calling this function on a connector where the panel_orientation has
  * already been set is a no-op (e.g. the orientation has been overridden with
@@ -2373,19 +2373,12 @@ int drm_connector_set_panel_orientation(
 	info->panel_orientation = panel_orientation;
 
 	prop = dev->mode_config.panel_orientation_property;
-	if (!prop) {
-		prop = drm_property_create_enum(dev, DRM_MODE_PROP_IMMUTABLE,
-				"panel orientation",
-				drm_panel_orientation_enum_list,
-				ARRAY_SIZE(drm_panel_orientation_enum_list));
-		if (!prop)
-			return -ENOMEM;
-
-		dev->mode_config.panel_orientation_property = prop;
-	}
+	if (!prop &&
+	    drm_connector_init_panel_orientation_property(connector) < 0)
+		return -ENOMEM;
 
-	drm_object_attach_property(&connector->base, prop,
-				   info->panel_orientation);
+	drm_object_property_set_value(&connector->base, prop,
+				      info->panel_orientation);
 	return 0;
 }
 EXPORT_SYMBOL(drm_connector_set_panel_orientation);
@@ -2393,7 +2386,7 @@ EXPORT_SYMBOL(drm_connector_set_panel_orientation);
 /**
  * drm_connector_set_panel_orientation_with_quirk - set the
  *	connector's panel_orientation after checking for quirks
- * @connector: connector for which to init the panel-orientation property.
+ * @connector: connector for which to set the panel-orientation property.
  * @panel_orientation: drm_panel_orientation value to set
  * @width: width in pixels of the panel, used for panel quirk detection
  * @height: height in pixels of the panel, used for panel quirk detection
@@ -2420,6 +2413,43 @@ int drm_connector_set_panel_orientation_with_quirk(
 }
 EXPORT_SYMBOL(drm_connector_set_panel_orientation_with_quirk);
 
+/**
+ * drm_connector_init_panel_orientation_property -
+ * 	create the connector's panel orientation property
+ *
+ * This function attaches a "panel orientation" property to the connector
+ * and initializes its value to DRM_MODE_PANEL_ORIENTATION_UNKNOWN.
+ *
+ * The value of the property can be set by drm_connector_set_panel_orientation()
+ * or drm_connector_set_panel_orientation_with_quirk() later.
+ *
+ * Returns:
+ * Zero on success, negative errno on failure.
+ */
+int drm_connector_init_panel_orientation_property(
+	struct drm_connector *connector)
+{
+	struct drm_device *dev = connector->dev;
+	struct drm_property *prop;
+
+	if(dev->mode_config.panel_orientation_property)
+		return 0;
+
+	prop = drm_property_create_enum(dev, DRM_MODE_PROP_IMMUTABLE,
+			"panel orientation",
+			drm_panel_orientation_enum_list,
+			ARRAY_SIZE(drm_panel_orientation_enum_list));
+	if (!prop)
+		return -ENOMEM;
+
+	dev->mode_config.panel_orientation_property = prop;
+	drm_object_attach_property(&connector->base, prop,
+				   DRM_MODE_PANEL_ORIENTATION_UNKNOWN);
+
+	return 0;
+}
+EXPORT_SYMBOL(drm_connector_init_panel_orientation_property);
+
 static const struct drm_prop_enum_list privacy_screen_enum[] = {
 	{ PRIVACY_SCREEN_DISABLED,		"Disabled" },
 	{ PRIVACY_SCREEN_ENABLED,		"Enabled" },
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 64cf5f88c05b6a..d3448a71bb4d85 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -1798,6 +1798,8 @@ int drm_connector_set_panel_orientation_with_quirk(
 	struct drm_connector *connector,
 	enum drm_panel_orientation panel_orientation,
 	int width, int height);
+int drm_connector_init_panel_orientation_property(
+	struct drm_connector *connector);
 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);
-- 
2.35.0.263.gb82422642f-goog

[Intel-gfx] [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Hsin-Yi Wang]

drm_dev_register() sets connector->registration_state to
DRM_CONNECTOR_REGISTERED and dev->registered to true. If
drm_connector_set_panel_orientation() is first called after
drm_dev_register(), it will fail several checks and results in following
warning.

Add a function to create panel orientation property and set default value
to UNKNOWN, so drivers can call this function to init the property earlier
, and let the panel set the real value later.

[    4.480976] ------------[ cut here ]------------
[    4.485603] WARNING: CPU: 5 PID: 369 at drivers/gpu/drm/drm_mode_object.c:45 __drm_mode_object_add+0xb4/0xbc
<snip>
[    4.609772] Call trace:
[    4.612208]  __drm_mode_object_add+0xb4/0xbc
[    4.616466]  drm_mode_object_add+0x20/0x2c
[    4.620552]  drm_property_create+0xdc/0x174
[    4.624723]  drm_property_create_enum+0x34/0x98
[    4.629241]  drm_connector_set_panel_orientation+0x64/0xa0
[    4.634716]  boe_panel_get_modes+0x88/0xd8
[    4.638802]  drm_panel_get_modes+0x2c/0x48
[    4.642887]  panel_bridge_get_modes+0x1c/0x28
[    4.647233]  drm_bridge_connector_get_modes+0xa0/0xd4
[    4.652273]  drm_helper_probe_single_connector_modes+0x218/0x700
[    4.658266]  drm_mode_getconnector+0x1b4/0x45c
[    4.662699]  drm_ioctl_kernel+0xac/0x128
[    4.666611]  drm_ioctl+0x268/0x410
[    4.670002]  drm_compat_ioctl+0xdc/0xf0
[    4.673829]  __arm64_compat_sys_ioctl+0xc8/0x100
[    4.678436]  el0_svc_common+0xf4/0x1c0
[    4.682174]  do_el0_svc_compat+0x28/0x3c
[    4.686088]  el0_svc_compat+0x10/0x1c
[    4.689738]  el0_sync_compat_handler+0xa8/0xcc
[    4.694171]  el0_sync_compat+0x178/0x180
[    4.698082] ---[ end trace b4f2db9d9c88610b ]---
[    4.702721] ------------[ cut here ]------------
[    4.707329] WARNING: CPU: 5 PID: 369 at drivers/gpu/drm/drm_mode_object.c:243 drm_object_attach_property+0x48/0xb8
<snip>
[    4.833830] Call trace:
[    4.836266]  drm_object_attach_property+0x48/0xb8
[    4.840958]  drm_connector_set_panel_orientation+0x84/0xa0
[    4.846432]  boe_panel_get_modes+0x88/0xd8
[    4.850516]  drm_panel_get_modes+0x2c/0x48
[    4.854600]  panel_bridge_get_modes+0x1c/0x28
[    4.858946]  drm_bridge_connector_get_modes+0xa0/0xd4
[    4.863984]  drm_helper_probe_single_connector_modes+0x218/0x700
[    4.869978]  drm_mode_getconnector+0x1b4/0x45c
[    4.874410]  drm_ioctl_kernel+0xac/0x128
[    4.878320]  drm_ioctl+0x268/0x410
[    4.881711]  drm_compat_ioctl+0xdc/0xf0
[    4.885536]  __arm64_compat_sys_ioctl+0xc8/0x100
[    4.890142]  el0_svc_common+0xf4/0x1c0
[    4.893879]  do_el0_svc_compat+0x28/0x3c
[    4.897791]  el0_svc_compat+0x10/0x1c
[    4.901441]  el0_sync_compat_handler+0xa8/0xcc
[    4.905873]  el0_sync_compat+0x178/0x180
[    4.909783] ---[ end trace b4f2db9d9c88610c ]---

Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
---
v7->v8:
- check if the prop is created to avoid leak issue when called multiple
  times.
- attempt to create prop in drm_connector_set_panel_orientation if prop
  is not created before, so driver don't need to call
  drm_connector_init_panel_orientation_property if they don't need to
  set the property earlier.
---
 drivers/gpu/drm/drm_connector.c | 62 ++++++++++++++++++++++++---------
 include/drm/drm_connector.h     |  2 ++
 2 files changed, 48 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index a50c82bc2b2fec..572ead7ac10690 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1252,7 +1252,7 @@ static const struct drm_prop_enum_list dp_colorspaces[] = {
  *	INPUT_PROP_DIRECT) will still map 1:1 to the actual LCD panel
  *	coordinates, so if userspace rotates the picture to adjust for
  *	the orientation it must also apply the same transformation to the
- *	touchscreen input coordinates. This property is initialized by calling
+ *	touchscreen input coordinates. This property value is set by calling
  *	drm_connector_set_panel_orientation() or
  *	drm_connector_set_panel_orientation_with_quirk()
  *
@@ -2341,8 +2341,8 @@ EXPORT_SYMBOL(drm_connector_set_vrr_capable_property);
  * @connector: connector for which to set the panel-orientation property.
  * @panel_orientation: drm_panel_orientation value to set
  *
- * This function sets the connector's panel_orientation and attaches
- * a "panel orientation" property to the connector.
+ * This function sets the connector's panel_orientation value. If the property
+ * doesn't exist, it will try to create one.
  *
  * Calling this function on a connector where the panel_orientation has
  * already been set is a no-op (e.g. the orientation has been overridden with
@@ -2373,19 +2373,12 @@ int drm_connector_set_panel_orientation(
 	info->panel_orientation = panel_orientation;
 
 	prop = dev->mode_config.panel_orientation_property;
-	if (!prop) {
-		prop = drm_property_create_enum(dev, DRM_MODE_PROP_IMMUTABLE,
-				"panel orientation",
-				drm_panel_orientation_enum_list,
-				ARRAY_SIZE(drm_panel_orientation_enum_list));
-		if (!prop)
-			return -ENOMEM;
-
-		dev->mode_config.panel_orientation_property = prop;
-	}
+	if (!prop &&
+	    drm_connector_init_panel_orientation_property(connector) < 0)
+		return -ENOMEM;
 
-	drm_object_attach_property(&connector->base, prop,
-				   info->panel_orientation);
+	drm_object_property_set_value(&connector->base, prop,
+				      info->panel_orientation);
 	return 0;
 }
 EXPORT_SYMBOL(drm_connector_set_panel_orientation);
@@ -2393,7 +2386,7 @@ EXPORT_SYMBOL(drm_connector_set_panel_orientation);
 /**
  * drm_connector_set_panel_orientation_with_quirk - set the
  *	connector's panel_orientation after checking for quirks
- * @connector: connector for which to init the panel-orientation property.
+ * @connector: connector for which to set the panel-orientation property.
  * @panel_orientation: drm_panel_orientation value to set
  * @width: width in pixels of the panel, used for panel quirk detection
  * @height: height in pixels of the panel, used for panel quirk detection
@@ -2420,6 +2413,43 @@ int drm_connector_set_panel_orientation_with_quirk(
 }
 EXPORT_SYMBOL(drm_connector_set_panel_orientation_with_quirk);
 
+/**
+ * drm_connector_init_panel_orientation_property -
+ * 	create the connector's panel orientation property
+ *
+ * This function attaches a "panel orientation" property to the connector
+ * and initializes its value to DRM_MODE_PANEL_ORIENTATION_UNKNOWN.
+ *
+ * The value of the property can be set by drm_connector_set_panel_orientation()
+ * or drm_connector_set_panel_orientation_with_quirk() later.
+ *
+ * Returns:
+ * Zero on success, negative errno on failure.
+ */
+int drm_connector_init_panel_orientation_property(
+	struct drm_connector *connector)
+{
+	struct drm_device *dev = connector->dev;
+	struct drm_property *prop;
+
+	if(dev->mode_config.panel_orientation_property)
+		return 0;
+
+	prop = drm_property_create_enum(dev, DRM_MODE_PROP_IMMUTABLE,
+			"panel orientation",
+			drm_panel_orientation_enum_list,
+			ARRAY_SIZE(drm_panel_orientation_enum_list));
+	if (!prop)
+		return -ENOMEM;
+
+	dev->mode_config.panel_orientation_property = prop;
+	drm_object_attach_property(&connector->base, prop,
+				   DRM_MODE_PANEL_ORIENTATION_UNKNOWN);
+
+	return 0;
+}
+EXPORT_SYMBOL(drm_connector_init_panel_orientation_property);
+
 static const struct drm_prop_enum_list privacy_screen_enum[] = {
 	{ PRIVACY_SCREEN_DISABLED,		"Disabled" },
 	{ PRIVACY_SCREEN_ENABLED,		"Enabled" },
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 64cf5f88c05b6a..d3448a71bb4d85 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -1798,6 +1798,8 @@ int drm_connector_set_panel_orientation_with_quirk(
 	struct drm_connector *connector,
 	enum drm_panel_orientation panel_orientation,
 	int width, int height);
+int drm_connector_init_panel_orientation_property(
+	struct drm_connector *connector);
 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);
-- 
2.35.0.263.gb82422642f-goog

[PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Hsin-Yi Wang]

drm_dev_register() sets connector->registration_state to
DRM_CONNECTOR_REGISTERED and dev->registered to true. If
drm_connector_set_panel_orientation() is first called after
drm_dev_register(), it will fail several checks and results in following
warning.

Add a function to create panel orientation property and set default value
to UNKNOWN, so drivers can call this function to init the property earlier
, and let the panel set the real value later.

[    4.480976] ------------[ cut here ]------------
[    4.485603] WARNING: CPU: 5 PID: 369 at drivers/gpu/drm/drm_mode_object.c:45 __drm_mode_object_add+0xb4/0xbc
<snip>
[    4.609772] Call trace:
[    4.612208]  __drm_mode_object_add+0xb4/0xbc
[    4.616466]  drm_mode_object_add+0x20/0x2c
[    4.620552]  drm_property_create+0xdc/0x174
[    4.624723]  drm_property_create_enum+0x34/0x98
[    4.629241]  drm_connector_set_panel_orientation+0x64/0xa0
[    4.634716]  boe_panel_get_modes+0x88/0xd8
[    4.638802]  drm_panel_get_modes+0x2c/0x48
[    4.642887]  panel_bridge_get_modes+0x1c/0x28
[    4.647233]  drm_bridge_connector_get_modes+0xa0/0xd4
[    4.652273]  drm_helper_probe_single_connector_modes+0x218/0x700
[    4.658266]  drm_mode_getconnector+0x1b4/0x45c
[    4.662699]  drm_ioctl_kernel+0xac/0x128
[    4.666611]  drm_ioctl+0x268/0x410
[    4.670002]  drm_compat_ioctl+0xdc/0xf0
[    4.673829]  __arm64_compat_sys_ioctl+0xc8/0x100
[    4.678436]  el0_svc_common+0xf4/0x1c0
[    4.682174]  do_el0_svc_compat+0x28/0x3c
[    4.686088]  el0_svc_compat+0x10/0x1c
[    4.689738]  el0_sync_compat_handler+0xa8/0xcc
[    4.694171]  el0_sync_compat+0x178/0x180
[    4.698082] ---[ end trace b4f2db9d9c88610b ]---
[    4.702721] ------------[ cut here ]------------
[    4.707329] WARNING: CPU: 5 PID: 369 at drivers/gpu/drm/drm_mode_object.c:243 drm_object_attach_property+0x48/0xb8
<snip>
[    4.833830] Call trace:
[    4.836266]  drm_object_attach_property+0x48/0xb8
[    4.840958]  drm_connector_set_panel_orientation+0x84/0xa0
[    4.846432]  boe_panel_get_modes+0x88/0xd8
[    4.850516]  drm_panel_get_modes+0x2c/0x48
[    4.854600]  panel_bridge_get_modes+0x1c/0x28
[    4.858946]  drm_bridge_connector_get_modes+0xa0/0xd4
[    4.863984]  drm_helper_probe_single_connector_modes+0x218/0x700
[    4.869978]  drm_mode_getconnector+0x1b4/0x45c
[    4.874410]  drm_ioctl_kernel+0xac/0x128
[    4.878320]  drm_ioctl+0x268/0x410
[    4.881711]  drm_compat_ioctl+0xdc/0xf0
[    4.885536]  __arm64_compat_sys_ioctl+0xc8/0x100
[    4.890142]  el0_svc_common+0xf4/0x1c0
[    4.893879]  do_el0_svc_compat+0x28/0x3c
[    4.897791]  el0_svc_compat+0x10/0x1c
[    4.901441]  el0_sync_compat_handler+0xa8/0xcc
[    4.905873]  el0_sync_compat+0x178/0x180
[    4.909783] ---[ end trace b4f2db9d9c88610c ]---

Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
---
v7->v8:
- check if the prop is created to avoid leak issue when called multiple
  times.
- attempt to create prop in drm_connector_set_panel_orientation if prop
  is not created before, so driver don't need to call
  drm_connector_init_panel_orientation_property if they don't need to
  set the property earlier.
---
 drivers/gpu/drm/drm_connector.c | 62 ++++++++++++++++++++++++---------
 include/drm/drm_connector.h     |  2 ++
 2 files changed, 48 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index a50c82bc2b2fec..572ead7ac10690 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1252,7 +1252,7 @@ static const struct drm_prop_enum_list dp_colorspaces[] = {
  *	INPUT_PROP_DIRECT) will still map 1:1 to the actual LCD panel
  *	coordinates, so if userspace rotates the picture to adjust for
  *	the orientation it must also apply the same transformation to the
- *	touchscreen input coordinates. This property is initialized by calling
+ *	touchscreen input coordinates. This property value is set by calling
  *	drm_connector_set_panel_orientation() or
  *	drm_connector_set_panel_orientation_with_quirk()
  *
@@ -2341,8 +2341,8 @@ EXPORT_SYMBOL(drm_connector_set_vrr_capable_property);
  * @connector: connector for which to set the panel-orientation property.
  * @panel_orientation: drm_panel_orientation value to set
  *
- * This function sets the connector's panel_orientation and attaches
- * a "panel orientation" property to the connector.
+ * This function sets the connector's panel_orientation value. If the property
+ * doesn't exist, it will try to create one.
  *
  * Calling this function on a connector where the panel_orientation has
  * already been set is a no-op (e.g. the orientation has been overridden with
@@ -2373,19 +2373,12 @@ int drm_connector_set_panel_orientation(
 	info->panel_orientation = panel_orientation;
 
 	prop = dev->mode_config.panel_orientation_property;
-	if (!prop) {
-		prop = drm_property_create_enum(dev, DRM_MODE_PROP_IMMUTABLE,
-				"panel orientation",
-				drm_panel_orientation_enum_list,
-				ARRAY_SIZE(drm_panel_orientation_enum_list));
-		if (!prop)
-			return -ENOMEM;
-
-		dev->mode_config.panel_orientation_property = prop;
-	}
+	if (!prop &&
+	    drm_connector_init_panel_orientation_property(connector) < 0)
+		return -ENOMEM;
 
-	drm_object_attach_property(&connector->base, prop,
-				   info->panel_orientation);
+	drm_object_property_set_value(&connector->base, prop,
+				      info->panel_orientation);
 	return 0;
 }
 EXPORT_SYMBOL(drm_connector_set_panel_orientation);
@@ -2393,7 +2386,7 @@ EXPORT_SYMBOL(drm_connector_set_panel_orientation);
 /**
  * drm_connector_set_panel_orientation_with_quirk - set the
  *	connector's panel_orientation after checking for quirks
- * @connector: connector for which to init the panel-orientation property.
+ * @connector: connector for which to set the panel-orientation property.
  * @panel_orientation: drm_panel_orientation value to set
  * @width: width in pixels of the panel, used for panel quirk detection
  * @height: height in pixels of the panel, used for panel quirk detection
@@ -2420,6 +2413,43 @@ int drm_connector_set_panel_orientation_with_quirk(
 }
 EXPORT_SYMBOL(drm_connector_set_panel_orientation_with_quirk);
 
+/**
+ * drm_connector_init_panel_orientation_property -
+ * 	create the connector's panel orientation property
+ *
+ * This function attaches a "panel orientation" property to the connector
+ * and initializes its value to DRM_MODE_PANEL_ORIENTATION_UNKNOWN.
+ *
+ * The value of the property can be set by drm_connector_set_panel_orientation()
+ * or drm_connector_set_panel_orientation_with_quirk() later.
+ *
+ * Returns:
+ * Zero on success, negative errno on failure.
+ */
+int drm_connector_init_panel_orientation_property(
+	struct drm_connector *connector)
+{
+	struct drm_device *dev = connector->dev;
+	struct drm_property *prop;
+
+	if(dev->mode_config.panel_orientation_property)
+		return 0;
+
+	prop = drm_property_create_enum(dev, DRM_MODE_PROP_IMMUTABLE,
+			"panel orientation",
+			drm_panel_orientation_enum_list,
+			ARRAY_SIZE(drm_panel_orientation_enum_list));
+	if (!prop)
+		return -ENOMEM;
+
+	dev->mode_config.panel_orientation_property = prop;
+	drm_object_attach_property(&connector->base, prop,
+				   DRM_MODE_PANEL_ORIENTATION_UNKNOWN);
+
+	return 0;
+}
+EXPORT_SYMBOL(drm_connector_init_panel_orientation_property);
+
 static const struct drm_prop_enum_list privacy_screen_enum[] = {
 	{ PRIVACY_SCREEN_DISABLED,		"Disabled" },
 	{ PRIVACY_SCREEN_ENABLED,		"Enabled" },
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 64cf5f88c05b6a..d3448a71bb4d85 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -1798,6 +1798,8 @@ int drm_connector_set_panel_orientation_with_quirk(
 	struct drm_connector *connector,
 	enum drm_panel_orientation panel_orientation,
 	int width, int height);
+int drm_connector_init_panel_orientation_property(
+	struct drm_connector *connector);
 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);
-- 
2.35.0.263.gb82422642f-goog


_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

[PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Hsin-Yi Wang]

drm_dev_register() sets connector->registration_state to
DRM_CONNECTOR_REGISTERED and dev->registered to true. If
drm_connector_set_panel_orientation() is first called after
drm_dev_register(), it will fail several checks and results in following
warning.

Add a function to create panel orientation property and set default value
to UNKNOWN, so drivers can call this function to init the property earlier
, and let the panel set the real value later.

[    4.480976] ------------[ cut here ]------------
[    4.485603] WARNING: CPU: 5 PID: 369 at drivers/gpu/drm/drm_mode_object.c:45 __drm_mode_object_add+0xb4/0xbc
<snip>
[    4.609772] Call trace:
[    4.612208]  __drm_mode_object_add+0xb4/0xbc
[    4.616466]  drm_mode_object_add+0x20/0x2c
[    4.620552]  drm_property_create+0xdc/0x174
[    4.624723]  drm_property_create_enum+0x34/0x98
[    4.629241]  drm_connector_set_panel_orientation+0x64/0xa0
[    4.634716]  boe_panel_get_modes+0x88/0xd8
[    4.638802]  drm_panel_get_modes+0x2c/0x48
[    4.642887]  panel_bridge_get_modes+0x1c/0x28
[    4.647233]  drm_bridge_connector_get_modes+0xa0/0xd4
[    4.652273]  drm_helper_probe_single_connector_modes+0x218/0x700
[    4.658266]  drm_mode_getconnector+0x1b4/0x45c
[    4.662699]  drm_ioctl_kernel+0xac/0x128
[    4.666611]  drm_ioctl+0x268/0x410
[    4.670002]  drm_compat_ioctl+0xdc/0xf0
[    4.673829]  __arm64_compat_sys_ioctl+0xc8/0x100
[    4.678436]  el0_svc_common+0xf4/0x1c0
[    4.682174]  do_el0_svc_compat+0x28/0x3c
[    4.686088]  el0_svc_compat+0x10/0x1c
[    4.689738]  el0_sync_compat_handler+0xa8/0xcc
[    4.694171]  el0_sync_compat+0x178/0x180
[    4.698082] ---[ end trace b4f2db9d9c88610b ]---
[    4.702721] ------------[ cut here ]------------
[    4.707329] WARNING: CPU: 5 PID: 369 at drivers/gpu/drm/drm_mode_object.c:243 drm_object_attach_property+0x48/0xb8
<snip>
[    4.833830] Call trace:
[    4.836266]  drm_object_attach_property+0x48/0xb8
[    4.840958]  drm_connector_set_panel_orientation+0x84/0xa0
[    4.846432]  boe_panel_get_modes+0x88/0xd8
[    4.850516]  drm_panel_get_modes+0x2c/0x48
[    4.854600]  panel_bridge_get_modes+0x1c/0x28
[    4.858946]  drm_bridge_connector_get_modes+0xa0/0xd4
[    4.863984]  drm_helper_probe_single_connector_modes+0x218/0x700
[    4.869978]  drm_mode_getconnector+0x1b4/0x45c
[    4.874410]  drm_ioctl_kernel+0xac/0x128
[    4.878320]  drm_ioctl+0x268/0x410
[    4.881711]  drm_compat_ioctl+0xdc/0xf0
[    4.885536]  __arm64_compat_sys_ioctl+0xc8/0x100
[    4.890142]  el0_svc_common+0xf4/0x1c0
[    4.893879]  do_el0_svc_compat+0x28/0x3c
[    4.897791]  el0_svc_compat+0x10/0x1c
[    4.901441]  el0_sync_compat_handler+0xa8/0xcc
[    4.905873]  el0_sync_compat+0x178/0x180
[    4.909783] ---[ end trace b4f2db9d9c88610c ]---

Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
---
v7->v8:
- check if the prop is created to avoid leak issue when called multiple
  times.
- attempt to create prop in drm_connector_set_panel_orientation if prop
  is not created before, so driver don't need to call
  drm_connector_init_panel_orientation_property if they don't need to
  set the property earlier.
---
 drivers/gpu/drm/drm_connector.c | 62 ++++++++++++++++++++++++---------
 include/drm/drm_connector.h     |  2 ++
 2 files changed, 48 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index a50c82bc2b2fec..572ead7ac10690 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1252,7 +1252,7 @@ static const struct drm_prop_enum_list dp_colorspaces[] = {
  *	INPUT_PROP_DIRECT) will still map 1:1 to the actual LCD panel
  *	coordinates, so if userspace rotates the picture to adjust for
  *	the orientation it must also apply the same transformation to the
- *	touchscreen input coordinates. This property is initialized by calling
+ *	touchscreen input coordinates. This property value is set by calling
  *	drm_connector_set_panel_orientation() or
  *	drm_connector_set_panel_orientation_with_quirk()
  *
@@ -2341,8 +2341,8 @@ EXPORT_SYMBOL(drm_connector_set_vrr_capable_property);
  * @connector: connector for which to set the panel-orientation property.
  * @panel_orientation: drm_panel_orientation value to set
  *
- * This function sets the connector's panel_orientation and attaches
- * a "panel orientation" property to the connector.
+ * This function sets the connector's panel_orientation value. If the property
+ * doesn't exist, it will try to create one.
  *
  * Calling this function on a connector where the panel_orientation has
  * already been set is a no-op (e.g. the orientation has been overridden with
@@ -2373,19 +2373,12 @@ int drm_connector_set_panel_orientation(
 	info->panel_orientation = panel_orientation;
 
 	prop = dev->mode_config.panel_orientation_property;
-	if (!prop) {
-		prop = drm_property_create_enum(dev, DRM_MODE_PROP_IMMUTABLE,
-				"panel orientation",
-				drm_panel_orientation_enum_list,
-				ARRAY_SIZE(drm_panel_orientation_enum_list));
-		if (!prop)
-			return -ENOMEM;
-
-		dev->mode_config.panel_orientation_property = prop;
-	}
+	if (!prop &&
+	    drm_connector_init_panel_orientation_property(connector) < 0)
+		return -ENOMEM;
 
-	drm_object_attach_property(&connector->base, prop,
-				   info->panel_orientation);
+	drm_object_property_set_value(&connector->base, prop,
+				      info->panel_orientation);
 	return 0;
 }
 EXPORT_SYMBOL(drm_connector_set_panel_orientation);
@@ -2393,7 +2386,7 @@ EXPORT_SYMBOL(drm_connector_set_panel_orientation);
 /**
  * drm_connector_set_panel_orientation_with_quirk - set the
  *	connector's panel_orientation after checking for quirks
- * @connector: connector for which to init the panel-orientation property.
+ * @connector: connector for which to set the panel-orientation property.
  * @panel_orientation: drm_panel_orientation value to set
  * @width: width in pixels of the panel, used for panel quirk detection
  * @height: height in pixels of the panel, used for panel quirk detection
@@ -2420,6 +2413,43 @@ int drm_connector_set_panel_orientation_with_quirk(
 }
 EXPORT_SYMBOL(drm_connector_set_panel_orientation_with_quirk);
 
+/**
+ * drm_connector_init_panel_orientation_property -
+ * 	create the connector's panel orientation property
+ *
+ * This function attaches a "panel orientation" property to the connector
+ * and initializes its value to DRM_MODE_PANEL_ORIENTATION_UNKNOWN.
+ *
+ * The value of the property can be set by drm_connector_set_panel_orientation()
+ * or drm_connector_set_panel_orientation_with_quirk() later.
+ *
+ * Returns:
+ * Zero on success, negative errno on failure.
+ */
+int drm_connector_init_panel_orientation_property(
+	struct drm_connector *connector)
+{
+	struct drm_device *dev = connector->dev;
+	struct drm_property *prop;
+
+	if(dev->mode_config.panel_orientation_property)
+		return 0;
+
+	prop = drm_property_create_enum(dev, DRM_MODE_PROP_IMMUTABLE,
+			"panel orientation",
+			drm_panel_orientation_enum_list,
+			ARRAY_SIZE(drm_panel_orientation_enum_list));
+	if (!prop)
+		return -ENOMEM;
+
+	dev->mode_config.panel_orientation_property = prop;
+	drm_object_attach_property(&connector->base, prop,
+				   DRM_MODE_PANEL_ORIENTATION_UNKNOWN);
+
+	return 0;
+}
+EXPORT_SYMBOL(drm_connector_init_panel_orientation_property);
+
 static const struct drm_prop_enum_list privacy_screen_enum[] = {
 	{ PRIVACY_SCREEN_DISABLED,		"Disabled" },
 	{ PRIVACY_SCREEN_ENABLED,		"Enabled" },
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 64cf5f88c05b6a..d3448a71bb4d85 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -1798,6 +1798,8 @@ int drm_connector_set_panel_orientation_with_quirk(
 	struct drm_connector *connector,
 	enum drm_panel_orientation panel_orientation,
 	int width, int height);
+int drm_connector_init_panel_orientation_property(
+	struct drm_connector *connector);
 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);
-- 
2.35.0.263.gb82422642f-goog


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Hsin-Yi Wang]

drm_dev_register() sets connector->registration_state to
DRM_CONNECTOR_REGISTERED and dev->registered to true. If
drm_connector_set_panel_orientation() is first called after
drm_dev_register(), it will fail several checks and results in following
warning.

Add a function to create panel orientation property and set default value
to UNKNOWN, so drivers can call this function to init the property earlier
, and let the panel set the real value later.

[    4.480976] ------------[ cut here ]------------
[    4.485603] WARNING: CPU: 5 PID: 369 at drivers/gpu/drm/drm_mode_object.c:45 __drm_mode_object_add+0xb4/0xbc
<snip>
[    4.609772] Call trace:
[    4.612208]  __drm_mode_object_add+0xb4/0xbc
[    4.616466]  drm_mode_object_add+0x20/0x2c
[    4.620552]  drm_property_create+0xdc/0x174
[    4.624723]  drm_property_create_enum+0x34/0x98
[    4.629241]  drm_connector_set_panel_orientation+0x64/0xa0
[    4.634716]  boe_panel_get_modes+0x88/0xd8
[    4.638802]  drm_panel_get_modes+0x2c/0x48
[    4.642887]  panel_bridge_get_modes+0x1c/0x28
[    4.647233]  drm_bridge_connector_get_modes+0xa0/0xd4
[    4.652273]  drm_helper_probe_single_connector_modes+0x218/0x700
[    4.658266]  drm_mode_getconnector+0x1b4/0x45c
[    4.662699]  drm_ioctl_kernel+0xac/0x128
[    4.666611]  drm_ioctl+0x268/0x410
[    4.670002]  drm_compat_ioctl+0xdc/0xf0
[    4.673829]  __arm64_compat_sys_ioctl+0xc8/0x100
[    4.678436]  el0_svc_common+0xf4/0x1c0
[    4.682174]  do_el0_svc_compat+0x28/0x3c
[    4.686088]  el0_svc_compat+0x10/0x1c
[    4.689738]  el0_sync_compat_handler+0xa8/0xcc
[    4.694171]  el0_sync_compat+0x178/0x180
[    4.698082] ---[ end trace b4f2db9d9c88610b ]---
[    4.702721] ------------[ cut here ]------------
[    4.707329] WARNING: CPU: 5 PID: 369 at drivers/gpu/drm/drm_mode_object.c:243 drm_object_attach_property+0x48/0xb8
<snip>
[    4.833830] Call trace:
[    4.836266]  drm_object_attach_property+0x48/0xb8
[    4.840958]  drm_connector_set_panel_orientation+0x84/0xa0
[    4.846432]  boe_panel_get_modes+0x88/0xd8
[    4.850516]  drm_panel_get_modes+0x2c/0x48
[    4.854600]  panel_bridge_get_modes+0x1c/0x28
[    4.858946]  drm_bridge_connector_get_modes+0xa0/0xd4
[    4.863984]  drm_helper_probe_single_connector_modes+0x218/0x700
[    4.869978]  drm_mode_getconnector+0x1b4/0x45c
[    4.874410]  drm_ioctl_kernel+0xac/0x128
[    4.878320]  drm_ioctl+0x268/0x410
[    4.881711]  drm_compat_ioctl+0xdc/0xf0
[    4.885536]  __arm64_compat_sys_ioctl+0xc8/0x100
[    4.890142]  el0_svc_common+0xf4/0x1c0
[    4.893879]  do_el0_svc_compat+0x28/0x3c
[    4.897791]  el0_svc_compat+0x10/0x1c
[    4.901441]  el0_sync_compat_handler+0xa8/0xcc
[    4.905873]  el0_sync_compat+0x178/0x180
[    4.909783] ---[ end trace b4f2db9d9c88610c ]---

Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
---
v7->v8:
- check if the prop is created to avoid leak issue when called multiple
  times.
- attempt to create prop in drm_connector_set_panel_orientation if prop
  is not created before, so driver don't need to call
  drm_connector_init_panel_orientation_property if they don't need to
  set the property earlier.
---
 drivers/gpu/drm/drm_connector.c | 62 ++++++++++++++++++++++++---------
 include/drm/drm_connector.h     |  2 ++
 2 files changed, 48 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index a50c82bc2b2fec..572ead7ac10690 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1252,7 +1252,7 @@ static const struct drm_prop_enum_list dp_colorspaces[] = {
  *	INPUT_PROP_DIRECT) will still map 1:1 to the actual LCD panel
  *	coordinates, so if userspace rotates the picture to adjust for
  *	the orientation it must also apply the same transformation to the
- *	touchscreen input coordinates. This property is initialized by calling
+ *	touchscreen input coordinates. This property value is set by calling
  *	drm_connector_set_panel_orientation() or
  *	drm_connector_set_panel_orientation_with_quirk()
  *
@@ -2341,8 +2341,8 @@ EXPORT_SYMBOL(drm_connector_set_vrr_capable_property);
  * @connector: connector for which to set the panel-orientation property.
  * @panel_orientation: drm_panel_orientation value to set
  *
- * This function sets the connector's panel_orientation and attaches
- * a "panel orientation" property to the connector.
+ * This function sets the connector's panel_orientation value. If the property
+ * doesn't exist, it will try to create one.
  *
  * Calling this function on a connector where the panel_orientation has
  * already been set is a no-op (e.g. the orientation has been overridden with
@@ -2373,19 +2373,12 @@ int drm_connector_set_panel_orientation(
 	info->panel_orientation = panel_orientation;
 
 	prop = dev->mode_config.panel_orientation_property;
-	if (!prop) {
-		prop = drm_property_create_enum(dev, DRM_MODE_PROP_IMMUTABLE,
-				"panel orientation",
-				drm_panel_orientation_enum_list,
-				ARRAY_SIZE(drm_panel_orientation_enum_list));
-		if (!prop)
-			return -ENOMEM;
-
-		dev->mode_config.panel_orientation_property = prop;
-	}
+	if (!prop &&
+	    drm_connector_init_panel_orientation_property(connector) < 0)
+		return -ENOMEM;
 
-	drm_object_attach_property(&connector->base, prop,
-				   info->panel_orientation);
+	drm_object_property_set_value(&connector->base, prop,
+				      info->panel_orientation);
 	return 0;
 }
 EXPORT_SYMBOL(drm_connector_set_panel_orientation);
@@ -2393,7 +2386,7 @@ EXPORT_SYMBOL(drm_connector_set_panel_orientation);
 /**
  * drm_connector_set_panel_orientation_with_quirk - set the
  *	connector's panel_orientation after checking for quirks
- * @connector: connector for which to init the panel-orientation property.
+ * @connector: connector for which to set the panel-orientation property.
  * @panel_orientation: drm_panel_orientation value to set
  * @width: width in pixels of the panel, used for panel quirk detection
  * @height: height in pixels of the panel, used for panel quirk detection
@@ -2420,6 +2413,43 @@ int drm_connector_set_panel_orientation_with_quirk(
 }
 EXPORT_SYMBOL(drm_connector_set_panel_orientation_with_quirk);
 
+/**
+ * drm_connector_init_panel_orientation_property -
+ * 	create the connector's panel orientation property
+ *
+ * This function attaches a "panel orientation" property to the connector
+ * and initializes its value to DRM_MODE_PANEL_ORIENTATION_UNKNOWN.
+ *
+ * The value of the property can be set by drm_connector_set_panel_orientation()
+ * or drm_connector_set_panel_orientation_with_quirk() later.
+ *
+ * Returns:
+ * Zero on success, negative errno on failure.
+ */
+int drm_connector_init_panel_orientation_property(
+	struct drm_connector *connector)
+{
+	struct drm_device *dev = connector->dev;
+	struct drm_property *prop;
+
+	if(dev->mode_config.panel_orientation_property)
+		return 0;
+
+	prop = drm_property_create_enum(dev, DRM_MODE_PROP_IMMUTABLE,
+			"panel orientation",
+			drm_panel_orientation_enum_list,
+			ARRAY_SIZE(drm_panel_orientation_enum_list));
+	if (!prop)
+		return -ENOMEM;
+
+	dev->mode_config.panel_orientation_property = prop;
+	drm_object_attach_property(&connector->base, prop,
+				   DRM_MODE_PANEL_ORIENTATION_UNKNOWN);
+
+	return 0;
+}
+EXPORT_SYMBOL(drm_connector_init_panel_orientation_property);
+
 static const struct drm_prop_enum_list privacy_screen_enum[] = {
 	{ PRIVACY_SCREEN_DISABLED,		"Disabled" },
 	{ PRIVACY_SCREEN_ENABLED,		"Enabled" },
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 64cf5f88c05b6a..d3448a71bb4d85 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -1798,6 +1798,8 @@ int drm_connector_set_panel_orientation_with_quirk(
 	struct drm_connector *connector,
 	enum drm_panel_orientation panel_orientation,
 	int width, int height);
+int drm_connector_init_panel_orientation_property(
+	struct drm_connector *connector);
 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);
-- 
2.35.0.263.gb82422642f-goog

[PATCH v8 2/3] drm/mediatek: init panel orientation property

[Hsin-Yi Wang]

Init panel orientation property after connector is initialized. Let the
panel driver decides the orientation value later.

Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org>
Acked-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
---
 drivers/gpu/drm/mediatek/mtk_dsi.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c
index 5d90d2eb001935..491bf5b0a2b984 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -965,6 +965,13 @@ static int mtk_dsi_encoder_init(struct drm_device *drm, struct mtk_dsi *dsi)
 		ret = PTR_ERR(dsi->connector);
 		goto err_cleanup_encoder;
 	}
+
+	ret = drm_connector_init_panel_orientation_property(dsi->connector);
+	if (ret) {
+		DRM_ERROR("Unable to init panel orientation\n");
+		goto err_cleanup_encoder;
+	}
+
 	drm_connector_attach_encoder(dsi->connector, &dsi->encoder);
 
 	return 0;
-- 
2.35.0.263.gb82422642f-goog

[PATCH v8 2/3] drm/mediatek: init panel orientation property

[Hsin-Yi Wang]

Init panel orientation property after connector is initialized. Let the
panel driver decides the orientation value later.

Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org>
Acked-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
---
 drivers/gpu/drm/mediatek/mtk_dsi.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c
index 5d90d2eb001935..491bf5b0a2b984 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -965,6 +965,13 @@ static int mtk_dsi_encoder_init(struct drm_device *drm, struct mtk_dsi *dsi)
 		ret = PTR_ERR(dsi->connector);
 		goto err_cleanup_encoder;
 	}
+
+	ret = drm_connector_init_panel_orientation_property(dsi->connector);
+	if (ret) {
+		DRM_ERROR("Unable to init panel orientation\n");
+		goto err_cleanup_encoder;
+	}
+
 	drm_connector_attach_encoder(dsi->connector, &dsi->encoder);
 
 	return 0;
-- 
2.35.0.263.gb82422642f-goog

[Intel-gfx] [PATCH v8 2/3] drm/mediatek: init panel orientation property

[Hsin-Yi Wang]

Init panel orientation property after connector is initialized. Let the
panel driver decides the orientation value later.

Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org>
Acked-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
---
 drivers/gpu/drm/mediatek/mtk_dsi.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c
index 5d90d2eb001935..491bf5b0a2b984 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -965,6 +965,13 @@ static int mtk_dsi_encoder_init(struct drm_device *drm, struct mtk_dsi *dsi)
 		ret = PTR_ERR(dsi->connector);
 		goto err_cleanup_encoder;
 	}
+
+	ret = drm_connector_init_panel_orientation_property(dsi->connector);
+	if (ret) {
+		DRM_ERROR("Unable to init panel orientation\n");
+		goto err_cleanup_encoder;
+	}
+
 	drm_connector_attach_encoder(dsi->connector, &dsi->encoder);
 
 	return 0;
-- 
2.35.0.263.gb82422642f-goog

[PATCH v8 2/3] drm/mediatek: init panel orientation property

[Hsin-Yi Wang]

Init panel orientation property after connector is initialized. Let the
panel driver decides the orientation value later.

Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org>
Acked-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
---
 drivers/gpu/drm/mediatek/mtk_dsi.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c
index 5d90d2eb001935..491bf5b0a2b984 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -965,6 +965,13 @@ static int mtk_dsi_encoder_init(struct drm_device *drm, struct mtk_dsi *dsi)
 		ret = PTR_ERR(dsi->connector);
 		goto err_cleanup_encoder;
 	}
+
+	ret = drm_connector_init_panel_orientation_property(dsi->connector);
+	if (ret) {
+		DRM_ERROR("Unable to init panel orientation\n");
+		goto err_cleanup_encoder;
+	}
+
 	drm_connector_attach_encoder(dsi->connector, &dsi->encoder);
 
 	return 0;
-- 
2.35.0.263.gb82422642f-goog


_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

[PATCH v8 2/3] drm/mediatek: init panel orientation property

[Hsin-Yi Wang]

Init panel orientation property after connector is initialized. Let the
panel driver decides the orientation value later.

Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org>
Acked-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
---
 drivers/gpu/drm/mediatek/mtk_dsi.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c
index 5d90d2eb001935..491bf5b0a2b984 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -965,6 +965,13 @@ static int mtk_dsi_encoder_init(struct drm_device *drm, struct mtk_dsi *dsi)
 		ret = PTR_ERR(dsi->connector);
 		goto err_cleanup_encoder;
 	}
+
+	ret = drm_connector_init_panel_orientation_property(dsi->connector);
+	if (ret) {
+		DRM_ERROR("Unable to init panel orientation\n");
+		goto err_cleanup_encoder;
+	}
+
 	drm_connector_attach_encoder(dsi->connector, &dsi->encoder);
 
 	return 0;
-- 
2.35.0.263.gb82422642f-goog


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v8 2/3] drm/mediatek: init panel orientation property

[Hsin-Yi Wang]

Init panel orientation property after connector is initialized. Let the
panel driver decides the orientation value later.

Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org>
Acked-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
---
 drivers/gpu/drm/mediatek/mtk_dsi.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c
index 5d90d2eb001935..491bf5b0a2b984 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -965,6 +965,13 @@ static int mtk_dsi_encoder_init(struct drm_device *drm, struct mtk_dsi *dsi)
 		ret = PTR_ERR(dsi->connector);
 		goto err_cleanup_encoder;
 	}
+
+	ret = drm_connector_init_panel_orientation_property(dsi->connector);
+	if (ret) {
+		DRM_ERROR("Unable to init panel orientation\n");
+		goto err_cleanup_encoder;
+	}
+
 	drm_connector_attach_encoder(dsi->connector, &dsi->encoder);
 
 	return 0;
-- 
2.35.0.263.gb82422642f-goog

[PATCH v8 3/3] arm64: dts: mt8183: Add panel rotation

[Hsin-Yi Wang]

krane, kakadu, and kodama boards have a default panel rotation.

Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org>
Reviewed-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
---
 arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi b/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
index b42d81d26d7211..d29d4378170971 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
@@ -276,6 +276,7 @@ panel: panel@0 {
 		avee-supply = <&ppvarp_lcd>;
 		pp1800-supply = <&pp1800_lcd>;
 		backlight = <&backlight_lcd0>;
+		rotation = <270>;
 		port {
 			panel_in: endpoint {
 				remote-endpoint = <&dsi_out>;
-- 
2.35.0.263.gb82422642f-goog

[Intel-gfx] [PATCH v8 3/3] arm64: dts: mt8183: Add panel rotation

[Hsin-Yi Wang]

krane, kakadu, and kodama boards have a default panel rotation.

Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org>
Reviewed-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
---
 arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi b/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
index b42d81d26d7211..d29d4378170971 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
@@ -276,6 +276,7 @@ panel: panel@0 {
 		avee-supply = <&ppvarp_lcd>;
 		pp1800-supply = <&pp1800_lcd>;
 		backlight = <&backlight_lcd0>;
+		rotation = <270>;
 		port {
 			panel_in: endpoint {
 				remote-endpoint = <&dsi_out>;
-- 
2.35.0.263.gb82422642f-goog

[PATCH v8 3/3] arm64: dts: mt8183: Add panel rotation

[Hsin-Yi Wang]

krane, kakadu, and kodama boards have a default panel rotation.

Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org>
Reviewed-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
---
 arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi b/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
index b42d81d26d7211..d29d4378170971 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
@@ -276,6 +276,7 @@ panel: panel@0 {
 		avee-supply = <&ppvarp_lcd>;
 		pp1800-supply = <&pp1800_lcd>;
 		backlight = <&backlight_lcd0>;
+		rotation = <270>;
 		port {
 			panel_in: endpoint {
 				remote-endpoint = <&dsi_out>;
-- 
2.35.0.263.gb82422642f-goog

[PATCH v8 3/3] arm64: dts: mt8183: Add panel rotation

[Hsin-Yi Wang]

krane, kakadu, and kodama boards have a default panel rotation.

Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org>
Reviewed-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
---
 arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi b/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
index b42d81d26d7211..d29d4378170971 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
@@ -276,6 +276,7 @@ panel: panel@0 {
 		avee-supply = <&ppvarp_lcd>;
 		pp1800-supply = <&pp1800_lcd>;
 		backlight = <&backlight_lcd0>;
+		rotation = <270>;
 		port {
 			panel_in: endpoint {
 				remote-endpoint = <&dsi_out>;
-- 
2.35.0.263.gb82422642f-goog


_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

[PATCH v8 3/3] arm64: dts: mt8183: Add panel rotation

[Hsin-Yi Wang]

krane, kakadu, and kodama boards have a default panel rotation.

Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org>
Reviewed-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
---
 arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi b/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
index b42d81d26d7211..d29d4378170971 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
@@ -276,6 +276,7 @@ panel: panel@0 {
 		avee-supply = <&ppvarp_lcd>;
 		pp1800-supply = <&pp1800_lcd>;
 		backlight = <&backlight_lcd0>;
+		rotation = <270>;
 		port {
 			panel_in: endpoint {
 				remote-endpoint = <&dsi_out>;
-- 
2.35.0.263.gb82422642f-goog


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v8 3/3] arm64: dts: mt8183: Add panel rotation

[Hsin-Yi Wang]

krane, kakadu, and kodama boards have a default panel rotation.

Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org>
Reviewed-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
---
 arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi b/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
index b42d81d26d7211..d29d4378170971 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
@@ -276,6 +276,7 @@ panel: panel@0 {
 		avee-supply = <&ppvarp_lcd>;
 		pp1800-supply = <&pp1800_lcd>;
 		backlight = <&backlight_lcd0>;
+		rotation = <270>;
 		port {
 			panel_in: endpoint {
 				remote-endpoint = <&dsi_out>;
-- 
2.35.0.263.gb82422642f-goog

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [v8,1/3] gpu: drm: separate panel orientation property creating and value setting

[Patchwork]

== Series Details ==

Series: series starting with [v8,1/3] gpu: drm: separate panel orientation property creating and value setting
URL   : https://patchwork.freedesktop.org/series/99828/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
a832dc08d88f gpu: drm: separate panel orientation property creating and value setting
-:132: WARNING:SPACE_BEFORE_TAB: please, no space before tabs
#132: FILE: drivers/gpu/drm/drm_connector.c:2418:
+ * ^Icreate the connector's panel orientation property$

-:143: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#143: FILE: drivers/gpu/drm/drm_connector.c:2429:
+int drm_connector_init_panel_orientation_property(

-:149: ERROR:SPACING: space required before the open parenthesis '('
#149: FILE: drivers/gpu/drm/drm_connector.c:2435:
+	if(dev->mode_config.panel_orientation_property)

-:153: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#153: FILE: drivers/gpu/drm/drm_connector.c:2439:
+	prop = drm_property_create_enum(dev, DRM_MODE_PROP_IMMUTABLE,
+			"panel orientation",

-:178: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#178: FILE: include/drm/drm_connector.h:1801:
+int drm_connector_init_panel_orientation_property(

total: 1 errors, 1 warnings, 3 checks, 101 lines checked
73d060c30153 drm/mediatek: init panel orientation property
d313feab36a3 arm64: dts: mt8183: Add panel rotation

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [v8,1/3] gpu: drm: separate panel orientation property creating and value setting

[Patchwork]

== Series Details ==

Series: series starting with [v8,1/3] gpu: drm: separate panel orientation property creating and value setting
URL   : https://patchwork.freedesktop.org/series/99828/
State : warning

== Summary ==

$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v8,1/3] gpu: drm: separate panel orientation property creating and value setting

[Patchwork]

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

== Series Details ==

Series: series starting with [v8,1/3] gpu: drm: separate panel orientation property creating and value setting
URL   : https://patchwork.freedesktop.org/series/99828/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11200 -> Patchwork_22199
====================================================

Summary
-------

  **SUCCESS**

  No regressions found.

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/index.html

Participating hosts (41 -> 46)
------------------------------

  Additional (6): fi-kbl-soraka bat-adls-5 bat-dg1-5 bat-adlp-4 fi-pnv-d510 bat-jsl-2 
  Missing    (1): shard-tglu 

Known issues
------------

  Here are the changes found in Patchwork_22199 that come from known issues:

### IGT changes ###

#### Issues hit ####

  * igt@amdgpu/amd_basic@cs-multi-fence:
    - fi-blb-e6850:       NOTRUN -> [SKIP][1] ([fdo#109271]) +17 similar issues
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/fi-blb-e6850/igt@amdgpu/amd_basic@cs-multi-fence.html

  * igt@gem_exec_gttfill@basic:
    - bat-dg1-5:          NOTRUN -> [SKIP][2] ([i915#4086])
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/bat-dg1-5/igt@gem_exec_gttfill@basic.html

  * igt@gem_mmap@basic:
    - bat-dg1-5:          NOTRUN -> [SKIP][3] ([i915#4083])
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/bat-dg1-5/igt@gem_mmap@basic.html

  * igt@gem_tiled_fence_blits@basic:
    - bat-dg1-5:          NOTRUN -> [SKIP][4] ([i915#4077]) +2 similar issues
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/bat-dg1-5/igt@gem_tiled_fence_blits@basic.html

  * igt@gem_tiled_pread_basic:
    - bat-dg1-5:          NOTRUN -> [SKIP][5] ([i915#4079]) +1 similar issue
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/bat-dg1-5/igt@gem_tiled_pread_basic.html

  * igt@i915_pm_backlight@basic-brightness:
    - bat-dg1-5:          NOTRUN -> [SKIP][6] ([i915#1155])
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/bat-dg1-5/igt@i915_pm_backlight@basic-brightness.html

  * igt@i915_selftest@live@hangcheck:
    - bat-dg1-5:          NOTRUN -> [DMESG-FAIL][7] ([i915#4494] / [i915#4957])
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/bat-dg1-5/igt@i915_selftest@live@hangcheck.html

  * igt@kms_addfb_basic@basic-y-tiled-legacy:
    - bat-dg1-5:          NOTRUN -> [SKIP][8] ([i915#4215])
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/bat-dg1-5/igt@kms_addfb_basic@basic-y-tiled-legacy.html

  * igt@kms_addfb_basic@tile-pitch-mismatch:
    - bat-dg1-5:          NOTRUN -> [SKIP][9] ([i915#4212]) +7 similar issues
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/bat-dg1-5/igt@kms_addfb_basic@tile-pitch-mismatch.html

  * igt@kms_chamelium@hdmi-hpd-fast:
    - bat-dg1-5:          NOTRUN -> [SKIP][10] ([fdo#111827]) +8 similar issues
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/bat-dg1-5/igt@kms_chamelium@hdmi-hpd-fast.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
    - bat-dg1-5:          NOTRUN -> [SKIP][11] ([i915#4103] / [i915#4213]) +1 similar issue
   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/bat-dg1-5/igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy.html

  * igt@kms_force_connector_basic@force-load-detect:
    - bat-dg1-5:          NOTRUN -> [SKIP][12] ([fdo#109285])
   [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/bat-dg1-5/igt@kms_force_connector_basic@force-load-detect.html

  * igt@kms_psr@primary_page_flip:
    - bat-dg1-5:          NOTRUN -> [SKIP][13] ([i915#1072] / [i915#4078]) +3 similar issues
   [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/bat-dg1-5/igt@kms_psr@primary_page_flip.html

  * igt@prime_vgem@basic-fence-mmap:
    - bat-dg1-5:          NOTRUN -> [SKIP][14] ([i915#3708] / [i915#4077]) +1 similar issue
   [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/bat-dg1-5/igt@prime_vgem@basic-fence-mmap.html

  * igt@prime_vgem@basic-userptr:
    - fi-pnv-d510:        NOTRUN -> [SKIP][15] ([fdo#109271]) +57 similar issues
   [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/fi-pnv-d510/igt@prime_vgem@basic-userptr.html
    - bat-dg1-5:          NOTRUN -> [SKIP][16] ([i915#3708] / [i915#4873])
   [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/bat-dg1-5/igt@prime_vgem@basic-userptr.html

  * igt@prime_vgem@basic-write:
    - bat-dg1-5:          NOTRUN -> [SKIP][17] ([i915#3708]) +3 similar issues
   [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/bat-dg1-5/igt@prime_vgem@basic-write.html

  * igt@runner@aborted:
    - fi-bsw-kefka:       NOTRUN -> [FAIL][18] ([i915#3690] / [i915#4312])
   [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/fi-bsw-kefka/igt@runner@aborted.html
    - fi-glk-dsi:         NOTRUN -> [FAIL][19] ([i915#2426] / [i915#4312] / [k.org#202321])
   [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/fi-glk-dsi/igt@runner@aborted.html
    - fi-kbl-soraka:      NOTRUN -> [FAIL][20] ([i915#2426] / [i915#4312])
   [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/fi-kbl-soraka/igt@runner@aborted.html
    - bat-adlp-4:         NOTRUN -> [FAIL][21] ([i915#4312])
   [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/bat-adlp-4/igt@runner@aborted.html
    - fi-cml-u2:          NOTRUN -> [FAIL][22] ([i915#2426] / [i915#4312])
   [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/fi-cml-u2/igt@runner@aborted.html
    - fi-bxt-dsi:         NOTRUN -> [FAIL][23] ([i915#2426] / [i915#4312])
   [23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/fi-bxt-dsi/igt@runner@aborted.html

  
#### Possible fixes ####

  * igt@i915_selftest@live@requests:
    - fi-blb-e6850:       [DMESG-FAIL][24] ([i915#4528] / [i915#5026]) -> [PASS][25]
   [24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11200/fi-blb-e6850/igt@i915_selftest@live@requests.html
   [25]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/fi-blb-e6850/igt@i915_selftest@live@requests.html

  
#### Warnings ####

  * igt@runner@aborted:
    - fi-skl-6600u:       [FAIL][26] ([i915#4312]) -> [FAIL][27] ([i915#2426] / [i915#4312])
   [26]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11200/fi-skl-6600u/igt@runner@aborted.html
   [27]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/fi-skl-6600u/igt@runner@aborted.html

  
  {name}: This element is suppressed. This means it is ignored when computing
          the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
  [i915#1155]: https://gitlab.freedesktop.org/drm/intel/issues/1155
  [i915#2426]: https://gitlab.freedesktop.org/drm/intel/issues/2426
  [i915#2582]: https://gitlab.freedesktop.org/drm/intel/issues/2582
  [i915#3690]: https://gitlab.freedesktop.org/drm/intel/issues/3690
  [i915#3708]: https://gitlab.freedesktop.org/drm/intel/issues/3708
  [i915#4077]: https://gitlab.freedesktop.org/drm/intel/issues/4077
  [i915#4078]: https://gitlab.freedesktop.org/drm/intel/issues/4078
  [i915#4079]: https://gitlab.freedesktop.org/drm/intel/issues/4079
  [i915#4083]: https://gitlab.freedesktop.org/drm/intel/issues/4083
  [i915#4086]: https://gitlab.freedesktop.org/drm/intel/issues/4086
  [i915#4103]: https://gitlab.freedesktop.org/drm/intel/issues/4103
  [i915#4212]: https://gitlab.freedesktop.org/drm/intel/issues/4212
  [i915#4213]: https://gitlab.freedesktop.org/drm/intel/issues/4213
  [i915#4215]: https://gitlab.freedesktop.org/drm/intel/issues/4215
  [i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
  [i915#4494]: https://gitlab.freedesktop.org/drm/intel/issues/4494
  [i915#4528]: https://gitlab.freedesktop.org/drm/intel/issues/4528
  [i915#4873]: https://gitlab.freedesktop.org/drm/intel/issues/4873
  [i915#4898]: https://gitlab.freedesktop.org/drm/intel/issues/4898
  [i915#4957]: https://gitlab.freedesktop.org/drm/intel/issues/4957
  [i915#5026]: https://gitlab.freedesktop.org/drm/intel/issues/5026
  [k.org#202321]: https://bugzilla.kernel.org/show_bug.cgi?id=202321


Build changes
-------------

  * Linux: CI_DRM_11200 -> Patchwork_22199

  CI-20190529: 20190529
  CI_DRM_11200: a82048d804ae32de6e00da56d2c74e449d486738 @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6341: a96674e747ea2f2431bbf8813156adc44ec3162a @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_22199: d313feab36a3940d0e3cafa2d18813d255be5920 @ git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

d313feab36a3 arm64: dts: mt8183: Add panel rotation
73d060c30153 drm/mediatek: init panel orientation property
a832dc08d88f gpu: drm: separate panel orientation property creating and value setting

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/index.html

[-- Attachment #2: Type: text/html, Size: 11185 bytes --]

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [v8,1/3] gpu: drm: separate panel orientation property creating and value setting

[Patchwork]

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

== Series Details ==

Series: series starting with [v8,1/3] gpu: drm: separate panel orientation property creating and value setting
URL   : https://patchwork.freedesktop.org/series/99828/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11200_full -> Patchwork_22199_full
====================================================

Summary
-------

  **FAILURE**

  Serious unknown changes coming with Patchwork_22199_full absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_22199_full, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  

Participating hosts (11 -> 11)
------------------------------

  No changes in participating hosts

Possible new issues
-------------------

  Here are the unknown changes that may have been introduced in Patchwork_22199_full:

### IGT changes ###

#### Possible regressions ####

  * igt@kms_flip@flip-vs-fences-interruptible@b-vga1:
    - shard-snb:          [PASS][1] -> [INCOMPLETE][2]
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11200/shard-snb2/igt@kms_flip@flip-vs-fences-interruptible@b-vga1.html
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-snb6/igt@kms_flip@flip-vs-fences-interruptible@b-vga1.html

  * igt@syncobj_timeline@transfer-timeline-point:
    - shard-kbl:          NOTRUN -> [DMESG-WARN][3]
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-kbl3/igt@syncobj_timeline@transfer-timeline-point.html
    - shard-apl:          NOTRUN -> [DMESG-WARN][4]
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-apl1/igt@syncobj_timeline@transfer-timeline-point.html

  
#### Suppressed ####

  The following results come from untrusted machines, tests, or statuses.
  They do not affect the overall result.

  * igt@syncobj_timeline@transfer-timeline-point:
    - {shard-tglu}:       NOTRUN -> [DMESG-WARN][5]
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-tglu-2/igt@syncobj_timeline@transfer-timeline-point.html

  
Known issues
------------

  Here are the changes found in Patchwork_22199_full that come from known issues:

### IGT changes ###

#### Issues hit ####

  * igt@gem_ctx_isolation@preservation-s3@rcs0:
    - shard-kbl:          [PASS][6] -> [DMESG-WARN][7] ([i915#180]) +2 similar issues
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11200/shard-kbl6/igt@gem_ctx_isolation@preservation-s3@rcs0.html
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-kbl6/igt@gem_ctx_isolation@preservation-s3@rcs0.html

  * igt@gem_exec_fair@basic-none-solo@rcs0:
    - shard-kbl:          NOTRUN -> [FAIL][8] ([i915#2842])
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-kbl1/igt@gem_exec_fair@basic-none-solo@rcs0.html

  * igt@gem_exec_fair@basic-none@vcs0:
    - shard-kbl:          [PASS][9] -> [FAIL][10] ([i915#2842]) +2 similar issues
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11200/shard-kbl6/igt@gem_exec_fair@basic-none@vcs0.html
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-kbl7/igt@gem_exec_fair@basic-none@vcs0.html

  * igt@gem_lmem_swapping@smem-oom:
    - shard-kbl:          NOTRUN -> [SKIP][11] ([fdo#109271] / [i915#4613])
   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-kbl3/igt@gem_lmem_swapping@smem-oom.html

  * igt@gem_pwrite@basic-exhaustion:
    - shard-kbl:          NOTRUN -> [WARN][12] ([i915#2658])
   [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-kbl1/igt@gem_pwrite@basic-exhaustion.html

  * igt@gem_userptr_blits@unsync-unmap-cycles:
    - shard-kbl:          NOTRUN -> [SKIP][13] ([fdo#109271]) +66 similar issues
   [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-kbl3/igt@gem_userptr_blits@unsync-unmap-cycles.html

  * igt@gen7_exec_parse@basic-offset:
    - shard-apl:          NOTRUN -> [SKIP][14] ([fdo#109271]) +53 similar issues
   [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-apl1/igt@gen7_exec_parse@basic-offset.html

  * igt@i915_pm_dc@dc6-dpms:
    - shard-kbl:          NOTRUN -> [FAIL][15] ([i915#454])
   [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-kbl1/igt@i915_pm_dc@dc6-dpms.html

  * igt@kms_big_fb@x-tiled-max-hw-stride-64bpp-rotate-0-hflip-async-flip:
    - shard-apl:          NOTRUN -> [SKIP][16] ([fdo#109271] / [i915#3777])
   [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-apl4/igt@kms_big_fb@x-tiled-max-hw-stride-64bpp-rotate-0-hflip-async-flip.html

  * igt@kms_big_fb@x-tiled-max-hw-stride-64bpp-rotate-180-hflip-async-flip:
    - shard-kbl:          NOTRUN -> [SKIP][17] ([fdo#109271] / [i915#3777])
   [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-kbl3/igt@kms_big_fb@x-tiled-max-hw-stride-64bpp-rotate-180-hflip-async-flip.html

  * igt@kms_ccs@pipe-a-crc-primary-rotation-180-y_tiled_gen12_rc_ccs_cc:
    - shard-kbl:          NOTRUN -> [SKIP][18] ([fdo#109271] / [i915#3886]) +4 similar issues
   [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-kbl1/igt@kms_ccs@pipe-a-crc-primary-rotation-180-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][19] ([fdo#109271] / [i915#3886]) +4 similar issues
   [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-apl2/igt@kms_ccs@pipe-b-crc-sprite-planes-basic-y_tiled_gen12_rc_ccs_cc.html

  * igt@kms_chamelium@hdmi-hpd-with-enabled-mode:
    - shard-kbl:          NOTRUN -> [SKIP][20] ([fdo#109271] / [fdo#111827]) +5 similar issues
   [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-kbl1/igt@kms_chamelium@hdmi-hpd-with-enabled-mode.html

  * igt@kms_color_chamelium@pipe-a-ctm-limited-range:
    - shard-apl:          NOTRUN -> [SKIP][21] ([fdo#109271] / [fdo#111827]) +4 similar issues
   [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-apl1/igt@kms_color_chamelium@pipe-a-ctm-limited-range.html

  * igt@kms_flip@flip-vs-suspend-interruptible@c-dp1:
    - shard-apl:          [PASS][22] -> [DMESG-WARN][23] ([i915#180]) +1 similar issue
   [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11200/shard-apl2/igt@kms_flip@flip-vs-suspend-interruptible@c-dp1.html
   [23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-apl4/igt@kms_flip@flip-vs-suspend-interruptible@c-dp1.html

  * igt@kms_flip_scaled_crc@flip-32bpp-ytile-to-32bpp-ytileccs-upscaling:
    - shard-glk:          [PASS][24] -> [FAIL][25] ([i915#4911]) +1 similar issue
   [24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11200/shard-glk5/igt@kms_flip_scaled_crc@flip-32bpp-ytile-to-32bpp-ytileccs-upscaling.html
   [25]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-glk8/igt@kms_flip_scaled_crc@flip-32bpp-ytile-to-32bpp-ytileccs-upscaling.html

  * igt@kms_pipe_crc_basic@hang-read-crc-pipe-d:
    - shard-kbl:          NOTRUN -> [SKIP][26] ([fdo#109271] / [i915#533])
   [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-kbl1/igt@kms_pipe_crc_basic@hang-read-crc-pipe-d.html

  * igt@kms_pipe_crc_basic@read-crc-pipe-d:
    - shard-apl:          NOTRUN -> [SKIP][27] ([fdo#109271] / [i915#533])
   [27]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-apl2/igt@kms_pipe_crc_basic@read-crc-pipe-d.html

  * igt@kms_plane_alpha_blend@pipe-a-alpha-basic:
    - shard-kbl:          NOTRUN -> [FAIL][28] ([fdo#108145] / [i915#265])
   [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-kbl3/igt@kms_plane_alpha_blend@pipe-a-alpha-basic.html

  * igt@kms_psr2_sf@cursor-plane-update-sf:
    - shard-apl:          NOTRUN -> [SKIP][29] ([fdo#109271] / [i915#658]) +1 similar issue
   [29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-apl4/igt@kms_psr2_sf@cursor-plane-update-sf.html

  * igt@kms_psr2_su@frontbuffer-xrgb8888:
    - shard-kbl:          NOTRUN -> [SKIP][30] ([fdo#109271] / [i915#658])
   [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-kbl1/igt@kms_psr2_su@frontbuffer-xrgb8888.html

  * igt@kms_vblank@pipe-a-ts-continuation-suspend:
    - shard-kbl:          [PASS][31] -> [DMESG-WARN][32] ([i915#180] / [i915#295])
   [31]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11200/shard-kbl7/igt@kms_vblank@pipe-a-ts-continuation-suspend.html
   [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-kbl6/igt@kms_vblank@pipe-a-ts-continuation-suspend.html

  * igt@sysfs_clients@fair-3:
    - shard-kbl:          NOTRUN -> [SKIP][33] ([fdo#109271] / [i915#2994])
   [33]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-kbl3/igt@sysfs_clients@fair-3.html

  
#### Possible fixes ####

  * igt@gem_exec_fair@basic-pace-share@rcs0:
    - shard-glk:          [FAIL][34] ([i915#2842]) -> [PASS][35]
   [34]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11200/shard-glk9/igt@gem_exec_fair@basic-pace-share@rcs0.html
   [35]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-glk8/igt@gem_exec_fair@basic-pace-share@rcs0.html

  * igt@kms_big_fb@linear-16bpp-rotate-0:
    - {shard-tglu}:       [DMESG-WARN][36] ([i915#402]) -> [PASS][37]
   [36]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11200/shard-tglu-5/igt@kms_big_fb@linear-16bpp-rotate-0.html
   [37]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-tglu-2/igt@kms_big_fb@linear-16bpp-rotate-0.html

  * igt@kms_cursor_crc@pipe-a-cursor-128x128-sliding:
    - shard-snb:          [SKIP][38] ([fdo#109271]) -> [PASS][39]
   [38]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11200/shard-snb7/igt@kms_cursor_crc@pipe-a-cursor-128x128-sliding.html
   [39]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-snb5/igt@kms_cursor_crc@pipe-a-cursor-128x128-sliding.html

  * igt@kms_cursor_crc@pipe-c-cursor-suspend:
    - shard-kbl:          [DMESG-WARN][40] ([i915#180]) -> [PASS][41] +4 similar issues
   [40]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11200/shard-kbl1/igt@kms_cursor_crc@pipe-c-cursor-suspend.html
   [41]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-kbl3/igt@kms_cursor_crc@pipe-c-cursor-suspend.html
    - shard-apl:          [DMESG-WARN][42] ([i915#180]) -> [PASS][43] +3 similar issues
   [42]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11200/shard-apl7/igt@kms_cursor_crc@pipe-c-cursor-suspend.html
   [43]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-apl1/igt@kms_cursor_crc@pipe-c-cursor-suspend.html

  * igt@kms_lease@lease_invalid_plane:
    - shard-glk:          [DMESG-WARN][44] ([i915#118]) -> [PASS][45]
   [44]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11200/shard-glk7/igt@kms_lease@lease_invalid_plane.html
   [45]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-glk2/igt@kms_lease@lease_invalid_plane.html

  
#### Warnings ####

  * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
    - shard-apl:          [DMESG-WARN][46] ([i915#180] / [i915#1982]) -> [DMESG-WARN][47] ([i915#180])
   [46]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11200/shard-apl1/igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a.html
   [47]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-apl8/igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a.html

  * igt@runner@aborted:
    - shard-kbl:          ([FAIL][48], [FAIL][49], [FAIL][50], [FAIL][51], [FAIL][52], [FAIL][53], [FAIL][54], [FAIL][55], [FAIL][56], [FAIL][57], [FAIL][58], [FAIL][59], [FAIL][60], [FAIL][61], [FAIL][62], [FAIL][63]) ([i915#1436] / [i915#180] / [i915#1814] / [i915#3002] / [i915#4312]) -> ([FAIL][64], [FAIL][65], [FAIL][66], [FAIL][67], [FAIL][68], [FAIL][69], [FAIL][70], [FAIL][71], [FAIL][72], [FAIL][73], [FAIL][74], [FAIL][75], [FAIL][76], [FAIL][77], [FAIL][78]) ([i915#1436] / [i915#180] / [i915#1814] / [i915#3002] / [i915#4312] / [i915#602])
   [48]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11200/shard-kbl6/igt@runner@aborted.html
   [49]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11200/shard-kbl4/igt@runner@aborted.html
   [50]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11200/shard-kbl4/igt@runner@aborted.html
   [51]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11200/shard-kbl6/igt@runner@aborted.html
   [52]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11200/shard-kbl3/igt@runner@aborted.html
   [53]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11200/shard-kbl1/igt@runner@aborted.html
   [54]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11200/shard-kbl1/igt@runner@aborted.html
   [55]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11200/shard-kbl1/igt@runner@aborted.html
   [56]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11200/shard-kbl3/igt@runner@aborted.html
   [57]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11200/shard-kbl1/igt@runner@aborted.html
   [58]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11200/shard-kbl4/igt@runner@aborted.html
   [59]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11200/shard-kbl4/igt@runner@aborted.html
   [60]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11200/shard-kbl1/igt@runner@aborted.html
   [61]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11200/shard-kbl7/igt@runner@aborted.html
   [62]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11200/shard-kbl6/igt@runner@aborted.html
   [63]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11200/shard-kbl6/igt@runner@aborted.html
   [64]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-kbl4/igt@runner@aborted.html
   [65]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-kbl1/igt@runner@aborted.html
   [66]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-kbl6/igt@runner@aborted.html
   [67]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-kbl3/igt@runner@aborted.html
   [68]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-kbl4/igt@runner@aborted.html
   [69]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-kbl6/igt@runner@aborted.html
   [70]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-kbl4/igt@runner@aborted.html
   [71]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-kbl3/igt@runner@aborted.html
   [72]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-kbl4/igt@runner@aborted.html
   [73]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-kbl6/igt@runner@aborted.html
   [74]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-kbl1/igt@runner@aborted.html
   [75]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-kbl1/igt@runner@aborted.html
   [76]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-kbl3/igt@runner@aborted.html
   [77]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-kbl1/igt@runner@aborted.html
   [78]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-kbl6/igt@runner@aborted.html
    - shard-iclb:         ([FAIL][79], [FAIL][80], [FAIL][81], [FAIL][82], [FAIL][83], [FAIL][84], [FAIL][85], [FAIL][86]) ([i915#3002] / [i915#4312]) -> ([FAIL][87], [FAIL][88], [FAIL][89], [FAIL][90], [FAIL][91], [FAIL][92], [FAIL][93], [FAIL][94], [FAIL][95], [FAIL][96], [FAIL][97], [FAIL][98], [FAIL][99], [FAIL][100], [FAIL][101], [FAIL][102], [FAIL][103], [FAIL][104], [FAIL][105], [FAIL][106], [FAIL][107], [FAIL][108], [FAIL][109], [FAIL][110], [FAIL][111]) ([i915#2426] / [i915#3690] / [i915#4312])
   [79]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11200/shard-iclb1/igt@runner@aborted.html
   [80]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11200/shard-iclb8/igt@runner@aborted.html
   [81]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11200/shard-iclb8/igt@runner@aborted.html
   [82]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11200/shard-iclb2/igt@runner@aborted.html
   [83]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11200/shard-iclb3/igt@runner@aborted.html
   [84]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11200/shard-iclb1/igt@runner@aborted.html
   [85]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11200/shard-iclb2/igt@runner@aborted.html
   [86]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11200/shard-iclb2/igt@runner@aborted.html
   [87]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-iclb7/igt@runner@aborted.html
   [88]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-iclb1/igt@runner@aborted.html
   [89]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-iclb5/igt@runner@aborted.html
   [90]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-iclb2/igt@runner@aborted.html
   [91]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-iclb5/igt@runner@aborted.html
   [92]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-iclb2/igt@runner@aborted.html
   [93]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-iclb8/igt@runner@aborted.html
   [94]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-iclb3/igt@runner@aborted.html
   [95]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-iclb5/igt@runner@aborted.html
   [96]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-iclb2/igt@runner@aborted.html
   [97]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-iclb4/igt@runner@aborted.html
   [98]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-iclb1/igt@runner@aborted.html
   [99]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-iclb4/igt@runner@aborted.html
   [100]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-iclb3/igt@runner@aborted.html
   [101]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-iclb8/igt@runner@aborted.html
   [102]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-iclb3/igt@runner@aborted.html
   [103]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-iclb1/igt@runner@aborted.html
   [104]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-iclb7/igt@runner@aborted.html
   [105]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-iclb6/igt@runner@aborted.html
   [106]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-iclb4/igt@runner@aborted.html
   [107]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-iclb8/igt@runner@aborted.html
   [108]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-iclb6/igt@runner@aborted.html
   [109]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-iclb4/igt@runner@aborted.html
   [110]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-iclb7/igt@runner@aborted.html
   [111]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-iclb6/igt@runner@aborted.html
    - shard-tglb:         ([FAIL][112], [FAIL][113], [FAIL][114], [FAIL][115], [FAIL][116], [FAIL][117], [FAIL][118], [FAIL][119], [FAIL][120], [FAIL][121]) ([i915#3002] / [i915#4312]) -> ([FAIL][122], [FAIL][123], [FAIL][124], [FAIL][125], [FAIL][126], [FAIL][127], [FAIL][128], [FAIL][129], [FAIL][130], [FAIL][131], [FAIL][132], [FAIL][133], [FAIL][134], [FAIL][135], [FAIL][136], [FAIL][137], [FAIL][138], [FAIL][139], [FAIL][140], [FAIL][141], [FAIL][142], [FAIL][143], [FAIL][144], [FAIL][145], [FAIL][146]) ([i915#2426] / [i915#3690] / [i915#4312])
   [112]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11200/shard-tglb5/igt@runner@aborted.html
   [113]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11200/shard-tglb1/igt@runner@aborted.html
   [114]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11200/shard-tglb8/igt@runner@aborted.html
   [115]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11200/shard-tglb2/igt@runner@aborted.html
   [116]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11200/shard-tglb3/igt@runner@aborted.html
   [117]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11200/shard-tglb7/igt@runner@aborted.html
   [118]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11200/shard-tglb5/igt@runner@aborted.html
   [119]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11200/shard-tglb6/igt@runner@aborted.html
   [120]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11200/shard-tglb7/igt@runner@aborted.html
   [121]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11200/shard-tglb3/igt@runner@aborted.html
   [122]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-tglb1/igt@runner@aborted.html
   [123]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-tglb2/igt@runner@aborted.html
   [124]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-tglb1/igt@runner@aborted.html
   [125]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-tglb2/igt@runner@aborted.html
   [126]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-tglb1/igt@runner@aborted.html
   [127]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-tglb1/igt@runner@aborted.html
   [128]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-tglb6/igt@runner@aborted.html
   [129]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-tglb7/igt@runner@aborted.html
   [130]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-tglb5/igt@runner@aborted.html
   [131]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-tglb7/igt@runner@aborted.html
   [132]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-tglb6/igt@runner@aborted.html
   [133]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-tglb5/igt@runner@aborted.html
   [134]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-tglb3/igt@runner@aborted.html
   [135]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-tglb3/igt@runner@aborted.html
   [136]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-tglb8/igt@runner@aborted.html
   [137]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-tglb6/igt@runner@aborted.html
   [138]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-tglb8/igt@runner@aborted.html
   [139]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-tglb2/igt@runner@aborted.html
   [140]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-tglb8/igt@runner@aborted.html
   [141]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-tglb5/igt@runner@aborted.html
   [142]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-tglb7/igt@runner@aborted.html
   [143]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-tglb3/igt@runner@aborted.html
   [144]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-tglb2/igt@runner@aborted.html
   [145]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-tglb6/igt@runner@aborted.html
   [146]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-tglb7/igt@runner@aborted.html
    - shard-skl:          ([FAIL][147], [FAIL][148], [FAIL][149], [FAIL][150], [FAIL][151]) ([i915#1436] / [i915#3002] / [i915#4312]) -> ([FAIL][152], [FAIL][153], [FAIL][154], [FAIL][155], [FAIL][156], [FAIL][157], [FAIL][158], [FAIL][159], [FAIL][160], [FAIL][161], [FAIL][162], [FAIL][163], [FAIL][164], [FAIL][165], [FAIL][166], [FAIL][167], [FAIL][168], [FAIL][169], [FAIL][170], [FAIL][171]) ([i915#2426] / [i915#4312])
   [147]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11200/shard-skl6/igt@runner@aborted.html
   [148]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11200/shard-skl6/igt@runner@aborted.html
   [149]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11200/shard-skl8/igt@runner@aborted.html
   [150]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11200/shard-skl4/igt@runner@aborted.html
   [151]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11200/shard-skl10/igt@runner@aborted.html
   [152]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-skl3/igt@runner@aborted.html
   [153]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-skl10/igt@runner@aborted.html
   [154]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-skl8/igt@runner@aborted.html
   [155]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-skl9/igt@runner@aborted.html
   [156]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-skl9/igt@runner@aborted.html
   [157]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-skl7/igt@runner@aborted.html
   [158]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-skl10/igt@runner@aborted.html
   [159]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-skl2/igt@runner@aborted.html
   [160]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-skl4/igt@runner@aborted.html
   [161]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-skl4/igt@runner@aborted.html
   [162]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-skl1/igt@runner@aborted.html
   [163]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-skl3/igt@runner@aborted.html
   [164]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-skl7/igt@runner@aborted.html
   [165]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-skl1/igt@runner@aborted.html
   [166]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-skl10/igt@runner@aborted.html
   [167]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-skl3/igt@runner@aborted.html
   [168]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-skl10/igt@runner@aborted.html
   [169]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-skl7/igt@runner@aborted.html
   [170]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-skl2/igt@runner@aborted.html
   [171]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/shard-skl7/igt@runner@aborted.html

  
  {name}: This element is suppressed. This means it is ignored when computing
          the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#108145]: https://bugs.freedesktop.org/show_bug.cgi?id=108145
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109274]: https://bugs.freedesktop.org/show_bug.cgi?id=109274
  [fdo#109279]: https://bugs.freedesktop.org/show_bug.cgi?id=109279
  [fdo#109280]: https://bugs.freedesktop.org/show_bug.cgi?id=109280
  [fdo#109289]: https://bugs.freedesktop.org/show_bug.cgi?id=109289
  [fdo#109291]: https://bugs.freedesktop.org/show_bug.cgi?id=109291
  [fdo#109303]: https://bugs.freedesktop.org/show_bug.cgi?id=109303
  [fdo#109313]: https://bugs.freedesktop.org/show_bug.cgi?id=109313
  [fdo#109502]: https://bugs.freedesktop.org/show_bug.cgi?id=109502
  [fdo#109506]: https://bugs.freedesktop.org/show_bug.cgi?id=109506
  [fdo#110189]: https://bugs.freedesktop.org/show_bug.cgi?id=110189
  [fdo#111614]: https://bugs.freedesktop.org/show_bug.cgi?id=111614
  [fdo#111615]: https://bugs.freedesktop.org/show_bug.cgi?id=111615
  [fdo#111644]: https://bugs.freedesktop.org/show_bug.cgi?id=111644
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1063]: https://gitlab.freedesktop.org/drm/intel/issues/1063
  [i915#118]: https://gitlab.freedesktop.org/drm/intel/issues/118
  [i915#1397]: https://gitlab.freedesktop.org/drm/intel/issues/1397
  [i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436
  [i915#180]: https://gitlab.freedesktop.org/drm/intel/issues/180
  [i915#1814]: https://gitlab.freedesktop.org/drm/intel/issues/1814
  [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
  [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
  [i915#2426]: https://gitlab.freedesktop.org/drm/intel/issues/2426
  [i915#2527]: https://gitlab.freedesktop.org/drm/intel/issues/2527
  [i915#2530]: https://gitlab.freedesktop.org/drm/intel/issues/2530
  [i915#265]: https://gitlab.freedesktop.org/drm/intel/issues/265
  [i915#2658]: https://gitlab.freedesktop.org/drm/intel/issues/2658
  [i915#2842]: https://gitlab.freedesktop.org/drm/intel/issues/2842
  [i915#2856]: https://gitlab.freedesktop.org/drm/intel/issues/2856
  [i915#295]: https://gitlab.freedesktop.org/drm/intel/issues/295
  [i915#2994]: https://gitlab.freedesktop.org/drm/intel/issues/2994
  [i915#3002]: https://gitlab.freedesktop.org/drm/intel/issues/3002
  [i915#3319]: https://gitlab.freedesktop.org/drm/intel/issues/3319
  [i915#3359]: https://gitlab.freedesktop.org/drm/intel/issues/3359
  [i915#3469]: https://gitlab.freedesktop.org/drm/intel/issues/3469
  [i915#3689]: https://gitlab.freedesktop.org/drm/intel/issues/3689
  [i915#3690]: https://gitlab.freedesktop.org/drm/intel/issues/3690
  [i915#3777]: https://gitlab.freedesktop.org/drm/intel/issues/3777
  [i915#3886]: https://gitlab.freedesktop.org/drm/intel/issues/3886
  [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402
  [i915#4103]: https://gitlab.freedesktop.org/drm/intel/issues/4103
  [i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
  [i915#454]: https://gitlab.freedesktop.org/drm/intel/issues/454
  [i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
  [i915#4911]: https://gitlab.freedesktop.org/drm/intel/issues/4911
  [i915#533]: https://gitlab.freedesktop.org/drm/intel/issues/533
  [i915#602]: https://gitlab.freedesktop.org/drm/intel/issues/602
  [i915#658]: https://gitlab.freedesktop.org/drm/intel/issues/658


Build changes
-------------

  * Linux: CI_DRM_11200 -> Patchwork_22199

  CI-20190529: 20190529
  CI_DRM_11200: a82048d804ae32de6e00da56d2c74e449d486738 @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6341: a96674e747ea2f2431bbf8813156adc44ec3162a @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_22199: d313feab36a3940d0e3cafa2d18813d255be5920 @ git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22199/index.html

[-- Attachment #2: Type: text/html, Size: 33186 bytes --]

Re: [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Gabriel Krisman Bertazi]

Hsin-Yi Wang <hsinyi@chromium.org> writes:

> drm_dev_register() sets connector->registration_state to
> DRM_CONNECTOR_REGISTERED and dev->registered to true. If
> drm_connector_set_panel_orientation() is first called after
> drm_dev_register(), it will fail several checks and results in following
> warning.

Hi,

I stumbled upon this when investigating the same WARN_ON on amdgpu.
Thanks for the patch :)

> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index a50c82bc2b2fec..572ead7ac10690 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -1252,7 +1252,7 @@ static const struct drm_prop_enum_list dp_colorspaces[] = {
>   *	INPUT_PROP_DIRECT) will still map 1:1 to the actual LCD panel
>   *	coordinates, so if userspace rotates the picture to adjust for
>   *	the orientation it must also apply the same transformation to the
> - *	touchscreen input coordinates. This property is initialized by calling
> + *	touchscreen input coordinates. This property value is set by calling
>   *	drm_connector_set_panel_orientation() or
>   *	drm_connector_set_panel_orientation_with_quirk()
>   *
> @@ -2341,8 +2341,8 @@ EXPORT_SYMBOL(drm_connector_set_vrr_capable_property);
>   * @connector: connector for which to set the panel-orientation property.
>   * @panel_orientation: drm_panel_orientation value to set
>   *
> - * This function sets the connector's panel_orientation and attaches
> - * a "panel orientation" property to the connector.
> + * This function sets the connector's panel_orientation value. If the property
> + * doesn't exist, it will try to create one.
>   *
>   * Calling this function on a connector where the panel_orientation has
>   * already been set is a no-op (e.g. the orientation has been overridden with
> @@ -2373,19 +2373,12 @@ int drm_connector_set_panel_orientation(
>  	info->panel_orientation = panel_orientation;
>  
>  	prop = dev->mode_config.panel_orientation_property;
> -	if (!prop) {
> -		prop = drm_property_create_enum(dev, DRM_MODE_PROP_IMMUTABLE,
> -				"panel orientation",
> -				drm_panel_orientation_enum_list,
> -				ARRAY_SIZE(drm_panel_orientation_enum_list));
> -		if (!prop)
> -			return -ENOMEM;
> -
> -		dev->mode_config.panel_orientation_property = prop;
> -	}
> +	if (!prop &&
> +	    drm_connector_init_panel_orientation_property(connector) < 0)
> +		return -ENOMEM;
>

In the case where the property has not been created beforehand, you
forgot to reinitialize prop here, after calling
drm_connector_init_panel_orientation_property().  This means
drm_object_property_set_value() will be called with a NULL second argument
and Oops the kernel.


> -	drm_object_attach_property(&connector->base, prop,
> -				   info->panel_orientation);
> +	drm_object_property_set_value(&connector->base, prop,
> +				      info->panel_orientation);


-- 
Gabriel Krisman Bertazi

Re: [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Gabriel Krisman Bertazi]

Hsin-Yi Wang <hsinyi@chromium.org> writes:

> drm_dev_register() sets connector->registration_state to
> DRM_CONNECTOR_REGISTERED and dev->registered to true. If
> drm_connector_set_panel_orientation() is first called after
> drm_dev_register(), it will fail several checks and results in following
> warning.

Hi,

I stumbled upon this when investigating the same WARN_ON on amdgpu.
Thanks for the patch :)

> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index a50c82bc2b2fec..572ead7ac10690 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -1252,7 +1252,7 @@ static const struct drm_prop_enum_list dp_colorspaces[] = {
>   *	INPUT_PROP_DIRECT) will still map 1:1 to the actual LCD panel
>   *	coordinates, so if userspace rotates the picture to adjust for
>   *	the orientation it must also apply the same transformation to the
> - *	touchscreen input coordinates. This property is initialized by calling
> + *	touchscreen input coordinates. This property value is set by calling
>   *	drm_connector_set_panel_orientation() or
>   *	drm_connector_set_panel_orientation_with_quirk()
>   *
> @@ -2341,8 +2341,8 @@ EXPORT_SYMBOL(drm_connector_set_vrr_capable_property);
>   * @connector: connector for which to set the panel-orientation property.
>   * @panel_orientation: drm_panel_orientation value to set
>   *
> - * This function sets the connector's panel_orientation and attaches
> - * a "panel orientation" property to the connector.
> + * This function sets the connector's panel_orientation value. If the property
> + * doesn't exist, it will try to create one.
>   *
>   * Calling this function on a connector where the panel_orientation has
>   * already been set is a no-op (e.g. the orientation has been overridden with
> @@ -2373,19 +2373,12 @@ int drm_connector_set_panel_orientation(
>  	info->panel_orientation = panel_orientation;
>  
>  	prop = dev->mode_config.panel_orientation_property;
> -	if (!prop) {
> -		prop = drm_property_create_enum(dev, DRM_MODE_PROP_IMMUTABLE,
> -				"panel orientation",
> -				drm_panel_orientation_enum_list,
> -				ARRAY_SIZE(drm_panel_orientation_enum_list));
> -		if (!prop)
> -			return -ENOMEM;
> -
> -		dev->mode_config.panel_orientation_property = prop;
> -	}
> +	if (!prop &&
> +	    drm_connector_init_panel_orientation_property(connector) < 0)
> +		return -ENOMEM;
>

In the case where the property has not been created beforehand, you
forgot to reinitialize prop here, after calling
drm_connector_init_panel_orientation_property().  This means
drm_object_property_set_value() will be called with a NULL second argument
and Oops the kernel.


> -	drm_object_attach_property(&connector->base, prop,
> -				   info->panel_orientation);
> +	drm_object_property_set_value(&connector->base, prop,
> +				      info->panel_orientation);


-- 
Gabriel Krisman Bertazi

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

Re: [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Gabriel Krisman Bertazi]

Hsin-Yi Wang <hsinyi@chromium.org> writes:

> drm_dev_register() sets connector->registration_state to
> DRM_CONNECTOR_REGISTERED and dev->registered to true. If
> drm_connector_set_panel_orientation() is first called after
> drm_dev_register(), it will fail several checks and results in following
> warning.

Hi,

I stumbled upon this when investigating the same WARN_ON on amdgpu.
Thanks for the patch :)

> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index a50c82bc2b2fec..572ead7ac10690 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -1252,7 +1252,7 @@ static const struct drm_prop_enum_list dp_colorspaces[] = {
>   *	INPUT_PROP_DIRECT) will still map 1:1 to the actual LCD panel
>   *	coordinates, so if userspace rotates the picture to adjust for
>   *	the orientation it must also apply the same transformation to the
> - *	touchscreen input coordinates. This property is initialized by calling
> + *	touchscreen input coordinates. This property value is set by calling
>   *	drm_connector_set_panel_orientation() or
>   *	drm_connector_set_panel_orientation_with_quirk()
>   *
> @@ -2341,8 +2341,8 @@ EXPORT_SYMBOL(drm_connector_set_vrr_capable_property);
>   * @connector: connector for which to set the panel-orientation property.
>   * @panel_orientation: drm_panel_orientation value to set
>   *
> - * This function sets the connector's panel_orientation and attaches
> - * a "panel orientation" property to the connector.
> + * This function sets the connector's panel_orientation value. If the property
> + * doesn't exist, it will try to create one.
>   *
>   * Calling this function on a connector where the panel_orientation has
>   * already been set is a no-op (e.g. the orientation has been overridden with
> @@ -2373,19 +2373,12 @@ int drm_connector_set_panel_orientation(
>  	info->panel_orientation = panel_orientation;
>  
>  	prop = dev->mode_config.panel_orientation_property;
> -	if (!prop) {
> -		prop = drm_property_create_enum(dev, DRM_MODE_PROP_IMMUTABLE,
> -				"panel orientation",
> -				drm_panel_orientation_enum_list,
> -				ARRAY_SIZE(drm_panel_orientation_enum_list));
> -		if (!prop)
> -			return -ENOMEM;
> -
> -		dev->mode_config.panel_orientation_property = prop;
> -	}
> +	if (!prop &&
> +	    drm_connector_init_panel_orientation_property(connector) < 0)
> +		return -ENOMEM;
>

In the case where the property has not been created beforehand, you
forgot to reinitialize prop here, after calling
drm_connector_init_panel_orientation_property().  This means
drm_object_property_set_value() will be called with a NULL second argument
and Oops the kernel.


> -	drm_object_attach_property(&connector->base, prop,
> -				   info->panel_orientation);
> +	drm_object_property_set_value(&connector->base, prop,
> +				      info->panel_orientation);


-- 
Gabriel Krisman Bertazi

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Gabriel Krisman Bertazi]

Hsin-Yi Wang <hsinyi@chromium.org> writes:

> drm_dev_register() sets connector->registration_state to
> DRM_CONNECTOR_REGISTERED and dev->registered to true. If
> drm_connector_set_panel_orientation() is first called after
> drm_dev_register(), it will fail several checks and results in following
> warning.

Hi,

I stumbled upon this when investigating the same WARN_ON on amdgpu.
Thanks for the patch :)

> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index a50c82bc2b2fec..572ead7ac10690 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -1252,7 +1252,7 @@ static const struct drm_prop_enum_list dp_colorspaces[] = {
>   *	INPUT_PROP_DIRECT) will still map 1:1 to the actual LCD panel
>   *	coordinates, so if userspace rotates the picture to adjust for
>   *	the orientation it must also apply the same transformation to the
> - *	touchscreen input coordinates. This property is initialized by calling
> + *	touchscreen input coordinates. This property value is set by calling
>   *	drm_connector_set_panel_orientation() or
>   *	drm_connector_set_panel_orientation_with_quirk()
>   *
> @@ -2341,8 +2341,8 @@ EXPORT_SYMBOL(drm_connector_set_vrr_capable_property);
>   * @connector: connector for which to set the panel-orientation property.
>   * @panel_orientation: drm_panel_orientation value to set
>   *
> - * This function sets the connector's panel_orientation and attaches
> - * a "panel orientation" property to the connector.
> + * This function sets the connector's panel_orientation value. If the property
> + * doesn't exist, it will try to create one.
>   *
>   * Calling this function on a connector where the panel_orientation has
>   * already been set is a no-op (e.g. the orientation has been overridden with
> @@ -2373,19 +2373,12 @@ int drm_connector_set_panel_orientation(
>  	info->panel_orientation = panel_orientation;
>  
>  	prop = dev->mode_config.panel_orientation_property;
> -	if (!prop) {
> -		prop = drm_property_create_enum(dev, DRM_MODE_PROP_IMMUTABLE,
> -				"panel orientation",
> -				drm_panel_orientation_enum_list,
> -				ARRAY_SIZE(drm_panel_orientation_enum_list));
> -		if (!prop)
> -			return -ENOMEM;
> -
> -		dev->mode_config.panel_orientation_property = prop;
> -	}
> +	if (!prop &&
> +	    drm_connector_init_panel_orientation_property(connector) < 0)
> +		return -ENOMEM;
>

In the case where the property has not been created beforehand, you
forgot to reinitialize prop here, after calling
drm_connector_init_panel_orientation_property().  This means
drm_object_property_set_value() will be called with a NULL second argument
and Oops the kernel.


> -	drm_object_attach_property(&connector->base, prop,
> -				   info->panel_orientation);
> +	drm_object_property_set_value(&connector->base, prop,
> +				      info->panel_orientation);


-- 
Gabriel Krisman Bertazi

Re: [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Gabriel Krisman Bertazi]

Hsin-Yi Wang <hsinyi@chromium.org> writes:

> drm_dev_register() sets connector->registration_state to
> DRM_CONNECTOR_REGISTERED and dev->registered to true. If
> drm_connector_set_panel_orientation() is first called after
> drm_dev_register(), it will fail several checks and results in following
> warning.

Hi,

I stumbled upon this when investigating the same WARN_ON on amdgpu.
Thanks for the patch :)

> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index a50c82bc2b2fec..572ead7ac10690 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -1252,7 +1252,7 @@ static const struct drm_prop_enum_list dp_colorspaces[] = {
>   *	INPUT_PROP_DIRECT) will still map 1:1 to the actual LCD panel
>   *	coordinates, so if userspace rotates the picture to adjust for
>   *	the orientation it must also apply the same transformation to the
> - *	touchscreen input coordinates. This property is initialized by calling
> + *	touchscreen input coordinates. This property value is set by calling
>   *	drm_connector_set_panel_orientation() or
>   *	drm_connector_set_panel_orientation_with_quirk()
>   *
> @@ -2341,8 +2341,8 @@ EXPORT_SYMBOL(drm_connector_set_vrr_capable_property);
>   * @connector: connector for which to set the panel-orientation property.
>   * @panel_orientation: drm_panel_orientation value to set
>   *
> - * This function sets the connector's panel_orientation and attaches
> - * a "panel orientation" property to the connector.
> + * This function sets the connector's panel_orientation value. If the property
> + * doesn't exist, it will try to create one.
>   *
>   * Calling this function on a connector where the panel_orientation has
>   * already been set is a no-op (e.g. the orientation has been overridden with
> @@ -2373,19 +2373,12 @@ int drm_connector_set_panel_orientation(
>  	info->panel_orientation = panel_orientation;
>  
>  	prop = dev->mode_config.panel_orientation_property;
> -	if (!prop) {
> -		prop = drm_property_create_enum(dev, DRM_MODE_PROP_IMMUTABLE,
> -				"panel orientation",
> -				drm_panel_orientation_enum_list,
> -				ARRAY_SIZE(drm_panel_orientation_enum_list));
> -		if (!prop)
> -			return -ENOMEM;
> -
> -		dev->mode_config.panel_orientation_property = prop;
> -	}
> +	if (!prop &&
> +	    drm_connector_init_panel_orientation_property(connector) < 0)
> +		return -ENOMEM;
>

In the case where the property has not been created beforehand, you
forgot to reinitialize prop here, after calling
drm_connector_init_panel_orientation_property().  This means
drm_object_property_set_value() will be called with a NULL second argument
and Oops the kernel.


> -	drm_object_attach_property(&connector->base, prop,
> -				   info->panel_orientation);
> +	drm_object_property_set_value(&connector->base, prop,
> +				      info->panel_orientation);


-- 
Gabriel Krisman Bertazi

Re: [Intel-gfx] [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Gabriel Krisman Bertazi]

Hsin-Yi Wang <hsinyi@chromium.org> writes:

> drm_dev_register() sets connector->registration_state to
> DRM_CONNECTOR_REGISTERED and dev->registered to true. If
> drm_connector_set_panel_orientation() is first called after
> drm_dev_register(), it will fail several checks and results in following
> warning.

Hi,

I stumbled upon this when investigating the same WARN_ON on amdgpu.
Thanks for the patch :)

> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index a50c82bc2b2fec..572ead7ac10690 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -1252,7 +1252,7 @@ static const struct drm_prop_enum_list dp_colorspaces[] = {
>   *	INPUT_PROP_DIRECT) will still map 1:1 to the actual LCD panel
>   *	coordinates, so if userspace rotates the picture to adjust for
>   *	the orientation it must also apply the same transformation to the
> - *	touchscreen input coordinates. This property is initialized by calling
> + *	touchscreen input coordinates. This property value is set by calling
>   *	drm_connector_set_panel_orientation() or
>   *	drm_connector_set_panel_orientation_with_quirk()
>   *
> @@ -2341,8 +2341,8 @@ EXPORT_SYMBOL(drm_connector_set_vrr_capable_property);
>   * @connector: connector for which to set the panel-orientation property.
>   * @panel_orientation: drm_panel_orientation value to set
>   *
> - * This function sets the connector's panel_orientation and attaches
> - * a "panel orientation" property to the connector.
> + * This function sets the connector's panel_orientation value. If the property
> + * doesn't exist, it will try to create one.
>   *
>   * Calling this function on a connector where the panel_orientation has
>   * already been set is a no-op (e.g. the orientation has been overridden with
> @@ -2373,19 +2373,12 @@ int drm_connector_set_panel_orientation(
>  	info->panel_orientation = panel_orientation;
>  
>  	prop = dev->mode_config.panel_orientation_property;
> -	if (!prop) {
> -		prop = drm_property_create_enum(dev, DRM_MODE_PROP_IMMUTABLE,
> -				"panel orientation",
> -				drm_panel_orientation_enum_list,
> -				ARRAY_SIZE(drm_panel_orientation_enum_list));
> -		if (!prop)
> -			return -ENOMEM;
> -
> -		dev->mode_config.panel_orientation_property = prop;
> -	}
> +	if (!prop &&
> +	    drm_connector_init_panel_orientation_property(connector) < 0)
> +		return -ENOMEM;
>

In the case where the property has not been created beforehand, you
forgot to reinitialize prop here, after calling
drm_connector_init_panel_orientation_property().  This means
drm_object_property_set_value() will be called with a NULL second argument
and Oops the kernel.


> -	drm_object_attach_property(&connector->base, prop,
> -				   info->panel_orientation);
> +	drm_object_property_set_value(&connector->base, prop,
> +				      info->panel_orientation);


-- 
Gabriel Krisman Bertazi

Re: [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Hsin-Yi Wang]

On Tue, Feb 15, 2022 at 9:17 AM Gabriel Krisman Bertazi
<krisman@collabora.com> wrote:
>
> Hsin-Yi Wang <hsinyi@chromium.org> writes:
>
> > drm_dev_register() sets connector->registration_state to
> > DRM_CONNECTOR_REGISTERED and dev->registered to true. If
> > drm_connector_set_panel_orientation() is first called after
> > drm_dev_register(), it will fail several checks and results in following
> > warning.
>
> Hi,
>
> I stumbled upon this when investigating the same WARN_ON on amdgpu.
> Thanks for the patch :)
>
> > diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> > index a50c82bc2b2fec..572ead7ac10690 100644
> > --- a/drivers/gpu/drm/drm_connector.c
> > +++ b/drivers/gpu/drm/drm_connector.c
> > @@ -1252,7 +1252,7 @@ static const struct drm_prop_enum_list dp_colorspaces[] = {
> >   *   INPUT_PROP_DIRECT) will still map 1:1 to the actual LCD panel
> >   *   coordinates, so if userspace rotates the picture to adjust for
> >   *   the orientation it must also apply the same transformation to the
> > - *   touchscreen input coordinates. This property is initialized by calling
> > + *   touchscreen input coordinates. This property value is set by calling
> >   *   drm_connector_set_panel_orientation() or
> >   *   drm_connector_set_panel_orientation_with_quirk()
> >   *
> > @@ -2341,8 +2341,8 @@ EXPORT_SYMBOL(drm_connector_set_vrr_capable_property);
> >   * @connector: connector for which to set the panel-orientation property.
> >   * @panel_orientation: drm_panel_orientation value to set
> >   *
> > - * This function sets the connector's panel_orientation and attaches
> > - * a "panel orientation" property to the connector.
> > + * This function sets the connector's panel_orientation value. If the property
> > + * doesn't exist, it will try to create one.
> >   *
> >   * Calling this function on a connector where the panel_orientation has
> >   * already been set is a no-op (e.g. the orientation has been overridden with
> > @@ -2373,19 +2373,12 @@ int drm_connector_set_panel_orientation(
> >       info->panel_orientation = panel_orientation;
> >
> >       prop = dev->mode_config.panel_orientation_property;
> > -     if (!prop) {
> > -             prop = drm_property_create_enum(dev, DRM_MODE_PROP_IMMUTABLE,
> > -                             "panel orientation",
> > -                             drm_panel_orientation_enum_list,
> > -                             ARRAY_SIZE(drm_panel_orientation_enum_list));
> > -             if (!prop)
> > -                     return -ENOMEM;
> > -
> > -             dev->mode_config.panel_orientation_property = prop;
> > -     }
> > +     if (!prop &&
> > +         drm_connector_init_panel_orientation_property(connector) < 0)
> > +             return -ENOMEM;
> >
>
> In the case where the property has not been created beforehand, you
> forgot to reinitialize prop here, after calling
> drm_connector_init_panel_orientation_property().  This means
hi Gabriel,

drm_connector_init_panel_orientation_property() will create prop if
it's null. If prop fails to be created there, it will return -ENOMEM.

> drm_object_property_set_value() will be called with a NULL second argument
> and Oops the kernel.
>
>
> > -     drm_object_attach_property(&connector->base, prop,
> > -                                info->panel_orientation);
> > +     drm_object_property_set_value(&connector->base, prop,
> > +                                   info->panel_orientation);
>
>
> --
> Gabriel Krisman Bertazi

Re: [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Hsin-Yi Wang]

On Tue, Feb 15, 2022 at 9:17 AM Gabriel Krisman Bertazi
<krisman@collabora.com> wrote:
>
> Hsin-Yi Wang <hsinyi@chromium.org> writes:
>
> > drm_dev_register() sets connector->registration_state to
> > DRM_CONNECTOR_REGISTERED and dev->registered to true. If
> > drm_connector_set_panel_orientation() is first called after
> > drm_dev_register(), it will fail several checks and results in following
> > warning.
>
> Hi,
>
> I stumbled upon this when investigating the same WARN_ON on amdgpu.
> Thanks for the patch :)
>
> > diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> > index a50c82bc2b2fec..572ead7ac10690 100644
> > --- a/drivers/gpu/drm/drm_connector.c
> > +++ b/drivers/gpu/drm/drm_connector.c
> > @@ -1252,7 +1252,7 @@ static const struct drm_prop_enum_list dp_colorspaces[] = {
> >   *   INPUT_PROP_DIRECT) will still map 1:1 to the actual LCD panel
> >   *   coordinates, so if userspace rotates the picture to adjust for
> >   *   the orientation it must also apply the same transformation to the
> > - *   touchscreen input coordinates. This property is initialized by calling
> > + *   touchscreen input coordinates. This property value is set by calling
> >   *   drm_connector_set_panel_orientation() or
> >   *   drm_connector_set_panel_orientation_with_quirk()
> >   *
> > @@ -2341,8 +2341,8 @@ EXPORT_SYMBOL(drm_connector_set_vrr_capable_property);
> >   * @connector: connector for which to set the panel-orientation property.
> >   * @panel_orientation: drm_panel_orientation value to set
> >   *
> > - * This function sets the connector's panel_orientation and attaches
> > - * a "panel orientation" property to the connector.
> > + * This function sets the connector's panel_orientation value. If the property
> > + * doesn't exist, it will try to create one.
> >   *
> >   * Calling this function on a connector where the panel_orientation has
> >   * already been set is a no-op (e.g. the orientation has been overridden with
> > @@ -2373,19 +2373,12 @@ int drm_connector_set_panel_orientation(
> >       info->panel_orientation = panel_orientation;
> >
> >       prop = dev->mode_config.panel_orientation_property;
> > -     if (!prop) {
> > -             prop = drm_property_create_enum(dev, DRM_MODE_PROP_IMMUTABLE,
> > -                             "panel orientation",
> > -                             drm_panel_orientation_enum_list,
> > -                             ARRAY_SIZE(drm_panel_orientation_enum_list));
> > -             if (!prop)
> > -                     return -ENOMEM;
> > -
> > -             dev->mode_config.panel_orientation_property = prop;
> > -     }
> > +     if (!prop &&
> > +         drm_connector_init_panel_orientation_property(connector) < 0)
> > +             return -ENOMEM;
> >
>
> In the case where the property has not been created beforehand, you
> forgot to reinitialize prop here, after calling
> drm_connector_init_panel_orientation_property().  This means
hi Gabriel,

drm_connector_init_panel_orientation_property() will create prop if
it's null. If prop fails to be created there, it will return -ENOMEM.

> drm_object_property_set_value() will be called with a NULL second argument
> and Oops the kernel.
>
>
> > -     drm_object_attach_property(&connector->base, prop,
> > -                                info->panel_orientation);
> > +     drm_object_property_set_value(&connector->base, prop,
> > +                                   info->panel_orientation);
>
>
> --
> Gabriel Krisman Bertazi

Re: [Intel-gfx] [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Hsin-Yi Wang]

On Tue, Feb 15, 2022 at 9:17 AM Gabriel Krisman Bertazi
<krisman@collabora.com> wrote:
>
> Hsin-Yi Wang <hsinyi@chromium.org> writes:
>
> > drm_dev_register() sets connector->registration_state to
> > DRM_CONNECTOR_REGISTERED and dev->registered to true. If
> > drm_connector_set_panel_orientation() is first called after
> > drm_dev_register(), it will fail several checks and results in following
> > warning.
>
> Hi,
>
> I stumbled upon this when investigating the same WARN_ON on amdgpu.
> Thanks for the patch :)
>
> > diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> > index a50c82bc2b2fec..572ead7ac10690 100644
> > --- a/drivers/gpu/drm/drm_connector.c
> > +++ b/drivers/gpu/drm/drm_connector.c
> > @@ -1252,7 +1252,7 @@ static const struct drm_prop_enum_list dp_colorspaces[] = {
> >   *   INPUT_PROP_DIRECT) will still map 1:1 to the actual LCD panel
> >   *   coordinates, so if userspace rotates the picture to adjust for
> >   *   the orientation it must also apply the same transformation to the
> > - *   touchscreen input coordinates. This property is initialized by calling
> > + *   touchscreen input coordinates. This property value is set by calling
> >   *   drm_connector_set_panel_orientation() or
> >   *   drm_connector_set_panel_orientation_with_quirk()
> >   *
> > @@ -2341,8 +2341,8 @@ EXPORT_SYMBOL(drm_connector_set_vrr_capable_property);
> >   * @connector: connector for which to set the panel-orientation property.
> >   * @panel_orientation: drm_panel_orientation value to set
> >   *
> > - * This function sets the connector's panel_orientation and attaches
> > - * a "panel orientation" property to the connector.
> > + * This function sets the connector's panel_orientation value. If the property
> > + * doesn't exist, it will try to create one.
> >   *
> >   * Calling this function on a connector where the panel_orientation has
> >   * already been set is a no-op (e.g. the orientation has been overridden with
> > @@ -2373,19 +2373,12 @@ int drm_connector_set_panel_orientation(
> >       info->panel_orientation = panel_orientation;
> >
> >       prop = dev->mode_config.panel_orientation_property;
> > -     if (!prop) {
> > -             prop = drm_property_create_enum(dev, DRM_MODE_PROP_IMMUTABLE,
> > -                             "panel orientation",
> > -                             drm_panel_orientation_enum_list,
> > -                             ARRAY_SIZE(drm_panel_orientation_enum_list));
> > -             if (!prop)
> > -                     return -ENOMEM;
> > -
> > -             dev->mode_config.panel_orientation_property = prop;
> > -     }
> > +     if (!prop &&
> > +         drm_connector_init_panel_orientation_property(connector) < 0)
> > +             return -ENOMEM;
> >
>
> In the case where the property has not been created beforehand, you
> forgot to reinitialize prop here, after calling
> drm_connector_init_panel_orientation_property().  This means
hi Gabriel,

drm_connector_init_panel_orientation_property() will create prop if
it's null. If prop fails to be created there, it will return -ENOMEM.

> drm_object_property_set_value() will be called with a NULL second argument
> and Oops the kernel.
>
>
> > -     drm_object_attach_property(&connector->base, prop,
> > -                                info->panel_orientation);
> > +     drm_object_property_set_value(&connector->base, prop,
> > +                                   info->panel_orientation);
>
>
> --
> Gabriel Krisman Bertazi

Re: [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Hsin-Yi Wang]

On Tue, Feb 15, 2022 at 9:17 AM Gabriel Krisman Bertazi
<krisman@collabora.com> wrote:
>
> Hsin-Yi Wang <hsinyi@chromium.org> writes:
>
> > drm_dev_register() sets connector->registration_state to
> > DRM_CONNECTOR_REGISTERED and dev->registered to true. If
> > drm_connector_set_panel_orientation() is first called after
> > drm_dev_register(), it will fail several checks and results in following
> > warning.
>
> Hi,
>
> I stumbled upon this when investigating the same WARN_ON on amdgpu.
> Thanks for the patch :)
>
> > diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> > index a50c82bc2b2fec..572ead7ac10690 100644
> > --- a/drivers/gpu/drm/drm_connector.c
> > +++ b/drivers/gpu/drm/drm_connector.c
> > @@ -1252,7 +1252,7 @@ static const struct drm_prop_enum_list dp_colorspaces[] = {
> >   *   INPUT_PROP_DIRECT) will still map 1:1 to the actual LCD panel
> >   *   coordinates, so if userspace rotates the picture to adjust for
> >   *   the orientation it must also apply the same transformation to the
> > - *   touchscreen input coordinates. This property is initialized by calling
> > + *   touchscreen input coordinates. This property value is set by calling
> >   *   drm_connector_set_panel_orientation() or
> >   *   drm_connector_set_panel_orientation_with_quirk()
> >   *
> > @@ -2341,8 +2341,8 @@ EXPORT_SYMBOL(drm_connector_set_vrr_capable_property);
> >   * @connector: connector for which to set the panel-orientation property.
> >   * @panel_orientation: drm_panel_orientation value to set
> >   *
> > - * This function sets the connector's panel_orientation and attaches
> > - * a "panel orientation" property to the connector.
> > + * This function sets the connector's panel_orientation value. If the property
> > + * doesn't exist, it will try to create one.
> >   *
> >   * Calling this function on a connector where the panel_orientation has
> >   * already been set is a no-op (e.g. the orientation has been overridden with
> > @@ -2373,19 +2373,12 @@ int drm_connector_set_panel_orientation(
> >       info->panel_orientation = panel_orientation;
> >
> >       prop = dev->mode_config.panel_orientation_property;
> > -     if (!prop) {
> > -             prop = drm_property_create_enum(dev, DRM_MODE_PROP_IMMUTABLE,
> > -                             "panel orientation",
> > -                             drm_panel_orientation_enum_list,
> > -                             ARRAY_SIZE(drm_panel_orientation_enum_list));
> > -             if (!prop)
> > -                     return -ENOMEM;
> > -
> > -             dev->mode_config.panel_orientation_property = prop;
> > -     }
> > +     if (!prop &&
> > +         drm_connector_init_panel_orientation_property(connector) < 0)
> > +             return -ENOMEM;
> >
>
> In the case where the property has not been created beforehand, you
> forgot to reinitialize prop here, after calling
> drm_connector_init_panel_orientation_property().  This means
hi Gabriel,

drm_connector_init_panel_orientation_property() will create prop if
it's null. If prop fails to be created there, it will return -ENOMEM.

> drm_object_property_set_value() will be called with a NULL second argument
> and Oops the kernel.
>
>
> > -     drm_object_attach_property(&connector->base, prop,
> > -                                info->panel_orientation);
> > +     drm_object_property_set_value(&connector->base, prop,
> > +                                   info->panel_orientation);
>
>
> --
> Gabriel Krisman Bertazi

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

Re: [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Hsin-Yi Wang]

On Tue, Feb 15, 2022 at 9:17 AM Gabriel Krisman Bertazi
<krisman@collabora.com> wrote:
>
> Hsin-Yi Wang <hsinyi@chromium.org> writes:
>
> > drm_dev_register() sets connector->registration_state to
> > DRM_CONNECTOR_REGISTERED and dev->registered to true. If
> > drm_connector_set_panel_orientation() is first called after
> > drm_dev_register(), it will fail several checks and results in following
> > warning.
>
> Hi,
>
> I stumbled upon this when investigating the same WARN_ON on amdgpu.
> Thanks for the patch :)
>
> > diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> > index a50c82bc2b2fec..572ead7ac10690 100644
> > --- a/drivers/gpu/drm/drm_connector.c
> > +++ b/drivers/gpu/drm/drm_connector.c
> > @@ -1252,7 +1252,7 @@ static const struct drm_prop_enum_list dp_colorspaces[] = {
> >   *   INPUT_PROP_DIRECT) will still map 1:1 to the actual LCD panel
> >   *   coordinates, so if userspace rotates the picture to adjust for
> >   *   the orientation it must also apply the same transformation to the
> > - *   touchscreen input coordinates. This property is initialized by calling
> > + *   touchscreen input coordinates. This property value is set by calling
> >   *   drm_connector_set_panel_orientation() or
> >   *   drm_connector_set_panel_orientation_with_quirk()
> >   *
> > @@ -2341,8 +2341,8 @@ EXPORT_SYMBOL(drm_connector_set_vrr_capable_property);
> >   * @connector: connector for which to set the panel-orientation property.
> >   * @panel_orientation: drm_panel_orientation value to set
> >   *
> > - * This function sets the connector's panel_orientation and attaches
> > - * a "panel orientation" property to the connector.
> > + * This function sets the connector's panel_orientation value. If the property
> > + * doesn't exist, it will try to create one.
> >   *
> >   * Calling this function on a connector where the panel_orientation has
> >   * already been set is a no-op (e.g. the orientation has been overridden with
> > @@ -2373,19 +2373,12 @@ int drm_connector_set_panel_orientation(
> >       info->panel_orientation = panel_orientation;
> >
> >       prop = dev->mode_config.panel_orientation_property;
> > -     if (!prop) {
> > -             prop = drm_property_create_enum(dev, DRM_MODE_PROP_IMMUTABLE,
> > -                             "panel orientation",
> > -                             drm_panel_orientation_enum_list,
> > -                             ARRAY_SIZE(drm_panel_orientation_enum_list));
> > -             if (!prop)
> > -                     return -ENOMEM;
> > -
> > -             dev->mode_config.panel_orientation_property = prop;
> > -     }
> > +     if (!prop &&
> > +         drm_connector_init_panel_orientation_property(connector) < 0)
> > +             return -ENOMEM;
> >
>
> In the case where the property has not been created beforehand, you
> forgot to reinitialize prop here, after calling
> drm_connector_init_panel_orientation_property().  This means
hi Gabriel,

drm_connector_init_panel_orientation_property() will create prop if
it's null. If prop fails to be created there, it will return -ENOMEM.

> drm_object_property_set_value() will be called with a NULL second argument
> and Oops the kernel.
>
>
> > -     drm_object_attach_property(&connector->base, prop,
> > -                                info->panel_orientation);
> > +     drm_object_property_set_value(&connector->base, prop,
> > +                                   info->panel_orientation);
>
>
> --
> Gabriel Krisman Bertazi

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Hsin-Yi Wang]

On Tue, Feb 15, 2022 at 9:17 AM Gabriel Krisman Bertazi
<krisman@collabora.com> wrote:
>
> Hsin-Yi Wang <hsinyi@chromium.org> writes:
>
> > drm_dev_register() sets connector->registration_state to
> > DRM_CONNECTOR_REGISTERED and dev->registered to true. If
> > drm_connector_set_panel_orientation() is first called after
> > drm_dev_register(), it will fail several checks and results in following
> > warning.
>
> Hi,
>
> I stumbled upon this when investigating the same WARN_ON on amdgpu.
> Thanks for the patch :)
>
> > diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> > index a50c82bc2b2fec..572ead7ac10690 100644
> > --- a/drivers/gpu/drm/drm_connector.c
> > +++ b/drivers/gpu/drm/drm_connector.c
> > @@ -1252,7 +1252,7 @@ static const struct drm_prop_enum_list dp_colorspaces[] = {
> >   *   INPUT_PROP_DIRECT) will still map 1:1 to the actual LCD panel
> >   *   coordinates, so if userspace rotates the picture to adjust for
> >   *   the orientation it must also apply the same transformation to the
> > - *   touchscreen input coordinates. This property is initialized by calling
> > + *   touchscreen input coordinates. This property value is set by calling
> >   *   drm_connector_set_panel_orientation() or
> >   *   drm_connector_set_panel_orientation_with_quirk()
> >   *
> > @@ -2341,8 +2341,8 @@ EXPORT_SYMBOL(drm_connector_set_vrr_capable_property);
> >   * @connector: connector for which to set the panel-orientation property.
> >   * @panel_orientation: drm_panel_orientation value to set
> >   *
> > - * This function sets the connector's panel_orientation and attaches
> > - * a "panel orientation" property to the connector.
> > + * This function sets the connector's panel_orientation value. If the property
> > + * doesn't exist, it will try to create one.
> >   *
> >   * Calling this function on a connector where the panel_orientation has
> >   * already been set is a no-op (e.g. the orientation has been overridden with
> > @@ -2373,19 +2373,12 @@ int drm_connector_set_panel_orientation(
> >       info->panel_orientation = panel_orientation;
> >
> >       prop = dev->mode_config.panel_orientation_property;
> > -     if (!prop) {
> > -             prop = drm_property_create_enum(dev, DRM_MODE_PROP_IMMUTABLE,
> > -                             "panel orientation",
> > -                             drm_panel_orientation_enum_list,
> > -                             ARRAY_SIZE(drm_panel_orientation_enum_list));
> > -             if (!prop)
> > -                     return -ENOMEM;
> > -
> > -             dev->mode_config.panel_orientation_property = prop;
> > -     }
> > +     if (!prop &&
> > +         drm_connector_init_panel_orientation_property(connector) < 0)
> > +             return -ENOMEM;
> >
>
> In the case where the property has not been created beforehand, you
> forgot to reinitialize prop here, after calling
> drm_connector_init_panel_orientation_property().  This means
hi Gabriel,

drm_connector_init_panel_orientation_property() will create prop if
it's null. If prop fails to be created there, it will return -ENOMEM.

> drm_object_property_set_value() will be called with a NULL second argument
> and Oops the kernel.
>
>
> > -     drm_object_attach_property(&connector->base, prop,
> > -                                info->panel_orientation);
> > +     drm_object_property_set_value(&connector->base, prop,
> > +                                   info->panel_orientation);
>
>
> --
> Gabriel Krisman Bertazi

Re: [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Gabriel Krisman Bertazi]

Hsin-Yi Wang <hsinyi@chromium.org> writes:

> On Tue, Feb 15, 2022 at 9:17 AM Gabriel Krisman Bertazi
> <krisman@collabora.com> wrote:
>>
>> Hsin-Yi Wang <hsinyi@chromium.org> writes:
>>
>> > drm_dev_register() sets connector->registration_state to
>> > DRM_CONNECTOR_REGISTERED and dev->registered to true. If
>> > drm_connector_set_panel_orientation() is first called after
>> > drm_dev_register(), it will fail several checks and results in following
>> > warning.
>>
>> Hi,
>>
>> I stumbled upon this when investigating the same WARN_ON on amdgpu.
>> Thanks for the patch :)
>>
>> > diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
>> > index a50c82bc2b2fec..572ead7ac10690 100644
>> > --- a/drivers/gpu/drm/drm_connector.c
>> > +++ b/drivers/gpu/drm/drm_connector.c
>> > @@ -1252,7 +1252,7 @@ static const struct drm_prop_enum_list dp_colorspaces[] = {
>> >   *   INPUT_PROP_DIRECT) will still map 1:1 to the actual LCD panel
>> >   *   coordinates, so if userspace rotates the picture to adjust for
>> >   *   the orientation it must also apply the same transformation to the
>> > - *   touchscreen input coordinates. This property is initialized by calling
>> > + *   touchscreen input coordinates. This property value is set by calling
>> >   *   drm_connector_set_panel_orientation() or
>> >   *   drm_connector_set_panel_orientation_with_quirk()
>> >   *
>> > @@ -2341,8 +2341,8 @@ EXPORT_SYMBOL(drm_connector_set_vrr_capable_property);
>> >   * @connector: connector for which to set the panel-orientation property.
>> >   * @panel_orientation: drm_panel_orientation value to set
>> >   *
>> > - * This function sets the connector's panel_orientation and attaches
>> > - * a "panel orientation" property to the connector.
>> > + * This function sets the connector's panel_orientation value. If the property
>> > + * doesn't exist, it will try to create one.
>> >   *
>> >   * Calling this function on a connector where the panel_orientation has
>> >   * already been set is a no-op (e.g. the orientation has been overridden with
>> > @@ -2373,19 +2373,12 @@ int drm_connector_set_panel_orientation(
>> >       info->panel_orientation = panel_orientation;
>> >
>> >       prop = dev->mode_config.panel_orientation_property;
>> > -     if (!prop) {
>> > -             prop = drm_property_create_enum(dev, DRM_MODE_PROP_IMMUTABLE,
>> > -                             "panel orientation",
>> > -                             drm_panel_orientation_enum_list,
>> > -                             ARRAY_SIZE(drm_panel_orientation_enum_list));
>> > -             if (!prop)
>> > -                     return -ENOMEM;
>> > -
>> > -             dev->mode_config.panel_orientation_property = prop;
>> > -     }
>> > +     if (!prop &&
>> > +         drm_connector_init_panel_orientation_property(connector) < 0)
>> > +             return -ENOMEM;
>> >
>>
>> In the case where the property has not been created beforehand, you
>> forgot to reinitialize prop here, after calling
>> drm_connector_init_panel_orientation_property().  This means
> hi Gabriel,
>
> drm_connector_init_panel_orientation_property() will create prop if
> it's null. If prop fails to be created there, it will return -ENOMEM.

Yes.  But *after the property is successfully created*, the prop variable is still
NULL.  And then you call the following, using prop, which is still NULL:

>> > +     drm_object_property_set_value(&connector->base, prop,
>> > +                                   info->panel_orientation);

This will do property->dev right on the first line of code, and dereference the
null prop pointer.

You must do

  prop = dev->mode_config.panel_orientation_property;

again after drm_connector_init_panel_orientation_property successfully
returns, or call drm_object_property_set_value using
dev->mode_config.panel_orientation_property directly:

  drm_object_property_set_value(&connector->base,
			dev->mode_config.panel_orientation_property
		        info->panel_orientation);

-- 
Gabriel Krisman Bertazi

Re: [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Gabriel Krisman Bertazi]

Hsin-Yi Wang <hsinyi@chromium.org> writes:

> On Tue, Feb 15, 2022 at 9:17 AM Gabriel Krisman Bertazi
> <krisman@collabora.com> wrote:
>>
>> Hsin-Yi Wang <hsinyi@chromium.org> writes:
>>
>> > drm_dev_register() sets connector->registration_state to
>> > DRM_CONNECTOR_REGISTERED and dev->registered to true. If
>> > drm_connector_set_panel_orientation() is first called after
>> > drm_dev_register(), it will fail several checks and results in following
>> > warning.
>>
>> Hi,
>>
>> I stumbled upon this when investigating the same WARN_ON on amdgpu.
>> Thanks for the patch :)
>>
>> > diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
>> > index a50c82bc2b2fec..572ead7ac10690 100644
>> > --- a/drivers/gpu/drm/drm_connector.c
>> > +++ b/drivers/gpu/drm/drm_connector.c
>> > @@ -1252,7 +1252,7 @@ static const struct drm_prop_enum_list dp_colorspaces[] = {
>> >   *   INPUT_PROP_DIRECT) will still map 1:1 to the actual LCD panel
>> >   *   coordinates, so if userspace rotates the picture to adjust for
>> >   *   the orientation it must also apply the same transformation to the
>> > - *   touchscreen input coordinates. This property is initialized by calling
>> > + *   touchscreen input coordinates. This property value is set by calling
>> >   *   drm_connector_set_panel_orientation() or
>> >   *   drm_connector_set_panel_orientation_with_quirk()
>> >   *
>> > @@ -2341,8 +2341,8 @@ EXPORT_SYMBOL(drm_connector_set_vrr_capable_property);
>> >   * @connector: connector for which to set the panel-orientation property.
>> >   * @panel_orientation: drm_panel_orientation value to set
>> >   *
>> > - * This function sets the connector's panel_orientation and attaches
>> > - * a "panel orientation" property to the connector.
>> > + * This function sets the connector's panel_orientation value. If the property
>> > + * doesn't exist, it will try to create one.
>> >   *
>> >   * Calling this function on a connector where the panel_orientation has
>> >   * already been set is a no-op (e.g. the orientation has been overridden with
>> > @@ -2373,19 +2373,12 @@ int drm_connector_set_panel_orientation(
>> >       info->panel_orientation = panel_orientation;
>> >
>> >       prop = dev->mode_config.panel_orientation_property;
>> > -     if (!prop) {
>> > -             prop = drm_property_create_enum(dev, DRM_MODE_PROP_IMMUTABLE,
>> > -                             "panel orientation",
>> > -                             drm_panel_orientation_enum_list,
>> > -                             ARRAY_SIZE(drm_panel_orientation_enum_list));
>> > -             if (!prop)
>> > -                     return -ENOMEM;
>> > -
>> > -             dev->mode_config.panel_orientation_property = prop;
>> > -     }
>> > +     if (!prop &&
>> > +         drm_connector_init_panel_orientation_property(connector) < 0)
>> > +             return -ENOMEM;
>> >
>>
>> In the case where the property has not been created beforehand, you
>> forgot to reinitialize prop here, after calling
>> drm_connector_init_panel_orientation_property().  This means
> hi Gabriel,
>
> drm_connector_init_panel_orientation_property() will create prop if
> it's null. If prop fails to be created there, it will return -ENOMEM.

Yes.  But *after the property is successfully created*, the prop variable is still
NULL.  And then you call the following, using prop, which is still NULL:

>> > +     drm_object_property_set_value(&connector->base, prop,
>> > +                                   info->panel_orientation);

This will do property->dev right on the first line of code, and dereference the
null prop pointer.

You must do

  prop = dev->mode_config.panel_orientation_property;

again after drm_connector_init_panel_orientation_property successfully
returns, or call drm_object_property_set_value using
dev->mode_config.panel_orientation_property directly:

  drm_object_property_set_value(&connector->base,
			dev->mode_config.panel_orientation_property
		        info->panel_orientation);

-- 
Gabriel Krisman Bertazi

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

Re: [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Gabriel Krisman Bertazi]

Hsin-Yi Wang <hsinyi@chromium.org> writes:

> On Tue, Feb 15, 2022 at 9:17 AM Gabriel Krisman Bertazi
> <krisman@collabora.com> wrote:
>>
>> Hsin-Yi Wang <hsinyi@chromium.org> writes:
>>
>> > drm_dev_register() sets connector->registration_state to
>> > DRM_CONNECTOR_REGISTERED and dev->registered to true. If
>> > drm_connector_set_panel_orientation() is first called after
>> > drm_dev_register(), it will fail several checks and results in following
>> > warning.
>>
>> Hi,
>>
>> I stumbled upon this when investigating the same WARN_ON on amdgpu.
>> Thanks for the patch :)
>>
>> > diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
>> > index a50c82bc2b2fec..572ead7ac10690 100644
>> > --- a/drivers/gpu/drm/drm_connector.c
>> > +++ b/drivers/gpu/drm/drm_connector.c
>> > @@ -1252,7 +1252,7 @@ static const struct drm_prop_enum_list dp_colorspaces[] = {
>> >   *   INPUT_PROP_DIRECT) will still map 1:1 to the actual LCD panel
>> >   *   coordinates, so if userspace rotates the picture to adjust for
>> >   *   the orientation it must also apply the same transformation to the
>> > - *   touchscreen input coordinates. This property is initialized by calling
>> > + *   touchscreen input coordinates. This property value is set by calling
>> >   *   drm_connector_set_panel_orientation() or
>> >   *   drm_connector_set_panel_orientation_with_quirk()
>> >   *
>> > @@ -2341,8 +2341,8 @@ EXPORT_SYMBOL(drm_connector_set_vrr_capable_property);
>> >   * @connector: connector for which to set the panel-orientation property.
>> >   * @panel_orientation: drm_panel_orientation value to set
>> >   *
>> > - * This function sets the connector's panel_orientation and attaches
>> > - * a "panel orientation" property to the connector.
>> > + * This function sets the connector's panel_orientation value. If the property
>> > + * doesn't exist, it will try to create one.
>> >   *
>> >   * Calling this function on a connector where the panel_orientation has
>> >   * already been set is a no-op (e.g. the orientation has been overridden with
>> > @@ -2373,19 +2373,12 @@ int drm_connector_set_panel_orientation(
>> >       info->panel_orientation = panel_orientation;
>> >
>> >       prop = dev->mode_config.panel_orientation_property;
>> > -     if (!prop) {
>> > -             prop = drm_property_create_enum(dev, DRM_MODE_PROP_IMMUTABLE,
>> > -                             "panel orientation",
>> > -                             drm_panel_orientation_enum_list,
>> > -                             ARRAY_SIZE(drm_panel_orientation_enum_list));
>> > -             if (!prop)
>> > -                     return -ENOMEM;
>> > -
>> > -             dev->mode_config.panel_orientation_property = prop;
>> > -     }
>> > +     if (!prop &&
>> > +         drm_connector_init_panel_orientation_property(connector) < 0)
>> > +             return -ENOMEM;
>> >
>>
>> In the case where the property has not been created beforehand, you
>> forgot to reinitialize prop here, after calling
>> drm_connector_init_panel_orientation_property().  This means
> hi Gabriel,
>
> drm_connector_init_panel_orientation_property() will create prop if
> it's null. If prop fails to be created there, it will return -ENOMEM.

Yes.  But *after the property is successfully created*, the prop variable is still
NULL.  And then you call the following, using prop, which is still NULL:

>> > +     drm_object_property_set_value(&connector->base, prop,
>> > +                                   info->panel_orientation);

This will do property->dev right on the first line of code, and dereference the
null prop pointer.

You must do

  prop = dev->mode_config.panel_orientation_property;

again after drm_connector_init_panel_orientation_property successfully
returns, or call drm_object_property_set_value using
dev->mode_config.panel_orientation_property directly:

  drm_object_property_set_value(&connector->base,
			dev->mode_config.panel_orientation_property
		        info->panel_orientation);

-- 
Gabriel Krisman Bertazi

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Gabriel Krisman Bertazi]

Hsin-Yi Wang <hsinyi@chromium.org> writes:

> On Tue, Feb 15, 2022 at 9:17 AM Gabriel Krisman Bertazi
> <krisman@collabora.com> wrote:
>>
>> Hsin-Yi Wang <hsinyi@chromium.org> writes:
>>
>> > drm_dev_register() sets connector->registration_state to
>> > DRM_CONNECTOR_REGISTERED and dev->registered to true. If
>> > drm_connector_set_panel_orientation() is first called after
>> > drm_dev_register(), it will fail several checks and results in following
>> > warning.
>>
>> Hi,
>>
>> I stumbled upon this when investigating the same WARN_ON on amdgpu.
>> Thanks for the patch :)
>>
>> > diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
>> > index a50c82bc2b2fec..572ead7ac10690 100644
>> > --- a/drivers/gpu/drm/drm_connector.c
>> > +++ b/drivers/gpu/drm/drm_connector.c
>> > @@ -1252,7 +1252,7 @@ static const struct drm_prop_enum_list dp_colorspaces[] = {
>> >   *   INPUT_PROP_DIRECT) will still map 1:1 to the actual LCD panel
>> >   *   coordinates, so if userspace rotates the picture to adjust for
>> >   *   the orientation it must also apply the same transformation to the
>> > - *   touchscreen input coordinates. This property is initialized by calling
>> > + *   touchscreen input coordinates. This property value is set by calling
>> >   *   drm_connector_set_panel_orientation() or
>> >   *   drm_connector_set_panel_orientation_with_quirk()
>> >   *
>> > @@ -2341,8 +2341,8 @@ EXPORT_SYMBOL(drm_connector_set_vrr_capable_property);
>> >   * @connector: connector for which to set the panel-orientation property.
>> >   * @panel_orientation: drm_panel_orientation value to set
>> >   *
>> > - * This function sets the connector's panel_orientation and attaches
>> > - * a "panel orientation" property to the connector.
>> > + * This function sets the connector's panel_orientation value. If the property
>> > + * doesn't exist, it will try to create one.
>> >   *
>> >   * Calling this function on a connector where the panel_orientation has
>> >   * already been set is a no-op (e.g. the orientation has been overridden with
>> > @@ -2373,19 +2373,12 @@ int drm_connector_set_panel_orientation(
>> >       info->panel_orientation = panel_orientation;
>> >
>> >       prop = dev->mode_config.panel_orientation_property;
>> > -     if (!prop) {
>> > -             prop = drm_property_create_enum(dev, DRM_MODE_PROP_IMMUTABLE,
>> > -                             "panel orientation",
>> > -                             drm_panel_orientation_enum_list,
>> > -                             ARRAY_SIZE(drm_panel_orientation_enum_list));
>> > -             if (!prop)
>> > -                     return -ENOMEM;
>> > -
>> > -             dev->mode_config.panel_orientation_property = prop;
>> > -     }
>> > +     if (!prop &&
>> > +         drm_connector_init_panel_orientation_property(connector) < 0)
>> > +             return -ENOMEM;
>> >
>>
>> In the case where the property has not been created beforehand, you
>> forgot to reinitialize prop here, after calling
>> drm_connector_init_panel_orientation_property().  This means
> hi Gabriel,
>
> drm_connector_init_panel_orientation_property() will create prop if
> it's null. If prop fails to be created there, it will return -ENOMEM.

Yes.  But *after the property is successfully created*, the prop variable is still
NULL.  And then you call the following, using prop, which is still NULL:

>> > +     drm_object_property_set_value(&connector->base, prop,
>> > +                                   info->panel_orientation);

This will do property->dev right on the first line of code, and dereference the
null prop pointer.

You must do

  prop = dev->mode_config.panel_orientation_property;

again after drm_connector_init_panel_orientation_property successfully
returns, or call drm_object_property_set_value using
dev->mode_config.panel_orientation_property directly:

  drm_object_property_set_value(&connector->base,
			dev->mode_config.panel_orientation_property
		        info->panel_orientation);

-- 
Gabriel Krisman Bertazi

Re: [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Gabriel Krisman Bertazi]

Hsin-Yi Wang <hsinyi@chromium.org> writes:

> On Tue, Feb 15, 2022 at 9:17 AM Gabriel Krisman Bertazi
> <krisman@collabora.com> wrote:
>>
>> Hsin-Yi Wang <hsinyi@chromium.org> writes:
>>
>> > drm_dev_register() sets connector->registration_state to
>> > DRM_CONNECTOR_REGISTERED and dev->registered to true. If
>> > drm_connector_set_panel_orientation() is first called after
>> > drm_dev_register(), it will fail several checks and results in following
>> > warning.
>>
>> Hi,
>>
>> I stumbled upon this when investigating the same WARN_ON on amdgpu.
>> Thanks for the patch :)
>>
>> > diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
>> > index a50c82bc2b2fec..572ead7ac10690 100644
>> > --- a/drivers/gpu/drm/drm_connector.c
>> > +++ b/drivers/gpu/drm/drm_connector.c
>> > @@ -1252,7 +1252,7 @@ static const struct drm_prop_enum_list dp_colorspaces[] = {
>> >   *   INPUT_PROP_DIRECT) will still map 1:1 to the actual LCD panel
>> >   *   coordinates, so if userspace rotates the picture to adjust for
>> >   *   the orientation it must also apply the same transformation to the
>> > - *   touchscreen input coordinates. This property is initialized by calling
>> > + *   touchscreen input coordinates. This property value is set by calling
>> >   *   drm_connector_set_panel_orientation() or
>> >   *   drm_connector_set_panel_orientation_with_quirk()
>> >   *
>> > @@ -2341,8 +2341,8 @@ EXPORT_SYMBOL(drm_connector_set_vrr_capable_property);
>> >   * @connector: connector for which to set the panel-orientation property.
>> >   * @panel_orientation: drm_panel_orientation value to set
>> >   *
>> > - * This function sets the connector's panel_orientation and attaches
>> > - * a "panel orientation" property to the connector.
>> > + * This function sets the connector's panel_orientation value. If the property
>> > + * doesn't exist, it will try to create one.
>> >   *
>> >   * Calling this function on a connector where the panel_orientation has
>> >   * already been set is a no-op (e.g. the orientation has been overridden with
>> > @@ -2373,19 +2373,12 @@ int drm_connector_set_panel_orientation(
>> >       info->panel_orientation = panel_orientation;
>> >
>> >       prop = dev->mode_config.panel_orientation_property;
>> > -     if (!prop) {
>> > -             prop = drm_property_create_enum(dev, DRM_MODE_PROP_IMMUTABLE,
>> > -                             "panel orientation",
>> > -                             drm_panel_orientation_enum_list,
>> > -                             ARRAY_SIZE(drm_panel_orientation_enum_list));
>> > -             if (!prop)
>> > -                     return -ENOMEM;
>> > -
>> > -             dev->mode_config.panel_orientation_property = prop;
>> > -     }
>> > +     if (!prop &&
>> > +         drm_connector_init_panel_orientation_property(connector) < 0)
>> > +             return -ENOMEM;
>> >
>>
>> In the case where the property has not been created beforehand, you
>> forgot to reinitialize prop here, after calling
>> drm_connector_init_panel_orientation_property().  This means
> hi Gabriel,
>
> drm_connector_init_panel_orientation_property() will create prop if
> it's null. If prop fails to be created there, it will return -ENOMEM.

Yes.  But *after the property is successfully created*, the prop variable is still
NULL.  And then you call the following, using prop, which is still NULL:

>> > +     drm_object_property_set_value(&connector->base, prop,
>> > +                                   info->panel_orientation);

This will do property->dev right on the first line of code, and dereference the
null prop pointer.

You must do

  prop = dev->mode_config.panel_orientation_property;

again after drm_connector_init_panel_orientation_property successfully
returns, or call drm_object_property_set_value using
dev->mode_config.panel_orientation_property directly:

  drm_object_property_set_value(&connector->base,
			dev->mode_config.panel_orientation_property
		        info->panel_orientation);

-- 
Gabriel Krisman Bertazi

Re: [Intel-gfx] [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Gabriel Krisman Bertazi]

Hsin-Yi Wang <hsinyi@chromium.org> writes:

> On Tue, Feb 15, 2022 at 9:17 AM Gabriel Krisman Bertazi
> <krisman@collabora.com> wrote:
>>
>> Hsin-Yi Wang <hsinyi@chromium.org> writes:
>>
>> > drm_dev_register() sets connector->registration_state to
>> > DRM_CONNECTOR_REGISTERED and dev->registered to true. If
>> > drm_connector_set_panel_orientation() is first called after
>> > drm_dev_register(), it will fail several checks and results in following
>> > warning.
>>
>> Hi,
>>
>> I stumbled upon this when investigating the same WARN_ON on amdgpu.
>> Thanks for the patch :)
>>
>> > diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
>> > index a50c82bc2b2fec..572ead7ac10690 100644
>> > --- a/drivers/gpu/drm/drm_connector.c
>> > +++ b/drivers/gpu/drm/drm_connector.c
>> > @@ -1252,7 +1252,7 @@ static const struct drm_prop_enum_list dp_colorspaces[] = {
>> >   *   INPUT_PROP_DIRECT) will still map 1:1 to the actual LCD panel
>> >   *   coordinates, so if userspace rotates the picture to adjust for
>> >   *   the orientation it must also apply the same transformation to the
>> > - *   touchscreen input coordinates. This property is initialized by calling
>> > + *   touchscreen input coordinates. This property value is set by calling
>> >   *   drm_connector_set_panel_orientation() or
>> >   *   drm_connector_set_panel_orientation_with_quirk()
>> >   *
>> > @@ -2341,8 +2341,8 @@ EXPORT_SYMBOL(drm_connector_set_vrr_capable_property);
>> >   * @connector: connector for which to set the panel-orientation property.
>> >   * @panel_orientation: drm_panel_orientation value to set
>> >   *
>> > - * This function sets the connector's panel_orientation and attaches
>> > - * a "panel orientation" property to the connector.
>> > + * This function sets the connector's panel_orientation value. If the property
>> > + * doesn't exist, it will try to create one.
>> >   *
>> >   * Calling this function on a connector where the panel_orientation has
>> >   * already been set is a no-op (e.g. the orientation has been overridden with
>> > @@ -2373,19 +2373,12 @@ int drm_connector_set_panel_orientation(
>> >       info->panel_orientation = panel_orientation;
>> >
>> >       prop = dev->mode_config.panel_orientation_property;
>> > -     if (!prop) {
>> > -             prop = drm_property_create_enum(dev, DRM_MODE_PROP_IMMUTABLE,
>> > -                             "panel orientation",
>> > -                             drm_panel_orientation_enum_list,
>> > -                             ARRAY_SIZE(drm_panel_orientation_enum_list));
>> > -             if (!prop)
>> > -                     return -ENOMEM;
>> > -
>> > -             dev->mode_config.panel_orientation_property = prop;
>> > -     }
>> > +     if (!prop &&
>> > +         drm_connector_init_panel_orientation_property(connector) < 0)
>> > +             return -ENOMEM;
>> >
>>
>> In the case where the property has not been created beforehand, you
>> forgot to reinitialize prop here, after calling
>> drm_connector_init_panel_orientation_property().  This means
> hi Gabriel,
>
> drm_connector_init_panel_orientation_property() will create prop if
> it's null. If prop fails to be created there, it will return -ENOMEM.

Yes.  But *after the property is successfully created*, the prop variable is still
NULL.  And then you call the following, using prop, which is still NULL:

>> > +     drm_object_property_set_value(&connector->base, prop,
>> > +                                   info->panel_orientation);

This will do property->dev right on the first line of code, and dereference the
null prop pointer.

You must do

  prop = dev->mode_config.panel_orientation_property;

again after drm_connector_init_panel_orientation_property successfully
returns, or call drm_object_property_set_value using
dev->mode_config.panel_orientation_property directly:

  drm_object_property_set_value(&connector->base,
			dev->mode_config.panel_orientation_property
		        info->panel_orientation);

-- 
Gabriel Krisman Bertazi

Re: [Intel-gfx] [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Emil Velikov]

Greetings everyone,

Padron for joining in so late o/

On Tue, 8 Feb 2022 at 08:42, Hsin-Yi Wang <hsinyi@chromium.org> wrote:
>
> drm_dev_register() sets connector->registration_state to
> DRM_CONNECTOR_REGISTERED and dev->registered to true. If
> drm_connector_set_panel_orientation() is first called after
> drm_dev_register(), it will fail several checks and results in following
> warning.
>
> Add a function to create panel orientation property and set default value
> to UNKNOWN, so drivers can call this function to init the property earlier
> , and let the panel set the real value later.
>

The warning illustrates a genuine race condition, where userspace will
read the old/invalid property value/state. So this patch masks away
the WARNING without addressing the actual issue.
Instead can we fix the respective drivers, so that no properties are
created after drm_dev_register()?

Longer version:
As we look into drm_dev_register() it's in charge of creating the
dev/sysfs nodes (et al). Note that connectors cannot disappear at
runtime.
For panel orientation, we are creating an immutable connector
properly, meaning that as soon as drm_dev_register() is called we must
ensure that the property is available (if applicable) and set to the
correct value.

For illustration, consider the following scenario:
 - DRM modules are loaded late - are not built-in and not part of
initrd (or there's no initrd)
 - kernel boots
 - plymouth/similar user-space component kicks in before the
driver/module is loaded
 - module gets loaded, drm_dev_register() kicks in populating /dev/dri/card0
 - plymouth opens the dev node and reads DRM_MODE_PANEL_ORIENTATION_UNKNOWN
 - module updates the orientation property

Thanks
Emil

Re: [Intel-gfx] [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Emil Velikov]

Greetings everyone,

Padron for joining in so late o/

On Tue, 8 Feb 2022 at 08:42, Hsin-Yi Wang <hsinyi@chromium.org> wrote:
>
> drm_dev_register() sets connector->registration_state to
> DRM_CONNECTOR_REGISTERED and dev->registered to true. If
> drm_connector_set_panel_orientation() is first called after
> drm_dev_register(), it will fail several checks and results in following
> warning.
>
> Add a function to create panel orientation property and set default value
> to UNKNOWN, so drivers can call this function to init the property earlier
> , and let the panel set the real value later.
>

The warning illustrates a genuine race condition, where userspace will
read the old/invalid property value/state. So this patch masks away
the WARNING without addressing the actual issue.
Instead can we fix the respective drivers, so that no properties are
created after drm_dev_register()?

Longer version:
As we look into drm_dev_register() it's in charge of creating the
dev/sysfs nodes (et al). Note that connectors cannot disappear at
runtime.
For panel orientation, we are creating an immutable connector
properly, meaning that as soon as drm_dev_register() is called we must
ensure that the property is available (if applicable) and set to the
correct value.

For illustration, consider the following scenario:
 - DRM modules are loaded late - are not built-in and not part of
initrd (or there's no initrd)
 - kernel boots
 - plymouth/similar user-space component kicks in before the
driver/module is loaded
 - module gets loaded, drm_dev_register() kicks in populating /dev/dri/card0
 - plymouth opens the dev node and reads DRM_MODE_PANEL_ORIENTATION_UNKNOWN
 - module updates the orientation property

Thanks
Emil

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

Re: [Intel-gfx] [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Emil Velikov]

Greetings everyone,

Padron for joining in so late o/

On Tue, 8 Feb 2022 at 08:42, Hsin-Yi Wang <hsinyi@chromium.org> wrote:
>
> drm_dev_register() sets connector->registration_state to
> DRM_CONNECTOR_REGISTERED and dev->registered to true. If
> drm_connector_set_panel_orientation() is first called after
> drm_dev_register(), it will fail several checks and results in following
> warning.
>
> Add a function to create panel orientation property and set default value
> to UNKNOWN, so drivers can call this function to init the property earlier
> , and let the panel set the real value later.
>

The warning illustrates a genuine race condition, where userspace will
read the old/invalid property value/state. So this patch masks away
the WARNING without addressing the actual issue.
Instead can we fix the respective drivers, so that no properties are
created after drm_dev_register()?

Longer version:
As we look into drm_dev_register() it's in charge of creating the
dev/sysfs nodes (et al). Note that connectors cannot disappear at
runtime.
For panel orientation, we are creating an immutable connector
properly, meaning that as soon as drm_dev_register() is called we must
ensure that the property is available (if applicable) and set to the
correct value.

For illustration, consider the following scenario:
 - DRM modules are loaded late - are not built-in and not part of
initrd (or there's no initrd)
 - kernel boots
 - plymouth/similar user-space component kicks in before the
driver/module is loaded
 - module gets loaded, drm_dev_register() kicks in populating /dev/dri/card0
 - plymouth opens the dev node and reads DRM_MODE_PANEL_ORIENTATION_UNKNOWN
 - module updates the orientation property

Thanks
Emil

Re: [Intel-gfx] [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Emil Velikov]

Greetings everyone,

Padron for joining in so late o/

On Tue, 8 Feb 2022 at 08:42, Hsin-Yi Wang <hsinyi@chromium.org> wrote:
>
> drm_dev_register() sets connector->registration_state to
> DRM_CONNECTOR_REGISTERED and dev->registered to true. If
> drm_connector_set_panel_orientation() is first called after
> drm_dev_register(), it will fail several checks and results in following
> warning.
>
> Add a function to create panel orientation property and set default value
> to UNKNOWN, so drivers can call this function to init the property earlier
> , and let the panel set the real value later.
>

The warning illustrates a genuine race condition, where userspace will
read the old/invalid property value/state. So this patch masks away
the WARNING without addressing the actual issue.
Instead can we fix the respective drivers, so that no properties are
created after drm_dev_register()?

Longer version:
As we look into drm_dev_register() it's in charge of creating the
dev/sysfs nodes (et al). Note that connectors cannot disappear at
runtime.
For panel orientation, we are creating an immutable connector
properly, meaning that as soon as drm_dev_register() is called we must
ensure that the property is available (if applicable) and set to the
correct value.

For illustration, consider the following scenario:
 - DRM modules are loaded late - are not built-in and not part of
initrd (or there's no initrd)
 - kernel boots
 - plymouth/similar user-space component kicks in before the
driver/module is loaded
 - module gets loaded, drm_dev_register() kicks in populating /dev/dri/card0
 - plymouth opens the dev node and reads DRM_MODE_PANEL_ORIENTATION_UNKNOWN
 - module updates the orientation property

Thanks
Emil

Re: [Intel-gfx] [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Emil Velikov]

Greetings everyone,

Padron for joining in so late o/

On Tue, 8 Feb 2022 at 08:42, Hsin-Yi Wang <hsinyi@chromium.org> wrote:
>
> drm_dev_register() sets connector->registration_state to
> DRM_CONNECTOR_REGISTERED and dev->registered to true. If
> drm_connector_set_panel_orientation() is first called after
> drm_dev_register(), it will fail several checks and results in following
> warning.
>
> Add a function to create panel orientation property and set default value
> to UNKNOWN, so drivers can call this function to init the property earlier
> , and let the panel set the real value later.
>

The warning illustrates a genuine race condition, where userspace will
read the old/invalid property value/state. So this patch masks away
the WARNING without addressing the actual issue.
Instead can we fix the respective drivers, so that no properties are
created after drm_dev_register()?

Longer version:
As we look into drm_dev_register() it's in charge of creating the
dev/sysfs nodes (et al). Note that connectors cannot disappear at
runtime.
For panel orientation, we are creating an immutable connector
properly, meaning that as soon as drm_dev_register() is called we must
ensure that the property is available (if applicable) and set to the
correct value.

For illustration, consider the following scenario:
 - DRM modules are loaded late - are not built-in and not part of
initrd (or there's no initrd)
 - kernel boots
 - plymouth/similar user-space component kicks in before the
driver/module is loaded
 - module gets loaded, drm_dev_register() kicks in populating /dev/dri/card0
 - plymouth opens the dev node and reads DRM_MODE_PANEL_ORIENTATION_UNKNOWN
 - module updates the orientation property

Thanks
Emil

Re: [Intel-gfx] [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Emil Velikov]

Greetings everyone,

Padron for joining in so late o/

On Tue, 8 Feb 2022 at 08:42, Hsin-Yi Wang <hsinyi@chromium.org> wrote:
>
> drm_dev_register() sets connector->registration_state to
> DRM_CONNECTOR_REGISTERED and dev->registered to true. If
> drm_connector_set_panel_orientation() is first called after
> drm_dev_register(), it will fail several checks and results in following
> warning.
>
> Add a function to create panel orientation property and set default value
> to UNKNOWN, so drivers can call this function to init the property earlier
> , and let the panel set the real value later.
>

The warning illustrates a genuine race condition, where userspace will
read the old/invalid property value/state. So this patch masks away
the WARNING without addressing the actual issue.
Instead can we fix the respective drivers, so that no properties are
created after drm_dev_register()?

Longer version:
As we look into drm_dev_register() it's in charge of creating the
dev/sysfs nodes (et al). Note that connectors cannot disappear at
runtime.
For panel orientation, we are creating an immutable connector
properly, meaning that as soon as drm_dev_register() is called we must
ensure that the property is available (if applicable) and set to the
correct value.

For illustration, consider the following scenario:
 - DRM modules are loaded late - are not built-in and not part of
initrd (or there's no initrd)
 - kernel boots
 - plymouth/similar user-space component kicks in before the
driver/module is loaded
 - module gets loaded, drm_dev_register() kicks in populating /dev/dri/card0
 - plymouth opens the dev node and reads DRM_MODE_PANEL_ORIENTATION_UNKNOWN
 - module updates the orientation property

Thanks
Emil

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [Intel-gfx] [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Hsin-Yi Wang]

On Tue, Feb 15, 2022 at 8:04 PM Emil Velikov <emil.l.velikov@gmail.com> wrote:
>
> Greetings everyone,
>
> Padron for joining in so late o/
>
> On Tue, 8 Feb 2022 at 08:42, Hsin-Yi Wang <hsinyi@chromium.org> wrote:
> >
> > drm_dev_register() sets connector->registration_state to
> > DRM_CONNECTOR_REGISTERED and dev->registered to true. If
> > drm_connector_set_panel_orientation() is first called after
> > drm_dev_register(), it will fail several checks and results in following
> > warning.
> >
> > Add a function to create panel orientation property and set default value
> > to UNKNOWN, so drivers can call this function to init the property earlier
> > , and let the panel set the real value later.
> >
>
> The warning illustrates a genuine race condition, where userspace will
> read the old/invalid property value/state. So this patch masks away
> the WARNING without addressing the actual issue.
> Instead can we fix the respective drivers, so that no properties are
> created after drm_dev_register()?
>
1. How about the proposal in previous version:
v7 https://patchwork.kernel.org/project/linux-mediatek/patch/20220208073714.1540390-1-hsinyi@chromium.org/
we separate property creation
(drm_connector_init_panel_orientation_property) and value setting
(drm_connector_set_panel_orientation). This is also similar to some of
other optional properties are created, eg. vrr_capable.

And drm drivers have to make sure that if they want to use this
property, they have to create it before drm_dev_register(). For
example, in the 2nd patch, mtk_drm sets the property before calling
drm_dev_register().

2. I'm not sure how to handle the case that if user space tries to
read the property before the proper value is set. Currently drm
creates this property and the panels[1] will set the correct value
parsed from DT. If userspace calls before the panel sets the correct
value, it will get unknown (similar to the illustration you mentioned
below). Do you think that the drm should be responsible for parsing
the value if the panel provides it? In this way it's guaranteed that
the value is set when the property is created.

[1] https://elixir.bootlin.com/linux/latest/A/ident/drm_connector_set_panel_orientation

> Longer version:
> As we look into drm_dev_register() it's in charge of creating the
> dev/sysfs nodes (et al). Note that connectors cannot disappear at
> runtime.
> For panel orientation, we are creating an immutable connector
> properly, meaning that as soon as drm_dev_register() is called we must
> ensure that the property is available (if applicable) and set to the
> correct value.
>
> For illustration, consider the following scenario:
>  - DRM modules are loaded late - are not built-in and not part of
> initrd (or there's no initrd)
>  - kernel boots
>  - plymouth/similar user-space component kicks in before the
> driver/module is loaded
>  - module gets loaded, drm_dev_register() kicks in populating /dev/dri/card0
>  - plymouth opens the dev node and reads DRM_MODE_PANEL_ORIENTATION_UNKNOWN
>  - module updates the orientation property
>
> Thanks
> Emil

Re: [Intel-gfx] [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Hsin-Yi Wang]

On Tue, Feb 15, 2022 at 8:04 PM Emil Velikov <emil.l.velikov@gmail.com> wrote:
>
> Greetings everyone,
>
> Padron for joining in so late o/
>
> On Tue, 8 Feb 2022 at 08:42, Hsin-Yi Wang <hsinyi@chromium.org> wrote:
> >
> > drm_dev_register() sets connector->registration_state to
> > DRM_CONNECTOR_REGISTERED and dev->registered to true. If
> > drm_connector_set_panel_orientation() is first called after
> > drm_dev_register(), it will fail several checks and results in following
> > warning.
> >
> > Add a function to create panel orientation property and set default value
> > to UNKNOWN, so drivers can call this function to init the property earlier
> > , and let the panel set the real value later.
> >
>
> The warning illustrates a genuine race condition, where userspace will
> read the old/invalid property value/state. So this patch masks away
> the WARNING without addressing the actual issue.
> Instead can we fix the respective drivers, so that no properties are
> created after drm_dev_register()?
>
1. How about the proposal in previous version:
v7 https://patchwork.kernel.org/project/linux-mediatek/patch/20220208073714.1540390-1-hsinyi@chromium.org/
we separate property creation
(drm_connector_init_panel_orientation_property) and value setting
(drm_connector_set_panel_orientation). This is also similar to some of
other optional properties are created, eg. vrr_capable.

And drm drivers have to make sure that if they want to use this
property, they have to create it before drm_dev_register(). For
example, in the 2nd patch, mtk_drm sets the property before calling
drm_dev_register().

2. I'm not sure how to handle the case that if user space tries to
read the property before the proper value is set. Currently drm
creates this property and the panels[1] will set the correct value
parsed from DT. If userspace calls before the panel sets the correct
value, it will get unknown (similar to the illustration you mentioned
below). Do you think that the drm should be responsible for parsing
the value if the panel provides it? In this way it's guaranteed that
the value is set when the property is created.

[1] https://elixir.bootlin.com/linux/latest/A/ident/drm_connector_set_panel_orientation

> Longer version:
> As we look into drm_dev_register() it's in charge of creating the
> dev/sysfs nodes (et al). Note that connectors cannot disappear at
> runtime.
> For panel orientation, we are creating an immutable connector
> properly, meaning that as soon as drm_dev_register() is called we must
> ensure that the property is available (if applicable) and set to the
> correct value.
>
> For illustration, consider the following scenario:
>  - DRM modules are loaded late - are not built-in and not part of
> initrd (or there's no initrd)
>  - kernel boots
>  - plymouth/similar user-space component kicks in before the
> driver/module is loaded
>  - module gets loaded, drm_dev_register() kicks in populating /dev/dri/card0
>  - plymouth opens the dev node and reads DRM_MODE_PANEL_ORIENTATION_UNKNOWN
>  - module updates the orientation property
>
> Thanks
> Emil

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

Re: [Intel-gfx] [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Hsin-Yi Wang]

On Tue, Feb 15, 2022 at 8:04 PM Emil Velikov <emil.l.velikov@gmail.com> wrote:
>
> Greetings everyone,
>
> Padron for joining in so late o/
>
> On Tue, 8 Feb 2022 at 08:42, Hsin-Yi Wang <hsinyi@chromium.org> wrote:
> >
> > drm_dev_register() sets connector->registration_state to
> > DRM_CONNECTOR_REGISTERED and dev->registered to true. If
> > drm_connector_set_panel_orientation() is first called after
> > drm_dev_register(), it will fail several checks and results in following
> > warning.
> >
> > Add a function to create panel orientation property and set default value
> > to UNKNOWN, so drivers can call this function to init the property earlier
> > , and let the panel set the real value later.
> >
>
> The warning illustrates a genuine race condition, where userspace will
> read the old/invalid property value/state. So this patch masks away
> the WARNING without addressing the actual issue.
> Instead can we fix the respective drivers, so that no properties are
> created after drm_dev_register()?
>
1. How about the proposal in previous version:
v7 https://patchwork.kernel.org/project/linux-mediatek/patch/20220208073714.1540390-1-hsinyi@chromium.org/
we separate property creation
(drm_connector_init_panel_orientation_property) and value setting
(drm_connector_set_panel_orientation). This is also similar to some of
other optional properties are created, eg. vrr_capable.

And drm drivers have to make sure that if they want to use this
property, they have to create it before drm_dev_register(). For
example, in the 2nd patch, mtk_drm sets the property before calling
drm_dev_register().

2. I'm not sure how to handle the case that if user space tries to
read the property before the proper value is set. Currently drm
creates this property and the panels[1] will set the correct value
parsed from DT. If userspace calls before the panel sets the correct
value, it will get unknown (similar to the illustration you mentioned
below). Do you think that the drm should be responsible for parsing
the value if the panel provides it? In this way it's guaranteed that
the value is set when the property is created.

[1] https://elixir.bootlin.com/linux/latest/A/ident/drm_connector_set_panel_orientation

> Longer version:
> As we look into drm_dev_register() it's in charge of creating the
> dev/sysfs nodes (et al). Note that connectors cannot disappear at
> runtime.
> For panel orientation, we are creating an immutable connector
> properly, meaning that as soon as drm_dev_register() is called we must
> ensure that the property is available (if applicable) and set to the
> correct value.
>
> For illustration, consider the following scenario:
>  - DRM modules are loaded late - are not built-in and not part of
> initrd (or there's no initrd)
>  - kernel boots
>  - plymouth/similar user-space component kicks in before the
> driver/module is loaded
>  - module gets loaded, drm_dev_register() kicks in populating /dev/dri/card0
>  - plymouth opens the dev node and reads DRM_MODE_PANEL_ORIENTATION_UNKNOWN
>  - module updates the orientation property
>
> Thanks
> Emil

Re: [Intel-gfx] [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Hsin-Yi Wang]

On Tue, Feb 15, 2022 at 8:04 PM Emil Velikov <emil.l.velikov@gmail.com> wrote:
>
> Greetings everyone,
>
> Padron for joining in so late o/
>
> On Tue, 8 Feb 2022 at 08:42, Hsin-Yi Wang <hsinyi@chromium.org> wrote:
> >
> > drm_dev_register() sets connector->registration_state to
> > DRM_CONNECTOR_REGISTERED and dev->registered to true. If
> > drm_connector_set_panel_orientation() is first called after
> > drm_dev_register(), it will fail several checks and results in following
> > warning.
> >
> > Add a function to create panel orientation property and set default value
> > to UNKNOWN, so drivers can call this function to init the property earlier
> > , and let the panel set the real value later.
> >
>
> The warning illustrates a genuine race condition, where userspace will
> read the old/invalid property value/state. So this patch masks away
> the WARNING without addressing the actual issue.
> Instead can we fix the respective drivers, so that no properties are
> created after drm_dev_register()?
>
1. How about the proposal in previous version:
v7 https://patchwork.kernel.org/project/linux-mediatek/patch/20220208073714.1540390-1-hsinyi@chromium.org/
we separate property creation
(drm_connector_init_panel_orientation_property) and value setting
(drm_connector_set_panel_orientation). This is also similar to some of
other optional properties are created, eg. vrr_capable.

And drm drivers have to make sure that if they want to use this
property, they have to create it before drm_dev_register(). For
example, in the 2nd patch, mtk_drm sets the property before calling
drm_dev_register().

2. I'm not sure how to handle the case that if user space tries to
read the property before the proper value is set. Currently drm
creates this property and the panels[1] will set the correct value
parsed from DT. If userspace calls before the panel sets the correct
value, it will get unknown (similar to the illustration you mentioned
below). Do you think that the drm should be responsible for parsing
the value if the panel provides it? In this way it's guaranteed that
the value is set when the property is created.

[1] https://elixir.bootlin.com/linux/latest/A/ident/drm_connector_set_panel_orientation

> Longer version:
> As we look into drm_dev_register() it's in charge of creating the
> dev/sysfs nodes (et al). Note that connectors cannot disappear at
> runtime.
> For panel orientation, we are creating an immutable connector
> properly, meaning that as soon as drm_dev_register() is called we must
> ensure that the property is available (if applicable) and set to the
> correct value.
>
> For illustration, consider the following scenario:
>  - DRM modules are loaded late - are not built-in and not part of
> initrd (or there's no initrd)
>  - kernel boots
>  - plymouth/similar user-space component kicks in before the
> driver/module is loaded
>  - module gets loaded, drm_dev_register() kicks in populating /dev/dri/card0
>  - plymouth opens the dev node and reads DRM_MODE_PANEL_ORIENTATION_UNKNOWN
>  - module updates the orientation property
>
> Thanks
> Emil

Re: [Intel-gfx] [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Hsin-Yi Wang]

On Tue, Feb 15, 2022 at 8:04 PM Emil Velikov <emil.l.velikov@gmail.com> wrote:
>
> Greetings everyone,
>
> Padron for joining in so late o/
>
> On Tue, 8 Feb 2022 at 08:42, Hsin-Yi Wang <hsinyi@chromium.org> wrote:
> >
> > drm_dev_register() sets connector->registration_state to
> > DRM_CONNECTOR_REGISTERED and dev->registered to true. If
> > drm_connector_set_panel_orientation() is first called after
> > drm_dev_register(), it will fail several checks and results in following
> > warning.
> >
> > Add a function to create panel orientation property and set default value
> > to UNKNOWN, so drivers can call this function to init the property earlier
> > , and let the panel set the real value later.
> >
>
> The warning illustrates a genuine race condition, where userspace will
> read the old/invalid property value/state. So this patch masks away
> the WARNING without addressing the actual issue.
> Instead can we fix the respective drivers, so that no properties are
> created after drm_dev_register()?
>
1. How about the proposal in previous version:
v7 https://patchwork.kernel.org/project/linux-mediatek/patch/20220208073714.1540390-1-hsinyi@chromium.org/
we separate property creation
(drm_connector_init_panel_orientation_property) and value setting
(drm_connector_set_panel_orientation). This is also similar to some of
other optional properties are created, eg. vrr_capable.

And drm drivers have to make sure that if they want to use this
property, they have to create it before drm_dev_register(). For
example, in the 2nd patch, mtk_drm sets the property before calling
drm_dev_register().

2. I'm not sure how to handle the case that if user space tries to
read the property before the proper value is set. Currently drm
creates this property and the panels[1] will set the correct value
parsed from DT. If userspace calls before the panel sets the correct
value, it will get unknown (similar to the illustration you mentioned
below). Do you think that the drm should be responsible for parsing
the value if the panel provides it? In this way it's guaranteed that
the value is set when the property is created.

[1] https://elixir.bootlin.com/linux/latest/A/ident/drm_connector_set_panel_orientation

> Longer version:
> As we look into drm_dev_register() it's in charge of creating the
> dev/sysfs nodes (et al). Note that connectors cannot disappear at
> runtime.
> For panel orientation, we are creating an immutable connector
> properly, meaning that as soon as drm_dev_register() is called we must
> ensure that the property is available (if applicable) and set to the
> correct value.
>
> For illustration, consider the following scenario:
>  - DRM modules are loaded late - are not built-in and not part of
> initrd (or there's no initrd)
>  - kernel boots
>  - plymouth/similar user-space component kicks in before the
> driver/module is loaded
>  - module gets loaded, drm_dev_register() kicks in populating /dev/dri/card0
>  - plymouth opens the dev node and reads DRM_MODE_PANEL_ORIENTATION_UNKNOWN
>  - module updates the orientation property
>
> Thanks
> Emil

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [Intel-gfx] [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Hsin-Yi Wang]

On Tue, Feb 15, 2022 at 8:04 PM Emil Velikov <emil.l.velikov@gmail.com> wrote:
>
> Greetings everyone,
>
> Padron for joining in so late o/
>
> On Tue, 8 Feb 2022 at 08:42, Hsin-Yi Wang <hsinyi@chromium.org> wrote:
> >
> > drm_dev_register() sets connector->registration_state to
> > DRM_CONNECTOR_REGISTERED and dev->registered to true. If
> > drm_connector_set_panel_orientation() is first called after
> > drm_dev_register(), it will fail several checks and results in following
> > warning.
> >
> > Add a function to create panel orientation property and set default value
> > to UNKNOWN, so drivers can call this function to init the property earlier
> > , and let the panel set the real value later.
> >
>
> The warning illustrates a genuine race condition, where userspace will
> read the old/invalid property value/state. So this patch masks away
> the WARNING without addressing the actual issue.
> Instead can we fix the respective drivers, so that no properties are
> created after drm_dev_register()?
>
1. How about the proposal in previous version:
v7 https://patchwork.kernel.org/project/linux-mediatek/patch/20220208073714.1540390-1-hsinyi@chromium.org/
we separate property creation
(drm_connector_init_panel_orientation_property) and value setting
(drm_connector_set_panel_orientation). This is also similar to some of
other optional properties are created, eg. vrr_capable.

And drm drivers have to make sure that if they want to use this
property, they have to create it before drm_dev_register(). For
example, in the 2nd patch, mtk_drm sets the property before calling
drm_dev_register().

2. I'm not sure how to handle the case that if user space tries to
read the property before the proper value is set. Currently drm
creates this property and the panels[1] will set the correct value
parsed from DT. If userspace calls before the panel sets the correct
value, it will get unknown (similar to the illustration you mentioned
below). Do you think that the drm should be responsible for parsing
the value if the panel provides it? In this way it's guaranteed that
the value is set when the property is created.

[1] https://elixir.bootlin.com/linux/latest/A/ident/drm_connector_set_panel_orientation

> Longer version:
> As we look into drm_dev_register() it's in charge of creating the
> dev/sysfs nodes (et al). Note that connectors cannot disappear at
> runtime.
> For panel orientation, we are creating an immutable connector
> properly, meaning that as soon as drm_dev_register() is called we must
> ensure that the property is available (if applicable) and set to the
> correct value.
>
> For illustration, consider the following scenario:
>  - DRM modules are loaded late - are not built-in and not part of
> initrd (or there's no initrd)
>  - kernel boots
>  - plymouth/similar user-space component kicks in before the
> driver/module is loaded
>  - module gets loaded, drm_dev_register() kicks in populating /dev/dri/card0
>  - plymouth opens the dev node and reads DRM_MODE_PANEL_ORIENTATION_UNKNOWN
>  - module updates the orientation property
>
> Thanks
> Emil

Re: [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Hsin-Yi Wang]

On Tue, Feb 15, 2022 at 12:03 PM Gabriel Krisman Bertazi
<krisman@collabora.com> wrote:
>
> Hsin-Yi Wang <hsinyi@chromium.org> writes:
>
> > On Tue, Feb 15, 2022 at 9:17 AM Gabriel Krisman Bertazi
> > <krisman@collabora.com> wrote:
> >>
> >> Hsin-Yi Wang <hsinyi@chromium.org> writes:
> >>
> >> > drm_dev_register() sets connector->registration_state to
> >> > DRM_CONNECTOR_REGISTERED and dev->registered to true. If
> >> > drm_connector_set_panel_orientation() is first called after
> >> > drm_dev_register(), it will fail several checks and results in following
> >> > warning.
> >>
> >> Hi,
> >>
> >> I stumbled upon this when investigating the same WARN_ON on amdgpu.
> >> Thanks for the patch :)
> >>
> >> > diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> >> > index a50c82bc2b2fec..572ead7ac10690 100644
> >> > --- a/drivers/gpu/drm/drm_connector.c
> >> > +++ b/drivers/gpu/drm/drm_connector.c
> >> > @@ -1252,7 +1252,7 @@ static const struct drm_prop_enum_list dp_colorspaces[] = {
> >> >   *   INPUT_PROP_DIRECT) will still map 1:1 to the actual LCD panel
> >> >   *   coordinates, so if userspace rotates the picture to adjust for
> >> >   *   the orientation it must also apply the same transformation to the
> >> > - *   touchscreen input coordinates. This property is initialized by calling
> >> > + *   touchscreen input coordinates. This property value is set by calling
> >> >   *   drm_connector_set_panel_orientation() or
> >> >   *   drm_connector_set_panel_orientation_with_quirk()
> >> >   *
> >> > @@ -2341,8 +2341,8 @@ EXPORT_SYMBOL(drm_connector_set_vrr_capable_property);
> >> >   * @connector: connector for which to set the panel-orientation property.
> >> >   * @panel_orientation: drm_panel_orientation value to set
> >> >   *
> >> > - * This function sets the connector's panel_orientation and attaches
> >> > - * a "panel orientation" property to the connector.
> >> > + * This function sets the connector's panel_orientation value. If the property
> >> > + * doesn't exist, it will try to create one.
> >> >   *
> >> >   * Calling this function on a connector where the panel_orientation has
> >> >   * already been set is a no-op (e.g. the orientation has been overridden with
> >> > @@ -2373,19 +2373,12 @@ int drm_connector_set_panel_orientation(
> >> >       info->panel_orientation = panel_orientation;
> >> >
> >> >       prop = dev->mode_config.panel_orientation_property;
> >> > -     if (!prop) {
> >> > -             prop = drm_property_create_enum(dev, DRM_MODE_PROP_IMMUTABLE,
> >> > -                             "panel orientation",
> >> > -                             drm_panel_orientation_enum_list,
> >> > -                             ARRAY_SIZE(drm_panel_orientation_enum_list));
> >> > -             if (!prop)
> >> > -                     return -ENOMEM;
> >> > -
> >> > -             dev->mode_config.panel_orientation_property = prop;
> >> > -     }
> >> > +     if (!prop &&
> >> > +         drm_connector_init_panel_orientation_property(connector) < 0)
> >> > +             return -ENOMEM;
> >> >
> >>
> >> In the case where the property has not been created beforehand, you
> >> forgot to reinitialize prop here, after calling
> >> drm_connector_init_panel_orientation_property().  This means
> > hi Gabriel,
> >
> > drm_connector_init_panel_orientation_property() will create prop if
> > it's null. If prop fails to be created there, it will return -ENOMEM.
>
> Yes.  But *after the property is successfully created*, the prop variable is still
> NULL.  And then you call the following, using prop, which is still NULL:
>
> >> > +     drm_object_property_set_value(&connector->base, prop,
> >> > +                                   info->panel_orientation);
>
> This will do property->dev right on the first line of code, and dereference the
> null prop pointer.

Ah, right. Sorry that I totally missed this.
I'll fix it in the next version if the idea of this patch is accepted.
There might be another preferred solution for this.

>
> You must do
>
>   prop = dev->mode_config.panel_orientation_property;
>
> again after drm_connector_init_panel_orientation_property successfully
> returns, or call drm_object_property_set_value using
> dev->mode_config.panel_orientation_property directly:
>
>   drm_object_property_set_value(&connector->base,
>                         dev->mode_config.panel_orientation_property
>                         info->panel_orientation);
>
> --
> Gabriel Krisman Bertazi

Re: [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Hsin-Yi Wang]

On Tue, Feb 15, 2022 at 12:03 PM Gabriel Krisman Bertazi
<krisman@collabora.com> wrote:
>
> Hsin-Yi Wang <hsinyi@chromium.org> writes:
>
> > On Tue, Feb 15, 2022 at 9:17 AM Gabriel Krisman Bertazi
> > <krisman@collabora.com> wrote:
> >>
> >> Hsin-Yi Wang <hsinyi@chromium.org> writes:
> >>
> >> > drm_dev_register() sets connector->registration_state to
> >> > DRM_CONNECTOR_REGISTERED and dev->registered to true. If
> >> > drm_connector_set_panel_orientation() is first called after
> >> > drm_dev_register(), it will fail several checks and results in following
> >> > warning.
> >>
> >> Hi,
> >>
> >> I stumbled upon this when investigating the same WARN_ON on amdgpu.
> >> Thanks for the patch :)
> >>
> >> > diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> >> > index a50c82bc2b2fec..572ead7ac10690 100644
> >> > --- a/drivers/gpu/drm/drm_connector.c
> >> > +++ b/drivers/gpu/drm/drm_connector.c
> >> > @@ -1252,7 +1252,7 @@ static const struct drm_prop_enum_list dp_colorspaces[] = {
> >> >   *   INPUT_PROP_DIRECT) will still map 1:1 to the actual LCD panel
> >> >   *   coordinates, so if userspace rotates the picture to adjust for
> >> >   *   the orientation it must also apply the same transformation to the
> >> > - *   touchscreen input coordinates. This property is initialized by calling
> >> > + *   touchscreen input coordinates. This property value is set by calling
> >> >   *   drm_connector_set_panel_orientation() or
> >> >   *   drm_connector_set_panel_orientation_with_quirk()
> >> >   *
> >> > @@ -2341,8 +2341,8 @@ EXPORT_SYMBOL(drm_connector_set_vrr_capable_property);
> >> >   * @connector: connector for which to set the panel-orientation property.
> >> >   * @panel_orientation: drm_panel_orientation value to set
> >> >   *
> >> > - * This function sets the connector's panel_orientation and attaches
> >> > - * a "panel orientation" property to the connector.
> >> > + * This function sets the connector's panel_orientation value. If the property
> >> > + * doesn't exist, it will try to create one.
> >> >   *
> >> >   * Calling this function on a connector where the panel_orientation has
> >> >   * already been set is a no-op (e.g. the orientation has been overridden with
> >> > @@ -2373,19 +2373,12 @@ int drm_connector_set_panel_orientation(
> >> >       info->panel_orientation = panel_orientation;
> >> >
> >> >       prop = dev->mode_config.panel_orientation_property;
> >> > -     if (!prop) {
> >> > -             prop = drm_property_create_enum(dev, DRM_MODE_PROP_IMMUTABLE,
> >> > -                             "panel orientation",
> >> > -                             drm_panel_orientation_enum_list,
> >> > -                             ARRAY_SIZE(drm_panel_orientation_enum_list));
> >> > -             if (!prop)
> >> > -                     return -ENOMEM;
> >> > -
> >> > -             dev->mode_config.panel_orientation_property = prop;
> >> > -     }
> >> > +     if (!prop &&
> >> > +         drm_connector_init_panel_orientation_property(connector) < 0)
> >> > +             return -ENOMEM;
> >> >
> >>
> >> In the case where the property has not been created beforehand, you
> >> forgot to reinitialize prop here, after calling
> >> drm_connector_init_panel_orientation_property().  This means
> > hi Gabriel,
> >
> > drm_connector_init_panel_orientation_property() will create prop if
> > it's null. If prop fails to be created there, it will return -ENOMEM.
>
> Yes.  But *after the property is successfully created*, the prop variable is still
> NULL.  And then you call the following, using prop, which is still NULL:
>
> >> > +     drm_object_property_set_value(&connector->base, prop,
> >> > +                                   info->panel_orientation);
>
> This will do property->dev right on the first line of code, and dereference the
> null prop pointer.

Ah, right. Sorry that I totally missed this.
I'll fix it in the next version if the idea of this patch is accepted.
There might be another preferred solution for this.

>
> You must do
>
>   prop = dev->mode_config.panel_orientation_property;
>
> again after drm_connector_init_panel_orientation_property successfully
> returns, or call drm_object_property_set_value using
> dev->mode_config.panel_orientation_property directly:
>
>   drm_object_property_set_value(&connector->base,
>                         dev->mode_config.panel_orientation_property
>                         info->panel_orientation);
>
> --
> Gabriel Krisman Bertazi

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

Re: [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Hsin-Yi Wang]

On Tue, Feb 15, 2022 at 12:03 PM Gabriel Krisman Bertazi
<krisman@collabora.com> wrote:
>
> Hsin-Yi Wang <hsinyi@chromium.org> writes:
>
> > On Tue, Feb 15, 2022 at 9:17 AM Gabriel Krisman Bertazi
> > <krisman@collabora.com> wrote:
> >>
> >> Hsin-Yi Wang <hsinyi@chromium.org> writes:
> >>
> >> > drm_dev_register() sets connector->registration_state to
> >> > DRM_CONNECTOR_REGISTERED and dev->registered to true. If
> >> > drm_connector_set_panel_orientation() is first called after
> >> > drm_dev_register(), it will fail several checks and results in following
> >> > warning.
> >>
> >> Hi,
> >>
> >> I stumbled upon this when investigating the same WARN_ON on amdgpu.
> >> Thanks for the patch :)
> >>
> >> > diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> >> > index a50c82bc2b2fec..572ead7ac10690 100644
> >> > --- a/drivers/gpu/drm/drm_connector.c
> >> > +++ b/drivers/gpu/drm/drm_connector.c
> >> > @@ -1252,7 +1252,7 @@ static const struct drm_prop_enum_list dp_colorspaces[] = {
> >> >   *   INPUT_PROP_DIRECT) will still map 1:1 to the actual LCD panel
> >> >   *   coordinates, so if userspace rotates the picture to adjust for
> >> >   *   the orientation it must also apply the same transformation to the
> >> > - *   touchscreen input coordinates. This property is initialized by calling
> >> > + *   touchscreen input coordinates. This property value is set by calling
> >> >   *   drm_connector_set_panel_orientation() or
> >> >   *   drm_connector_set_panel_orientation_with_quirk()
> >> >   *
> >> > @@ -2341,8 +2341,8 @@ EXPORT_SYMBOL(drm_connector_set_vrr_capable_property);
> >> >   * @connector: connector for which to set the panel-orientation property.
> >> >   * @panel_orientation: drm_panel_orientation value to set
> >> >   *
> >> > - * This function sets the connector's panel_orientation and attaches
> >> > - * a "panel orientation" property to the connector.
> >> > + * This function sets the connector's panel_orientation value. If the property
> >> > + * doesn't exist, it will try to create one.
> >> >   *
> >> >   * Calling this function on a connector where the panel_orientation has
> >> >   * already been set is a no-op (e.g. the orientation has been overridden with
> >> > @@ -2373,19 +2373,12 @@ int drm_connector_set_panel_orientation(
> >> >       info->panel_orientation = panel_orientation;
> >> >
> >> >       prop = dev->mode_config.panel_orientation_property;
> >> > -     if (!prop) {
> >> > -             prop = drm_property_create_enum(dev, DRM_MODE_PROP_IMMUTABLE,
> >> > -                             "panel orientation",
> >> > -                             drm_panel_orientation_enum_list,
> >> > -                             ARRAY_SIZE(drm_panel_orientation_enum_list));
> >> > -             if (!prop)
> >> > -                     return -ENOMEM;
> >> > -
> >> > -             dev->mode_config.panel_orientation_property = prop;
> >> > -     }
> >> > +     if (!prop &&
> >> > +         drm_connector_init_panel_orientation_property(connector) < 0)
> >> > +             return -ENOMEM;
> >> >
> >>
> >> In the case where the property has not been created beforehand, you
> >> forgot to reinitialize prop here, after calling
> >> drm_connector_init_panel_orientation_property().  This means
> > hi Gabriel,
> >
> > drm_connector_init_panel_orientation_property() will create prop if
> > it's null. If prop fails to be created there, it will return -ENOMEM.
>
> Yes.  But *after the property is successfully created*, the prop variable is still
> NULL.  And then you call the following, using prop, which is still NULL:
>
> >> > +     drm_object_property_set_value(&connector->base, prop,
> >> > +                                   info->panel_orientation);
>
> This will do property->dev right on the first line of code, and dereference the
> null prop pointer.

Ah, right. Sorry that I totally missed this.
I'll fix it in the next version if the idea of this patch is accepted.
There might be another preferred solution for this.

>
> You must do
>
>   prop = dev->mode_config.panel_orientation_property;
>
> again after drm_connector_init_panel_orientation_property successfully
> returns, or call drm_object_property_set_value using
> dev->mode_config.panel_orientation_property directly:
>
>   drm_object_property_set_value(&connector->base,
>                         dev->mode_config.panel_orientation_property
>                         info->panel_orientation);
>
> --
> Gabriel Krisman Bertazi

Re: [Intel-gfx] [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Hsin-Yi Wang]

On Tue, Feb 15, 2022 at 12:03 PM Gabriel Krisman Bertazi
<krisman@collabora.com> wrote:
>
> Hsin-Yi Wang <hsinyi@chromium.org> writes:
>
> > On Tue, Feb 15, 2022 at 9:17 AM Gabriel Krisman Bertazi
> > <krisman@collabora.com> wrote:
> >>
> >> Hsin-Yi Wang <hsinyi@chromium.org> writes:
> >>
> >> > drm_dev_register() sets connector->registration_state to
> >> > DRM_CONNECTOR_REGISTERED and dev->registered to true. If
> >> > drm_connector_set_panel_orientation() is first called after
> >> > drm_dev_register(), it will fail several checks and results in following
> >> > warning.
> >>
> >> Hi,
> >>
> >> I stumbled upon this when investigating the same WARN_ON on amdgpu.
> >> Thanks for the patch :)
> >>
> >> > diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> >> > index a50c82bc2b2fec..572ead7ac10690 100644
> >> > --- a/drivers/gpu/drm/drm_connector.c
> >> > +++ b/drivers/gpu/drm/drm_connector.c
> >> > @@ -1252,7 +1252,7 @@ static const struct drm_prop_enum_list dp_colorspaces[] = {
> >> >   *   INPUT_PROP_DIRECT) will still map 1:1 to the actual LCD panel
> >> >   *   coordinates, so if userspace rotates the picture to adjust for
> >> >   *   the orientation it must also apply the same transformation to the
> >> > - *   touchscreen input coordinates. This property is initialized by calling
> >> > + *   touchscreen input coordinates. This property value is set by calling
> >> >   *   drm_connector_set_panel_orientation() or
> >> >   *   drm_connector_set_panel_orientation_with_quirk()
> >> >   *
> >> > @@ -2341,8 +2341,8 @@ EXPORT_SYMBOL(drm_connector_set_vrr_capable_property);
> >> >   * @connector: connector for which to set the panel-orientation property.
> >> >   * @panel_orientation: drm_panel_orientation value to set
> >> >   *
> >> > - * This function sets the connector's panel_orientation and attaches
> >> > - * a "panel orientation" property to the connector.
> >> > + * This function sets the connector's panel_orientation value. If the property
> >> > + * doesn't exist, it will try to create one.
> >> >   *
> >> >   * Calling this function on a connector where the panel_orientation has
> >> >   * already been set is a no-op (e.g. the orientation has been overridden with
> >> > @@ -2373,19 +2373,12 @@ int drm_connector_set_panel_orientation(
> >> >       info->panel_orientation = panel_orientation;
> >> >
> >> >       prop = dev->mode_config.panel_orientation_property;
> >> > -     if (!prop) {
> >> > -             prop = drm_property_create_enum(dev, DRM_MODE_PROP_IMMUTABLE,
> >> > -                             "panel orientation",
> >> > -                             drm_panel_orientation_enum_list,
> >> > -                             ARRAY_SIZE(drm_panel_orientation_enum_list));
> >> > -             if (!prop)
> >> > -                     return -ENOMEM;
> >> > -
> >> > -             dev->mode_config.panel_orientation_property = prop;
> >> > -     }
> >> > +     if (!prop &&
> >> > +         drm_connector_init_panel_orientation_property(connector) < 0)
> >> > +             return -ENOMEM;
> >> >
> >>
> >> In the case where the property has not been created beforehand, you
> >> forgot to reinitialize prop here, after calling
> >> drm_connector_init_panel_orientation_property().  This means
> > hi Gabriel,
> >
> > drm_connector_init_panel_orientation_property() will create prop if
> > it's null. If prop fails to be created there, it will return -ENOMEM.
>
> Yes.  But *after the property is successfully created*, the prop variable is still
> NULL.  And then you call the following, using prop, which is still NULL:
>
> >> > +     drm_object_property_set_value(&connector->base, prop,
> >> > +                                   info->panel_orientation);
>
> This will do property->dev right on the first line of code, and dereference the
> null prop pointer.

Ah, right. Sorry that I totally missed this.
I'll fix it in the next version if the idea of this patch is accepted.
There might be another preferred solution for this.

>
> You must do
>
>   prop = dev->mode_config.panel_orientation_property;
>
> again after drm_connector_init_panel_orientation_property successfully
> returns, or call drm_object_property_set_value using
> dev->mode_config.panel_orientation_property directly:
>
>   drm_object_property_set_value(&connector->base,
>                         dev->mode_config.panel_orientation_property
>                         info->panel_orientation);
>
> --
> Gabriel Krisman Bertazi

Re: [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Hsin-Yi Wang]

On Tue, Feb 15, 2022 at 12:03 PM Gabriel Krisman Bertazi
<krisman@collabora.com> wrote:
>
> Hsin-Yi Wang <hsinyi@chromium.org> writes:
>
> > On Tue, Feb 15, 2022 at 9:17 AM Gabriel Krisman Bertazi
> > <krisman@collabora.com> wrote:
> >>
> >> Hsin-Yi Wang <hsinyi@chromium.org> writes:
> >>
> >> > drm_dev_register() sets connector->registration_state to
> >> > DRM_CONNECTOR_REGISTERED and dev->registered to true. If
> >> > drm_connector_set_panel_orientation() is first called after
> >> > drm_dev_register(), it will fail several checks and results in following
> >> > warning.
> >>
> >> Hi,
> >>
> >> I stumbled upon this when investigating the same WARN_ON on amdgpu.
> >> Thanks for the patch :)
> >>
> >> > diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> >> > index a50c82bc2b2fec..572ead7ac10690 100644
> >> > --- a/drivers/gpu/drm/drm_connector.c
> >> > +++ b/drivers/gpu/drm/drm_connector.c
> >> > @@ -1252,7 +1252,7 @@ static const struct drm_prop_enum_list dp_colorspaces[] = {
> >> >   *   INPUT_PROP_DIRECT) will still map 1:1 to the actual LCD panel
> >> >   *   coordinates, so if userspace rotates the picture to adjust for
> >> >   *   the orientation it must also apply the same transformation to the
> >> > - *   touchscreen input coordinates. This property is initialized by calling
> >> > + *   touchscreen input coordinates. This property value is set by calling
> >> >   *   drm_connector_set_panel_orientation() or
> >> >   *   drm_connector_set_panel_orientation_with_quirk()
> >> >   *
> >> > @@ -2341,8 +2341,8 @@ EXPORT_SYMBOL(drm_connector_set_vrr_capable_property);
> >> >   * @connector: connector for which to set the panel-orientation property.
> >> >   * @panel_orientation: drm_panel_orientation value to set
> >> >   *
> >> > - * This function sets the connector's panel_orientation and attaches
> >> > - * a "panel orientation" property to the connector.
> >> > + * This function sets the connector's panel_orientation value. If the property
> >> > + * doesn't exist, it will try to create one.
> >> >   *
> >> >   * Calling this function on a connector where the panel_orientation has
> >> >   * already been set is a no-op (e.g. the orientation has been overridden with
> >> > @@ -2373,19 +2373,12 @@ int drm_connector_set_panel_orientation(
> >> >       info->panel_orientation = panel_orientation;
> >> >
> >> >       prop = dev->mode_config.panel_orientation_property;
> >> > -     if (!prop) {
> >> > -             prop = drm_property_create_enum(dev, DRM_MODE_PROP_IMMUTABLE,
> >> > -                             "panel orientation",
> >> > -                             drm_panel_orientation_enum_list,
> >> > -                             ARRAY_SIZE(drm_panel_orientation_enum_list));
> >> > -             if (!prop)
> >> > -                     return -ENOMEM;
> >> > -
> >> > -             dev->mode_config.panel_orientation_property = prop;
> >> > -     }
> >> > +     if (!prop &&
> >> > +         drm_connector_init_panel_orientation_property(connector) < 0)
> >> > +             return -ENOMEM;
> >> >
> >>
> >> In the case where the property has not been created beforehand, you
> >> forgot to reinitialize prop here, after calling
> >> drm_connector_init_panel_orientation_property().  This means
> > hi Gabriel,
> >
> > drm_connector_init_panel_orientation_property() will create prop if
> > it's null. If prop fails to be created there, it will return -ENOMEM.
>
> Yes.  But *after the property is successfully created*, the prop variable is still
> NULL.  And then you call the following, using prop, which is still NULL:
>
> >> > +     drm_object_property_set_value(&connector->base, prop,
> >> > +                                   info->panel_orientation);
>
> This will do property->dev right on the first line of code, and dereference the
> null prop pointer.

Ah, right. Sorry that I totally missed this.
I'll fix it in the next version if the idea of this patch is accepted.
There might be another preferred solution for this.

>
> You must do
>
>   prop = dev->mode_config.panel_orientation_property;
>
> again after drm_connector_init_panel_orientation_property successfully
> returns, or call drm_object_property_set_value using
> dev->mode_config.panel_orientation_property directly:
>
>   drm_object_property_set_value(&connector->base,
>                         dev->mode_config.panel_orientation_property
>                         info->panel_orientation);
>
> --
> Gabriel Krisman Bertazi

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Hsin-Yi Wang]

On Tue, Feb 15, 2022 at 12:03 PM Gabriel Krisman Bertazi
<krisman@collabora.com> wrote:
>
> Hsin-Yi Wang <hsinyi@chromium.org> writes:
>
> > On Tue, Feb 15, 2022 at 9:17 AM Gabriel Krisman Bertazi
> > <krisman@collabora.com> wrote:
> >>
> >> Hsin-Yi Wang <hsinyi@chromium.org> writes:
> >>
> >> > drm_dev_register() sets connector->registration_state to
> >> > DRM_CONNECTOR_REGISTERED and dev->registered to true. If
> >> > drm_connector_set_panel_orientation() is first called after
> >> > drm_dev_register(), it will fail several checks and results in following
> >> > warning.
> >>
> >> Hi,
> >>
> >> I stumbled upon this when investigating the same WARN_ON on amdgpu.
> >> Thanks for the patch :)
> >>
> >> > diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> >> > index a50c82bc2b2fec..572ead7ac10690 100644
> >> > --- a/drivers/gpu/drm/drm_connector.c
> >> > +++ b/drivers/gpu/drm/drm_connector.c
> >> > @@ -1252,7 +1252,7 @@ static const struct drm_prop_enum_list dp_colorspaces[] = {
> >> >   *   INPUT_PROP_DIRECT) will still map 1:1 to the actual LCD panel
> >> >   *   coordinates, so if userspace rotates the picture to adjust for
> >> >   *   the orientation it must also apply the same transformation to the
> >> > - *   touchscreen input coordinates. This property is initialized by calling
> >> > + *   touchscreen input coordinates. This property value is set by calling
> >> >   *   drm_connector_set_panel_orientation() or
> >> >   *   drm_connector_set_panel_orientation_with_quirk()
> >> >   *
> >> > @@ -2341,8 +2341,8 @@ EXPORT_SYMBOL(drm_connector_set_vrr_capable_property);
> >> >   * @connector: connector for which to set the panel-orientation property.
> >> >   * @panel_orientation: drm_panel_orientation value to set
> >> >   *
> >> > - * This function sets the connector's panel_orientation and attaches
> >> > - * a "panel orientation" property to the connector.
> >> > + * This function sets the connector's panel_orientation value. If the property
> >> > + * doesn't exist, it will try to create one.
> >> >   *
> >> >   * Calling this function on a connector where the panel_orientation has
> >> >   * already been set is a no-op (e.g. the orientation has been overridden with
> >> > @@ -2373,19 +2373,12 @@ int drm_connector_set_panel_orientation(
> >> >       info->panel_orientation = panel_orientation;
> >> >
> >> >       prop = dev->mode_config.panel_orientation_property;
> >> > -     if (!prop) {
> >> > -             prop = drm_property_create_enum(dev, DRM_MODE_PROP_IMMUTABLE,
> >> > -                             "panel orientation",
> >> > -                             drm_panel_orientation_enum_list,
> >> > -                             ARRAY_SIZE(drm_panel_orientation_enum_list));
> >> > -             if (!prop)
> >> > -                     return -ENOMEM;
> >> > -
> >> > -             dev->mode_config.panel_orientation_property = prop;
> >> > -     }
> >> > +     if (!prop &&
> >> > +         drm_connector_init_panel_orientation_property(connector) < 0)
> >> > +             return -ENOMEM;
> >> >
> >>
> >> In the case where the property has not been created beforehand, you
> >> forgot to reinitialize prop here, after calling
> >> drm_connector_init_panel_orientation_property().  This means
> > hi Gabriel,
> >
> > drm_connector_init_panel_orientation_property() will create prop if
> > it's null. If prop fails to be created there, it will return -ENOMEM.
>
> Yes.  But *after the property is successfully created*, the prop variable is still
> NULL.  And then you call the following, using prop, which is still NULL:
>
> >> > +     drm_object_property_set_value(&connector->base, prop,
> >> > +                                   info->panel_orientation);
>
> This will do property->dev right on the first line of code, and dereference the
> null prop pointer.

Ah, right. Sorry that I totally missed this.
I'll fix it in the next version if the idea of this patch is accepted.
There might be another preferred solution for this.

>
> You must do
>
>   prop = dev->mode_config.panel_orientation_property;
>
> again after drm_connector_init_panel_orientation_property successfully
> returns, or call drm_object_property_set_value using
> dev->mode_config.panel_orientation_property directly:
>
>   drm_object_property_set_value(&connector->base,
>                         dev->mode_config.panel_orientation_property
>                         info->panel_orientation);
>
> --
> Gabriel Krisman Bertazi

Re: [Intel-gfx] [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Simon Ser]

On Tuesday, February 15th, 2022 at 13:04, Emil Velikov <emil.l.velikov@gmail.com> wrote:

> Greetings everyone,
>
> Padron for joining in so late o/
>
> On Tue, 8 Feb 2022 at 08:42, Hsin-Yi Wang <hsinyi@chromium.org> wrote:
> >
> > drm_dev_register() sets connector->registration_state to
> > DRM_CONNECTOR_REGISTERED and dev->registered to true. If
> > drm_connector_set_panel_orientation() is first called after
> > drm_dev_register(), it will fail several checks and results in following
> > warning.
> >
> > Add a function to create panel orientation property and set default value
> > to UNKNOWN, so drivers can call this function to init the property earlier
> > , and let the panel set the real value later.
> >
>
> The warning illustrates a genuine race condition, where userspace will
> read the old/invalid property value/state. So this patch masks away
> the WARNING without addressing the actual issue.
> Instead can we fix the respective drivers, so that no properties are
> created after drm_dev_register()?
>
> Longer version:
> As we look into drm_dev_register() it's in charge of creating the
> dev/sysfs nodes (et al). Note that connectors cannot disappear at
> runtime.
> For panel orientation, we are creating an immutable connector
> properly, meaning that as soon as drm_dev_register() is called we must
> ensure that the property is available (if applicable) and set to the
> correct value.

Unfortunately we can't quite do this. To apply the panel orientation quirks we
need to grab the EDID of the eDP connector, and this happened too late in my
testing.

What we can do is create the prop early during module load, and update it when
we read the EDID (at the place where we create it right now). User-space will
receive a hotplug event after the EDID is read, so will be able to pick up the
new value if any.

Re: [Intel-gfx] [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Simon Ser]

On Tuesday, February 15th, 2022 at 13:04, Emil Velikov <emil.l.velikov@gmail.com> wrote:

> Greetings everyone,
>
> Padron for joining in so late o/
>
> On Tue, 8 Feb 2022 at 08:42, Hsin-Yi Wang <hsinyi@chromium.org> wrote:
> >
> > drm_dev_register() sets connector->registration_state to
> > DRM_CONNECTOR_REGISTERED and dev->registered to true. If
> > drm_connector_set_panel_orientation() is first called after
> > drm_dev_register(), it will fail several checks and results in following
> > warning.
> >
> > Add a function to create panel orientation property and set default value
> > to UNKNOWN, so drivers can call this function to init the property earlier
> > , and let the panel set the real value later.
> >
>
> The warning illustrates a genuine race condition, where userspace will
> read the old/invalid property value/state. So this patch masks away
> the WARNING without addressing the actual issue.
> Instead can we fix the respective drivers, so that no properties are
> created after drm_dev_register()?
>
> Longer version:
> As we look into drm_dev_register() it's in charge of creating the
> dev/sysfs nodes (et al). Note that connectors cannot disappear at
> runtime.
> For panel orientation, we are creating an immutable connector
> properly, meaning that as soon as drm_dev_register() is called we must
> ensure that the property is available (if applicable) and set to the
> correct value.

Unfortunately we can't quite do this. To apply the panel orientation quirks we
need to grab the EDID of the eDP connector, and this happened too late in my
testing.

What we can do is create the prop early during module load, and update it when
we read the EDID (at the place where we create it right now). User-space will
receive a hotplug event after the EDID is read, so will be able to pick up the
new value if any.

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

Re: [Intel-gfx] [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Simon Ser]

On Tuesday, February 15th, 2022 at 13:04, Emil Velikov <emil.l.velikov@gmail.com> wrote:

> Greetings everyone,
>
> Padron for joining in so late o/
>
> On Tue, 8 Feb 2022 at 08:42, Hsin-Yi Wang <hsinyi@chromium.org> wrote:
> >
> > drm_dev_register() sets connector->registration_state to
> > DRM_CONNECTOR_REGISTERED and dev->registered to true. If
> > drm_connector_set_panel_orientation() is first called after
> > drm_dev_register(), it will fail several checks and results in following
> > warning.
> >
> > Add a function to create panel orientation property and set default value
> > to UNKNOWN, so drivers can call this function to init the property earlier
> > , and let the panel set the real value later.
> >
>
> The warning illustrates a genuine race condition, where userspace will
> read the old/invalid property value/state. So this patch masks away
> the WARNING without addressing the actual issue.
> Instead can we fix the respective drivers, so that no properties are
> created after drm_dev_register()?
>
> Longer version:
> As we look into drm_dev_register() it's in charge of creating the
> dev/sysfs nodes (et al). Note that connectors cannot disappear at
> runtime.
> For panel orientation, we are creating an immutable connector
> properly, meaning that as soon as drm_dev_register() is called we must
> ensure that the property is available (if applicable) and set to the
> correct value.

Unfortunately we can't quite do this. To apply the panel orientation quirks we
need to grab the EDID of the eDP connector, and this happened too late in my
testing.

What we can do is create the prop early during module load, and update it when
we read the EDID (at the place where we create it right now). User-space will
receive a hotplug event after the EDID is read, so will be able to pick up the
new value if any.

Re: [Intel-gfx] [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Simon Ser]

On Tuesday, February 15th, 2022 at 13:04, Emil Velikov <emil.l.velikov@gmail.com> wrote:

> Greetings everyone,
>
> Padron for joining in so late o/
>
> On Tue, 8 Feb 2022 at 08:42, Hsin-Yi Wang <hsinyi@chromium.org> wrote:
> >
> > drm_dev_register() sets connector->registration_state to
> > DRM_CONNECTOR_REGISTERED and dev->registered to true. If
> > drm_connector_set_panel_orientation() is first called after
> > drm_dev_register(), it will fail several checks and results in following
> > warning.
> >
> > Add a function to create panel orientation property and set default value
> > to UNKNOWN, so drivers can call this function to init the property earlier
> > , and let the panel set the real value later.
> >
>
> The warning illustrates a genuine race condition, where userspace will
> read the old/invalid property value/state. So this patch masks away
> the WARNING without addressing the actual issue.
> Instead can we fix the respective drivers, so that no properties are
> created after drm_dev_register()?
>
> Longer version:
> As we look into drm_dev_register() it's in charge of creating the
> dev/sysfs nodes (et al). Note that connectors cannot disappear at
> runtime.
> For panel orientation, we are creating an immutable connector
> properly, meaning that as soon as drm_dev_register() is called we must
> ensure that the property is available (if applicable) and set to the
> correct value.

Unfortunately we can't quite do this. To apply the panel orientation quirks we
need to grab the EDID of the eDP connector, and this happened too late in my
testing.

What we can do is create the prop early during module load, and update it when
we read the EDID (at the place where we create it right now). User-space will
receive a hotplug event after the EDID is read, so will be able to pick up the
new value if any.

Re: [Intel-gfx] [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Simon Ser]

On Tuesday, February 15th, 2022 at 13:04, Emil Velikov <emil.l.velikov@gmail.com> wrote:

> Greetings everyone,
>
> Padron for joining in so late o/
>
> On Tue, 8 Feb 2022 at 08:42, Hsin-Yi Wang <hsinyi@chromium.org> wrote:
> >
> > drm_dev_register() sets connector->registration_state to
> > DRM_CONNECTOR_REGISTERED and dev->registered to true. If
> > drm_connector_set_panel_orientation() is first called after
> > drm_dev_register(), it will fail several checks and results in following
> > warning.
> >
> > Add a function to create panel orientation property and set default value
> > to UNKNOWN, so drivers can call this function to init the property earlier
> > , and let the panel set the real value later.
> >
>
> The warning illustrates a genuine race condition, where userspace will
> read the old/invalid property value/state. So this patch masks away
> the WARNING without addressing the actual issue.
> Instead can we fix the respective drivers, so that no properties are
> created after drm_dev_register()?
>
> Longer version:
> As we look into drm_dev_register() it's in charge of creating the
> dev/sysfs nodes (et al). Note that connectors cannot disappear at
> runtime.
> For panel orientation, we are creating an immutable connector
> properly, meaning that as soon as drm_dev_register() is called we must
> ensure that the property is available (if applicable) and set to the
> correct value.

Unfortunately we can't quite do this. To apply the panel orientation quirks we
need to grab the EDID of the eDP connector, and this happened too late in my
testing.

What we can do is create the prop early during module load, and update it when
we read the EDID (at the place where we create it right now). User-space will
receive a hotplug event after the EDID is read, so will be able to pick up the
new value if any.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [Intel-gfx] [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Simon Ser]

On Tuesday, February 15th, 2022 at 13:04, Emil Velikov <emil.l.velikov@gmail.com> wrote:

> Greetings everyone,
>
> Padron for joining in so late o/
>
> On Tue, 8 Feb 2022 at 08:42, Hsin-Yi Wang <hsinyi@chromium.org> wrote:
> >
> > drm_dev_register() sets connector->registration_state to
> > DRM_CONNECTOR_REGISTERED and dev->registered to true. If
> > drm_connector_set_panel_orientation() is first called after
> > drm_dev_register(), it will fail several checks and results in following
> > warning.
> >
> > Add a function to create panel orientation property and set default value
> > to UNKNOWN, so drivers can call this function to init the property earlier
> > , and let the panel set the real value later.
> >
>
> The warning illustrates a genuine race condition, where userspace will
> read the old/invalid property value/state. So this patch masks away
> the WARNING without addressing the actual issue.
> Instead can we fix the respective drivers, so that no properties are
> created after drm_dev_register()?
>
> Longer version:
> As we look into drm_dev_register() it's in charge of creating the
> dev/sysfs nodes (et al). Note that connectors cannot disappear at
> runtime.
> For panel orientation, we are creating an immutable connector
> properly, meaning that as soon as drm_dev_register() is called we must
> ensure that the property is available (if applicable) and set to the
> correct value.

Unfortunately we can't quite do this. To apply the panel orientation quirks we
need to grab the EDID of the eDP connector, and this happened too late in my
testing.

What we can do is create the prop early during module load, and update it when
we read the EDID (at the place where we create it right now). User-space will
receive a hotplug event after the EDID is read, so will be able to pick up the
new value if any.

Re: [Intel-gfx] [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Emil Velikov]

On Tue, 15 Feb 2022 at 13:55, Simon Ser <contact@emersion.fr> wrote:
>
> On Tuesday, February 15th, 2022 at 13:04, Emil Velikov <emil.l.velikov@gmail.com> wrote:
>
> > Greetings everyone,
> >
> > Padron for joining in so late o/
> >
> > On Tue, 8 Feb 2022 at 08:42, Hsin-Yi Wang <hsinyi@chromium.org> wrote:
> > >
> > > drm_dev_register() sets connector->registration_state to
> > > DRM_CONNECTOR_REGISTERED and dev->registered to true. If
> > > drm_connector_set_panel_orientation() is first called after
> > > drm_dev_register(), it will fail several checks and results in following
> > > warning.
> > >
> > > Add a function to create panel orientation property and set default value
> > > to UNKNOWN, so drivers can call this function to init the property earlier
> > > , and let the panel set the real value later.
> > >
> >
> > The warning illustrates a genuine race condition, where userspace will
> > read the old/invalid property value/state. So this patch masks away
> > the WARNING without addressing the actual issue.
> > Instead can we fix the respective drivers, so that no properties are
> > created after drm_dev_register()?
> >
> > Longer version:
> > As we look into drm_dev_register() it's in charge of creating the
> > dev/sysfs nodes (et al). Note that connectors cannot disappear at
> > runtime.
> > For panel orientation, we are creating an immutable connector
> > properly, meaning that as soon as drm_dev_register() is called we must
> > ensure that the property is available (if applicable) and set to the
> > correct value.
>
> Unfortunately we can't quite do this. To apply the panel orientation quirks we
> need to grab the EDID of the eDP connector, and this happened too late in my
> testing.
>
> What we can do is create the prop early during module load, and update it when
> we read the EDID (at the place where we create it right now). User-space will
> receive a hotplug event after the EDID is read, so will be able to pick up the
> new value if any.

Didn't quite get that, are you saying that a GETPROPERTY for the EDID,
the ioctl blocks or that we get an empty EDID?

The EDID hotplug even thing is neat - sounds like it also signals on
panel orientation, correct?
On such an event, which properties userspace should be re-fetching -
everything or guess randomly?

Looking through the documentation, I cannot see a clear answer :-\

Thanks
Emil

Re: [Intel-gfx] [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Emil Velikov]

On Tue, 15 Feb 2022 at 13:55, Simon Ser <contact@emersion.fr> wrote:
>
> On Tuesday, February 15th, 2022 at 13:04, Emil Velikov <emil.l.velikov@gmail.com> wrote:
>
> > Greetings everyone,
> >
> > Padron for joining in so late o/
> >
> > On Tue, 8 Feb 2022 at 08:42, Hsin-Yi Wang <hsinyi@chromium.org> wrote:
> > >
> > > drm_dev_register() sets connector->registration_state to
> > > DRM_CONNECTOR_REGISTERED and dev->registered to true. If
> > > drm_connector_set_panel_orientation() is first called after
> > > drm_dev_register(), it will fail several checks and results in following
> > > warning.
> > >
> > > Add a function to create panel orientation property and set default value
> > > to UNKNOWN, so drivers can call this function to init the property earlier
> > > , and let the panel set the real value later.
> > >
> >
> > The warning illustrates a genuine race condition, where userspace will
> > read the old/invalid property value/state. So this patch masks away
> > the WARNING without addressing the actual issue.
> > Instead can we fix the respective drivers, so that no properties are
> > created after drm_dev_register()?
> >
> > Longer version:
> > As we look into drm_dev_register() it's in charge of creating the
> > dev/sysfs nodes (et al). Note that connectors cannot disappear at
> > runtime.
> > For panel orientation, we are creating an immutable connector
> > properly, meaning that as soon as drm_dev_register() is called we must
> > ensure that the property is available (if applicable) and set to the
> > correct value.
>
> Unfortunately we can't quite do this. To apply the panel orientation quirks we
> need to grab the EDID of the eDP connector, and this happened too late in my
> testing.
>
> What we can do is create the prop early during module load, and update it when
> we read the EDID (at the place where we create it right now). User-space will
> receive a hotplug event after the EDID is read, so will be able to pick up the
> new value if any.

Didn't quite get that, are you saying that a GETPROPERTY for the EDID,
the ioctl blocks or that we get an empty EDID?

The EDID hotplug even thing is neat - sounds like it also signals on
panel orientation, correct?
On such an event, which properties userspace should be re-fetching -
everything or guess randomly?

Looking through the documentation, I cannot see a clear answer :-\

Thanks
Emil

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

Re: [Intel-gfx] [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Emil Velikov]

On Tue, 15 Feb 2022 at 13:55, Simon Ser <contact@emersion.fr> wrote:
>
> On Tuesday, February 15th, 2022 at 13:04, Emil Velikov <emil.l.velikov@gmail.com> wrote:
>
> > Greetings everyone,
> >
> > Padron for joining in so late o/
> >
> > On Tue, 8 Feb 2022 at 08:42, Hsin-Yi Wang <hsinyi@chromium.org> wrote:
> > >
> > > drm_dev_register() sets connector->registration_state to
> > > DRM_CONNECTOR_REGISTERED and dev->registered to true. If
> > > drm_connector_set_panel_orientation() is first called after
> > > drm_dev_register(), it will fail several checks and results in following
> > > warning.
> > >
> > > Add a function to create panel orientation property and set default value
> > > to UNKNOWN, so drivers can call this function to init the property earlier
> > > , and let the panel set the real value later.
> > >
> >
> > The warning illustrates a genuine race condition, where userspace will
> > read the old/invalid property value/state. So this patch masks away
> > the WARNING without addressing the actual issue.
> > Instead can we fix the respective drivers, so that no properties are
> > created after drm_dev_register()?
> >
> > Longer version:
> > As we look into drm_dev_register() it's in charge of creating the
> > dev/sysfs nodes (et al). Note that connectors cannot disappear at
> > runtime.
> > For panel orientation, we are creating an immutable connector
> > properly, meaning that as soon as drm_dev_register() is called we must
> > ensure that the property is available (if applicable) and set to the
> > correct value.
>
> Unfortunately we can't quite do this. To apply the panel orientation quirks we
> need to grab the EDID of the eDP connector, and this happened too late in my
> testing.
>
> What we can do is create the prop early during module load, and update it when
> we read the EDID (at the place where we create it right now). User-space will
> receive a hotplug event after the EDID is read, so will be able to pick up the
> new value if any.

Didn't quite get that, are you saying that a GETPROPERTY for the EDID,
the ioctl blocks or that we get an empty EDID?

The EDID hotplug even thing is neat - sounds like it also signals on
panel orientation, correct?
On such an event, which properties userspace should be re-fetching -
everything or guess randomly?

Looking through the documentation, I cannot see a clear answer :-\

Thanks
Emil

Re: [Intel-gfx] [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Emil Velikov]

On Tue, 15 Feb 2022 at 13:55, Simon Ser <contact@emersion.fr> wrote:
>
> On Tuesday, February 15th, 2022 at 13:04, Emil Velikov <emil.l.velikov@gmail.com> wrote:
>
> > Greetings everyone,
> >
> > Padron for joining in so late o/
> >
> > On Tue, 8 Feb 2022 at 08:42, Hsin-Yi Wang <hsinyi@chromium.org> wrote:
> > >
> > > drm_dev_register() sets connector->registration_state to
> > > DRM_CONNECTOR_REGISTERED and dev->registered to true. If
> > > drm_connector_set_panel_orientation() is first called after
> > > drm_dev_register(), it will fail several checks and results in following
> > > warning.
> > >
> > > Add a function to create panel orientation property and set default value
> > > to UNKNOWN, so drivers can call this function to init the property earlier
> > > , and let the panel set the real value later.
> > >
> >
> > The warning illustrates a genuine race condition, where userspace will
> > read the old/invalid property value/state. So this patch masks away
> > the WARNING without addressing the actual issue.
> > Instead can we fix the respective drivers, so that no properties are
> > created after drm_dev_register()?
> >
> > Longer version:
> > As we look into drm_dev_register() it's in charge of creating the
> > dev/sysfs nodes (et al). Note that connectors cannot disappear at
> > runtime.
> > For panel orientation, we are creating an immutable connector
> > properly, meaning that as soon as drm_dev_register() is called we must
> > ensure that the property is available (if applicable) and set to the
> > correct value.
>
> Unfortunately we can't quite do this. To apply the panel orientation quirks we
> need to grab the EDID of the eDP connector, and this happened too late in my
> testing.
>
> What we can do is create the prop early during module load, and update it when
> we read the EDID (at the place where we create it right now). User-space will
> receive a hotplug event after the EDID is read, so will be able to pick up the
> new value if any.

Didn't quite get that, are you saying that a GETPROPERTY for the EDID,
the ioctl blocks or that we get an empty EDID?

The EDID hotplug even thing is neat - sounds like it also signals on
panel orientation, correct?
On such an event, which properties userspace should be re-fetching -
everything or guess randomly?

Looking through the documentation, I cannot see a clear answer :-\

Thanks
Emil

Re: [Intel-gfx] [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Emil Velikov]

On Tue, 15 Feb 2022 at 13:55, Simon Ser <contact@emersion.fr> wrote:
>
> On Tuesday, February 15th, 2022 at 13:04, Emil Velikov <emil.l.velikov@gmail.com> wrote:
>
> > Greetings everyone,
> >
> > Padron for joining in so late o/
> >
> > On Tue, 8 Feb 2022 at 08:42, Hsin-Yi Wang <hsinyi@chromium.org> wrote:
> > >
> > > drm_dev_register() sets connector->registration_state to
> > > DRM_CONNECTOR_REGISTERED and dev->registered to true. If
> > > drm_connector_set_panel_orientation() is first called after
> > > drm_dev_register(), it will fail several checks and results in following
> > > warning.
> > >
> > > Add a function to create panel orientation property and set default value
> > > to UNKNOWN, so drivers can call this function to init the property earlier
> > > , and let the panel set the real value later.
> > >
> >
> > The warning illustrates a genuine race condition, where userspace will
> > read the old/invalid property value/state. So this patch masks away
> > the WARNING without addressing the actual issue.
> > Instead can we fix the respective drivers, so that no properties are
> > created after drm_dev_register()?
> >
> > Longer version:
> > As we look into drm_dev_register() it's in charge of creating the
> > dev/sysfs nodes (et al). Note that connectors cannot disappear at
> > runtime.
> > For panel orientation, we are creating an immutable connector
> > properly, meaning that as soon as drm_dev_register() is called we must
> > ensure that the property is available (if applicable) and set to the
> > correct value.
>
> Unfortunately we can't quite do this. To apply the panel orientation quirks we
> need to grab the EDID of the eDP connector, and this happened too late in my
> testing.
>
> What we can do is create the prop early during module load, and update it when
> we read the EDID (at the place where we create it right now). User-space will
> receive a hotplug event after the EDID is read, so will be able to pick up the
> new value if any.

Didn't quite get that, are you saying that a GETPROPERTY for the EDID,
the ioctl blocks or that we get an empty EDID?

The EDID hotplug even thing is neat - sounds like it also signals on
panel orientation, correct?
On such an event, which properties userspace should be re-fetching -
everything or guess randomly?

Looking through the documentation, I cannot see a clear answer :-\

Thanks
Emil

Re: [Intel-gfx] [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Emil Velikov]

On Tue, 15 Feb 2022 at 13:55, Simon Ser <contact@emersion.fr> wrote:
>
> On Tuesday, February 15th, 2022 at 13:04, Emil Velikov <emil.l.velikov@gmail.com> wrote:
>
> > Greetings everyone,
> >
> > Padron for joining in so late o/
> >
> > On Tue, 8 Feb 2022 at 08:42, Hsin-Yi Wang <hsinyi@chromium.org> wrote:
> > >
> > > drm_dev_register() sets connector->registration_state to
> > > DRM_CONNECTOR_REGISTERED and dev->registered to true. If
> > > drm_connector_set_panel_orientation() is first called after
> > > drm_dev_register(), it will fail several checks and results in following
> > > warning.
> > >
> > > Add a function to create panel orientation property and set default value
> > > to UNKNOWN, so drivers can call this function to init the property earlier
> > > , and let the panel set the real value later.
> > >
> >
> > The warning illustrates a genuine race condition, where userspace will
> > read the old/invalid property value/state. So this patch masks away
> > the WARNING without addressing the actual issue.
> > Instead can we fix the respective drivers, so that no properties are
> > created after drm_dev_register()?
> >
> > Longer version:
> > As we look into drm_dev_register() it's in charge of creating the
> > dev/sysfs nodes (et al). Note that connectors cannot disappear at
> > runtime.
> > For panel orientation, we are creating an immutable connector
> > properly, meaning that as soon as drm_dev_register() is called we must
> > ensure that the property is available (if applicable) and set to the
> > correct value.
>
> Unfortunately we can't quite do this. To apply the panel orientation quirks we
> need to grab the EDID of the eDP connector, and this happened too late in my
> testing.
>
> What we can do is create the prop early during module load, and update it when
> we read the EDID (at the place where we create it right now). User-space will
> receive a hotplug event after the EDID is read, so will be able to pick up the
> new value if any.

Didn't quite get that, are you saying that a GETPROPERTY for the EDID,
the ioctl blocks or that we get an empty EDID?

The EDID hotplug even thing is neat - sounds like it also signals on
panel orientation, correct?
On such an event, which properties userspace should be re-fetching -
everything or guess randomly?

Looking through the documentation, I cannot see a clear answer :-\

Thanks
Emil

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [Intel-gfx] [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Simon Ser]

On Tuesday, February 15th, 2022 at 15:38, Emil Velikov <emil.l.velikov@gmail.com> wrote:

> On Tue, 15 Feb 2022 at 13:55, Simon Ser <contact@emersion.fr> wrote:
> >
> > On Tuesday, February 15th, 2022 at 13:04, Emil Velikov <emil.l.velikov@gmail.com> wrote:
> >
> > > Greetings everyone,
> > >
> > > Padron for joining in so late o/
> > >
> > > On Tue, 8 Feb 2022 at 08:42, Hsin-Yi Wang <hsinyi@chromium.org> wrote:
> > > >
> > > > drm_dev_register() sets connector->registration_state to
> > > > DRM_CONNECTOR_REGISTERED and dev->registered to true. If
> > > > drm_connector_set_panel_orientation() is first called after
> > > > drm_dev_register(), it will fail several checks and results in following
> > > > warning.
> > > >
> > > > Add a function to create panel orientation property and set default value
> > > > to UNKNOWN, so drivers can call this function to init the property earlier
> > > > , and let the panel set the real value later.
> > > >
> > >
> > > The warning illustrates a genuine race condition, where userspace will
> > > read the old/invalid property value/state. So this patch masks away
> > > the WARNING without addressing the actual issue.
> > > Instead can we fix the respective drivers, so that no properties are
> > > created after drm_dev_register()?
> > >
> > > Longer version:
> > > As we look into drm_dev_register() it's in charge of creating the
> > > dev/sysfs nodes (et al). Note that connectors cannot disappear at
> > > runtime.
> > > For panel orientation, we are creating an immutable connector
> > > properly, meaning that as soon as drm_dev_register() is called we must
> > > ensure that the property is available (if applicable) and set to the
> > > correct value.
> >
> > Unfortunately we can't quite do this. To apply the panel orientation quirks we
> > need to grab the EDID of the eDP connector, and this happened too late in my
> > testing.
> >
> > What we can do is create the prop early during module load, and update it when
> > we read the EDID (at the place where we create it right now). User-space will
> > receive a hotplug event after the EDID is read, so will be able to pick up the
> > new value if any.
>
> Didn't quite get that, are you saying that a GETPROPERTY for the EDID,
> the ioctl blocks or that we get an empty EDID?

I'm not referring to GETPROPERTY, I'm referring to the driver getting the EDID
from the sink (here, the eDP panel). In my experimentations with amdgpu I
noticed that the driver module load finished before the EDID was available to
the driver. Maybe other drivers behave differently and probe connectors when
loaded, not sure.

> The EDID hotplug even thing is neat - sounds like it also signals on
> panel orientation, correct?
> On such an event, which properties userspace should be re-fetching -
> everything or guess randomly?
>
> Looking through the documentation, I cannot see a clear answer :-\

User-space should re-fetch *all* properties. In practice some user-space may
only be fetching some properties, but that should get fixed in user-space.

Also the kernel can indicate that only a single connector changed via the
"CONNECTOR" uevent prop, or even a single connector property via "PROPERTY".
See [1] for a user-space implementation. But all of this is purely an optional
optimization. Re-fetching all properties is a bit slower (especially if some
drmModeGetConnector calls force-probe connectors) but works perfectly fine.

It would be nice to document, if you have the time feel free to send a patch
and CC danvet, pq and me.

[1]: https://gitlab.freedesktop.org/wlroots/wlroots/-/blob/252b2348bd62170d97c4e81fb2050f757b56d67e/backend/session/session.c#L144

Re: [Intel-gfx] [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Simon Ser]

On Tuesday, February 15th, 2022 at 15:38, Emil Velikov <emil.l.velikov@gmail.com> wrote:

> On Tue, 15 Feb 2022 at 13:55, Simon Ser <contact@emersion.fr> wrote:
> >
> > On Tuesday, February 15th, 2022 at 13:04, Emil Velikov <emil.l.velikov@gmail.com> wrote:
> >
> > > Greetings everyone,
> > >
> > > Padron for joining in so late o/
> > >
> > > On Tue, 8 Feb 2022 at 08:42, Hsin-Yi Wang <hsinyi@chromium.org> wrote:
> > > >
> > > > drm_dev_register() sets connector->registration_state to
> > > > DRM_CONNECTOR_REGISTERED and dev->registered to true. If
> > > > drm_connector_set_panel_orientation() is first called after
> > > > drm_dev_register(), it will fail several checks and results in following
> > > > warning.
> > > >
> > > > Add a function to create panel orientation property and set default value
> > > > to UNKNOWN, so drivers can call this function to init the property earlier
> > > > , and let the panel set the real value later.
> > > >
> > >
> > > The warning illustrates a genuine race condition, where userspace will
> > > read the old/invalid property value/state. So this patch masks away
> > > the WARNING without addressing the actual issue.
> > > Instead can we fix the respective drivers, so that no properties are
> > > created after drm_dev_register()?
> > >
> > > Longer version:
> > > As we look into drm_dev_register() it's in charge of creating the
> > > dev/sysfs nodes (et al). Note that connectors cannot disappear at
> > > runtime.
> > > For panel orientation, we are creating an immutable connector
> > > properly, meaning that as soon as drm_dev_register() is called we must
> > > ensure that the property is available (if applicable) and set to the
> > > correct value.
> >
> > Unfortunately we can't quite do this. To apply the panel orientation quirks we
> > need to grab the EDID of the eDP connector, and this happened too late in my
> > testing.
> >
> > What we can do is create the prop early during module load, and update it when
> > we read the EDID (at the place where we create it right now). User-space will
> > receive a hotplug event after the EDID is read, so will be able to pick up the
> > new value if any.
>
> Didn't quite get that, are you saying that a GETPROPERTY for the EDID,
> the ioctl blocks or that we get an empty EDID?

I'm not referring to GETPROPERTY, I'm referring to the driver getting the EDID
from the sink (here, the eDP panel). In my experimentations with amdgpu I
noticed that the driver module load finished before the EDID was available to
the driver. Maybe other drivers behave differently and probe connectors when
loaded, not sure.

> The EDID hotplug even thing is neat - sounds like it also signals on
> panel orientation, correct?
> On such an event, which properties userspace should be re-fetching -
> everything or guess randomly?
>
> Looking through the documentation, I cannot see a clear answer :-\

User-space should re-fetch *all* properties. In practice some user-space may
only be fetching some properties, but that should get fixed in user-space.

Also the kernel can indicate that only a single connector changed via the
"CONNECTOR" uevent prop, or even a single connector property via "PROPERTY".
See [1] for a user-space implementation. But all of this is purely an optional
optimization. Re-fetching all properties is a bit slower (especially if some
drmModeGetConnector calls force-probe connectors) but works perfectly fine.

It would be nice to document, if you have the time feel free to send a patch
and CC danvet, pq and me.

[1]: https://gitlab.freedesktop.org/wlroots/wlroots/-/blob/252b2348bd62170d97c4e81fb2050f757b56d67e/backend/session/session.c#L144

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

Re: [Intel-gfx] [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Simon Ser]

On Tuesday, February 15th, 2022 at 15:38, Emil Velikov <emil.l.velikov@gmail.com> wrote:

> On Tue, 15 Feb 2022 at 13:55, Simon Ser <contact@emersion.fr> wrote:
> >
> > On Tuesday, February 15th, 2022 at 13:04, Emil Velikov <emil.l.velikov@gmail.com> wrote:
> >
> > > Greetings everyone,
> > >
> > > Padron for joining in so late o/
> > >
> > > On Tue, 8 Feb 2022 at 08:42, Hsin-Yi Wang <hsinyi@chromium.org> wrote:
> > > >
> > > > drm_dev_register() sets connector->registration_state to
> > > > DRM_CONNECTOR_REGISTERED and dev->registered to true. If
> > > > drm_connector_set_panel_orientation() is first called after
> > > > drm_dev_register(), it will fail several checks and results in following
> > > > warning.
> > > >
> > > > Add a function to create panel orientation property and set default value
> > > > to UNKNOWN, so drivers can call this function to init the property earlier
> > > > , and let the panel set the real value later.
> > > >
> > >
> > > The warning illustrates a genuine race condition, where userspace will
> > > read the old/invalid property value/state. So this patch masks away
> > > the WARNING without addressing the actual issue.
> > > Instead can we fix the respective drivers, so that no properties are
> > > created after drm_dev_register()?
> > >
> > > Longer version:
> > > As we look into drm_dev_register() it's in charge of creating the
> > > dev/sysfs nodes (et al). Note that connectors cannot disappear at
> > > runtime.
> > > For panel orientation, we are creating an immutable connector
> > > properly, meaning that as soon as drm_dev_register() is called we must
> > > ensure that the property is available (if applicable) and set to the
> > > correct value.
> >
> > Unfortunately we can't quite do this. To apply the panel orientation quirks we
> > need to grab the EDID of the eDP connector, and this happened too late in my
> > testing.
> >
> > What we can do is create the prop early during module load, and update it when
> > we read the EDID (at the place where we create it right now). User-space will
> > receive a hotplug event after the EDID is read, so will be able to pick up the
> > new value if any.
>
> Didn't quite get that, are you saying that a GETPROPERTY for the EDID,
> the ioctl blocks or that we get an empty EDID?

I'm not referring to GETPROPERTY, I'm referring to the driver getting the EDID
from the sink (here, the eDP panel). In my experimentations with amdgpu I
noticed that the driver module load finished before the EDID was available to
the driver. Maybe other drivers behave differently and probe connectors when
loaded, not sure.

> The EDID hotplug even thing is neat - sounds like it also signals on
> panel orientation, correct?
> On such an event, which properties userspace should be re-fetching -
> everything or guess randomly?
>
> Looking through the documentation, I cannot see a clear answer :-\

User-space should re-fetch *all* properties. In practice some user-space may
only be fetching some properties, but that should get fixed in user-space.

Also the kernel can indicate that only a single connector changed via the
"CONNECTOR" uevent prop, or even a single connector property via "PROPERTY".
See [1] for a user-space implementation. But all of this is purely an optional
optimization. Re-fetching all properties is a bit slower (especially if some
drmModeGetConnector calls force-probe connectors) but works perfectly fine.

It would be nice to document, if you have the time feel free to send a patch
and CC danvet, pq and me.

[1]: https://gitlab.freedesktop.org/wlroots/wlroots/-/blob/252b2348bd62170d97c4e81fb2050f757b56d67e/backend/session/session.c#L144

Re: [Intel-gfx] [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Simon Ser]

On Tuesday, February 15th, 2022 at 15:38, Emil Velikov <emil.l.velikov@gmail.com> wrote:

> On Tue, 15 Feb 2022 at 13:55, Simon Ser <contact@emersion.fr> wrote:
> >
> > On Tuesday, February 15th, 2022 at 13:04, Emil Velikov <emil.l.velikov@gmail.com> wrote:
> >
> > > Greetings everyone,
> > >
> > > Padron for joining in so late o/
> > >
> > > On Tue, 8 Feb 2022 at 08:42, Hsin-Yi Wang <hsinyi@chromium.org> wrote:
> > > >
> > > > drm_dev_register() sets connector->registration_state to
> > > > DRM_CONNECTOR_REGISTERED and dev->registered to true. If
> > > > drm_connector_set_panel_orientation() is first called after
> > > > drm_dev_register(), it will fail several checks and results in following
> > > > warning.
> > > >
> > > > Add a function to create panel orientation property and set default value
> > > > to UNKNOWN, so drivers can call this function to init the property earlier
> > > > , and let the panel set the real value later.
> > > >
> > >
> > > The warning illustrates a genuine race condition, where userspace will
> > > read the old/invalid property value/state. So this patch masks away
> > > the WARNING without addressing the actual issue.
> > > Instead can we fix the respective drivers, so that no properties are
> > > created after drm_dev_register()?
> > >
> > > Longer version:
> > > As we look into drm_dev_register() it's in charge of creating the
> > > dev/sysfs nodes (et al). Note that connectors cannot disappear at
> > > runtime.
> > > For panel orientation, we are creating an immutable connector
> > > properly, meaning that as soon as drm_dev_register() is called we must
> > > ensure that the property is available (if applicable) and set to the
> > > correct value.
> >
> > Unfortunately we can't quite do this. To apply the panel orientation quirks we
> > need to grab the EDID of the eDP connector, and this happened too late in my
> > testing.
> >
> > What we can do is create the prop early during module load, and update it when
> > we read the EDID (at the place where we create it right now). User-space will
> > receive a hotplug event after the EDID is read, so will be able to pick up the
> > new value if any.
>
> Didn't quite get that, are you saying that a GETPROPERTY for the EDID,
> the ioctl blocks or that we get an empty EDID?

I'm not referring to GETPROPERTY, I'm referring to the driver getting the EDID
from the sink (here, the eDP panel). In my experimentations with amdgpu I
noticed that the driver module load finished before the EDID was available to
the driver. Maybe other drivers behave differently and probe connectors when
loaded, not sure.

> The EDID hotplug even thing is neat - sounds like it also signals on
> panel orientation, correct?
> On such an event, which properties userspace should be re-fetching -
> everything or guess randomly?
>
> Looking through the documentation, I cannot see a clear answer :-\

User-space should re-fetch *all* properties. In practice some user-space may
only be fetching some properties, but that should get fixed in user-space.

Also the kernel can indicate that only a single connector changed via the
"CONNECTOR" uevent prop, or even a single connector property via "PROPERTY".
See [1] for a user-space implementation. But all of this is purely an optional
optimization. Re-fetching all properties is a bit slower (especially if some
drmModeGetConnector calls force-probe connectors) but works perfectly fine.

It would be nice to document, if you have the time feel free to send a patch
and CC danvet, pq and me.

[1]: https://gitlab.freedesktop.org/wlroots/wlroots/-/blob/252b2348bd62170d97c4e81fb2050f757b56d67e/backend/session/session.c#L144

Re: [Intel-gfx] [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Simon Ser]

On Tuesday, February 15th, 2022 at 15:38, Emil Velikov <emil.l.velikov@gmail.com> wrote:

> On Tue, 15 Feb 2022 at 13:55, Simon Ser <contact@emersion.fr> wrote:
> >
> > On Tuesday, February 15th, 2022 at 13:04, Emil Velikov <emil.l.velikov@gmail.com> wrote:
> >
> > > Greetings everyone,
> > >
> > > Padron for joining in so late o/
> > >
> > > On Tue, 8 Feb 2022 at 08:42, Hsin-Yi Wang <hsinyi@chromium.org> wrote:
> > > >
> > > > drm_dev_register() sets connector->registration_state to
> > > > DRM_CONNECTOR_REGISTERED and dev->registered to true. If
> > > > drm_connector_set_panel_orientation() is first called after
> > > > drm_dev_register(), it will fail several checks and results in following
> > > > warning.
> > > >
> > > > Add a function to create panel orientation property and set default value
> > > > to UNKNOWN, so drivers can call this function to init the property earlier
> > > > , and let the panel set the real value later.
> > > >
> > >
> > > The warning illustrates a genuine race condition, where userspace will
> > > read the old/invalid property value/state. So this patch masks away
> > > the WARNING without addressing the actual issue.
> > > Instead can we fix the respective drivers, so that no properties are
> > > created after drm_dev_register()?
> > >
> > > Longer version:
> > > As we look into drm_dev_register() it's in charge of creating the
> > > dev/sysfs nodes (et al). Note that connectors cannot disappear at
> > > runtime.
> > > For panel orientation, we are creating an immutable connector
> > > properly, meaning that as soon as drm_dev_register() is called we must
> > > ensure that the property is available (if applicable) and set to the
> > > correct value.
> >
> > Unfortunately we can't quite do this. To apply the panel orientation quirks we
> > need to grab the EDID of the eDP connector, and this happened too late in my
> > testing.
> >
> > What we can do is create the prop early during module load, and update it when
> > we read the EDID (at the place where we create it right now). User-space will
> > receive a hotplug event after the EDID is read, so will be able to pick up the
> > new value if any.
>
> Didn't quite get that, are you saying that a GETPROPERTY for the EDID,
> the ioctl blocks or that we get an empty EDID?

I'm not referring to GETPROPERTY, I'm referring to the driver getting the EDID
from the sink (here, the eDP panel). In my experimentations with amdgpu I
noticed that the driver module load finished before the EDID was available to
the driver. Maybe other drivers behave differently and probe connectors when
loaded, not sure.

> The EDID hotplug even thing is neat - sounds like it also signals on
> panel orientation, correct?
> On such an event, which properties userspace should be re-fetching -
> everything or guess randomly?
>
> Looking through the documentation, I cannot see a clear answer :-\

User-space should re-fetch *all* properties. In practice some user-space may
only be fetching some properties, but that should get fixed in user-space.

Also the kernel can indicate that only a single connector changed via the
"CONNECTOR" uevent prop, or even a single connector property via "PROPERTY".
See [1] for a user-space implementation. But all of this is purely an optional
optimization. Re-fetching all properties is a bit slower (especially if some
drmModeGetConnector calls force-probe connectors) but works perfectly fine.

It would be nice to document, if you have the time feel free to send a patch
and CC danvet, pq and me.

[1]: https://gitlab.freedesktop.org/wlroots/wlroots/-/blob/252b2348bd62170d97c4e81fb2050f757b56d67e/backend/session/session.c#L144

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [Intel-gfx] [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Simon Ser]

On Tuesday, February 15th, 2022 at 15:38, Emil Velikov <emil.l.velikov@gmail.com> wrote:

> On Tue, 15 Feb 2022 at 13:55, Simon Ser <contact@emersion.fr> wrote:
> >
> > On Tuesday, February 15th, 2022 at 13:04, Emil Velikov <emil.l.velikov@gmail.com> wrote:
> >
> > > Greetings everyone,
> > >
> > > Padron for joining in so late o/
> > >
> > > On Tue, 8 Feb 2022 at 08:42, Hsin-Yi Wang <hsinyi@chromium.org> wrote:
> > > >
> > > > drm_dev_register() sets connector->registration_state to
> > > > DRM_CONNECTOR_REGISTERED and dev->registered to true. If
> > > > drm_connector_set_panel_orientation() is first called after
> > > > drm_dev_register(), it will fail several checks and results in following
> > > > warning.
> > > >
> > > > Add a function to create panel orientation property and set default value
> > > > to UNKNOWN, so drivers can call this function to init the property earlier
> > > > , and let the panel set the real value later.
> > > >
> > >
> > > The warning illustrates a genuine race condition, where userspace will
> > > read the old/invalid property value/state. So this patch masks away
> > > the WARNING without addressing the actual issue.
> > > Instead can we fix the respective drivers, so that no properties are
> > > created after drm_dev_register()?
> > >
> > > Longer version:
> > > As we look into drm_dev_register() it's in charge of creating the
> > > dev/sysfs nodes (et al). Note that connectors cannot disappear at
> > > runtime.
> > > For panel orientation, we are creating an immutable connector
> > > properly, meaning that as soon as drm_dev_register() is called we must
> > > ensure that the property is available (if applicable) and set to the
> > > correct value.
> >
> > Unfortunately we can't quite do this. To apply the panel orientation quirks we
> > need to grab the EDID of the eDP connector, and this happened too late in my
> > testing.
> >
> > What we can do is create the prop early during module load, and update it when
> > we read the EDID (at the place where we create it right now). User-space will
> > receive a hotplug event after the EDID is read, so will be able to pick up the
> > new value if any.
>
> Didn't quite get that, are you saying that a GETPROPERTY for the EDID,
> the ioctl blocks or that we get an empty EDID?

I'm not referring to GETPROPERTY, I'm referring to the driver getting the EDID
from the sink (here, the eDP panel). In my experimentations with amdgpu I
noticed that the driver module load finished before the EDID was available to
the driver. Maybe other drivers behave differently and probe connectors when
loaded, not sure.

> The EDID hotplug even thing is neat - sounds like it also signals on
> panel orientation, correct?
> On such an event, which properties userspace should be re-fetching -
> everything or guess randomly?
>
> Looking through the documentation, I cannot see a clear answer :-\

User-space should re-fetch *all* properties. In practice some user-space may
only be fetching some properties, but that should get fixed in user-space.

Also the kernel can indicate that only a single connector changed via the
"CONNECTOR" uevent prop, or even a single connector property via "PROPERTY".
See [1] for a user-space implementation. But all of this is purely an optional
optimization. Re-fetching all properties is a bit slower (especially if some
drmModeGetConnector calls force-probe connectors) but works perfectly fine.

It would be nice to document, if you have the time feel free to send a patch
and CC danvet, pq and me.

[1]: https://gitlab.freedesktop.org/wlroots/wlroots/-/blob/252b2348bd62170d97c4e81fb2050f757b56d67e/backend/session/session.c#L144

Re: [Intel-gfx] [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Emil Velikov]

On Tue, 15 Feb 2022 at 16:37, Simon Ser <contact@emersion.fr> wrote:
>
> On Tuesday, February 15th, 2022 at 15:38, Emil Velikov <emil.l.velikov@gmail.com> wrote:
>
> > On Tue, 15 Feb 2022 at 13:55, Simon Ser <contact@emersion.fr> wrote:
> > >
> > > On Tuesday, February 15th, 2022 at 13:04, Emil Velikov <emil.l.velikov@gmail.com> wrote:
> > >
> > > > Greetings everyone,
> > > >
> > > > Padron for joining in so late o/
> > > >
> > > > On Tue, 8 Feb 2022 at 08:42, Hsin-Yi Wang <hsinyi@chromium.org> wrote:
> > > > >
> > > > > drm_dev_register() sets connector->registration_state to
> > > > > DRM_CONNECTOR_REGISTERED and dev->registered to true. If
> > > > > drm_connector_set_panel_orientation() is first called after
> > > > > drm_dev_register(), it will fail several checks and results in following
> > > > > warning.
> > > > >
> > > > > Add a function to create panel orientation property and set default value
> > > > > to UNKNOWN, so drivers can call this function to init the property earlier
> > > > > , and let the panel set the real value later.
> > > > >
> > > >
> > > > The warning illustrates a genuine race condition, where userspace will
> > > > read the old/invalid property value/state. So this patch masks away
> > > > the WARNING without addressing the actual issue.
> > > > Instead can we fix the respective drivers, so that no properties are
> > > > created after drm_dev_register()?
> > > >
> > > > Longer version:
> > > > As we look into drm_dev_register() it's in charge of creating the
> > > > dev/sysfs nodes (et al). Note that connectors cannot disappear at
> > > > runtime.
> > > > For panel orientation, we are creating an immutable connector
> > > > properly, meaning that as soon as drm_dev_register() is called we must
> > > > ensure that the property is available (if applicable) and set to the
> > > > correct value.
> > >
> > > Unfortunately we can't quite do this. To apply the panel orientation quirks we
> > > need to grab the EDID of the eDP connector, and this happened too late in my
> > > testing.
> > >
> > > What we can do is create the prop early during module load, and update it when
> > > we read the EDID (at the place where we create it right now). User-space will
> > > receive a hotplug event after the EDID is read, so will be able to pick up the
> > > new value if any.
> >
> > Didn't quite get that, are you saying that a GETPROPERTY for the EDID,
> > the ioctl blocks or that we get an empty EDID?
>
> I'm not referring to GETPROPERTY, I'm referring to the driver getting the EDID
> from the sink (here, the eDP panel). In my experimentations with amdgpu I
> noticed that the driver module load finished before the EDID was available to
> the driver. Maybe other drivers behave differently and probe connectors when
> loaded, not sure.
>
I see thanks.

> > The EDID hotplug even thing is neat - sounds like it also signals on
> > panel orientation, correct?
> > On such an event, which properties userspace should be re-fetching -
> > everything or guess randomly?
> >
> > Looking through the documentation, I cannot see a clear answer :-\
>
> User-space should re-fetch *all* properties. In practice some user-space may
> only be fetching some properties, but that should get fixed in user-space.
>
> Also the kernel can indicate that only a single connector changed via the
> "CONNECTOR" uevent prop, or even a single connector property via "PROPERTY".
> See [1] for a user-space implementation. But all of this is purely an optional
> optimization. Re-fetching all properties is a bit slower (especially if some
> drmModeGetConnector calls force-probe connectors) but works perfectly fine.
>
Looking at KDE/kwin (the one I'm running) - doesn't seem like it
handles any of the three "HOTPLUG", "PROPERTY" or "CONNECTOR" uevents
:-\
Skimming through GNOME/mutter - it handles "HOTPLUG", but not the optional ones.

Guess we're in the clear wrt potential races, even though the
documentation on the topic is lacklustre.

> It would be nice to document, if you have the time feel free to send a patch
> and CC danvet, pq and me.
>

Doubt I will have the time in the upcoming weeks, but I'll add it to
my ever-growing TODO list :-P

Thanks
Emil

Re: [Intel-gfx] [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Emil Velikov]

On Tue, 15 Feb 2022 at 16:37, Simon Ser <contact@emersion.fr> wrote:
>
> On Tuesday, February 15th, 2022 at 15:38, Emil Velikov <emil.l.velikov@gmail.com> wrote:
>
> > On Tue, 15 Feb 2022 at 13:55, Simon Ser <contact@emersion.fr> wrote:
> > >
> > > On Tuesday, February 15th, 2022 at 13:04, Emil Velikov <emil.l.velikov@gmail.com> wrote:
> > >
> > > > Greetings everyone,
> > > >
> > > > Padron for joining in so late o/
> > > >
> > > > On Tue, 8 Feb 2022 at 08:42, Hsin-Yi Wang <hsinyi@chromium.org> wrote:
> > > > >
> > > > > drm_dev_register() sets connector->registration_state to
> > > > > DRM_CONNECTOR_REGISTERED and dev->registered to true. If
> > > > > drm_connector_set_panel_orientation() is first called after
> > > > > drm_dev_register(), it will fail several checks and results in following
> > > > > warning.
> > > > >
> > > > > Add a function to create panel orientation property and set default value
> > > > > to UNKNOWN, so drivers can call this function to init the property earlier
> > > > > , and let the panel set the real value later.
> > > > >
> > > >
> > > > The warning illustrates a genuine race condition, where userspace will
> > > > read the old/invalid property value/state. So this patch masks away
> > > > the WARNING without addressing the actual issue.
> > > > Instead can we fix the respective drivers, so that no properties are
> > > > created after drm_dev_register()?
> > > >
> > > > Longer version:
> > > > As we look into drm_dev_register() it's in charge of creating the
> > > > dev/sysfs nodes (et al). Note that connectors cannot disappear at
> > > > runtime.
> > > > For panel orientation, we are creating an immutable connector
> > > > properly, meaning that as soon as drm_dev_register() is called we must
> > > > ensure that the property is available (if applicable) and set to the
> > > > correct value.
> > >
> > > Unfortunately we can't quite do this. To apply the panel orientation quirks we
> > > need to grab the EDID of the eDP connector, and this happened too late in my
> > > testing.
> > >
> > > What we can do is create the prop early during module load, and update it when
> > > we read the EDID (at the place where we create it right now). User-space will
> > > receive a hotplug event after the EDID is read, so will be able to pick up the
> > > new value if any.
> >
> > Didn't quite get that, are you saying that a GETPROPERTY for the EDID,
> > the ioctl blocks or that we get an empty EDID?
>
> I'm not referring to GETPROPERTY, I'm referring to the driver getting the EDID
> from the sink (here, the eDP panel). In my experimentations with amdgpu I
> noticed that the driver module load finished before the EDID was available to
> the driver. Maybe other drivers behave differently and probe connectors when
> loaded, not sure.
>
I see thanks.

> > The EDID hotplug even thing is neat - sounds like it also signals on
> > panel orientation, correct?
> > On such an event, which properties userspace should be re-fetching -
> > everything or guess randomly?
> >
> > Looking through the documentation, I cannot see a clear answer :-\
>
> User-space should re-fetch *all* properties. In practice some user-space may
> only be fetching some properties, but that should get fixed in user-space.
>
> Also the kernel can indicate that only a single connector changed via the
> "CONNECTOR" uevent prop, or even a single connector property via "PROPERTY".
> See [1] for a user-space implementation. But all of this is purely an optional
> optimization. Re-fetching all properties is a bit slower (especially if some
> drmModeGetConnector calls force-probe connectors) but works perfectly fine.
>
Looking at KDE/kwin (the one I'm running) - doesn't seem like it
handles any of the three "HOTPLUG", "PROPERTY" or "CONNECTOR" uevents
:-\
Skimming through GNOME/mutter - it handles "HOTPLUG", but not the optional ones.

Guess we're in the clear wrt potential races, even though the
documentation on the topic is lacklustre.

> It would be nice to document, if you have the time feel free to send a patch
> and CC danvet, pq and me.
>

Doubt I will have the time in the upcoming weeks, but I'll add it to
my ever-growing TODO list :-P

Thanks
Emil

Re: [Intel-gfx] [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Emil Velikov]

On Tue, 15 Feb 2022 at 16:37, Simon Ser <contact@emersion.fr> wrote:
>
> On Tuesday, February 15th, 2022 at 15:38, Emil Velikov <emil.l.velikov@gmail.com> wrote:
>
> > On Tue, 15 Feb 2022 at 13:55, Simon Ser <contact@emersion.fr> wrote:
> > >
> > > On Tuesday, February 15th, 2022 at 13:04, Emil Velikov <emil.l.velikov@gmail.com> wrote:
> > >
> > > > Greetings everyone,
> > > >
> > > > Padron for joining in so late o/
> > > >
> > > > On Tue, 8 Feb 2022 at 08:42, Hsin-Yi Wang <hsinyi@chromium.org> wrote:
> > > > >
> > > > > drm_dev_register() sets connector->registration_state to
> > > > > DRM_CONNECTOR_REGISTERED and dev->registered to true. If
> > > > > drm_connector_set_panel_orientation() is first called after
> > > > > drm_dev_register(), it will fail several checks and results in following
> > > > > warning.
> > > > >
> > > > > Add a function to create panel orientation property and set default value
> > > > > to UNKNOWN, so drivers can call this function to init the property earlier
> > > > > , and let the panel set the real value later.
> > > > >
> > > >
> > > > The warning illustrates a genuine race condition, where userspace will
> > > > read the old/invalid property value/state. So this patch masks away
> > > > the WARNING without addressing the actual issue.
> > > > Instead can we fix the respective drivers, so that no properties are
> > > > created after drm_dev_register()?
> > > >
> > > > Longer version:
> > > > As we look into drm_dev_register() it's in charge of creating the
> > > > dev/sysfs nodes (et al). Note that connectors cannot disappear at
> > > > runtime.
> > > > For panel orientation, we are creating an immutable connector
> > > > properly, meaning that as soon as drm_dev_register() is called we must
> > > > ensure that the property is available (if applicable) and set to the
> > > > correct value.
> > >
> > > Unfortunately we can't quite do this. To apply the panel orientation quirks we
> > > need to grab the EDID of the eDP connector, and this happened too late in my
> > > testing.
> > >
> > > What we can do is create the prop early during module load, and update it when
> > > we read the EDID (at the place where we create it right now). User-space will
> > > receive a hotplug event after the EDID is read, so will be able to pick up the
> > > new value if any.
> >
> > Didn't quite get that, are you saying that a GETPROPERTY for the EDID,
> > the ioctl blocks or that we get an empty EDID?
>
> I'm not referring to GETPROPERTY, I'm referring to the driver getting the EDID
> from the sink (here, the eDP panel). In my experimentations with amdgpu I
> noticed that the driver module load finished before the EDID was available to
> the driver. Maybe other drivers behave differently and probe connectors when
> loaded, not sure.
>
I see thanks.

> > The EDID hotplug even thing is neat - sounds like it also signals on
> > panel orientation, correct?
> > On such an event, which properties userspace should be re-fetching -
> > everything or guess randomly?
> >
> > Looking through the documentation, I cannot see a clear answer :-\
>
> User-space should re-fetch *all* properties. In practice some user-space may
> only be fetching some properties, but that should get fixed in user-space.
>
> Also the kernel can indicate that only a single connector changed via the
> "CONNECTOR" uevent prop, or even a single connector property via "PROPERTY".
> See [1] for a user-space implementation. But all of this is purely an optional
> optimization. Re-fetching all properties is a bit slower (especially if some
> drmModeGetConnector calls force-probe connectors) but works perfectly fine.
>
Looking at KDE/kwin (the one I'm running) - doesn't seem like it
handles any of the three "HOTPLUG", "PROPERTY" or "CONNECTOR" uevents
:-\
Skimming through GNOME/mutter - it handles "HOTPLUG", but not the optional ones.

Guess we're in the clear wrt potential races, even though the
documentation on the topic is lacklustre.

> It would be nice to document, if you have the time feel free to send a patch
> and CC danvet, pq and me.
>

Doubt I will have the time in the upcoming weeks, but I'll add it to
my ever-growing TODO list :-P

Thanks
Emil

Re: [Intel-gfx] [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Emil Velikov]

On Tue, 15 Feb 2022 at 16:37, Simon Ser <contact@emersion.fr> wrote:
>
> On Tuesday, February 15th, 2022 at 15:38, Emil Velikov <emil.l.velikov@gmail.com> wrote:
>
> > On Tue, 15 Feb 2022 at 13:55, Simon Ser <contact@emersion.fr> wrote:
> > >
> > > On Tuesday, February 15th, 2022 at 13:04, Emil Velikov <emil.l.velikov@gmail.com> wrote:
> > >
> > > > Greetings everyone,
> > > >
> > > > Padron for joining in so late o/
> > > >
> > > > On Tue, 8 Feb 2022 at 08:42, Hsin-Yi Wang <hsinyi@chromium.org> wrote:
> > > > >
> > > > > drm_dev_register() sets connector->registration_state to
> > > > > DRM_CONNECTOR_REGISTERED and dev->registered to true. If
> > > > > drm_connector_set_panel_orientation() is first called after
> > > > > drm_dev_register(), it will fail several checks and results in following
> > > > > warning.
> > > > >
> > > > > Add a function to create panel orientation property and set default value
> > > > > to UNKNOWN, so drivers can call this function to init the property earlier
> > > > > , and let the panel set the real value later.
> > > > >
> > > >
> > > > The warning illustrates a genuine race condition, where userspace will
> > > > read the old/invalid property value/state. So this patch masks away
> > > > the WARNING without addressing the actual issue.
> > > > Instead can we fix the respective drivers, so that no properties are
> > > > created after drm_dev_register()?
> > > >
> > > > Longer version:
> > > > As we look into drm_dev_register() it's in charge of creating the
> > > > dev/sysfs nodes (et al). Note that connectors cannot disappear at
> > > > runtime.
> > > > For panel orientation, we are creating an immutable connector
> > > > properly, meaning that as soon as drm_dev_register() is called we must
> > > > ensure that the property is available (if applicable) and set to the
> > > > correct value.
> > >
> > > Unfortunately we can't quite do this. To apply the panel orientation quirks we
> > > need to grab the EDID of the eDP connector, and this happened too late in my
> > > testing.
> > >
> > > What we can do is create the prop early during module load, and update it when
> > > we read the EDID (at the place where we create it right now). User-space will
> > > receive a hotplug event after the EDID is read, so will be able to pick up the
> > > new value if any.
> >
> > Didn't quite get that, are you saying that a GETPROPERTY for the EDID,
> > the ioctl blocks or that we get an empty EDID?
>
> I'm not referring to GETPROPERTY, I'm referring to the driver getting the EDID
> from the sink (here, the eDP panel). In my experimentations with amdgpu I
> noticed that the driver module load finished before the EDID was available to
> the driver. Maybe other drivers behave differently and probe connectors when
> loaded, not sure.
>
I see thanks.

> > The EDID hotplug even thing is neat - sounds like it also signals on
> > panel orientation, correct?
> > On such an event, which properties userspace should be re-fetching -
> > everything or guess randomly?
> >
> > Looking through the documentation, I cannot see a clear answer :-\
>
> User-space should re-fetch *all* properties. In practice some user-space may
> only be fetching some properties, but that should get fixed in user-space.
>
> Also the kernel can indicate that only a single connector changed via the
> "CONNECTOR" uevent prop, or even a single connector property via "PROPERTY".
> See [1] for a user-space implementation. But all of this is purely an optional
> optimization. Re-fetching all properties is a bit slower (especially if some
> drmModeGetConnector calls force-probe connectors) but works perfectly fine.
>
Looking at KDE/kwin (the one I'm running) - doesn't seem like it
handles any of the three "HOTPLUG", "PROPERTY" or "CONNECTOR" uevents
:-\
Skimming through GNOME/mutter - it handles "HOTPLUG", but not the optional ones.

Guess we're in the clear wrt potential races, even though the
documentation on the topic is lacklustre.

> It would be nice to document, if you have the time feel free to send a patch
> and CC danvet, pq and me.
>

Doubt I will have the time in the upcoming weeks, but I'll add it to
my ever-growing TODO list :-P

Thanks
Emil

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

Re: [Intel-gfx] [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Emil Velikov]

On Tue, 15 Feb 2022 at 16:37, Simon Ser <contact@emersion.fr> wrote:
>
> On Tuesday, February 15th, 2022 at 15:38, Emil Velikov <emil.l.velikov@gmail.com> wrote:
>
> > On Tue, 15 Feb 2022 at 13:55, Simon Ser <contact@emersion.fr> wrote:
> > >
> > > On Tuesday, February 15th, 2022 at 13:04, Emil Velikov <emil.l.velikov@gmail.com> wrote:
> > >
> > > > Greetings everyone,
> > > >
> > > > Padron for joining in so late o/
> > > >
> > > > On Tue, 8 Feb 2022 at 08:42, Hsin-Yi Wang <hsinyi@chromium.org> wrote:
> > > > >
> > > > > drm_dev_register() sets connector->registration_state to
> > > > > DRM_CONNECTOR_REGISTERED and dev->registered to true. If
> > > > > drm_connector_set_panel_orientation() is first called after
> > > > > drm_dev_register(), it will fail several checks and results in following
> > > > > warning.
> > > > >
> > > > > Add a function to create panel orientation property and set default value
> > > > > to UNKNOWN, so drivers can call this function to init the property earlier
> > > > > , and let the panel set the real value later.
> > > > >
> > > >
> > > > The warning illustrates a genuine race condition, where userspace will
> > > > read the old/invalid property value/state. So this patch masks away
> > > > the WARNING without addressing the actual issue.
> > > > Instead can we fix the respective drivers, so that no properties are
> > > > created after drm_dev_register()?
> > > >
> > > > Longer version:
> > > > As we look into drm_dev_register() it's in charge of creating the
> > > > dev/sysfs nodes (et al). Note that connectors cannot disappear at
> > > > runtime.
> > > > For panel orientation, we are creating an immutable connector
> > > > properly, meaning that as soon as drm_dev_register() is called we must
> > > > ensure that the property is available (if applicable) and set to the
> > > > correct value.
> > >
> > > Unfortunately we can't quite do this. To apply the panel orientation quirks we
> > > need to grab the EDID of the eDP connector, and this happened too late in my
> > > testing.
> > >
> > > What we can do is create the prop early during module load, and update it when
> > > we read the EDID (at the place where we create it right now). User-space will
> > > receive a hotplug event after the EDID is read, so will be able to pick up the
> > > new value if any.
> >
> > Didn't quite get that, are you saying that a GETPROPERTY for the EDID,
> > the ioctl blocks or that we get an empty EDID?
>
> I'm not referring to GETPROPERTY, I'm referring to the driver getting the EDID
> from the sink (here, the eDP panel). In my experimentations with amdgpu I
> noticed that the driver module load finished before the EDID was available to
> the driver. Maybe other drivers behave differently and probe connectors when
> loaded, not sure.
>
I see thanks.

> > The EDID hotplug even thing is neat - sounds like it also signals on
> > panel orientation, correct?
> > On such an event, which properties userspace should be re-fetching -
> > everything or guess randomly?
> >
> > Looking through the documentation, I cannot see a clear answer :-\
>
> User-space should re-fetch *all* properties. In practice some user-space may
> only be fetching some properties, but that should get fixed in user-space.
>
> Also the kernel can indicate that only a single connector changed via the
> "CONNECTOR" uevent prop, or even a single connector property via "PROPERTY".
> See [1] for a user-space implementation. But all of this is purely an optional
> optimization. Re-fetching all properties is a bit slower (especially if some
> drmModeGetConnector calls force-probe connectors) but works perfectly fine.
>
Looking at KDE/kwin (the one I'm running) - doesn't seem like it
handles any of the three "HOTPLUG", "PROPERTY" or "CONNECTOR" uevents
:-\
Skimming through GNOME/mutter - it handles "HOTPLUG", but not the optional ones.

Guess we're in the clear wrt potential races, even though the
documentation on the topic is lacklustre.

> It would be nice to document, if you have the time feel free to send a patch
> and CC danvet, pq and me.
>

Doubt I will have the time in the upcoming weeks, but I'll add it to
my ever-growing TODO list :-P

Thanks
Emil

Re: [Intel-gfx] [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Emil Velikov]

On Tue, 15 Feb 2022 at 16:37, Simon Ser <contact@emersion.fr> wrote:
>
> On Tuesday, February 15th, 2022 at 15:38, Emil Velikov <emil.l.velikov@gmail.com> wrote:
>
> > On Tue, 15 Feb 2022 at 13:55, Simon Ser <contact@emersion.fr> wrote:
> > >
> > > On Tuesday, February 15th, 2022 at 13:04, Emil Velikov <emil.l.velikov@gmail.com> wrote:
> > >
> > > > Greetings everyone,
> > > >
> > > > Padron for joining in so late o/
> > > >
> > > > On Tue, 8 Feb 2022 at 08:42, Hsin-Yi Wang <hsinyi@chromium.org> wrote:
> > > > >
> > > > > drm_dev_register() sets connector->registration_state to
> > > > > DRM_CONNECTOR_REGISTERED and dev->registered to true. If
> > > > > drm_connector_set_panel_orientation() is first called after
> > > > > drm_dev_register(), it will fail several checks and results in following
> > > > > warning.
> > > > >
> > > > > Add a function to create panel orientation property and set default value
> > > > > to UNKNOWN, so drivers can call this function to init the property earlier
> > > > > , and let the panel set the real value later.
> > > > >
> > > >
> > > > The warning illustrates a genuine race condition, where userspace will
> > > > read the old/invalid property value/state. So this patch masks away
> > > > the WARNING without addressing the actual issue.
> > > > Instead can we fix the respective drivers, so that no properties are
> > > > created after drm_dev_register()?
> > > >
> > > > Longer version:
> > > > As we look into drm_dev_register() it's in charge of creating the
> > > > dev/sysfs nodes (et al). Note that connectors cannot disappear at
> > > > runtime.
> > > > For panel orientation, we are creating an immutable connector
> > > > properly, meaning that as soon as drm_dev_register() is called we must
> > > > ensure that the property is available (if applicable) and set to the
> > > > correct value.
> > >
> > > Unfortunately we can't quite do this. To apply the panel orientation quirks we
> > > need to grab the EDID of the eDP connector, and this happened too late in my
> > > testing.
> > >
> > > What we can do is create the prop early during module load, and update it when
> > > we read the EDID (at the place where we create it right now). User-space will
> > > receive a hotplug event after the EDID is read, so will be able to pick up the
> > > new value if any.
> >
> > Didn't quite get that, are you saying that a GETPROPERTY for the EDID,
> > the ioctl blocks or that we get an empty EDID?
>
> I'm not referring to GETPROPERTY, I'm referring to the driver getting the EDID
> from the sink (here, the eDP panel). In my experimentations with amdgpu I
> noticed that the driver module load finished before the EDID was available to
> the driver. Maybe other drivers behave differently and probe connectors when
> loaded, not sure.
>
I see thanks.

> > The EDID hotplug even thing is neat - sounds like it also signals on
> > panel orientation, correct?
> > On such an event, which properties userspace should be re-fetching -
> > everything or guess randomly?
> >
> > Looking through the documentation, I cannot see a clear answer :-\
>
> User-space should re-fetch *all* properties. In practice some user-space may
> only be fetching some properties, but that should get fixed in user-space.
>
> Also the kernel can indicate that only a single connector changed via the
> "CONNECTOR" uevent prop, or even a single connector property via "PROPERTY".
> See [1] for a user-space implementation. But all of this is purely an optional
> optimization. Re-fetching all properties is a bit slower (especially if some
> drmModeGetConnector calls force-probe connectors) but works perfectly fine.
>
Looking at KDE/kwin (the one I'm running) - doesn't seem like it
handles any of the three "HOTPLUG", "PROPERTY" or "CONNECTOR" uevents
:-\
Skimming through GNOME/mutter - it handles "HOTPLUG", but not the optional ones.

Guess we're in the clear wrt potential races, even though the
documentation on the topic is lacklustre.

> It would be nice to document, if you have the time feel free to send a patch
> and CC danvet, pq and me.
>

Doubt I will have the time in the upcoming weeks, but I'll add it to
my ever-growing TODO list :-P

Thanks
Emil

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [Intel-gfx] [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Hans de Goede]

Hi,

Sorry for jumping in in the middle of the thread I did
not notice this thread before.

On 2/16/22 13:00, Emil Velikov wrote:
> On Tue, 15 Feb 2022 at 16:37, Simon Ser <contact@emersion.fr> wrote:
>>
>> On Tuesday, February 15th, 2022 at 15:38, Emil Velikov <emil.l.velikov@gmail.com> wrote:
>>
>>> On Tue, 15 Feb 2022 at 13:55, Simon Ser <contact@emersion.fr> wrote:
>>>>
>>>> On Tuesday, February 15th, 2022 at 13:04, Emil Velikov <emil.l.velikov@gmail.com> wrote:
>>>>
>>>>> Greetings everyone,
>>>>>
>>>>> Padron for joining in so late o/
>>>>>
>>>>> On Tue, 8 Feb 2022 at 08:42, Hsin-Yi Wang <hsinyi@chromium.org> wrote:
>>>>>>
>>>>>> drm_dev_register() sets connector->registration_state to
>>>>>> DRM_CONNECTOR_REGISTERED and dev->registered to true. If
>>>>>> drm_connector_set_panel_orientation() is first called after
>>>>>> drm_dev_register(), it will fail several checks and results in following
>>>>>> warning.
>>>>>>
>>>>>> Add a function to create panel orientation property and set default value
>>>>>> to UNKNOWN, so drivers can call this function to init the property earlier
>>>>>> , and let the panel set the real value later.
>>>>>>
>>>>>
>>>>> The warning illustrates a genuine race condition, where userspace will
>>>>> read the old/invalid property value/state. So this patch masks away
>>>>> the WARNING without addressing the actual issue.
>>>>> Instead can we fix the respective drivers, so that no properties are
>>>>> created after drm_dev_register()?
>>>>>
>>>>> Longer version:
>>>>> As we look into drm_dev_register() it's in charge of creating the
>>>>> dev/sysfs nodes (et al). Note that connectors cannot disappear at
>>>>> runtime.
>>>>> For panel orientation, we are creating an immutable connector
>>>>> properly, meaning that as soon as drm_dev_register() is called we must
>>>>> ensure that the property is available (if applicable) and set to the
>>>>> correct value.
>>>>
>>>> Unfortunately we can't quite do this. To apply the panel orientation quirks we
>>>> need to grab the EDID of the eDP connector, and this happened too late in my
>>>> testing.
>>>>
>>>> What we can do is create the prop early during module load, and update it when
>>>> we read the EDID (at the place where we create it right now). User-space will
>>>> receive a hotplug event after the EDID is read, so will be able to pick up the
>>>> new value if any.
>>>
>>> Didn't quite get that, are you saying that a GETPROPERTY for the EDID,
>>> the ioctl blocks or that we get an empty EDID?
>>
>> I'm not referring to GETPROPERTY, I'm referring to the driver getting the EDID
>> from the sink (here, the eDP panel). In my experimentations with amdgpu I
>> noticed that the driver module load finished before the EDID was available to
>> the driver. Maybe other drivers behave differently and probe connectors when
>> loaded, not sure.
>>
> I see thanks.
> 
>>> The EDID hotplug even thing is neat - sounds like it also signals on
>>> panel orientation, correct?
>>> On such an event, which properties userspace should be re-fetching -
>>> everything or guess randomly?
>>>
>>> Looking through the documentation, I cannot see a clear answer :-\
>>
>> User-space should re-fetch *all* properties. In practice some user-space may
>> only be fetching some properties, but that should get fixed in user-space.
>>
>> Also the kernel can indicate that only a single connector changed via the
>> "CONNECTOR" uevent prop, or even a single connector property via "PROPERTY".
>> See [1] for a user-space implementation. But all of this is purely an optional
>> optimization. Re-fetching all properties is a bit slower (especially if some
>> drmModeGetConnector calls force-probe connectors) but works perfectly fine

What I'm reading in the above is that it is being considered to allow
changing the panel-orientation value after the connector has been made
available to userspace; and let userspace know about this through a uevent.

I believe that this is a bad idea, it is important to keep in mind here
what userspace (e.g. plymouth) uses this prorty for. This property is
used to rotate the image being rendered / shown on the framebuffer to
adjust for the panel orientation.

So now lets assume we apply the correct upside-down orientation later
on a device with an upside-down mounted LCD panel. Then on boot the
following could happen:

1. amdgpu exports a connector for the LCD panel to userspace without
setting panel-orient=upside-down
2. plymouth sees this and renders its splash normally, but since the
panel is upside-down it will now actually show upside-down
3. amdgpu adjusts the panel-orient prop to upside-down, sends out
uevents
4. Lets assume plymouth handles this well (i) and now adjust its
rendering and renders the next frame of the bootsplash 180° rotated
to compensate for the panel being upside down. Then from now on
the user will see the splash normally

So this means that the user will briefly see the bootsplash rendered
upside down which IMHO is not acceptable behavior. Also see my footnote
about how I seriously doubt plymouth will see the panel-orient change
at all.

I'm also a bit unsure about:

a) How you can register the panel connector with userspace before
reading the edid, don't you need the edid to give the physical size +
modeline to userspace, which you cannot just leave out ?

I guess the initial modeline is inherited from the video-bios, but
what about the physical size? Note that you cannot just change the
physical size later either, that gets used to determine the hidpi
scaling factor in the bootsplash, and changing that after the initial
bootsplash dislay will also look ugly

b) Why you need the edid for the panel-orientation property at all,
typically the edid prom is part of the panel and the panel does not
know that it is mounted e.g. upside down at all, that is a property
of the system as a whole not of the panel as a standalone unit so
in my experience getting panel-orient info is something which comes
from the firmware /video-bios not from edid ?

Regards,

Hans



i) I don't think plymouth will handle this well though, since it tries to
skip unchanged connectors and I believe it only checks the crtc routing +
preferred modeline to determine "unchanged".

Re: [Intel-gfx] [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Hans de Goede]

Hi,

Sorry for jumping in in the middle of the thread I did
not notice this thread before.

On 2/16/22 13:00, Emil Velikov wrote:
> On Tue, 15 Feb 2022 at 16:37, Simon Ser <contact@emersion.fr> wrote:
>>
>> On Tuesday, February 15th, 2022 at 15:38, Emil Velikov <emil.l.velikov@gmail.com> wrote:
>>
>>> On Tue, 15 Feb 2022 at 13:55, Simon Ser <contact@emersion.fr> wrote:
>>>>
>>>> On Tuesday, February 15th, 2022 at 13:04, Emil Velikov <emil.l.velikov@gmail.com> wrote:
>>>>
>>>>> Greetings everyone,
>>>>>
>>>>> Padron for joining in so late o/
>>>>>
>>>>> On Tue, 8 Feb 2022 at 08:42, Hsin-Yi Wang <hsinyi@chromium.org> wrote:
>>>>>>
>>>>>> drm_dev_register() sets connector->registration_state to
>>>>>> DRM_CONNECTOR_REGISTERED and dev->registered to true. If
>>>>>> drm_connector_set_panel_orientation() is first called after
>>>>>> drm_dev_register(), it will fail several checks and results in following
>>>>>> warning.
>>>>>>
>>>>>> Add a function to create panel orientation property and set default value
>>>>>> to UNKNOWN, so drivers can call this function to init the property earlier
>>>>>> , and let the panel set the real value later.
>>>>>>
>>>>>
>>>>> The warning illustrates a genuine race condition, where userspace will
>>>>> read the old/invalid property value/state. So this patch masks away
>>>>> the WARNING without addressing the actual issue.
>>>>> Instead can we fix the respective drivers, so that no properties are
>>>>> created after drm_dev_register()?
>>>>>
>>>>> Longer version:
>>>>> As we look into drm_dev_register() it's in charge of creating the
>>>>> dev/sysfs nodes (et al). Note that connectors cannot disappear at
>>>>> runtime.
>>>>> For panel orientation, we are creating an immutable connector
>>>>> properly, meaning that as soon as drm_dev_register() is called we must
>>>>> ensure that the property is available (if applicable) and set to the
>>>>> correct value.
>>>>
>>>> Unfortunately we can't quite do this. To apply the panel orientation quirks we
>>>> need to grab the EDID of the eDP connector, and this happened too late in my
>>>> testing.
>>>>
>>>> What we can do is create the prop early during module load, and update it when
>>>> we read the EDID (at the place where we create it right now). User-space will
>>>> receive a hotplug event after the EDID is read, so will be able to pick up the
>>>> new value if any.
>>>
>>> Didn't quite get that, are you saying that a GETPROPERTY for the EDID,
>>> the ioctl blocks or that we get an empty EDID?
>>
>> I'm not referring to GETPROPERTY, I'm referring to the driver getting the EDID
>> from the sink (here, the eDP panel). In my experimentations with amdgpu I
>> noticed that the driver module load finished before the EDID was available to
>> the driver. Maybe other drivers behave differently and probe connectors when
>> loaded, not sure.
>>
> I see thanks.
> 
>>> The EDID hotplug even thing is neat - sounds like it also signals on
>>> panel orientation, correct?
>>> On such an event, which properties userspace should be re-fetching -
>>> everything or guess randomly?
>>>
>>> Looking through the documentation, I cannot see a clear answer :-\
>>
>> User-space should re-fetch *all* properties. In practice some user-space may
>> only be fetching some properties, but that should get fixed in user-space.
>>
>> Also the kernel can indicate that only a single connector changed via the
>> "CONNECTOR" uevent prop, or even a single connector property via "PROPERTY".
>> See [1] for a user-space implementation. But all of this is purely an optional
>> optimization. Re-fetching all properties is a bit slower (especially if some
>> drmModeGetConnector calls force-probe connectors) but works perfectly fine

What I'm reading in the above is that it is being considered to allow
changing the panel-orientation value after the connector has been made
available to userspace; and let userspace know about this through a uevent.

I believe that this is a bad idea, it is important to keep in mind here
what userspace (e.g. plymouth) uses this prorty for. This property is
used to rotate the image being rendered / shown on the framebuffer to
adjust for the panel orientation.

So now lets assume we apply the correct upside-down orientation later
on a device with an upside-down mounted LCD panel. Then on boot the
following could happen:

1. amdgpu exports a connector for the LCD panel to userspace without
setting panel-orient=upside-down
2. plymouth sees this and renders its splash normally, but since the
panel is upside-down it will now actually show upside-down
3. amdgpu adjusts the panel-orient prop to upside-down, sends out
uevents
4. Lets assume plymouth handles this well (i) and now adjust its
rendering and renders the next frame of the bootsplash 180° rotated
to compensate for the panel being upside down. Then from now on
the user will see the splash normally

So this means that the user will briefly see the bootsplash rendered
upside down which IMHO is not acceptable behavior. Also see my footnote
about how I seriously doubt plymouth will see the panel-orient change
at all.

I'm also a bit unsure about:

a) How you can register the panel connector with userspace before
reading the edid, don't you need the edid to give the physical size +
modeline to userspace, which you cannot just leave out ?

I guess the initial modeline is inherited from the video-bios, but
what about the physical size? Note that you cannot just change the
physical size later either, that gets used to determine the hidpi
scaling factor in the bootsplash, and changing that after the initial
bootsplash dislay will also look ugly

b) Why you need the edid for the panel-orientation property at all,
typically the edid prom is part of the panel and the panel does not
know that it is mounted e.g. upside down at all, that is a property
of the system as a whole not of the panel as a standalone unit so
in my experience getting panel-orient info is something which comes
from the firmware /video-bios not from edid ?

Regards,

Hans



i) I don't think plymouth will handle this well though, since it tries to
skip unchanged connectors and I believe it only checks the crtc routing +
preferred modeline to determine "unchanged".

Re: [Intel-gfx] [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Hans de Goede]

Hi,

Sorry for jumping in in the middle of the thread I did
not notice this thread before.

On 2/16/22 13:00, Emil Velikov wrote:
> On Tue, 15 Feb 2022 at 16:37, Simon Ser <contact@emersion.fr> wrote:
>>
>> On Tuesday, February 15th, 2022 at 15:38, Emil Velikov <emil.l.velikov@gmail.com> wrote:
>>
>>> On Tue, 15 Feb 2022 at 13:55, Simon Ser <contact@emersion.fr> wrote:
>>>>
>>>> On Tuesday, February 15th, 2022 at 13:04, Emil Velikov <emil.l.velikov@gmail.com> wrote:
>>>>
>>>>> Greetings everyone,
>>>>>
>>>>> Padron for joining in so late o/
>>>>>
>>>>> On Tue, 8 Feb 2022 at 08:42, Hsin-Yi Wang <hsinyi@chromium.org> wrote:
>>>>>>
>>>>>> drm_dev_register() sets connector->registration_state to
>>>>>> DRM_CONNECTOR_REGISTERED and dev->registered to true. If
>>>>>> drm_connector_set_panel_orientation() is first called after
>>>>>> drm_dev_register(), it will fail several checks and results in following
>>>>>> warning.
>>>>>>
>>>>>> Add a function to create panel orientation property and set default value
>>>>>> to UNKNOWN, so drivers can call this function to init the property earlier
>>>>>> , and let the panel set the real value later.
>>>>>>
>>>>>
>>>>> The warning illustrates a genuine race condition, where userspace will
>>>>> read the old/invalid property value/state. So this patch masks away
>>>>> the WARNING without addressing the actual issue.
>>>>> Instead can we fix the respective drivers, so that no properties are
>>>>> created after drm_dev_register()?
>>>>>
>>>>> Longer version:
>>>>> As we look into drm_dev_register() it's in charge of creating the
>>>>> dev/sysfs nodes (et al). Note that connectors cannot disappear at
>>>>> runtime.
>>>>> For panel orientation, we are creating an immutable connector
>>>>> properly, meaning that as soon as drm_dev_register() is called we must
>>>>> ensure that the property is available (if applicable) and set to the
>>>>> correct value.
>>>>
>>>> Unfortunately we can't quite do this. To apply the panel orientation quirks we
>>>> need to grab the EDID of the eDP connector, and this happened too late in my
>>>> testing.
>>>>
>>>> What we can do is create the prop early during module load, and update it when
>>>> we read the EDID (at the place where we create it right now). User-space will
>>>> receive a hotplug event after the EDID is read, so will be able to pick up the
>>>> new value if any.
>>>
>>> Didn't quite get that, are you saying that a GETPROPERTY for the EDID,
>>> the ioctl blocks or that we get an empty EDID?
>>
>> I'm not referring to GETPROPERTY, I'm referring to the driver getting the EDID
>> from the sink (here, the eDP panel). In my experimentations with amdgpu I
>> noticed that the driver module load finished before the EDID was available to
>> the driver. Maybe other drivers behave differently and probe connectors when
>> loaded, not sure.
>>
> I see thanks.
> 
>>> The EDID hotplug even thing is neat - sounds like it also signals on
>>> panel orientation, correct?
>>> On such an event, which properties userspace should be re-fetching -
>>> everything or guess randomly?
>>>
>>> Looking through the documentation, I cannot see a clear answer :-\
>>
>> User-space should re-fetch *all* properties. In practice some user-space may
>> only be fetching some properties, but that should get fixed in user-space.
>>
>> Also the kernel can indicate that only a single connector changed via the
>> "CONNECTOR" uevent prop, or even a single connector property via "PROPERTY".
>> See [1] for a user-space implementation. But all of this is purely an optional
>> optimization. Re-fetching all properties is a bit slower (especially if some
>> drmModeGetConnector calls force-probe connectors) but works perfectly fine

What I'm reading in the above is that it is being considered to allow
changing the panel-orientation value after the connector has been made
available to userspace; and let userspace know about this through a uevent.

I believe that this is a bad idea, it is important to keep in mind here
what userspace (e.g. plymouth) uses this prorty for. This property is
used to rotate the image being rendered / shown on the framebuffer to
adjust for the panel orientation.

So now lets assume we apply the correct upside-down orientation later
on a device with an upside-down mounted LCD panel. Then on boot the
following could happen:

1. amdgpu exports a connector for the LCD panel to userspace without
setting panel-orient=upside-down
2. plymouth sees this and renders its splash normally, but since the
panel is upside-down it will now actually show upside-down
3. amdgpu adjusts the panel-orient prop to upside-down, sends out
uevents
4. Lets assume plymouth handles this well (i) and now adjust its
rendering and renders the next frame of the bootsplash 180° rotated
to compensate for the panel being upside down. Then from now on
the user will see the splash normally

So this means that the user will briefly see the bootsplash rendered
upside down which IMHO is not acceptable behavior. Also see my footnote
about how I seriously doubt plymouth will see the panel-orient change
at all.

I'm also a bit unsure about:

a) How you can register the panel connector with userspace before
reading the edid, don't you need the edid to give the physical size +
modeline to userspace, which you cannot just leave out ?

I guess the initial modeline is inherited from the video-bios, but
what about the physical size? Note that you cannot just change the
physical size later either, that gets used to determine the hidpi
scaling factor in the bootsplash, and changing that after the initial
bootsplash dislay will also look ugly

b) Why you need the edid for the panel-orientation property at all,
typically the edid prom is part of the panel and the panel does not
know that it is mounted e.g. upside down at all, that is a property
of the system as a whole not of the panel as a standalone unit so
in my experience getting panel-orient info is something which comes
from the firmware /video-bios not from edid ?

Regards,

Hans



i) I don't think plymouth will handle this well though, since it tries to
skip unchanged connectors and I believe it only checks the crtc routing +
preferred modeline to determine "unchanged".

Re: [Intel-gfx] [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Hans de Goede]

Hi,

Sorry for jumping in in the middle of the thread I did
not notice this thread before.

On 2/16/22 13:00, Emil Velikov wrote:
> On Tue, 15 Feb 2022 at 16:37, Simon Ser <contact@emersion.fr> wrote:
>>
>> On Tuesday, February 15th, 2022 at 15:38, Emil Velikov <emil.l.velikov@gmail.com> wrote:
>>
>>> On Tue, 15 Feb 2022 at 13:55, Simon Ser <contact@emersion.fr> wrote:
>>>>
>>>> On Tuesday, February 15th, 2022 at 13:04, Emil Velikov <emil.l.velikov@gmail.com> wrote:
>>>>
>>>>> Greetings everyone,
>>>>>
>>>>> Padron for joining in so late o/
>>>>>
>>>>> On Tue, 8 Feb 2022 at 08:42, Hsin-Yi Wang <hsinyi@chromium.org> wrote:
>>>>>>
>>>>>> drm_dev_register() sets connector->registration_state to
>>>>>> DRM_CONNECTOR_REGISTERED and dev->registered to true. If
>>>>>> drm_connector_set_panel_orientation() is first called after
>>>>>> drm_dev_register(), it will fail several checks and results in following
>>>>>> warning.
>>>>>>
>>>>>> Add a function to create panel orientation property and set default value
>>>>>> to UNKNOWN, so drivers can call this function to init the property earlier
>>>>>> , and let the panel set the real value later.
>>>>>>
>>>>>
>>>>> The warning illustrates a genuine race condition, where userspace will
>>>>> read the old/invalid property value/state. So this patch masks away
>>>>> the WARNING without addressing the actual issue.
>>>>> Instead can we fix the respective drivers, so that no properties are
>>>>> created after drm_dev_register()?
>>>>>
>>>>> Longer version:
>>>>> As we look into drm_dev_register() it's in charge of creating the
>>>>> dev/sysfs nodes (et al). Note that connectors cannot disappear at
>>>>> runtime.
>>>>> For panel orientation, we are creating an immutable connector
>>>>> properly, meaning that as soon as drm_dev_register() is called we must
>>>>> ensure that the property is available (if applicable) and set to the
>>>>> correct value.
>>>>
>>>> Unfortunately we can't quite do this. To apply the panel orientation quirks we
>>>> need to grab the EDID of the eDP connector, and this happened too late in my
>>>> testing.
>>>>
>>>> What we can do is create the prop early during module load, and update it when
>>>> we read the EDID (at the place where we create it right now). User-space will
>>>> receive a hotplug event after the EDID is read, so will be able to pick up the
>>>> new value if any.
>>>
>>> Didn't quite get that, are you saying that a GETPROPERTY for the EDID,
>>> the ioctl blocks or that we get an empty EDID?
>>
>> I'm not referring to GETPROPERTY, I'm referring to the driver getting the EDID
>> from the sink (here, the eDP panel). In my experimentations with amdgpu I
>> noticed that the driver module load finished before the EDID was available to
>> the driver. Maybe other drivers behave differently and probe connectors when
>> loaded, not sure.
>>
> I see thanks.
> 
>>> The EDID hotplug even thing is neat - sounds like it also signals on
>>> panel orientation, correct?
>>> On such an event, which properties userspace should be re-fetching -
>>> everything or guess randomly?
>>>
>>> Looking through the documentation, I cannot see a clear answer :-\
>>
>> User-space should re-fetch *all* properties. In practice some user-space may
>> only be fetching some properties, but that should get fixed in user-space.
>>
>> Also the kernel can indicate that only a single connector changed via the
>> "CONNECTOR" uevent prop, or even a single connector property via "PROPERTY".
>> See [1] for a user-space implementation. But all of this is purely an optional
>> optimization. Re-fetching all properties is a bit slower (especially if some
>> drmModeGetConnector calls force-probe connectors) but works perfectly fine

What I'm reading in the above is that it is being considered to allow
changing the panel-orientation value after the connector has been made
available to userspace; and let userspace know about this through a uevent.

I believe that this is a bad idea, it is important to keep in mind here
what userspace (e.g. plymouth) uses this prorty for. This property is
used to rotate the image being rendered / shown on the framebuffer to
adjust for the panel orientation.

So now lets assume we apply the correct upside-down orientation later
on a device with an upside-down mounted LCD panel. Then on boot the
following could happen:

1. amdgpu exports a connector for the LCD panel to userspace without
setting panel-orient=upside-down
2. plymouth sees this and renders its splash normally, but since the
panel is upside-down it will now actually show upside-down
3. amdgpu adjusts the panel-orient prop to upside-down, sends out
uevents
4. Lets assume plymouth handles this well (i) and now adjust its
rendering and renders the next frame of the bootsplash 180° rotated
to compensate for the panel being upside down. Then from now on
the user will see the splash normally

So this means that the user will briefly see the bootsplash rendered
upside down which IMHO is not acceptable behavior. Also see my footnote
about how I seriously doubt plymouth will see the panel-orient change
at all.

I'm also a bit unsure about:

a) How you can register the panel connector with userspace before
reading the edid, don't you need the edid to give the physical size +
modeline to userspace, which you cannot just leave out ?

I guess the initial modeline is inherited from the video-bios, but
what about the physical size? Note that you cannot just change the
physical size later either, that gets used to determine the hidpi
scaling factor in the bootsplash, and changing that after the initial
bootsplash dislay will also look ugly

b) Why you need the edid for the panel-orientation property at all,
typically the edid prom is part of the panel and the panel does not
know that it is mounted e.g. upside down at all, that is a property
of the system as a whole not of the panel as a standalone unit so
in my experience getting panel-orient info is something which comes
from the firmware /video-bios not from edid ?

Regards,

Hans



i) I don't think plymouth will handle this well though, since it tries to
skip unchanged connectors and I believe it only checks the crtc routing +
preferred modeline to determine "unchanged".


_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

Re: [Intel-gfx] [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Hans de Goede]

Hi,

Sorry for jumping in in the middle of the thread I did
not notice this thread before.

On 2/16/22 13:00, Emil Velikov wrote:
> On Tue, 15 Feb 2022 at 16:37, Simon Ser <contact@emersion.fr> wrote:
>>
>> On Tuesday, February 15th, 2022 at 15:38, Emil Velikov <emil.l.velikov@gmail.com> wrote:
>>
>>> On Tue, 15 Feb 2022 at 13:55, Simon Ser <contact@emersion.fr> wrote:
>>>>
>>>> On Tuesday, February 15th, 2022 at 13:04, Emil Velikov <emil.l.velikov@gmail.com> wrote:
>>>>
>>>>> Greetings everyone,
>>>>>
>>>>> Padron for joining in so late o/
>>>>>
>>>>> On Tue, 8 Feb 2022 at 08:42, Hsin-Yi Wang <hsinyi@chromium.org> wrote:
>>>>>>
>>>>>> drm_dev_register() sets connector->registration_state to
>>>>>> DRM_CONNECTOR_REGISTERED and dev->registered to true. If
>>>>>> drm_connector_set_panel_orientation() is first called after
>>>>>> drm_dev_register(), it will fail several checks and results in following
>>>>>> warning.
>>>>>>
>>>>>> Add a function to create panel orientation property and set default value
>>>>>> to UNKNOWN, so drivers can call this function to init the property earlier
>>>>>> , and let the panel set the real value later.
>>>>>>
>>>>>
>>>>> The warning illustrates a genuine race condition, where userspace will
>>>>> read the old/invalid property value/state. So this patch masks away
>>>>> the WARNING without addressing the actual issue.
>>>>> Instead can we fix the respective drivers, so that no properties are
>>>>> created after drm_dev_register()?
>>>>>
>>>>> Longer version:
>>>>> As we look into drm_dev_register() it's in charge of creating the
>>>>> dev/sysfs nodes (et al). Note that connectors cannot disappear at
>>>>> runtime.
>>>>> For panel orientation, we are creating an immutable connector
>>>>> properly, meaning that as soon as drm_dev_register() is called we must
>>>>> ensure that the property is available (if applicable) and set to the
>>>>> correct value.
>>>>
>>>> Unfortunately we can't quite do this. To apply the panel orientation quirks we
>>>> need to grab the EDID of the eDP connector, and this happened too late in my
>>>> testing.
>>>>
>>>> What we can do is create the prop early during module load, and update it when
>>>> we read the EDID (at the place where we create it right now). User-space will
>>>> receive a hotplug event after the EDID is read, so will be able to pick up the
>>>> new value if any.
>>>
>>> Didn't quite get that, are you saying that a GETPROPERTY for the EDID,
>>> the ioctl blocks or that we get an empty EDID?
>>
>> I'm not referring to GETPROPERTY, I'm referring to the driver getting the EDID
>> from the sink (here, the eDP panel). In my experimentations with amdgpu I
>> noticed that the driver module load finished before the EDID was available to
>> the driver. Maybe other drivers behave differently and probe connectors when
>> loaded, not sure.
>>
> I see thanks.
> 
>>> The EDID hotplug even thing is neat - sounds like it also signals on
>>> panel orientation, correct?
>>> On such an event, which properties userspace should be re-fetching -
>>> everything or guess randomly?
>>>
>>> Looking through the documentation, I cannot see a clear answer :-\
>>
>> User-space should re-fetch *all* properties. In practice some user-space may
>> only be fetching some properties, but that should get fixed in user-space.
>>
>> Also the kernel can indicate that only a single connector changed via the
>> "CONNECTOR" uevent prop, or even a single connector property via "PROPERTY".
>> See [1] for a user-space implementation. But all of this is purely an optional
>> optimization. Re-fetching all properties is a bit slower (especially if some
>> drmModeGetConnector calls force-probe connectors) but works perfectly fine

What I'm reading in the above is that it is being considered to allow
changing the panel-orientation value after the connector has been made
available to userspace; and let userspace know about this through a uevent.

I believe that this is a bad idea, it is important to keep in mind here
what userspace (e.g. plymouth) uses this prorty for. This property is
used to rotate the image being rendered / shown on the framebuffer to
adjust for the panel orientation.

So now lets assume we apply the correct upside-down orientation later
on a device with an upside-down mounted LCD panel. Then on boot the
following could happen:

1. amdgpu exports a connector for the LCD panel to userspace without
setting panel-orient=upside-down
2. plymouth sees this and renders its splash normally, but since the
panel is upside-down it will now actually show upside-down
3. amdgpu adjusts the panel-orient prop to upside-down, sends out
uevents
4. Lets assume plymouth handles this well (i) and now adjust its
rendering and renders the next frame of the bootsplash 180° rotated
to compensate for the panel being upside down. Then from now on
the user will see the splash normally

So this means that the user will briefly see the bootsplash rendered
upside down which IMHO is not acceptable behavior. Also see my footnote
about how I seriously doubt plymouth will see the panel-orient change
at all.

I'm also a bit unsure about:

a) How you can register the panel connector with userspace before
reading the edid, don't you need the edid to give the physical size +
modeline to userspace, which you cannot just leave out ?

I guess the initial modeline is inherited from the video-bios, but
what about the physical size? Note that you cannot just change the
physical size later either, that gets used to determine the hidpi
scaling factor in the bootsplash, and changing that after the initial
bootsplash dislay will also look ugly

b) Why you need the edid for the panel-orientation property at all,
typically the edid prom is part of the panel and the panel does not
know that it is mounted e.g. upside down at all, that is a property
of the system as a whole not of the panel as a standalone unit so
in my experience getting panel-orient info is something which comes
from the firmware /video-bios not from edid ?

Regards,

Hans



i) I don't think plymouth will handle this well though, since it tries to
skip unchanged connectors and I believe it only checks the crtc routing +
preferred modeline to determine "unchanged".


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [Intel-gfx] [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Simon Ser]

On Friday, February 18th, 2022 at 11:38, Hans de Goede <hdegoede@redhat.com> wrote:

> What I'm reading in the above is that it is being considered to allow
> changing the panel-orientation value after the connector has been made
> available to userspace; and let userspace know about this through a uevent.
>
> I believe that this is a bad idea, it is important to keep in mind here
> what userspace (e.g. plymouth) uses this prorty for. This property is
> used to rotate the image being rendered / shown on the framebuffer to
> adjust for the panel orientation.
>
> So now lets assume we apply the correct upside-down orientation later
> on a device with an upside-down mounted LCD panel. Then on boot the
> following could happen:
>
> 1. amdgpu exports a connector for the LCD panel to userspace without
> setting panel-orient=upside-down
> 2. plymouth sees this and renders its splash normally, but since the
> panel is upside-down it will now actually show upside-down

At this point amdgpu hasn't probed the connector yet. So the connector
will be marked as disconnected, and plymouth shouldn't render anything.

> 3. amdgpu adjusts the panel-orient prop to upside-down, sends out
> uevents

That's when amdgpu marks the connector as connected. So everything
should be fine I believe, no bad frame.

> 4. Lets assume plymouth handles this well (i) and now adjust its
> rendering and renders the next frame of the bootsplash 180° rotated
> to compensate for the panel being upside down. Then from now on
> the user will see the splash normally
>
> So this means that the user will briefly see the bootsplash rendered
> upside down which IMHO is not acceptable behavior. Also see my footnote
> about how I seriously doubt plymouth will see the panel-orient change
> at all.
>
> I'm also a bit unsure about:
>
> a) How you can register the panel connector with userspace before
> reading the edid, don't you need the edid to give the physical size +
> modeline to userspace, which you cannot just leave out ?

Yup. The KMS EDID property is created before the EDID is read, and is set
to zero (NULL blob). The width/height in mm and other info are also zero.
You can try inspecting the state printed by drm_info on any disconnected
connector to see for yourself.

> I guess the initial modeline is inherited from the video-bios, but
> what about the physical size? Note that you cannot just change the
> physical size later either, that gets used to determine the hidpi
> scaling factor in the bootsplash, and changing that after the initial
> bootsplash dislay will also look ugly
>
> b) Why you need the edid for the panel-orientation property at all,
> typically the edid prom is part of the panel and the panel does not
> know that it is mounted e.g. upside down at all, that is a property
> of the system as a whole not of the panel as a standalone unit so
> in my experience getting panel-orient info is something which comes
> from the firmware /video-bios not from edid ?

This is an internal DRM thing. The orientation quirks logic uses the
mode size advertised by the EDID. I agree that at least in the Steam
Deck case it may not make a lot of sense to use any info from the
EDID, but that's needed for the current status quo.

Also note, DisplayID has a bit to indicate the panel orientation IIRC.
Would be nice to support parsing this at some point.

Re: [Intel-gfx] [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Simon Ser]

On Friday, February 18th, 2022 at 11:38, Hans de Goede <hdegoede@redhat.com> wrote:

> What I'm reading in the above is that it is being considered to allow
> changing the panel-orientation value after the connector has been made
> available to userspace; and let userspace know about this through a uevent.
>
> I believe that this is a bad idea, it is important to keep in mind here
> what userspace (e.g. plymouth) uses this prorty for. This property is
> used to rotate the image being rendered / shown on the framebuffer to
> adjust for the panel orientation.
>
> So now lets assume we apply the correct upside-down orientation later
> on a device with an upside-down mounted LCD panel. Then on boot the
> following could happen:
>
> 1. amdgpu exports a connector for the LCD panel to userspace without
> setting panel-orient=upside-down
> 2. plymouth sees this and renders its splash normally, but since the
> panel is upside-down it will now actually show upside-down

At this point amdgpu hasn't probed the connector yet. So the connector
will be marked as disconnected, and plymouth shouldn't render anything.

> 3. amdgpu adjusts the panel-orient prop to upside-down, sends out
> uevents

That's when amdgpu marks the connector as connected. So everything
should be fine I believe, no bad frame.

> 4. Lets assume plymouth handles this well (i) and now adjust its
> rendering and renders the next frame of the bootsplash 180° rotated
> to compensate for the panel being upside down. Then from now on
> the user will see the splash normally
>
> So this means that the user will briefly see the bootsplash rendered
> upside down which IMHO is not acceptable behavior. Also see my footnote
> about how I seriously doubt plymouth will see the panel-orient change
> at all.
>
> I'm also a bit unsure about:
>
> a) How you can register the panel connector with userspace before
> reading the edid, don't you need the edid to give the physical size +
> modeline to userspace, which you cannot just leave out ?

Yup. The KMS EDID property is created before the EDID is read, and is set
to zero (NULL blob). The width/height in mm and other info are also zero.
You can try inspecting the state printed by drm_info on any disconnected
connector to see for yourself.

> I guess the initial modeline is inherited from the video-bios, but
> what about the physical size? Note that you cannot just change the
> physical size later either, that gets used to determine the hidpi
> scaling factor in the bootsplash, and changing that after the initial
> bootsplash dislay will also look ugly
>
> b) Why you need the edid for the panel-orientation property at all,
> typically the edid prom is part of the panel and the panel does not
> know that it is mounted e.g. upside down at all, that is a property
> of the system as a whole not of the panel as a standalone unit so
> in my experience getting panel-orient info is something which comes
> from the firmware /video-bios not from edid ?

This is an internal DRM thing. The orientation quirks logic uses the
mode size advertised by the EDID. I agree that at least in the Steam
Deck case it may not make a lot of sense to use any info from the
EDID, but that's needed for the current status quo.

Also note, DisplayID has a bit to indicate the panel orientation IIRC.
Would be nice to support parsing this at some point.

Re: [Intel-gfx] [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Simon Ser]

On Friday, February 18th, 2022 at 11:38, Hans de Goede <hdegoede@redhat.com> wrote:

> What I'm reading in the above is that it is being considered to allow
> changing the panel-orientation value after the connector has been made
> available to userspace; and let userspace know about this through a uevent.
>
> I believe that this is a bad idea, it is important to keep in mind here
> what userspace (e.g. plymouth) uses this prorty for. This property is
> used to rotate the image being rendered / shown on the framebuffer to
> adjust for the panel orientation.
>
> So now lets assume we apply the correct upside-down orientation later
> on a device with an upside-down mounted LCD panel. Then on boot the
> following could happen:
>
> 1. amdgpu exports a connector for the LCD panel to userspace without
> setting panel-orient=upside-down
> 2. plymouth sees this and renders its splash normally, but since the
> panel is upside-down it will now actually show upside-down

At this point amdgpu hasn't probed the connector yet. So the connector
will be marked as disconnected, and plymouth shouldn't render anything.

> 3. amdgpu adjusts the panel-orient prop to upside-down, sends out
> uevents

That's when amdgpu marks the connector as connected. So everything
should be fine I believe, no bad frame.

> 4. Lets assume plymouth handles this well (i) and now adjust its
> rendering and renders the next frame of the bootsplash 180° rotated
> to compensate for the panel being upside down. Then from now on
> the user will see the splash normally
>
> So this means that the user will briefly see the bootsplash rendered
> upside down which IMHO is not acceptable behavior. Also see my footnote
> about how I seriously doubt plymouth will see the panel-orient change
> at all.
>
> I'm also a bit unsure about:
>
> a) How you can register the panel connector with userspace before
> reading the edid, don't you need the edid to give the physical size +
> modeline to userspace, which you cannot just leave out ?

Yup. The KMS EDID property is created before the EDID is read, and is set
to zero (NULL blob). The width/height in mm and other info are also zero.
You can try inspecting the state printed by drm_info on any disconnected
connector to see for yourself.

> I guess the initial modeline is inherited from the video-bios, but
> what about the physical size? Note that you cannot just change the
> physical size later either, that gets used to determine the hidpi
> scaling factor in the bootsplash, and changing that after the initial
> bootsplash dislay will also look ugly
>
> b) Why you need the edid for the panel-orientation property at all,
> typically the edid prom is part of the panel and the panel does not
> know that it is mounted e.g. upside down at all, that is a property
> of the system as a whole not of the panel as a standalone unit so
> in my experience getting panel-orient info is something which comes
> from the firmware /video-bios not from edid ?

This is an internal DRM thing. The orientation quirks logic uses the
mode size advertised by the EDID. I agree that at least in the Steam
Deck case it may not make a lot of sense to use any info from the
EDID, but that's needed for the current status quo.

Also note, DisplayID has a bit to indicate the panel orientation IIRC.
Would be nice to support parsing this at some point.

Re: [Intel-gfx] [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Simon Ser]

On Friday, February 18th, 2022 at 11:38, Hans de Goede <hdegoede@redhat.com> wrote:

> What I'm reading in the above is that it is being considered to allow
> changing the panel-orientation value after the connector has been made
> available to userspace; and let userspace know about this through a uevent.
>
> I believe that this is a bad idea, it is important to keep in mind here
> what userspace (e.g. plymouth) uses this prorty for. This property is
> used to rotate the image being rendered / shown on the framebuffer to
> adjust for the panel orientation.
>
> So now lets assume we apply the correct upside-down orientation later
> on a device with an upside-down mounted LCD panel. Then on boot the
> following could happen:
>
> 1. amdgpu exports a connector for the LCD panel to userspace without
> setting panel-orient=upside-down
> 2. plymouth sees this and renders its splash normally, but since the
> panel is upside-down it will now actually show upside-down

At this point amdgpu hasn't probed the connector yet. So the connector
will be marked as disconnected, and plymouth shouldn't render anything.

> 3. amdgpu adjusts the panel-orient prop to upside-down, sends out
> uevents

That's when amdgpu marks the connector as connected. So everything
should be fine I believe, no bad frame.

> 4. Lets assume plymouth handles this well (i) and now adjust its
> rendering and renders the next frame of the bootsplash 180° rotated
> to compensate for the panel being upside down. Then from now on
> the user will see the splash normally
>
> So this means that the user will briefly see the bootsplash rendered
> upside down which IMHO is not acceptable behavior. Also see my footnote
> about how I seriously doubt plymouth will see the panel-orient change
> at all.
>
> I'm also a bit unsure about:
>
> a) How you can register the panel connector with userspace before
> reading the edid, don't you need the edid to give the physical size +
> modeline to userspace, which you cannot just leave out ?

Yup. The KMS EDID property is created before the EDID is read, and is set
to zero (NULL blob). The width/height in mm and other info are also zero.
You can try inspecting the state printed by drm_info on any disconnected
connector to see for yourself.

> I guess the initial modeline is inherited from the video-bios, but
> what about the physical size? Note that you cannot just change the
> physical size later either, that gets used to determine the hidpi
> scaling factor in the bootsplash, and changing that after the initial
> bootsplash dislay will also look ugly
>
> b) Why you need the edid for the panel-orientation property at all,
> typically the edid prom is part of the panel and the panel does not
> know that it is mounted e.g. upside down at all, that is a property
> of the system as a whole not of the panel as a standalone unit so
> in my experience getting panel-orient info is something which comes
> from the firmware /video-bios not from edid ?

This is an internal DRM thing. The orientation quirks logic uses the
mode size advertised by the EDID. I agree that at least in the Steam
Deck case it may not make a lot of sense to use any info from the
EDID, but that's needed for the current status quo.

Also note, DisplayID has a bit to indicate the panel orientation IIRC.
Would be nice to support parsing this at some point.

Re: [Intel-gfx] [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Simon Ser]

On Friday, February 18th, 2022 at 11:38, Hans de Goede <hdegoede@redhat.com> wrote:

> What I'm reading in the above is that it is being considered to allow
> changing the panel-orientation value after the connector has been made
> available to userspace; and let userspace know about this through a uevent.
>
> I believe that this is a bad idea, it is important to keep in mind here
> what userspace (e.g. plymouth) uses this prorty for. This property is
> used to rotate the image being rendered / shown on the framebuffer to
> adjust for the panel orientation.
>
> So now lets assume we apply the correct upside-down orientation later
> on a device with an upside-down mounted LCD panel. Then on boot the
> following could happen:
>
> 1. amdgpu exports a connector for the LCD panel to userspace without
> setting panel-orient=upside-down
> 2. plymouth sees this and renders its splash normally, but since the
> panel is upside-down it will now actually show upside-down

At this point amdgpu hasn't probed the connector yet. So the connector
will be marked as disconnected, and plymouth shouldn't render anything.

> 3. amdgpu adjusts the panel-orient prop to upside-down, sends out
> uevents

That's when amdgpu marks the connector as connected. So everything
should be fine I believe, no bad frame.

> 4. Lets assume plymouth handles this well (i) and now adjust its
> rendering and renders the next frame of the bootsplash 180° rotated
> to compensate for the panel being upside down. Then from now on
> the user will see the splash normally
>
> So this means that the user will briefly see the bootsplash rendered
> upside down which IMHO is not acceptable behavior. Also see my footnote
> about how I seriously doubt plymouth will see the panel-orient change
> at all.
>
> I'm also a bit unsure about:
>
> a) How you can register the panel connector with userspace before
> reading the edid, don't you need the edid to give the physical size +
> modeline to userspace, which you cannot just leave out ?

Yup. The KMS EDID property is created before the EDID is read, and is set
to zero (NULL blob). The width/height in mm and other info are also zero.
You can try inspecting the state printed by drm_info on any disconnected
connector to see for yourself.

> I guess the initial modeline is inherited from the video-bios, but
> what about the physical size? Note that you cannot just change the
> physical size later either, that gets used to determine the hidpi
> scaling factor in the bootsplash, and changing that after the initial
> bootsplash dislay will also look ugly
>
> b) Why you need the edid for the panel-orientation property at all,
> typically the edid prom is part of the panel and the panel does not
> know that it is mounted e.g. upside down at all, that is a property
> of the system as a whole not of the panel as a standalone unit so
> in my experience getting panel-orient info is something which comes
> from the firmware /video-bios not from edid ?

This is an internal DRM thing. The orientation quirks logic uses the
mode size advertised by the EDID. I agree that at least in the Steam
Deck case it may not make a lot of sense to use any info from the
EDID, but that's needed for the current status quo.

Also note, DisplayID has a bit to indicate the panel orientation IIRC.
Would be nice to support parsing this at some point.

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

Re: [Intel-gfx] [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Simon Ser]

On Friday, February 18th, 2022 at 11:38, Hans de Goede <hdegoede@redhat.com> wrote:

> What I'm reading in the above is that it is being considered to allow
> changing the panel-orientation value after the connector has been made
> available to userspace; and let userspace know about this through a uevent.
>
> I believe that this is a bad idea, it is important to keep in mind here
> what userspace (e.g. plymouth) uses this prorty for. This property is
> used to rotate the image being rendered / shown on the framebuffer to
> adjust for the panel orientation.
>
> So now lets assume we apply the correct upside-down orientation later
> on a device with an upside-down mounted LCD panel. Then on boot the
> following could happen:
>
> 1. amdgpu exports a connector for the LCD panel to userspace without
> setting panel-orient=upside-down
> 2. plymouth sees this and renders its splash normally, but since the
> panel is upside-down it will now actually show upside-down

At this point amdgpu hasn't probed the connector yet. So the connector
will be marked as disconnected, and plymouth shouldn't render anything.

> 3. amdgpu adjusts the panel-orient prop to upside-down, sends out
> uevents

That's when amdgpu marks the connector as connected. So everything
should be fine I believe, no bad frame.

> 4. Lets assume plymouth handles this well (i) and now adjust its
> rendering and renders the next frame of the bootsplash 180° rotated
> to compensate for the panel being upside down. Then from now on
> the user will see the splash normally
>
> So this means that the user will briefly see the bootsplash rendered
> upside down which IMHO is not acceptable behavior. Also see my footnote
> about how I seriously doubt plymouth will see the panel-orient change
> at all.
>
> I'm also a bit unsure about:
>
> a) How you can register the panel connector with userspace before
> reading the edid, don't you need the edid to give the physical size +
> modeline to userspace, which you cannot just leave out ?

Yup. The KMS EDID property is created before the EDID is read, and is set
to zero (NULL blob). The width/height in mm and other info are also zero.
You can try inspecting the state printed by drm_info on any disconnected
connector to see for yourself.

> I guess the initial modeline is inherited from the video-bios, but
> what about the physical size? Note that you cannot just change the
> physical size later either, that gets used to determine the hidpi
> scaling factor in the bootsplash, and changing that after the initial
> bootsplash dislay will also look ugly
>
> b) Why you need the edid for the panel-orientation property at all,
> typically the edid prom is part of the panel and the panel does not
> know that it is mounted e.g. upside down at all, that is a property
> of the system as a whole not of the panel as a standalone unit so
> in my experience getting panel-orient info is something which comes
> from the firmware /video-bios not from edid ?

This is an internal DRM thing. The orientation quirks logic uses the
mode size advertised by the EDID. I agree that at least in the Steam
Deck case it may not make a lot of sense to use any info from the
EDID, but that's needed for the current status quo.

Also note, DisplayID has a bit to indicate the panel orientation IIRC.
Would be nice to support parsing this at some point.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [Intel-gfx] [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Hans de Goede]

Hi,

On 2/18/22 12:39, Simon Ser wrote:
> On Friday, February 18th, 2022 at 11:38, Hans de Goede <hdegoede@redhat.com> wrote:
> 
>> What I'm reading in the above is that it is being considered to allow
>> changing the panel-orientation value after the connector has been made
>> available to userspace; and let userspace know about this through a uevent.
>>
>> I believe that this is a bad idea, it is important to keep in mind here
>> what userspace (e.g. plymouth) uses this prorty for. This property is
>> used to rotate the image being rendered / shown on the framebuffer to
>> adjust for the panel orientation.
>>
>> So now lets assume we apply the correct upside-down orientation later
>> on a device with an upside-down mounted LCD panel. Then on boot the
>> following could happen:
>>
>> 1. amdgpu exports a connector for the LCD panel to userspace without
>> setting panel-orient=upside-down
>> 2. plymouth sees this and renders its splash normally, but since the
>> panel is upside-down it will now actually show upside-down
> 
> At this point amdgpu hasn't probed the connector yet. So the connector
> will be marked as disconnected, and plymouth shouldn't render anything.

If before the initial probe of the connector there is a /dev/dri/card0 
which plymouth can access, then plymouth may at this point decide
to disable any seemingly unused crtcs, which will make the screen go black...

I'm not sure if plymouth will actually do this, but AFAICT this would
not be invalid behavior for a userspace kms consumer to do and I
believe it is likely that mutter will disable unused crtcs.

IMHO it is just a bad idea to register /dev/dri/card0 with userspace
before the initial connector probe is done. Nothing good can come
of that.

If all the exposed connectors initially are going to show up as
disconnected anyways what is the value in registering /dev/dri/card0
with userspace early ?

>> 3. amdgpu adjusts the panel-orient prop to upside-down, sends out
>> uevents
> 
> That's when amdgpu marks the connector as connected. So everything
> should be fine I believe, no bad frame.

See above.

>> 4. Lets assume plymouth handles this well (i) and now adjust its
>> rendering and renders the next frame of the bootsplash 180° rotated
>> to compensate for the panel being upside down. Then from now on
>> the user will see the splash normally
>>
>> So this means that the user will briefly see the bootsplash rendered
>> upside down which IMHO is not acceptable behavior. Also see my footnote
>> about how I seriously doubt plymouth will see the panel-orient change
>> at all.
>>
>> I'm also a bit unsure about:
>>
>> a) How you can register the panel connector with userspace before
>> reading the edid, don't you need the edid to give the physical size +
>> modeline to userspace, which you cannot just leave out ?
> 
> Yup. The KMS EDID property is created before the EDID is read, and is set
> to zero (NULL blob). The width/height in mm and other info are also zero.
> You can try inspecting the state printed by drm_info on any disconnected
> connector to see for yourself.

Right, I missed the detail hat the connector is initially marked as
disconnected. That solves the issue of invalid panel-orient / mode /
dpi info, bit it opens up other problems.

>> I guess the initial modeline is inherited from the video-bios, but
>> what about the physical size? Note that you cannot just change the
>> physical size later either, that gets used to determine the hidpi
>> scaling factor in the bootsplash, and changing that after the initial
>> bootsplash dislay will also look ugly
>>
>> b) Why you need the edid for the panel-orientation property at all,
>> typically the edid prom is part of the panel and the panel does not
>> know that it is mounted e.g. upside down at all, that is a property
>> of the system as a whole not of the panel as a standalone unit so
>> in my experience getting panel-orient info is something which comes
>> from the firmware /video-bios not from edid ?
> 
> This is an internal DRM thing. The orientation quirks logic uses the
> mode size advertised by the EDID.

The DMI based quirking does, yes. But e.g. the quirk code directly
reading this from the Intel VBT does not rely on the mode.

But if you are planning on using a DMI based quirk for the steamdeck
then yes that needs the mode.

Thee mode check is there for 2 reasons:

1. To avoid also applying the quirk to external displays, but
I think that that is also solved in most drivers by only checking for
a quirk at all on the eDP connector

2. Some laptop models ship with different panels in different badges
some of these are portrait (so need a panel-orient) setting and others
are landscape.

> I agree that at least in the Steam
> Deck case it may not make a lot of sense to use any info from the
> EDID, but that's needed for the current status quo.

We could extend the DMI quirk mechanism to allow quirks which don't
do the mode check, for use on devices where we can guarantee neither
1 nor 2 happens, then amdgpu could call the quirk code early simply
passing 0x0 as resolution.

> Also note, DisplayID has a bit to indicate the panel orientation IIRC.
> Would be nice to support parsing this at some point.

Ack.

Regards,

Hans

Re: [Intel-gfx] [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Hans de Goede]

Hi,

On 2/18/22 12:39, Simon Ser wrote:
> On Friday, February 18th, 2022 at 11:38, Hans de Goede <hdegoede@redhat.com> wrote:
> 
>> What I'm reading in the above is that it is being considered to allow
>> changing the panel-orientation value after the connector has been made
>> available to userspace; and let userspace know about this through a uevent.
>>
>> I believe that this is a bad idea, it is important to keep in mind here
>> what userspace (e.g. plymouth) uses this prorty for. This property is
>> used to rotate the image being rendered / shown on the framebuffer to
>> adjust for the panel orientation.
>>
>> So now lets assume we apply the correct upside-down orientation later
>> on a device with an upside-down mounted LCD panel. Then on boot the
>> following could happen:
>>
>> 1. amdgpu exports a connector for the LCD panel to userspace without
>> setting panel-orient=upside-down
>> 2. plymouth sees this and renders its splash normally, but since the
>> panel is upside-down it will now actually show upside-down
> 
> At this point amdgpu hasn't probed the connector yet. So the connector
> will be marked as disconnected, and plymouth shouldn't render anything.

If before the initial probe of the connector there is a /dev/dri/card0 
which plymouth can access, then plymouth may at this point decide
to disable any seemingly unused crtcs, which will make the screen go black...

I'm not sure if plymouth will actually do this, but AFAICT this would
not be invalid behavior for a userspace kms consumer to do and I
believe it is likely that mutter will disable unused crtcs.

IMHO it is just a bad idea to register /dev/dri/card0 with userspace
before the initial connector probe is done. Nothing good can come
of that.

If all the exposed connectors initially are going to show up as
disconnected anyways what is the value in registering /dev/dri/card0
with userspace early ?

>> 3. amdgpu adjusts the panel-orient prop to upside-down, sends out
>> uevents
> 
> That's when amdgpu marks the connector as connected. So everything
> should be fine I believe, no bad frame.

See above.

>> 4. Lets assume plymouth handles this well (i) and now adjust its
>> rendering and renders the next frame of the bootsplash 180° rotated
>> to compensate for the panel being upside down. Then from now on
>> the user will see the splash normally
>>
>> So this means that the user will briefly see the bootsplash rendered
>> upside down which IMHO is not acceptable behavior. Also see my footnote
>> about how I seriously doubt plymouth will see the panel-orient change
>> at all.
>>
>> I'm also a bit unsure about:
>>
>> a) How you can register the panel connector with userspace before
>> reading the edid, don't you need the edid to give the physical size +
>> modeline to userspace, which you cannot just leave out ?
> 
> Yup. The KMS EDID property is created before the EDID is read, and is set
> to zero (NULL blob). The width/height in mm and other info are also zero.
> You can try inspecting the state printed by drm_info on any disconnected
> connector to see for yourself.

Right, I missed the detail hat the connector is initially marked as
disconnected. That solves the issue of invalid panel-orient / mode /
dpi info, bit it opens up other problems.

>> I guess the initial modeline is inherited from the video-bios, but
>> what about the physical size? Note that you cannot just change the
>> physical size later either, that gets used to determine the hidpi
>> scaling factor in the bootsplash, and changing that after the initial
>> bootsplash dislay will also look ugly
>>
>> b) Why you need the edid for the panel-orientation property at all,
>> typically the edid prom is part of the panel and the panel does not
>> know that it is mounted e.g. upside down at all, that is a property
>> of the system as a whole not of the panel as a standalone unit so
>> in my experience getting panel-orient info is something which comes
>> from the firmware /video-bios not from edid ?
> 
> This is an internal DRM thing. The orientation quirks logic uses the
> mode size advertised by the EDID.

The DMI based quirking does, yes. But e.g. the quirk code directly
reading this from the Intel VBT does not rely on the mode.

But if you are planning on using a DMI based quirk for the steamdeck
then yes that needs the mode.

Thee mode check is there for 2 reasons:

1. To avoid also applying the quirk to external displays, but
I think that that is also solved in most drivers by only checking for
a quirk at all on the eDP connector

2. Some laptop models ship with different panels in different badges
some of these are portrait (so need a panel-orient) setting and others
are landscape.

> I agree that at least in the Steam
> Deck case it may not make a lot of sense to use any info from the
> EDID, but that's needed for the current status quo.

We could extend the DMI quirk mechanism to allow quirks which don't
do the mode check, for use on devices where we can guarantee neither
1 nor 2 happens, then amdgpu could call the quirk code early simply
passing 0x0 as resolution.

> Also note, DisplayID has a bit to indicate the panel orientation IIRC.
> Would be nice to support parsing this at some point.

Ack.

Regards,

Hans

Re: [Intel-gfx] [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Hans de Goede]

Hi,

On 2/18/22 12:39, Simon Ser wrote:
> On Friday, February 18th, 2022 at 11:38, Hans de Goede <hdegoede@redhat.com> wrote:
> 
>> What I'm reading in the above is that it is being considered to allow
>> changing the panel-orientation value after the connector has been made
>> available to userspace; and let userspace know about this through a uevent.
>>
>> I believe that this is a bad idea, it is important to keep in mind here
>> what userspace (e.g. plymouth) uses this prorty for. This property is
>> used to rotate the image being rendered / shown on the framebuffer to
>> adjust for the panel orientation.
>>
>> So now lets assume we apply the correct upside-down orientation later
>> on a device with an upside-down mounted LCD panel. Then on boot the
>> following could happen:
>>
>> 1. amdgpu exports a connector for the LCD panel to userspace without
>> setting panel-orient=upside-down
>> 2. plymouth sees this and renders its splash normally, but since the
>> panel is upside-down it will now actually show upside-down
> 
> At this point amdgpu hasn't probed the connector yet. So the connector
> will be marked as disconnected, and plymouth shouldn't render anything.

If before the initial probe of the connector there is a /dev/dri/card0 
which plymouth can access, then plymouth may at this point decide
to disable any seemingly unused crtcs, which will make the screen go black...

I'm not sure if plymouth will actually do this, but AFAICT this would
not be invalid behavior for a userspace kms consumer to do and I
believe it is likely that mutter will disable unused crtcs.

IMHO it is just a bad idea to register /dev/dri/card0 with userspace
before the initial connector probe is done. Nothing good can come
of that.

If all the exposed connectors initially are going to show up as
disconnected anyways what is the value in registering /dev/dri/card0
with userspace early ?

>> 3. amdgpu adjusts the panel-orient prop to upside-down, sends out
>> uevents
> 
> That's when amdgpu marks the connector as connected. So everything
> should be fine I believe, no bad frame.

See above.

>> 4. Lets assume plymouth handles this well (i) and now adjust its
>> rendering and renders the next frame of the bootsplash 180° rotated
>> to compensate for the panel being upside down. Then from now on
>> the user will see the splash normally
>>
>> So this means that the user will briefly see the bootsplash rendered
>> upside down which IMHO is not acceptable behavior. Also see my footnote
>> about how I seriously doubt plymouth will see the panel-orient change
>> at all.
>>
>> I'm also a bit unsure about:
>>
>> a) How you can register the panel connector with userspace before
>> reading the edid, don't you need the edid to give the physical size +
>> modeline to userspace, which you cannot just leave out ?
> 
> Yup. The KMS EDID property is created before the EDID is read, and is set
> to zero (NULL blob). The width/height in mm and other info are also zero.
> You can try inspecting the state printed by drm_info on any disconnected
> connector to see for yourself.

Right, I missed the detail hat the connector is initially marked as
disconnected. That solves the issue of invalid panel-orient / mode /
dpi info, bit it opens up other problems.

>> I guess the initial modeline is inherited from the video-bios, but
>> what about the physical size? Note that you cannot just change the
>> physical size later either, that gets used to determine the hidpi
>> scaling factor in the bootsplash, and changing that after the initial
>> bootsplash dislay will also look ugly
>>
>> b) Why you need the edid for the panel-orientation property at all,
>> typically the edid prom is part of the panel and the panel does not
>> know that it is mounted e.g. upside down at all, that is a property
>> of the system as a whole not of the panel as a standalone unit so
>> in my experience getting panel-orient info is something which comes
>> from the firmware /video-bios not from edid ?
> 
> This is an internal DRM thing. The orientation quirks logic uses the
> mode size advertised by the EDID.

The DMI based quirking does, yes. But e.g. the quirk code directly
reading this from the Intel VBT does not rely on the mode.

But if you are planning on using a DMI based quirk for the steamdeck
then yes that needs the mode.

Thee mode check is there for 2 reasons:

1. To avoid also applying the quirk to external displays, but
I think that that is also solved in most drivers by only checking for
a quirk at all on the eDP connector

2. Some laptop models ship with different panels in different badges
some of these are portrait (so need a panel-orient) setting and others
are landscape.

> I agree that at least in the Steam
> Deck case it may not make a lot of sense to use any info from the
> EDID, but that's needed for the current status quo.

We could extend the DMI quirk mechanism to allow quirks which don't
do the mode check, for use on devices where we can guarantee neither
1 nor 2 happens, then amdgpu could call the quirk code early simply
passing 0x0 as resolution.

> Also note, DisplayID has a bit to indicate the panel orientation IIRC.
> Would be nice to support parsing this at some point.

Ack.

Regards,

Hans

Re: [Intel-gfx] [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Hans de Goede]

Hi,

On 2/18/22 12:39, Simon Ser wrote:
> On Friday, February 18th, 2022 at 11:38, Hans de Goede <hdegoede@redhat.com> wrote:
> 
>> What I'm reading in the above is that it is being considered to allow
>> changing the panel-orientation value after the connector has been made
>> available to userspace; and let userspace know about this through a uevent.
>>
>> I believe that this is a bad idea, it is important to keep in mind here
>> what userspace (e.g. plymouth) uses this prorty for. This property is
>> used to rotate the image being rendered / shown on the framebuffer to
>> adjust for the panel orientation.
>>
>> So now lets assume we apply the correct upside-down orientation later
>> on a device with an upside-down mounted LCD panel. Then on boot the
>> following could happen:
>>
>> 1. amdgpu exports a connector for the LCD panel to userspace without
>> setting panel-orient=upside-down
>> 2. plymouth sees this and renders its splash normally, but since the
>> panel is upside-down it will now actually show upside-down
> 
> At this point amdgpu hasn't probed the connector yet. So the connector
> will be marked as disconnected, and plymouth shouldn't render anything.

If before the initial probe of the connector there is a /dev/dri/card0 
which plymouth can access, then plymouth may at this point decide
to disable any seemingly unused crtcs, which will make the screen go black...

I'm not sure if plymouth will actually do this, but AFAICT this would
not be invalid behavior for a userspace kms consumer to do and I
believe it is likely that mutter will disable unused crtcs.

IMHO it is just a bad idea to register /dev/dri/card0 with userspace
before the initial connector probe is done. Nothing good can come
of that.

If all the exposed connectors initially are going to show up as
disconnected anyways what is the value in registering /dev/dri/card0
with userspace early ?

>> 3. amdgpu adjusts the panel-orient prop to upside-down, sends out
>> uevents
> 
> That's when amdgpu marks the connector as connected. So everything
> should be fine I believe, no bad frame.

See above.

>> 4. Lets assume plymouth handles this well (i) and now adjust its
>> rendering and renders the next frame of the bootsplash 180° rotated
>> to compensate for the panel being upside down. Then from now on
>> the user will see the splash normally
>>
>> So this means that the user will briefly see the bootsplash rendered
>> upside down which IMHO is not acceptable behavior. Also see my footnote
>> about how I seriously doubt plymouth will see the panel-orient change
>> at all.
>>
>> I'm also a bit unsure about:
>>
>> a) How you can register the panel connector with userspace before
>> reading the edid, don't you need the edid to give the physical size +
>> modeline to userspace, which you cannot just leave out ?
> 
> Yup. The KMS EDID property is created before the EDID is read, and is set
> to zero (NULL blob). The width/height in mm and other info are also zero.
> You can try inspecting the state printed by drm_info on any disconnected
> connector to see for yourself.

Right, I missed the detail hat the connector is initially marked as
disconnected. That solves the issue of invalid panel-orient / mode /
dpi info, bit it opens up other problems.

>> I guess the initial modeline is inherited from the video-bios, but
>> what about the physical size? Note that you cannot just change the
>> physical size later either, that gets used to determine the hidpi
>> scaling factor in the bootsplash, and changing that after the initial
>> bootsplash dislay will also look ugly
>>
>> b) Why you need the edid for the panel-orientation property at all,
>> typically the edid prom is part of the panel and the panel does not
>> know that it is mounted e.g. upside down at all, that is a property
>> of the system as a whole not of the panel as a standalone unit so
>> in my experience getting panel-orient info is something which comes
>> from the firmware /video-bios not from edid ?
> 
> This is an internal DRM thing. The orientation quirks logic uses the
> mode size advertised by the EDID.

The DMI based quirking does, yes. But e.g. the quirk code directly
reading this from the Intel VBT does not rely on the mode.

But if you are planning on using a DMI based quirk for the steamdeck
then yes that needs the mode.

Thee mode check is there for 2 reasons:

1. To avoid also applying the quirk to external displays, but
I think that that is also solved in most drivers by only checking for
a quirk at all on the eDP connector

2. Some laptop models ship with different panels in different badges
some of these are portrait (so need a panel-orient) setting and others
are landscape.

> I agree that at least in the Steam
> Deck case it may not make a lot of sense to use any info from the
> EDID, but that's needed for the current status quo.

We could extend the DMI quirk mechanism to allow quirks which don't
do the mode check, for use on devices where we can guarantee neither
1 nor 2 happens, then amdgpu could call the quirk code early simply
passing 0x0 as resolution.

> Also note, DisplayID has a bit to indicate the panel orientation IIRC.
> Would be nice to support parsing this at some point.

Ack.

Regards,

Hans


_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

Re: [Intel-gfx] [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Hans de Goede]

Hi,

On 2/18/22 12:39, Simon Ser wrote:
> On Friday, February 18th, 2022 at 11:38, Hans de Goede <hdegoede@redhat.com> wrote:
> 
>> What I'm reading in the above is that it is being considered to allow
>> changing the panel-orientation value after the connector has been made
>> available to userspace; and let userspace know about this through a uevent.
>>
>> I believe that this is a bad idea, it is important to keep in mind here
>> what userspace (e.g. plymouth) uses this prorty for. This property is
>> used to rotate the image being rendered / shown on the framebuffer to
>> adjust for the panel orientation.
>>
>> So now lets assume we apply the correct upside-down orientation later
>> on a device with an upside-down mounted LCD panel. Then on boot the
>> following could happen:
>>
>> 1. amdgpu exports a connector for the LCD panel to userspace without
>> setting panel-orient=upside-down
>> 2. plymouth sees this and renders its splash normally, but since the
>> panel is upside-down it will now actually show upside-down
> 
> At this point amdgpu hasn't probed the connector yet. So the connector
> will be marked as disconnected, and plymouth shouldn't render anything.

If before the initial probe of the connector there is a /dev/dri/card0 
which plymouth can access, then plymouth may at this point decide
to disable any seemingly unused crtcs, which will make the screen go black...

I'm not sure if plymouth will actually do this, but AFAICT this would
not be invalid behavior for a userspace kms consumer to do and I
believe it is likely that mutter will disable unused crtcs.

IMHO it is just a bad idea to register /dev/dri/card0 with userspace
before the initial connector probe is done. Nothing good can come
of that.

If all the exposed connectors initially are going to show up as
disconnected anyways what is the value in registering /dev/dri/card0
with userspace early ?

>> 3. amdgpu adjusts the panel-orient prop to upside-down, sends out
>> uevents
> 
> That's when amdgpu marks the connector as connected. So everything
> should be fine I believe, no bad frame.

See above.

>> 4. Lets assume plymouth handles this well (i) and now adjust its
>> rendering and renders the next frame of the bootsplash 180° rotated
>> to compensate for the panel being upside down. Then from now on
>> the user will see the splash normally
>>
>> So this means that the user will briefly see the bootsplash rendered
>> upside down which IMHO is not acceptable behavior. Also see my footnote
>> about how I seriously doubt plymouth will see the panel-orient change
>> at all.
>>
>> I'm also a bit unsure about:
>>
>> a) How you can register the panel connector with userspace before
>> reading the edid, don't you need the edid to give the physical size +
>> modeline to userspace, which you cannot just leave out ?
> 
> Yup. The KMS EDID property is created before the EDID is read, and is set
> to zero (NULL blob). The width/height in mm and other info are also zero.
> You can try inspecting the state printed by drm_info on any disconnected
> connector to see for yourself.

Right, I missed the detail hat the connector is initially marked as
disconnected. That solves the issue of invalid panel-orient / mode /
dpi info, bit it opens up other problems.

>> I guess the initial modeline is inherited from the video-bios, but
>> what about the physical size? Note that you cannot just change the
>> physical size later either, that gets used to determine the hidpi
>> scaling factor in the bootsplash, and changing that after the initial
>> bootsplash dislay will also look ugly
>>
>> b) Why you need the edid for the panel-orientation property at all,
>> typically the edid prom is part of the panel and the panel does not
>> know that it is mounted e.g. upside down at all, that is a property
>> of the system as a whole not of the panel as a standalone unit so
>> in my experience getting panel-orient info is something which comes
>> from the firmware /video-bios not from edid ?
> 
> This is an internal DRM thing. The orientation quirks logic uses the
> mode size advertised by the EDID.

The DMI based quirking does, yes. But e.g. the quirk code directly
reading this from the Intel VBT does not rely on the mode.

But if you are planning on using a DMI based quirk for the steamdeck
then yes that needs the mode.

Thee mode check is there for 2 reasons:

1. To avoid also applying the quirk to external displays, but
I think that that is also solved in most drivers by only checking for
a quirk at all on the eDP connector

2. Some laptop models ship with different panels in different badges
some of these are portrait (so need a panel-orient) setting and others
are landscape.

> I agree that at least in the Steam
> Deck case it may not make a lot of sense to use any info from the
> EDID, but that's needed for the current status quo.

We could extend the DMI quirk mechanism to allow quirks which don't
do the mode check, for use on devices where we can guarantee neither
1 nor 2 happens, then amdgpu could call the quirk code early simply
passing 0x0 as resolution.

> Also note, DisplayID has a bit to indicate the panel orientation IIRC.
> Would be nice to support parsing this at some point.

Ack.

Regards,

Hans


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [Intel-gfx] [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Hans de Goede]

Hi,

On 2/18/22 12:39, Simon Ser wrote:
> On Friday, February 18th, 2022 at 11:38, Hans de Goede <hdegoede@redhat.com> wrote:
> 
>> What I'm reading in the above is that it is being considered to allow
>> changing the panel-orientation value after the connector has been made
>> available to userspace; and let userspace know about this through a uevent.
>>
>> I believe that this is a bad idea, it is important to keep in mind here
>> what userspace (e.g. plymouth) uses this prorty for. This property is
>> used to rotate the image being rendered / shown on the framebuffer to
>> adjust for the panel orientation.
>>
>> So now lets assume we apply the correct upside-down orientation later
>> on a device with an upside-down mounted LCD panel. Then on boot the
>> following could happen:
>>
>> 1. amdgpu exports a connector for the LCD panel to userspace without
>> setting panel-orient=upside-down
>> 2. plymouth sees this and renders its splash normally, but since the
>> panel is upside-down it will now actually show upside-down
> 
> At this point amdgpu hasn't probed the connector yet. So the connector
> will be marked as disconnected, and plymouth shouldn't render anything.

If before the initial probe of the connector there is a /dev/dri/card0 
which plymouth can access, then plymouth may at this point decide
to disable any seemingly unused crtcs, which will make the screen go black...

I'm not sure if plymouth will actually do this, but AFAICT this would
not be invalid behavior for a userspace kms consumer to do and I
believe it is likely that mutter will disable unused crtcs.

IMHO it is just a bad idea to register /dev/dri/card0 with userspace
before the initial connector probe is done. Nothing good can come
of that.

If all the exposed connectors initially are going to show up as
disconnected anyways what is the value in registering /dev/dri/card0
with userspace early ?

>> 3. amdgpu adjusts the panel-orient prop to upside-down, sends out
>> uevents
> 
> That's when amdgpu marks the connector as connected. So everything
> should be fine I believe, no bad frame.

See above.

>> 4. Lets assume plymouth handles this well (i) and now adjust its
>> rendering and renders the next frame of the bootsplash 180° rotated
>> to compensate for the panel being upside down. Then from now on
>> the user will see the splash normally
>>
>> So this means that the user will briefly see the bootsplash rendered
>> upside down which IMHO is not acceptable behavior. Also see my footnote
>> about how I seriously doubt plymouth will see the panel-orient change
>> at all.
>>
>> I'm also a bit unsure about:
>>
>> a) How you can register the panel connector with userspace before
>> reading the edid, don't you need the edid to give the physical size +
>> modeline to userspace, which you cannot just leave out ?
> 
> Yup. The KMS EDID property is created before the EDID is read, and is set
> to zero (NULL blob). The width/height in mm and other info are also zero.
> You can try inspecting the state printed by drm_info on any disconnected
> connector to see for yourself.

Right, I missed the detail hat the connector is initially marked as
disconnected. That solves the issue of invalid panel-orient / mode /
dpi info, bit it opens up other problems.

>> I guess the initial modeline is inherited from the video-bios, but
>> what about the physical size? Note that you cannot just change the
>> physical size later either, that gets used to determine the hidpi
>> scaling factor in the bootsplash, and changing that after the initial
>> bootsplash dislay will also look ugly
>>
>> b) Why you need the edid for the panel-orientation property at all,
>> typically the edid prom is part of the panel and the panel does not
>> know that it is mounted e.g. upside down at all, that is a property
>> of the system as a whole not of the panel as a standalone unit so
>> in my experience getting panel-orient info is something which comes
>> from the firmware /video-bios not from edid ?
> 
> This is an internal DRM thing. The orientation quirks logic uses the
> mode size advertised by the EDID.

The DMI based quirking does, yes. But e.g. the quirk code directly
reading this from the Intel VBT does not rely on the mode.

But if you are planning on using a DMI based quirk for the steamdeck
then yes that needs the mode.

Thee mode check is there for 2 reasons:

1. To avoid also applying the quirk to external displays, but
I think that that is also solved in most drivers by only checking for
a quirk at all on the eDP connector

2. Some laptop models ship with different panels in different badges
some of these are portrait (so need a panel-orient) setting and others
are landscape.

> I agree that at least in the Steam
> Deck case it may not make a lot of sense to use any info from the
> EDID, but that's needed for the current status quo.

We could extend the DMI quirk mechanism to allow quirks which don't
do the mode check, for use on devices where we can guarantee neither
1 nor 2 happens, then amdgpu could call the quirk code early simply
passing 0x0 as resolution.

> Also note, DisplayID has a bit to indicate the panel orientation IIRC.
> Would be nice to support parsing this at some point.

Ack.

Regards,

Hans

Re: [Intel-gfx] [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Simon Ser]

On Friday, February 18th, 2022 at 12:54, Hans de Goede <hdegoede@redhat.com> wrote:

> On 2/18/22 12:39, Simon Ser wrote:
> > On Friday, February 18th, 2022 at 11:38, Hans de Goede <hdegoede@redhat.com> wrote:
> >
> >> What I'm reading in the above is that it is being considered to allow
> >> changing the panel-orientation value after the connector has been made
> >> available to userspace; and let userspace know about this through a uevent.
> >>
> >> I believe that this is a bad idea, it is important to keep in mind here
> >> what userspace (e.g. plymouth) uses this prorty for. This property is
> >> used to rotate the image being rendered / shown on the framebuffer to
> >> adjust for the panel orientation.
> >>
> >> So now lets assume we apply the correct upside-down orientation later
> >> on a device with an upside-down mounted LCD panel. Then on boot the
> >> following could happen:
> >>
> >> 1. amdgpu exports a connector for the LCD panel to userspace without
> >> setting panel-orient=upside-down
> >> 2. plymouth sees this and renders its splash normally, but since the
> >> panel is upside-down it will now actually show upside-down
> >
> > At this point amdgpu hasn't probed the connector yet. So the connector
> > will be marked as disconnected, and plymouth shouldn't render anything.
>
> If before the initial probe of the connector there is a /dev/dri/card0
> which plymouth can access, then plymouth may at this point decide
> to disable any seemingly unused crtcs, which will make the screen go black...
>
> I'm not sure if plymouth will actually do this, but AFAICT this would
> not be invalid behavior for a userspace kms consumer to do and I
> believe it is likely that mutter will disable unused crtcs.
>
> IMHO it is just a bad idea to register /dev/dri/card0 with userspace
> before the initial connector probe is done. Nothing good can come
> of that.
>
> If all the exposed connectors initially are going to show up as
> disconnected anyways what is the value in registering /dev/dri/card0
> with userspace early ?

OK. I'm still unsure how I feel about this, but I think I agree with
you. That said, the amdgpu architecture is quite involved with multiple
abstraction levels, so I don't think I'm equipped to write a patch to
fix this...

cc Daniel Vetter: can you confirm probing all connectors is a good thing
to do on driver module load?

> >> I guess the initial modeline is inherited from the video-bios, but
> >> what about the physical size? Note that you cannot just change the
> >> physical size later either, that gets used to determine the hidpi
> >> scaling factor in the bootsplash, and changing that after the initial
> >> bootsplash dislay will also look ugly
> >>
> >> b) Why you need the edid for the panel-orientation property at all,
> >> typically the edid prom is part of the panel and the panel does not
> >> know that it is mounted e.g. upside down at all, that is a property
> >> of the system as a whole not of the panel as a standalone unit so
> >> in my experience getting panel-orient info is something which comes
> >> from the firmware /video-bios not from edid ?
> >
> > This is an internal DRM thing. The orientation quirks logic uses the
> > mode size advertised by the EDID.
>
> The DMI based quirking does, yes. But e.g. the quirk code directly
> reading this from the Intel VBT does not rely on the mode.
>
> But if you are planning on using a DMI based quirk for the steamdeck
> then yes that needs the mode.
>
> Thee mode check is there for 2 reasons:
>
> 1. To avoid also applying the quirk to external displays, but
> I think that that is also solved in most drivers by only checking for
> a quirk at all on the eDP connector
>
> 2. Some laptop models ship with different panels in different badges
> some of these are portrait (so need a panel-orient) setting and others
> are landscape.

That makes sense. So yeah the EDID mode based matching logic needs to
stay to accomodate for these cases.

> > I agree that at least in the Steam
> > Deck case it may not make a lot of sense to use any info from the
> > EDID, but that's needed for the current status quo.
>
> We could extend the DMI quirk mechanism to allow quirks which don't
> do the mode check, for use on devices where we can guarantee neither
> 1 nor 2 happens, then amdgpu could call the quirk code early simply
> passing 0x0 as resolution.

Yeah. But per the above amdgpu should maybe probe connectors on module
load. If/when amdgpu is fixed to do this, then we don't need to disable
the mode matching logic in panel-orientation quirks anymore.

Re: [Intel-gfx] [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Simon Ser]

On Friday, February 18th, 2022 at 12:54, Hans de Goede <hdegoede@redhat.com> wrote:

> On 2/18/22 12:39, Simon Ser wrote:
> > On Friday, February 18th, 2022 at 11:38, Hans de Goede <hdegoede@redhat.com> wrote:
> >
> >> What I'm reading in the above is that it is being considered to allow
> >> changing the panel-orientation value after the connector has been made
> >> available to userspace; and let userspace know about this through a uevent.
> >>
> >> I believe that this is a bad idea, it is important to keep in mind here
> >> what userspace (e.g. plymouth) uses this prorty for. This property is
> >> used to rotate the image being rendered / shown on the framebuffer to
> >> adjust for the panel orientation.
> >>
> >> So now lets assume we apply the correct upside-down orientation later
> >> on a device with an upside-down mounted LCD panel. Then on boot the
> >> following could happen:
> >>
> >> 1. amdgpu exports a connector for the LCD panel to userspace without
> >> setting panel-orient=upside-down
> >> 2. plymouth sees this and renders its splash normally, but since the
> >> panel is upside-down it will now actually show upside-down
> >
> > At this point amdgpu hasn't probed the connector yet. So the connector
> > will be marked as disconnected, and plymouth shouldn't render anything.
>
> If before the initial probe of the connector there is a /dev/dri/card0
> which plymouth can access, then plymouth may at this point decide
> to disable any seemingly unused crtcs, which will make the screen go black...
>
> I'm not sure if plymouth will actually do this, but AFAICT this would
> not be invalid behavior for a userspace kms consumer to do and I
> believe it is likely that mutter will disable unused crtcs.
>
> IMHO it is just a bad idea to register /dev/dri/card0 with userspace
> before the initial connector probe is done. Nothing good can come
> of that.
>
> If all the exposed connectors initially are going to show up as
> disconnected anyways what is the value in registering /dev/dri/card0
> with userspace early ?

OK. I'm still unsure how I feel about this, but I think I agree with
you. That said, the amdgpu architecture is quite involved with multiple
abstraction levels, so I don't think I'm equipped to write a patch to
fix this...

cc Daniel Vetter: can you confirm probing all connectors is a good thing
to do on driver module load?

> >> I guess the initial modeline is inherited from the video-bios, but
> >> what about the physical size? Note that you cannot just change the
> >> physical size later either, that gets used to determine the hidpi
> >> scaling factor in the bootsplash, and changing that after the initial
> >> bootsplash dislay will also look ugly
> >>
> >> b) Why you need the edid for the panel-orientation property at all,
> >> typically the edid prom is part of the panel and the panel does not
> >> know that it is mounted e.g. upside down at all, that is a property
> >> of the system as a whole not of the panel as a standalone unit so
> >> in my experience getting panel-orient info is something which comes
> >> from the firmware /video-bios not from edid ?
> >
> > This is an internal DRM thing. The orientation quirks logic uses the
> > mode size advertised by the EDID.
>
> The DMI based quirking does, yes. But e.g. the quirk code directly
> reading this from the Intel VBT does not rely on the mode.
>
> But if you are planning on using a DMI based quirk for the steamdeck
> then yes that needs the mode.
>
> Thee mode check is there for 2 reasons:
>
> 1. To avoid also applying the quirk to external displays, but
> I think that that is also solved in most drivers by only checking for
> a quirk at all on the eDP connector
>
> 2. Some laptop models ship with different panels in different badges
> some of these are portrait (so need a panel-orient) setting and others
> are landscape.

That makes sense. So yeah the EDID mode based matching logic needs to
stay to accomodate for these cases.

> > I agree that at least in the Steam
> > Deck case it may not make a lot of sense to use any info from the
> > EDID, but that's needed for the current status quo.
>
> We could extend the DMI quirk mechanism to allow quirks which don't
> do the mode check, for use on devices where we can guarantee neither
> 1 nor 2 happens, then amdgpu could call the quirk code early simply
> passing 0x0 as resolution.

Yeah. But per the above amdgpu should maybe probe connectors on module
load. If/when amdgpu is fixed to do this, then we don't need to disable
the mode matching logic in panel-orientation quirks anymore.

Re: [Intel-gfx] [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Simon Ser]

On Friday, February 18th, 2022 at 12:54, Hans de Goede <hdegoede@redhat.com> wrote:

> On 2/18/22 12:39, Simon Ser wrote:
> > On Friday, February 18th, 2022 at 11:38, Hans de Goede <hdegoede@redhat.com> wrote:
> >
> >> What I'm reading in the above is that it is being considered to allow
> >> changing the panel-orientation value after the connector has been made
> >> available to userspace; and let userspace know about this through a uevent.
> >>
> >> I believe that this is a bad idea, it is important to keep in mind here
> >> what userspace (e.g. plymouth) uses this prorty for. This property is
> >> used to rotate the image being rendered / shown on the framebuffer to
> >> adjust for the panel orientation.
> >>
> >> So now lets assume we apply the correct upside-down orientation later
> >> on a device with an upside-down mounted LCD panel. Then on boot the
> >> following could happen:
> >>
> >> 1. amdgpu exports a connector for the LCD panel to userspace without
> >> setting panel-orient=upside-down
> >> 2. plymouth sees this and renders its splash normally, but since the
> >> panel is upside-down it will now actually show upside-down
> >
> > At this point amdgpu hasn't probed the connector yet. So the connector
> > will be marked as disconnected, and plymouth shouldn't render anything.
>
> If before the initial probe of the connector there is a /dev/dri/card0
> which plymouth can access, then plymouth may at this point decide
> to disable any seemingly unused crtcs, which will make the screen go black...
>
> I'm not sure if plymouth will actually do this, but AFAICT this would
> not be invalid behavior for a userspace kms consumer to do and I
> believe it is likely that mutter will disable unused crtcs.
>
> IMHO it is just a bad idea to register /dev/dri/card0 with userspace
> before the initial connector probe is done. Nothing good can come
> of that.
>
> If all the exposed connectors initially are going to show up as
> disconnected anyways what is the value in registering /dev/dri/card0
> with userspace early ?

OK. I'm still unsure how I feel about this, but I think I agree with
you. That said, the amdgpu architecture is quite involved with multiple
abstraction levels, so I don't think I'm equipped to write a patch to
fix this...

cc Daniel Vetter: can you confirm probing all connectors is a good thing
to do on driver module load?

> >> I guess the initial modeline is inherited from the video-bios, but
> >> what about the physical size? Note that you cannot just change the
> >> physical size later either, that gets used to determine the hidpi
> >> scaling factor in the bootsplash, and changing that after the initial
> >> bootsplash dislay will also look ugly
> >>
> >> b) Why you need the edid for the panel-orientation property at all,
> >> typically the edid prom is part of the panel and the panel does not
> >> know that it is mounted e.g. upside down at all, that is a property
> >> of the system as a whole not of the panel as a standalone unit so
> >> in my experience getting panel-orient info is something which comes
> >> from the firmware /video-bios not from edid ?
> >
> > This is an internal DRM thing. The orientation quirks logic uses the
> > mode size advertised by the EDID.
>
> The DMI based quirking does, yes. But e.g. the quirk code directly
> reading this from the Intel VBT does not rely on the mode.
>
> But if you are planning on using a DMI based quirk for the steamdeck
> then yes that needs the mode.
>
> Thee mode check is there for 2 reasons:
>
> 1. To avoid also applying the quirk to external displays, but
> I think that that is also solved in most drivers by only checking for
> a quirk at all on the eDP connector
>
> 2. Some laptop models ship with different panels in different badges
> some of these are portrait (so need a panel-orient) setting and others
> are landscape.

That makes sense. So yeah the EDID mode based matching logic needs to
stay to accomodate for these cases.

> > I agree that at least in the Steam
> > Deck case it may not make a lot of sense to use any info from the
> > EDID, but that's needed for the current status quo.
>
> We could extend the DMI quirk mechanism to allow quirks which don't
> do the mode check, for use on devices where we can guarantee neither
> 1 nor 2 happens, then amdgpu could call the quirk code early simply
> passing 0x0 as resolution.

Yeah. But per the above amdgpu should maybe probe connectors on module
load. If/when amdgpu is fixed to do this, then we don't need to disable
the mode matching logic in panel-orientation quirks anymore.

Re: [Intel-gfx] [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Simon Ser]

On Friday, February 18th, 2022 at 12:54, Hans de Goede <hdegoede@redhat.com> wrote:

> On 2/18/22 12:39, Simon Ser wrote:
> > On Friday, February 18th, 2022 at 11:38, Hans de Goede <hdegoede@redhat.com> wrote:
> >
> >> What I'm reading in the above is that it is being considered to allow
> >> changing the panel-orientation value after the connector has been made
> >> available to userspace; and let userspace know about this through a uevent.
> >>
> >> I believe that this is a bad idea, it is important to keep in mind here
> >> what userspace (e.g. plymouth) uses this prorty for. This property is
> >> used to rotate the image being rendered / shown on the framebuffer to
> >> adjust for the panel orientation.
> >>
> >> So now lets assume we apply the correct upside-down orientation later
> >> on a device with an upside-down mounted LCD panel. Then on boot the
> >> following could happen:
> >>
> >> 1. amdgpu exports a connector for the LCD panel to userspace without
> >> setting panel-orient=upside-down
> >> 2. plymouth sees this and renders its splash normally, but since the
> >> panel is upside-down it will now actually show upside-down
> >
> > At this point amdgpu hasn't probed the connector yet. So the connector
> > will be marked as disconnected, and plymouth shouldn't render anything.
>
> If before the initial probe of the connector there is a /dev/dri/card0
> which plymouth can access, then plymouth may at this point decide
> to disable any seemingly unused crtcs, which will make the screen go black...
>
> I'm not sure if plymouth will actually do this, but AFAICT this would
> not be invalid behavior for a userspace kms consumer to do and I
> believe it is likely that mutter will disable unused crtcs.
>
> IMHO it is just a bad idea to register /dev/dri/card0 with userspace
> before the initial connector probe is done. Nothing good can come
> of that.
>
> If all the exposed connectors initially are going to show up as
> disconnected anyways what is the value in registering /dev/dri/card0
> with userspace early ?

OK. I'm still unsure how I feel about this, but I think I agree with
you. That said, the amdgpu architecture is quite involved with multiple
abstraction levels, so I don't think I'm equipped to write a patch to
fix this...

cc Daniel Vetter: can you confirm probing all connectors is a good thing
to do on driver module load?

> >> I guess the initial modeline is inherited from the video-bios, but
> >> what about the physical size? Note that you cannot just change the
> >> physical size later either, that gets used to determine the hidpi
> >> scaling factor in the bootsplash, and changing that after the initial
> >> bootsplash dislay will also look ugly
> >>
> >> b) Why you need the edid for the panel-orientation property at all,
> >> typically the edid prom is part of the panel and the panel does not
> >> know that it is mounted e.g. upside down at all, that is a property
> >> of the system as a whole not of the panel as a standalone unit so
> >> in my experience getting panel-orient info is something which comes
> >> from the firmware /video-bios not from edid ?
> >
> > This is an internal DRM thing. The orientation quirks logic uses the
> > mode size advertised by the EDID.
>
> The DMI based quirking does, yes. But e.g. the quirk code directly
> reading this from the Intel VBT does not rely on the mode.
>
> But if you are planning on using a DMI based quirk for the steamdeck
> then yes that needs the mode.
>
> Thee mode check is there for 2 reasons:
>
> 1. To avoid also applying the quirk to external displays, but
> I think that that is also solved in most drivers by only checking for
> a quirk at all on the eDP connector
>
> 2. Some laptop models ship with different panels in different badges
> some of these are portrait (so need a panel-orient) setting and others
> are landscape.

That makes sense. So yeah the EDID mode based matching logic needs to
stay to accomodate for these cases.

> > I agree that at least in the Steam
> > Deck case it may not make a lot of sense to use any info from the
> > EDID, but that's needed for the current status quo.
>
> We could extend the DMI quirk mechanism to allow quirks which don't
> do the mode check, for use on devices where we can guarantee neither
> 1 nor 2 happens, then amdgpu could call the quirk code early simply
> passing 0x0 as resolution.

Yeah. But per the above amdgpu should maybe probe connectors on module
load. If/when amdgpu is fixed to do this, then we don't need to disable
the mode matching logic in panel-orientation quirks anymore.

Re: [Intel-gfx] [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Simon Ser]

On Friday, February 18th, 2022 at 12:54, Hans de Goede <hdegoede@redhat.com> wrote:

> On 2/18/22 12:39, Simon Ser wrote:
> > On Friday, February 18th, 2022 at 11:38, Hans de Goede <hdegoede@redhat.com> wrote:
> >
> >> What I'm reading in the above is that it is being considered to allow
> >> changing the panel-orientation value after the connector has been made
> >> available to userspace; and let userspace know about this through a uevent.
> >>
> >> I believe that this is a bad idea, it is important to keep in mind here
> >> what userspace (e.g. plymouth) uses this prorty for. This property is
> >> used to rotate the image being rendered / shown on the framebuffer to
> >> adjust for the panel orientation.
> >>
> >> So now lets assume we apply the correct upside-down orientation later
> >> on a device with an upside-down mounted LCD panel. Then on boot the
> >> following could happen:
> >>
> >> 1. amdgpu exports a connector for the LCD panel to userspace without
> >> setting panel-orient=upside-down
> >> 2. plymouth sees this and renders its splash normally, but since the
> >> panel is upside-down it will now actually show upside-down
> >
> > At this point amdgpu hasn't probed the connector yet. So the connector
> > will be marked as disconnected, and plymouth shouldn't render anything.
>
> If before the initial probe of the connector there is a /dev/dri/card0
> which plymouth can access, then plymouth may at this point decide
> to disable any seemingly unused crtcs, which will make the screen go black...
>
> I'm not sure if plymouth will actually do this, but AFAICT this would
> not be invalid behavior for a userspace kms consumer to do and I
> believe it is likely that mutter will disable unused crtcs.
>
> IMHO it is just a bad idea to register /dev/dri/card0 with userspace
> before the initial connector probe is done. Nothing good can come
> of that.
>
> If all the exposed connectors initially are going to show up as
> disconnected anyways what is the value in registering /dev/dri/card0
> with userspace early ?

OK. I'm still unsure how I feel about this, but I think I agree with
you. That said, the amdgpu architecture is quite involved with multiple
abstraction levels, so I don't think I'm equipped to write a patch to
fix this...

cc Daniel Vetter: can you confirm probing all connectors is a good thing
to do on driver module load?

> >> I guess the initial modeline is inherited from the video-bios, but
> >> what about the physical size? Note that you cannot just change the
> >> physical size later either, that gets used to determine the hidpi
> >> scaling factor in the bootsplash, and changing that after the initial
> >> bootsplash dislay will also look ugly
> >>
> >> b) Why you need the edid for the panel-orientation property at all,
> >> typically the edid prom is part of the panel and the panel does not
> >> know that it is mounted e.g. upside down at all, that is a property
> >> of the system as a whole not of the panel as a standalone unit so
> >> in my experience getting panel-orient info is something which comes
> >> from the firmware /video-bios not from edid ?
> >
> > This is an internal DRM thing. The orientation quirks logic uses the
> > mode size advertised by the EDID.
>
> The DMI based quirking does, yes. But e.g. the quirk code directly
> reading this from the Intel VBT does not rely on the mode.
>
> But if you are planning on using a DMI based quirk for the steamdeck
> then yes that needs the mode.
>
> Thee mode check is there for 2 reasons:
>
> 1. To avoid also applying the quirk to external displays, but
> I think that that is also solved in most drivers by only checking for
> a quirk at all on the eDP connector
>
> 2. Some laptop models ship with different panels in different badges
> some of these are portrait (so need a panel-orient) setting and others
> are landscape.

That makes sense. So yeah the EDID mode based matching logic needs to
stay to accomodate for these cases.

> > I agree that at least in the Steam
> > Deck case it may not make a lot of sense to use any info from the
> > EDID, but that's needed for the current status quo.
>
> We could extend the DMI quirk mechanism to allow quirks which don't
> do the mode check, for use on devices where we can guarantee neither
> 1 nor 2 happens, then amdgpu could call the quirk code early simply
> passing 0x0 as resolution.

Yeah. But per the above amdgpu should maybe probe connectors on module
load. If/when amdgpu is fixed to do this, then we don't need to disable
the mode matching logic in panel-orientation quirks anymore.

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

Re: [Intel-gfx] [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Simon Ser]

On Friday, February 18th, 2022 at 12:54, Hans de Goede <hdegoede@redhat.com> wrote:

> On 2/18/22 12:39, Simon Ser wrote:
> > On Friday, February 18th, 2022 at 11:38, Hans de Goede <hdegoede@redhat.com> wrote:
> >
> >> What I'm reading in the above is that it is being considered to allow
> >> changing the panel-orientation value after the connector has been made
> >> available to userspace; and let userspace know about this through a uevent.
> >>
> >> I believe that this is a bad idea, it is important to keep in mind here
> >> what userspace (e.g. plymouth) uses this prorty for. This property is
> >> used to rotate the image being rendered / shown on the framebuffer to
> >> adjust for the panel orientation.
> >>
> >> So now lets assume we apply the correct upside-down orientation later
> >> on a device with an upside-down mounted LCD panel. Then on boot the
> >> following could happen:
> >>
> >> 1. amdgpu exports a connector for the LCD panel to userspace without
> >> setting panel-orient=upside-down
> >> 2. plymouth sees this and renders its splash normally, but since the
> >> panel is upside-down it will now actually show upside-down
> >
> > At this point amdgpu hasn't probed the connector yet. So the connector
> > will be marked as disconnected, and plymouth shouldn't render anything.
>
> If before the initial probe of the connector there is a /dev/dri/card0
> which plymouth can access, then plymouth may at this point decide
> to disable any seemingly unused crtcs, which will make the screen go black...
>
> I'm not sure if plymouth will actually do this, but AFAICT this would
> not be invalid behavior for a userspace kms consumer to do and I
> believe it is likely that mutter will disable unused crtcs.
>
> IMHO it is just a bad idea to register /dev/dri/card0 with userspace
> before the initial connector probe is done. Nothing good can come
> of that.
>
> If all the exposed connectors initially are going to show up as
> disconnected anyways what is the value in registering /dev/dri/card0
> with userspace early ?

OK. I'm still unsure how I feel about this, but I think I agree with
you. That said, the amdgpu architecture is quite involved with multiple
abstraction levels, so I don't think I'm equipped to write a patch to
fix this...

cc Daniel Vetter: can you confirm probing all connectors is a good thing
to do on driver module load?

> >> I guess the initial modeline is inherited from the video-bios, but
> >> what about the physical size? Note that you cannot just change the
> >> physical size later either, that gets used to determine the hidpi
> >> scaling factor in the bootsplash, and changing that after the initial
> >> bootsplash dislay will also look ugly
> >>
> >> b) Why you need the edid for the panel-orientation property at all,
> >> typically the edid prom is part of the panel and the panel does not
> >> know that it is mounted e.g. upside down at all, that is a property
> >> of the system as a whole not of the panel as a standalone unit so
> >> in my experience getting panel-orient info is something which comes
> >> from the firmware /video-bios not from edid ?
> >
> > This is an internal DRM thing. The orientation quirks logic uses the
> > mode size advertised by the EDID.
>
> The DMI based quirking does, yes. But e.g. the quirk code directly
> reading this from the Intel VBT does not rely on the mode.
>
> But if you are planning on using a DMI based quirk for the steamdeck
> then yes that needs the mode.
>
> Thee mode check is there for 2 reasons:
>
> 1. To avoid also applying the quirk to external displays, but
> I think that that is also solved in most drivers by only checking for
> a quirk at all on the eDP connector
>
> 2. Some laptop models ship with different panels in different badges
> some of these are portrait (so need a panel-orient) setting and others
> are landscape.

That makes sense. So yeah the EDID mode based matching logic needs to
stay to accomodate for these cases.

> > I agree that at least in the Steam
> > Deck case it may not make a lot of sense to use any info from the
> > EDID, but that's needed for the current status quo.
>
> We could extend the DMI quirk mechanism to allow quirks which don't
> do the mode check, for use on devices where we can guarantee neither
> 1 nor 2 happens, then amdgpu could call the quirk code early simply
> passing 0x0 as resolution.

Yeah. But per the above amdgpu should maybe probe connectors on module
load. If/when amdgpu is fixed to do this, then we don't need to disable
the mode matching logic in panel-orientation quirks anymore.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [Intel-gfx] [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Alex Deucher]

On Fri, Feb 18, 2022 at 7:13 AM Simon Ser <contact@emersion.fr> wrote:
>
> On Friday, February 18th, 2022 at 12:54, Hans de Goede <hdegoede@redhat.com> wrote:
>
> > On 2/18/22 12:39, Simon Ser wrote:
> > > On Friday, February 18th, 2022 at 11:38, Hans de Goede <hdegoede@redhat.com> wrote:
> > >
> > >> What I'm reading in the above is that it is being considered to allow
> > >> changing the panel-orientation value after the connector has been made
> > >> available to userspace; and let userspace know about this through a uevent.
> > >>
> > >> I believe that this is a bad idea, it is important to keep in mind here
> > >> what userspace (e.g. plymouth) uses this prorty for. This property is
> > >> used to rotate the image being rendered / shown on the framebuffer to
> > >> adjust for the panel orientation.
> > >>
> > >> So now lets assume we apply the correct upside-down orientation later
> > >> on a device with an upside-down mounted LCD panel. Then on boot the
> > >> following could happen:
> > >>
> > >> 1. amdgpu exports a connector for the LCD panel to userspace without
> > >> setting panel-orient=upside-down
> > >> 2. plymouth sees this and renders its splash normally, but since the
> > >> panel is upside-down it will now actually show upside-down
> > >
> > > At this point amdgpu hasn't probed the connector yet. So the connector
> > > will be marked as disconnected, and plymouth shouldn't render anything.
> >
> > If before the initial probe of the connector there is a /dev/dri/card0
> > which plymouth can access, then plymouth may at this point decide
> > to disable any seemingly unused crtcs, which will make the screen go black...
> >
> > I'm not sure if plymouth will actually do this, but AFAICT this would
> > not be invalid behavior for a userspace kms consumer to do and I
> > believe it is likely that mutter will disable unused crtcs.
> >
> > IMHO it is just a bad idea to register /dev/dri/card0 with userspace
> > before the initial connector probe is done. Nothing good can come
> > of that.
> >
> > If all the exposed connectors initially are going to show up as
> > disconnected anyways what is the value in registering /dev/dri/card0
> > with userspace early ?
>
> OK. I'm still unsure how I feel about this, but I think I agree with
> you. That said, the amdgpu architecture is quite involved with multiple
> abstraction levels, so I don't think I'm equipped to write a patch to
> fix this...
>
> cc Daniel Vetter: can you confirm probing all connectors is a good thing
> to do on driver module load?

I don't think it's a big deal to change, but at least my
understanding, albeit this was back in the early KMS days, was that
probing was driven by things outside of the driver.  I.e., there is no
need to probe displays if nothing is going to use them.  If you want
to use the displays, you'd call probe first before trying to use them
so you know what is available.

Alex

>
> > >> I guess the initial modeline is inherited from the video-bios, but
> > >> what about the physical size? Note that you cannot just change the
> > >> physical size later either, that gets used to determine the hidpi
> > >> scaling factor in the bootsplash, and changing that after the initial
> > >> bootsplash dislay will also look ugly
> > >>
> > >> b) Why you need the edid for the panel-orientation property at all,
> > >> typically the edid prom is part of the panel and the panel does not
> > >> know that it is mounted e.g. upside down at all, that is a property
> > >> of the system as a whole not of the panel as a standalone unit so
> > >> in my experience getting panel-orient info is something which comes
> > >> from the firmware /video-bios not from edid ?
> > >
> > > This is an internal DRM thing. The orientation quirks logic uses the
> > > mode size advertised by the EDID.
> >
> > The DMI based quirking does, yes. But e.g. the quirk code directly
> > reading this from the Intel VBT does not rely on the mode.
> >
> > But if you are planning on using a DMI based quirk for the steamdeck
> > then yes that needs the mode.
> >
> > Thee mode check is there for 2 reasons:
> >
> > 1. To avoid also applying the quirk to external displays, but
> > I think that that is also solved in most drivers by only checking for
> > a quirk at all on the eDP connector
> >
> > 2. Some laptop models ship with different panels in different badges
> > some of these are portrait (so need a panel-orient) setting and others
> > are landscape.
>
> That makes sense. So yeah the EDID mode based matching logic needs to
> stay to accomodate for these cases.
>
> > > I agree that at least in the Steam
> > > Deck case it may not make a lot of sense to use any info from the
> > > EDID, but that's needed for the current status quo.
> >
> > We could extend the DMI quirk mechanism to allow quirks which don't
> > do the mode check, for use on devices where we can guarantee neither
> > 1 nor 2 happens, then amdgpu could call the quirk code early simply
> > passing 0x0 as resolution.
>
> Yeah. But per the above amdgpu should maybe probe connectors on module
> load. If/when amdgpu is fixed to do this, then we don't need to disable
> the mode matching logic in panel-orientation quirks anymore.

Re: [Intel-gfx] [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Alex Deucher]

On Fri, Feb 18, 2022 at 7:13 AM Simon Ser <contact@emersion.fr> wrote:
>
> On Friday, February 18th, 2022 at 12:54, Hans de Goede <hdegoede@redhat.com> wrote:
>
> > On 2/18/22 12:39, Simon Ser wrote:
> > > On Friday, February 18th, 2022 at 11:38, Hans de Goede <hdegoede@redhat.com> wrote:
> > >
> > >> What I'm reading in the above is that it is being considered to allow
> > >> changing the panel-orientation value after the connector has been made
> > >> available to userspace; and let userspace know about this through a uevent.
> > >>
> > >> I believe that this is a bad idea, it is important to keep in mind here
> > >> what userspace (e.g. plymouth) uses this prorty for. This property is
> > >> used to rotate the image being rendered / shown on the framebuffer to
> > >> adjust for the panel orientation.
> > >>
> > >> So now lets assume we apply the correct upside-down orientation later
> > >> on a device with an upside-down mounted LCD panel. Then on boot the
> > >> following could happen:
> > >>
> > >> 1. amdgpu exports a connector for the LCD panel to userspace without
> > >> setting panel-orient=upside-down
> > >> 2. plymouth sees this and renders its splash normally, but since the
> > >> panel is upside-down it will now actually show upside-down
> > >
> > > At this point amdgpu hasn't probed the connector yet. So the connector
> > > will be marked as disconnected, and plymouth shouldn't render anything.
> >
> > If before the initial probe of the connector there is a /dev/dri/card0
> > which plymouth can access, then plymouth may at this point decide
> > to disable any seemingly unused crtcs, which will make the screen go black...
> >
> > I'm not sure if plymouth will actually do this, but AFAICT this would
> > not be invalid behavior for a userspace kms consumer to do and I
> > believe it is likely that mutter will disable unused crtcs.
> >
> > IMHO it is just a bad idea to register /dev/dri/card0 with userspace
> > before the initial connector probe is done. Nothing good can come
> > of that.
> >
> > If all the exposed connectors initially are going to show up as
> > disconnected anyways what is the value in registering /dev/dri/card0
> > with userspace early ?
>
> OK. I'm still unsure how I feel about this, but I think I agree with
> you. That said, the amdgpu architecture is quite involved with multiple
> abstraction levels, so I don't think I'm equipped to write a patch to
> fix this...
>
> cc Daniel Vetter: can you confirm probing all connectors is a good thing
> to do on driver module load?

I don't think it's a big deal to change, but at least my
understanding, albeit this was back in the early KMS days, was that
probing was driven by things outside of the driver.  I.e., there is no
need to probe displays if nothing is going to use them.  If you want
to use the displays, you'd call probe first before trying to use them
so you know what is available.

Alex

>
> > >> I guess the initial modeline is inherited from the video-bios, but
> > >> what about the physical size? Note that you cannot just change the
> > >> physical size later either, that gets used to determine the hidpi
> > >> scaling factor in the bootsplash, and changing that after the initial
> > >> bootsplash dislay will also look ugly
> > >>
> > >> b) Why you need the edid for the panel-orientation property at all,
> > >> typically the edid prom is part of the panel and the panel does not
> > >> know that it is mounted e.g. upside down at all, that is a property
> > >> of the system as a whole not of the panel as a standalone unit so
> > >> in my experience getting panel-orient info is something which comes
> > >> from the firmware /video-bios not from edid ?
> > >
> > > This is an internal DRM thing. The orientation quirks logic uses the
> > > mode size advertised by the EDID.
> >
> > The DMI based quirking does, yes. But e.g. the quirk code directly
> > reading this from the Intel VBT does not rely on the mode.
> >
> > But if you are planning on using a DMI based quirk for the steamdeck
> > then yes that needs the mode.
> >
> > Thee mode check is there for 2 reasons:
> >
> > 1. To avoid also applying the quirk to external displays, but
> > I think that that is also solved in most drivers by only checking for
> > a quirk at all on the eDP connector
> >
> > 2. Some laptop models ship with different panels in different badges
> > some of these are portrait (so need a panel-orient) setting and others
> > are landscape.
>
> That makes sense. So yeah the EDID mode based matching logic needs to
> stay to accomodate for these cases.
>
> > > I agree that at least in the Steam
> > > Deck case it may not make a lot of sense to use any info from the
> > > EDID, but that's needed for the current status quo.
> >
> > We could extend the DMI quirk mechanism to allow quirks which don't
> > do the mode check, for use on devices where we can guarantee neither
> > 1 nor 2 happens, then amdgpu could call the quirk code early simply
> > passing 0x0 as resolution.
>
> Yeah. But per the above amdgpu should maybe probe connectors on module
> load. If/when amdgpu is fixed to do this, then we don't need to disable
> the mode matching logic in panel-orientation quirks anymore.

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

Re: [Intel-gfx] [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Alex Deucher]

On Fri, Feb 18, 2022 at 7:13 AM Simon Ser <contact@emersion.fr> wrote:
>
> On Friday, February 18th, 2022 at 12:54, Hans de Goede <hdegoede@redhat.com> wrote:
>
> > On 2/18/22 12:39, Simon Ser wrote:
> > > On Friday, February 18th, 2022 at 11:38, Hans de Goede <hdegoede@redhat.com> wrote:
> > >
> > >> What I'm reading in the above is that it is being considered to allow
> > >> changing the panel-orientation value after the connector has been made
> > >> available to userspace; and let userspace know about this through a uevent.
> > >>
> > >> I believe that this is a bad idea, it is important to keep in mind here
> > >> what userspace (e.g. plymouth) uses this prorty for. This property is
> > >> used to rotate the image being rendered / shown on the framebuffer to
> > >> adjust for the panel orientation.
> > >>
> > >> So now lets assume we apply the correct upside-down orientation later
> > >> on a device with an upside-down mounted LCD panel. Then on boot the
> > >> following could happen:
> > >>
> > >> 1. amdgpu exports a connector for the LCD panel to userspace without
> > >> setting panel-orient=upside-down
> > >> 2. plymouth sees this and renders its splash normally, but since the
> > >> panel is upside-down it will now actually show upside-down
> > >
> > > At this point amdgpu hasn't probed the connector yet. So the connector
> > > will be marked as disconnected, and plymouth shouldn't render anything.
> >
> > If before the initial probe of the connector there is a /dev/dri/card0
> > which plymouth can access, then plymouth may at this point decide
> > to disable any seemingly unused crtcs, which will make the screen go black...
> >
> > I'm not sure if plymouth will actually do this, but AFAICT this would
> > not be invalid behavior for a userspace kms consumer to do and I
> > believe it is likely that mutter will disable unused crtcs.
> >
> > IMHO it is just a bad idea to register /dev/dri/card0 with userspace
> > before the initial connector probe is done. Nothing good can come
> > of that.
> >
> > If all the exposed connectors initially are going to show up as
> > disconnected anyways what is the value in registering /dev/dri/card0
> > with userspace early ?
>
> OK. I'm still unsure how I feel about this, but I think I agree with
> you. That said, the amdgpu architecture is quite involved with multiple
> abstraction levels, so I don't think I'm equipped to write a patch to
> fix this...
>
> cc Daniel Vetter: can you confirm probing all connectors is a good thing
> to do on driver module load?

I don't think it's a big deal to change, but at least my
understanding, albeit this was back in the early KMS days, was that
probing was driven by things outside of the driver.  I.e., there is no
need to probe displays if nothing is going to use them.  If you want
to use the displays, you'd call probe first before trying to use them
so you know what is available.

Alex

>
> > >> I guess the initial modeline is inherited from the video-bios, but
> > >> what about the physical size? Note that you cannot just change the
> > >> physical size later either, that gets used to determine the hidpi
> > >> scaling factor in the bootsplash, and changing that after the initial
> > >> bootsplash dislay will also look ugly
> > >>
> > >> b) Why you need the edid for the panel-orientation property at all,
> > >> typically the edid prom is part of the panel and the panel does not
> > >> know that it is mounted e.g. upside down at all, that is a property
> > >> of the system as a whole not of the panel as a standalone unit so
> > >> in my experience getting panel-orient info is something which comes
> > >> from the firmware /video-bios not from edid ?
> > >
> > > This is an internal DRM thing. The orientation quirks logic uses the
> > > mode size advertised by the EDID.
> >
> > The DMI based quirking does, yes. But e.g. the quirk code directly
> > reading this from the Intel VBT does not rely on the mode.
> >
> > But if you are planning on using a DMI based quirk for the steamdeck
> > then yes that needs the mode.
> >
> > Thee mode check is there for 2 reasons:
> >
> > 1. To avoid also applying the quirk to external displays, but
> > I think that that is also solved in most drivers by only checking for
> > a quirk at all on the eDP connector
> >
> > 2. Some laptop models ship with different panels in different badges
> > some of these are portrait (so need a panel-orient) setting and others
> > are landscape.
>
> That makes sense. So yeah the EDID mode based matching logic needs to
> stay to accomodate for these cases.
>
> > > I agree that at least in the Steam
> > > Deck case it may not make a lot of sense to use any info from the
> > > EDID, but that's needed for the current status quo.
> >
> > We could extend the DMI quirk mechanism to allow quirks which don't
> > do the mode check, for use on devices where we can guarantee neither
> > 1 nor 2 happens, then amdgpu could call the quirk code early simply
> > passing 0x0 as resolution.
>
> Yeah. But per the above amdgpu should maybe probe connectors on module
> load. If/when amdgpu is fixed to do this, then we don't need to disable
> the mode matching logic in panel-orientation quirks anymore.

Re: [Intel-gfx] [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Alex Deucher]

On Fri, Feb 18, 2022 at 7:13 AM Simon Ser <contact@emersion.fr> wrote:
>
> On Friday, February 18th, 2022 at 12:54, Hans de Goede <hdegoede@redhat.com> wrote:
>
> > On 2/18/22 12:39, Simon Ser wrote:
> > > On Friday, February 18th, 2022 at 11:38, Hans de Goede <hdegoede@redhat.com> wrote:
> > >
> > >> What I'm reading in the above is that it is being considered to allow
> > >> changing the panel-orientation value after the connector has been made
> > >> available to userspace; and let userspace know about this through a uevent.
> > >>
> > >> I believe that this is a bad idea, it is important to keep in mind here
> > >> what userspace (e.g. plymouth) uses this prorty for. This property is
> > >> used to rotate the image being rendered / shown on the framebuffer to
> > >> adjust for the panel orientation.
> > >>
> > >> So now lets assume we apply the correct upside-down orientation later
> > >> on a device with an upside-down mounted LCD panel. Then on boot the
> > >> following could happen:
> > >>
> > >> 1. amdgpu exports a connector for the LCD panel to userspace without
> > >> setting panel-orient=upside-down
> > >> 2. plymouth sees this and renders its splash normally, but since the
> > >> panel is upside-down it will now actually show upside-down
> > >
> > > At this point amdgpu hasn't probed the connector yet. So the connector
> > > will be marked as disconnected, and plymouth shouldn't render anything.
> >
> > If before the initial probe of the connector there is a /dev/dri/card0
> > which plymouth can access, then plymouth may at this point decide
> > to disable any seemingly unused crtcs, which will make the screen go black...
> >
> > I'm not sure if plymouth will actually do this, but AFAICT this would
> > not be invalid behavior for a userspace kms consumer to do and I
> > believe it is likely that mutter will disable unused crtcs.
> >
> > IMHO it is just a bad idea to register /dev/dri/card0 with userspace
> > before the initial connector probe is done. Nothing good can come
> > of that.
> >
> > If all the exposed connectors initially are going to show up as
> > disconnected anyways what is the value in registering /dev/dri/card0
> > with userspace early ?
>
> OK. I'm still unsure how I feel about this, but I think I agree with
> you. That said, the amdgpu architecture is quite involved with multiple
> abstraction levels, so I don't think I'm equipped to write a patch to
> fix this...
>
> cc Daniel Vetter: can you confirm probing all connectors is a good thing
> to do on driver module load?

I don't think it's a big deal to change, but at least my
understanding, albeit this was back in the early KMS days, was that
probing was driven by things outside of the driver.  I.e., there is no
need to probe displays if nothing is going to use them.  If you want
to use the displays, you'd call probe first before trying to use them
so you know what is available.

Alex

>
> > >> I guess the initial modeline is inherited from the video-bios, but
> > >> what about the physical size? Note that you cannot just change the
> > >> physical size later either, that gets used to determine the hidpi
> > >> scaling factor in the bootsplash, and changing that after the initial
> > >> bootsplash dislay will also look ugly
> > >>
> > >> b) Why you need the edid for the panel-orientation property at all,
> > >> typically the edid prom is part of the panel and the panel does not
> > >> know that it is mounted e.g. upside down at all, that is a property
> > >> of the system as a whole not of the panel as a standalone unit so
> > >> in my experience getting panel-orient info is something which comes
> > >> from the firmware /video-bios not from edid ?
> > >
> > > This is an internal DRM thing. The orientation quirks logic uses the
> > > mode size advertised by the EDID.
> >
> > The DMI based quirking does, yes. But e.g. the quirk code directly
> > reading this from the Intel VBT does not rely on the mode.
> >
> > But if you are planning on using a DMI based quirk for the steamdeck
> > then yes that needs the mode.
> >
> > Thee mode check is there for 2 reasons:
> >
> > 1. To avoid also applying the quirk to external displays, but
> > I think that that is also solved in most drivers by only checking for
> > a quirk at all on the eDP connector
> >
> > 2. Some laptop models ship with different panels in different badges
> > some of these are portrait (so need a panel-orient) setting and others
> > are landscape.
>
> That makes sense. So yeah the EDID mode based matching logic needs to
> stay to accomodate for these cases.
>
> > > I agree that at least in the Steam
> > > Deck case it may not make a lot of sense to use any info from the
> > > EDID, but that's needed for the current status quo.
> >
> > We could extend the DMI quirk mechanism to allow quirks which don't
> > do the mode check, for use on devices where we can guarantee neither
> > 1 nor 2 happens, then amdgpu could call the quirk code early simply
> > passing 0x0 as resolution.
>
> Yeah. But per the above amdgpu should maybe probe connectors on module
> load. If/when amdgpu is fixed to do this, then we don't need to disable
> the mode matching logic in panel-orientation quirks anymore.

Re: [Intel-gfx] [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Alex Deucher]

On Fri, Feb 18, 2022 at 7:13 AM Simon Ser <contact@emersion.fr> wrote:
>
> On Friday, February 18th, 2022 at 12:54, Hans de Goede <hdegoede@redhat.com> wrote:
>
> > On 2/18/22 12:39, Simon Ser wrote:
> > > On Friday, February 18th, 2022 at 11:38, Hans de Goede <hdegoede@redhat.com> wrote:
> > >
> > >> What I'm reading in the above is that it is being considered to allow
> > >> changing the panel-orientation value after the connector has been made
> > >> available to userspace; and let userspace know about this through a uevent.
> > >>
> > >> I believe that this is a bad idea, it is important to keep in mind here
> > >> what userspace (e.g. plymouth) uses this prorty for. This property is
> > >> used to rotate the image being rendered / shown on the framebuffer to
> > >> adjust for the panel orientation.
> > >>
> > >> So now lets assume we apply the correct upside-down orientation later
> > >> on a device with an upside-down mounted LCD panel. Then on boot the
> > >> following could happen:
> > >>
> > >> 1. amdgpu exports a connector for the LCD panel to userspace without
> > >> setting panel-orient=upside-down
> > >> 2. plymouth sees this and renders its splash normally, but since the
> > >> panel is upside-down it will now actually show upside-down
> > >
> > > At this point amdgpu hasn't probed the connector yet. So the connector
> > > will be marked as disconnected, and plymouth shouldn't render anything.
> >
> > If before the initial probe of the connector there is a /dev/dri/card0
> > which plymouth can access, then plymouth may at this point decide
> > to disable any seemingly unused crtcs, which will make the screen go black...
> >
> > I'm not sure if plymouth will actually do this, but AFAICT this would
> > not be invalid behavior for a userspace kms consumer to do and I
> > believe it is likely that mutter will disable unused crtcs.
> >
> > IMHO it is just a bad idea to register /dev/dri/card0 with userspace
> > before the initial connector probe is done. Nothing good can come
> > of that.
> >
> > If all the exposed connectors initially are going to show up as
> > disconnected anyways what is the value in registering /dev/dri/card0
> > with userspace early ?
>
> OK. I'm still unsure how I feel about this, but I think I agree with
> you. That said, the amdgpu architecture is quite involved with multiple
> abstraction levels, so I don't think I'm equipped to write a patch to
> fix this...
>
> cc Daniel Vetter: can you confirm probing all connectors is a good thing
> to do on driver module load?

I don't think it's a big deal to change, but at least my
understanding, albeit this was back in the early KMS days, was that
probing was driven by things outside of the driver.  I.e., there is no
need to probe displays if nothing is going to use them.  If you want
to use the displays, you'd call probe first before trying to use them
so you know what is available.

Alex

>
> > >> I guess the initial modeline is inherited from the video-bios, but
> > >> what about the physical size? Note that you cannot just change the
> > >> physical size later either, that gets used to determine the hidpi
> > >> scaling factor in the bootsplash, and changing that after the initial
> > >> bootsplash dislay will also look ugly
> > >>
> > >> b) Why you need the edid for the panel-orientation property at all,
> > >> typically the edid prom is part of the panel and the panel does not
> > >> know that it is mounted e.g. upside down at all, that is a property
> > >> of the system as a whole not of the panel as a standalone unit so
> > >> in my experience getting panel-orient info is something which comes
> > >> from the firmware /video-bios not from edid ?
> > >
> > > This is an internal DRM thing. The orientation quirks logic uses the
> > > mode size advertised by the EDID.
> >
> > The DMI based quirking does, yes. But e.g. the quirk code directly
> > reading this from the Intel VBT does not rely on the mode.
> >
> > But if you are planning on using a DMI based quirk for the steamdeck
> > then yes that needs the mode.
> >
> > Thee mode check is there for 2 reasons:
> >
> > 1. To avoid also applying the quirk to external displays, but
> > I think that that is also solved in most drivers by only checking for
> > a quirk at all on the eDP connector
> >
> > 2. Some laptop models ship with different panels in different badges
> > some of these are portrait (so need a panel-orient) setting and others
> > are landscape.
>
> That makes sense. So yeah the EDID mode based matching logic needs to
> stay to accomodate for these cases.
>
> > > I agree that at least in the Steam
> > > Deck case it may not make a lot of sense to use any info from the
> > > EDID, but that's needed for the current status quo.
> >
> > We could extend the DMI quirk mechanism to allow quirks which don't
> > do the mode check, for use on devices where we can guarantee neither
> > 1 nor 2 happens, then amdgpu could call the quirk code early simply
> > passing 0x0 as resolution.
>
> Yeah. But per the above amdgpu should maybe probe connectors on module
> load. If/when amdgpu is fixed to do this, then we don't need to disable
> the mode matching logic in panel-orientation quirks anymore.

Re: [Intel-gfx] [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Alex Deucher]

On Fri, Feb 18, 2022 at 7:13 AM Simon Ser <contact@emersion.fr> wrote:
>
> On Friday, February 18th, 2022 at 12:54, Hans de Goede <hdegoede@redhat.com> wrote:
>
> > On 2/18/22 12:39, Simon Ser wrote:
> > > On Friday, February 18th, 2022 at 11:38, Hans de Goede <hdegoede@redhat.com> wrote:
> > >
> > >> What I'm reading in the above is that it is being considered to allow
> > >> changing the panel-orientation value after the connector has been made
> > >> available to userspace; and let userspace know about this through a uevent.
> > >>
> > >> I believe that this is a bad idea, it is important to keep in mind here
> > >> what userspace (e.g. plymouth) uses this prorty for. This property is
> > >> used to rotate the image being rendered / shown on the framebuffer to
> > >> adjust for the panel orientation.
> > >>
> > >> So now lets assume we apply the correct upside-down orientation later
> > >> on a device with an upside-down mounted LCD panel. Then on boot the
> > >> following could happen:
> > >>
> > >> 1. amdgpu exports a connector for the LCD panel to userspace without
> > >> setting panel-orient=upside-down
> > >> 2. plymouth sees this and renders its splash normally, but since the
> > >> panel is upside-down it will now actually show upside-down
> > >
> > > At this point amdgpu hasn't probed the connector yet. So the connector
> > > will be marked as disconnected, and plymouth shouldn't render anything.
> >
> > If before the initial probe of the connector there is a /dev/dri/card0
> > which plymouth can access, then plymouth may at this point decide
> > to disable any seemingly unused crtcs, which will make the screen go black...
> >
> > I'm not sure if plymouth will actually do this, but AFAICT this would
> > not be invalid behavior for a userspace kms consumer to do and I
> > believe it is likely that mutter will disable unused crtcs.
> >
> > IMHO it is just a bad idea to register /dev/dri/card0 with userspace
> > before the initial connector probe is done. Nothing good can come
> > of that.
> >
> > If all the exposed connectors initially are going to show up as
> > disconnected anyways what is the value in registering /dev/dri/card0
> > with userspace early ?
>
> OK. I'm still unsure how I feel about this, but I think I agree with
> you. That said, the amdgpu architecture is quite involved with multiple
> abstraction levels, so I don't think I'm equipped to write a patch to
> fix this...
>
> cc Daniel Vetter: can you confirm probing all connectors is a good thing
> to do on driver module load?

I don't think it's a big deal to change, but at least my
understanding, albeit this was back in the early KMS days, was that
probing was driven by things outside of the driver.  I.e., there is no
need to probe displays if nothing is going to use them.  If you want
to use the displays, you'd call probe first before trying to use them
so you know what is available.

Alex

>
> > >> I guess the initial modeline is inherited from the video-bios, but
> > >> what about the physical size? Note that you cannot just change the
> > >> physical size later either, that gets used to determine the hidpi
> > >> scaling factor in the bootsplash, and changing that after the initial
> > >> bootsplash dislay will also look ugly
> > >>
> > >> b) Why you need the edid for the panel-orientation property at all,
> > >> typically the edid prom is part of the panel and the panel does not
> > >> know that it is mounted e.g. upside down at all, that is a property
> > >> of the system as a whole not of the panel as a standalone unit so
> > >> in my experience getting panel-orient info is something which comes
> > >> from the firmware /video-bios not from edid ?
> > >
> > > This is an internal DRM thing. The orientation quirks logic uses the
> > > mode size advertised by the EDID.
> >
> > The DMI based quirking does, yes. But e.g. the quirk code directly
> > reading this from the Intel VBT does not rely on the mode.
> >
> > But if you are planning on using a DMI based quirk for the steamdeck
> > then yes that needs the mode.
> >
> > Thee mode check is there for 2 reasons:
> >
> > 1. To avoid also applying the quirk to external displays, but
> > I think that that is also solved in most drivers by only checking for
> > a quirk at all on the eDP connector
> >
> > 2. Some laptop models ship with different panels in different badges
> > some of these are portrait (so need a panel-orient) setting and others
> > are landscape.
>
> That makes sense. So yeah the EDID mode based matching logic needs to
> stay to accomodate for these cases.
>
> > > I agree that at least in the Steam
> > > Deck case it may not make a lot of sense to use any info from the
> > > EDID, but that's needed for the current status quo.
> >
> > We could extend the DMI quirk mechanism to allow quirks which don't
> > do the mode check, for use on devices where we can guarantee neither
> > 1 nor 2 happens, then amdgpu could call the quirk code early simply
> > passing 0x0 as resolution.
>
> Yeah. But per the above amdgpu should maybe probe connectors on module
> load. If/when amdgpu is fixed to do this, then we don't need to disable
> the mode matching logic in panel-orientation quirks anymore.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [Intel-gfx] [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Harry Wentland]

On 2022-02-18 07:12, Simon Ser wrote:
> On Friday, February 18th, 2022 at 12:54, Hans de Goede <hdegoede@redhat.com> wrote:
> 
>> On 2/18/22 12:39, Simon Ser wrote:
>>> On Friday, February 18th, 2022 at 11:38, Hans de Goede <hdegoede@redhat.com> wrote:
>>>
>>>> What I'm reading in the above is that it is being considered to allow
>>>> changing the panel-orientation value after the connector has been made
>>>> available to userspace; and let userspace know about this through a uevent.
>>>>
>>>> I believe that this is a bad idea, it is important to keep in mind here
>>>> what userspace (e.g. plymouth) uses this prorty for. This property is
>>>> used to rotate the image being rendered / shown on the framebuffer to
>>>> adjust for the panel orientation.
>>>>
>>>> So now lets assume we apply the correct upside-down orientation later
>>>> on a device with an upside-down mounted LCD panel. Then on boot the
>>>> following could happen:
>>>>
>>>> 1. amdgpu exports a connector for the LCD panel to userspace without
>>>> setting panel-orient=upside-down
>>>> 2. plymouth sees this and renders its splash normally, but since the
>>>> panel is upside-down it will now actually show upside-down
>>>
>>> At this point amdgpu hasn't probed the connector yet. So the connector
>>> will be marked as disconnected, and plymouth shouldn't render anything.
>>
>> If before the initial probe of the connector there is a /dev/dri/card0
>> which plymouth can access, then plymouth may at this point decide
>> to disable any seemingly unused crtcs, which will make the screen go black...
>>
>> I'm not sure if plymouth will actually do this, but AFAICT this would
>> not be invalid behavior for a userspace kms consumer to do and I
>> believe it is likely that mutter will disable unused crtcs.
>>
>> IMHO it is just a bad idea to register /dev/dri/card0 with userspace
>> before the initial connector probe is done. Nothing good can come
>> of that.
>>
>> If all the exposed connectors initially are going to show up as
>> disconnected anyways what is the value in registering /dev/dri/card0
>> with userspace early ?
> 
> OK. I'm still unsure how I feel about this, but I think I agree with
> you. That said, the amdgpu architecture is quite involved with multiple
> abstraction levels, so I don't think I'm equipped to write a patch to
> fix this...
> 

amdgpu_dm's connector registration already triggers a detection. See the
calls to dc_link_detect and amdgpu_dm_update_connector_after_detect in
amdgpu_dm_initialize_drm_device.

dc_link_detect is supposed to read the edid via
dm_helpers_read_local_edid and amdgpu_dm_update_connector_after_detect
will update the EDID on the connector via a
drm_connector_update_edid_property call.

This all happens at driver load.

I don't know why you're seeing the embedded connector as disconnected
unless the DP-MIPI bridge for some reason doesn't indicate that the panel
is connected at driver load.

Harry

> cc Daniel Vetter: can you confirm probing all connectors is a good thing
> to do on driver module load?
> 
>>>> I guess the initial modeline is inherited from the video-bios, but
>>>> what about the physical size? Note that you cannot just change the
>>>> physical size later either, that gets used to determine the hidpi
>>>> scaling factor in the bootsplash, and changing that after the initial
>>>> bootsplash dislay will also look ugly
>>>>
>>>> b) Why you need the edid for the panel-orientation property at all,
>>>> typically the edid prom is part of the panel and the panel does not
>>>> know that it is mounted e.g. upside down at all, that is a property
>>>> of the system as a whole not of the panel as a standalone unit so
>>>> in my experience getting panel-orient info is something which comes
>>>> from the firmware /video-bios not from edid ?
>>>
>>> This is an internal DRM thing. The orientation quirks logic uses the
>>> mode size advertised by the EDID.
>>
>> The DMI based quirking does, yes. But e.g. the quirk code directly
>> reading this from the Intel VBT does not rely on the mode.
>>
>> But if you are planning on using a DMI based quirk for the steamdeck
>> then yes that needs the mode.
>>
>> Thee mode check is there for 2 reasons:
>>
>> 1. To avoid also applying the quirk to external displays, but
>> I think that that is also solved in most drivers by only checking for
>> a quirk at all on the eDP connector
>>
>> 2. Some laptop models ship with different panels in different badges
>> some of these are portrait (so need a panel-orient) setting and others
>> are landscape.
> 
> That makes sense. So yeah the EDID mode based matching logic needs to
> stay to accomodate for these cases.
> 
>>> I agree that at least in the Steam
>>> Deck case it may not make a lot of sense to use any info from the
>>> EDID, but that's needed for the current status quo.
>>
>> We could extend the DMI quirk mechanism to allow quirks which don't
>> do the mode check, for use on devices where we can guarantee neither
>> 1 nor 2 happens, then amdgpu could call the quirk code early simply
>> passing 0x0 as resolution.
> 
> Yeah. But per the above amdgpu should maybe probe connectors on module
> load. If/when amdgpu is fixed to do this, then we don't need to disable
> the mode matching logic in panel-orientation quirks anymore.

Re: [Intel-gfx] [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Harry Wentland]

On 2022-02-18 07:12, Simon Ser wrote:
> On Friday, February 18th, 2022 at 12:54, Hans de Goede <hdegoede@redhat.com> wrote:
> 
>> On 2/18/22 12:39, Simon Ser wrote:
>>> On Friday, February 18th, 2022 at 11:38, Hans de Goede <hdegoede@redhat.com> wrote:
>>>
>>>> What I'm reading in the above is that it is being considered to allow
>>>> changing the panel-orientation value after the connector has been made
>>>> available to userspace; and let userspace know about this through a uevent.
>>>>
>>>> I believe that this is a bad idea, it is important to keep in mind here
>>>> what userspace (e.g. plymouth) uses this prorty for. This property is
>>>> used to rotate the image being rendered / shown on the framebuffer to
>>>> adjust for the panel orientation.
>>>>
>>>> So now lets assume we apply the correct upside-down orientation later
>>>> on a device with an upside-down mounted LCD panel. Then on boot the
>>>> following could happen:
>>>>
>>>> 1. amdgpu exports a connector for the LCD panel to userspace without
>>>> setting panel-orient=upside-down
>>>> 2. plymouth sees this and renders its splash normally, but since the
>>>> panel is upside-down it will now actually show upside-down
>>>
>>> At this point amdgpu hasn't probed the connector yet. So the connector
>>> will be marked as disconnected, and plymouth shouldn't render anything.
>>
>> If before the initial probe of the connector there is a /dev/dri/card0
>> which plymouth can access, then plymouth may at this point decide
>> to disable any seemingly unused crtcs, which will make the screen go black...
>>
>> I'm not sure if plymouth will actually do this, but AFAICT this would
>> not be invalid behavior for a userspace kms consumer to do and I
>> believe it is likely that mutter will disable unused crtcs.
>>
>> IMHO it is just a bad idea to register /dev/dri/card0 with userspace
>> before the initial connector probe is done. Nothing good can come
>> of that.
>>
>> If all the exposed connectors initially are going to show up as
>> disconnected anyways what is the value in registering /dev/dri/card0
>> with userspace early ?
> 
> OK. I'm still unsure how I feel about this, but I think I agree with
> you. That said, the amdgpu architecture is quite involved with multiple
> abstraction levels, so I don't think I'm equipped to write a patch to
> fix this...
> 

amdgpu_dm's connector registration already triggers a detection. See the
calls to dc_link_detect and amdgpu_dm_update_connector_after_detect in
amdgpu_dm_initialize_drm_device.

dc_link_detect is supposed to read the edid via
dm_helpers_read_local_edid and amdgpu_dm_update_connector_after_detect
will update the EDID on the connector via a
drm_connector_update_edid_property call.

This all happens at driver load.

I don't know why you're seeing the embedded connector as disconnected
unless the DP-MIPI bridge for some reason doesn't indicate that the panel
is connected at driver load.

Harry

> cc Daniel Vetter: can you confirm probing all connectors is a good thing
> to do on driver module load?
> 
>>>> I guess the initial modeline is inherited from the video-bios, but
>>>> what about the physical size? Note that you cannot just change the
>>>> physical size later either, that gets used to determine the hidpi
>>>> scaling factor in the bootsplash, and changing that after the initial
>>>> bootsplash dislay will also look ugly
>>>>
>>>> b) Why you need the edid for the panel-orientation property at all,
>>>> typically the edid prom is part of the panel and the panel does not
>>>> know that it is mounted e.g. upside down at all, that is a property
>>>> of the system as a whole not of the panel as a standalone unit so
>>>> in my experience getting panel-orient info is something which comes
>>>> from the firmware /video-bios not from edid ?
>>>
>>> This is an internal DRM thing. The orientation quirks logic uses the
>>> mode size advertised by the EDID.
>>
>> The DMI based quirking does, yes. But e.g. the quirk code directly
>> reading this from the Intel VBT does not rely on the mode.
>>
>> But if you are planning on using a DMI based quirk for the steamdeck
>> then yes that needs the mode.
>>
>> Thee mode check is there for 2 reasons:
>>
>> 1. To avoid also applying the quirk to external displays, but
>> I think that that is also solved in most drivers by only checking for
>> a quirk at all on the eDP connector
>>
>> 2. Some laptop models ship with different panels in different badges
>> some of these are portrait (so need a panel-orient) setting and others
>> are landscape.
> 
> That makes sense. So yeah the EDID mode based matching logic needs to
> stay to accomodate for these cases.
> 
>>> I agree that at least in the Steam
>>> Deck case it may not make a lot of sense to use any info from the
>>> EDID, but that's needed for the current status quo.
>>
>> We could extend the DMI quirk mechanism to allow quirks which don't
>> do the mode check, for use on devices where we can guarantee neither
>> 1 nor 2 happens, then amdgpu could call the quirk code early simply
>> passing 0x0 as resolution.
> 
> Yeah. But per the above amdgpu should maybe probe connectors on module
> load. If/when amdgpu is fixed to do this, then we don't need to disable
> the mode matching logic in panel-orientation quirks anymore.


_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

Re: [Intel-gfx] [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Harry Wentland]

On 2022-02-18 07:12, Simon Ser wrote:
> On Friday, February 18th, 2022 at 12:54, Hans de Goede <hdegoede@redhat.com> wrote:
> 
>> On 2/18/22 12:39, Simon Ser wrote:
>>> On Friday, February 18th, 2022 at 11:38, Hans de Goede <hdegoede@redhat.com> wrote:
>>>
>>>> What I'm reading in the above is that it is being considered to allow
>>>> changing the panel-orientation value after the connector has been made
>>>> available to userspace; and let userspace know about this through a uevent.
>>>>
>>>> I believe that this is a bad idea, it is important to keep in mind here
>>>> what userspace (e.g. plymouth) uses this prorty for. This property is
>>>> used to rotate the image being rendered / shown on the framebuffer to
>>>> adjust for the panel orientation.
>>>>
>>>> So now lets assume we apply the correct upside-down orientation later
>>>> on a device with an upside-down mounted LCD panel. Then on boot the
>>>> following could happen:
>>>>
>>>> 1. amdgpu exports a connector for the LCD panel to userspace without
>>>> setting panel-orient=upside-down
>>>> 2. plymouth sees this and renders its splash normally, but since the
>>>> panel is upside-down it will now actually show upside-down
>>>
>>> At this point amdgpu hasn't probed the connector yet. So the connector
>>> will be marked as disconnected, and plymouth shouldn't render anything.
>>
>> If before the initial probe of the connector there is a /dev/dri/card0
>> which plymouth can access, then plymouth may at this point decide
>> to disable any seemingly unused crtcs, which will make the screen go black...
>>
>> I'm not sure if plymouth will actually do this, but AFAICT this would
>> not be invalid behavior for a userspace kms consumer to do and I
>> believe it is likely that mutter will disable unused crtcs.
>>
>> IMHO it is just a bad idea to register /dev/dri/card0 with userspace
>> before the initial connector probe is done. Nothing good can come
>> of that.
>>
>> If all the exposed connectors initially are going to show up as
>> disconnected anyways what is the value in registering /dev/dri/card0
>> with userspace early ?
> 
> OK. I'm still unsure how I feel about this, but I think I agree with
> you. That said, the amdgpu architecture is quite involved with multiple
> abstraction levels, so I don't think I'm equipped to write a patch to
> fix this...
> 

amdgpu_dm's connector registration already triggers a detection. See the
calls to dc_link_detect and amdgpu_dm_update_connector_after_detect in
amdgpu_dm_initialize_drm_device.

dc_link_detect is supposed to read the edid via
dm_helpers_read_local_edid and amdgpu_dm_update_connector_after_detect
will update the EDID on the connector via a
drm_connector_update_edid_property call.

This all happens at driver load.

I don't know why you're seeing the embedded connector as disconnected
unless the DP-MIPI bridge for some reason doesn't indicate that the panel
is connected at driver load.

Harry

> cc Daniel Vetter: can you confirm probing all connectors is a good thing
> to do on driver module load?
> 
>>>> I guess the initial modeline is inherited from the video-bios, but
>>>> what about the physical size? Note that you cannot just change the
>>>> physical size later either, that gets used to determine the hidpi
>>>> scaling factor in the bootsplash, and changing that after the initial
>>>> bootsplash dislay will also look ugly
>>>>
>>>> b) Why you need the edid for the panel-orientation property at all,
>>>> typically the edid prom is part of the panel and the panel does not
>>>> know that it is mounted e.g. upside down at all, that is a property
>>>> of the system as a whole not of the panel as a standalone unit so
>>>> in my experience getting panel-orient info is something which comes
>>>> from the firmware /video-bios not from edid ?
>>>
>>> This is an internal DRM thing. The orientation quirks logic uses the
>>> mode size advertised by the EDID.
>>
>> The DMI based quirking does, yes. But e.g. the quirk code directly
>> reading this from the Intel VBT does not rely on the mode.
>>
>> But if you are planning on using a DMI based quirk for the steamdeck
>> then yes that needs the mode.
>>
>> Thee mode check is there for 2 reasons:
>>
>> 1. To avoid also applying the quirk to external displays, but
>> I think that that is also solved in most drivers by only checking for
>> a quirk at all on the eDP connector
>>
>> 2. Some laptop models ship with different panels in different badges
>> some of these are portrait (so need a panel-orient) setting and others
>> are landscape.
> 
> That makes sense. So yeah the EDID mode based matching logic needs to
> stay to accomodate for these cases.
> 
>>> I agree that at least in the Steam
>>> Deck case it may not make a lot of sense to use any info from the
>>> EDID, but that's needed for the current status quo.
>>
>> We could extend the DMI quirk mechanism to allow quirks which don't
>> do the mode check, for use on devices where we can guarantee neither
>> 1 nor 2 happens, then amdgpu could call the quirk code early simply
>> passing 0x0 as resolution.
> 
> Yeah. But per the above amdgpu should maybe probe connectors on module
> load. If/when amdgpu is fixed to do this, then we don't need to disable
> the mode matching logic in panel-orientation quirks anymore.

Re: [Intel-gfx] [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Harry Wentland]

On 2022-02-18 07:12, Simon Ser wrote:
> On Friday, February 18th, 2022 at 12:54, Hans de Goede <hdegoede@redhat.com> wrote:
> 
>> On 2/18/22 12:39, Simon Ser wrote:
>>> On Friday, February 18th, 2022 at 11:38, Hans de Goede <hdegoede@redhat.com> wrote:
>>>
>>>> What I'm reading in the above is that it is being considered to allow
>>>> changing the panel-orientation value after the connector has been made
>>>> available to userspace; and let userspace know about this through a uevent.
>>>>
>>>> I believe that this is a bad idea, it is important to keep in mind here
>>>> what userspace (e.g. plymouth) uses this prorty for. This property is
>>>> used to rotate the image being rendered / shown on the framebuffer to
>>>> adjust for the panel orientation.
>>>>
>>>> So now lets assume we apply the correct upside-down orientation later
>>>> on a device with an upside-down mounted LCD panel. Then on boot the
>>>> following could happen:
>>>>
>>>> 1. amdgpu exports a connector for the LCD panel to userspace without
>>>> setting panel-orient=upside-down
>>>> 2. plymouth sees this and renders its splash normally, but since the
>>>> panel is upside-down it will now actually show upside-down
>>>
>>> At this point amdgpu hasn't probed the connector yet. So the connector
>>> will be marked as disconnected, and plymouth shouldn't render anything.
>>
>> If before the initial probe of the connector there is a /dev/dri/card0
>> which plymouth can access, then plymouth may at this point decide
>> to disable any seemingly unused crtcs, which will make the screen go black...
>>
>> I'm not sure if plymouth will actually do this, but AFAICT this would
>> not be invalid behavior for a userspace kms consumer to do and I
>> believe it is likely that mutter will disable unused crtcs.
>>
>> IMHO it is just a bad idea to register /dev/dri/card0 with userspace
>> before the initial connector probe is done. Nothing good can come
>> of that.
>>
>> If all the exposed connectors initially are going to show up as
>> disconnected anyways what is the value in registering /dev/dri/card0
>> with userspace early ?
> 
> OK. I'm still unsure how I feel about this, but I think I agree with
> you. That said, the amdgpu architecture is quite involved with multiple
> abstraction levels, so I don't think I'm equipped to write a patch to
> fix this...
> 

amdgpu_dm's connector registration already triggers a detection. See the
calls to dc_link_detect and amdgpu_dm_update_connector_after_detect in
amdgpu_dm_initialize_drm_device.

dc_link_detect is supposed to read the edid via
dm_helpers_read_local_edid and amdgpu_dm_update_connector_after_detect
will update the EDID on the connector via a
drm_connector_update_edid_property call.

This all happens at driver load.

I don't know why you're seeing the embedded connector as disconnected
unless the DP-MIPI bridge for some reason doesn't indicate that the panel
is connected at driver load.

Harry

> cc Daniel Vetter: can you confirm probing all connectors is a good thing
> to do on driver module load?
> 
>>>> I guess the initial modeline is inherited from the video-bios, but
>>>> what about the physical size? Note that you cannot just change the
>>>> physical size later either, that gets used to determine the hidpi
>>>> scaling factor in the bootsplash, and changing that after the initial
>>>> bootsplash dislay will also look ugly
>>>>
>>>> b) Why you need the edid for the panel-orientation property at all,
>>>> typically the edid prom is part of the panel and the panel does not
>>>> know that it is mounted e.g. upside down at all, that is a property
>>>> of the system as a whole not of the panel as a standalone unit so
>>>> in my experience getting panel-orient info is something which comes
>>>> from the firmware /video-bios not from edid ?
>>>
>>> This is an internal DRM thing. The orientation quirks logic uses the
>>> mode size advertised by the EDID.
>>
>> The DMI based quirking does, yes. But e.g. the quirk code directly
>> reading this from the Intel VBT does not rely on the mode.
>>
>> But if you are planning on using a DMI based quirk for the steamdeck
>> then yes that needs the mode.
>>
>> Thee mode check is there for 2 reasons:
>>
>> 1. To avoid also applying the quirk to external displays, but
>> I think that that is also solved in most drivers by only checking for
>> a quirk at all on the eDP connector
>>
>> 2. Some laptop models ship with different panels in different badges
>> some of these are portrait (so need a panel-orient) setting and others
>> are landscape.
> 
> That makes sense. So yeah the EDID mode based matching logic needs to
> stay to accomodate for these cases.
> 
>>> I agree that at least in the Steam
>>> Deck case it may not make a lot of sense to use any info from the
>>> EDID, but that's needed for the current status quo.
>>
>> We could extend the DMI quirk mechanism to allow quirks which don't
>> do the mode check, for use on devices where we can guarantee neither
>> 1 nor 2 happens, then amdgpu could call the quirk code early simply
>> passing 0x0 as resolution.
> 
> Yeah. But per the above amdgpu should maybe probe connectors on module
> load. If/when amdgpu is fixed to do this, then we don't need to disable
> the mode matching logic in panel-orientation quirks anymore.

Re: [Intel-gfx] [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Harry Wentland]

On 2022-02-18 07:12, Simon Ser wrote:
> On Friday, February 18th, 2022 at 12:54, Hans de Goede <hdegoede@redhat.com> wrote:
> 
>> On 2/18/22 12:39, Simon Ser wrote:
>>> On Friday, February 18th, 2022 at 11:38, Hans de Goede <hdegoede@redhat.com> wrote:
>>>
>>>> What I'm reading in the above is that it is being considered to allow
>>>> changing the panel-orientation value after the connector has been made
>>>> available to userspace; and let userspace know about this through a uevent.
>>>>
>>>> I believe that this is a bad idea, it is important to keep in mind here
>>>> what userspace (e.g. plymouth) uses this prorty for. This property is
>>>> used to rotate the image being rendered / shown on the framebuffer to
>>>> adjust for the panel orientation.
>>>>
>>>> So now lets assume we apply the correct upside-down orientation later
>>>> on a device with an upside-down mounted LCD panel. Then on boot the
>>>> following could happen:
>>>>
>>>> 1. amdgpu exports a connector for the LCD panel to userspace without
>>>> setting panel-orient=upside-down
>>>> 2. plymouth sees this and renders its splash normally, but since the
>>>> panel is upside-down it will now actually show upside-down
>>>
>>> At this point amdgpu hasn't probed the connector yet. So the connector
>>> will be marked as disconnected, and plymouth shouldn't render anything.
>>
>> If before the initial probe of the connector there is a /dev/dri/card0
>> which plymouth can access, then plymouth may at this point decide
>> to disable any seemingly unused crtcs, which will make the screen go black...
>>
>> I'm not sure if plymouth will actually do this, but AFAICT this would
>> not be invalid behavior for a userspace kms consumer to do and I
>> believe it is likely that mutter will disable unused crtcs.
>>
>> IMHO it is just a bad idea to register /dev/dri/card0 with userspace
>> before the initial connector probe is done. Nothing good can come
>> of that.
>>
>> If all the exposed connectors initially are going to show up as
>> disconnected anyways what is the value in registering /dev/dri/card0
>> with userspace early ?
> 
> OK. I'm still unsure how I feel about this, but I think I agree with
> you. That said, the amdgpu architecture is quite involved with multiple
> abstraction levels, so I don't think I'm equipped to write a patch to
> fix this...
> 

amdgpu_dm's connector registration already triggers a detection. See the
calls to dc_link_detect and amdgpu_dm_update_connector_after_detect in
amdgpu_dm_initialize_drm_device.

dc_link_detect is supposed to read the edid via
dm_helpers_read_local_edid and amdgpu_dm_update_connector_after_detect
will update the EDID on the connector via a
drm_connector_update_edid_property call.

This all happens at driver load.

I don't know why you're seeing the embedded connector as disconnected
unless the DP-MIPI bridge for some reason doesn't indicate that the panel
is connected at driver load.

Harry

> cc Daniel Vetter: can you confirm probing all connectors is a good thing
> to do on driver module load?
> 
>>>> I guess the initial modeline is inherited from the video-bios, but
>>>> what about the physical size? Note that you cannot just change the
>>>> physical size later either, that gets used to determine the hidpi
>>>> scaling factor in the bootsplash, and changing that after the initial
>>>> bootsplash dislay will also look ugly
>>>>
>>>> b) Why you need the edid for the panel-orientation property at all,
>>>> typically the edid prom is part of the panel and the panel does not
>>>> know that it is mounted e.g. upside down at all, that is a property
>>>> of the system as a whole not of the panel as a standalone unit so
>>>> in my experience getting panel-orient info is something which comes
>>>> from the firmware /video-bios not from edid ?
>>>
>>> This is an internal DRM thing. The orientation quirks logic uses the
>>> mode size advertised by the EDID.
>>
>> The DMI based quirking does, yes. But e.g. the quirk code directly
>> reading this from the Intel VBT does not rely on the mode.
>>
>> But if you are planning on using a DMI based quirk for the steamdeck
>> then yes that needs the mode.
>>
>> Thee mode check is there for 2 reasons:
>>
>> 1. To avoid also applying the quirk to external displays, but
>> I think that that is also solved in most drivers by only checking for
>> a quirk at all on the eDP connector
>>
>> 2. Some laptop models ship with different panels in different badges
>> some of these are portrait (so need a panel-orient) setting and others
>> are landscape.
> 
> That makes sense. So yeah the EDID mode based matching logic needs to
> stay to accomodate for these cases.
> 
>>> I agree that at least in the Steam
>>> Deck case it may not make a lot of sense to use any info from the
>>> EDID, but that's needed for the current status quo.
>>
>> We could extend the DMI quirk mechanism to allow quirks which don't
>> do the mode check, for use on devices where we can guarantee neither
>> 1 nor 2 happens, then amdgpu could call the quirk code early simply
>> passing 0x0 as resolution.
> 
> Yeah. But per the above amdgpu should maybe probe connectors on module
> load. If/when amdgpu is fixed to do this, then we don't need to disable
> the mode matching logic in panel-orientation quirks anymore.

Re: [Intel-gfx] [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Harry Wentland]

On 2022-02-18 07:12, Simon Ser wrote:
> On Friday, February 18th, 2022 at 12:54, Hans de Goede <hdegoede@redhat.com> wrote:
> 
>> On 2/18/22 12:39, Simon Ser wrote:
>>> On Friday, February 18th, 2022 at 11:38, Hans de Goede <hdegoede@redhat.com> wrote:
>>>
>>>> What I'm reading in the above is that it is being considered to allow
>>>> changing the panel-orientation value after the connector has been made
>>>> available to userspace; and let userspace know about this through a uevent.
>>>>
>>>> I believe that this is a bad idea, it is important to keep in mind here
>>>> what userspace (e.g. plymouth) uses this prorty for. This property is
>>>> used to rotate the image being rendered / shown on the framebuffer to
>>>> adjust for the panel orientation.
>>>>
>>>> So now lets assume we apply the correct upside-down orientation later
>>>> on a device with an upside-down mounted LCD panel. Then on boot the
>>>> following could happen:
>>>>
>>>> 1. amdgpu exports a connector for the LCD panel to userspace without
>>>> setting panel-orient=upside-down
>>>> 2. plymouth sees this and renders its splash normally, but since the
>>>> panel is upside-down it will now actually show upside-down
>>>
>>> At this point amdgpu hasn't probed the connector yet. So the connector
>>> will be marked as disconnected, and plymouth shouldn't render anything.
>>
>> If before the initial probe of the connector there is a /dev/dri/card0
>> which plymouth can access, then plymouth may at this point decide
>> to disable any seemingly unused crtcs, which will make the screen go black...
>>
>> I'm not sure if plymouth will actually do this, but AFAICT this would
>> not be invalid behavior for a userspace kms consumer to do and I
>> believe it is likely that mutter will disable unused crtcs.
>>
>> IMHO it is just a bad idea to register /dev/dri/card0 with userspace
>> before the initial connector probe is done. Nothing good can come
>> of that.
>>
>> If all the exposed connectors initially are going to show up as
>> disconnected anyways what is the value in registering /dev/dri/card0
>> with userspace early ?
> 
> OK. I'm still unsure how I feel about this, but I think I agree with
> you. That said, the amdgpu architecture is quite involved with multiple
> abstraction levels, so I don't think I'm equipped to write a patch to
> fix this...
> 

amdgpu_dm's connector registration already triggers a detection. See the
calls to dc_link_detect and amdgpu_dm_update_connector_after_detect in
amdgpu_dm_initialize_drm_device.

dc_link_detect is supposed to read the edid via
dm_helpers_read_local_edid and amdgpu_dm_update_connector_after_detect
will update the EDID on the connector via a
drm_connector_update_edid_property call.

This all happens at driver load.

I don't know why you're seeing the embedded connector as disconnected
unless the DP-MIPI bridge for some reason doesn't indicate that the panel
is connected at driver load.

Harry

> cc Daniel Vetter: can you confirm probing all connectors is a good thing
> to do on driver module load?
> 
>>>> I guess the initial modeline is inherited from the video-bios, but
>>>> what about the physical size? Note that you cannot just change the
>>>> physical size later either, that gets used to determine the hidpi
>>>> scaling factor in the bootsplash, and changing that after the initial
>>>> bootsplash dislay will also look ugly
>>>>
>>>> b) Why you need the edid for the panel-orientation property at all,
>>>> typically the edid prom is part of the panel and the panel does not
>>>> know that it is mounted e.g. upside down at all, that is a property
>>>> of the system as a whole not of the panel as a standalone unit so
>>>> in my experience getting panel-orient info is something which comes
>>>> from the firmware /video-bios not from edid ?
>>>
>>> This is an internal DRM thing. The orientation quirks logic uses the
>>> mode size advertised by the EDID.
>>
>> The DMI based quirking does, yes. But e.g. the quirk code directly
>> reading this from the Intel VBT does not rely on the mode.
>>
>> But if you are planning on using a DMI based quirk for the steamdeck
>> then yes that needs the mode.
>>
>> Thee mode check is there for 2 reasons:
>>
>> 1. To avoid also applying the quirk to external displays, but
>> I think that that is also solved in most drivers by only checking for
>> a quirk at all on the eDP connector
>>
>> 2. Some laptop models ship with different panels in different badges
>> some of these are portrait (so need a panel-orient) setting and others
>> are landscape.
> 
> That makes sense. So yeah the EDID mode based matching logic needs to
> stay to accomodate for these cases.
> 
>>> I agree that at least in the Steam
>>> Deck case it may not make a lot of sense to use any info from the
>>> EDID, but that's needed for the current status quo.
>>
>> We could extend the DMI quirk mechanism to allow quirks which don't
>> do the mode check, for use on devices where we can guarantee neither
>> 1 nor 2 happens, then amdgpu could call the quirk code early simply
>> passing 0x0 as resolution.
> 
> Yeah. But per the above amdgpu should maybe probe connectors on module
> load. If/when amdgpu is fixed to do this, then we don't need to disable
> the mode matching logic in panel-orientation quirks anymore.


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [Intel-gfx] [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Hsin-Yi Wang]

On Fri, Feb 18, 2022 at 11:57 PM Harry Wentland <harry.wentland@amd.com> wrote:
>
> On 2022-02-18 07:12, Simon Ser wrote:
> > On Friday, February 18th, 2022 at 12:54, Hans de Goede <hdegoede@redhat.com> wrote:
> >
> >> On 2/18/22 12:39, Simon Ser wrote:
> >>> On Friday, February 18th, 2022 at 11:38, Hans de Goede <hdegoede@redhat.com> wrote:
> >>>
> >>>> What I'm reading in the above is that it is being considered to allow
> >>>> changing the panel-orientation value after the connector has been made
> >>>> available to userspace; and let userspace know about this through a uevent.
> >>>>
> >>>> I believe that this is a bad idea, it is important to keep in mind here
> >>>> what userspace (e.g. plymouth) uses this prorty for. This property is
> >>>> used to rotate the image being rendered / shown on the framebuffer to
> >>>> adjust for the panel orientation.
> >>>>
> >>>> So now lets assume we apply the correct upside-down orientation later
> >>>> on a device with an upside-down mounted LCD panel. Then on boot the
> >>>> following could happen:
> >>>>
> >>>> 1. amdgpu exports a connector for the LCD panel to userspace without
> >>>> setting panel-orient=upside-down
> >>>> 2. plymouth sees this and renders its splash normally, but since the
> >>>> panel is upside-down it will now actually show upside-down
> >>>
> >>> At this point amdgpu hasn't probed the connector yet. So the connector
> >>> will be marked as disconnected, and plymouth shouldn't render anything.
> >>
> >> If before the initial probe of the connector there is a /dev/dri/card0
> >> which plymouth can access, then plymouth may at this point decide
> >> to disable any seemingly unused crtcs, which will make the screen go black...
> >>
> >> I'm not sure if plymouth will actually do this, but AFAICT this would
> >> not be invalid behavior for a userspace kms consumer to do and I
> >> believe it is likely that mutter will disable unused crtcs.
> >>
> >> IMHO it is just a bad idea to register /dev/dri/card0 with userspace
> >> before the initial connector probe is done. Nothing good can come
> >> of that.
> >>
> >> If all the exposed connectors initially are going to show up as
> >> disconnected anyways what is the value in registering /dev/dri/card0
> >> with userspace early ?
> >
> > OK. I'm still unsure how I feel about this, but I think I agree with
> > you. That said, the amdgpu architecture is quite involved with multiple
> > abstraction levels, so I don't think I'm equipped to write a patch to
> > fix this...
> >
>
> amdgpu_dm's connector registration already triggers a detection. See the
> calls to dc_link_detect and amdgpu_dm_update_connector_after_detect in
> amdgpu_dm_initialize_drm_device.
>
> dc_link_detect is supposed to read the edid via
> dm_helpers_read_local_edid and amdgpu_dm_update_connector_after_detect
> will update the EDID on the connector via a
> drm_connector_update_edid_property call.
>
> This all happens at driver load.
>
> I don't know why you're seeing the embedded connector as disconnected
> unless the DP-MIPI bridge for some reason doesn't indicate that the panel
> is connected at driver load.
>
> Harry
>
> > cc Daniel Vetter: can you confirm probing all connectors is a good thing
> > to do on driver module load?
> >
> >>>> I guess the initial modeline is inherited from the video-bios, but
> >>>> what about the physical size? Note that you cannot just change the
> >>>> physical size later either, that gets used to determine the hidpi
> >>>> scaling factor in the bootsplash, and changing that after the initial
> >>>> bootsplash dislay will also look ugly
> >>>>
> >>>> b) Why you need the edid for the panel-orientation property at all,
> >>>> typically the edid prom is part of the panel and the panel does not
> >>>> know that it is mounted e.g. upside down at all, that is a property
> >>>> of the system as a whole not of the panel as a standalone unit so
> >>>> in my experience getting panel-orient info is something which comes
> >>>> from the firmware /video-bios not from edid ?
> >>>
> >>> This is an internal DRM thing. The orientation quirks logic uses the
> >>> mode size advertised by the EDID.
> >>
> >> The DMI based quirking does, yes. But e.g. the quirk code directly
> >> reading this from the Intel VBT does not rely on the mode.
> >>
> >> But if you are planning on using a DMI based quirk for the steamdeck
> >> then yes that needs the mode.
> >>
> >> Thee mode check is there for 2 reasons:
> >>
> >> 1. To avoid also applying the quirk to external displays, but
> >> I think that that is also solved in most drivers by only checking for
> >> a quirk at all on the eDP connector
> >>
> >> 2. Some laptop models ship with different panels in different badges
> >> some of these are portrait (so need a panel-orient) setting and others
> >> are landscape.
> >
> > That makes sense. So yeah the EDID mode based matching logic needs to
> > stay to accomodate for these cases.
> >
> >>> I agree that at least in the Steam
> >>> Deck case it may not make a lot of sense to use any info from the
> >>> EDID, but that's needed for the current status quo.
> >>
> >> We could extend the DMI quirk mechanism to allow quirks which don't
> >> do the mode check, for use on devices where we can guarantee neither
> >> 1 nor 2 happens, then amdgpu could call the quirk code early simply
> >> passing 0x0 as resolution.
> >
> > Yeah. But per the above amdgpu should maybe probe connectors on module
> > load. If/when amdgpu is fixed to do this, then we don't need to disable
> > the mode matching logic in panel-orientation quirks anymore.
>

Hi all,

Thanks for all of the discussion. I'm not sure about how amd drm
works, but for some SoC, the panel orientation is set in panel[1].
The goal of this patch is to separate the property creation, so some
drm can optionally create it earlier before drm_dev_register().

I've sent the v9 to address some issues in v8, but the basic idea is
still the same. It has no effect to
drm_connector_set_panel_orientation_with_quirk() used in amdgpu and
i915, they work the same as before. Do you think this is reasonable?

[1]  https://elixir.bootlin.com/linux/v5.17-rc7/source/drivers/gpu/drm/panel/panel-edp.c#L556

Re: [Intel-gfx] [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Hsin-Yi Wang]

On Fri, Feb 18, 2022 at 11:57 PM Harry Wentland <harry.wentland@amd.com> wrote:
>
> On 2022-02-18 07:12, Simon Ser wrote:
> > On Friday, February 18th, 2022 at 12:54, Hans de Goede <hdegoede@redhat.com> wrote:
> >
> >> On 2/18/22 12:39, Simon Ser wrote:
> >>> On Friday, February 18th, 2022 at 11:38, Hans de Goede <hdegoede@redhat.com> wrote:
> >>>
> >>>> What I'm reading in the above is that it is being considered to allow
> >>>> changing the panel-orientation value after the connector has been made
> >>>> available to userspace; and let userspace know about this through a uevent.
> >>>>
> >>>> I believe that this is a bad idea, it is important to keep in mind here
> >>>> what userspace (e.g. plymouth) uses this prorty for. This property is
> >>>> used to rotate the image being rendered / shown on the framebuffer to
> >>>> adjust for the panel orientation.
> >>>>
> >>>> So now lets assume we apply the correct upside-down orientation later
> >>>> on a device with an upside-down mounted LCD panel. Then on boot the
> >>>> following could happen:
> >>>>
> >>>> 1. amdgpu exports a connector for the LCD panel to userspace without
> >>>> setting panel-orient=upside-down
> >>>> 2. plymouth sees this and renders its splash normally, but since the
> >>>> panel is upside-down it will now actually show upside-down
> >>>
> >>> At this point amdgpu hasn't probed the connector yet. So the connector
> >>> will be marked as disconnected, and plymouth shouldn't render anything.
> >>
> >> If before the initial probe of the connector there is a /dev/dri/card0
> >> which plymouth can access, then plymouth may at this point decide
> >> to disable any seemingly unused crtcs, which will make the screen go black...
> >>
> >> I'm not sure if plymouth will actually do this, but AFAICT this would
> >> not be invalid behavior for a userspace kms consumer to do and I
> >> believe it is likely that mutter will disable unused crtcs.
> >>
> >> IMHO it is just a bad idea to register /dev/dri/card0 with userspace
> >> before the initial connector probe is done. Nothing good can come
> >> of that.
> >>
> >> If all the exposed connectors initially are going to show up as
> >> disconnected anyways what is the value in registering /dev/dri/card0
> >> with userspace early ?
> >
> > OK. I'm still unsure how I feel about this, but I think I agree with
> > you. That said, the amdgpu architecture is quite involved with multiple
> > abstraction levels, so I don't think I'm equipped to write a patch to
> > fix this...
> >
>
> amdgpu_dm's connector registration already triggers a detection. See the
> calls to dc_link_detect and amdgpu_dm_update_connector_after_detect in
> amdgpu_dm_initialize_drm_device.
>
> dc_link_detect is supposed to read the edid via
> dm_helpers_read_local_edid and amdgpu_dm_update_connector_after_detect
> will update the EDID on the connector via a
> drm_connector_update_edid_property call.
>
> This all happens at driver load.
>
> I don't know why you're seeing the embedded connector as disconnected
> unless the DP-MIPI bridge for some reason doesn't indicate that the panel
> is connected at driver load.
>
> Harry
>
> > cc Daniel Vetter: can you confirm probing all connectors is a good thing
> > to do on driver module load?
> >
> >>>> I guess the initial modeline is inherited from the video-bios, but
> >>>> what about the physical size? Note that you cannot just change the
> >>>> physical size later either, that gets used to determine the hidpi
> >>>> scaling factor in the bootsplash, and changing that after the initial
> >>>> bootsplash dislay will also look ugly
> >>>>
> >>>> b) Why you need the edid for the panel-orientation property at all,
> >>>> typically the edid prom is part of the panel and the panel does not
> >>>> know that it is mounted e.g. upside down at all, that is a property
> >>>> of the system as a whole not of the panel as a standalone unit so
> >>>> in my experience getting panel-orient info is something which comes
> >>>> from the firmware /video-bios not from edid ?
> >>>
> >>> This is an internal DRM thing. The orientation quirks logic uses the
> >>> mode size advertised by the EDID.
> >>
> >> The DMI based quirking does, yes. But e.g. the quirk code directly
> >> reading this from the Intel VBT does not rely on the mode.
> >>
> >> But if you are planning on using a DMI based quirk for the steamdeck
> >> then yes that needs the mode.
> >>
> >> Thee mode check is there for 2 reasons:
> >>
> >> 1. To avoid also applying the quirk to external displays, but
> >> I think that that is also solved in most drivers by only checking for
> >> a quirk at all on the eDP connector
> >>
> >> 2. Some laptop models ship with different panels in different badges
> >> some of these are portrait (so need a panel-orient) setting and others
> >> are landscape.
> >
> > That makes sense. So yeah the EDID mode based matching logic needs to
> > stay to accomodate for these cases.
> >
> >>> I agree that at least in the Steam
> >>> Deck case it may not make a lot of sense to use any info from the
> >>> EDID, but that's needed for the current status quo.
> >>
> >> We could extend the DMI quirk mechanism to allow quirks which don't
> >> do the mode check, for use on devices where we can guarantee neither
> >> 1 nor 2 happens, then amdgpu could call the quirk code early simply
> >> passing 0x0 as resolution.
> >
> > Yeah. But per the above amdgpu should maybe probe connectors on module
> > load. If/when amdgpu is fixed to do this, then we don't need to disable
> > the mode matching logic in panel-orientation quirks anymore.
>

Hi all,

Thanks for all of the discussion. I'm not sure about how amd drm
works, but for some SoC, the panel orientation is set in panel[1].
The goal of this patch is to separate the property creation, so some
drm can optionally create it earlier before drm_dev_register().

I've sent the v9 to address some issues in v8, but the basic idea is
still the same. It has no effect to
drm_connector_set_panel_orientation_with_quirk() used in amdgpu and
i915, they work the same as before. Do you think this is reasonable?

[1]  https://elixir.bootlin.com/linux/v5.17-rc7/source/drivers/gpu/drm/panel/panel-edp.c#L556

Re: [Intel-gfx] [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Hsin-Yi Wang]

On Fri, Feb 18, 2022 at 11:57 PM Harry Wentland <harry.wentland@amd.com> wrote:
>
> On 2022-02-18 07:12, Simon Ser wrote:
> > On Friday, February 18th, 2022 at 12:54, Hans de Goede <hdegoede@redhat.com> wrote:
> >
> >> On 2/18/22 12:39, Simon Ser wrote:
> >>> On Friday, February 18th, 2022 at 11:38, Hans de Goede <hdegoede@redhat.com> wrote:
> >>>
> >>>> What I'm reading in the above is that it is being considered to allow
> >>>> changing the panel-orientation value after the connector has been made
> >>>> available to userspace; and let userspace know about this through a uevent.
> >>>>
> >>>> I believe that this is a bad idea, it is important to keep in mind here
> >>>> what userspace (e.g. plymouth) uses this prorty for. This property is
> >>>> used to rotate the image being rendered / shown on the framebuffer to
> >>>> adjust for the panel orientation.
> >>>>
> >>>> So now lets assume we apply the correct upside-down orientation later
> >>>> on a device with an upside-down mounted LCD panel. Then on boot the
> >>>> following could happen:
> >>>>
> >>>> 1. amdgpu exports a connector for the LCD panel to userspace without
> >>>> setting panel-orient=upside-down
> >>>> 2. plymouth sees this and renders its splash normally, but since the
> >>>> panel is upside-down it will now actually show upside-down
> >>>
> >>> At this point amdgpu hasn't probed the connector yet. So the connector
> >>> will be marked as disconnected, and plymouth shouldn't render anything.
> >>
> >> If before the initial probe of the connector there is a /dev/dri/card0
> >> which plymouth can access, then plymouth may at this point decide
> >> to disable any seemingly unused crtcs, which will make the screen go black...
> >>
> >> I'm not sure if plymouth will actually do this, but AFAICT this would
> >> not be invalid behavior for a userspace kms consumer to do and I
> >> believe it is likely that mutter will disable unused crtcs.
> >>
> >> IMHO it is just a bad idea to register /dev/dri/card0 with userspace
> >> before the initial connector probe is done. Nothing good can come
> >> of that.
> >>
> >> If all the exposed connectors initially are going to show up as
> >> disconnected anyways what is the value in registering /dev/dri/card0
> >> with userspace early ?
> >
> > OK. I'm still unsure how I feel about this, but I think I agree with
> > you. That said, the amdgpu architecture is quite involved with multiple
> > abstraction levels, so I don't think I'm equipped to write a patch to
> > fix this...
> >
>
> amdgpu_dm's connector registration already triggers a detection. See the
> calls to dc_link_detect and amdgpu_dm_update_connector_after_detect in
> amdgpu_dm_initialize_drm_device.
>
> dc_link_detect is supposed to read the edid via
> dm_helpers_read_local_edid and amdgpu_dm_update_connector_after_detect
> will update the EDID on the connector via a
> drm_connector_update_edid_property call.
>
> This all happens at driver load.
>
> I don't know why you're seeing the embedded connector as disconnected
> unless the DP-MIPI bridge for some reason doesn't indicate that the panel
> is connected at driver load.
>
> Harry
>
> > cc Daniel Vetter: can you confirm probing all connectors is a good thing
> > to do on driver module load?
> >
> >>>> I guess the initial modeline is inherited from the video-bios, but
> >>>> what about the physical size? Note that you cannot just change the
> >>>> physical size later either, that gets used to determine the hidpi
> >>>> scaling factor in the bootsplash, and changing that after the initial
> >>>> bootsplash dislay will also look ugly
> >>>>
> >>>> b) Why you need the edid for the panel-orientation property at all,
> >>>> typically the edid prom is part of the panel and the panel does not
> >>>> know that it is mounted e.g. upside down at all, that is a property
> >>>> of the system as a whole not of the panel as a standalone unit so
> >>>> in my experience getting panel-orient info is something which comes
> >>>> from the firmware /video-bios not from edid ?
> >>>
> >>> This is an internal DRM thing. The orientation quirks logic uses the
> >>> mode size advertised by the EDID.
> >>
> >> The DMI based quirking does, yes. But e.g. the quirk code directly
> >> reading this from the Intel VBT does not rely on the mode.
> >>
> >> But if you are planning on using a DMI based quirk for the steamdeck
> >> then yes that needs the mode.
> >>
> >> Thee mode check is there for 2 reasons:
> >>
> >> 1. To avoid also applying the quirk to external displays, but
> >> I think that that is also solved in most drivers by only checking for
> >> a quirk at all on the eDP connector
> >>
> >> 2. Some laptop models ship with different panels in different badges
> >> some of these are portrait (so need a panel-orient) setting and others
> >> are landscape.
> >
> > That makes sense. So yeah the EDID mode based matching logic needs to
> > stay to accomodate for these cases.
> >
> >>> I agree that at least in the Steam
> >>> Deck case it may not make a lot of sense to use any info from the
> >>> EDID, but that's needed for the current status quo.
> >>
> >> We could extend the DMI quirk mechanism to allow quirks which don't
> >> do the mode check, for use on devices where we can guarantee neither
> >> 1 nor 2 happens, then amdgpu could call the quirk code early simply
> >> passing 0x0 as resolution.
> >
> > Yeah. But per the above amdgpu should maybe probe connectors on module
> > load. If/when amdgpu is fixed to do this, then we don't need to disable
> > the mode matching logic in panel-orientation quirks anymore.
>

Hi all,

Thanks for all of the discussion. I'm not sure about how amd drm
works, but for some SoC, the panel orientation is set in panel[1].
The goal of this patch is to separate the property creation, so some
drm can optionally create it earlier before drm_dev_register().

I've sent the v9 to address some issues in v8, but the basic idea is
still the same. It has no effect to
drm_connector_set_panel_orientation_with_quirk() used in amdgpu and
i915, they work the same as before. Do you think this is reasonable?

[1]  https://elixir.bootlin.com/linux/v5.17-rc7/source/drivers/gpu/drm/panel/panel-edp.c#L556

Re: [Intel-gfx] [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Hsin-Yi Wang]

On Fri, Feb 18, 2022 at 11:57 PM Harry Wentland <harry.wentland@amd.com> wrote:
>
> On 2022-02-18 07:12, Simon Ser wrote:
> > On Friday, February 18th, 2022 at 12:54, Hans de Goede <hdegoede@redhat.com> wrote:
> >
> >> On 2/18/22 12:39, Simon Ser wrote:
> >>> On Friday, February 18th, 2022 at 11:38, Hans de Goede <hdegoede@redhat.com> wrote:
> >>>
> >>>> What I'm reading in the above is that it is being considered to allow
> >>>> changing the panel-orientation value after the connector has been made
> >>>> available to userspace; and let userspace know about this through a uevent.
> >>>>
> >>>> I believe that this is a bad idea, it is important to keep in mind here
> >>>> what userspace (e.g. plymouth) uses this prorty for. This property is
> >>>> used to rotate the image being rendered / shown on the framebuffer to
> >>>> adjust for the panel orientation.
> >>>>
> >>>> So now lets assume we apply the correct upside-down orientation later
> >>>> on a device with an upside-down mounted LCD panel. Then on boot the
> >>>> following could happen:
> >>>>
> >>>> 1. amdgpu exports a connector for the LCD panel to userspace without
> >>>> setting panel-orient=upside-down
> >>>> 2. plymouth sees this and renders its splash normally, but since the
> >>>> panel is upside-down it will now actually show upside-down
> >>>
> >>> At this point amdgpu hasn't probed the connector yet. So the connector
> >>> will be marked as disconnected, and plymouth shouldn't render anything.
> >>
> >> If before the initial probe of the connector there is a /dev/dri/card0
> >> which plymouth can access, then plymouth may at this point decide
> >> to disable any seemingly unused crtcs, which will make the screen go black...
> >>
> >> I'm not sure if plymouth will actually do this, but AFAICT this would
> >> not be invalid behavior for a userspace kms consumer to do and I
> >> believe it is likely that mutter will disable unused crtcs.
> >>
> >> IMHO it is just a bad idea to register /dev/dri/card0 with userspace
> >> before the initial connector probe is done. Nothing good can come
> >> of that.
> >>
> >> If all the exposed connectors initially are going to show up as
> >> disconnected anyways what is the value in registering /dev/dri/card0
> >> with userspace early ?
> >
> > OK. I'm still unsure how I feel about this, but I think I agree with
> > you. That said, the amdgpu architecture is quite involved with multiple
> > abstraction levels, so I don't think I'm equipped to write a patch to
> > fix this...
> >
>
> amdgpu_dm's connector registration already triggers a detection. See the
> calls to dc_link_detect and amdgpu_dm_update_connector_after_detect in
> amdgpu_dm_initialize_drm_device.
>
> dc_link_detect is supposed to read the edid via
> dm_helpers_read_local_edid and amdgpu_dm_update_connector_after_detect
> will update the EDID on the connector via a
> drm_connector_update_edid_property call.
>
> This all happens at driver load.
>
> I don't know why you're seeing the embedded connector as disconnected
> unless the DP-MIPI bridge for some reason doesn't indicate that the panel
> is connected at driver load.
>
> Harry
>
> > cc Daniel Vetter: can you confirm probing all connectors is a good thing
> > to do on driver module load?
> >
> >>>> I guess the initial modeline is inherited from the video-bios, but
> >>>> what about the physical size? Note that you cannot just change the
> >>>> physical size later either, that gets used to determine the hidpi
> >>>> scaling factor in the bootsplash, and changing that after the initial
> >>>> bootsplash dislay will also look ugly
> >>>>
> >>>> b) Why you need the edid for the panel-orientation property at all,
> >>>> typically the edid prom is part of the panel and the panel does not
> >>>> know that it is mounted e.g. upside down at all, that is a property
> >>>> of the system as a whole not of the panel as a standalone unit so
> >>>> in my experience getting panel-orient info is something which comes
> >>>> from the firmware /video-bios not from edid ?
> >>>
> >>> This is an internal DRM thing. The orientation quirks logic uses the
> >>> mode size advertised by the EDID.
> >>
> >> The DMI based quirking does, yes. But e.g. the quirk code directly
> >> reading this from the Intel VBT does not rely on the mode.
> >>
> >> But if you are planning on using a DMI based quirk for the steamdeck
> >> then yes that needs the mode.
> >>
> >> Thee mode check is there for 2 reasons:
> >>
> >> 1. To avoid also applying the quirk to external displays, but
> >> I think that that is also solved in most drivers by only checking for
> >> a quirk at all on the eDP connector
> >>
> >> 2. Some laptop models ship with different panels in different badges
> >> some of these are portrait (so need a panel-orient) setting and others
> >> are landscape.
> >
> > That makes sense. So yeah the EDID mode based matching logic needs to
> > stay to accomodate for these cases.
> >
> >>> I agree that at least in the Steam
> >>> Deck case it may not make a lot of sense to use any info from the
> >>> EDID, but that's needed for the current status quo.
> >>
> >> We could extend the DMI quirk mechanism to allow quirks which don't
> >> do the mode check, for use on devices where we can guarantee neither
> >> 1 nor 2 happens, then amdgpu could call the quirk code early simply
> >> passing 0x0 as resolution.
> >
> > Yeah. But per the above amdgpu should maybe probe connectors on module
> > load. If/when amdgpu is fixed to do this, then we don't need to disable
> > the mode matching logic in panel-orientation quirks anymore.
>

Hi all,

Thanks for all of the discussion. I'm not sure about how amd drm
works, but for some SoC, the panel orientation is set in panel[1].
The goal of this patch is to separate the property creation, so some
drm can optionally create it earlier before drm_dev_register().

I've sent the v9 to address some issues in v8, but the basic idea is
still the same. It has no effect to
drm_connector_set_panel_orientation_with_quirk() used in amdgpu and
i915, they work the same as before. Do you think this is reasonable?

[1]  https://elixir.bootlin.com/linux/v5.17-rc7/source/drivers/gpu/drm/panel/panel-edp.c#L556

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

Re: [Intel-gfx] [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Hsin-Yi Wang]

On Fri, Feb 18, 2022 at 11:57 PM Harry Wentland <harry.wentland@amd.com> wrote:
>
> On 2022-02-18 07:12, Simon Ser wrote:
> > On Friday, February 18th, 2022 at 12:54, Hans de Goede <hdegoede@redhat.com> wrote:
> >
> >> On 2/18/22 12:39, Simon Ser wrote:
> >>> On Friday, February 18th, 2022 at 11:38, Hans de Goede <hdegoede@redhat.com> wrote:
> >>>
> >>>> What I'm reading in the above is that it is being considered to allow
> >>>> changing the panel-orientation value after the connector has been made
> >>>> available to userspace; and let userspace know about this through a uevent.
> >>>>
> >>>> I believe that this is a bad idea, it is important to keep in mind here
> >>>> what userspace (e.g. plymouth) uses this prorty for. This property is
> >>>> used to rotate the image being rendered / shown on the framebuffer to
> >>>> adjust for the panel orientation.
> >>>>
> >>>> So now lets assume we apply the correct upside-down orientation later
> >>>> on a device with an upside-down mounted LCD panel. Then on boot the
> >>>> following could happen:
> >>>>
> >>>> 1. amdgpu exports a connector for the LCD panel to userspace without
> >>>> setting panel-orient=upside-down
> >>>> 2. plymouth sees this and renders its splash normally, but since the
> >>>> panel is upside-down it will now actually show upside-down
> >>>
> >>> At this point amdgpu hasn't probed the connector yet. So the connector
> >>> will be marked as disconnected, and plymouth shouldn't render anything.
> >>
> >> If before the initial probe of the connector there is a /dev/dri/card0
> >> which plymouth can access, then plymouth may at this point decide
> >> to disable any seemingly unused crtcs, which will make the screen go black...
> >>
> >> I'm not sure if plymouth will actually do this, but AFAICT this would
> >> not be invalid behavior for a userspace kms consumer to do and I
> >> believe it is likely that mutter will disable unused crtcs.
> >>
> >> IMHO it is just a bad idea to register /dev/dri/card0 with userspace
> >> before the initial connector probe is done. Nothing good can come
> >> of that.
> >>
> >> If all the exposed connectors initially are going to show up as
> >> disconnected anyways what is the value in registering /dev/dri/card0
> >> with userspace early ?
> >
> > OK. I'm still unsure how I feel about this, but I think I agree with
> > you. That said, the amdgpu architecture is quite involved with multiple
> > abstraction levels, so I don't think I'm equipped to write a patch to
> > fix this...
> >
>
> amdgpu_dm's connector registration already triggers a detection. See the
> calls to dc_link_detect and amdgpu_dm_update_connector_after_detect in
> amdgpu_dm_initialize_drm_device.
>
> dc_link_detect is supposed to read the edid via
> dm_helpers_read_local_edid and amdgpu_dm_update_connector_after_detect
> will update the EDID on the connector via a
> drm_connector_update_edid_property call.
>
> This all happens at driver load.
>
> I don't know why you're seeing the embedded connector as disconnected
> unless the DP-MIPI bridge for some reason doesn't indicate that the panel
> is connected at driver load.
>
> Harry
>
> > cc Daniel Vetter: can you confirm probing all connectors is a good thing
> > to do on driver module load?
> >
> >>>> I guess the initial modeline is inherited from the video-bios, but
> >>>> what about the physical size? Note that you cannot just change the
> >>>> physical size later either, that gets used to determine the hidpi
> >>>> scaling factor in the bootsplash, and changing that after the initial
> >>>> bootsplash dislay will also look ugly
> >>>>
> >>>> b) Why you need the edid for the panel-orientation property at all,
> >>>> typically the edid prom is part of the panel and the panel does not
> >>>> know that it is mounted e.g. upside down at all, that is a property
> >>>> of the system as a whole not of the panel as a standalone unit so
> >>>> in my experience getting panel-orient info is something which comes
> >>>> from the firmware /video-bios not from edid ?
> >>>
> >>> This is an internal DRM thing. The orientation quirks logic uses the
> >>> mode size advertised by the EDID.
> >>
> >> The DMI based quirking does, yes. But e.g. the quirk code directly
> >> reading this from the Intel VBT does not rely on the mode.
> >>
> >> But if you are planning on using a DMI based quirk for the steamdeck
> >> then yes that needs the mode.
> >>
> >> Thee mode check is there for 2 reasons:
> >>
> >> 1. To avoid also applying the quirk to external displays, but
> >> I think that that is also solved in most drivers by only checking for
> >> a quirk at all on the eDP connector
> >>
> >> 2. Some laptop models ship with different panels in different badges
> >> some of these are portrait (so need a panel-orient) setting and others
> >> are landscape.
> >
> > That makes sense. So yeah the EDID mode based matching logic needs to
> > stay to accomodate for these cases.
> >
> >>> I agree that at least in the Steam
> >>> Deck case it may not make a lot of sense to use any info from the
> >>> EDID, but that's needed for the current status quo.
> >>
> >> We could extend the DMI quirk mechanism to allow quirks which don't
> >> do the mode check, for use on devices where we can guarantee neither
> >> 1 nor 2 happens, then amdgpu could call the quirk code early simply
> >> passing 0x0 as resolution.
> >
> > Yeah. But per the above amdgpu should maybe probe connectors on module
> > load. If/when amdgpu is fixed to do this, then we don't need to disable
> > the mode matching logic in panel-orientation quirks anymore.
>

Hi all,

Thanks for all of the discussion. I'm not sure about how amd drm
works, but for some SoC, the panel orientation is set in panel[1].
The goal of this patch is to separate the property creation, so some
drm can optionally create it earlier before drm_dev_register().

I've sent the v9 to address some issues in v8, but the basic idea is
still the same. It has no effect to
drm_connector_set_panel_orientation_with_quirk() used in amdgpu and
i915, they work the same as before. Do you think this is reasonable?

[1]  https://elixir.bootlin.com/linux/v5.17-rc7/source/drivers/gpu/drm/panel/panel-edp.c#L556

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [Intel-gfx] [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Hsin-Yi Wang]

On Fri, Feb 18, 2022 at 11:57 PM Harry Wentland <harry.wentland@amd.com> wrote:
>
> On 2022-02-18 07:12, Simon Ser wrote:
> > On Friday, February 18th, 2022 at 12:54, Hans de Goede <hdegoede@redhat.com> wrote:
> >
> >> On 2/18/22 12:39, Simon Ser wrote:
> >>> On Friday, February 18th, 2022 at 11:38, Hans de Goede <hdegoede@redhat.com> wrote:
> >>>
> >>>> What I'm reading in the above is that it is being considered to allow
> >>>> changing the panel-orientation value after the connector has been made
> >>>> available to userspace; and let userspace know about this through a uevent.
> >>>>
> >>>> I believe that this is a bad idea, it is important to keep in mind here
> >>>> what userspace (e.g. plymouth) uses this prorty for. This property is
> >>>> used to rotate the image being rendered / shown on the framebuffer to
> >>>> adjust for the panel orientation.
> >>>>
> >>>> So now lets assume we apply the correct upside-down orientation later
> >>>> on a device with an upside-down mounted LCD panel. Then on boot the
> >>>> following could happen:
> >>>>
> >>>> 1. amdgpu exports a connector for the LCD panel to userspace without
> >>>> setting panel-orient=upside-down
> >>>> 2. plymouth sees this and renders its splash normally, but since the
> >>>> panel is upside-down it will now actually show upside-down
> >>>
> >>> At this point amdgpu hasn't probed the connector yet. So the connector
> >>> will be marked as disconnected, and plymouth shouldn't render anything.
> >>
> >> If before the initial probe of the connector there is a /dev/dri/card0
> >> which plymouth can access, then plymouth may at this point decide
> >> to disable any seemingly unused crtcs, which will make the screen go black...
> >>
> >> I'm not sure if plymouth will actually do this, but AFAICT this would
> >> not be invalid behavior for a userspace kms consumer to do and I
> >> believe it is likely that mutter will disable unused crtcs.
> >>
> >> IMHO it is just a bad idea to register /dev/dri/card0 with userspace
> >> before the initial connector probe is done. Nothing good can come
> >> of that.
> >>
> >> If all the exposed connectors initially are going to show up as
> >> disconnected anyways what is the value in registering /dev/dri/card0
> >> with userspace early ?
> >
> > OK. I'm still unsure how I feel about this, but I think I agree with
> > you. That said, the amdgpu architecture is quite involved with multiple
> > abstraction levels, so I don't think I'm equipped to write a patch to
> > fix this...
> >
>
> amdgpu_dm's connector registration already triggers a detection. See the
> calls to dc_link_detect and amdgpu_dm_update_connector_after_detect in
> amdgpu_dm_initialize_drm_device.
>
> dc_link_detect is supposed to read the edid via
> dm_helpers_read_local_edid and amdgpu_dm_update_connector_after_detect
> will update the EDID on the connector via a
> drm_connector_update_edid_property call.
>
> This all happens at driver load.
>
> I don't know why you're seeing the embedded connector as disconnected
> unless the DP-MIPI bridge for some reason doesn't indicate that the panel
> is connected at driver load.
>
> Harry
>
> > cc Daniel Vetter: can you confirm probing all connectors is a good thing
> > to do on driver module load?
> >
> >>>> I guess the initial modeline is inherited from the video-bios, but
> >>>> what about the physical size? Note that you cannot just change the
> >>>> physical size later either, that gets used to determine the hidpi
> >>>> scaling factor in the bootsplash, and changing that after the initial
> >>>> bootsplash dislay will also look ugly
> >>>>
> >>>> b) Why you need the edid for the panel-orientation property at all,
> >>>> typically the edid prom is part of the panel and the panel does not
> >>>> know that it is mounted e.g. upside down at all, that is a property
> >>>> of the system as a whole not of the panel as a standalone unit so
> >>>> in my experience getting panel-orient info is something which comes
> >>>> from the firmware /video-bios not from edid ?
> >>>
> >>> This is an internal DRM thing. The orientation quirks logic uses the
> >>> mode size advertised by the EDID.
> >>
> >> The DMI based quirking does, yes. But e.g. the quirk code directly
> >> reading this from the Intel VBT does not rely on the mode.
> >>
> >> But if you are planning on using a DMI based quirk for the steamdeck
> >> then yes that needs the mode.
> >>
> >> Thee mode check is there for 2 reasons:
> >>
> >> 1. To avoid also applying the quirk to external displays, but
> >> I think that that is also solved in most drivers by only checking for
> >> a quirk at all on the eDP connector
> >>
> >> 2. Some laptop models ship with different panels in different badges
> >> some of these are portrait (so need a panel-orient) setting and others
> >> are landscape.
> >
> > That makes sense. So yeah the EDID mode based matching logic needs to
> > stay to accomodate for these cases.
> >
> >>> I agree that at least in the Steam
> >>> Deck case it may not make a lot of sense to use any info from the
> >>> EDID, but that's needed for the current status quo.
> >>
> >> We could extend the DMI quirk mechanism to allow quirks which don't
> >> do the mode check, for use on devices where we can guarantee neither
> >> 1 nor 2 happens, then amdgpu could call the quirk code early simply
> >> passing 0x0 as resolution.
> >
> > Yeah. But per the above amdgpu should maybe probe connectors on module
> > load. If/when amdgpu is fixed to do this, then we don't need to disable
> > the mode matching logic in panel-orientation quirks anymore.
>

Hi all,

Thanks for all of the discussion. I'm not sure about how amd drm
works, but for some SoC, the panel orientation is set in panel[1].
The goal of this patch is to separate the property creation, so some
drm can optionally create it earlier before drm_dev_register().

I've sent the v9 to address some issues in v8, but the basic idea is
still the same. It has no effect to
drm_connector_set_panel_orientation_with_quirk() used in amdgpu and
i915, they work the same as before. Do you think this is reasonable?

[1]  https://elixir.bootlin.com/linux/v5.17-rc7/source/drivers/gpu/drm/panel/panel-edp.c#L556