Re: [PATCH] drm: Print bad EDID notices only once
On 9/26/24 09:32, Andi Kleen wrote:
I have an old monitor that reports a zero EDID block, which results in a
warning message. This happens on every screen save cycle, and maybe in
some other situations, and over time the whole kernel log gets filled
with these redundant messages. Printing it only once should be
sufficient.
Mark all the bad EDID notices as _once.
Signed-off-by: Andi Kleen
---
drivers/gpu/drm/drm_edid.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 855beafb76ff..d6b47bdcd5d7 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1916,10 +1916,10 @@ static void edid_block_status_print(enum
edid_block_status status,
pr_debug("EDID block %d pointer is NULL\n", block_num);
break;
case EDID_BLOCK_ZERO:
- pr_notice("EDID block %d is all zeroes\n", block_num);
+ pr_notice_once("EDID block %d is all zeroes\n", block_num);
It may be a good opportunity to switch these over to drm_notice_once()
instead.
Hamza
break;
case EDID_BLOCK_HEADER_CORRUPT:
- pr_notice("EDID has corrupt header\n");
+ pr_notice_once("EDID has corrupt header\n");
break;
case EDID_BLOCK_HEADER_REPAIR:
pr_debug("EDID corrupt header needs repair\n");
@@ -1933,13 +1933,13 @@ static void edid_block_status_print(enum
edid_block_status status,
block_num, edid_block_tag(block),
edid_block_compute_checksum(block));
} else {
- pr_notice("EDID block %d (tag 0x%02x) checksum is invalid,
remainder is %d\n",
+ pr_notice_once("EDID block %d (tag 0x%02x) checksum is
invalid, remainder is %d\n",
block_num, edid_block_tag(block),
edid_block_compute_checksum(block));
}
break;
case EDID_BLOCK_VERSION:
- pr_notice("EDID has major version %d, instead of 1\n",
+ pr_notice_once("EDID has major version %d, instead of 1\n",
block->version);
break;
default:
--
Hamza
Re: [PATCH v7 10/10] drm/amd/display: Fetch the EDID from _DDC if available for eDP
On 9/19/24 13:29, Alex Deucher wrote:
On Thu, Sep 19, 2024 at 12:06 PM Mario Limonciello
wrote:
On 9/19/2024 11:03, Alex Hung wrote:
A minor comment (see inline below).
Otherwise
Reviewed-by: Alex Hung
On 2024-09-18 15:38, Mario Limonciello wrote:
Some manufacturers have intentionally put an EDID that differs from
the EDID on the internal panel on laptops.
Attempt to fetch this EDID if it exists and prefer it over the EDID
that is provided by the panel. If a user prefers to use the EDID from
the panel, offer a DC debugging parameter that would disable this.
Signed-off-by: Mario Limonciello
---
.../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 62 ++-
drivers/gpu/drm/amd/include/amd_shared.h | 5 ++
2 files changed, 66 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
index 8f4be7a1ec45..05d3e00ecce0 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
@@ -23,6 +23,8 @@
*
*/
+#include
+
#include
#include
#include
@@ -874,6 +876,60 @@ bool dm_helpers_is_dp_sink_present(struct dc_link
*link)
return dp_sink_present;
}
+static int
+dm_helpers_probe_acpi_edid(void *data, u8 *buf, unsigned int block,
size_t len)
+{
+struct drm_connector *connector = data;
+struct acpi_device *acpidev = ACPI_COMPANION(connector->dev->dev);
+unsigned char start = block * EDID_LENGTH;
+void *edid;
+int r;
+
+if (!acpidev)
+return -ENODEV;
+
+/* fetch the entire edid from BIOS */
+r = acpi_video_get_edid(acpidev, ACPI_VIDEO_DISPLAY_LCD, -1, &edid);
+if (r < 0) {
+DRM_DEBUG_KMS("Failed to get EDID from ACPI: %d\n", r);
+return r;
+}
+if (len > r || start > r || start + len > r) {
+r = -EINVAL;
+goto cleanup;
+}
+
+memcpy(buf, edid + start, len);
+r = 0;
+
+cleanup:
+kfree(edid);
+
+return r;
+}
+
+static const struct drm_edid *
+dm_helpers_read_acpi_edid(struct amdgpu_dm_connector *aconnector)
+{
+struct drm_connector *connector = &aconnector->base;
+
+if (amdgpu_dc_debug_mask & DC_DISABLE_ACPI_EDID)
+return NULL;
+
+switch (connector->connector_type) {
+case DRM_MODE_CONNECTOR_LVDS:
+case DRM_MODE_CONNECTOR_eDP:
+break;
+default:
+return NULL;
+}
+
+if (connector->force == DRM_FORCE_OFF)
+return NULL;
+
+return drm_edid_read_custom(connector,
dm_helpers_probe_acpi_edid, connector);
+}
+
enum dc_edid_status dm_helpers_read_local_edid(
struct dc_context *ctx,
struct dc_link *link,
@@ -896,7 +952,11 @@ enum dc_edid_status dm_helpers_read_local_edid(
* do check sum and retry to make sure read correct edid.
*/
do {
-drm_edid = drm_edid_read_ddc(connector, ddc);
+drm_edid = dm_helpers_read_acpi_edid(aconnector);
+if (drm_edid)
+DRM_DEBUG_KMS("Using ACPI provided EDID for %s\n",
connector->name);
It is better to always output a message when ACPI's EDID is used without
enabling any debug options. How about DRM_INFO?
Thanks, DRM_INFO makes sense for discoverability and will adjust it.
I'd suggest using dev_info() or one of the newer DRM macros so we know
which device we are talking about if there are multiple GPUs in the
system.
Ya, I'd personally prefer moving amdgpu_dm over to the new(er) drm_.*
family of logging macros.
Alex
+else
+drm_edid = drm_edid_read_ddc(connector, ddc);
drm_edid_connector_update(connector, drm_edid);
aconnector->drm_edid = drm_edid;
diff --git a/drivers/gpu/drm/amd/include/amd_shared.h
b/drivers/gpu/drm/amd/include/amd_shared.h
index 3f91926a50e9..1ec7c5e5249e 100644
--- a/drivers/gpu/drm/amd/include/amd_shared.h
+++ b/drivers/gpu/drm/amd/include/amd_shared.h
@@ -337,6 +337,11 @@ enum DC_DEBUG_MASK {
* @DC_FORCE_IPS_ENABLE: If set, force enable all IPS, all the
time.
*/
DC_FORCE_IPS_ENABLE = 0x4000,
+/**
+ * @DC_DISABLE_ACPI_EDID: If set, don't attempt to fetch EDID for
+ * eDP display from ACPI _DDC method.
+ */
+DC_DISABLE_ACPI_EDID = 0x8000,
};
enum amd_dpm_forced_level;
--
Hamza
[PATCH v4] drm/edid: add CTA Video Format Data Block support
Video Format Data Blocks (VFDBs) contain the necessary information that
needs to be fed to the Optimized Video Timings (OVT) Algorithm.
Also, we require OVT support to cover modes that aren't supported by
earlier standards (e.g. CVT). So, parse all of the relevant VFDB data
and feed it to the OVT Algorithm, to extract all of the missing OVT
modes.
Suggested-by: Karol Herbst
Signed-off-by: Hamza Mahfooz
---
v3: move ovt stuff above add_cea_modes() and break up
calculate_ovt_mode() to make it easier to read.
v4: fix 32 bit build and constify read-only vars.
---
drivers/gpu/drm/drm_edid.c | 452 +
1 file changed, 452 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 855beafb76ff..01de2117aaf2 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -741,6 +742,93 @@ static const struct minimode extra_modes[] = {
{ 2048, 1536, 60, 0 },
};
+struct cta_rid {
+ u16 hactive;
+ u16 vactive;
+ u8 hratio;
+ u8 vratio;
+};
+
+/* CTA-861-I Table 11 - Resolution Identification (RID) */
+static const struct cta_rid rids[] = {
+ /* RID 0-9 */
+ { 0, 0, 0, 0 },
+ { 1280, 720, 16, 9 },
+ { 1280, 720, 64, 27 },
+ { 1680, 720, 64, 27 },
+ { 1920, 1080, 16, 9 },
+ { 1920, 1080, 64, 27 },
+ { 2560, 1080, 64, 27 },
+ { 3840, 1080, 32, 9 },
+ { 2560, 1440, 16, 9 },
+ { 3440, 1440, 64, 27 },
+ /* RID 10-19 */
+ { 5120, 1440, 32, 9 },
+ { 3840, 2160, 16, 9 },
+ { 3840, 2160, 64, 27 },
+ { 5120, 2160, 64, 27 },
+ { 7680, 2160, 32, 9 },
+ { 5120, 2880, 16, 9 },
+ { 5120, 2880, 64, 27 },
+ { 6880, 2880, 64, 27 },
+ { 10240, 2880, 32, 9 },
+ { 7680, 4320, 16, 9 },
+ /* RID 20-28 */
+ { 7680, 4320, 64, 27 },
+ { 10240, 4320, 64, 27 },
+ { 15360, 4320, 32, 9 },
+ { 11520, 6480, 16, 9 },
+ { 11520, 6480, 64, 27 },
+ { 15360, 6480, 64, 27 },
+ { 15360, 8640, 16, 9 },
+ { 15360, 8640, 64, 27 },
+ { 20480, 8640, 64, 27 },
+};
+
+/* CTA-861-I Table 12 - AVI InfoFrame Video Format Frame Rate */
+static const u16 cta_vf_fr[] = {
+ /* Frame Rate 0-7 */
+ 0, 24, 25, 30, 48, 50, 60, 100,
+ /* Frame Rate 8-15 */
+ 120, 144, 200, 240, 300, 360, 400, 480,
+};
+
+/* CTA-861-I Table 13 - RID To VIC Mapping */
+static const u8 rid_to_vic[][8] = {
+ /* RID 0-9 */
+ {},
+ { 60, 61, 62, 108, 19, 4, 41, 47 },
+ { 65, 66, 67, 109, 68, 69, 70, 71 },
+ { 79, 80, 81, 110, 82, 83, 84, 85 },
+ { 32, 33, 34, 111, 31, 16, 64, 63 },
+ { 72, 73, 74, 112, 75, 76, 77, 78 },
+ { 86, 87, 88, 113, 89, 90, 91, 92 },
+ {},
+ {},
+ {},
+ /* RID 10-19 */
+ {},
+ { 93, 94, 95, 114, 96, 97, 117, 118 },
+ { 103, 104, 105, 116, 106, 107, 119, 120 },
+ { 121, 122, 123, 124, 125, 126, 127, 193 },
+ {},
+ {},
+ {},
+ {},
+ {},
+ { 194, 195, 196, 197, 198, 199, 200, 201 },
+ /* RID 20-28 */
+ { 202, 203, 204, 205, 206, 207, 208, 209 },
+ { 210, 211, 212, 213, 214, 215, 216, 217 },
+ {},
+ {},
+ {},
+ {},
+ {},
+ {},
+ {},
+};
+
/*
* From CEA/CTA-861 spec.
*
@@ -4131,6 +4219,7 @@ static int add_detailed_modes(struct drm_connector
*connector,
#define CTA_DB_VIDEO 2
#define CTA_DB_VENDOR 3
#define CTA_DB_SPEAKER 4
+#define CTA_DB_VIDEO_FORMAT6
#define CTA_DB_EXTENDED_TAG7
/* CTA-861-H Table 62 - CTA Extended Tag Codes */
@@ -4972,6 +5061,16 @@ struct cea_db {
u8 data[];
} __packed;
+struct cta_vfd {
+ u8 rid;
+ u8 fr_fact;
+ bool bfr50;
+ bool fr24;
+ bool bfr60;
+ bool fr144;
+ bool fr48;
+};
+
static int cea_db_tag(const struct cea_db *db)
{
return db->tag_length >> 5;
@@ -5250,6 +5349,357 @@ static int edid_hfeeodb_extension_block_count(const
struct edid *edid)
return cta[4 + 2];
}
+/* CTA-861 Video Format Descriptor (CTA VFD) */
+static void parse_cta_vfd(struct cta_vfd *vfd, const u8 *data, int vfd_len)
+{
+ vfd->rid = data[0] & 0x3f;
+ vfd->bfr50 = data[0] & 0x80;
+ vfd->fr24 = data[0] & 0x40;
+ vfd->bfr60 = vfd_len > 1 ? (data[1] & 0x80) : 0x1;
+ vfd->fr144 = vfd_len > 1 ? (data[1] & 0x40) : 0x0;
+ vfd->fr_fact = vfd_len > 1 ? (data[1] & 0x3f) : 0x3;
+ vfd->fr48 = vfd_len > 2 ? (data[2] & 0x1) : 0x0;
+}
+
+static bool vfd_has_fr(const struct cta_vfd *vfd, int rate_idx)
+{
+ static const u8 factors[] = {
+ 1, 2, 4, 8, 12, 16
+ };
+ u16
[PATCH v3] drm/edid: add CTA Video Format Data Block support
Video Format Data Blocks (VFDBs) contain the necessary information that
needs to be fed to the Optimized Video Timings (OVT) Algorithm.
Also, we require OVT support to cover modes that aren't supported by
earlier standards (e.g. CVT). So, parse all of the relevant VFDB data
and feed it to the OVT Algorithm, to extract all of the missing OVT
modes.
Suggested-by: Karol Herbst
Signed-off-by: Hamza Mahfooz
---
v3: move ovt stuff above add_cea_modes() and break up
calculate_ovt_mode() to make it easier to read.
---
drivers/gpu/drm/drm_edid.c | 443 +
1 file changed, 443 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 855beafb76ff..5df915955c5f 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -741,6 +742,93 @@ static const struct minimode extra_modes[] = {
{ 2048, 1536, 60, 0 },
};
+struct cta_rid {
+ u16 hactive;
+ u16 vactive;
+ u8 hratio;
+ u8 vratio;
+};
+
+/* CTA-861-I Table 11 - Resolution Identification (RID) */
+static const struct cta_rid rids[] = {
+ /* RID 0-9 */
+ { 0, 0, 0, 0 },
+ { 1280, 720, 16, 9 },
+ { 1280, 720, 64, 27 },
+ { 1680, 720, 64, 27 },
+ { 1920, 1080, 16, 9 },
+ { 1920, 1080, 64, 27 },
+ { 2560, 1080, 64, 27 },
+ { 3840, 1080, 32, 9 },
+ { 2560, 1440, 16, 9 },
+ { 3440, 1440, 64, 27 },
+ /* RID 10-19 */
+ { 5120, 1440, 32, 9 },
+ { 3840, 2160, 16, 9 },
+ { 3840, 2160, 64, 27 },
+ { 5120, 2160, 64, 27 },
+ { 7680, 2160, 32, 9 },
+ { 5120, 2880, 16, 9 },
+ { 5120, 2880, 64, 27 },
+ { 6880, 2880, 64, 27 },
+ { 10240, 2880, 32, 9 },
+ { 7680, 4320, 16, 9 },
+ /* RID 20-28 */
+ { 7680, 4320, 64, 27 },
+ { 10240, 4320, 64, 27 },
+ { 15360, 4320, 32, 9 },
+ { 11520, 6480, 16, 9 },
+ { 11520, 6480, 64, 27 },
+ { 15360, 6480, 64, 27 },
+ { 15360, 8640, 16, 9 },
+ { 15360, 8640, 64, 27 },
+ { 20480, 8640, 64, 27 },
+};
+
+/* CTA-861-I Table 12 - AVI InfoFrame Video Format Frame Rate */
+static const u16 cta_vf_fr[] = {
+ /* Frame Rate 0-7 */
+ 0, 24, 25, 30, 48, 50, 60, 100,
+ /* Frame Rate 8-15 */
+ 120, 144, 200, 240, 300, 360, 400, 480,
+};
+
+/* CTA-861-I Table 13 - RID To VIC Mapping */
+static const u8 rid_to_vic[][8] = {
+ /* RID 0-9 */
+ {},
+ { 60, 61, 62, 108, 19, 4, 41, 47 },
+ { 65, 66, 67, 109, 68, 69, 70, 71 },
+ { 79, 80, 81, 110, 82, 83, 84, 85 },
+ { 32, 33, 34, 111, 31, 16, 64, 63 },
+ { 72, 73, 74, 112, 75, 76, 77, 78 },
+ { 86, 87, 88, 113, 89, 90, 91, 92 },
+ {},
+ {},
+ {},
+ /* RID 10-19 */
+ {},
+ { 93, 94, 95, 114, 96, 97, 117, 118 },
+ { 103, 104, 105, 116, 106, 107, 119, 120 },
+ { 121, 122, 123, 124, 125, 126, 127, 193 },
+ {},
+ {},
+ {},
+ {},
+ {},
+ { 194, 195, 196, 197, 198, 199, 200, 201 },
+ /* RID 20-28 */
+ { 202, 203, 204, 205, 206, 207, 208, 209 },
+ { 210, 211, 212, 213, 214, 215, 216, 217 },
+ {},
+ {},
+ {},
+ {},
+ {},
+ {},
+ {},
+};
+
/*
* From CEA/CTA-861 spec.
*
@@ -4131,6 +4219,7 @@ static int add_detailed_modes(struct drm_connector
*connector,
#define CTA_DB_VIDEO 2
#define CTA_DB_VENDOR 3
#define CTA_DB_SPEAKER 4
+#define CTA_DB_VIDEO_FORMAT6
#define CTA_DB_EXTENDED_TAG7
/* CTA-861-H Table 62 - CTA Extended Tag Codes */
@@ -4972,6 +5061,16 @@ struct cea_db {
u8 data[];
} __packed;
+struct cta_vfd {
+ u8 rid;
+ u8 fr_fact;
+ bool bfr50;
+ bool fr24;
+ bool bfr60;
+ bool fr144;
+ bool fr48;
+};
+
static int cea_db_tag(const struct cea_db *db)
{
return db->tag_length >> 5;
@@ -5250,6 +5349,348 @@ static int edid_hfeeodb_extension_block_count(const
struct edid *edid)
return cta[4 + 2];
}
+/* CTA-861 Video Format Descriptor (CTA VFD) */
+static void parse_cta_vfd(struct cta_vfd *vfd, const u8 *data, int vfd_len)
+{
+ vfd->rid = data[0] & 0x3f;
+ vfd->bfr50 = data[0] & 0x80;
+ vfd->fr24 = data[0] & 0x40;
+ vfd->bfr60 = vfd_len > 1 ? (data[1] & 0x80) : 0x1;
+ vfd->fr144 = vfd_len > 1 ? (data[1] & 0x40) : 0x0;
+ vfd->fr_fact = vfd_len > 1 ? (data[1] & 0x3f) : 0x3;
+ vfd->fr48 = vfd_len > 2 ? (data[2] & 0x1) : 0x0;
+}
+
+static bool vfd_has_fr(const struct cta_vfd *vfd, int rate_idx)
+{
+ static const u8 factors[] = {
+ 1, 2, 4, 8, 12, 16
+ };
+ u16 rate = cta_vf_fr[rate_idx];
+ u16 fa
[PATCH] drm/amdgpu: enable -Wformat-truncation
It is enabled by W=1 and amdgpu has a clean build with it enabled. So, to make sure we block future instances of it from showing up on our driver, enable it by default for the module. Signed-off-by: Hamza Mahfooz --- drivers/gpu/drm/amd/amdgpu/Makefile | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/amd/amdgpu/Makefile b/drivers/gpu/drm/amd/amdgpu/Makefile index 34943b866687..64adadb56fd6 100644 --- a/drivers/gpu/drm/amd/amdgpu/Makefile +++ b/drivers/gpu/drm/amd/amdgpu/Makefile @@ -41,6 +41,7 @@ ccflags-y := -I$(FULL_AMD_PATH)/include/asic_reg \ # Locally disable W=1 warnings enabled in drm subsystem Makefile subdir-ccflags-y += -Wno-override-init +subdir-ccflags-y += $(call cc-option, -Wformat-truncation) subdir-ccflags-$(CONFIG_DRM_AMDGPU_WERROR) += -Werror amdgpu-y := amdgpu_drv.o -- 2.46.0
Re: [PATCH 3/3] drm/amdgpu: drop redundant W=1 warnings from Makefile
On 5/23/24 09:37, Jani Nikula wrote:
Since commit a61ddb4393ad ("drm: enable (most) W=1 warnings by default
across the subsystem"), most of the extra warnings in the driver
Makefile are redundant. Remove them.
Note that -Wmissing-declarations and -Wmissing-prototypes are always
enabled by default in scripts/Makefile.extrawarn.
Signed-off-by: Jani Nikula
Sorry, it took me so long to get to this. But, I guess as they say,
better late than never.
Applied, thanks!
---
drivers/gpu/drm/amd/amdgpu/Makefile | 18 +-
1 file changed, 1 insertion(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/Makefile
b/drivers/gpu/drm/amd/amdgpu/Makefile
index 1f6b56ec99f6..9508d0b5708e 100644
--- a/drivers/gpu/drm/amd/amdgpu/Makefile
+++ b/drivers/gpu/drm/amd/amdgpu/Makefile
@@ -39,23 +39,7 @@ ccflags-y := -I$(FULL_AMD_PATH)/include/asic_reg \
-I$(FULL_AMD_DISPLAY_PATH)/amdgpu_dm \
-I$(FULL_AMD_PATH)/amdkfd
-subdir-ccflags-y := -Wextra
-subdir-ccflags-y += -Wunused
-subdir-ccflags-y += -Wmissing-prototypes
-subdir-ccflags-y += -Wmissing-declarations
-subdir-ccflags-y += -Wmissing-include-dirs
-subdir-ccflags-y += -Wold-style-definition
-subdir-ccflags-y += -Wmissing-format-attribute
-# Need this to avoid recursive variable evaluation issues
-cond-flags := $(call cc-option, -Wunused-but-set-variable) \
- $(call cc-option, -Wunused-const-variable) \
- $(call cc-option, -Wstringop-truncation) \
- $(call cc-option, -Wpacked-not-aligned)
-subdir-ccflags-y += $(cond-flags)
-subdir-ccflags-y += -Wno-unused-parameter
-subdir-ccflags-y += -Wno-type-limits
-subdir-ccflags-y += -Wno-sign-compare
-subdir-ccflags-y += -Wno-missing-field-initializers
+# Locally disable W=1 warnings enabled in drm subsystem Makefile
subdir-ccflags-y += -Wno-override-init
subdir-ccflags-$(CONFIG_DRM_AMDGPU_WERROR) += -Werror
--
Hamza
Re: [RESEND 3/3] drm/amd/display: switch to guid_gen() to generate valid GUIDs
On 8/28/24 10:06, Jani Nikula wrote:
On Wed, 28 Aug 2024, Hamza Mahfooz wrote:
On 8/12/24 08:23, Jani Nikula wrote:
Instead of just smashing jiffies into a GUID, use guid_gen() to generate
RFC 4122 compliant GUIDs.
Signed-off-by: Jani Nikula
---
Acked-by: Hamza Mahfooz
I would prefer to take this series through the amdgpu tree though,
assuming nobody minds.
How long is it going to take for that to get synced back to
drm-misc-next though?
It might take awhile, so it's probably best to merge it through
drm-misc-next.
BR,
Jani.
Side note, it baffles me why amdgpu has a copy of this instead of
plumbing it into drm mst code.
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 23 ++-
1 file changed, 12 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 72c10fc2c890..ce05e7e2a383 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -2568,9 +2568,9 @@ static int dm_late_init(void *handle)
static void resume_mst_branch_status(struct drm_dp_mst_topology_mgr *mgr)
{
+ u8 buf[UUID_SIZE];
+ guid_t guid;
int ret;
- u8 guid[16];
- u64 tmp64;
mutex_lock(&mgr->lock);
if (!mgr->mst_primary)
@@ -2591,26 +2591,27 @@ static void resume_mst_branch_status(struct
drm_dp_mst_topology_mgr *mgr)
}
/* Some hubs forget their guids after they resume */
- ret = drm_dp_dpcd_read(mgr->aux, DP_GUID, guid, 16);
- if (ret != 16) {
+ ret = drm_dp_dpcd_read(mgr->aux, DP_GUID, buf, sizeof(buf));
+ if (ret != sizeof(buf)) {
drm_dbg_kms(mgr->dev, "dpcd read failed - undocked during
suspend?\n");
goto out_fail;
}
- if (memchr_inv(guid, 0, 16) == NULL) {
- tmp64 = get_jiffies_64();
- memcpy(&guid[0], &tmp64, sizeof(u64));
- memcpy(&guid[8], &tmp64, sizeof(u64));
+ import_guid(&guid, buf);
- ret = drm_dp_dpcd_write(mgr->aux, DP_GUID, guid, 16);
+ if (guid_is_null(&guid)) {
+ guid_gen(&guid);
+ export_guid(buf, &guid);
- if (ret != 16) {
+ ret = drm_dp_dpcd_write(mgr->aux, DP_GUID, buf, sizeof(buf));
+
+ if (ret != sizeof(buf)) {
drm_dbg_kms(mgr->dev, "check mstb guid failed - undocked
during suspend?\n");
goto out_fail;
}
}
- import_guid(&mgr->mst_primary->guid, guid);
+ guid_copy(&mgr->mst_primary->guid, &guid);
out_fail:
mutex_unlock(&mgr->lock);
--
Hamza
Re: [RESEND 3/3] drm/amd/display: switch to guid_gen() to generate valid GUIDs
On 8/12/24 08:23, Jani Nikula wrote:
Instead of just smashing jiffies into a GUID, use guid_gen() to generate
RFC 4122 compliant GUIDs.
Signed-off-by: Jani Nikula
---
Acked-by: Hamza Mahfooz
I would prefer to take this series through the amdgpu tree though,
assuming nobody minds.
Side note, it baffles me why amdgpu has a copy of this instead of
plumbing it into drm mst code.
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 23 ++-
1 file changed, 12 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 72c10fc2c890..ce05e7e2a383 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -2568,9 +2568,9 @@ static int dm_late_init(void *handle)
static void resume_mst_branch_status(struct drm_dp_mst_topology_mgr *mgr)
{
+ u8 buf[UUID_SIZE];
+ guid_t guid;
int ret;
- u8 guid[16];
- u64 tmp64;
mutex_lock(&mgr->lock);
if (!mgr->mst_primary)
@@ -2591,26 +2591,27 @@ static void resume_mst_branch_status(struct
drm_dp_mst_topology_mgr *mgr)
}
/* Some hubs forget their guids after they resume */
- ret = drm_dp_dpcd_read(mgr->aux, DP_GUID, guid, 16);
- if (ret != 16) {
+ ret = drm_dp_dpcd_read(mgr->aux, DP_GUID, buf, sizeof(buf));
+ if (ret != sizeof(buf)) {
drm_dbg_kms(mgr->dev, "dpcd read failed - undocked during
suspend?\n");
goto out_fail;
}
- if (memchr_inv(guid, 0, 16) == NULL) {
- tmp64 = get_jiffies_64();
- memcpy(&guid[0], &tmp64, sizeof(u64));
- memcpy(&guid[8], &tmp64, sizeof(u64));
+ import_guid(&guid, buf);
- ret = drm_dp_dpcd_write(mgr->aux, DP_GUID, guid, 16);
+ if (guid_is_null(&guid)) {
+ guid_gen(&guid);
+ export_guid(buf, &guid);
- if (ret != 16) {
+ ret = drm_dp_dpcd_write(mgr->aux, DP_GUID, buf, sizeof(buf));
+
+ if (ret != sizeof(buf)) {
drm_dbg_kms(mgr->dev, "check mstb guid failed - undocked
during suspend?\n");
goto out_fail;
}
}
- import_guid(&mgr->mst_primary->guid, guid);
+ guid_copy(&mgr->mst_primary->guid, &guid);
out_fail:
mutex_unlock(&mgr->lock);
--
Hamza
Re: [PATCH v2 65/86] drm/amdgpu: Run DRM default client setup
On 8/21/24 09:00, Thomas Zimmermann wrote:
Call drm_client_setup() to run the kernel's default client setup
for DRM. Set fbdev_probe in struct drm_driver, so that the client
setup can start the common fbdev client.
The amdgpu driver specifies a preferred color mode depending on
the available video memory, with a default of 32. Adapt this for
the new client interface.
v2:
- style changes
Signed-off-by: Thomas Zimmermann
Cc: Alex Deucher
Cc: "Christian König"
Cc: Xinhui Pan
Tested-by: Hamza Mahfooz
Acked-by: Hamza Mahfooz
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 5dd39e6c6223..849d59e2bca7 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -23,6 +23,7 @@
*/
#include
+#include
#include
#include
#include
@@ -2341,11 +2342,15 @@ static int amdgpu_pci_probe(struct pci_dev *pdev,
*/
if (adev->mode_info.mode_config_initialized &&
!list_empty(&adev_to_drm(adev)->mode_config.connector_list)) {
+ const struct drm_format_info *format;
+
/* select 8 bpp console on low vram cards */
if (adev->gmc.real_vram_size <= (32*1024*1024))
- drm_fbdev_ttm_setup(adev_to_drm(adev), 8);
+ format = drm_format_info(DRM_FORMAT_C8);
else
- drm_fbdev_ttm_setup(adev_to_drm(adev), 32);
+ format = NULL;
+
+ drm_client_setup(adev_to_drm(adev), format);
}
ret = amdgpu_debugfs_init(adev);
@@ -2957,6 +2962,7 @@ static const struct drm_driver amdgpu_kms_driver = {
.num_ioctls = ARRAY_SIZE(amdgpu_ioctls_kms),
.dumb_create = amdgpu_mode_dumb_create,
.dumb_map_offset = amdgpu_mode_dumb_mmap,
+ DRM_FBDEV_TTM_DRIVER_OPS,
.fops = &amdgpu_driver_kms_fops,
.release = &amdgpu_driver_release_kms,
#ifdef CONFIG_PROC_FS
@@ -2983,6 +2989,7 @@ const struct drm_driver amdgpu_partition_driver = {
.num_ioctls = ARRAY_SIZE(amdgpu_ioctls_kms),
.dumb_create = amdgpu_mode_dumb_create,
.dumb_map_offset = amdgpu_mode_dumb_mmap,
+ DRM_FBDEV_TTM_DRIVER_OPS,
.fops = &amdgpu_driver_kms_fops,
.release = &amdgpu_driver_release_kms,
--
Hamza
Re: [PATCH v6 2/4] drm/rect: Add drm_rect_overlap()
On 8/12/24 09:49, Jani Nikula wrote:
On Mon, 12 Aug 2024, Jocelyn Falempe wrote:
Check if two rectangles overlap.
It's a bit similar to drm_rect_intersect() but this won't modify
the rectangle.
Simplifies a bit drm_panic.
Based on the name, I'd expect drm_rect_overlap() to return true for
*any* overlap, while this one seems to mean if one rectangle is
completely within another, with no adjacent borders.
I'd expect a drm_rect_overlap() to return true for this:
+---+
| +---+---+
| | |
+---+ |
| |
+---+
While this seems to be required instead:
+---+
| +---+ |
| | | |
| +---+ |
+---+
IOW, I find the name misleading.
Ya, maybe drm_rect_encloses() would be a better fit.
BR,
Jani.
Signed-off-by: Jocelyn Falempe
---
drivers/gpu/drm/drm_panic.c | 3 +--
include/drm/drm_rect.h | 15 +++
2 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_panic.c b/drivers/gpu/drm/drm_panic.c
index 0a047152f88b8..59fba23e5fd7a 100644
--- a/drivers/gpu/drm/drm_panic.c
+++ b/drivers/gpu/drm/drm_panic.c
@@ -529,8 +529,7 @@ static void draw_panic_static_user(struct
drm_scanout_buffer *sb)
/* Fill with the background color, and draw text on top */
drm_panic_fill(sb, &r_screen, bg_color);
- if ((r_msg.x1 >= logo_width || r_msg.y1 >= logo_height) &&
- logo_width <= sb->width && logo_height <= sb->height) {
+ if (!drm_rect_overlap(&r_logo, &r_msg)) {
if (logo_mono)
drm_panic_blit(sb, &r_logo, logo_mono->data,
DIV_ROUND_UP(logo_width, 8),
fg_color);
diff --git a/include/drm/drm_rect.h b/include/drm/drm_rect.h
index 73fcb899a01da..7bafde747d560 100644
--- a/include/drm/drm_rect.h
+++ b/include/drm/drm_rect.h
@@ -238,6 +238,21 @@ static inline void drm_rect_fp_to_int(struct drm_rect *dst,
drm_rect_height(src) >> 16);
}
+/**
+ * drm_rect_overlap - Check if two rectangles overlap
+ * @r1: first rectangle
+ * @r2: second rectangle
+ *
+ * RETURNS:
+ * %true if the rectangles overlap, %false otherwise.
If you do end up going with that name, the returns doc ought to be:
%true if @r2 is completely enclosed in @r1, %false otherwise.
+ */
+static inline bool drm_rect_overlap(const struct drm_rect *r1,
+ const struct drm_rect *r2)
+{
+ return (r1->x2 > r2->x1 && r2->x2 > r1->x1 &&
+ r1->y2 > r2->y1 && r2->y2 > r1->y1);
+}
+
bool drm_rect_intersect(struct drm_rect *r, const struct drm_rect *clip);
bool drm_rect_clip_scaled(struct drm_rect *src, struct drm_rect *dst,
const struct drm_rect *clip);
--
Hamza
Re: [PATCH v2] kerneldoc: Fix two missing newlines in drm_connector.c
On 8/8/24 23:23, Daniel Yang wrote: Fix the unexpected indentation errors. drm_connector.c has some kerneldoc comments that were missing newlines. This results in the following warnings when running make htmldocs: ./Documentation/gpu/drm-kms:538: ./drivers/gpu/drm/drm_connector.c:2344: WARNING: Definition list ends without a blank line; unexpected unindent. [docutils] ./Documentation/gpu/drm-kms:538: ./drivers/gpu/drm/drm_connector.c:2346: ERROR: Unexpected indentation. [docutils] ./Documentation/gpu/drm-kms:538: ./drivers/gpu/drm/drm_connector.c:2368: WARNING: Block quote ends without a blank line; unexpected unindent. [docutils] ./Documentation/gpu/drm-kms:538: ./drivers/gpu/drm/drm_connector.c:2381: ERROR: Unexpected indentation. [docutils] Signed-off-by: Daniel Yang Applied, thanks! --- Notes: v2: added "Fix the unexpected indentation errors" line to description. drivers/gpu/drm/drm_connector.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c index 80e239a6493..fc35f47e284 100644 --- a/drivers/gpu/drm/drm_connector.c +++ b/drivers/gpu/drm/drm_connector.c @@ -2342,7 +2342,9 @@ EXPORT_SYMBOL(drm_mode_create_aspect_ratio_property); * *Default: *The behavior is driver-specific. + * *BT2020_RGB: + * *BT2020_YCC: *User space configures the pixel operation properties to produce *RGB content with Rec. ITU-R BT.2020 colorimetry, Rec. @@ -2366,6 +2368,7 @@ EXPORT_SYMBOL(drm_mode_create_aspect_ratio_property); *range. *The variants BT2020_RGB and BT2020_YCC are equivalent and the *driver chooses between RGB and YCbCr on its own. + * *SMPTE_170M_YCC: *BT709_YCC: *XVYCC_601: @@ -2378,6 +2381,7 @@ EXPORT_SYMBOL(drm_mode_create_aspect_ratio_property); *DCI-P3_RGB_Theater: *RGB_WIDE_FIXED: *RGB_WIDE_FLOAT: + * *BT601_YCC: *The behavior is undefined. * -- Hamza
Re: [PATCH v2] drm/edid: add CTA Video Format Data Block support
Ping?
On 8/2/24 11:53, Hamza Mahfooz wrote:
On 8/1/24 03:35, Jani Nikula wrote:
On Wed, 31 Jul 2024, Hamza Mahfooz wrote:
Video Format Data Blocks (VFDBs) contain the necessary information that
needs to be fed to the Optimized Video Timings (OVT) Algorithm.
Also, we require OVT support to cover modes that aren't supported by
earlier standards (e.g. CVT). So, parse all of the relevant VFDB data
and feed it to the OVT Algorithm, to extract all of the missing OVT
modes.
Suggested-by: Karol Herbst
Signed-off-by: Hamza Mahfooz
---
v2: address comments from Jani
---
drivers/gpu/drm/drm_edid.c | 456 ++---
1 file changed, 428 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index f68a41eeb1fa..f608ab4e32ae 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -741,6 +742,93 @@ static const struct minimode extra_modes[] = {
{ 2048, 1536, 60, 0 },
};
+struct cta_rid {
+ u16 hactive;
+ u16 vactive;
+ u8 hratio;
+ u8 vratio;
+};
+
+/* CTA-861-I Table 11 - Resolution Identification (RID) */
+static const struct cta_rid rids[] = {
+ /* RID 0-9 */
+ { 0, 0, 0, 0 },
+ { 1280, 720, 16, 9 },
+ { 1280, 720, 64, 27 },
+ { 1680, 720, 64, 27 },
+ { 1920, 1080, 16, 9 },
+ { 1920, 1080, 64, 27 },
+ { 2560, 1080, 64, 27 },
+ { 3840, 1080, 32, 9 },
+ { 2560, 1440, 16, 9 },
+ { 3440, 1440, 64, 27 },
+ /* RID 10-19 */
+ { 5120, 1440, 32, 9 },
+ { 3840, 2160, 16, 9 },
+ { 3840, 2160, 64, 27 },
+ { 5120, 2160, 64, 27 },
+ { 7680, 2160, 32, 9 },
+ { 5120, 2880, 16, 9 },
+ { 5120, 2880, 64, 27 },
+ { 6880, 2880, 64, 27 },
+ { 10240, 2880, 32, 9 },
+ { 7680, 4320, 16, 9 },
+ /* RID 20-28 */
+ { 7680, 4320, 64, 27 },
+ { 10240, 4320, 64, 27 },
+ { 15360, 4320, 32, 9 },
+ { 11520, 6480, 16, 9 },
+ { 11520, 6480, 64, 27 },
+ { 15360, 6480, 64, 27 },
+ { 15360, 8640, 16, 9 },
+ { 15360, 8640, 64, 27 },
+ { 20480, 8640, 64, 27 },
+};
+
+/* CTA-861-I Table 12 - AVI InfoFrame Video Format Frame Rate */
+static const u16 cta_vf_fr[] = {
+ /* Frame Rate 0-7 */
+ 0, 24, 25, 30, 48, 50, 60, 100,
+ /* Frame Rate 8-15 */
+ 120, 144, 200, 240, 300, 360, 400, 480,
+};
+
+/* CTA-861-I Table 13 - RID To VIC Mapping */
+static const u8 rid_to_vic[][8] = {
+ /* RID 0-9 */
+ {},
+ { 60, 61, 62, 108, 19, 4, 41, 47 },
+ { 65, 66, 67, 109, 68, 69, 70, 71 },
+ { 79, 80, 81, 110, 82, 83, 84, 85 },
+ { 32, 33, 34, 111, 31, 16, 64, 63 },
+ { 72, 73, 74, 112, 75, 76, 77, 78 },
+ { 86, 87, 88, 113, 89, 90, 91, 92 },
+ {},
+ {},
+ {},
+ /* RID 10-19 */
+ {},
+ { 93, 94, 95, 114, 96, 97, 117, 118 },
+ { 103, 104, 105, 116, 106, 107, 119, 120 },
+ { 121, 122, 123, 124, 125, 126, 127, 193 },
+ {},
+ {},
+ {},
+ {},
+ {},
+ { 194, 195, 196, 197, 198, 199, 200, 201 },
+ /* RID 20-28 */
+ { 202, 203, 204, 205, 206, 207, 208, 209 },
+ { 210, 211, 212, 213, 214, 215, 216, 217 },
+ {},
+ {},
+ {},
+ {},
+ {},
+ {},
+ {},
+};
+
/*
* From CEA/CTA-861 spec.
*
@@ -4140,6 +4228,7 @@ static int add_detailed_modes(struct
drm_connector *connector,
#define CTA_DB_VIDEO 2
#define CTA_DB_VENDOR 3
#define CTA_DB_SPEAKER 4
+#define CTA_DB_VIDEO_FORMAT 6
#define CTA_DB_EXTENDED_TAG 7
/* CTA-861-H Table 62 - CTA Extended Tag Codes */
@@ -4981,6 +5070,16 @@ struct cea_db {
u8 data[];
} __packed;
+struct cta_vfd {
+ u8 rid;
+ u8 fr_fact;
+ bool bfr50;
+ bool fr24;
+ bool bfr60;
+ bool fr144;
+ bool fr48;
+};
+
static int cea_db_tag(const struct cea_db *db)
{
return db->tag_length >> 5;
@@ -5306,34 +5405,6 @@ static void parse_cta_y420cmdb(struct
drm_connector *connector,
*y420cmdb_map = map;
}
-static int add_cea_modes(struct drm_connector *connector,
- const struct drm_edid *drm_edid)
-{
- const struct cea_db *db;
- struct cea_db_iter iter;
- int modes;
-
- /* CTA VDB block VICs parsed earlier */
- modes = add_cta_vdb_modes(connector);
-
- cea_db_iter_edid_begin(drm_edid, &iter);
- cea_db_iter_for_each(db, &iter) {
- if (cea_db_is_hdmi_vsdb(db)) {
- modes += do_hdmi_vsdb_modes(connector, (const u8 *)db,
- cea_db_payload_len(db));
- } else if (cea_db_is_y420vdb(db)) {
- const u8 *vdb420 = cea_db_data(db) + 1;
-
- /* Add 4:2:0(only) modes present in EDID */
- modes += do_y420vdb_modes(connector, vdb420,
- cea_db_payload_len(db) - 1);
- }
- }
- cea_db_iter_end(&iter);
-
- return modes;
-}
-
Is there anything that really requires moving add_cea_modes() down? Y
Re: [PATCH v2] drm/edid: add CTA Video Format Data Block support
On 8/1/24 03:35, Jani Nikula wrote:
On Wed, 31 Jul 2024, Hamza Mahfooz wrote:
Video Format Data Blocks (VFDBs) contain the necessary information that
needs to be fed to the Optimized Video Timings (OVT) Algorithm.
Also, we require OVT support to cover modes that aren't supported by
earlier standards (e.g. CVT). So, parse all of the relevant VFDB data
and feed it to the OVT Algorithm, to extract all of the missing OVT
modes.
Suggested-by: Karol Herbst
Signed-off-by: Hamza Mahfooz
---
v2: address comments from Jani
---
drivers/gpu/drm/drm_edid.c | 456 ++---
1 file changed, 428 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index f68a41eeb1fa..f608ab4e32ae 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -741,6 +742,93 @@ static const struct minimode extra_modes[] = {
{ 2048, 1536, 60, 0 },
};
+struct cta_rid {
+ u16 hactive;
+ u16 vactive;
+ u8 hratio;
+ u8 vratio;
+};
+
+/* CTA-861-I Table 11 - Resolution Identification (RID) */
+static const struct cta_rid rids[] = {
+ /* RID 0-9 */
+ { 0, 0, 0, 0 },
+ { 1280, 720, 16, 9 },
+ { 1280, 720, 64, 27 },
+ { 1680, 720, 64, 27 },
+ { 1920, 1080, 16, 9 },
+ { 1920, 1080, 64, 27 },
+ { 2560, 1080, 64, 27 },
+ { 3840, 1080, 32, 9 },
+ { 2560, 1440, 16, 9 },
+ { 3440, 1440, 64, 27 },
+ /* RID 10-19 */
+ { 5120, 1440, 32, 9 },
+ { 3840, 2160, 16, 9 },
+ { 3840, 2160, 64, 27 },
+ { 5120, 2160, 64, 27 },
+ { 7680, 2160, 32, 9 },
+ { 5120, 2880, 16, 9 },
+ { 5120, 2880, 64, 27 },
+ { 6880, 2880, 64, 27 },
+ { 10240, 2880, 32, 9 },
+ { 7680, 4320, 16, 9 },
+ /* RID 20-28 */
+ { 7680, 4320, 64, 27 },
+ { 10240, 4320, 64, 27 },
+ { 15360, 4320, 32, 9 },
+ { 11520, 6480, 16, 9 },
+ { 11520, 6480, 64, 27 },
+ { 15360, 6480, 64, 27 },
+ { 15360, 8640, 16, 9 },
+ { 15360, 8640, 64, 27 },
+ { 20480, 8640, 64, 27 },
+};
+
+/* CTA-861-I Table 12 - AVI InfoFrame Video Format Frame Rate */
+static const u16 cta_vf_fr[] = {
+ /* Frame Rate 0-7 */
+ 0, 24, 25, 30, 48, 50, 60, 100,
+ /* Frame Rate 8-15 */
+ 120, 144, 200, 240, 300, 360, 400, 480,
+};
+
+/* CTA-861-I Table 13 - RID To VIC Mapping */
+static const u8 rid_to_vic[][8] = {
+ /* RID 0-9 */
+ {},
+ { 60, 61, 62, 108, 19, 4, 41, 47 },
+ { 65, 66, 67, 109, 68, 69, 70, 71 },
+ { 79, 80, 81, 110, 82, 83, 84, 85 },
+ { 32, 33, 34, 111, 31, 16, 64, 63 },
+ { 72, 73, 74, 112, 75, 76, 77, 78 },
+ { 86, 87, 88, 113, 89, 90, 91, 92 },
+ {},
+ {},
+ {},
+ /* RID 10-19 */
+ {},
+ { 93, 94, 95, 114, 96, 97, 117, 118 },
+ { 103, 104, 105, 116, 106, 107, 119, 120 },
+ { 121, 122, 123, 124, 125, 126, 127, 193 },
+ {},
+ {},
+ {},
+ {},
+ {},
+ { 194, 195, 196, 197, 198, 199, 200, 201 },
+ /* RID 20-28 */
+ { 202, 203, 204, 205, 206, 207, 208, 209 },
+ { 210, 211, 212, 213, 214, 215, 216, 217 },
+ {},
+ {},
+ {},
+ {},
+ {},
+ {},
+ {},
+};
+
/*
* From CEA/CTA-861 spec.
*
@@ -4140,6 +4228,7 @@ static int add_detailed_modes(struct drm_connector
*connector,
#define CTA_DB_VIDEO 2
#define CTA_DB_VENDOR 3
#define CTA_DB_SPEAKER4
+#define CTA_DB_VIDEO_FORMAT6
#define CTA_DB_EXTENDED_TAG 7
/* CTA-861-H Table 62 - CTA Extended Tag Codes */
@@ -4981,6 +5070,16 @@ struct cea_db {
u8 data[];
} __packed;
+struct cta_vfd {
+ u8 rid;
+ u8 fr_fact;
+ bool bfr50;
+ bool fr24;
+ bool bfr60;
+ bool fr144;
+ bool fr48;
+};
+
static int cea_db_tag(const struct cea_db *db)
{
return db->tag_length >> 5;
@@ -5306,34 +5405,6 @@ static void parse_cta_y420cmdb(struct drm_connector
*connector,
*y420cmdb_map = map;
}
-static int add_cea_modes(struct drm_connector *connector,
-const struct drm_edid *drm_edid)
-{
- const struct cea_db *db;
- struct cea_db_iter iter;
- int modes;
-
- /* CTA VDB block VICs parsed earlier */
- modes = add_cta_vdb_modes(connector);
-
- cea_db_iter_edid_begin(drm_edid, &iter);
- cea_db_iter_for_each(db, &iter) {
- if (cea_db_is_hdmi_vsdb(db)) {
- modes += do_hdmi_vsdb_modes(connector, (const u8 *)db,
- cea_db_payload_len(db));
- } else if (cea_db_is_y420vdb(db)) {
- const u8 *vdb420
Re: [REGRESSION] Brightness at max level after waking up from sleep on AMD Laptop
On 7/31/24 02:38, Linux regression tracking (Thorsten Leemhuis) wrote:
[+amd-glx, +lkml, +dri-devel]
On 27.07.24 18:52, serg.parti...@gmail.com wrote:
After updating from 6.8.9 to 6.9.1 I noticed a bug on my HP Envy x360
with AMD Ryzen 5 4500U.
[...]
After waking up from sleep brightness is set to max level, ignoring
previous value.
With the help of Arch Linux team, we was able to track bad commit to
this:
https://gitlab.freedesktop.org/agd5f/linux/-/commit/63d0b87213a0ba241b3fcfba3fe7b0aed0cd1cc5
Hamza Mahfooz, in case you missed it, that is a patch of yours:
63d0b87213a0ba ("drm/amd/display: add panel_power_savings sysfs entry to
eDP connectors") [v6.9-rc1].
Um, for the time being you should be able to set `amdgpu.abmlevel=0` in
the kernel's cmdline to avoid the issue.
I have tested this on latest mainline kernel:
Results after waking up:
cat /sys/class/backlight/amdgpu_bl1/{brightness,actual_brightness}
12
252
Then, on exact this commit (63d0b87213a0ba241b3fcfba3fe7b0aed0cd1cc5),
result is the same.
Then, on commit just before this one (aeaf3e6cf842):
cat /sys/class/backlight/amdgpu_bl1/{brightness,actual_brightness}
12
12
I hope I included all relevant information, more info can be found here:
https://gitlab.archlinux.org/archlinux/packaging/packages/linux/-/issues/52
Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
--
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtracking.leemhuis.info/about/#tldr
If I did something stupid, please tell me, as explained on that page.
P.S.:
#regzbot introduced: 63d0b87213a0ba241
--
Hamza
[PATCH 2/2] Revert "drm/amd: Add power_saving_policy drm property to eDP connectors"
This reverts commit 9d8c094ddab05db88d183ba82e23be807848cad8.
It was merged without meeting userspace requirements.
Signed-off-by: Hamza Mahfooz
---
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 4 --
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 52 ++-
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 2 -
3 files changed, 5 insertions(+), 53 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
index 879b4a04c588..092ec11258cd 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
@@ -1407,10 +1407,6 @@ int amdgpu_display_modeset_create_props(struct
amdgpu_device *adev)
"dither",
amdgpu_dither_enum_list, sz);
- if (adev->dc_enabled)
- drm_mode_create_power_saving_policy_property(adev_to_drm(adev),
-
DRM_MODE_POWER_SAVING_POLICY_ALL);
-
return 0;
}
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 0ce983ab5d65..7e7929f24ae4 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -6725,14 +6725,6 @@ int amdgpu_dm_connector_atomic_set_property(struct
drm_connector *connector,
} else if (property == adev->mode_info.underscan_property) {
dm_new_state->underscan_enable = val;
ret = 0;
- } else if (property == dev->mode_config.power_saving_policy) {
- dm_new_state->abm_forbidden = val &
DRM_MODE_REQUIRE_COLOR_ACCURACY;
- dm_new_state->abm_level = (dm_new_state->abm_forbidden ||
- !dm_old_state->abm_level) ?
- ABM_LEVEL_IMMEDIATE_DISABLE :
- dm_old_state->abm_level;
- dm_new_state->psr_forbidden = val &
DRM_MODE_REQUIRE_LOW_LATENCY;
- ret = 0;
}
return ret;
@@ -6775,13 +6767,6 @@ int amdgpu_dm_connector_atomic_get_property(struct
drm_connector *connector,
} else if (property == adev->mode_info.underscan_property) {
*val = dm_state->underscan_enable;
ret = 0;
- } else if (property == dev->mode_config.power_saving_policy) {
- *val = 0;
- if (dm_state->psr_forbidden)
- *val |= DRM_MODE_REQUIRE_LOW_LATENCY;
- if (dm_state->abm_forbidden)
- *val |= DRM_MODE_REQUIRE_COLOR_ACCURACY;
- ret = 0;
}
return ret;
@@ -6808,12 +6793,9 @@ static ssize_t panel_power_savings_show(struct device
*device,
u8 val;
drm_modeset_lock(&dev->mode_config.connection_mutex, NULL);
- if (to_dm_connector_state(connector->state)->abm_forbidden)
- val = 0;
- else
- val = to_dm_connector_state(connector->state)->abm_level ==
- ABM_LEVEL_IMMEDIATE_DISABLE ? 0 :
- to_dm_connector_state(connector->state)->abm_level;
+ val = to_dm_connector_state(connector->state)->abm_level ==
+ ABM_LEVEL_IMMEDIATE_DISABLE ? 0 :
+ to_dm_connector_state(connector->state)->abm_level;
drm_modeset_unlock(&dev->mode_config.connection_mutex);
return sysfs_emit(buf, "%u\n", val);
@@ -6837,16 +6819,10 @@ static ssize_t panel_power_savings_store(struct device
*device,
return -EINVAL;
drm_modeset_lock(&dev->mode_config.connection_mutex, NULL);
- if (to_dm_connector_state(connector->state)->abm_forbidden)
- ret = -EBUSY;
- else
- to_dm_connector_state(connector->state)->abm_level = val ?:
- ABM_LEVEL_IMMEDIATE_DISABLE;
+ to_dm_connector_state(connector->state)->abm_level = val ?:
+ ABM_LEVEL_IMMEDIATE_DISABLE;
drm_modeset_unlock(&dev->mode_config.connection_mutex);
- if (ret)
- return ret;
-
drm_kms_helper_hotplug_event(dev);
return count;
@@ -8040,14 +8016,6 @@ void amdgpu_dm_connector_init_helper(struct
amdgpu_display_manager *dm,
aconnector->base.state->max_bpc = 16;
aconnector->base.state->max_requested_bpc =
aconnector->base.state->max_bpc;
- if (connector_type == DRM_MODE_CONNECTOR_eDP &&
- (dc_is_dmcu_initialized(adev->dm.dc) ||
-adev->dm.dc->ctx->dmub_srv)) {
- drm_object_attach_property(&aconnector->base.base,
-
[PATCH 1/2] Revert "drm: Introduce 'power saving policy' drm property"
This reverts commit 76299a557f36d624ca32500173ad7856e1ad93c0.
It was merged without meeting userspace requirements.
Signed-off-by: Hamza Mahfooz
---
drivers/gpu/drm/drm_connector.c | 48 -
include/drm/drm_connector.h | 2 --
include/drm/drm_mode_config.h | 5
include/uapi/drm/drm_mode.h | 7 -
4 files changed, 62 deletions(-)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 7c44e3a1d8e0..b4f4d2f908d1 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1043,11 +1043,6 @@ static const struct drm_prop_enum_list
drm_scaling_mode_enum_list[] = {
{ DRM_MODE_SCALE_ASPECT, "Full aspect" },
};
-static const struct drm_prop_enum_list drm_power_saving_policy_enum_list[] = {
- { __builtin_ffs(DRM_MODE_REQUIRE_COLOR_ACCURACY) - 1, "Require color
accuracy" },
- { __builtin_ffs(DRM_MODE_REQUIRE_LOW_LATENCY) - 1, "Require low
latency" },
-};
-
static const struct drm_prop_enum_list drm_aspect_ratio_enum_list[] = {
{ DRM_MODE_PICTURE_ASPECT_NONE, "Automatic" },
{ DRM_MODE_PICTURE_ASPECT_4_3, "4:3" },
@@ -1634,16 +1629,6 @@ EXPORT_SYMBOL(drm_hdmi_connector_get_output_format_name);
*
* Drivers can set up these properties by calling
* drm_mode_create_tv_margin_properties().
- * power saving policy:
- * This property is used to set the power saving policy for the connector.
- * This property is populated with a bitmask of optional requirements set
- * by the drm master for the drm driver to respect:
- * - "Require color accuracy": Disable power saving features that will
- * affect color fidelity.
- * For example: Hardware assisted backlight modulation.
- * - "Require low latency": Disable power saving features that will
- * affect latency.
- * For example: Panel self refresh (PSR)
*/
int drm_connector_create_standard_properties(struct drm_device *dev)
@@ -2146,39 +2131,6 @@ int drm_mode_create_scaling_mode_property(struct
drm_device *dev)
}
EXPORT_SYMBOL(drm_mode_create_scaling_mode_property);
-/**
- * drm_mode_create_power_saving_policy_property - create power saving policy
property
- * @dev: DRM device
- * @supported_policies: bitmask of supported power saving policies
- *
- * Called by a driver the first time it's needed, must be attached to desired
- * connectors.
- *
- * Returns: %0
- */
-int drm_mode_create_power_saving_policy_property(struct drm_device *dev,
-uint64_t supported_policies)
-{
- struct drm_property *power_saving;
-
- if (dev->mode_config.power_saving_policy)
- return 0;
- WARN_ON((supported_policies & DRM_MODE_POWER_SAVING_POLICY_ALL) == 0);
-
- power_saving =
- drm_property_create_bitmask(dev, 0, "power saving policy",
- drm_power_saving_policy_enum_list,
-
ARRAY_SIZE(drm_power_saving_policy_enum_list),
- supported_policies);
- if (!power_saving)
- return -ENOMEM;
-
- dev->mode_config.power_saving_policy = power_saving;
-
- return 0;
-}
-EXPORT_SYMBOL(drm_mode_create_power_saving_policy_property);
-
/**
* DOC: Variable refresh properties
*
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 5ad735253413..e3fa43291f44 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -2267,8 +2267,6 @@ int drm_mode_create_dp_colorspace_property(struct
drm_connector *connector,
u32 supported_colorspaces);
int drm_mode_create_content_type_property(struct drm_device *dev);
int drm_mode_create_suggested_offset_properties(struct drm_device *dev);
-int drm_mode_create_power_saving_policy_property(struct drm_device *dev,
-uint64_t supported_policies);
int drm_connector_set_path_property(struct drm_connector *connector,
const char *path);
diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
index 150f9a3b649f..ab0f167474b1 100644
--- a/include/drm/drm_mode_config.h
+++ b/include/drm/drm_mode_config.h
@@ -969,11 +969,6 @@ struct drm_mode_config {
*/
struct drm_atomic_state *suspend_state;
- /**
-* @power_saving_policy: bitmask for power saving policy requests.
-*/
- struct drm_property *power_saving_policy;
-
const struct drm_mode_config_helper_funcs *helper_private;
};
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 880303c2ad97..d390011b89b4 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -152,13 +152,
[PATCH v2] drm/edid: add CTA Video Format Data Block support
Video Format Data Blocks (VFDBs) contain the necessary information that
needs to be fed to the Optimized Video Timings (OVT) Algorithm.
Also, we require OVT support to cover modes that aren't supported by
earlier standards (e.g. CVT). So, parse all of the relevant VFDB data
and feed it to the OVT Algorithm, to extract all of the missing OVT
modes.
Suggested-by: Karol Herbst
Signed-off-by: Hamza Mahfooz
---
v2: address comments from Jani
---
drivers/gpu/drm/drm_edid.c | 456 ++---
1 file changed, 428 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index f68a41eeb1fa..f608ab4e32ae 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -741,6 +742,93 @@ static const struct minimode extra_modes[] = {
{ 2048, 1536, 60, 0 },
};
+struct cta_rid {
+ u16 hactive;
+ u16 vactive;
+ u8 hratio;
+ u8 vratio;
+};
+
+/* CTA-861-I Table 11 - Resolution Identification (RID) */
+static const struct cta_rid rids[] = {
+ /* RID 0-9 */
+ { 0, 0, 0, 0 },
+ { 1280, 720, 16, 9 },
+ { 1280, 720, 64, 27 },
+ { 1680, 720, 64, 27 },
+ { 1920, 1080, 16, 9 },
+ { 1920, 1080, 64, 27 },
+ { 2560, 1080, 64, 27 },
+ { 3840, 1080, 32, 9 },
+ { 2560, 1440, 16, 9 },
+ { 3440, 1440, 64, 27 },
+ /* RID 10-19 */
+ { 5120, 1440, 32, 9 },
+ { 3840, 2160, 16, 9 },
+ { 3840, 2160, 64, 27 },
+ { 5120, 2160, 64, 27 },
+ { 7680, 2160, 32, 9 },
+ { 5120, 2880, 16, 9 },
+ { 5120, 2880, 64, 27 },
+ { 6880, 2880, 64, 27 },
+ { 10240, 2880, 32, 9 },
+ { 7680, 4320, 16, 9 },
+ /* RID 20-28 */
+ { 7680, 4320, 64, 27 },
+ { 10240, 4320, 64, 27 },
+ { 15360, 4320, 32, 9 },
+ { 11520, 6480, 16, 9 },
+ { 11520, 6480, 64, 27 },
+ { 15360, 6480, 64, 27 },
+ { 15360, 8640, 16, 9 },
+ { 15360, 8640, 64, 27 },
+ { 20480, 8640, 64, 27 },
+};
+
+/* CTA-861-I Table 12 - AVI InfoFrame Video Format Frame Rate */
+static const u16 cta_vf_fr[] = {
+ /* Frame Rate 0-7 */
+ 0, 24, 25, 30, 48, 50, 60, 100,
+ /* Frame Rate 8-15 */
+ 120, 144, 200, 240, 300, 360, 400, 480,
+};
+
+/* CTA-861-I Table 13 - RID To VIC Mapping */
+static const u8 rid_to_vic[][8] = {
+ /* RID 0-9 */
+ {},
+ { 60, 61, 62, 108, 19, 4, 41, 47 },
+ { 65, 66, 67, 109, 68, 69, 70, 71 },
+ { 79, 80, 81, 110, 82, 83, 84, 85 },
+ { 32, 33, 34, 111, 31, 16, 64, 63 },
+ { 72, 73, 74, 112, 75, 76, 77, 78 },
+ { 86, 87, 88, 113, 89, 90, 91, 92 },
+ {},
+ {},
+ {},
+ /* RID 10-19 */
+ {},
+ { 93, 94, 95, 114, 96, 97, 117, 118 },
+ { 103, 104, 105, 116, 106, 107, 119, 120 },
+ { 121, 122, 123, 124, 125, 126, 127, 193 },
+ {},
+ {},
+ {},
+ {},
+ {},
+ { 194, 195, 196, 197, 198, 199, 200, 201 },
+ /* RID 20-28 */
+ { 202, 203, 204, 205, 206, 207, 208, 209 },
+ { 210, 211, 212, 213, 214, 215, 216, 217 },
+ {},
+ {},
+ {},
+ {},
+ {},
+ {},
+ {},
+};
+
/*
* From CEA/CTA-861 spec.
*
@@ -4140,6 +4228,7 @@ static int add_detailed_modes(struct drm_connector
*connector,
#define CTA_DB_VIDEO 2
#define CTA_DB_VENDOR 3
#define CTA_DB_SPEAKER 4
+#define CTA_DB_VIDEO_FORMAT6
#define CTA_DB_EXTENDED_TAG7
/* CTA-861-H Table 62 - CTA Extended Tag Codes */
@@ -4981,6 +5070,16 @@ struct cea_db {
u8 data[];
} __packed;
+struct cta_vfd {
+ u8 rid;
+ u8 fr_fact;
+ bool bfr50;
+ bool fr24;
+ bool bfr60;
+ bool fr144;
+ bool fr48;
+};
+
static int cea_db_tag(const struct cea_db *db)
{
return db->tag_length >> 5;
@@ -5306,34 +5405,6 @@ static void parse_cta_y420cmdb(struct drm_connector
*connector,
*y420cmdb_map = map;
}
-static int add_cea_modes(struct drm_connector *connector,
-const struct drm_edid *drm_edid)
-{
- const struct cea_db *db;
- struct cea_db_iter iter;
- int modes;
-
- /* CTA VDB block VICs parsed earlier */
- modes = add_cta_vdb_modes(connector);
-
- cea_db_iter_edid_begin(drm_edid, &iter);
- cea_db_iter_for_each(db, &iter) {
- if (cea_db_is_hdmi_vsdb(db)) {
- modes += do_hdmi_vsdb_modes(connector, (const u8 *)db,
- cea_db_payload_len(db));
- } else if (cea_db_is_y420vdb(db)) {
- const u8 *vdb420 = cea_db_data(db) + 1;
-
- /* Add 4:2:0(only) modes present in EDID */
- mod
Re: [PATCH] drm/edid: add CTA Video Format Data Block support
On 7/31/24 04:36, Jani Nikula wrote:
On Tue, 30 Jul 2024, Hamza Mahfooz wrote:
Video Format Data Blocks (VFDBs) contain the necessary information that
needs to be fed to the Optimized Video Timings (OVT) Algorithm.
Also, we require OVT support to cover modes that aren't supported by
earlier standards (e.g. CVT). So, parse all of the relevant VFDB data
and feed it to the OVT Algorithm, to extract all of the missing OVT
modes.
Is VFDB new to CTA-861-I? AFAICT the H version doesn't have it.
I believe it first appeared in CTA-861.6.
Is there any particular reason for the two step approach here? I mean
first allocating and storing the modes in drm_parse_cea_ext() and then
adding them in _drm_edid_connector_add_modes()? I think you could just
as well do everything in the latter, without the complications of
allocation. See e.g. add_cea_modes() which also iterates the CTA data
blocks. I think this would simplify everything considerably.
It just seemed like the logical place to put it I guess. But looking at
it again, it would make more sense to just do everything in
_drm_edid_connector_add_modes().
Please find some additional comments inline. I'll do more when I've got
hold of CTA-861-I.
BR,
Jani.
Link: https://gitlab.freedesktop.org/drm/amd/-/issues/1442
Suggested-by: Karol Herbst
Signed-off-by: Hamza Mahfooz
---
drivers/gpu/drm/drm_edid.c | 426
include/drm/drm_connector.h | 12 +
2 files changed, 438 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index f68a41eeb1fa..112a0070c4d5 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -741,6 +742,93 @@ static const struct minimode extra_modes[] = {
{ 2048, 1536, 60, 0 },
};
+struct cta_rid {
+ u16 hactive;
+ u16 vactive;
+ u8 hratio;
+ u8 vratio;
+};
+
+/* CTA-861-I Table 11 - Resolution Identification (RID) */
+static const struct cta_rid rids[] = {
+ /* RID 0-9 */
+ { 0, 0, 0, 0 },
+ { 1280, 720, 16, 9 },
+ { 1280, 720, 64, 27 },
+ { 1680, 720, 64, 27 },
+ { 1920, 1080, 16, 9 },
+ { 1920, 1080, 64, 27 },
+ { 2560, 1080, 64, 27 },
+ { 3840, 1080, 32, 9 },
+ { 2560, 1440, 16, 9 },
+ { 3440, 1440, 64, 27 },
+ /* RID 10-19 */
+ { 5120, 1440, 32, 9 },
+ { 3840, 2160, 16, 9 },
+ { 3840, 2160, 64, 27 },
+ { 5120, 2160, 64, 27 },
+ { 7680, 2160, 32, 9 },
+ { 5120, 2880, 16, 9 },
+ { 5120, 2880, 64, 27 },
+ { 6880, 2880, 64, 27 },
+ { 10240, 2880, 32, 9 },
+ { 7680, 4320, 16, 9 },
+ /* RID 20-28 */
+ { 7680, 4320, 64, 27 },
+ { 10240, 4320, 64, 27 },
+ { 15360, 4320, 32, 9 },
+ { 11520, 6480, 16, 9 },
+ { 11520, 6480, 64, 27 },
+ { 15360, 6480, 64, 27 },
+ { 15360, 8640, 16, 9 },
+ { 15360, 8640, 64, 27 },
+ { 20480, 8640, 64, 27 },
+};
+
+/* CTA-861-I Table 12 - AVI InfoFrame Video Format Frame Rate */
+static const u16 cta_vf_fr[] = {
+ /* Frame Rate 0-7 */
+ 0, 24, 25, 30, 48, 50, 60, 100,
+ /* Frame Rate 8-15 */
+ 120, 144, 200, 240, 300, 360, 400, 480,
+};
+
+/* CTA-861-I Table 13 - RID To VIC Mapping */
+static const u8 rid_to_vic[][8] = {
+ /* RID 0-9 */
+ {},
+ { 60, 61, 62, 108, 19, 4, 41, 47 },
+ { 65, 66, 67, 109, 68, 69, 70, 71 },
+ { 79, 80, 81, 110, 82, 83, 84, 85 },
+ { 32, 33, 34, 111, 31, 16, 64, 63 },
+ { 72, 73, 74, 112, 75, 76, 77, 78 },
+ { 86, 87, 88, 113, 89, 90, 91, 92 },
+ {},
+ {},
+ {},
+ /* RID 10-19 */
+ {},
+ { 93, 94, 95, 114, 96, 97, 117, 118 },
+ { 103, 104, 105, 116, 106, 107, 119, 120 },
+ { 121, 122, 123, 124, 125, 126, 127, 193 },
+ {},
+ {},
+ {},
+ {},
+ {},
+ { 194, 195, 196, 197, 198, 199, 200, 201 },
+ /* RID 20-28 */
+ { 202, 203, 204, 205, 206, 207, 208, 209 },
+ { 210, 211, 212, 213, 214, 215, 216, 217 },
+ {},
+ {},
+ {},
+ {},
+ {},
+ {},
+ {},
+};
+
/*
* From CEA/CTA-861 spec.
*
@@ -4140,6 +4228,7 @@ static int add_detailed_modes(struct drm_connector
*connector,
#define CTA_DB_VIDEO 2
#define CTA_DB_VENDOR 3
#define CTA_DB_SPEAKER4
+#define CTA_DB_VIDEO_FORMAT6
#define CTA_DB_EXTENDED_TAG 7
/* CTA-861-H Table 62 - CTA Extended Tag Codes */
@@ -4981,6 +5070,16 @@ struct cea_db {
u8 data[];
} __packed;
+struct cta_vfd {
+ u8 rid;
+ u8 fr_fact;
+ bool bfr50;
+ bool fr24;
+ bool bfr60;
+ bool fr144;
+ bool fr48;
+};
+
static int cea_db_tag(const struct cea_db *db)
{
return
[PATCH] drm/edid: add CTA Video Format Data Block support
Video Format Data Blocks (VFDBs) contain the necessary information that
needs to be fed to the Optimized Video Timings (OVT) Algorithm.
Also, we require OVT support to cover modes that aren't supported by
earlier standards (e.g. CVT). So, parse all of the relevant VFDB data
and feed it to the OVT Algorithm, to extract all of the missing OVT
modes.
Link: https://gitlab.freedesktop.org/drm/amd/-/issues/1442
Suggested-by: Karol Herbst
Signed-off-by: Hamza Mahfooz
---
drivers/gpu/drm/drm_edid.c | 426
include/drm/drm_connector.h | 12 +
2 files changed, 438 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index f68a41eeb1fa..112a0070c4d5 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -741,6 +742,93 @@ static const struct minimode extra_modes[] = {
{ 2048, 1536, 60, 0 },
};
+struct cta_rid {
+ u16 hactive;
+ u16 vactive;
+ u8 hratio;
+ u8 vratio;
+};
+
+/* CTA-861-I Table 11 - Resolution Identification (RID) */
+static const struct cta_rid rids[] = {
+ /* RID 0-9 */
+ { 0, 0, 0, 0 },
+ { 1280, 720, 16, 9 },
+ { 1280, 720, 64, 27 },
+ { 1680, 720, 64, 27 },
+ { 1920, 1080, 16, 9 },
+ { 1920, 1080, 64, 27 },
+ { 2560, 1080, 64, 27 },
+ { 3840, 1080, 32, 9 },
+ { 2560, 1440, 16, 9 },
+ { 3440, 1440, 64, 27 },
+ /* RID 10-19 */
+ { 5120, 1440, 32, 9 },
+ { 3840, 2160, 16, 9 },
+ { 3840, 2160, 64, 27 },
+ { 5120, 2160, 64, 27 },
+ { 7680, 2160, 32, 9 },
+ { 5120, 2880, 16, 9 },
+ { 5120, 2880, 64, 27 },
+ { 6880, 2880, 64, 27 },
+ { 10240, 2880, 32, 9 },
+ { 7680, 4320, 16, 9 },
+ /* RID 20-28 */
+ { 7680, 4320, 64, 27 },
+ { 10240, 4320, 64, 27 },
+ { 15360, 4320, 32, 9 },
+ { 11520, 6480, 16, 9 },
+ { 11520, 6480, 64, 27 },
+ { 15360, 6480, 64, 27 },
+ { 15360, 8640, 16, 9 },
+ { 15360, 8640, 64, 27 },
+ { 20480, 8640, 64, 27 },
+};
+
+/* CTA-861-I Table 12 - AVI InfoFrame Video Format Frame Rate */
+static const u16 cta_vf_fr[] = {
+ /* Frame Rate 0-7 */
+ 0, 24, 25, 30, 48, 50, 60, 100,
+ /* Frame Rate 8-15 */
+ 120, 144, 200, 240, 300, 360, 400, 480,
+};
+
+/* CTA-861-I Table 13 - RID To VIC Mapping */
+static const u8 rid_to_vic[][8] = {
+ /* RID 0-9 */
+ {},
+ { 60, 61, 62, 108, 19, 4, 41, 47 },
+ { 65, 66, 67, 109, 68, 69, 70, 71 },
+ { 79, 80, 81, 110, 82, 83, 84, 85 },
+ { 32, 33, 34, 111, 31, 16, 64, 63 },
+ { 72, 73, 74, 112, 75, 76, 77, 78 },
+ { 86, 87, 88, 113, 89, 90, 91, 92 },
+ {},
+ {},
+ {},
+ /* RID 10-19 */
+ {},
+ { 93, 94, 95, 114, 96, 97, 117, 118 },
+ { 103, 104, 105, 116, 106, 107, 119, 120 },
+ { 121, 122, 123, 124, 125, 126, 127, 193 },
+ {},
+ {},
+ {},
+ {},
+ {},
+ { 194, 195, 196, 197, 198, 199, 200, 201 },
+ /* RID 20-28 */
+ { 202, 203, 204, 205, 206, 207, 208, 209 },
+ { 210, 211, 212, 213, 214, 215, 216, 217 },
+ {},
+ {},
+ {},
+ {},
+ {},
+ {},
+ {},
+};
+
/*
* From CEA/CTA-861 spec.
*
@@ -4140,6 +4228,7 @@ static int add_detailed_modes(struct drm_connector
*connector,
#define CTA_DB_VIDEO 2
#define CTA_DB_VENDOR 3
#define CTA_DB_SPEAKER 4
+#define CTA_DB_VIDEO_FORMAT6
#define CTA_DB_EXTENDED_TAG7
/* CTA-861-H Table 62 - CTA Extended Tag Codes */
@@ -4981,6 +5070,16 @@ struct cea_db {
u8 data[];
} __packed;
+struct cta_vfd {
+ u8 rid;
+ u8 fr_fact;
+ bool bfr50;
+ bool fr24;
+ bool bfr60;
+ bool fr144;
+ bool fr48;
+};
+
static int cea_db_tag(const struct cea_db *db)
{
return db->tag_length >> 5;
@@ -6018,6 +6117,307 @@ static void parse_cta_vdb(struct drm_connector
*connector, const struct cea_db *
}
}
+/* CTA-861 Video Format Descriptor (CTA VFD) */
+static void parse_cta_vfd(const u8 *data, int vfd_len, struct cta_vfd *vfd)
+{
+ vfd->rid = data[0] & 0x3f;
+ vfd->bfr50 = data[0] >> 7;
+ vfd->fr24 = !!(data[0] & 0x40);
+ vfd->bfr60 = vfd_len > 1 ? (data[1] >> 7) : 0x1;
+ vfd->fr144 = vfd_len > 1 ? !!(data[1] & 0x40) : 0x0;
+ vfd->fr_fact = vfd_len > 1 ? (data[1] & 0x3f) : 0x3;
+ vfd->fr48 = vfd_len > 2 ? !!(data[2] & 0x1) : 0x0;
+}
+
+static bool vfd_has_fr(const struct cta_vfd *vfd, int rate_idx)
+{
+ static const u8 factors[6] = {
+ 1, 2, 4, 8, 12, 16
+ };
+ u16 rate = cta_vf_fr[rate_idx];
+ u16 factor = 0;
+ unsign
[PATCH 2/2] drm/amd/display: use drm_crtc_vblank_on_config()
Hook up drm_crtc_vblank_on_config() in amdgpu_dm. So, that we can enable
PSR and other static screen optimizations more quickly, while avoiding
stuttering issues that are accompanied by the following dmesg error:
[drm:dc_dmub_srv_wait_idle [amdgpu]] *ERROR* Error waiting for DMUB idle:
status=3
This also allows us to mimic how vblanking is handled by the windows
amdgpu driver.
Signed-off-by: Hamza Mahfooz
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 49 +--
1 file changed, 44 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 07e373deb814..780e31a2d456 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -7952,7 +7952,7 @@ static int amdgpu_dm_encoder_init(struct drm_device *dev,
static void manage_dm_interrupts(struct amdgpu_device *adev,
struct amdgpu_crtc *acrtc,
-bool enable)
+struct dm_crtc_state *acrtc_state)
{
/*
* We have no guarantee that the frontend index maps to the same
@@ -7964,9 +7964,47 @@ static void manage_dm_interrupts(struct amdgpu_device
*adev,
amdgpu_display_crtc_idx_to_irq_type(
adev,
acrtc->crtc_id);
+ struct dc_crtc_timing *timing;
+ int vsync_rate_hz;
+ int offdelay = 30;
+
+ if (acrtc_state) {
+ timing = &acrtc_state->stream->timing;
+
+ vsync_rate_hz = div64_u64(div64_u64((timing->pix_clk_100hz *
+(uint64_t)100),
+ timing->v_total),
+ timing->h_total);
+
+ if (amdgpu_ip_version(adev, DCE_HWIP, 0) >=
+ IP_VERSION(3, 5, 0) && (adev->flags & AMD_IS_APU)) {
+ if (vsync_rate_hz)
+ /* at least 2 frames */
+ offdelay = 2000 / vsync_rate_hz + 1;
+
+ if (acrtc_state->stream->link->psr_settings.psr_version
<
+ DC_PSR_VERSION_UNSUPPORTED) {
+ const struct drm_vblank_crtc_config config = {
+ .offdelay_ms = offdelay,
+ .disable_immediate = false
+ };
+
+ drm_crtc_vblank_on_config(&acrtc->base,
+ &config);
+ } else {
+ const struct drm_vblank_crtc_config config = {
+ .offdelay_ms = 0,
+ .disable_immediate = true
+ };
+
+ drm_crtc_vblank_on_config(&acrtc->base,
+ &config);
+ }
+
+ } else {
+ drm_crtc_vblank_on(&acrtc->base);
+ }
- if (enable) {
- drm_crtc_vblank_on(&acrtc->base);
amdgpu_irq_get(
adev,
&adev->pageflip_irq,
@@ -8947,7 +8985,7 @@ static void amdgpu_dm_commit_streams(struct
drm_atomic_state *state,
if (old_crtc_state->active &&
(!new_crtc_state->active ||
drm_atomic_crtc_needs_modeset(new_crtc_state))) {
- manage_dm_interrupts(adev, acrtc, false);
+ manage_dm_interrupts(adev, acrtc, NULL);
dc_stream_release(dm_old_crtc_state->stream);
}
}
@@ -9465,7 +9503,8 @@ static void amdgpu_dm_atomic_commit_tail(struct
drm_atomic_state *state)
drm_atomic_crtc_needs_modeset(new_crtc_state))) {
dc_stream_retain(dm_new_crtc_state->stream);
acrtc->dm_irq_params.stream = dm_new_crtc_state->stream;
- manage_dm_interrupts(adev, acrtc, true);
+ manage_dm_interrupts(adev, acrtc,
+to_dm_crtc_state(new_crtc_state));
}
/* Handle vrr on->off / off->on transitions */
amdgpu_dm_handle_vrr_transition(dm_old_crtc_state,
dm_new_crtc_state);
--
2.45.2
[PATCH 1/2] drm/vblank: add dynamic per-crtc vblank configuration support
We would like to be able to enable vblank_disable_immediate
unconditionally, however there are a handful of cases where a small off
delay is necessary (e.g. with PSR enabled). So, we would like to be able
to adjust the vblank off delay and disable imminent values dynamically
for a given CRTC. Since, it will allow drivers to apply static screen
optimizations more quickly and consequently allow users to benefit more
so from the power savings afforded by the aforementioned optimizations,
while avoiding issues in cases where an off delay is still warranted.
In particular, the PSR case requires a small off delay of 2 frames,
otherwise display firmware isn't able to keep up with all of the
requests made to amdgpu. So, introduce drm_crtc_vblank_on_config() which
is like drm_crtc_vblank_on(), but it allows drivers to specify the
vblank CRTC configuration before enabling vblanking support for a given
CRTC.
Signed-off-by: Hamza Mahfooz
---
drivers/gpu/drm/drm_vblank.c | 57 ++--
include/drm/drm_vblank.h | 25
2 files changed, 66 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
index cc3571e25a9a..c9de7d18389a 100644
--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -1241,6 +1241,7 @@ EXPORT_SYMBOL(drm_crtc_vblank_get);
void drm_vblank_put(struct drm_device *dev, unsigned int pipe)
{
struct drm_vblank_crtc *vblank = drm_vblank_crtc(dev, pipe);
+ int vblank_offdelay = vblank->config.offdelay_ms;
if (drm_WARN_ON(dev, pipe >= dev->num_crtcs))
return;
@@ -1250,13 +1251,13 @@ void drm_vblank_put(struct drm_device *dev, unsigned
int pipe)
/* Last user schedules interrupt disable */
if (atomic_dec_and_test(&vblank->refcount)) {
- if (drm_vblank_offdelay == 0)
+ if (!vblank_offdelay)
return;
- else if (drm_vblank_offdelay < 0)
+ else if (vblank_offdelay < 0)
vblank_disable_fn(&vblank->disable_timer);
- else if (!dev->vblank_disable_immediate)
+ else if (!vblank->config.disable_immediate)
mod_timer(&vblank->disable_timer,
- jiffies + ((drm_vblank_offdelay * HZ)/1000));
+ jiffies + ((vblank_offdelay * HZ) / 1000));
}
}
@@ -1466,16 +1467,16 @@ void drm_crtc_set_max_vblank_count(struct drm_crtc
*crtc,
EXPORT_SYMBOL(drm_crtc_set_max_vblank_count);
/**
- * drm_crtc_vblank_on - enable vblank events on a CRTC
+ * drm_crtc_vblank_on_config - enable vblank events on a CRTC with custom
+ * configuration options
* @crtc: CRTC in question
+ * @config: Vblank configuration value
*
- * This functions restores the vblank interrupt state captured with
- * drm_crtc_vblank_off() again and is generally called when enabling @crtc.
Note
- * that calls to drm_crtc_vblank_on() and drm_crtc_vblank_off() can be
- * unbalanced and so can also be unconditionally called in driver load code to
- * reflect the current hardware state of the crtc.
+ * See drm_crtc_vblank_on(). In addition, this function allows you to provide a
+ * custom vblank configuration for a given CRTC.
*/
-void drm_crtc_vblank_on(struct drm_crtc *crtc)
+void drm_crtc_vblank_on_config(struct drm_crtc *crtc,
+ const struct drm_vblank_crtc_config *config)
{
struct drm_device *dev = crtc->dev;
unsigned int pipe = drm_crtc_index(crtc);
@@ -1488,6 +1489,8 @@ void drm_crtc_vblank_on(struct drm_crtc *crtc)
drm_dbg_vbl(dev, "crtc %d, vblank enabled %d, inmodeset %d\n",
pipe, vblank->enabled, vblank->inmodeset);
+ vblank->config = *config;
+
/* Drop our private "prevent drm_vblank_get" refcount */
if (vblank->inmodeset) {
atomic_dec(&vblank->refcount);
@@ -1500,10 +1503,31 @@ void drm_crtc_vblank_on(struct drm_crtc *crtc)
* re-enable interrupts if there are users left, or the
* user wishes vblank interrupts to be enabled all the time.
*/
- if (atomic_read(&vblank->refcount) != 0 || drm_vblank_offdelay == 0)
+ if (atomic_read(&vblank->refcount) != 0 || !vblank->config.offdelay_ms)
drm_WARN_ON(dev, drm_vblank_enable(dev, pipe));
spin_unlock_irq(&dev->vbl_lock);
}
+EXPORT_SYMBOL(drm_crtc_vblank_on_config);
+
+/**
+ * drm_crtc_vblank_on - enable vblank events on a CRTC
+ * @crtc: CRTC in question
+ *
+ * This functions restores the vblank interrupt state captured with
+ * drm_crtc_vblank_off() again and is generally called when enabling @crtc.
Note
+ * that calls to drm_crtc_vblank_on() and drm_crtc_vblank_off() can be
+ * unbalanced and so can also be unconditionally calle
Re: [PATCH AUTOSEL 6.9 11/22] drm/amd/display: Reset freesync config before update new state
Hi Sasha,
On 7/16/24 10:24, Sasha Levin wrote:
From: Tom Chung
[ Upstream commit 6b8487cdf9fc7bae707519ac5b5daeca18d1e85b ]
[Why]
Sometimes the new_crtc_state->vrr_infopacket did not sync up with the
current state.
It will affect the update_freesync_state_on_stream() does not update
the state correctly.
[How]
Reset the freesync config before get_freesync_config_for_crtc() to
make sure we have the correct new_crtc_state for VRR.
Please drop this patch from the stable queue entirely, since it has
already been reverted (as of commit dc1000bf463d ("Revert
"drm/amd/display: Reset freesync config before update new state"")).
Reviewed-by: Sun peng Li
Signed-off-by: Jerry Zuo
Signed-off-by: Tom Chung
Tested-by: Daniel Wheeler
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index f866a02f4f489..53a55270998cc 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -10028,6 +10028,7 @@ static int dm_update_crtc_state(struct
amdgpu_display_manager *dm,
}
/* Update Freesync settings. */
+ reset_freesync_config_for_crtc(dm_new_crtc_state);
get_freesync_config_for_crtc(dm_new_crtc_state,
dm_new_conn_state);
--
Hamza
Re: [PATCH 2/2] drm/amd/display: use drm_crtc_set_vblank_offdelay()
On 7/10/24 04:43, Daniel Vetter wrote:
On Tue, Jul 09, 2024 at 10:02:08AM -0400, Hamza Mahfooz wrote:
On 7/9/24 06:09, Daniel Vetter wrote:
On Tue, Jul 09, 2024 at 11:32:11AM +0200, Daniel Vetter wrote:
On Mon, Jul 08, 2024 at 04:29:07PM -0400, Hamza Mahfooz wrote:
Hook up drm_crtc_set_vblank_offdelay() in amdgpu_dm, so that we can
enable PSR more quickly for displays that support it.
Signed-off-by: Hamza Mahfooz
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 30 ++-
1 file changed, 22 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index fdbc9b57a23d..ee6c31e9d3c4 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -8231,7 +8231,7 @@ static int amdgpu_dm_encoder_init(struct drm_device *dev,
static void manage_dm_interrupts(struct amdgpu_device *adev,
struct amdgpu_crtc *acrtc,
-bool enable)
+struct dm_crtc_state *acrtc_state)
{
/*
* We have no guarantee that the frontend index maps to the same
@@ -8239,12 +8239,25 @@ static void manage_dm_interrupts(struct amdgpu_device
*adev,
*
* TODO: Use a different interrupt or check DC itself for the mapping.
*/
- int irq_type =
- amdgpu_display_crtc_idx_to_irq_type(
- adev,
- acrtc->crtc_id);
+ int irq_type = amdgpu_display_crtc_idx_to_irq_type(adev,
+ acrtc->crtc_id);
+ struct dc_crtc_timing *timing;
+ int offdelay;
+
+ if (acrtc_state) {
+ timing = &acrtc_state->stream->timing;
+
+ /* at least 2 frames */
+ offdelay = 2000 / div64_u64(div64_u64((timing->pix_clk_100hz *
+ (uint64_t)100),
+ timing->v_total),
+ timing->h_total) + 1;
Yeah, _especially_ when you have a this short timeout your really have to
instead fix the vblank driver code properly so you can enable
vblank_disable_immediate. This is just cheating :-)
Michel mentioned on irc that DC had immediate vblank disabling, but this
was reverted with f64e6e0b6afe ("Revert "drm/amdgpu/display: set
vblank_disable_immediate for DC"").
I haven't looked at the details of the bug report, but stuttering is
exactly what happens when the driver's vblank code has these races. Going
for a very low timeout instead of zero just means it's a bit harder to hit
the issue, and much, much harder to debug properly.
So yeah even more reasons to look at the underlying root-cause here I
think.
-Sima
The issue is that DMUB (display firmware) isn't able to keep up with all of
the requests that the driver is making. The issue is fairly difficult to
reproduce (I've only seen it once after letting the system run with a
program that would engage PSR every so often, after several hours).
It is also worth noting that we have the same 2 idle frame wait on the
windows
driver, for the same reasons. So, in all likelihood if it is your opinion
that
the series should be NAKed, we will probably have to move the wait into the
driver as a workaround.
Well that's an entirely different reason, and needs to be recorded in the
commit log that disabling/enabling vblank is too expensive and why. Also
would be good to record that windows does the same.
Point taken.
I'm also not entirely sure this is a good interface, so some
thoughts/question:
- is the issue only with psr, meaning that if we switch the panel to a
different crtc, do we need to update the off delay.
I can't say definitively, but all of the public reports (that I've seen)
and my local repro are PSR related.
- there's still the question of why vblank_immediate_disable resulted in
stuttering, is that the same bug? I think for consistency it'd be best
if we enable immediate vblank disabling everywhere (for maximum
testing), and then apply the 2 frame delay workaround only where needed
explicitly. Otherwise if there's other issues than DMUB being slow, they
might be mostly hidden and become really hard to track down when they
show up.
Ya, I believe they are all DMUB related since the stuttering issues are
accompanied by the following dmesg log entry:
[drm:dc_dmub_srv_wait_idle [amdgpu]] *ERROR* Error waiting for DMUB
idle: status=3
(which is pretty much an unspecified firmware timeout)
Also, setting vblank_immediate_disable unconditionally for amdgpu, while
only
enabling the delay for cases that we know that we need it seems
reasonable to me.
- I think an interf
Re: [PATCH v4 0/2] Add support for 'power saving policy' property
On 7/3/24 01:17, Mario Limonciello wrote: During the Display Next hackfest 2024 one of the topics discussed was the need for compositor to be able to relay intention to drivers that color fidelity is preferred over power savings. To accomplish this a new optional DRM property is being introduced called "power saving policy". This property is a bit mask that can be configured with requests of "Require color accuracy" or "Require low latency" that can be configured by the compositor. When a driver advertises support for this property and the compositor sets it to "Require color accuracy" then the driver will disable any power saving features that can compromise color fidelity. In practice the main feature this currently applies to is the "Adaptive Backlight Modulation" feature within AMD DCN on eDP panels. When the compositor has marked the property "Require color accuracy" then this feature will be disabled and any userspace that tries to turn it on will get an -EBUSY return code. Compositors can also request that low latency is critical which in practice should cause PSR and PSR2 to be disabled. When the compositor has restored the value back to no requirements then the previous value that would have been programmed will be restored. Applied, thanks! v3->v4: * Fixup for Xaver's reported issue v2->v3: * Updates from Leo's comments (see individual patches) Mario Limonciello (2): drm: Introduce 'power saving policy' drm property drm/amd: Add power_saving_policy drm property to eDP connectors drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 4 ++ .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 50 +-- .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 2 + drivers/gpu/drm/drm_connector.c | 48 ++ include/drm/drm_connector.h | 2 + include/drm/drm_mode_config.h | 5 ++ include/uapi/drm/drm_mode.h | 7 +++ 7 files changed, 113 insertions(+), 5 deletions(-) -- Hamza
Re: [PATCH 2/2] drm/amd/display: use drm_crtc_set_vblank_offdelay()
On 7/9/24 06:09, Daniel Vetter wrote:
On Tue, Jul 09, 2024 at 11:32:11AM +0200, Daniel Vetter wrote:
On Mon, Jul 08, 2024 at 04:29:07PM -0400, Hamza Mahfooz wrote:
Hook up drm_crtc_set_vblank_offdelay() in amdgpu_dm, so that we can
enable PSR more quickly for displays that support it.
Signed-off-by: Hamza Mahfooz
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 30 ++-
1 file changed, 22 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index fdbc9b57a23d..ee6c31e9d3c4 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -8231,7 +8231,7 @@ static int amdgpu_dm_encoder_init(struct drm_device *dev,
static void manage_dm_interrupts(struct amdgpu_device *adev,
struct amdgpu_crtc *acrtc,
-bool enable)
+struct dm_crtc_state *acrtc_state)
{
/*
* We have no guarantee that the frontend index maps to the same
@@ -8239,12 +8239,25 @@ static void manage_dm_interrupts(struct amdgpu_device
*adev,
*
* TODO: Use a different interrupt or check DC itself for the mapping.
*/
- int irq_type =
- amdgpu_display_crtc_idx_to_irq_type(
- adev,
- acrtc->crtc_id);
+ int irq_type = amdgpu_display_crtc_idx_to_irq_type(adev,
+ acrtc->crtc_id);
+ struct dc_crtc_timing *timing;
+ int offdelay;
+
+ if (acrtc_state) {
+ timing = &acrtc_state->stream->timing;
+
+ /* at least 2 frames */
+ offdelay = 2000 / div64_u64(div64_u64((timing->pix_clk_100hz *
+ (uint64_t)100),
+ timing->v_total),
+ timing->h_total) + 1;
Yeah, _especially_ when you have a this short timeout your really have to
instead fix the vblank driver code properly so you can enable
vblank_disable_immediate. This is just cheating :-)
Michel mentioned on irc that DC had immediate vblank disabling, but this
was reverted with f64e6e0b6afe ("Revert "drm/amdgpu/display: set
vblank_disable_immediate for DC"").
I haven't looked at the details of the bug report, but stuttering is
exactly what happens when the driver's vblank code has these races. Going
for a very low timeout instead of zero just means it's a bit harder to hit
the issue, and much, much harder to debug properly.
So yeah even more reasons to look at the underlying root-cause here I
think.
-Sima
The issue is that DMUB (display firmware) isn't able to keep up with all of
the requests that the driver is making. The issue is fairly difficult to
reproduce (I've only seen it once after letting the system run with a
program that would engage PSR every so often, after several hours).
It is also worth noting that we have the same 2 idle frame wait on the
windows
driver, for the same reasons. So, in all likelihood if it is your
opinion that
the series should be NAKed, we will probably have to move the wait into the
driver as a workaround.
--
Hamza
[PATCH 1/2] drm/vblank: allow dynamic per-crtc vblank off delay
We would like to be able to adjust the vblank off delay dynamically for
a given CRTC. Since, it will allow drivers to apply static screen
optimizations more quickly and consequently allow users to benefit more
so from the power savings afforded by the aforementioned optimizations.
Signed-off-by: Hamza Mahfooz
---
drivers/gpu/drm/drm_vblank.c | 31 ++-
include/drm/drm_vblank.h | 7 +++
2 files changed, 33 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
index 702a12bc93bd..4f475131a092 100644
--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -529,6 +529,7 @@ int drm_vblank_init(struct drm_device *dev, unsigned int
num_crtcs)
vblank->dev = dev;
vblank->pipe = i;
+ vblank->offdelay_ms = drm_vblank_offdelay;
init_waitqueue_head(&vblank->queue);
timer_setup(&vblank->disable_timer, vblank_disable_fn, 0);
seqlock_init(&vblank->seqlock);
@@ -1229,6 +1230,7 @@ EXPORT_SYMBOL(drm_crtc_vblank_get);
void drm_vblank_put(struct drm_device *dev, unsigned int pipe)
{
struct drm_vblank_crtc *vblank = &dev->vblank[pipe];
+ int vblank_offdelay = vblank->offdelay_ms;
if (drm_WARN_ON(dev, pipe >= dev->num_crtcs))
return;
@@ -1238,13 +1240,13 @@ void drm_vblank_put(struct drm_device *dev, unsigned
int pipe)
/* Last user schedules interrupt disable */
if (atomic_dec_and_test(&vblank->refcount)) {
- if (drm_vblank_offdelay == 0)
+ if (!vblank_offdelay)
return;
- else if (drm_vblank_offdelay < 0)
+ else if (vblank_offdelay < 0)
vblank_disable_fn(&vblank->disable_timer);
else if (!dev->vblank_disable_immediate)
mod_timer(&vblank->disable_timer,
- jiffies + ((drm_vblank_offdelay * HZ)/1000));
+ jiffies + ((vblank_offdelay * HZ) / 1000));
}
}
@@ -1455,6 +1457,25 @@ void drm_crtc_set_max_vblank_count(struct drm_crtc *crtc,
}
EXPORT_SYMBOL(drm_crtc_set_max_vblank_count);
+/**
+ * drm_crtc_set_vblank_offdelay - configure the vblank off delay value
+ * @crtc: CRTC in question
+ * @offdelay: off delay value
+ *
+ * If used, must be called before drm_vblank_on().
+ */
+void drm_crtc_set_vblank_offdelay(struct drm_crtc *crtc, int offdelay)
+{
+ struct drm_device *dev = crtc->dev;
+ unsigned int pipe = drm_crtc_index(crtc);
+ struct drm_vblank_crtc *vblank = &dev->vblank[pipe];
+
+ drm_WARN_ON(dev, dev->vblank_disable_immediate);
+
+ vblank->offdelay_ms = offdelay;
+}
+EXPORT_SYMBOL(drm_crtc_set_vblank_offdelay);
+
/**
* drm_crtc_vblank_on - enable vblank events on a CRTC
* @crtc: CRTC in question
@@ -1490,7 +1511,7 @@ void drm_crtc_vblank_on(struct drm_crtc *crtc)
* re-enable interrupts if there are users left, or the
* user wishes vblank interrupts to be enabled all the time.
*/
- if (atomic_read(&vblank->refcount) != 0 || drm_vblank_offdelay == 0)
+ if (atomic_read(&vblank->refcount) != 0 || !vblank->offdelay_ms)
drm_WARN_ON(dev, drm_vblank_enable(dev, pipe));
spin_unlock_irq(&dev->vbl_lock);
}
@@ -1909,7 +1930,7 @@ bool drm_handle_vblank(struct drm_device *dev, unsigned
int pipe)
* drm_handle_vblank_events) so that the timestamp is always accurate.
*/
disable_irq = (dev->vblank_disable_immediate &&
- drm_vblank_offdelay > 0 &&
+ vblank->offdelay_ms > 0 &&
!atomic_read(&vblank->refcount));
drm_handle_vblank_events(dev, pipe);
diff --git a/include/drm/drm_vblank.h b/include/drm/drm_vblank.h
index 7f3957943dd1..f92f28b816af 100644
--- a/include/drm/drm_vblank.h
+++ b/include/drm/drm_vblank.h
@@ -187,6 +187,12 @@ struct drm_vblank_crtc {
*/
int linedur_ns;
+ /**
+* @offdelay_ms: Vblank off delay in ms, used to determine how long
+* @disable_timer waits before disabling.
+*/
+ int offdelay_ms;
+
/**
* @hwmode:
*
@@ -255,6 +261,7 @@ void drm_calc_timestamping_constants(struct drm_crtc *crtc,
wait_queue_head_t *drm_crtc_vblank_waitqueue(struct drm_crtc *crtc);
void drm_crtc_set_max_vblank_count(struct drm_crtc *crtc,
u32 max_vblank_count);
+void drm_crtc_set_vblank_offdelay(struct drm_crtc *crtc, int offdelay);
/*
* Helpers for struct drm_crtc_funcs
--
2.45.1
[PATCH 2/2] drm/amd/display: use drm_crtc_set_vblank_offdelay()
Hook up drm_crtc_set_vblank_offdelay() in amdgpu_dm, so that we can
enable PSR more quickly for displays that support it.
Signed-off-by: Hamza Mahfooz
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 30 ++-
1 file changed, 22 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index fdbc9b57a23d..ee6c31e9d3c4 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -8231,7 +8231,7 @@ static int amdgpu_dm_encoder_init(struct drm_device *dev,
static void manage_dm_interrupts(struct amdgpu_device *adev,
struct amdgpu_crtc *acrtc,
-bool enable)
+struct dm_crtc_state *acrtc_state)
{
/*
* We have no guarantee that the frontend index maps to the same
@@ -8239,12 +8239,25 @@ static void manage_dm_interrupts(struct amdgpu_device
*adev,
*
* TODO: Use a different interrupt or check DC itself for the mapping.
*/
- int irq_type =
- amdgpu_display_crtc_idx_to_irq_type(
- adev,
- acrtc->crtc_id);
+ int irq_type = amdgpu_display_crtc_idx_to_irq_type(adev,
+ acrtc->crtc_id);
+ struct dc_crtc_timing *timing;
+ int offdelay;
+
+ if (acrtc_state) {
+ timing = &acrtc_state->stream->timing;
+
+ /* at least 2 frames */
+ offdelay = 2000 / div64_u64(div64_u64((timing->pix_clk_100hz *
+ (uint64_t)100),
+ timing->v_total),
+ timing->h_total) + 1;
+
+ if (acrtc_state->stream->link->psr_settings.psr_version <
+ DC_PSR_VERSION_UNSUPPORTED &&
+ amdgpu_ip_version(adev, DCE_HWIP, 0) >= IP_VERSION(3, 5, 0))
+ drm_crtc_set_vblank_offdelay(&acrtc->base, offdelay);
- if (enable) {
drm_crtc_vblank_on(&acrtc->base);
amdgpu_irq_get(
adev,
@@ -9319,7 +9332,7 @@ static void amdgpu_dm_commit_streams(struct
drm_atomic_state *state,
if (old_crtc_state->active &&
(!new_crtc_state->active ||
drm_atomic_crtc_needs_modeset(new_crtc_state))) {
- manage_dm_interrupts(adev, acrtc, false);
+ manage_dm_interrupts(adev, acrtc, NULL);
dc_stream_release(dm_old_crtc_state->stream);
}
}
@@ -9834,7 +9847,8 @@ static void amdgpu_dm_atomic_commit_tail(struct
drm_atomic_state *state)
drm_atomic_crtc_needs_modeset(new_crtc_state))) {
dc_stream_retain(dm_new_crtc_state->stream);
acrtc->dm_irq_params.stream = dm_new_crtc_state->stream;
- manage_dm_interrupts(adev, acrtc, true);
+ manage_dm_interrupts(adev, acrtc,
+to_dm_crtc_state(new_crtc_state));
}
/* Handle vrr on->off / off->on transitions */
amdgpu_dm_handle_vrr_transition(dm_old_crtc_state,
dm_new_crtc_state);
--
2.45.1
[PATCH] MAINTAINERS: add an entry for AMD DC DML
We want all DML changes to be reviewed by Chaitanya or Jun. So, add an entry for DML to MAINTAINERS. Suggested-by: Rodrigo Siqueira Signed-off-by: Hamza Mahfooz --- MAINTAINERS | 7 +++ 1 file changed, 7 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 7fec8ddb8d5b..d2fb60fee7e8 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -950,6 +950,13 @@ S: Supported T: git https://gitlab.freedesktop.org/agd5f/linux.git F: drivers/gpu/drm/amd/display/ +AMD DISPLAY CORE - DML +M: Chaitanya Dhere +M: Jun Lei +S: Supported +F: drivers/gpu/drm/amd/display/dc/dml/ +F: drivers/gpu/drm/amd/display/dc/dml2/ + AMD FAM15H PROCESSOR POWER MONITORING DRIVER M: Huang Rui L: linux-hw...@vger.kernel.org -- 2.45.1
Re: [PATCH v4 0/2] drm: panel-orientation-quirks: Add quirk for Steam Deck Galileo revision and re-label the Deck panel quirks to specify hardware revision
On 6/28/24 16:58, Matthew Schwartz wrote: This is a series of 2 patches. The first patch is from Valve's public kernel source tree. It adds a panel rotation quirk for Valve's Steam Deck Galileo revision, which has an 800x1280 OLED panel. The previous Steam Deck panel orientation quirk does not apply to the Galileo revision's DMI. I have added a short commit message and signed off below the original author. The second patch is one that I authored to clarify which device version each panel quirk applies to now that there are multiple Steam Deck revisions. --- v4: add missing S-o-b from original author of patch 1/2 and re-signed commit v3: fixup inconsistent patch versioning across patches in v2 v2: fixup patch 1/2 commit message Link to v3: https://lore.kernel.org/all/20240627203057.127034-1-mattschwa...@gwu.edu/ Link to v1: https://lore.kernel.org/all/20240627175947.65513-1-mattschwa...@gwu.edu/ Applied, thanks! --- John Schoenick (1): drm: panel-orientation-quirks: Add quirk for Valve Galileo Matthew Schwartz (1): drm: panel-orientation-quirks: Add labels for both Valve Steam Deck revisions drivers/gpu/drm/drm_panel_orientation_quirks.c | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) -- Hamza
Re: [PATCH v3 1/2] drm: panel-orientation-quirks: Add quirk for Valve Galileo
On 6/27/24 16:30, Matthew Schwartz wrote:
From: John Schoenick
Since this patch is from John, you would need his S-o-b in here as well
(assuming you have his permission to add it).
Valve's Steam Deck Galileo revision has a 800x1280 OLED panel
Suggested-by: John Schoenick
Link:
https://gitlab.com/evlaV/linux-integration/-/commit/d2522d8bf88b35a8cf6978afbbd55c80d2d53f4f
Signed-off-by: Matthew Schwartz
---
drivers/gpu/drm/drm_panel_orientation_quirks.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/drm_panel_orientation_quirks.c
b/drivers/gpu/drm/drm_panel_orientation_quirks.c
index 3d127127e7cb..ac8319d38e37 100644
--- a/drivers/gpu/drm/drm_panel_orientation_quirks.c
+++ b/drivers/gpu/drm/drm_panel_orientation_quirks.c
@@ -427,6 +427,13 @@ static const struct dmi_system_id orientation_data[] = {
DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "1"),
},
.driver_data = (void *)&lcd800x1280_rightside_up,
+ }, {/* Valve Steam Deck */
+ .matches = {
+ DMI_EXACT_MATCH(DMI_SYS_VENDOR, "Valve"),
+ DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "Galileo"),
+ DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "1"),
+ },
+ .driver_data = (void *)&lcd800x1280_rightside_up,
}, {/* VIOS LTH17 */
.matches = {
DMI_EXACT_MATCH(DMI_SYS_VENDOR, "VIOS"),
--
Hamza
Re: [PATCH] drm: deprecate driver date
On 4/29/24 12:43, Jani Nikula wrote: The driver date serves no useful purpose, because it's hardly ever updated. The information is misleading at best. As described in Documentation/gpu/drm-internals.rst: The driver date, formatted as MMDD, is meant to identify the date of the latest modification to the driver. However, as most drivers fail to update it, its value is mostly useless. The DRM core prints it to the kernel log at initialization time and passes it to userspace through the DRM_IOCTL_VERSION ioctl. Stop printing the driver date at init, and start returning the empty string "" as driver date through the DRM_IOCTL_VERSION ioctl. The driver date initialization in drivers and the struct drm_driver date member can be removed in follow-up. Signed-off-by: Jani Nikula I would prefer if it was dropped entirely in this patch, but if you feel that would require too much back and forth, I'm okay with what is currently proposed. Reviewed-by: Hamza Mahfooz --- The below approximates when each driver's date was last updated. $ git grepblame "\(\.date = \".*\"\|#define.*DRIVER_DATE\)" -- drivers/gpu drivers/accel fe77368c0f3e0 drivers/accel/habanalabs/common/habanalabs_drv.c 94 (Tomer Tayar 2023-02-19 11:58:46 +0200 104) .date = "20190505", 35b137630f08d drivers/accel/ivpu/ivpu_drv.h 20 (Jacek Lawrynowicz 2023-01-17 10:27:17 +0100 24) #define DRIVER_DATE "20230117" d38ceaf99ed01 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.h 43 (Alex Deucher 2015-04-20 16:55:21 -0400 43) #define DRIVER_DATE"20150101" 61f1c4a8ab757 drivers/gpu/drm/arm/display/komeda/komeda_kms.c 51 (james qian wang (Arm Technology China) 2019-01-03 11:41:30 + 64) .date = "20181101", 8e22d79240d95 drivers/gpu/drm/arm/hdlcd_drv.c 343 (Liviu Dudau 2015-04-02 19:48:39 +0100 234) .date = "20151021", ad49f8602fe88 drivers/gpu/drm/arm/malidp_drv.c 232 (Liviu Dudau 2016-03-07 10:00:53 + 571) .date = "20160106", 4f2a8f5898ecd drivers/gpu/drm/aspeed/aspeed_gfx_drv.c 208 (Joel Stanley 2019-04-03 10:49:08 +1030 253) .date = "20180319", 312fec1405dd5 drivers/gpu/drm/ast/ast_drv.h 46 (Dave Airlie 2012-02-29 13:40:04 + 46) #define DRIVER_DATE "20120228" 1a396789f65a2 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c 504 (Boris Brezillon 2015-01-06 11:13:28 +0100 741) .date = "20141504", 9913f74fe1570 drivers/gpu/drm/exynos/exynos_drm_drv.c 37 (Marek Szyprowski 2018-05-10 08:46:36 +0900 37) #define DRIVER_DATE"20180330" f90cd811ae7a3 drivers/gpu/drm/gma500/psb_drv.h 43 (Arthur Borsboom 2014-03-15 22:12:17 +0100 29) #define DRIVER_DATE "20140314" 1053d01864937 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c 1070 (Xu YiPing 2019-08-20 23:06:19 + 930).date = "20150718", 76c56a5affeba drivers/gpu/drm/hyperv/hyperv_drm_drv.c 22 (Deepak Rawat 2021-05-27 04:22:28 -0700 22) #define DRIVER_DATE "2020" 3570bd989acc6 drivers/gpu/drm/i915/i915_driver.h 18 (Jani Nikula 2023-09-29 12:43:23 +0300 18) #define DRIVER_DATE "20230929" 4babef0708656 drivers/gpu/drm/imagination/pvr_drv.h 12 (Sarah Walker 2023-11-22 16:34:26 + 12) #define PVR_DRIVER_DATE "20230904" c87e859cdeb5d drivers/gpu/drm/imx/lcdc/imx-lcdc.c 361 (Marian Cichy 2023-03-06 12:52:49 +0100 353) .date = "20200716", eb92830cdbc23 drivers/gpu/drm/kmb/kmb_drv.h 19 (Edmund Dea 2020-08-26 13:17:29 -0700 19) #define DRIVER_DATE"20210223" f39db26c54281 drivers/gpu/drm/loongson/lsdc_drv.c 28 (Sui Jingfeng 2023-06-15 22:36:12 +0800 28) #define DRIVER_DATE "20220701" 5fc537bfd0003 drivers/gpu/drm/mcde/mcde_drv.c 247 (Linus Walleij 2019-05-24 11:20:19 +0200 210) .date = "20180529", 119f5173628aa drivers/gpu/drm/mediatek/mtk_drm_drv.c 36 (CK Hu 2016-01-04 18:36:34 +0100 34) #define DRIVER_DATE "20150513" 414c453106255 drivers/gpu/drm/mgag200/mgag200_drv.h 34 (Dave Airlie 2012-04-17 15:01:25 +0100 31) #define DRIVER_DATE "20110418" 77145f1cbdf8d drivers/gpu/drm/nouveau/nouveau_drm.h 9 (Ben Skeggs 2012-07-31 16:16:21 +1000 10) #define DRIVER_DATE "20120801" cd5351f4d2b1b drivers/staging/omapdrm/omap_drv.c 27 (Rob Clark 2011-11-12 12:09:40 -0600 31) #define DRIVER_DATE"20110917" 4bdca11507928 drivers/gpu/drm/panthor/panthor_drv.c 1371 (Boris Brezillon 2024-02-29 17:22:25 +0100 1386) .date = "20230801", bed41005e6174 drivers/gpu/drm/pl111/pl111_drv.c 157 (Tom Cooksey 2017-04-12 20:17:46 -0700 222) .date = "20170317", f64122c1f6ade drivers/gpu/drm/qxl/qxl_drv.h 52 (Dave Airlie 2013-02-25 14:47:55 +1000 57) #define DRIVER_DATE "20120117" c0beb2a723d69 drivers/char/drm/radeon_drv.h 41 (Dave Airlie 2008
Re: [PATCH 01/12] kbuild: make -Woverride-init warnings more consistent
Cc: amd-...@lists.freedesktop.org
On 3/26/24 10:47, Arnd Bergmann wrote:
From: Arnd Bergmann
The -Woverride-init warn about code that may be intentional or not,
but the inintentional ones tend to be real bugs, so there is a bit of
disagreement on whether this warning option should be enabled by default
and we have multiple settings in scripts/Makefile.extrawarn as well as
individual subsystems.
Older versions of clang only supported -Wno-initializer-overrides with
the same meaning as gcc's -Woverride-init, though all supported versions
now work with both. Because of this difference, an earlier cleanup of
mine accidentally turned the clang warning off for W=1 builds and only
left it on for W=2, while it's still enabled for gcc with W=1.
There is also one driver that only turns the warning off for newer
versions of gcc but not other compilers, and some but not all the
Makefiles still use a cc-disable-warning conditional that is no
longer needed with supported compilers here.
Address all of the above by removing the special cases for clang
and always turning the warning off unconditionally where it got
in the way, using the syntax that is supported by both compilers.
Fixes: 2cd3271b7a31 ("kbuild: avoid duplicate warning options")
Signed-off-by: Arnd Bergmann
Acked-by: Hamza Mahfooz
For the amdgpu changes.
---
drivers/gpu/drm/amd/display/dc/dce110/Makefile | 2 +-
drivers/gpu/drm/amd/display/dc/dce112/Makefile | 2 +-
drivers/gpu/drm/amd/display/dc/dce120/Makefile | 2 +-
drivers/gpu/drm/amd/display/dc/dce60/Makefile | 2 +-
drivers/gpu/drm/amd/display/dc/dce80/Makefile | 2 +-
drivers/gpu/drm/i915/Makefile | 6 +++---
drivers/gpu/drm/xe/Makefile| 4 ++--
drivers/net/ethernet/renesas/sh_eth.c | 2 +-
drivers/pinctrl/aspeed/Makefile| 2 +-
fs/proc/Makefile | 2 +-
kernel/bpf/Makefile| 2 +-
mm/Makefile| 3 +--
scripts/Makefile.extrawarn | 10 +++---
13 files changed, 18 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dce110/Makefile
b/drivers/gpu/drm/amd/display/dc/dce110/Makefile
index f0777d61c2cb..c307f040e48f 100644
--- a/drivers/gpu/drm/amd/display/dc/dce110/Makefile
+++ b/drivers/gpu/drm/amd/display/dc/dce110/Makefile
@@ -23,7 +23,7 @@
# Makefile for the 'controller' sub-component of DAL.
# It provides the control and status of HW CRTC block.
-CFLAGS_$(AMDDALPATH)/dc/dce110/dce110_resource.o = $(call cc-disable-warning, override-init)
+CFLAGS_$(AMDDALPATH)/dc/dce110/dce110_resource.o = -Wno-override-init
DCE110 = dce110_timing_generator.o \
dce110_compressor.o dce110_opp_regamma_v.o \
diff --git a/drivers/gpu/drm/amd/display/dc/dce112/Makefile
b/drivers/gpu/drm/amd/display/dc/dce112/Makefile
index 7e92effec894..683866797709 100644
--- a/drivers/gpu/drm/amd/display/dc/dce112/Makefile
+++ b/drivers/gpu/drm/amd/display/dc/dce112/Makefile
@@ -23,7 +23,7 @@
# Makefile for the 'controller' sub-component of DAL.
# It provides the control and status of HW CRTC block.
-CFLAGS_$(AMDDALPATH)/dc/dce112/dce112_resource.o = $(call cc-disable-warning, override-init)
+CFLAGS_$(AMDDALPATH)/dc/dce112/dce112_resource.o = -Wno-override-init
DCE112 = dce112_compressor.o
diff --git a/drivers/gpu/drm/amd/display/dc/dce120/Makefile b/drivers/gpu/drm/amd/display/dc/dce120/Makefile
index 1e3ef68a452a..8f508e662748 100644
--- a/drivers/gpu/drm/amd/display/dc/dce120/Makefile
+++ b/drivers/gpu/drm/amd/display/dc/dce120/Makefile
@@ -24,7 +24,7 @@
# It provides the control and status of HW CRTC block.
-CFLAGS_$(AMDDALPATH)/dc/dce120/dce120_resource.o = $(call cc-disable-warning, override-init)
+CFLAGS_$(AMDDALPATH)/dc/dce120/dce120_resource.o = -Wno-override-init
DCE120 = dce120_timing_generator.o
diff --git a/drivers/gpu/drm/amd/display/dc/dce60/Makefile b/drivers/gpu/drm/amd/display/dc/dce60/Makefile
index fee331accc0e..eede83ad91fa 100644
--- a/drivers/gpu/drm/amd/display/dc/dce60/Makefile
+++ b/drivers/gpu/drm/amd/display/dc/dce60/Makefile
@@ -23,7 +23,7 @@
# Makefile for the 'controller' sub-component of DAL.
# It provides the control and status of HW CRTC block.
-CFLAGS_$(AMDDALPATH)/dc/dce60/dce60_resource.o = $(call cc-disable-warning, override-init)
+CFLAGS_$(AMDDALPATH)/dc/dce60/dce60_resource.o = -Wno-override-init
DCE60 = dce60_timing_generator.o dce60_hw_sequencer.o \
dce60_resource.o
diff --git a/drivers/gpu/drm/amd/display/dc/dce80/Makefile
b/drivers/gpu/drm/amd/display/dc/dce80/Makefile
index 7eefffbdc925..fba189d26652 100644
--- a/drivers/gpu/drm/amd/display/dc/dce80/Makefile
+++ b/drivers/gpu/drm/amd/display/dc/dce80/Makefile
@@ -23,7 +23,7 @@
# Makefile for the 'controller' sub-component of DAL.
# It provides the control an
Re: [PATCH] drm/amd/display: Add monitor patch for specific eDP
On 2/27/24 13:18, Rodrigo Siqueira wrote:
From: Ivan Lipski
[WHY]
Some eDP panels's ext caps don't write initial value cause the value of
dpcd_addr(0x317) is random. It means that sometimes the eDP will
clarify it is OLED, miniLED...etc cause the backlight control interface
is incorrect.
[HOW]
Add a new panel patch to remove sink ext caps(HDR,OLED...etc)
I wonder if it would make sense to turn this into a DPCD qurik (see
drivers/gpu/drm/display/drm_dp_helper.c). Since, it is rather unsettling
that we have so many panel quirks in our driver.
Cc: sta...@vger.kernel.org # 6.5.x
Cc: Hamza Mahfooz
Cc: Tsung-hua Lin
Cc: Chris Chi
Cc: Harry Wentland
Tested-by: Daniel Wheeler
Reviewed-by: Sun peng Li
Acked-by: Rodrigo Siqueira
Signed-off-by: Ivan Lipski
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
index d9a482908380..764dc3ffd91b 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
@@ -63,6 +63,12 @@ static void apply_edid_quirks(struct edid *edid, struct
dc_edid_caps *edid_caps)
DRM_DEBUG_DRIVER("Disabling FAMS on monitor with panel id
%X\n", panel_id);
edid_caps->panel_patch.disable_fams = true;
break;
+ /* Workaround for some monitors that do not clear DPCD 0x317 if
FreeSync is unsupported */
+ case drm_edid_encode_panel_id('A', 'U', 'O', 0xA7AB):
+ case drm_edid_encode_panel_id('A', 'U', 'O', 0xE69B):
+ DRM_DEBUG_DRIVER("Clearing DPCD 0x317 on monitor with panel id
%X\n", panel_id);
+ edid_caps->panel_patch.remove_sink_ext_caps = true;
+ break;
default:
return;
}
--
Hamza
Re: [PATCH v2] drm/amd/display: add panel_power_savings sysfs entry to eDP connectors
On 2/16/24 03:19, Pekka Paalanen wrote:
On Fri, 2 Feb 2024 10:28:35 -0500
Hamza Mahfooz wrote:
We want programs besides the compositor to be able to enable or disable
panel power saving features.
Could you also explain why, in the commit message, please?
It is unexpected for arbitrary programs to be able to override the KMS
client, and certainly new ways to do so should not be added without an
excellent justification.
Also, to be completely honest with you, I'm not sure why it was
initially exposed as a DRM prop, since it's a power management feature.
Which is to say, that it doesn't really make sense to have the
compositor control it.
Maybe debugfs would be more appropriate if the purpose is only testing
rather than production environments?
However, since they are currently only
configurable through DRM properties, that isn't possible. So, to remedy
that issue introduce a new "panel_power_savings" sysfs attribute.
When the DRM property was added, what was used as the userspace to
prove its workings?
Thanks,
pq
Cc: Mario Limonciello
Signed-off-by: Hamza Mahfooz
---
v2: hide ABM_LEVEL_IMMEDIATE_DISABLE in the read case, force an atomic
commit when setting the value, call sysfs_remove_group() in
amdgpu_dm_connector_unregister() and add some documentation.
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 76 +++
1 file changed, 76 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 8590c9f1dda6..3c62489d03dc 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -6436,10 +6436,79 @@ int amdgpu_dm_connector_atomic_get_property(struct
drm_connector *connector,
return ret;
}
+/**
+ * DOC: panel power savings
+ *
+ * The display manager allows you to set your desired **panel power savings**
+ * level (between 0-4, with 0 representing off), e.g. using the following::
+ *
+ * # echo 3 > /sys/class/drm/card0-eDP-1/amdgpu/panel_power_savings
+ *
+ * Modifying this value can have implications on color accuracy, so tread
+ * carefully.
+ */
+
+static ssize_t panel_power_savings_show(struct device *device,
+ struct device_attribute *attr,
+ char *buf)
+{
+ struct drm_connector *connector = dev_get_drvdata(device);
+ struct drm_device *dev = connector->dev;
+ u8 val;
+
+ drm_modeset_lock(&dev->mode_config.connection_mutex, NULL);
+ val = to_dm_connector_state(connector->state)->abm_level ==
+ ABM_LEVEL_IMMEDIATE_DISABLE ? 0 :
+ to_dm_connector_state(connector->state)->abm_level;
+ drm_modeset_unlock(&dev->mode_config.connection_mutex);
+
+ return sysfs_emit(buf, "%u\n", val);
+}
+
+static ssize_t panel_power_savings_store(struct device *device,
+struct device_attribute *attr,
+const char *buf, size_t count)
+{
+ struct drm_connector *connector = dev_get_drvdata(device);
+ struct drm_device *dev = connector->dev;
+ long val;
+ int ret;
+
+ ret = kstrtol(buf, 0, &val);
+
+ if (ret)
+ return ret;
+
+ if (val < 0 || val > 4)
+ return -EINVAL;
+
+ drm_modeset_lock(&dev->mode_config.connection_mutex, NULL);
+ to_dm_connector_state(connector->state)->abm_level = val ?:
+ ABM_LEVEL_IMMEDIATE_DISABLE;
+ drm_modeset_unlock(&dev->mode_config.connection_mutex);
+
+ drm_kms_helper_hotplug_event(dev);
+
+ return count;
+}
+
+static DEVICE_ATTR_RW(panel_power_savings);
+
+static struct attribute *amdgpu_attrs[] = {
+ &dev_attr_panel_power_savings.attr,
+ NULL
+};
+
+static const struct attribute_group amdgpu_group = {
+ .name = "amdgpu",
+ .attrs = amdgpu_attrs
+};
+
static void amdgpu_dm_connector_unregister(struct drm_connector *connector)
{
struct amdgpu_dm_connector *amdgpu_dm_connector =
to_amdgpu_dm_connector(connector);
+ sysfs_remove_group(&connector->kdev->kobj, &amdgpu_group);
drm_dp_aux_unregister(&amdgpu_dm_connector->dm_dp_aux.aux);
}
@@ -6541,6 +6610,13 @@ amdgpu_dm_connector_late_register(struct drm_connector *connector)
to_amdgpu_dm_connector(connector);
int r;
+ if (connector->connector_type == DRM_MODE_CONNECTOR_eDP) {
+ r = sysfs_create_group(&connector->kdev->kobj,
+ &amdgpu_group);
+ if (r)
+ return r;
+ }
+
amdgpu_dm_register_backlight_device(amdgpu_dm_connector);
if ((connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort) ||
--
Hamza
Re: [PATCH v2] drm/amd/display: add panel_power_savings sysfs entry to eDP connectors
On 2/16/24 03:19, Pekka Paalanen wrote:
On Fri, 2 Feb 2024 10:28:35 -0500
Hamza Mahfooz wrote:
We want programs besides the compositor to be able to enable or disable
panel power saving features.
Could you also explain why, in the commit message, please?
It is unexpected for arbitrary programs to be able to override the KMS
client, and certainly new ways to do so should not be added without an
excellent justification.
Maybe debugfs would be more appropriate if the purpose is only testing
rather than production environments?
However, since they are currently only
configurable through DRM properties, that isn't possible. So, to remedy
that issue introduce a new "panel_power_savings" sysfs attribute.
When the DRM property was added, what was used as the userspace to
prove its workings?
To my knowledge, it is only used by IGT. Also, it is worth noting that
it is a vendor specific property, so I doubt there are any compositors
out there that felt motivated enough to use it in any capacity.
Thanks,
pq
Cc: Mario Limonciello
Signed-off-by: Hamza Mahfooz
---
v2: hide ABM_LEVEL_IMMEDIATE_DISABLE in the read case, force an atomic
commit when setting the value, call sysfs_remove_group() in
amdgpu_dm_connector_unregister() and add some documentation.
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 76 +++
1 file changed, 76 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 8590c9f1dda6..3c62489d03dc 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -6436,10 +6436,79 @@ int amdgpu_dm_connector_atomic_get_property(struct
drm_connector *connector,
return ret;
}
+/**
+ * DOC: panel power savings
+ *
+ * The display manager allows you to set your desired **panel power savings**
+ * level (between 0-4, with 0 representing off), e.g. using the following::
+ *
+ * # echo 3 > /sys/class/drm/card0-eDP-1/amdgpu/panel_power_savings
+ *
+ * Modifying this value can have implications on color accuracy, so tread
+ * carefully.
+ */
+
+static ssize_t panel_power_savings_show(struct device *device,
+ struct device_attribute *attr,
+ char *buf)
+{
+ struct drm_connector *connector = dev_get_drvdata(device);
+ struct drm_device *dev = connector->dev;
+ u8 val;
+
+ drm_modeset_lock(&dev->mode_config.connection_mutex, NULL);
+ val = to_dm_connector_state(connector->state)->abm_level ==
+ ABM_LEVEL_IMMEDIATE_DISABLE ? 0 :
+ to_dm_connector_state(connector->state)->abm_level;
+ drm_modeset_unlock(&dev->mode_config.connection_mutex);
+
+ return sysfs_emit(buf, "%u\n", val);
+}
+
+static ssize_t panel_power_savings_store(struct device *device,
+struct device_attribute *attr,
+const char *buf, size_t count)
+{
+ struct drm_connector *connector = dev_get_drvdata(device);
+ struct drm_device *dev = connector->dev;
+ long val;
+ int ret;
+
+ ret = kstrtol(buf, 0, &val);
+
+ if (ret)
+ return ret;
+
+ if (val < 0 || val > 4)
+ return -EINVAL;
+
+ drm_modeset_lock(&dev->mode_config.connection_mutex, NULL);
+ to_dm_connector_state(connector->state)->abm_level = val ?:
+ ABM_LEVEL_IMMEDIATE_DISABLE;
+ drm_modeset_unlock(&dev->mode_config.connection_mutex);
+
+ drm_kms_helper_hotplug_event(dev);
+
+ return count;
+}
+
+static DEVICE_ATTR_RW(panel_power_savings);
+
+static struct attribute *amdgpu_attrs[] = {
+ &dev_attr_panel_power_savings.attr,
+ NULL
+};
+
+static const struct attribute_group amdgpu_group = {
+ .name = "amdgpu",
+ .attrs = amdgpu_attrs
+};
+
static void amdgpu_dm_connector_unregister(struct drm_connector *connector)
{
struct amdgpu_dm_connector *amdgpu_dm_connector =
to_amdgpu_dm_connector(connector);
+ sysfs_remove_group(&connector->kdev->kobj, &amdgpu_group);
drm_dp_aux_unregister(&amdgpu_dm_connector->dm_dp_aux.aux);
}
@@ -6541,6 +6610,13 @@ amdgpu_dm_connector_late_register(struct drm_connector *connector)
to_amdgpu_dm_connector(connector);
int r;
+ if (connector->connector_type == DRM_MODE_CONNECTOR_eDP) {
+ r = sysfs_create_group(&connector->kdev->kobj,
+ &amdgpu_group);
+ if (r)
+ return r;
+ }
+
amdgpu_dm_register_backlight_device(amdgpu_dm_connector);
if ((connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort) ||
--
Hamza
Re: [PATCH] drm/amd/display: Fix && vs || typos
On 2/9/24 08:02, Dan Carpenter wrote:
These ANDs should be ORs or it will lead to a NULL dereference.
Fixes: fb5a3d037082 ("drm/amd/display: Add NULL test for 'timing generator' in
'dcn21_set_pipe()'")
Fixes: 886571d217d7 ("drm/amd/display: Fix 'panel_cntl' could be null in
'dcn21_set_backlight_level()'")
Signed-off-by: Dan Carpenter
Applied, thanks!
---
drivers/gpu/drm/amd/display/dc/hwss/dcn21/dcn21_hwseq.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/hwss/dcn21/dcn21_hwseq.c
b/drivers/gpu/drm/amd/display/dc/hwss/dcn21/dcn21_hwseq.c
index 5c7f380a84f9..7252f5f781f0 100644
--- a/drivers/gpu/drm/amd/display/dc/hwss/dcn21/dcn21_hwseq.c
+++ b/drivers/gpu/drm/amd/display/dc/hwss/dcn21/dcn21_hwseq.c
@@ -211,7 +211,7 @@ void dcn21_set_pipe(struct pipe_ctx *pipe_ctx)
struct dmcu *dmcu = pipe_ctx->stream->ctx->dc->res_pool->dmcu;
uint32_t otg_inst;
- if (!abm && !tg && !panel_cntl)
+ if (!abm || !tg || !panel_cntl)
return;
otg_inst = tg->inst;
@@ -245,7 +245,7 @@ bool dcn21_set_backlight_level(struct pipe_ctx *pipe_ctx,
struct panel_cntl *panel_cntl = pipe_ctx->stream->link->panel_cntl;
uint32_t otg_inst;
- if (!abm && !tg && !panel_cntl)
+ if (!abm || !tg || !panel_cntl)
return false;
otg_inst = tg->inst;
--
Hamza
[PATCH 3/3] drm/amdgpu: wire up the can_remove() callback
Removing an amdgpu device that still has user space references allocated
to it causes undefined behaviour. So, implement amdgpu_pci_can_remove()
and disallow devices that still have files allocated to them from being
unbound.
Cc: sta...@vger.kernel.org
Signed-off-by: Hamza Mahfooz
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index cc69005f5b46..cfa64f3c5be5 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -2323,6 +2323,22 @@ static int amdgpu_pci_probe(struct pci_dev *pdev,
return ret;
}
+static bool amdgpu_pci_can_remove(struct pci_dev *pdev)
+{
+ struct drm_device *dev = pci_get_drvdata(pdev);
+
+ mutex_lock(&dev->filelist_mutex);
+
+ if (!list_empty(&dev->filelist)) {
+ mutex_unlock(&dev->filelist_mutex);
+ return false;
+ }
+
+ mutex_unlock(&dev->filelist_mutex);
+
+ return true;
+}
+
static void
amdgpu_pci_remove(struct pci_dev *pdev)
{
@@ -2929,6 +2945,7 @@ static struct pci_driver amdgpu_kms_pci_driver = {
.name = DRIVER_NAME,
.id_table = pciidlist,
.probe = amdgpu_pci_probe,
+ .can_remove = amdgpu_pci_can_remove,
.remove = amdgpu_pci_remove,
.shutdown = amdgpu_pci_shutdown,
.driver.pm = &amdgpu_pm_ops,
--
2.43.0
[PATCH 2/3] PCI: introduce can_remove()
Wire up the can_remove() callback, such that pci drivers can implement
their own version of it.
Cc: sta...@vger.kernel.org
Signed-off-by: Hamza Mahfooz
---
drivers/pci/pci-driver.c | 12
include/linux/pci.h | 5 +
2 files changed, 17 insertions(+)
diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c
index 51ec9e7e784f..8aae484c5494 100644
--- a/drivers/pci/pci-driver.c
+++ b/drivers/pci/pci-driver.c
@@ -466,6 +466,17 @@ static int pci_device_probe(struct device *dev)
return error;
}
+static bool pci_device_can_remove(struct device *dev)
+{
+ struct pci_dev *pci_dev = to_pci_dev(dev);
+ struct pci_driver *drv = pci_dev->driver;
+
+ if (drv->can_remove)
+ return drv->can_remove(pci_dev);
+
+ return true;
+}
+
static void pci_device_remove(struct device *dev)
{
struct pci_dev *pci_dev = to_pci_dev(dev);
@@ -1680,6 +1691,7 @@ struct bus_type pci_bus_type = {
.match = pci_bus_match,
.uevent = pci_uevent,
.probe = pci_device_probe,
+ .can_remove = pci_device_can_remove,
.remove = pci_device_remove,
.shutdown = pci_device_shutdown,
.dev_groups = pci_dev_groups,
diff --git a/include/linux/pci.h b/include/linux/pci.h
index add9368e6314..95276f44b23b 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -902,6 +902,10 @@ struct module;
* (negative number) otherwise.
* The probe function always gets called from process
* context, so it can sleep.
+ * @can_remove:The can_remove() function gets called during driver
+ * deregistration to determine if remove() can be called.
+ * The probe function always gets called from process
+ * context, so it can sleep.
* @remove:The remove() function gets called whenever a device
* being handled by this driver is removed (either during
* deregistration of the driver or when it's manually
@@ -943,6 +947,7 @@ struct pci_driver {
const char *name;
const struct pci_device_id *id_table; /* Must be non-NULL for probe
to be called */
int (*probe)(struct pci_dev *dev, const struct pci_device_id *id);
/* New device inserted */
+ bool (*can_remove)(struct pci_dev *dev);
void (*remove)(struct pci_dev *dev);/* Device removed (NULL if not
a hot-plug capable driver) */
int (*suspend)(struct pci_dev *dev, pm_message_t state); /*
Device suspended */
int (*resume)(struct pci_dev *dev);/* Device woken up */
--
2.43.0
[PATCH 1/3] driver core: bus: introduce can_remove()
Currently, drivers have no mechanism to block requests to unbind
devices. However, this can cause resource leaks and leave the device in
an inconsistent state, such that rebinding the device may cause a hang
or otherwise prevent the device from being rebound. So, introduce
the can_remove() callback to allow drivers to indicate if it isn't
appropriate to remove a device at the given time.
Cc: sta...@vger.kernel.org
Signed-off-by: Hamza Mahfooz
---
drivers/base/bus.c | 4
include/linux/device/bus.h | 2 ++
2 files changed, 6 insertions(+)
diff --git a/drivers/base/bus.c b/drivers/base/bus.c
index daee55c9b2d9..7c259b01ea99 100644
--- a/drivers/base/bus.c
+++ b/drivers/base/bus.c
@@ -239,6 +239,10 @@ static ssize_t unbind_store(struct device_driver *drv,
const char *buf,
dev = bus_find_device_by_name(bus, NULL, buf);
if (dev && dev->driver == drv) {
+ if (dev->bus && dev->bus->can_remove &&
+ !dev->bus->can_remove(dev))
+ return -EBUSY;
+
device_driver_detach(dev);
err = count;
}
diff --git a/include/linux/device/bus.h b/include/linux/device/bus.h
index 5ef4ec1c36c3..c9d4af0ed3b8 100644
--- a/include/linux/device/bus.h
+++ b/include/linux/device/bus.h
@@ -46,6 +46,7 @@ struct fwnode_handle;
* be called at late_initcall_sync level. If the device has
* consumers that are never bound to a driver, this function
* will never get called until they do.
+ * @can_remove: Called before attempting to remove a device from this bus.
* @remove:Called when a device removed from this bus.
* @shutdown: Called at shut-down time to quiesce the device.
*
@@ -85,6 +86,7 @@ struct bus_type {
int (*uevent)(const struct device *dev, struct kobj_uevent_env *env);
int (*probe)(struct device *dev);
void (*sync_state)(struct device *dev);
+ bool (*can_remove)(struct device *dev);
void (*remove)(struct device *dev);
void (*shutdown)(struct device *dev);
--
2.43.0
[PATCH v2] drm/amd/display: add panel_power_savings sysfs entry to eDP connectors
We want programs besides the compositor to be able to enable or disable
panel power saving features. However, since they are currently only
configurable through DRM properties, that isn't possible. So, to remedy
that issue introduce a new "panel_power_savings" sysfs attribute.
Cc: Mario Limonciello
Signed-off-by: Hamza Mahfooz
---
v2: hide ABM_LEVEL_IMMEDIATE_DISABLE in the read case, force an atomic
commit when setting the value, call sysfs_remove_group() in
amdgpu_dm_connector_unregister() and add some documentation.
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 76 +++
1 file changed, 76 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 8590c9f1dda6..3c62489d03dc 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -6436,10 +6436,79 @@ int amdgpu_dm_connector_atomic_get_property(struct
drm_connector *connector,
return ret;
}
+/**
+ * DOC: panel power savings
+ *
+ * The display manager allows you to set your desired **panel power savings**
+ * level (between 0-4, with 0 representing off), e.g. using the following::
+ *
+ * # echo 3 > /sys/class/drm/card0-eDP-1/amdgpu/panel_power_savings
+ *
+ * Modifying this value can have implications on color accuracy, so tread
+ * carefully.
+ */
+
+static ssize_t panel_power_savings_show(struct device *device,
+ struct device_attribute *attr,
+ char *buf)
+{
+ struct drm_connector *connector = dev_get_drvdata(device);
+ struct drm_device *dev = connector->dev;
+ u8 val;
+
+ drm_modeset_lock(&dev->mode_config.connection_mutex, NULL);
+ val = to_dm_connector_state(connector->state)->abm_level ==
+ ABM_LEVEL_IMMEDIATE_DISABLE ? 0 :
+ to_dm_connector_state(connector->state)->abm_level;
+ drm_modeset_unlock(&dev->mode_config.connection_mutex);
+
+ return sysfs_emit(buf, "%u\n", val);
+}
+
+static ssize_t panel_power_savings_store(struct device *device,
+struct device_attribute *attr,
+const char *buf, size_t count)
+{
+ struct drm_connector *connector = dev_get_drvdata(device);
+ struct drm_device *dev = connector->dev;
+ long val;
+ int ret;
+
+ ret = kstrtol(buf, 0, &val);
+
+ if (ret)
+ return ret;
+
+ if (val < 0 || val > 4)
+ return -EINVAL;
+
+ drm_modeset_lock(&dev->mode_config.connection_mutex, NULL);
+ to_dm_connector_state(connector->state)->abm_level = val ?:
+ ABM_LEVEL_IMMEDIATE_DISABLE;
+ drm_modeset_unlock(&dev->mode_config.connection_mutex);
+
+ drm_kms_helper_hotplug_event(dev);
+
+ return count;
+}
+
+static DEVICE_ATTR_RW(panel_power_savings);
+
+static struct attribute *amdgpu_attrs[] = {
+ &dev_attr_panel_power_savings.attr,
+ NULL
+};
+
+static const struct attribute_group amdgpu_group = {
+ .name = "amdgpu",
+ .attrs = amdgpu_attrs
+};
+
static void amdgpu_dm_connector_unregister(struct drm_connector *connector)
{
struct amdgpu_dm_connector *amdgpu_dm_connector =
to_amdgpu_dm_connector(connector);
+ sysfs_remove_group(&connector->kdev->kobj, &amdgpu_group);
drm_dp_aux_unregister(&amdgpu_dm_connector->dm_dp_aux.aux);
}
@@ -6541,6 +6610,13 @@ amdgpu_dm_connector_late_register(struct drm_connector
*connector)
to_amdgpu_dm_connector(connector);
int r;
+ if (connector->connector_type == DRM_MODE_CONNECTOR_eDP) {
+ r = sysfs_create_group(&connector->kdev->kobj,
+ &amdgpu_group);
+ if (r)
+ return r;
+ }
+
amdgpu_dm_register_backlight_device(amdgpu_dm_connector);
if ((connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort) ||
--
2.43.0
Re: [PATCH 2/6] drm: add drm_gem_object_is_shared_for_memory_stats() helper
On 1/30/24 11:12, Alex Deucher wrote:
Add a helper so that drm drivers can consistently report
shared status via the fdinfo shared memory stats interface.
In addition to handle count, show buffers as shared if they
are shared via dma-buf as well (e.g., shared with v4l or some
other subsystem).
Link:
https://lore.kernel.org/all/20231207180225.439482-1-alexander.deuc...@amd.com/
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/drm_gem.c | 16
include/drm/drm_gem.h | 1 +
2 files changed, 17 insertions(+)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 44a948b80ee1..71b5f628d828 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -1506,3 +1506,19 @@ int drm_gem_evict(struct drm_gem_object *obj)
return 0;
}
EXPORT_SYMBOL(drm_gem_evict);
+
+/**
+ * drm_gem_object_is_shared_for_memory_stats - helper for shared memory stats
+ *
+ * This helper should only be used for fdinfo shared memory stats to determine
+ * if a GEM object is shared.
+ *
+ * @obj: obj in question
+ */
+bool drm_gem_object_is_shared_for_memory_stats(struct drm_gem_object *obj)
+{
+ if ((obj->handle_count > 1) || obj->dma_buf)
+ return true;
+ return false;
nit: you can simplify this to:
return (obj->handle_count > 1) || obj->dma_buf;
(It maybe worth just inlining this to drm_gem.h).
+}
+EXPORT_SYMBOL(drm_gem_object_is_shared_for_memory_stats);
diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
index 369505447acd..86a9c696f038 100644
--- a/include/drm/drm_gem.h
+++ b/include/drm/drm_gem.h
@@ -552,6 +552,7 @@ unsigned long drm_gem_lru_scan(struct drm_gem_lru *lru,
bool (*shrink)(struct drm_gem_object *obj));
int drm_gem_evict(struct drm_gem_object *obj);
+bool drm_gem_object_is_shared_for_memory_stats(struct drm_gem_object *obj);
#ifdef CONFIG_LOCKDEP
/**
--
Hamza
[PATCH] drm/amd/display: add panel_power_savings sysfs entry to eDP connectors
We want programs besides the compositor to be able to enable or disable
panel power saving features. However, since they are currently only
configurable through DRM properties, that isn't possible. So, to remedy
that issue introduce a new "panel_power_savings" sysfs attribute.
Cc: Mario Limonciello
Signed-off-by: Hamza Mahfooz
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 59 +++
1 file changed, 59 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index cd98b3565178..b3fcd833015d 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -6534,6 +6534,58 @@ amdgpu_dm_connector_atomic_duplicate_state(struct
drm_connector *connector)
return &new_state->base;
}
+static ssize_t panel_power_savings_show(struct device *device,
+ struct device_attribute *attr,
+ char *buf)
+{
+ struct drm_connector *connector = dev_get_drvdata(device);
+ struct drm_device *dev = connector->dev;
+ ssize_t val;
+
+ drm_modeset_lock(&dev->mode_config.connection_mutex, NULL);
+ val = to_dm_connector_state(connector->state)->abm_level;
+ drm_modeset_unlock(&dev->mode_config.connection_mutex);
+
+ return sysfs_emit(buf, "%lu\n", val);
+}
+
+static ssize_t panel_power_savings_store(struct device *device,
+struct device_attribute *attr,
+const char *buf, size_t count)
+{
+ struct drm_connector *connector = dev_get_drvdata(device);
+ struct drm_device *dev = connector->dev;
+ long val;
+ int ret;
+
+ ret = kstrtol(buf, 0, &val);
+
+ if (ret)
+ return ret;
+
+ if (val < 0 || val > 4)
+ return -EINVAL;
+
+ drm_modeset_lock(&dev->mode_config.connection_mutex, NULL);
+ to_dm_connector_state(connector->state)->abm_level = val ?:
+ ABM_LEVEL_IMMEDIATE_DISABLE;
+ drm_modeset_unlock(&dev->mode_config.connection_mutex);
+
+ return count;
+}
+
+static DEVICE_ATTR_RW(panel_power_savings);
+
+static struct attribute *amdgpu_attrs[] = {
+ &dev_attr_panel_power_savings.attr,
+ NULL
+};
+
+static const struct attribute_group amdgpu_group = {
+ .name = "amdgpu",
+ .attrs = amdgpu_attrs
+};
+
static int
amdgpu_dm_connector_late_register(struct drm_connector *connector)
{
@@ -6541,6 +6593,13 @@ amdgpu_dm_connector_late_register(struct drm_connector
*connector)
to_amdgpu_dm_connector(connector);
int r;
+ if (connector->connector_type == DRM_MODE_CONNECTOR_eDP) {
+ r = sysfs_create_group(&connector->kdev->kobj,
+ &amdgpu_group);
+ if (r)
+ return r;
+ }
+
amdgpu_dm_register_backlight_device(amdgpu_dm_connector);
if ((connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort) ||
--
2.43.0
Re: [PATCH] drm/amd/display: Fix a switch statement in populate_dml_output_cfg_from_stream_state()
On 1/13/24 09:58, Christophe JAILLET wrote:
It is likely that the statement related to 'dml_edp' is misplaced. So move
it in the correct "case SIGNAL_TYPE_EDP".
Fixes: 7966f319c66d ("drm/amd/display: Introduce DML2")
Signed-off-by: Christophe JAILLET
Nice catch! Applied, thanks!
---
drivers/gpu/drm/amd/display/dc/dml2/dml2_translation_helper.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dml2/dml2_translation_helper.c
b/drivers/gpu/drm/amd/display/dc/dml2/dml2_translation_helper.c
index fa6a93dd9629..64d01a9cd68c 100644
--- a/drivers/gpu/drm/amd/display/dc/dml2/dml2_translation_helper.c
+++ b/drivers/gpu/drm/amd/display/dc/dml2/dml2_translation_helper.c
@@ -626,8 +626,8 @@ static void
populate_dml_output_cfg_from_stream_state(struct dml_output_cfg_st *
if (is_dp2p0_output_encoder(pipe))
out->OutputEncoder[location] = dml_dp2p0;
break;
- out->OutputEncoder[location] = dml_edp;
case SIGNAL_TYPE_EDP:
+ out->OutputEncoder[location] = dml_edp;
break;
case SIGNAL_TYPE_HDMI_TYPE_A:
case SIGNAL_TYPE_DVI_SINGLE_LINK:
--
Hamza
Re: [PATCH 6/6] drm: Add CONFIG_DRM_WERROR
On 1/10/24 12:39, Jani Nikula wrote: Add kconfig to enable -Werror subsystem wide. This is useful for development and CI to keep the subsystem warning free, while avoiding issues outside of the subsystem that kernel wide CONFIG_WERROR=y might hit. Signed-off-by: Jani Nikula Reviewed-by: Hamza Mahfooz --- drivers/gpu/drm/Kconfig | 18 ++ drivers/gpu/drm/Makefile | 3 +++ 2 files changed, 21 insertions(+) diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index 6ec33d36f3a4..36a00cba2540 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -414,3 +414,21 @@ config DRM_LIB_RANDOM config DRM_PRIVACY_SCREEN bool default n + +config DRM_WERROR + bool "Compile the drm subsystem with warnings as errors" + # As this may inadvertently break the build, only allow the user + # to shoot oneself in the foot iff they aim really hard + depends on EXPERT + # We use the dependency on !COMPILE_TEST to not be enabled in + # allmodconfig or allyesconfig configurations + depends on !COMPILE_TEST + default n + help + A kernel build should not cause any compiler warnings, and this + enables the '-Werror' flag to enforce that rule in the drm subsystem. + + The drm subsystem enables more warnings than the kernel default, so + this config option is disabled by default. + + If in doubt, say N. diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile index 8b6be830f7c3..b7fd3e58b7af 100644 --- a/drivers/gpu/drm/Makefile +++ b/drivers/gpu/drm/Makefile @@ -32,6 +32,9 @@ subdir-ccflags-y += -Wno-sign-compare endif # --- end copy-paste +# Enable -Werror in CI and development +subdir-ccflags-$(CONFIG_DRM_WERROR) += -Werror + drm-y := \ drm_aperture.o \ drm_atomic.o \ -- Hamza
Re: [PATCH 5/6] drm: enable (most) W=1 warnings by default across the subsystem
On 1/10/24 12:39, Jani Nikula wrote: At least the i915 and amd drivers enable a bunch more compiler warnings than the kernel defaults. Extend most of the W=1 warnings to the entire drm subsystem by default. Use the copy-pasted warnings from scripts/Makefile.extrawarn with s/KBUILD_CFLAGS/subdir-ccflags-y/ to make it easier to compare and keep up with them in the future. This is similar to the approach currently used in i915. Some of the -Wextra warnings do need to be disabled, just like in Makefile.extrawarn, but take care to not disable them for W=2 or W=3 builds, depending on the warning. There are too many -Wformat-truncation warnings to cleanly fix up front; leave that warning disabled for now. v2: - Drop -Wformat-truncation (too many warnings) - Drop -Wstringop-overflow (enabled by default upstream) Cc: David Airlie Cc: Daniel Vetter Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Thomas Zimmermann Cc: Alex Deucher Cc: Christian König Cc: Pan, Xinhui Cc: Karol Herbst Cc: Lyude Paul Cc: Danilo Krummrich Cc: Rob Clark Cc: Abhinav Kumar Cc: Dmitry Baryshkov Cc: Sean Paul Cc: Marijn Suijten Cc: Hamza Mahfooz Acked-by: Javier Martinez Canillas Acked-by: Thomas Zimmermann Acked-by: Sui Jingfeng Signed-off-by: Jani Nikula --- drivers/gpu/drm/Makefile | 27 +++ 1 file changed, 27 insertions(+) diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile index 104b42df2e95..8b6be830f7c3 100644 --- a/drivers/gpu/drm/Makefile +++ b/drivers/gpu/drm/Makefile @@ -5,6 +5,33 @@ CFLAGS-$(CONFIG_DRM_USE_DYNAMIC_DEBUG) += -DDYNAMIC_DEBUG_MODULE +# Unconditionally enable W=1 warnings locally +# --- begin copy-paste W=1 warnings from scripts/Makefile.extrawarn +subdir-ccflags-y += -Wextra -Wunused -Wno-unused-parameter +subdir-ccflags-y += -Wmissing-declarations +subdir-ccflags-y += $(call cc-option, -Wrestrict) It would be safer to do something along the lines of: cond-flags := $(call cc-option, -Wrestrict) \ $(call cc-option, -Wunused-but-set-variable) \ $(call cc-option, -Wunused-const-variable) \ $(call cc-option, -Wunused-const-variable) \ $(call cc-option, -Wformat-overflow) \ $(call cc-option, -Wstringop-truncation) subdir-ccflags-y += $(cond-flags) Otherwise, you will end up breaking `$ make M=drivers/gpu/drm` for a bunch of people. +subdir-ccflags-y += -Wmissing-format-attribute +subdir-ccflags-y += -Wmissing-prototypes +subdir-ccflags-y += -Wold-style-definition +subdir-ccflags-y += -Wmissing-include-dirs +subdir-ccflags-y += $(call cc-option, -Wunused-but-set-variable) +subdir-ccflags-y += $(call cc-option, -Wunused-const-variable) +subdir-ccflags-y += $(call cc-option, -Wpacked-not-aligned) +subdir-ccflags-y += $(call cc-option, -Wformat-overflow) +# FIXME: fix -Wformat-truncation warnings and uncomment +#subdir-ccflags-y += $(call cc-option, -Wformat-truncation) +subdir-ccflags-y += $(call cc-option, -Wstringop-truncation) +# The following turn off the warnings enabled by -Wextra +ifeq ($(findstring 2, $(KBUILD_EXTRA_WARN)),) +subdir-ccflags-y += -Wno-missing-field-initializers +subdir-ccflags-y += -Wno-type-limits +subdir-ccflags-y += -Wno-shift-negative-value +endif +ifeq ($(findstring 3, $(KBUILD_EXTRA_WARN)),) +subdir-ccflags-y += -Wno-sign-compare +endif +# --- end copy-paste + drm-y := \ drm_aperture.o \ drm_atomic.o \ -- Hamza
Re: [RFC PATCH] drm/amd/display: fix bandwidth validation failure on DCN 2.1
On 12/29/23 11:25, Melissa Wen wrote:
IGT `amdgpu/amd_color/crtc-lut-accuracy` fails right at the beginning of
the test execution, during atomic check, because DC rejects the
bandwidth state for a fb sizing 64x64. The test was previously working
with the deprecated dc_commit_state(). Now using
dc_validate_with_context() approach, the atomic check needs to perform a
full state validation. Therefore, set fast_validation to false in the
dc_validate_global_state call for atomic check.
Fixes: b8272241ff9d ("drm/amd/display: Drop dc_commit_state in favor of
dc_commit_streams")
Signed-off-by: Melissa Wen
---
Hi,
It's a long story. I was inspecting this bug report:
- https://gitlab.freedesktop.org/drm/amd/-/issues/2016
and noticed the IGT test `igt@amdgpu/amd_color@crtc-lut-accuracy`
mentioned there wasn't even being executed on a laptop with DCN 2.1
(HP HP ENVY x360 Convertible 13-ay1xxx/8929). The test fails right at
the beginning due to an atomic check rejection, as below:
Starting subtest: crtc-lut-accuracy
(amd_color:14772) igt_kms-CRITICAL: Test assertion failure function
igt_display_commit_atomic, file ../lib/igt_kms.c:4530:
(amd_color:14772) igt_kms-CRITICAL: Failed assertion: ret == 0
(amd_color:14772) igt_kms-CRITICAL: Last errno: 22, Invalid argument
(amd_color:14772) igt_kms-CRITICAL: error: -22 != 0
Stack trace:
#0 ../lib/igt_core.c:1989 __igt_fail_assert()
#1 [igt_display_commit_atomic+0x44]
#2 ../tests/amdgpu/amd_color.c:159 __igt_uniquereal_main395()
#3 ../tests/amdgpu/amd_color.c:395 main()
#4 ../sysdeps/nptl/libc_start_call_main.h:74 __libc_start_call_main()
#5 ../csu/libc-start.c:128 __libc_start_main@@GLIBC_2.34()
#6 [_start+0x21]
Subtest crtc-lut-accuracy failed.
Checking dmesg, we can see that a bandwidth validation failure causes
the atomic check rejection:
[ 711.147663] amdgpu :04:00.0: [drm] Mode Validation Warning: Unknown
Status failed validation.
[ 711.147667] [drm:amdgpu_dm_atomic_check [amdgpu]] DC global validation
failure: Bandwidth validation failure (BW and Watermark) (13)
[ 711.147772] [drm:amdgpu_irq_dispatch [amdgpu]] Unregistered interrupt
src_id: 243 of client_id:8
[ 711.148033] [drm:amdgpu_dm_atomic_check [amdgpu]] Atomic check failed with
err: -22
I also noticed that the atomic check doesn't fail if I change the fb
width and height used in the test from 64 to 66, and I can get the test
execution back (and with success). However, I recall that all test cases
of IGT `amd_color` were working in the past, so I bisected and found the
first bad commit:
b8272241ff9d drm/amd/display: Drop dc_commit_state in favor of dc_commit_streams
Bringing the `dc_commit_state` machinery back also prevents the
bandwidth validation failure, but the commit above says
dc_commit_streams validation is more complete than dc_commit_state, so I
discarded this approach.
After some debugging and code inspection, I found out that avoiding fast
validation on dc_validate_global_state during atomic check solves the
issue, but I'm not sure if this change may affect performance. I
compared exec time of some IGT tests and didn't see any differences, but
I recognize it doesn't provide enough evidence.
What do you think about this change? Should I examine other things? Do
you see any potential issue that I should investigate? Could you
recommend a better approach to assess any side-effect of not enabling
fast validation in the atomic check?
Please, let me know your thoughts.
We shouldn't be doing fast updates when lock_and_validation_needed is
true, so this seems to be correct.
Which is to say, applied, thanks!
Cc: sta...@vger.kernel.org
Happy New Year!
Melissa
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 2845c884398e..4f51a7ad7a3c 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -10745,7 +10745,7 @@ static int amdgpu_dm_atomic_check(struct drm_device
*dev,
DRM_DEBUG_DRIVER("drm_dp_mst_atomic_check() failed\n");
goto fail;
}
- status = dc_validate_global_state(dc, dm_state->context, true);
+ status = dc_validate_global_state(dc, dm_state->context, false);
if (status != DC_OK) {
DRM_DEBUG_DRIVER("DC global validation failure: %s
(%d)",
dc_status_to_str(status), status);
--
Hamza
Re: [PATCH v2 4/5] drm/atomic: Make the drm_atomic_state documentation less ambiguous
On 12/14/23 05:09, Maxime Ripard wrote:
The current documentation of drm_atomic_state says that it's the "global
state object". This is confusing since, while it does contain all the
objects affected by an update and their respective states, if an object
isn't affected by this update it won't be part of it.
Thus, it's not truly a "global state", unlike object state structures
that do contain the entire state of a given object.
Signed-off-by: Maxime Ripard
Reviewed-by: Hamza Mahfooz
---
include/drm/drm_atomic.h | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
index 914574b58ae7..5df67e587816 100644
--- a/include/drm/drm_atomic.h
+++ b/include/drm/drm_atomic.h
@@ -346,7 +346,13 @@ struct __drm_private_objs_state {
};
/**
- * struct drm_atomic_state - the global state object for atomic updates
+ * struct drm_atomic_state - Atomic commit structure
+ *
+ * This structure is the kernel counterpart of @drm_mode_atomic and represents
+ * an atomic commit that transitions from an old to a new display state. It
+ * contains all the objects affected by an atomic commits and both the new
+ * state structures and pointers to the old state structures for
+ * these.
*
* States are added to an atomic update by calling
drm_atomic_get_crtc_state(),
* drm_atomic_get_plane_state(), drm_atomic_get_connector_state(), or for
--
Hamza
Re: [RFC] drm: enable W=1 warnings by default across the subsystem
Cc: Nathan Chancellor On 11/29/23 13:12, Jani Nikula wrote: At least the i915 and amd drivers enable a bunch more compiler warnings than the kernel defaults. Extend the W=1 warnings to the entire drm subsystem by default. Use the copy-pasted warnings from scripts/Makefile.extrawarn with s/KBUILD_CFLAGS/subdir-ccflags-y/ to make it easier to compare and keep up with them in the future. This is similar to the approach currently used in i915. Some of the -Wextra warnings do need to be disabled, just like in Makefile.extrawarn, but take care to not disable them for W=2 or W=3 builds, depending on the warning. I think this should go in after drm-misc-next has a clean build (for COMPILE_TEST builds) with this patch applied. Otherwise, it will break a lot of build configs. Cc: David Airlie Cc: Daniel Vetter Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Thomas Zimmermann Cc: Alex Deucher Cc: Christian König Cc: Pan, Xinhui Cc: Karol Herbst Cc: Lyude Paul Cc: Danilo Krummrich Cc: Rob Clark Cc: Abhinav Kumar Cc: Dmitry Baryshkov Cc: Sean Paul Cc: Marijn Suijten Signed-off-by: Jani Nikula --- With my admittedly limited and very much x86 focused kernel config, I get some -Wunused-but-set-variable and -Wformat-truncation= warnings, but nothing we can't handle. We could fix them up front, or disable the extra warnings on a per driver basis with a FIXME comment in their respective Makefiles. With the experience from i915, I think this would significantly reduce the constant loop of warnings added by people not using W=1 and subsequently fixed by people using W=1. Note: I've Cc'd the maintainers of drm, drm misc and some of the biggest drivers. --- drivers/gpu/drm/Makefile | 27 +++ 1 file changed, 27 insertions(+) diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile index b4cb0835620a..6939e4ea13d5 100644 --- a/drivers/gpu/drm/Makefile +++ b/drivers/gpu/drm/Makefile @@ -5,6 +5,33 @@ CFLAGS-$(CONFIG_DRM_USE_DYNAMIC_DEBUG) += -DDYNAMIC_DEBUG_MODULE +# Unconditionally enable W=1 warnings locally +# --- begin copy-paste W=1 warnings from scripts/Makefile.extrawarn +subdir-ccflags-y += -Wextra -Wunused -Wno-unused-parameter +subdir-ccflags-y += -Wmissing-declarations +subdir-ccflags-y += $(call cc-option, -Wrestrict) +subdir-ccflags-y += -Wmissing-format-attribute +subdir-ccflags-y += -Wmissing-prototypes +subdir-ccflags-y += -Wold-style-definition +subdir-ccflags-y += -Wmissing-include-dirs +subdir-ccflags-y += $(call cc-option, -Wunused-but-set-variable) +subdir-ccflags-y += $(call cc-option, -Wunused-const-variable) +subdir-ccflags-y += $(call cc-option, -Wpacked-not-aligned) +subdir-ccflags-y += $(call cc-option, -Wformat-overflow) +subdir-ccflags-y += $(call cc-option, -Wformat-truncation) +subdir-ccflags-y += $(call cc-option, -Wstringop-overflow) +subdir-ccflags-y += $(call cc-option, -Wstringop-truncation) +# The following turn off the warnings enabled by -Wextra +ifeq ($(findstring 2, $(KBUILD_EXTRA_WARN)),) +subdir-ccflags-y += -Wno-missing-field-initializers +subdir-ccflags-y += -Wno-type-limits +subdir-ccflags-y += -Wno-shift-negative-value +endif +ifeq ($(findstring 3, $(KBUILD_EXTRA_WARN)),) +subdir-ccflags-y += -Wno-sign-compare +endif +# --- end copy-paste + drm-y := \ drm_aperture.o \ drm_atomic.o \ -- Hamza
Re: [PATCH 2/2] drm/amdgpu: use GTT only as fallback for VRAM|GTT
On 11/27/23 09:54, Christian König wrote: Try to fill up VRAM as well by setting the busy flag on GTT allocations. This fixes the issue that when VRAM was evacuated for suspend it's never filled up again unless the application is restarted. Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2893 Signed-off-by: Christian König --- drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c index aa0dd6dad068..ddc8fb4db678 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c @@ -173,6 +173,12 @@ void amdgpu_bo_placement_from_domain(struct amdgpu_bo *abo, u32 domain) abo->flags & AMDGPU_GEM_CREATE_PREEMPTIBLE ? AMDGPU_PL_PREEMPT : TTM_PL_TT; places[c].flags = 0; + /* +* When GTT is just an alternative to VRAM make sure that we +* only use it as fallback and still try to fill up VRAM first. +*/ + if (domain & AMDGPU_GEM_DOMAIN_VRAM) + places[c].flags |= TTM_PL_FLAG_BUSY; c++; } -- Hamza
Re: [PATCH v9 0/4] drm: Add support for atomic async page-flip
Hi André, On 11/22/23 11:19, André Almeida wrote: Hi, This work from me and Simon adds support for DRM_MODE_PAGE_FLIP_ASYNC through the atomic API. This feature is already available via the legacy API. The use case is to be able to present a new frame immediately (or as soon as possible), even if after missing a vblank. This might result in tearing, but it's useful when a high framerate is desired, such as for gaming. Differently from earlier versions, this one refuses to flip if any prop changes for async flips. The idea is that the fast path of immediate page flips doesn't play well with modeset changes, so only the fb_id can be changed. Tested with: - Intel TigerLake-LP GT2 - AMD VanGogh Have you had a chance to test this with VRR enabled? Since, I suspect this series might break that feature. Thanks, André - User-space patch: https://github.com/Plagman/gamescope/pull/595 - IGT tests: https://lore.kernel.org/all/20231110163811.24158-1-andrealm...@igalia.com/ Changes from v8: - Dropped atomic_async_page_flip_not_supported, giving that current design works with any driver that support atomic and async at the same time. - Dropped the patch that disabled atomic_async_page_flip_not_supported for AMD. - Reordered commits v8: https://lore.kernel.org/all/20231025005318.293690-1-andrealm...@igalia.com/ Changes from v7: - Only accept flips to primary planes. If a driver support flips in different planes, support will be added later. v7: https://lore.kernel.org/dri-devel/20231017092837.32428-1-andrealm...@igalia.com/ Changes from v6: - Dropped the exception to allow MODE_ID changes (Simon) - Clarify what happens when flipping with the same FB_ID (Pekka) v6: https://lore.kernel.org/dri-devel/20230815185710.159779-1-andrealm...@igalia.com/ Changes from v5: - Add note in the docs that not every redundant attribute will result in no-op, some might cause oversynchronization issues. v5: https://lore.kernel.org/dri-devel/20230707224059.305474-1-andrealm...@igalia.com/ Changes from v4: - Documentation rewrote by Pekka Paalanen v4: https://lore.kernel.org/dri-devel/20230701020917.143394-1-andrealm...@igalia.com/ Changes from v3: - Add new patch to reject prop changes - Add a documentation clarifying the KMS atomic state set v3: https://lore.kernel.org/dri-devel/20220929184307.258331-1-cont...@emersion.fr/ André Almeida (1): drm: Refuse to async flip with atomic prop changes Pekka Paalanen (1): drm/doc: Define KMS atomic state set Simon Ser (2): drm: allow DRM_MODE_PAGE_FLIP_ASYNC for atomic commits drm: introduce DRM_CAP_ATOMIC_ASYNC_PAGE_FLIP Documentation/gpu/drm-uapi.rst | 47 ++ drivers/gpu/drm/drm_atomic_uapi.c | 77 ++--- drivers/gpu/drm/drm_crtc_internal.h | 2 +- drivers/gpu/drm/drm_ioctl.c | 4 ++ drivers/gpu/drm/drm_mode_object.c | 2 +- include/uapi/drm/drm.h | 10 +++- include/uapi/drm/drm_mode.h | 9 7 files changed, 142 insertions(+), 9 deletions(-) -- Hamza
Re: [Bug 218168] New: amdgpu: kfd_topology.c warning: the frame size of 1408 bytes is larger than 1024 bytes
+ amd-gfx + Felix On 11/20/23 10:16, bugzilla-dae...@kernel.org wrote: https://bugzilla.kernel.org/show_bug.cgi?id=218168 Bug ID: 218168 Summary: amdgpu: kfd_topology.c warning: the frame size of 1408 bytes is larger than 1024 bytes Product: Drivers Version: 2.5 Hardware: All OS: Linux Status: NEW Severity: normal Priority: P3 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: bluesun...@gmail.com Regression: No Trying to compile Linux 6.6.2 with GCC 13.2.1 and CONFIG_WERROR=y: [...] drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_topology.c: In function 'kfd_topology_add_device': drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_topology.c:2082:1: error: the frame size of 1408 bytes is larger than 1024 bytes [-Werror=frame-larger-than=] 2082 | } | ^ cc1: all warnings being treated as errors [...] -- Hamza
Re: [PATCH v2] drm/amd/display: fix NULL dereference
On 11/14/23 10:27, José Pekkarinen wrote:
The following patch will fix a minor issue where a debug message is
referencing an struct that has just being checked whether is null or
not. This has been noticed by using coccinelle, in the following output:
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c:540:25-29: ERROR:
aconnector is NULL but dereferenced.
Fixes: 5d72e247e58c9 ("drm/amd/display: switch DC over to the new DRM logging
macros")
You only need the first 12 characters of the hash here. I have fixed it
for you and applied the patch in this case. But, in the future please
test your patches against `./scripts/checkpatch.pl` before submitting
them.
Signed-off-by: José Pekkarinen
---
[v1 -> v2]: Remove the debugging message, requested by Hamza
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
index ed784cf27d39..c7a29bb737e2 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
@@ -536,11 +536,8 @@ bool dm_helpers_dp_read_dpcd(
struct amdgpu_dm_connector *aconnector = link->priv;
- if (!aconnector) {
- drm_dbg_dp(aconnector->base.dev,
- "Failed to find connector for link!\n");
+ if (!aconnector)
return false;
- }
return drm_dp_dpcd_read(&aconnector->dm_dp_aux.aux, address, data,
size) == size;
--
Hamza
Re: [PATCH] drm/amd/display: fix NULL dereference
On 11/14/23 01:36, José Pekkarinen wrote:
The following patch will fix a minor issue where a debug message is
referencing an struct that has just being checked whether is null or
not. This has been noticed by using coccinelle, in the following output:
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c:540:25-29: ERROR:
aconnector is NULL but dereferenced.
Fixes: 5d72e247e58c9 ("drm/amd/display: switch DC over to the new DRM logging
macros")
Signed-off-by: José Pekkarinen
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
index ed784cf27d39..7048dab5e356 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
@@ -537,8 +537,7 @@ bool dm_helpers_dp_read_dpcd(
struct amdgpu_dm_connector *aconnector = link->priv;
if (!aconnector) {
- drm_dbg_dp(aconnector->base.dev,
- "Failed to find connector for link!\n");
+ DRM_ERROR("Failed to find connector for link!");
I would prefer a patch that drops this error message entirely since
it's not particularly useful. As, it's only possible before hw init
(and at that point it's expected).
return false;
}
--
Hamza
[PATCH v2] drm/amd/display: add a debugfs interface for the DMUB trace mask
For features that are implemented primarily in DMUB (e.g. PSR), it is
useful to be able to trace them at a DMUB level from the kernel,
especially when debugging issues. So, introduce a debugfs interface that
is able to read and set the DMUB trace mask dynamically at runtime and
document how to use it.
Cc: Alex Deucher
Cc: Mario Limonciello
Signed-off-by: Hamza Mahfooz
---
v2: only return -ETIMEDOUT for DMUB_STATUS_TIMEOUT
---
Documentation/gpu/amdgpu/display/dc-debug.rst | 41
.../gpu/amdgpu/display/trace-groups-table.csv | 29 ++
.../amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 97 +++
.../gpu/drm/amd/display/dmub/inc/dmub_cmd.h | 40 +++-
4 files changed, 205 insertions(+), 2 deletions(-)
create mode 100644 Documentation/gpu/amdgpu/display/trace-groups-table.csv
diff --git a/Documentation/gpu/amdgpu/display/dc-debug.rst
b/Documentation/gpu/amdgpu/display/dc-debug.rst
index 40c55a618918..817631b1dbf3 100644
--- a/Documentation/gpu/amdgpu/display/dc-debug.rst
+++ b/Documentation/gpu/amdgpu/display/dc-debug.rst
@@ -75,3 +75,44 @@ change in real-time by using something like::
When reporting a bug related to DC, consider attaching this log before and
after you reproduce the bug.
+
+DMUB Firmware Debug
+===
+
+Sometimes, dmesg logs aren't enough. This is especially true if a feature is
+implemented primarily in DMUB firmware. In such cases, all we see in dmesg when
+an issue arises is some generic timeout error. So, to get more relevant
+information, we can trace DMUB commands by enabling the relevant bits in
+`amdgpu_dm_dmub_trace_mask`.
+
+Currently, we support the tracing of the following groups:
+
+Trace Groups
+
+
+.. csv-table::
+ :header-rows: 1
+ :widths: 1, 1
+ :file: ./trace-groups-table.csv
+
+**Note: Not all ASICs support all of the listed trace groups**
+
+So, to enable just PSR tracing you can use the following command::
+
+ # echo 0x8020 > /sys/kernel/debug/dri/0/amdgpu_dm_dmub_trace_mask
+
+Then, you need to enable logging trace events to the buffer, which you can do
+using the following::
+
+ # echo 1 > /sys/kernel/debug/dri/0/amdgpu_dm_dmcub_trace_event_en
+
+Lastly, after you are able to reproduce the issue you are trying to debug,
+you can disable tracing and read the trace log by using the following::
+
+ # echo 0 > /sys/kernel/debug/dri/0/amdgpu_dm_dmcub_trace_event_en
+ # cat /sys/kernel/debug/dri/0/amdgpu_dm_dmub_tracebuffer
+
+So, when reporting bugs related to features such as PSR and ABM, consider
+enabling the relevant bits in the mask before reproducing the issue and
+attach the log that you obtain from the trace buffer in any bug reports that
you
+create.
diff --git a/Documentation/gpu/amdgpu/display/trace-groups-table.csv
b/Documentation/gpu/amdgpu/display/trace-groups-table.csv
new file mode 100644
index ..3f6a50d1d883
--- /dev/null
+++ b/Documentation/gpu/amdgpu/display/trace-groups-table.csv
@@ -0,0 +1,29 @@
+Name, Mask Value
+INFO, 0x1
+IRQ SVC, 0x2
+VBIOS, 0x4
+REGISTER, 0x8
+PHY DBG, 0x10
+PSR, 0x20
+AUX, 0x40
+SMU, 0x80
+MALL, 0x100
+ABM, 0x200
+ALPM, 0x400
+TIMER, 0x800
+HW LOCK MGR, 0x1000
+INBOX1, 0x2000
+PHY SEQ, 0x4000
+PSR STATE, 0x8000
+ZSTATE, 0x1
+TRANSMITTER CTL, 0x2
+PANEL CNTL, 0x4
+FAMS, 0x8
+DPIA, 0x10
+SUBVP, 0x20
+INBOX0, 0x40
+SDP, 0x400
+REPLAY, 0x800
+REPLAY RESIDENCY, 0x2000
+CURSOR INFO, 0x8000
+IPS, 0x1
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
index 45c972f2630d..67dea56cf583 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
@@ -2971,6 +2971,100 @@ static int allow_edp_hotplug_detection_set(void *data,
u64 val)
return 0;
}
+static int dmub_trace_mask_set(void *data, u64 val)
+{
+ struct amdgpu_device *adev = data;
+ struct dmub_srv *srv = adev->dm.dc->ctx->dmub_srv->dmub;
+ enum dmub_gpint_command cmd;
+ enum dmub_status status;
+ u64 mask = 0x;
+ u8 shift = 0;
+ u32 res;
+ int i;
+
+ if (!srv->fw_version)
+ return -EINVAL;
+
+ for (i = 0; i < 4; i++) {
+ res = (val & mask) >> shift;
+
+ switch (i) {
+ case 0:
+ cmd = DMUB_GPINT__SET_TRACE_BUFFER_MASK_WORD0;
+ break;
+ case 1:
+ cmd = DMUB_GPINT__SET_TRACE_BUFFER_MASK_WORD1;
+ break;
+ case 2:
+ cmd = DMUB_GPINT__SET_TRACE_BUFFER_MASK_WORD2;
+ break;
+ case 3:
+ cmd = DMUB_GPINT__SET_TRACE_BUFFER_MASK_WORD3;
+ break;
+ }
+
+ status = dmub_srv_send_gpint_command(srv, c
[PATCH] drm/amd/display: add a debugfs interface for the DMUB trace mask
For features that are implemented primarily in DMUB (e.g. PSR), it is
useful to be able to trace them at a DMUB level from the kernel,
especially when debugging issues. So, introduce a debugfs interface that
is able to read and set the DMUB trace mask dynamically at runtime and
document how to use it.
Cc: Alex Deucher
Cc: Mario Limonciello
Signed-off-by: Hamza Mahfooz
---
Documentation/gpu/amdgpu/display/dc-debug.rst | 41 +
.../gpu/amdgpu/display/trace-groups-table.csv | 29 ++
.../amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 91 +++
.../gpu/drm/amd/display/dmub/inc/dmub_cmd.h | 40 +++-
4 files changed, 199 insertions(+), 2 deletions(-)
create mode 100644 Documentation/gpu/amdgpu/display/trace-groups-table.csv
diff --git a/Documentation/gpu/amdgpu/display/dc-debug.rst
b/Documentation/gpu/amdgpu/display/dc-debug.rst
index 40c55a618918..817631b1dbf3 100644
--- a/Documentation/gpu/amdgpu/display/dc-debug.rst
+++ b/Documentation/gpu/amdgpu/display/dc-debug.rst
@@ -75,3 +75,44 @@ change in real-time by using something like::
When reporting a bug related to DC, consider attaching this log before and
after you reproduce the bug.
+
+DMUB Firmware Debug
+===
+
+Sometimes, dmesg logs aren't enough. This is especially true if a feature is
+implemented primarily in DMUB firmware. In such cases, all we see in dmesg when
+an issue arises is some generic timeout error. So, to get more relevant
+information, we can trace DMUB commands by enabling the relevant bits in
+`amdgpu_dm_dmub_trace_mask`.
+
+Currently, we support the tracing of the following groups:
+
+Trace Groups
+
+
+.. csv-table::
+ :header-rows: 1
+ :widths: 1, 1
+ :file: ./trace-groups-table.csv
+
+**Note: Not all ASICs support all of the listed trace groups**
+
+So, to enable just PSR tracing you can use the following command::
+
+ # echo 0x8020 > /sys/kernel/debug/dri/0/amdgpu_dm_dmub_trace_mask
+
+Then, you need to enable logging trace events to the buffer, which you can do
+using the following::
+
+ # echo 1 > /sys/kernel/debug/dri/0/amdgpu_dm_dmcub_trace_event_en
+
+Lastly, after you are able to reproduce the issue you are trying to debug,
+you can disable tracing and read the trace log by using the following::
+
+ # echo 0 > /sys/kernel/debug/dri/0/amdgpu_dm_dmcub_trace_event_en
+ # cat /sys/kernel/debug/dri/0/amdgpu_dm_dmub_tracebuffer
+
+So, when reporting bugs related to features such as PSR and ABM, consider
+enabling the relevant bits in the mask before reproducing the issue and
+attach the log that you obtain from the trace buffer in any bug reports that
you
+create.
diff --git a/Documentation/gpu/amdgpu/display/trace-groups-table.csv
b/Documentation/gpu/amdgpu/display/trace-groups-table.csv
new file mode 100644
index ..3f6a50d1d883
--- /dev/null
+++ b/Documentation/gpu/amdgpu/display/trace-groups-table.csv
@@ -0,0 +1,29 @@
+Name, Mask Value
+INFO, 0x1
+IRQ SVC, 0x2
+VBIOS, 0x4
+REGISTER, 0x8
+PHY DBG, 0x10
+PSR, 0x20
+AUX, 0x40
+SMU, 0x80
+MALL, 0x100
+ABM, 0x200
+ALPM, 0x400
+TIMER, 0x800
+HW LOCK MGR, 0x1000
+INBOX1, 0x2000
+PHY SEQ, 0x4000
+PSR STATE, 0x8000
+ZSTATE, 0x1
+TRANSMITTER CTL, 0x2
+PANEL CNTL, 0x4
+FAMS, 0x8
+DPIA, 0x10
+SUBVP, 0x20
+INBOX0, 0x40
+SDP, 0x400
+REPLAY, 0x800
+REPLAY RESIDENCY, 0x2000
+CURSOR INFO, 0x8000
+IPS, 0x1
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
index 13a177d34376..06a73f283e9d 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
@@ -2971,6 +2971,94 @@ static int allow_edp_hotplug_detection_set(void *data,
u64 val)
return 0;
}
+static int dmub_trace_mask_set(void *data, u64 val)
+{
+ struct amdgpu_device *adev = data;
+ struct dmub_srv *srv = adev->dm.dc->ctx->dmub_srv->dmub;
+ enum dmub_gpint_command cmd;
+ enum dmub_status status;
+ u64 mask = 0x;
+ u8 shift = 0;
+ u32 res;
+ int i;
+
+ if (!srv->fw_version)
+ return -EINVAL;
+
+ for (i = 0; i < 4; i++) {
+ res = (val & mask) >> shift;
+
+ switch (i) {
+ case 0:
+ cmd = DMUB_GPINT__SET_TRACE_BUFFER_MASK_WORD0;
+ break;
+ case 1:
+ cmd = DMUB_GPINT__SET_TRACE_BUFFER_MASK_WORD1;
+ break;
+ case 2:
+ cmd = DMUB_GPINT__SET_TRACE_BUFFER_MASK_WORD2;
+ break;
+ case 3:
+ cmd = DMUB_GPINT__SET_TRACE_BUFFER_MASK_WORD3;
+ break;
+ }
+
+ status = dmub_srv_send_gpint_command(srv, cmd, res, 30);
+
+ if (status != DMUB
Re: [PATCH] drm/edid: add a quirk for two 240Hz Samsung monitors
On 11/1/23 17:36, Alex Deucher wrote:
On Wed, Nov 1, 2023 at 5:01 PM Hamza Mahfooz wrote:
Without this fix the 5120x1440@240 timing of these monitors
leads to screen flickering.
Cc: sta...@vger.kernel.org # 6.1+
Link: https://gitlab.freedesktop.org/drm/amd/-/issues/1442
Co-developed-by: Harry Wentland
Signed-off-by: Harry Wentland
Signed-off-by: Hamza Mahfooz
---
drivers/gpu/drm/drm_edid.c | 47 +++---
1 file changed, 44 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index bca2af4fe1fc..3fdb8907f66b 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -89,6 +89,8 @@ static int oui(u8 first, u8 second, u8 third)
#define EDID_QUIRK_NON_DESKTOP (1 << 12)
/* Cap the DSC target bitrate to 15bpp */
#define EDID_QUIRK_CAP_DSC_15BPP (1 << 13)
+/* Fix up a particular 5120x1440@240Hz timing */
+#define EDID_QUIRK_FIXUP_5120_1440_240 (1 << 14)
What is wrong with the original timing that needs to be fixed?
Apparently, all of timing values for the 5120x1440@240 mode of these
monitors aren't set correctly (they are all lower than they should be)
in their EDIDs. For what it's worth, the windows driver has had a quirk
similar the one proposed in this patch for ~2 years.
Alex
#define MICROSOFT_IEEE_OUI 0xca125c
@@ -170,6 +172,12 @@ static const struct edid_quirk {
EDID_QUIRK('S', 'A', 'M', 596, EDID_QUIRK_PREFER_LARGE_60),
EDID_QUIRK('S', 'A', 'M', 638, EDID_QUIRK_PREFER_LARGE_60),
+ /* Samsung C49G95T */
+ EDID_QUIRK('S', 'A', 'M', 0x7053, EDID_QUIRK_FIXUP_5120_1440_240),
+
+ /* Samsung S49AG95 */
+ EDID_QUIRK('S', 'A', 'M', 0x71ac, EDID_QUIRK_FIXUP_5120_1440_240),
+
/* Sony PVM-2541A does up to 12 bpc, but only reports max 8 bpc */
EDID_QUIRK('S', 'N', 'Y', 0x2541, EDID_QUIRK_FORCE_12BPC),
@@ -6586,7 +6594,37 @@ static void update_display_info(struct drm_connector
*connector,
drm_edid_to_eld(connector, drm_edid);
}
-static struct drm_display_mode *drm_mode_displayid_detailed(struct drm_device
*dev,
+static void drm_mode_displayid_detailed_edid_quirks(struct drm_connector
*connector,
+ struct drm_display_mode
*mode)
+{
+ unsigned int hsync_width;
+ unsigned int vsync_width;
+
+ if (connector->display_info.quirks & EDID_QUIRK_FIXUP_5120_1440_240) {
+ if (mode->hdisplay == 5120 && mode->vdisplay == 1440 &&
+ mode->clock == 1939490) {
+ hsync_width = mode->hsync_end - mode->hsync_start;
+ vsync_width = mode->vsync_end - mode->vsync_start;
+
+ mode->clock = 2018490;
+ mode->hdisplay = 5120;
+ mode->hsync_start = 5120 + 8;
+ mode->hsync_end = 5120 + 8 + hsync_width;
+ mode->htotal = 5200;
+
+ mode->vdisplay = 1440;
+ mode->vsync_start = 1440 + 165;
+ mode->vsync_end = 1440 + 165 + vsync_width;
+ mode->vtotal = 1619;
+
+ drm_dbg_kms(connector->dev,
+ "[CONNECTOR:%d:%s] Samsung 240Hz mode quirk
applied\n",
+ connector->base.id, connector->name);
+ }
+ }
+}
+
+static struct drm_display_mode *drm_mode_displayid_detailed(struct
drm_connector *connector,
struct
displayid_detailed_timings_1 *timings,
bool type_7)
{
@@ -6605,7 +6643,7 @@ static struct drm_display_mode
*drm_mode_displayid_detailed(struct drm_device *d
bool hsync_positive = (timings->hsync[1] >> 7) & 0x1;
bool vsync_positive = (timings->vsync[1] >> 7) & 0x1;
- mode = drm_mode_create(dev);
+ mode = drm_mode_create(connector->dev);
if (!mode)
return NULL;
@@ -6628,6 +,9 @@ static struct drm_display_mode
*drm_mode_displayid_detailed(struct drm_device *d
if (timings->flags & 0x80)
mode->type |= DRM_MODE_TYPE_PREFERRED;
+
+ drm_mode_displayid_detailed_edid_quirks(connector, mode);
+
drm_mode_set_name(mode);
return mode;
@@ -6650,7 +6691,7 @@ static int add_displayid_detailed_1_modes(struct
drm_connector *connector,
for (i = 0; i < num_timings; i++) {
struct displayid_detailed_timings_1 *timings =
&det->timings[i];
- newmode = drm_mode_displayid_detailed(connector->dev, timings,
type_7);
+ newmode = drm_mode_displayid_detailed(connector, timings,
type_7);
if (!newmode)
continue;
--
2.42.0
--
Hamza
Re: [PATCH] drm/amd/display: Increase frame warning limit for clang in dml2
On 11/2/23 13:12, Nathan Chancellor wrote:
On Thu, Nov 02, 2023 at 12:59:00PM -0400, Hamza Mahfooz wrote:
On 11/2/23 12:24, Nathan Chancellor wrote:
When building ARCH=x86_64 allmodconfig with clang, which have sanitizers
enabled, there is a warning about a large stack frame.
drivers/gpu/drm/amd/amdgpu/../display/dc/dml2/display_mode_core.c:6265:13:
error: stack frame size (2520) exceeds limit (2048) in 'dml_prefetch_check'
[-Werror,-Wframe-larger-than]
6265 | static void dml_prefetch_check(struct display_mode_lib_st *mode_lib)
| ^
1 error generated.
Notably, GCC 13.2.0 does not do too much of a better job, as it is right
at the current limit of 2048:
drivers/gpu/drm/amd/amdgpu/../display/dc/dml2/display_mode_core.c: In
function 'dml_prefetch_check':
drivers/gpu/drm/amd/amdgpu/../display/dc/dml2/display_mode_core.c:6705:1:
error: the frame size of 2048 bytes is larger than 1800 bytes
[-Werror=frame-larger-than=]
6705 | }
| ^
In the past, these warnings have been avoided by reducing the number of
parameters to various functions so that not as many arguments need to be
passed on the stack. However, these patches take a good amount of effort
to write despite being mechanical due to code structure and complexity
and they are never carried forward to new generations of the code so
that effort has to be expended every new hardware generation, which
becomes harder to justify as time goes on.
There is some effort to improve clang's code generation but that may
take some time between code review, shifting priorities, and release
cycles. To avoid having a noticeable or lengthy breakage in
all{mod,yes}config, which are easy testing targets that have -Werror
enabled, increase the limit for clang by 50% so that cases of extremely
poor code generation can still be caught while not breaking the majority
of builds. When clang's code generation improves, the limit increase can
be restricted to older clang versions.
Signed-off-by: Nathan Chancellor
---
If there is another DRM pull before 6.7-rc1, it would be much
appreciated if this could make that so that other trees are not
potentially broken by this. If not, no worries, as it was my fault for
not sending this sooner.
---
drivers/gpu/drm/amd/display/dc/dml2/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dml2/Makefile
b/drivers/gpu/drm/amd/display/dc/dml2/Makefile
index 70ae5eba624e..dff8237c0999 100644
--- a/drivers/gpu/drm/amd/display/dc/dml2/Makefile
+++ b/drivers/gpu/drm/amd/display/dc/dml2/Makefile
@@ -60,7 +60,7 @@ endif
endif
ifneq ($(CONFIG_FRAME_WARN),0)
-frame_warn_flag := -Wframe-larger-than=2048
+frame_warn_flag := -Wframe-larger-than=$(if $(CONFIG_CC_IS_CLANG),3072,2048)
I would prefer checking for `CONFIG_KASAN || CONFIG_KCSAN` instead
since the stack usage shouldn't change much if both of those are disabled.
So something like this? Or were you talking about replacing the clang
check entirely with the KASAN/KCSAN check?
I think for the time being replacing the clang check with a KASAN/KCSAN
check would make more sense. Considering that, the allmodconfig for older
versions of gcc is also broken (see [1]).
1.
https://lore.kernel.org/amd-gfx/CADVatmO9NCs=ryng72hnzmdpqg862gpgnnfhq4uwtpekjok...@mail.gmail.com/
diff --git a/drivers/gpu/drm/amd/display/dc/dml2/Makefile
b/drivers/gpu/drm/amd/display/dc/dml2/Makefile
index 70ae5eba624e..0fc1b13295eb 100644
--- a/drivers/gpu/drm/amd/display/dc/dml2/Makefile
+++ b/drivers/gpu/drm/amd/display/dc/dml2/Makefile
@@ -60,8 +60,12 @@ endif
endif
ifneq ($(CONFIG_FRAME_WARN),0)
+ifeq ($(CONFIG_CC_IS_CLANG)$(filter y,$(CONFIG_KASAN)$(CONFIG_KCSAN)),yy)
+frame_warn_flag := -Wframe-larger-than=3072
+else
frame_warn_flag := -Wframe-larger-than=2048
endif
+endif
CFLAGS_$(AMDDALPATH)/dc/dml2/display_mode_core.o := $(dml2_ccflags) $(frame_warn_flag)
CFLAGS_$(AMDDALPATH)/dc/dml2/display_mode_util.o := $(dml2_ccflags)
endif
CFLAGS_$(AMDDALPATH)/dc/dml2/display_mode_core.o := $(dml2_ccflags)
$(frame_warn_flag)
---
base-commit: 21e80f3841c01aeaf32d7aee7bbc87b3db1aa0c6
change-id:
20231102-amdgpu-dml2-increase-frame-size-warning-for-clang-c93bd2d6a871
Best regards,
--
Hamza
--
Hamza
Re: [PATCH] drm/amd/display: Increase frame warning limit for clang in dml2
On 11/2/23 12:24, Nathan Chancellor wrote:
When building ARCH=x86_64 allmodconfig with clang, which have sanitizers
enabled, there is a warning about a large stack frame.
drivers/gpu/drm/amd/amdgpu/../display/dc/dml2/display_mode_core.c:6265:13:
error: stack frame size (2520) exceeds limit (2048) in 'dml_prefetch_check'
[-Werror,-Wframe-larger-than]
6265 | static void dml_prefetch_check(struct display_mode_lib_st *mode_lib)
| ^
1 error generated.
Notably, GCC 13.2.0 does not do too much of a better job, as it is right
at the current limit of 2048:
drivers/gpu/drm/amd/amdgpu/../display/dc/dml2/display_mode_core.c: In
function 'dml_prefetch_check':
drivers/gpu/drm/amd/amdgpu/../display/dc/dml2/display_mode_core.c:6705:1:
error: the frame size of 2048 bytes is larger than 1800 bytes
[-Werror=frame-larger-than=]
6705 | }
| ^
In the past, these warnings have been avoided by reducing the number of
parameters to various functions so that not as many arguments need to be
passed on the stack. However, these patches take a good amount of effort
to write despite being mechanical due to code structure and complexity
and they are never carried forward to new generations of the code so
that effort has to be expended every new hardware generation, which
becomes harder to justify as time goes on.
There is some effort to improve clang's code generation but that may
take some time between code review, shifting priorities, and release
cycles. To avoid having a noticeable or lengthy breakage in
all{mod,yes}config, which are easy testing targets that have -Werror
enabled, increase the limit for clang by 50% so that cases of extremely
poor code generation can still be caught while not breaking the majority
of builds. When clang's code generation improves, the limit increase can
be restricted to older clang versions.
Signed-off-by: Nathan Chancellor
---
If there is another DRM pull before 6.7-rc1, it would be much
appreciated if this could make that so that other trees are not
potentially broken by this. If not, no worries, as it was my fault for
not sending this sooner.
---
drivers/gpu/drm/amd/display/dc/dml2/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dml2/Makefile
b/drivers/gpu/drm/amd/display/dc/dml2/Makefile
index 70ae5eba624e..dff8237c0999 100644
--- a/drivers/gpu/drm/amd/display/dc/dml2/Makefile
+++ b/drivers/gpu/drm/amd/display/dc/dml2/Makefile
@@ -60,7 +60,7 @@ endif
endif
ifneq ($(CONFIG_FRAME_WARN),0)
-frame_warn_flag := -Wframe-larger-than=2048
+frame_warn_flag := -Wframe-larger-than=$(if $(CONFIG_CC_IS_CLANG),3072,2048)
I would prefer checking for `CONFIG_KASAN || CONFIG_KCSAN` instead
since the stack usage shouldn't change much if both of those are disabled.
endif
CFLAGS_$(AMDDALPATH)/dc/dml2/display_mode_core.o := $(dml2_ccflags) $(frame_warn_flag)
---
base-commit: 21e80f3841c01aeaf32d7aee7bbc87b3db1aa0c6
change-id:
20231102-amdgpu-dml2-increase-frame-size-warning-for-clang-c93bd2d6a871
Best regards,
--
Hamza
[PATCH] drm/edid: add a quirk for two 240Hz Samsung monitors
Without this fix the 5120x1440@240 timing of these monitors
leads to screen flickering.
Cc: sta...@vger.kernel.org # 6.1+
Link: https://gitlab.freedesktop.org/drm/amd/-/issues/1442
Co-developed-by: Harry Wentland
Signed-off-by: Harry Wentland
Signed-off-by: Hamza Mahfooz
---
drivers/gpu/drm/drm_edid.c | 47 +++---
1 file changed, 44 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index bca2af4fe1fc..3fdb8907f66b 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -89,6 +89,8 @@ static int oui(u8 first, u8 second, u8 third)
#define EDID_QUIRK_NON_DESKTOP (1 << 12)
/* Cap the DSC target bitrate to 15bpp */
#define EDID_QUIRK_CAP_DSC_15BPP (1 << 13)
+/* Fix up a particular 5120x1440@240Hz timing */
+#define EDID_QUIRK_FIXUP_5120_1440_240 (1 << 14)
#define MICROSOFT_IEEE_OUI 0xca125c
@@ -170,6 +172,12 @@ static const struct edid_quirk {
EDID_QUIRK('S', 'A', 'M', 596, EDID_QUIRK_PREFER_LARGE_60),
EDID_QUIRK('S', 'A', 'M', 638, EDID_QUIRK_PREFER_LARGE_60),
+ /* Samsung C49G95T */
+ EDID_QUIRK('S', 'A', 'M', 0x7053, EDID_QUIRK_FIXUP_5120_1440_240),
+
+ /* Samsung S49AG95 */
+ EDID_QUIRK('S', 'A', 'M', 0x71ac, EDID_QUIRK_FIXUP_5120_1440_240),
+
/* Sony PVM-2541A does up to 12 bpc, but only reports max 8 bpc */
EDID_QUIRK('S', 'N', 'Y', 0x2541, EDID_QUIRK_FORCE_12BPC),
@@ -6586,7 +6594,37 @@ static void update_display_info(struct drm_connector
*connector,
drm_edid_to_eld(connector, drm_edid);
}
-static struct drm_display_mode *drm_mode_displayid_detailed(struct drm_device
*dev,
+static void drm_mode_displayid_detailed_edid_quirks(struct drm_connector
*connector,
+ struct drm_display_mode
*mode)
+{
+ unsigned int hsync_width;
+ unsigned int vsync_width;
+
+ if (connector->display_info.quirks & EDID_QUIRK_FIXUP_5120_1440_240) {
+ if (mode->hdisplay == 5120 && mode->vdisplay == 1440 &&
+ mode->clock == 1939490) {
+ hsync_width = mode->hsync_end - mode->hsync_start;
+ vsync_width = mode->vsync_end - mode->vsync_start;
+
+ mode->clock = 2018490;
+ mode->hdisplay = 5120;
+ mode->hsync_start = 5120 + 8;
+ mode->hsync_end = 5120 + 8 + hsync_width;
+ mode->htotal = 5200;
+
+ mode->vdisplay = 1440;
+ mode->vsync_start = 1440 + 165;
+ mode->vsync_end = 1440 + 165 + vsync_width;
+ mode->vtotal = 1619;
+
+ drm_dbg_kms(connector->dev,
+ "[CONNECTOR:%d:%s] Samsung 240Hz mode quirk
applied\n",
+ connector->base.id, connector->name);
+ }
+ }
+}
+
+static struct drm_display_mode *drm_mode_displayid_detailed(struct
drm_connector *connector,
struct
displayid_detailed_timings_1 *timings,
bool type_7)
{
@@ -6605,7 +6643,7 @@ static struct drm_display_mode
*drm_mode_displayid_detailed(struct drm_device *d
bool hsync_positive = (timings->hsync[1] >> 7) & 0x1;
bool vsync_positive = (timings->vsync[1] >> 7) & 0x1;
- mode = drm_mode_create(dev);
+ mode = drm_mode_create(connector->dev);
if (!mode)
return NULL;
@@ -6628,6 +,9 @@ static struct drm_display_mode
*drm_mode_displayid_detailed(struct drm_device *d
if (timings->flags & 0x80)
mode->type |= DRM_MODE_TYPE_PREFERRED;
+
+ drm_mode_displayid_detailed_edid_quirks(connector, mode);
+
drm_mode_set_name(mode);
return mode;
@@ -6650,7 +6691,7 @@ static int add_displayid_detailed_1_modes(struct
drm_connector *connector,
for (i = 0; i < num_timings; i++) {
struct displayid_detailed_timings_1 *timings = &det->timings[i];
- newmode = drm_mode_displayid_detailed(connector->dev, timings,
type_7);
+ newmode = drm_mode_displayid_detailed(connector, timings,
type_7);
if (!newmode)
continue;
--
2.42.0
Re: [PATCH] drm/amdgpu: Fixes uninitialized variable usage in amdgpu_dm_setup_replay
On 10/27/23 11:55, Lakha, Bhawanpreet wrote:
[AMD Official Use Only - General]
There was a consensus to use memset instead of {0}. I remember making
changes related to that previously.
Hm, seems like it's used rather consistently in the DM and in DC
though.
Bhawan
*From:* Mahfooz, Hamza
*Sent:* October 27, 2023 11:53 AM
*To:* Yuran Pereira ; airl...@gmail.com
*Cc:* Li, Sun peng (Leo) ; Lakha, Bhawanpreet
; Pan, Xinhui ; Siqueira,
Rodrigo ; linux-ker...@vger.kernel.org
; amd-...@lists.freedesktop.org
; dri-devel@lists.freedesktop.org
; Deucher, Alexander
; Koenig, Christian
;
linux-kernel-ment...@lists.linuxfoundation.org
*Subject:* Re: [PATCH] drm/amdgpu: Fixes uninitialized variable usage in
amdgpu_dm_setup_replay
On 10/26/23 17:25, Yuran Pereira wrote:
Since `pr_config` is not initialized after its declaration, the
following operations with `replay_enable_option` may be performed
when `replay_enable_option` is holding junk values which could
possibly lead to undefined behaviour
```
...
pr_config.replay_enable_option |= pr_enable_option_static_screen;
...
if (!pr_config.replay_timing_sync_supported)
pr_config.replay_enable_option &= ~pr_enable_option_general_ui;
...
```
This patch initializes `pr_config` after its declaration to ensure that
it doesn't contain junk data, and prevent any undefined behaviour
Addresses-Coverity-ID: 1544428 ("Uninitialized scalar variable")
Fixes: dede1fea4460 ("drm/amd/display: Add Freesync Panel DM code")
Signed-off-by: Yuran Pereira
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_replay.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_replay.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_replay.c
index 32d3086c4cb7..40526507f50b 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_replay.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_replay.c
@@ -23,6 +23,7 @@
*
*/
+#include
#include "amdgpu_dm_replay.h"
#include "dc.h"
#include "dm_helpers.h"
@@ -74,6 +75,8 @@ bool amdgpu_dm_setup_replay(struct dc_link *link, struct
amdgpu_dm_connector *ac
struct replay_config pr_config;
I would prefer setting pr_config = {0};
union replay_debug_flags *debug_flags = NULL;
+ memset(&pr_config, 0, sizeof(pr_config));
+
// For eDP, if Replay is supported, return true to skip checks
if (link->replay_settings.config.replay_supported)
return true;
--
Hamza
--
Hamza
Re: [PATCH] drm/amdgpu: Fixes uninitialized variable usage in amdgpu_dm_setup_replay
Also, please write the tagline in present tense.
On 10/27/23 11:53, Hamza Mahfooz wrote:
On 10/26/23 17:25, Yuran Pereira wrote:
Since `pr_config` is not initialized after its declaration, the
following operations with `replay_enable_option` may be performed
when `replay_enable_option` is holding junk values which could
possibly lead to undefined behaviour
```
...
pr_config.replay_enable_option |= pr_enable_option_static_screen;
...
if (!pr_config.replay_timing_sync_supported)
pr_config.replay_enable_option &= ~pr_enable_option_general_ui;
...
```
This patch initializes `pr_config` after its declaration to ensure that
it doesn't contain junk data, and prevent any undefined behaviour
Addresses-Coverity-ID: 1544428 ("Uninitialized scalar variable")
Fixes: dede1fea4460 ("drm/amd/display: Add Freesync Panel DM code")
Signed-off-by: Yuran Pereira
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_replay.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_replay.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_replay.c
index 32d3086c4cb7..40526507f50b 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_replay.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_replay.c
@@ -23,6 +23,7 @@
*
*/
+#include
#include "amdgpu_dm_replay.h"
#include "dc.h"
#include "dm_helpers.h"
@@ -74,6 +75,8 @@ bool amdgpu_dm_setup_replay(struct dc_link *link,
struct amdgpu_dm_connector *ac
struct replay_config pr_config;
I would prefer setting pr_config = {0};
union replay_debug_flags *debug_flags = NULL;
+ memset(&pr_config, 0, sizeof(pr_config));
+
// For eDP, if Replay is supported, return true to skip checks
if (link->replay_settings.config.replay_supported)
return true;
--
Hamza
Re: [PATCH] drm/amdgpu: Fixes uninitialized variable usage in amdgpu_dm_setup_replay
On 10/26/23 17:25, Yuran Pereira wrote:
Since `pr_config` is not initialized after its declaration, the
following operations with `replay_enable_option` may be performed
when `replay_enable_option` is holding junk values which could
possibly lead to undefined behaviour
```
...
pr_config.replay_enable_option |= pr_enable_option_static_screen;
...
if (!pr_config.replay_timing_sync_supported)
pr_config.replay_enable_option &= ~pr_enable_option_general_ui;
...
```
This patch initializes `pr_config` after its declaration to ensure that
it doesn't contain junk data, and prevent any undefined behaviour
Addresses-Coverity-ID: 1544428 ("Uninitialized scalar variable")
Fixes: dede1fea4460 ("drm/amd/display: Add Freesync Panel DM code")
Signed-off-by: Yuran Pereira
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_replay.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_replay.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_replay.c
index 32d3086c4cb7..40526507f50b 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_replay.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_replay.c
@@ -23,6 +23,7 @@
*
*/
+#include
#include "amdgpu_dm_replay.h"
#include "dc.h"
#include "dm_helpers.h"
@@ -74,6 +75,8 @@ bool amdgpu_dm_setup_replay(struct dc_link *link, struct
amdgpu_dm_connector *ac
struct replay_config pr_config;
I would prefer setting pr_config = {0};
union replay_debug_flags *debug_flags = NULL;
+ memset(&pr_config, 0, sizeof(pr_config));
+
// For eDP, if Replay is supported, return true to skip checks
if (link->replay_settings.config.replay_supported)
return true;
--
Hamza
Re: [PATCH v2] drm/atomic-helper: Fix spelling mistake "preceeding" -> "preceding"
On 10/26/23 22:44, chentao wrote: From: Kunwu Chan There is a typo in the kernel documentation for function drm_atomic_helper_wait_for_dependencies. Fix it. Signed-off-by: Kunwu Chan Applied, thanks! --- drivers/gpu/drm/drm_atomic_helper.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c index 2444fc33dd7c..c3f677130def 100644 --- a/drivers/gpu/drm/drm_atomic_helper.c +++ b/drivers/gpu/drm/drm_atomic_helper.c @@ -2382,10 +2382,10 @@ int drm_atomic_helper_setup_commit(struct drm_atomic_state *state, EXPORT_SYMBOL(drm_atomic_helper_setup_commit); /** - * drm_atomic_helper_wait_for_dependencies - wait for required preceeding commits + * drm_atomic_helper_wait_for_dependencies - wait for required preceding commits * @old_state: atomic state object with old state structures * - * This function waits for all preceeding commits that touch the same CRTC as + * This function waits for all preceding commits that touch the same CRTC as * @old_state to both be committed to the hardware (as signalled by * drm_atomic_helper_commit_hw_done()) and executed by the hardware (as signalled * by calling drm_crtc_send_vblank_event() on the &drm_crtc_state.event). -- Hamza
Re: [PATCH] drm/atomic: Spelling fix in comments
Hi Kunwu, Can you make the tagline something along the lines of `drm/atomic helper: fix spelling mistake "preceeding" -> "preceding"`, in general to determine an appropriate prefix, you can see what previous commits used when making changes to files in your particular patch, e.g. using the following: $ git log drivers/gpu/drm/drm_atomic_helper.c On 10/25/23 04:26, Kunwu Chan wrote: fix a typo in a comments. For patch descriptions you should try to more descriptive. So, something like "There is a spelling mistake in drm_atomic_helper_wait_for_dependencies()'s kernel doc. Fix it." would be better. Signed-off-by: Kunwu Chan --- drivers/gpu/drm/drm_atomic_helper.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c index 2444fc33dd7c..c3f677130def 100644 --- a/drivers/gpu/drm/drm_atomic_helper.c +++ b/drivers/gpu/drm/drm_atomic_helper.c @@ -2382,10 +2382,10 @@ int drm_atomic_helper_setup_commit(struct drm_atomic_state *state, EXPORT_SYMBOL(drm_atomic_helper_setup_commit); /** - * drm_atomic_helper_wait_for_dependencies - wait for required preceeding commits + * drm_atomic_helper_wait_for_dependencies - wait for required preceding commits * @old_state: atomic state object with old state structures * - * This function waits for all preceeding commits that touch the same CRTC as + * This function waits for all preceding commits that touch the same CRTC as * @old_state to both be committed to the hardware (as signalled by * drm_atomic_helper_commit_hw_done()) and executed by the hardware (as signalled * by calling drm_crtc_send_vblank_event() on the &drm_crtc_state.event). -- Hamza
Re: [PATCH v3] drm/client: Convert drm_client_buffer_addfb() to drm_mode_addfb2()
On 10/15/23 10:27, Geert Uytterhoeven wrote:
Currently drm_client_buffer_addfb() uses the legacy drm_mode_addfb(),
which uses bpp and depth to guess the wanted buffer format.
However, drm_client_buffer_addfb() already knows the exact buffer
format, so there is no need to convert back and forth between buffer
format and bpp/depth, and the function can just call drm_mode_addfb2()
directly instead.
Signed-off-by: Geert Uytterhoeven
Reviewed-by: Javier Martinez Canillas
Tested-by: Javier Martinez Canillas
Applied and pushed to drm-misc-next, thanks!
---
v3:
- Extract from series "[PATCH v2 0/8] drm: fb-helper/ssd130x: Add
support for DRM_FORMAT_R1"
(https://lore.kernel.org/all/cover.1692888745.git.ge...@linux-m68k.org),
as this patch has merits on its own,
v2:
- Add Reviewed-by, Tested-by,
- s/drm_mode_create_dumb/drm_client_buffer_addfb/ in one-line summary.
---
drivers/gpu/drm/drm_client.c | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/drm_client.c b/drivers/gpu/drm/drm_client.c
index d4296440f297fc5a..a780832a0963fe38 100644
--- a/drivers/gpu/drm/drm_client.c
+++ b/drivers/gpu/drm/drm_client.c
@@ -395,19 +395,16 @@ static int drm_client_buffer_addfb(struct
drm_client_buffer *buffer,
u32 handle)
{
struct drm_client_dev *client = buffer->client;
- struct drm_mode_fb_cmd fb_req = { };
- const struct drm_format_info *info;
+ struct drm_mode_fb_cmd2 fb_req = { };
int ret;
- info = drm_format_info(format);
- fb_req.bpp = drm_format_info_bpp(info, 0);
- fb_req.depth = info->depth;
fb_req.width = width;
fb_req.height = height;
- fb_req.handle = handle;
- fb_req.pitch = buffer->pitch;
+ fb_req.pixel_format = format;
+ fb_req.handles[0] = handle;
+ fb_req.pitches[0] = buffer->pitch;
- ret = drm_mode_addfb(client->dev, &fb_req, client->file);
+ ret = drm_mode_addfb2(client->dev, &fb_req, client->file);
if (ret)
return ret;
--
Hamza
Re: [PATCH] drm/amd/display: Respect CONFIG_FRAME_WARN=0 in DML2
On 10/18/23 14:45, Nathan Chancellor wrote:
display_mode_code.c is unconditionally built with
-Wframe-larger-than=2048, which causes warnings even when
CONFIG_FRAME_WARN has been set to 0, which should show no warnings.
Use the existing $(frame_warn_flag) variable, which handles this
situation. This is basically commit 25f178bbd078 ("drm/amd/display:
Respect CONFIG_FRAME_WARN=0 in dml Makefile") but for DML2.
Fixes: 7966f319c66d ("drm/amd/display: Introduce DML2")
Signed-off-by: Nathan Chancellor
Applied, thanks!
---
drivers/gpu/drm/amd/display/dc/dml2/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dml2/Makefile
b/drivers/gpu/drm/amd/display/dc/dml2/Makefile
index f35ed8de260d..66431525f2a0 100644
--- a/drivers/gpu/drm/amd/display/dc/dml2/Makefile
+++ b/drivers/gpu/drm/amd/display/dc/dml2/Makefile
@@ -61,7 +61,7 @@ ifneq ($(CONFIG_FRAME_WARN),0)
frame_warn_flag := -Wframe-larger-than=2048
endif
-CFLAGS_$(AMDDALPATH)/dc/dml2/display_mode_core.o := $(dml2_ccflags) -Wframe-larger-than=2048
+CFLAGS_$(AMDDALPATH)/dc/dml2/display_mode_core.o := $(dml2_ccflags)
$(frame_warn_flag)
CFLAGS_$(AMDDALPATH)/dc/dml2/display_mode_util.o := $(dml2_ccflags)
CFLAGS_$(AMDDALPATH)/dc/dml2/dml2_wrapper.o := $(dml2_ccflags)
CFLAGS_$(AMDDALPATH)/dc/dml2/dml2_utils.o := $(dml2_ccflags)
---
base-commit: cd90511557fdfb394bb4ac4c3b539b007383914c
change-id: 20231018-amdgpu-dml2-respect-frame_warn-536e19b69ce0
Best regards,
--
Hamza
Re: [PATCH] drm/edid: add 8 bpc quirk to the BenQ GW2765
On 10/13/23 06:30, Ville Syrjälä wrote:
On Thu, Oct 12, 2023 at 02:49:27PM -0400, Hamza Mahfooz wrote:
The BenQ GW2765 reports that it supports higher (> 8) bpc modes, but
when trying to set them we end up with a black screen. So, limit it to 8
bpc modes.
Bad cable/etc was ruled out as the cause?
Yup, the issue was also reproduced by two different people with same
aforementioned monitor.
Cc: sta...@vger.kernel.org # 6.5+
Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2610
Signed-off-by: Hamza Mahfooz
---
drivers/gpu/drm/drm_edid.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 0454da505687..bca2af4fe1fc 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -123,6 +123,9 @@ static const struct edid_quirk {
/* AEO model 0 reports 8 bpc, but is a 6 bpc panel */
EDID_QUIRK('A', 'E', 'O', 0, EDID_QUIRK_FORCE_6BPC),
+ /* BenQ GW2765 */
+ EDID_QUIRK('B', 'N', 'Q', 0x78d6, EDID_QUIRK_FORCE_8BPC),
+
/* BOE model on HP Pavilion 15-n233sl reports 8 bpc, but is a 6 bpc
panel */
EDID_QUIRK('B', 'O', 'E', 0x78b, EDID_QUIRK_FORCE_6BPC),
--
2.42.0
--
Hamza
[PATCH] drm/edid: add 8 bpc quirk to the BenQ GW2765
The BenQ GW2765 reports that it supports higher (> 8) bpc modes, but
when trying to set them we end up with a black screen. So, limit it to 8
bpc modes.
Cc: sta...@vger.kernel.org # 6.5+
Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2610
Signed-off-by: Hamza Mahfooz
---
drivers/gpu/drm/drm_edid.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 0454da505687..bca2af4fe1fc 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -123,6 +123,9 @@ static const struct edid_quirk {
/* AEO model 0 reports 8 bpc, but is a 6 bpc panel */
EDID_QUIRK('A', 'E', 'O', 0, EDID_QUIRK_FORCE_6BPC),
+ /* BenQ GW2765 */
+ EDID_QUIRK('B', 'N', 'Q', 0x78d6, EDID_QUIRK_FORCE_8BPC),
+
/* BOE model on HP Pavilion 15-n233sl reports 8 bpc, but is a 6 bpc
panel */
EDID_QUIRK('B', 'O', 'E', 0x78b, EDID_QUIRK_FORCE_6BPC),
--
2.42.0
Re: [PATCH RESEND v2 1/2] drm/print: Add drm_dbg_ratelimited
On 10/10/23 08:15, Andi Shyti wrote: From: Nirmoy Das Add a function for ratelimitted debug print. Signed-off-by: Nirmoy Das Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Thomas Zimmermann Cc: David Airlie Cc: Daniel Vetter Reviewed-by: Matthew Auld Reviewed-by: Andrzej Hajda Reviewed-by: Andi Shyti Reviewed-by: Sam Ravnborg Signed-off-by: Andi Shyti --- include/drm/drm_print.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h index a93a387f8a1a..ad77ac4b6808 100644 --- a/include/drm/drm_print.h +++ b/include/drm/drm_print.h @@ -602,6 +602,9 @@ void __drm_err(const char *format, ...); drm_dev_printk(drm_ ? drm_->dev : NULL, KERN_DEBUG, fmt, ## __VA_ARGS__);\ }) +#define drm_dbg_ratelimited(drm, fmt, ...) \ + __DRM_DEFINE_DBG_RATELIMITED(DRIVER, drm, fmt, ## __VA_ARGS__) + I guess since this was last sent drm_dbg_driver() was introduced, with drm_dbg() only being grandfathered in since it's already widely used, so it would probably be better to call this drm_dbg_driver_ratelimited() instead. #define drm_dbg_kms_ratelimited(drm, fmt, ...) \ __DRM_DEFINE_DBG_RATELIMITED(KMS, drm, fmt, ## __VA_ARGS__) -- Hamza
Re: [PATCH 0/5] drm/amd/display: Remove migrate-disable and move memory allocation.
On 9/21/23 10:15, Sebastian Andrzej Siewior wrote: Hi, I stumbled uppon the amdgpu driver via a bugzilla report. The actual fix is #4 + #5 and the rest was made while looking at the code. Sebastian I have applied the series, thanks! -- Hamza
Re: [PATCH 1/5] drm/amd/display: Remove migrate_en/dis from dc_fpu_begin().
On 10/3/23 15:53, Harry Wentland wrote:
On 2023-09-21 10:15, Sebastian Andrzej Siewior wrote:
This is a revert of the commit mentioned below while it is not wrong, as
in the kernel will explode, having migrate_disable() here it is
complete waste of resources.
Additionally commit message is plain wrong the review tag does not make
Not sure I follow what's unhelpful about the review tag with
0c316556d1249 ("drm/amd/display: Disable migration to ensure consistency of per-CPU
variable")
I do wish the original patch showed the splat it's attempting
to fix. It apparently made a difference for something, whether
inadvertently or not. I wish I knew what that "something" was.
I did some digging, and it seems like the intention of that patch was to
fix the following splat:
WARNING: CPU: 5 PID: 1062 at
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/dc_fpu.c:71
dc_assert_fp_enabled+0x1a/0x30 [amdgpu]
[...]
CPU: 5 PID: 1062 Comm: Xorg Tainted: G OE
5.15.0-56-generic #62-Ubuntu
Hardware name: ASUS System Product Name/ROG STRIX Z590-F GAMING WIFI,
BIOS 1202 10/27/2021
RIP: 0010:dc_assert_fp_enabled+0x1a/0x30 [amdgpu]
Code: ff 45 31 f6 0f 0b e9 ca fe ff ff e8 90 1c 1f f7 48 c7 c0 00 30 03
00 65 48 03 05 b1 aa 86 3f 8b 00 85 c0 7e 05 c3 cc cc cc cc <0f> 0b c3
cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00
RSP: :b89b82a8f118 EFLAGS: 00010246
RAX: RBX: 8c271cd0 RCX:
RDX: 8c2708025000 RSI: 8c270e8c RDI: 8c271cd0
RBP: b89b82a8f1d0 R08: R09: 7f6a
R10: b89b82a8f240 R11: R12: 0002
R13: 8c271cd0 R14: 8c270e8c R15: 8c2708025000
FS: 7f0570019a80() GS:8c2e3fb4() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: 5594858a0058 CR3: 00010e204001 CR4: 00770ee0
PKRU: 5554
Call Trace:
? dcn20_populate_dml_pipes_from_context+0x47/0x1730 [amdgpu]
? __kmalloc_node+0x2cb/0x3a0
dcn32_populate_dml_pipes_from_context+0x2b/0x450 [amdgpu]
dcn32_internal_validate_bw+0x15f9/0x2670 [amdgpu]
dcn32_find_dummy_latency_index_for_fw_based_mclk_switch+0xd0/0x310
[amdgpu]
dcn32_calculate_wm_and_dlg_fpu+0xe6/0x1e50 [amdgpu]
dcn32_calculate_wm_and_dlg+0x46/0x70 [amdgpu]
dcn32_validate_bandwidth+0x1b7/0x3e0 [amdgpu]
dc_validate_global_state+0x32c/0x560 [amdgpu]
dc_validate_with_context+0x6e6/0xd80 [amdgpu]
dc_commit_streams+0x21b/0x500 [amdgpu]
dc_commit_state+0xf3/0x150 [amdgpu]
amdgpu_dm_atomic_commit_tail+0x60d/0x3120 [amdgpu]
? dcn32_internal_validate_bw+0xcf8/0x2670 [amdgpu]
? fill_plane_buffer_attributes+0x1e5/0x560 [amdgpu]
? dcn32_validate_bandwidth+0x1e0/0x3e0 [amdgpu]
? kfree+0x1f7/0x250
? dcn32_validate_bandwidth+0x1e0/0x3e0 [amdgpu]
? dc_validate_global_state+0x32c/0x560 [amdgpu]
? __cond_resched+0x1a/0x50
? __wait_for_common+0x3e/0x150
? fill_plane_buffer_attributes+0x1e5/0x560 [amdgpu]
? usleep_range_state+0x90/0x90
? wait_for_completion_timeout+0x1d/0x30
commit_tail+0xc2/0x170 [drm_kms_helper]
? drm_atomic_helper_swap_state+0x20f/0x370 [drm_kms_helper]
drm_atomic_helper_commit+0x12b/0x150 [drm_kms_helper]
amdgpu_dm_atomic_commit+0x11/0x20 [amdgpu]
drm_atomic_commit+0x47/0x60 [drm]
drm_mode_obj_set_property_ioctl+0x16b/0x420 [drm]
? mutex_lock+0x13/0x50
? drm_mode_createblob_ioctl+0xf6/0x130 [drm]
? drm_mode_obj_find_prop_id+0x90/0x90 [drm]
drm_ioctl_kernel+0xb0/0x100 [drm]
drm_ioctl+0x268/0x4b0 [drm]
? drm_mode_obj_find_prop_id+0x90/0x90 [drm]
? ktime_get_mono_fast_ns+0x4a/0xa0
amdgpu_drm_ioctl+0x4e/0x90 [amdgpu]
__x64_sys_ioctl+0x92/0xd0
do_syscall_64+0x59/0xc0
? do_user_addr_fault+0x1e7/0x670
? do_syscall_64+0x69/0xc0
? exit_to_user_mode_prepare+0x37/0xb0
? irqentry_exit_to_user_mode+0x9/0x20
? irqentry_exit+0x1d/0x30
? exc_page_fault+0x89/0x170
entry_SYSCALL_64_after_hwframe+0x61/0xcb
RIP: 0033:0x7f05704a2aff
Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10 00 00 00 48 89
44 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 05 <41> 89 c0
3d 00 f0 ff ff 77 1f 48 8b 44 24 18 64 48 2b 04 25 28 00
RSP: 002b:7ffc8c45a3f0 EFLAGS: 0246 ORIG_RAX: 0010
RAX: ffda RBX: 7ffc8c45a480 RCX: 7f05704a2aff
RDX: 7ffc8c45a480 RSI: c01864ba RDI: 000e
RBP: c01864ba R08: 0077 R09:
R10: 7f05705a22f0 R11: 0246 R12: 0004
R13: 000e R14: 000f R15: 7ffc8c45a8a8
---[ end trace 4deab30bb69df00f ]---
Harry
it any better. The migrate_disable() interface has a fat comment
describing it and it includes the word "undesired" in the headline which
should tickle people to read it before using it.
Initially I assumed it is worded too harsh but now I beg to differ.
The reviewer of the original commit, even not understanding what
migrate_disable() does should ask the following:
- migrate_disable()
[PATCH] Revert "drm/amd/display: Check all enabled planes in dm_check_crtc_cursor"
From: Ivan Lipski
This reverts commit 45e1ade04b4d60fe5df859076005779f27c4c9be.
Since, it causes the following IGT tests to fail:
kms_cursor_legacy@cursor-vs-flip.*
kms_cursor_legacy@flip-vs-cursor.*
Signed-off-by: Ivan Lipski
Signed-off-by: Hamza Mahfooz
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 14 ++
1 file changed, 2 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 32156609fbcf..49ffb4d6e9cc 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -10290,24 +10290,14 @@ static int dm_check_crtc_cursor(struct
drm_atomic_state *state,
* blending properties match the underlying planes'.
*/
- new_cursor_state = drm_atomic_get_plane_state(state, cursor);
- if (IS_ERR(new_cursor_state))
- return PTR_ERR(new_cursor_state);
-
- if (!new_cursor_state->fb)
+ new_cursor_state = drm_atomic_get_new_plane_state(state, cursor);
+ if (!new_cursor_state || !new_cursor_state->fb)
return 0;
dm_get_oriented_plane_size(new_cursor_state, &cursor_src_w,
&cursor_src_h);
cursor_scale_w = new_cursor_state->crtc_w * 1000 / cursor_src_w;
cursor_scale_h = new_cursor_state->crtc_h * 1000 / cursor_src_h;
- /* Need to check all enabled planes, even if this commit doesn't change
-* their state
-*/
- i = drm_atomic_add_affected_planes(state, crtc);
- if (i)
- return i;
-
for_each_new_plane_in_state_reverse(state, underlying,
new_underlying_state, i) {
/* Narrow down to non-cursor planes on the same CRTC as the
cursor */
if (new_underlying_state->crtc != crtc || underlying ==
crtc->cursor)
--
2.42.0
Re: [PATCH] drm/amd/display: fix the ability to use lower resolution modes on eDP
On 9/14/23 17:04, Hamza Mahfooz wrote:
On 9/14/23 16:40, Harry Wentland wrote:
On 2023-09-14 13:53, Hamza Mahfooz wrote:
On eDP we can receive invalid modes from dm_update_crtc_state() for
entirely new streams for which drm_mode_set_crtcinfo() shouldn't be
called on. So, instead of calling drm_mode_set_crtcinfo() from within
create_stream_for_sink() we can instead call it from
amdgpu_dm_connector_mode_valid(). Since, we are guaranteed to only call
drm_mode_set_crtcinfo() for valid modes from that function (invalid
modes are rejected by that callback) and that is the only user
of create_validate_stream_for_sink() that we need to call
drm_mode_set_crtcinfo() for (as before commit cb841d27b876
("drm/amd/display: Always pass connector_state to stream validation"),
that is the only place where create_validate_stream_for_sink()'s
dm_state was NULL).
I don't seem to see how a NULL dm_state in
create_validate_stream_for_sink() (or create_stream_for_sink() for that
matter) has an impact on the drm_mode_set_crtcinfo() call. That one
depends
on !old_stream and &mode.
If we look back to commit 4a2df0d1f28e ("drm/amd/display: Fixed
non-native modes not lighting up") it seems like the intent was to only
have drm_mode_set_crtcinfo() called for
amdgpu_dm_connector_mode_valid(). Since, even if we go that far back
create_stream_for_sink()'s dm_state was only NULL when it was called
from amdgpu_dm_connector_mode_valid().
It does look like &mode is an empty mode if we can't find a
preferred_mode,
though. Not sure if that can cause an issue.
I don't think it should be an issue, since before commit 4a2df0d1f28e
("drm/amd/display: Fixed non-native modes not lighting up") we always
I meant to refer to commit bd49f19039c1 ("drm/amd/display: Always set
crtcinfo from create_stream_for_sink") here.
called drm_mode_set_crtcinfo() in the aforementioned case (and only for
that case).
Harry
Cc: sta...@vger.kernel.org
Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2693
Fixes: cb841d27b876 ("drm/amd/display: Always pass connector_state to
stream validation")
Signed-off-by: Hamza Mahfooz
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 933c9b5d5252..beef4fef7338 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -6128,8 +6128,6 @@ create_stream_for_sink(struct
amdgpu_dm_connector *aconnector,
if (recalculate_timing)
drm_mode_set_crtcinfo(&saved_mode, 0);
- else if (!old_stream)
- drm_mode_set_crtcinfo(&mode, 0);
/*
* If scaling is enabled and refresh rate didn't change
@@ -6691,6 +6689,8 @@ enum drm_mode_status
amdgpu_dm_connector_mode_valid(struct drm_connector *connec
goto fail;
}
+ drm_mode_set_crtcinfo(mode, 0);
+
stream = create_validate_stream_for_sink(aconnector, mode,
to_dm_connector_state(connector->state),
NULL);
--
Hamza
Re: [PATCH] drm/amd/display: fix the ability to use lower resolution modes on eDP
On 9/14/23 16:40, Harry Wentland wrote:
On 2023-09-14 13:53, Hamza Mahfooz wrote:
On eDP we can receive invalid modes from dm_update_crtc_state() for
entirely new streams for which drm_mode_set_crtcinfo() shouldn't be
called on. So, instead of calling drm_mode_set_crtcinfo() from within
create_stream_for_sink() we can instead call it from
amdgpu_dm_connector_mode_valid(). Since, we are guaranteed to only call
drm_mode_set_crtcinfo() for valid modes from that function (invalid
modes are rejected by that callback) and that is the only user
of create_validate_stream_for_sink() that we need to call
drm_mode_set_crtcinfo() for (as before commit cb841d27b876
("drm/amd/display: Always pass connector_state to stream validation"),
that is the only place where create_validate_stream_for_sink()'s
dm_state was NULL).
I don't seem to see how a NULL dm_state in
create_validate_stream_for_sink() (or create_stream_for_sink() for that
matter) has an impact on the drm_mode_set_crtcinfo() call. That one depends
on !old_stream and &mode.
If we look back to commit 4a2df0d1f28e ("drm/amd/display: Fixed
non-native modes not lighting up") it seems like the intent was to only
have drm_mode_set_crtcinfo() called for
amdgpu_dm_connector_mode_valid(). Since, even if we go that far back
create_stream_for_sink()'s dm_state was only NULL when it was called
from amdgpu_dm_connector_mode_valid().
It does look like &mode is an empty mode if we can't find a preferred_mode,
though. Not sure if that can cause an issue.
I don't think it should be an issue, since before commit 4a2df0d1f28e
("drm/amd/display: Fixed non-native modes not lighting up") we always
called drm_mode_set_crtcinfo() in the aforementioned case (and only for
that case).
Harry
Cc: sta...@vger.kernel.org
Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2693
Fixes: cb841d27b876 ("drm/amd/display: Always pass connector_state to stream
validation")
Signed-off-by: Hamza Mahfooz
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 933c9b5d5252..beef4fef7338 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -6128,8 +6128,6 @@ create_stream_for_sink(struct amdgpu_dm_connector
*aconnector,
if (recalculate_timing)
drm_mode_set_crtcinfo(&saved_mode, 0);
- else if (!old_stream)
- drm_mode_set_crtcinfo(&mode, 0);
/*
* If scaling is enabled and refresh rate didn't change
@@ -6691,6 +6689,8 @@ enum drm_mode_status
amdgpu_dm_connector_mode_valid(struct drm_connector *connec
goto fail;
}
+ drm_mode_set_crtcinfo(mode, 0);
+
stream = create_validate_stream_for_sink(aconnector, mode,
to_dm_connector_state(connector->state),
NULL);
--
Hamza
[PATCH] drm/amd/display: fix the ability to use lower resolution modes on eDP
On eDP we can receive invalid modes from dm_update_crtc_state() for
entirely new streams for which drm_mode_set_crtcinfo() shouldn't be
called on. So, instead of calling drm_mode_set_crtcinfo() from within
create_stream_for_sink() we can instead call it from
amdgpu_dm_connector_mode_valid(). Since, we are guaranteed to only call
drm_mode_set_crtcinfo() for valid modes from that function (invalid
modes are rejected by that callback) and that is the only user
of create_validate_stream_for_sink() that we need to call
drm_mode_set_crtcinfo() for (as before commit cb841d27b876
("drm/amd/display: Always pass connector_state to stream validation"),
that is the only place where create_validate_stream_for_sink()'s
dm_state was NULL).
Cc: sta...@vger.kernel.org
Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2693
Fixes: cb841d27b876 ("drm/amd/display: Always pass connector_state to stream
validation")
Signed-off-by: Hamza Mahfooz
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 933c9b5d5252..beef4fef7338 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -6128,8 +6128,6 @@ create_stream_for_sink(struct amdgpu_dm_connector
*aconnector,
if (recalculate_timing)
drm_mode_set_crtcinfo(&saved_mode, 0);
- else if (!old_stream)
- drm_mode_set_crtcinfo(&mode, 0);
/*
* If scaling is enabled and refresh rate didn't change
@@ -6691,6 +6689,8 @@ enum drm_mode_status
amdgpu_dm_connector_mode_valid(struct drm_connector *connec
goto fail;
}
+ drm_mode_set_crtcinfo(mode, 0);
+
stream = create_validate_stream_for_sink(aconnector, mode,
to_dm_connector_state(connector->state),
NULL);
--
2.42.0
Re: [PATCH] drm/amd/display: Fix -Wuninitialized in dm_helpers_dp_mst_send_payload_allocation()
On 9/13/23 16:03, Alex Deucher wrote:
On Wed, Sep 13, 2023 at 3:57 PM Hamza Mahfooz wrote:
On 9/13/23 15:54, Alex Deucher wrote:
On Wed, Sep 13, 2023 at 12:17 PM Hamza Mahfooz wrote:
On 9/13/23 12:10, Nathan Chancellor wrote:
When building with clang, there is a warning (or error when
CONFIG_WERROR is set):
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_helpers.c:368:21:
error: variable 'old_payload' is uninitialized when used here
[-Werror,-Wuninitialized]
368 | new_payload,
old_payload);
|
^~~
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_helpers.c:344:61:
note: initialize the variable 'old_payload' to silence this warning
344 | struct drm_dp_mst_atomic_payload *new_payload,
*old_payload;
|
^
|
= NULL
1 error generated.
This variable is not required outside of this function so allocate
old_payload on the stack and pass it by reference to
dm_helpers_construct_old_payload(), resolving the warning.
Closes: https://github.com/ClangBuiltLinux/linux/issues/1931
Fixes: 5aa1dfcdf0a4 ("drm/mst: Refactor the flow for payload
allocation/removement")
Signed-off-by: Nathan Chancellor
Reviewed-by: Hamza Mahfooz
Hm, seems like this was pushed through drm-misc-next and as such our CI
didn't get a chance to test it.
Can you push this to drm-misc? That is where Wayne's patches landed.
If not, I can push it.
No need, I cherry-picked Wayne's patches to amd-staging-drm-next and
applied Nathan's fix.
Yes, but we can only have patches go upstream via one tree. Wayne's
patches are in drm-misc, so that is where the fix should be. It's
fine to have them in amd-staging-drm-next for testing purposes, but I
won't be upstreaming them via the amdgpu -next tree since they are
already in drm-misc.
In that case can you push it to drm-misc?
Alex
Alex
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
index 9ad509279b0a..c4c35f6844f4 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
@@ -341,7 +341,7 @@ bool dm_helpers_dp_mst_send_payload_allocation(
struct amdgpu_dm_connector *aconnector;
struct drm_dp_mst_topology_state *mst_state;
struct drm_dp_mst_topology_mgr *mst_mgr;
- struct drm_dp_mst_atomic_payload *new_payload, *old_payload;
+ struct drm_dp_mst_atomic_payload *new_payload, old_payload;
enum mst_progress_status set_flag = MST_ALLOCATE_NEW_PAYLOAD;
enum mst_progress_status clr_flag = MST_CLEAR_ALLOCATED_PAYLOAD;
int ret = 0;
@@ -365,8 +365,8 @@ bool dm_helpers_dp_mst_send_payload_allocation(
ret = drm_dp_add_payload_part2(mst_mgr, mst_state->base.state,
new_payload);
} else {
dm_helpers_construct_old_payload(stream->link,
mst_state->pbn_div,
- new_payload, old_payload);
- drm_dp_remove_payload_part2(mst_mgr, mst_state, old_payload,
new_payload);
+ new_payload, &old_payload);
+ drm_dp_remove_payload_part2(mst_mgr, mst_state, &old_payload,
new_payload);
}
if (ret) {
---
base-commit: 8569c31545385195bdb0c021124e68336e91c693
change-id:
20230913-fix-wuninitialized-dm_helpers_dp_mst_send_payload_allocation-c37b33aaad18
Best regards,
--
Hamza
--
Hamza
--
Hamza
Re: [PATCH] drm/amd/display: Fix -Wuninitialized in dm_helpers_dp_mst_send_payload_allocation()
On 9/13/23 15:54, Alex Deucher wrote:
On Wed, Sep 13, 2023 at 12:17 PM Hamza Mahfooz wrote:
On 9/13/23 12:10, Nathan Chancellor wrote:
When building with clang, there is a warning (or error when
CONFIG_WERROR is set):
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_helpers.c:368:21:
error: variable 'old_payload' is uninitialized when used here
[-Werror,-Wuninitialized]
368 | new_payload,
old_payload);
|
^~~
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_helpers.c:344:61:
note: initialize the variable 'old_payload' to silence this warning
344 | struct drm_dp_mst_atomic_payload *new_payload, *old_payload;
|^
|
= NULL
1 error generated.
This variable is not required outside of this function so allocate
old_payload on the stack and pass it by reference to
dm_helpers_construct_old_payload(), resolving the warning.
Closes: https://github.com/ClangBuiltLinux/linux/issues/1931
Fixes: 5aa1dfcdf0a4 ("drm/mst: Refactor the flow for payload
allocation/removement")
Signed-off-by: Nathan Chancellor
Reviewed-by: Hamza Mahfooz
Hm, seems like this was pushed through drm-misc-next and as such our CI
didn't get a chance to test it.
Can you push this to drm-misc? That is where Wayne's patches landed.
If not, I can push it.
No need, I cherry-picked Wayne's patches to amd-staging-drm-next and
applied Nathan's fix.
Alex
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
index 9ad509279b0a..c4c35f6844f4 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
@@ -341,7 +341,7 @@ bool dm_helpers_dp_mst_send_payload_allocation(
struct amdgpu_dm_connector *aconnector;
struct drm_dp_mst_topology_state *mst_state;
struct drm_dp_mst_topology_mgr *mst_mgr;
- struct drm_dp_mst_atomic_payload *new_payload, *old_payload;
+ struct drm_dp_mst_atomic_payload *new_payload, old_payload;
enum mst_progress_status set_flag = MST_ALLOCATE_NEW_PAYLOAD;
enum mst_progress_status clr_flag = MST_CLEAR_ALLOCATED_PAYLOAD;
int ret = 0;
@@ -365,8 +365,8 @@ bool dm_helpers_dp_mst_send_payload_allocation(
ret = drm_dp_add_payload_part2(mst_mgr, mst_state->base.state,
new_payload);
} else {
dm_helpers_construct_old_payload(stream->link,
mst_state->pbn_div,
- new_payload, old_payload);
- drm_dp_remove_payload_part2(mst_mgr, mst_state, old_payload,
new_payload);
+ new_payload, &old_payload);
+ drm_dp_remove_payload_part2(mst_mgr, mst_state, &old_payload,
new_payload);
}
if (ret) {
---
base-commit: 8569c31545385195bdb0c021124e68336e91c693
change-id:
20230913-fix-wuninitialized-dm_helpers_dp_mst_send_payload_allocation-c37b33aaad18
Best regards,
--
Hamza
--
Hamza
Re: [PATCH] drm/amd/display: Fix -Wuninitialized in dm_helpers_dp_mst_send_payload_allocation()
On 9/13/23 12:10, Nathan Chancellor wrote:
When building with clang, there is a warning (or error when
CONFIG_WERROR is set):
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_helpers.c:368:21:
error: variable 'old_payload' is uninitialized when used here
[-Werror,-Wuninitialized]
368 | new_payload,
old_payload);
|
^~~
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_helpers.c:344:61:
note: initialize the variable 'old_payload' to silence this warning
344 | struct drm_dp_mst_atomic_payload *new_payload, *old_payload;
|^
|
= NULL
1 error generated.
This variable is not required outside of this function so allocate
old_payload on the stack and pass it by reference to
dm_helpers_construct_old_payload(), resolving the warning.
Closes: https://github.com/ClangBuiltLinux/linux/issues/1931
Fixes: 5aa1dfcdf0a4 ("drm/mst: Refactor the flow for payload
allocation/removement")
Signed-off-by: Nathan Chancellor
Applied, thanks!
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
index 9ad509279b0a..c4c35f6844f4 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
@@ -341,7 +341,7 @@ bool dm_helpers_dp_mst_send_payload_allocation(
struct amdgpu_dm_connector *aconnector;
struct drm_dp_mst_topology_state *mst_state;
struct drm_dp_mst_topology_mgr *mst_mgr;
- struct drm_dp_mst_atomic_payload *new_payload, *old_payload;
+ struct drm_dp_mst_atomic_payload *new_payload, old_payload;
enum mst_progress_status set_flag = MST_ALLOCATE_NEW_PAYLOAD;
enum mst_progress_status clr_flag = MST_CLEAR_ALLOCATED_PAYLOAD;
int ret = 0;
@@ -365,8 +365,8 @@ bool dm_helpers_dp_mst_send_payload_allocation(
ret = drm_dp_add_payload_part2(mst_mgr, mst_state->base.state,
new_payload);
} else {
dm_helpers_construct_old_payload(stream->link,
mst_state->pbn_div,
-new_payload, old_payload);
- drm_dp_remove_payload_part2(mst_mgr, mst_state, old_payload,
new_payload);
+new_payload, &old_payload);
+ drm_dp_remove_payload_part2(mst_mgr, mst_state, &old_payload,
new_payload);
}
if (ret) {
---
base-commit: 8569c31545385195bdb0c021124e68336e91c693
change-id:
20230913-fix-wuninitialized-dm_helpers_dp_mst_send_payload_allocation-c37b33aaad18
Best regards,
--
Hamza
Re: [PATCH] drm/amd/display: Fix -Wuninitialized in dm_helpers_dp_mst_send_payload_allocation()
On 9/13/23 12:10, Nathan Chancellor wrote:
When building with clang, there is a warning (or error when
CONFIG_WERROR is set):
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_helpers.c:368:21:
error: variable 'old_payload' is uninitialized when used here
[-Werror,-Wuninitialized]
368 | new_payload,
old_payload);
|
^~~
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_helpers.c:344:61:
note: initialize the variable 'old_payload' to silence this warning
344 | struct drm_dp_mst_atomic_payload *new_payload, *old_payload;
|^
|
= NULL
1 error generated.
This variable is not required outside of this function so allocate
old_payload on the stack and pass it by reference to
dm_helpers_construct_old_payload(), resolving the warning.
Closes: https://github.com/ClangBuiltLinux/linux/issues/1931
Fixes: 5aa1dfcdf0a4 ("drm/mst: Refactor the flow for payload
allocation/removement")
Signed-off-by: Nathan Chancellor
Reviewed-by: Hamza Mahfooz
Hm, seems like this was pushed through drm-misc-next and as such our CI
didn't get a chance to test it.
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
index 9ad509279b0a..c4c35f6844f4 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
@@ -341,7 +341,7 @@ bool dm_helpers_dp_mst_send_payload_allocation(
struct amdgpu_dm_connector *aconnector;
struct drm_dp_mst_topology_state *mst_state;
struct drm_dp_mst_topology_mgr *mst_mgr;
- struct drm_dp_mst_atomic_payload *new_payload, *old_payload;
+ struct drm_dp_mst_atomic_payload *new_payload, old_payload;
enum mst_progress_status set_flag = MST_ALLOCATE_NEW_PAYLOAD;
enum mst_progress_status clr_flag = MST_CLEAR_ALLOCATED_PAYLOAD;
int ret = 0;
@@ -365,8 +365,8 @@ bool dm_helpers_dp_mst_send_payload_allocation(
ret = drm_dp_add_payload_part2(mst_mgr, mst_state->base.state,
new_payload);
} else {
dm_helpers_construct_old_payload(stream->link,
mst_state->pbn_div,
-new_payload, old_payload);
- drm_dp_remove_payload_part2(mst_mgr, mst_state, old_payload,
new_payload);
+new_payload, &old_payload);
+ drm_dp_remove_payload_part2(mst_mgr, mst_state, &old_payload,
new_payload);
}
if (ret) {
---
base-commit: 8569c31545385195bdb0c021124e68336e91c693
change-id:
20230913-fix-wuninitialized-dm_helpers_dp_mst_send_payload_allocation-c37b33aaad18
Best regards,
--
Hamza
Re: [PATCH v4 0/2] Merge all debug module parameters
On 9/11/23 13:12, André Almeida wrote: As suggested by Christian at [0], this patchset merges all debug modules parameters and creates a new one for disabling soft recovery: Maybe we can overload the amdgpu_gpu_recovery module option with this. Or even better merge all the developer module parameter into a amdgpu_debug option. This way it should be pretty obvious that this isn't meant to be used by someone who doesn't know how to use it. [0] https://lore.kernel.org/dri-devel/55f69184-1aa2-55d6-4a10-1560d75c7...@amd.com/ I have applied the series, thanks! Changelog: - rebased on top of current amd-staging-drm-next v3: https://lore.kernel.org/lkml/20230831152903.521404-1-andrealm...@igalia.com - move enum from include/amd_shared.h to amdgpu/amdgpu_drv.c v2: https://lore.kernel.org/lkml/20230830220808.421935-1-andrealm...@igalia.com/ - drop old module params - use BIT() macros - replace global var with adev-> vars v1: https://lore.kernel.org/lkml/20230824162505.173399-1-andrealm...@igalia.com/ André Almeida (2): drm/amdgpu: Merge debug module parameters drm/amdgpu: Create an option to disable soft recovery drivers/gpu/drm/amd/amdgpu/amdgpu.h | 5 ++ drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 63 drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c | 7 ++- drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 2 +- drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 2 +- drivers/gpu/drm/amd/amdkfd/kfd_crat.c| 2 +- 8 files changed, 59 insertions(+), 26 deletions(-) -- Hamza
Re: [PATCH v3 0/2] Merge all debug module parameters
On 9/11/23 09:54, André Almeida wrote: Christian, Alex, I think this series is ready to be picked as well. Can you rebase this onto amd-staging-drm-next (https://gitlab.freedesktop.org/agd5f/linux)? Since it currently doesn't apply there. Em 31/08/2023 12:29, André Almeida escreveu: As suggested by Christian at [0], this patchset merges all debug modules parameters and creates a new one for disabling soft recovery: Maybe we can overload the amdgpu_gpu_recovery module option with this. Or even better merge all the developer module parameter into a amdgpu_debug option. This way it should be pretty obvious that this isn't meant to be used by someone who doesn't know how to use it. [0] https://lore.kernel.org/dri-devel/55f69184-1aa2-55d6-4a10-1560d75c7...@amd.com/ Changelog: - move enum from include/amd_shared.h to amdgpu/amdgpu_drv.c v2: https://lore.kernel.org/lkml/20230830220808.421935-1-andrealm...@igalia.com/ - drop old module params - use BIT() macros - replace global var with adev-> vars v1: https://lore.kernel.org/lkml/20230824162505.173399-1-andrealm...@igalia.com/ André Almeida (2): drm/amdgpu: Merge debug module parameters drm/amdgpu: Create an option to disable soft recovery drivers/gpu/drm/amd/amdgpu/amdgpu.h | 5 ++ drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 63 drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c | 6 ++- drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 2 +- drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 2 +- drivers/gpu/drm/amd/amdkfd/kfd_crat.c | 2 +- 8 files changed, 58 insertions(+), 26 deletions(-) -- Hamza
Re: [PATCH] drm/amd/display: fix replay_mode kernel-doc warning
On 9/10/23 19:44, Randy Dunlap wrote:
Fix the typo in the kernel-doc for @replay_mode to prevent
kernel-doc warnings:
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h:623: warning: Incorrect use
of kernel-doc format: * @replay mode: Replay supported
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h:626: warning: Function
parameter or member 'replay_mode' not described in 'amdgpu_hdmi_vsdb_info'
Fixes: ec8e59cb4e0c ("drm/amd/display: Get replay info from VSDB")
Signed-off-by: Randy Dunlap
Reported-by: kernel test robot
Cc: Bhawanpreet Lakha
Cc: Harry Wentland
Cc: Alex Deucher
Cc: Leo Li
Cc: Rodrigo Siqueira
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Applied, thanks!
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
@@ -620,7 +620,7 @@ struct amdgpu_hdmi_vsdb_info {
unsigned int max_refresh_rate_hz;
/**
-* @replay mode: Replay supported
+* @replay_mode: Replay supported
*/
bool replay_mode;
};
--
Hamza
Re: [PATCH] drm/amd/display: clean up some inconsistent indenting
On 9/8/23 03:54, Jiapeng Chong wrote:
No functional modification involved.
drivers/gpu/drm/amd/amdgpu/../display/dc/link/link_dpms.c:2476
link_set_dpms_on() warn: if statement not indented.
Reported-by: Abaci Robot
Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=6502
Signed-off-by: Jiapeng Chong
Applied, thanks!
---
drivers/gpu/drm/amd/display/dc/link/link_dpms.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/link/link_dpms.c
b/drivers/gpu/drm/amd/display/dc/link/link_dpms.c
index cd9dd270b05f..e7e528c68cb6 100644
--- a/drivers/gpu/drm/amd/display/dc/link/link_dpms.c
+++ b/drivers/gpu/drm/amd/display/dc/link/link_dpms.c
@@ -2474,9 +2474,8 @@ void link_set_dpms_on(
*/
if (pipe_ctx->stream->timing.flags.DSC) {
if (dc_is_dp_signal(pipe_ctx->stream->signal) ||
- dc_is_virtual_signal(pipe_ctx->stream->signal))
- link_set_dsc_enable(pipe_ctx, true);
-
+ dc_is_virtual_signal(pipe_ctx->stream->signal))
+ link_set_dsc_enable(pipe_ctx, true);
}
status = enable_link(state, pipe_ctx);
--
Hamza
[PATCH v2 2/2] Revert "drm/amd: Disable S/G for APUs when 64GB or more host memory"
This reverts commit 5b7a256c982636ebc4f16b708b40ff56d33c8a86.
Since, we now have an actual fix for this issue, we can get rid of this
workaround as it can cause pin failures if enough VRAM isn't carved out
by the BIOS.
Cc: sta...@vger.kernel.org # 6.1+
Signed-off-by: Hamza Mahfooz
---
v2: new to the series
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 -
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c| 26 ---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 5 ++--
3 files changed, 3 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 83a9607a87b8..3a86d11d1605 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -1316,7 +1316,6 @@ int amdgpu_device_gpu_recover(struct amdgpu_device *adev,
void amdgpu_device_pci_config_reset(struct amdgpu_device *adev);
int amdgpu_device_pci_reset(struct amdgpu_device *adev);
bool amdgpu_device_need_post(struct amdgpu_device *adev);
-bool amdgpu_sg_display_supported(struct amdgpu_device *adev);
bool amdgpu_device_pcie_dynamic_switching_supported(void);
bool amdgpu_device_should_use_aspm(struct amdgpu_device *adev);
bool amdgpu_device_aspm_support_quirk(void);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 5f32e8d4f3d3..3d540b0cf0e1 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -1358,32 +1358,6 @@ bool amdgpu_device_need_post(struct amdgpu_device *adev)
return true;
}
-/*
- * On APUs with >= 64GB white flickering has been observed w/ SG enabled.
- * Disable S/G on such systems until we have a proper fix.
- * https://gitlab.freedesktop.org/drm/amd/-/issues/2354
- * https://gitlab.freedesktop.org/drm/amd/-/issues/2735
- */
-bool amdgpu_sg_display_supported(struct amdgpu_device *adev)
-{
- switch (amdgpu_sg_display) {
- case -1:
- break;
- case 0:
- return false;
- case 1:
- return true;
- default:
- return false;
- }
- if ((totalram_pages() << (PAGE_SHIFT - 10)) +
- (adev->gmc.real_vram_size / 1024) >= 6400) {
- DRM_WARN("Disabling S/G due to >=64GB RAM\n");
- return false;
- }
- return true;
-}
-
/*
* Intel hosts such as Raptor Lake and Sapphire Rapids don't support dynamic
* speed switching. Until we have confirmation from Intel that a specific host
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 5f14cd9391ca..740a6fcafe4c 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -1654,8 +1654,9 @@ static int amdgpu_dm_init(struct amdgpu_device *adev)
}
break;
}
- if (init_data.flags.gpu_vm_support)
- init_data.flags.gpu_vm_support =
amdgpu_sg_display_supported(adev);
+ if (init_data.flags.gpu_vm_support &&
+ (amdgpu_sg_display == 0))
+ init_data.flags.gpu_vm_support = false;
if (init_data.flags.gpu_vm_support)
adev->mode_info.gpu_vm_support = true;
--
2.41.0
[PATCH v2 1/2] drm/amd/display: fix the white screen issue when >= 64GB DRAM
From: Yifan Zhang
Dropping bit 31:4 of page table base is wrong, it makes page table
base points to wrong address if phys addr is beyond 64GB; dropping
page_table_start/end bit 31:4 is unnecessary since dcn20_vmid_setup
will do that. Also, while we are at it, cleanup the assignments using
upper_32_bits()/lower_32_bits() and AMDGPU_GPU_PAGE_SHIFT.
Cc: sta...@vger.kernel.org
Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2354
Fixes: 81d0bcf99009 ("drm/amdgpu: make display pinning more flexible (v2)")
Signed-off-by: Yifan Zhang
Signed-off-by: Hamza Mahfooz
---
v2: use upper_32_bits()/lower_32_bits() and AMDGPU_GPU_PAGE_SHIFT
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 1bb1a394f55f..5f14cd9391ca 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -1283,11 +1283,15 @@ static void mmhub_read_system_context(struct
amdgpu_device *adev, struct dc_phy_
pt_base = amdgpu_gmc_pd_addr(adev->gart.bo);
- page_table_start.high_part = (u32)(adev->gmc.gart_start >> 44) & 0xF;
- page_table_start.low_part = (u32)(adev->gmc.gart_start >> 12);
- page_table_end.high_part = (u32)(adev->gmc.gart_end >> 44) & 0xF;
- page_table_end.low_part = (u32)(adev->gmc.gart_end >> 12);
- page_table_base.high_part = upper_32_bits(pt_base) & 0xF;
+ page_table_start.high_part = upper_32_bits(adev->gmc.gart_start >>
+ AMDGPU_GPU_PAGE_SHIFT);
+ page_table_start.low_part = lower_32_bits(adev->gmc.gart_start >>
+ AMDGPU_GPU_PAGE_SHIFT);
+ page_table_end.high_part = upper_32_bits(adev->gmc.gart_end >>
+AMDGPU_GPU_PAGE_SHIFT);
+ page_table_end.low_part = lower_32_bits(adev->gmc.gart_end >>
+ AMDGPU_GPU_PAGE_SHIFT);
+ page_table_base.high_part = upper_32_bits(pt_base);
page_table_base.low_part = lower_32_bits(pt_base);
pa_config->system_aperture.start_addr = (uint64_t)logical_addr_low <<
18;
--
2.41.0
[PATCH] drm/amd/display: prevent potential division by zero errors
There are two places in apply_below_the_range() where it's possible for
a divide by zero error to occur. So, to fix this make sure the divisor
is non-zero before attempting the computation in both cases.
Cc: sta...@vger.kernel.org
Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2637
Fixes: a463b263032f ("drm/amd/display: Fix frames_to_insert math")
Fixes: ded6119e825a ("drm/amd/display: Reinstate LFC optimization")
Signed-off-by: Hamza Mahfooz
---
drivers/gpu/drm/amd/display/modules/freesync/freesync.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/modules/freesync/freesync.c
b/drivers/gpu/drm/amd/display/modules/freesync/freesync.c
index dbd60811f95d..ef3a67409021 100644
--- a/drivers/gpu/drm/amd/display/modules/freesync/freesync.c
+++ b/drivers/gpu/drm/amd/display/modules/freesync/freesync.c
@@ -338,7 +338,9 @@ static void apply_below_the_range(struct core_freesync
*core_freesync,
* - Delta for CEIL: delta_from_mid_point_in_us_1
* - Delta for FLOOR: delta_from_mid_point_in_us_2
*/
- if ((last_render_time_in_us / mid_point_frames_ceil) <
in_out_vrr->min_duration_in_us) {
+ if (mid_point_frames_ceil &&
+ (last_render_time_in_us / mid_point_frames_ceil) <
+ in_out_vrr->min_duration_in_us) {
/* Check for out of range.
* If using CEIL produces a value that is out of range,
* then we are forced to use FLOOR.
@@ -385,8 +387,9 @@ static void apply_below_the_range(struct core_freesync
*core_freesync,
/* Either we've calculated the number of frames to insert,
* or we need to insert min duration frames
*/
- if (last_render_time_in_us / frames_to_insert <
- in_out_vrr->min_duration_in_us){
+ if (frames_to_insert &&
+ (last_render_time_in_us / frames_to_insert) <
+ in_out_vrr->min_duration_in_us){
frames_to_insert -= (frames_to_insert > 1) ?
1 : 0;
}
--
2.41.0
[PATCH v2 2/2] drm/amd/display: limit the v_startup workaround for ASICs older than DCN3.1
Since, calling dcn20_adjust_freesync_v_startup() on DCN3.1+ ASICs can cause the display to flicker and underflow to occur we shouldn't call it for them. So, ensure that the DCN version is less than DCN_VERSION_3_1 before calling dcn20_adjust_freesync_v_startup(). Cc: sta...@vger.kernel.org Signed-off-by: Hamza Mahfooz --- drivers/gpu/drm/amd/display/dc/dml/dcn20/dcn20_fpu.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/display/dc/dml/dcn20/dcn20_fpu.c b/drivers/gpu/drm/amd/display/dc/dml/dcn20/dcn20_fpu.c index 1bfdf0271fdf..a68fb45ed487 100644 --- a/drivers/gpu/drm/amd/display/dc/dml/dcn20/dcn20_fpu.c +++ b/drivers/gpu/drm/amd/display/dc/dml/dcn20/dcn20_fpu.c @@ -1099,7 +1099,8 @@ void dcn20_calculate_dlg_params(struct dc *dc, context->res_ctx.pipe_ctx[i].plane_res.bw.dppclk_khz = pipes[pipe_idx].clks_cfg.dppclk_mhz * 1000; context->res_ctx.pipe_ctx[i].pipe_dlg_param = pipes[pipe_idx].pipe.dest; - if (context->res_ctx.pipe_ctx[i].stream->adaptive_sync_infopacket.valid) + if (dc->ctx->dce_version < DCN_VERSION_3_1 && + context->res_ctx.pipe_ctx[i].stream->adaptive_sync_infopacket.valid) dcn20_adjust_freesync_v_startup( &context->res_ctx.pipe_ctx[i].stream->timing, &context->res_ctx.pipe_ctx[i].pipe_dlg_param.vstartup_start); -- 2.41.0
[PATCH v2 1/2] Revert "drm/amd/display: Remove v_startup workaround for dcn3+"
This reverts commit 3a31e8b89b7240d9a17ace8a1ed050bdcb560f9e.
We still need to call dcn20_adjust_freesync_v_startup() for older DCN3+
ASICs otherwise it can cause DP to HDMI 2.1 PCONs to fail to light up.
Cc: sta...@vger.kernel.org
Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2809
Signed-off-by: Hamza Mahfooz
---
.../drm/amd/display/dc/dml/dcn20/dcn20_fpu.c | 24 ---
1 file changed, 4 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dml/dcn20/dcn20_fpu.c
b/drivers/gpu/drm/amd/display/dc/dml/dcn20/dcn20_fpu.c
index 0989a0152ae8..1bfdf0271fdf 100644
--- a/drivers/gpu/drm/amd/display/dc/dml/dcn20/dcn20_fpu.c
+++ b/drivers/gpu/drm/amd/display/dc/dml/dcn20/dcn20_fpu.c
@@ -1099,6 +1099,10 @@ void dcn20_calculate_dlg_params(struct dc *dc,
context->res_ctx.pipe_ctx[i].plane_res.bw.dppclk_khz =
pipes[pipe_idx].clks_cfg.dppclk_mhz * 1000;
context->res_ctx.pipe_ctx[i].pipe_dlg_param =
pipes[pipe_idx].pipe.dest;
+ if
(context->res_ctx.pipe_ctx[i].stream->adaptive_sync_infopacket.valid)
+ dcn20_adjust_freesync_v_startup(
+ &context->res_ctx.pipe_ctx[i].stream->timing,
+
&context->res_ctx.pipe_ctx[i].pipe_dlg_param.vstartup_start);
pipe_idx++;
}
@@ -1927,7 +1931,6 @@ static bool dcn20_validate_bandwidth_internal(struct dc
*dc, struct dc_state *co
int vlevel = 0;
int pipe_split_from[MAX_PIPES];
int pipe_cnt = 0;
- int i = 0;
display_e2e_pipe_params_st *pipes = kzalloc(dc->res_pool->pipe_count *
sizeof(display_e2e_pipe_params_st), GFP_ATOMIC);
DC_LOGGER_INIT(dc->ctx->logger);
@@ -1951,15 +1954,6 @@ static bool dcn20_validate_bandwidth_internal(struct dc
*dc, struct dc_state *co
dcn20_calculate_wm(dc, context, pipes, &pipe_cnt, pipe_split_from,
vlevel, fast_validate);
dcn20_calculate_dlg_params(dc, context, pipes, pipe_cnt, vlevel);
- for (i = 0; i < dc->res_pool->pipe_count; i++) {
- if (!context->res_ctx.pipe_ctx[i].stream)
- continue;
- if
(context->res_ctx.pipe_ctx[i].stream->adaptive_sync_infopacket.valid)
- dcn20_adjust_freesync_v_startup(
- &context->res_ctx.pipe_ctx[i].stream->timing,
-
&context->res_ctx.pipe_ctx[i].pipe_dlg_param.vstartup_start);
- }
-
BW_VAL_TRACE_END_WATERMARKS();
goto validate_out;
@@ -2232,7 +2226,6 @@ bool dcn21_validate_bandwidth_fp(struct dc *dc,
int vlevel = 0;
int pipe_split_from[MAX_PIPES];
int pipe_cnt = 0;
- int i = 0;
display_e2e_pipe_params_st *pipes = kzalloc(dc->res_pool->pipe_count *
sizeof(display_e2e_pipe_params_st), GFP_ATOMIC);
DC_LOGGER_INIT(dc->ctx->logger);
@@ -2261,15 +2254,6 @@ bool dcn21_validate_bandwidth_fp(struct dc *dc,
dcn21_calculate_wm(dc, context, pipes, &pipe_cnt, pipe_split_from,
vlevel, fast_validate);
dcn20_calculate_dlg_params(dc, context, pipes, pipe_cnt, vlevel);
- for (i = 0; i < dc->res_pool->pipe_count; i++) {
- if (!context->res_ctx.pipe_ctx[i].stream)
- continue;
- if
(context->res_ctx.pipe_ctx[i].stream->adaptive_sync_infopacket.valid)
- dcn20_adjust_freesync_v_startup(
- &context->res_ctx.pipe_ctx[i].stream->timing,
-
&context->res_ctx.pipe_ctx[i].pipe_dlg_param.vstartup_start);
- }
-
BW_VAL_TRACE_END_WATERMARKS();
goto validate_out;
--
2.41.0
[PATCH] Revert "drm/amd/display: Remove v_startup workaround for dcn3+"
This reverts commit 3a31e8b89b7240d9a17ace8a1ed050bdcb560f9e.
We still need to call dcn20_adjust_freesync_v_startup() for older DCN3+
ASICs otherwise it can cause DP to HDMI 2.1 PCONs to fail to light up.
So, reintroduce the reverted code and limit it to ASICs older than
DCN31.
Cc: sta...@vger.kernel.org
Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2809
Signed-off-by: Hamza Mahfooz
---
.../drm/amd/display/dc/dml/dcn20/dcn20_fpu.c | 24 ---
1 file changed, 4 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dml/dcn20/dcn20_fpu.c
b/drivers/gpu/drm/amd/display/dc/dml/dcn20/dcn20_fpu.c
index 0989a0152ae8..0841176e8d6c 100644
--- a/drivers/gpu/drm/amd/display/dc/dml/dcn20/dcn20_fpu.c
+++ b/drivers/gpu/drm/amd/display/dc/dml/dcn20/dcn20_fpu.c
@@ -1099,6 +1099,10 @@ void dcn20_calculate_dlg_params(struct dc *dc,
context->res_ctx.pipe_ctx[i].plane_res.bw.dppclk_khz =
pipes[pipe_idx].clks_cfg.dppclk_mhz * 1000;
context->res_ctx.pipe_ctx[i].pipe_dlg_param =
pipes[pipe_idx].pipe.dest;
+ if (dc->ctx->dce_version < DCN_VERSION_3_1 &&
+
context->res_ctx.pipe_ctx[i].stream->adaptive_sync_infopacket.valid)
+
dcn20_adjust_freesync_v_startup(&context->res_ctx.pipe_ctx[i].stream->timing,
+
&context->res_ctx.pipe_ctx[i].pipe_dlg_param.vstartup_start);
pipe_idx++;
}
@@ -1927,7 +1931,6 @@ static bool dcn20_validate_bandwidth_internal(struct dc
*dc, struct dc_state *co
int vlevel = 0;
int pipe_split_from[MAX_PIPES];
int pipe_cnt = 0;
- int i = 0;
display_e2e_pipe_params_st *pipes = kzalloc(dc->res_pool->pipe_count *
sizeof(display_e2e_pipe_params_st), GFP_ATOMIC);
DC_LOGGER_INIT(dc->ctx->logger);
@@ -1951,15 +1954,6 @@ static bool dcn20_validate_bandwidth_internal(struct dc
*dc, struct dc_state *co
dcn20_calculate_wm(dc, context, pipes, &pipe_cnt, pipe_split_from,
vlevel, fast_validate);
dcn20_calculate_dlg_params(dc, context, pipes, pipe_cnt, vlevel);
- for (i = 0; i < dc->res_pool->pipe_count; i++) {
- if (!context->res_ctx.pipe_ctx[i].stream)
- continue;
- if
(context->res_ctx.pipe_ctx[i].stream->adaptive_sync_infopacket.valid)
- dcn20_adjust_freesync_v_startup(
- &context->res_ctx.pipe_ctx[i].stream->timing,
-
&context->res_ctx.pipe_ctx[i].pipe_dlg_param.vstartup_start);
- }
-
BW_VAL_TRACE_END_WATERMARKS();
goto validate_out;
@@ -2232,7 +2226,6 @@ bool dcn21_validate_bandwidth_fp(struct dc *dc,
int vlevel = 0;
int pipe_split_from[MAX_PIPES];
int pipe_cnt = 0;
- int i = 0;
display_e2e_pipe_params_st *pipes = kzalloc(dc->res_pool->pipe_count *
sizeof(display_e2e_pipe_params_st), GFP_ATOMIC);
DC_LOGGER_INIT(dc->ctx->logger);
@@ -2261,15 +2254,6 @@ bool dcn21_validate_bandwidth_fp(struct dc *dc,
dcn21_calculate_wm(dc, context, pipes, &pipe_cnt, pipe_split_from,
vlevel, fast_validate);
dcn20_calculate_dlg_params(dc, context, pipes, pipe_cnt, vlevel);
- for (i = 0; i < dc->res_pool->pipe_count; i++) {
- if (!context->res_ctx.pipe_ctx[i].stream)
- continue;
- if
(context->res_ctx.pipe_ctx[i].stream->adaptive_sync_infopacket.valid)
- dcn20_adjust_freesync_v_startup(
- &context->res_ctx.pipe_ctx[i].stream->timing,
-
&context->res_ctx.pipe_ctx[i].pipe_dlg_param.vstartup_start);
- }
-
BW_VAL_TRACE_END_WATERMARKS();
goto validate_out;
--
2.41.0
[PATCH] Revert "Revert "drm/amd/display: Implement zpos property""
This reverts commit 984612bd4649c91f12e9c7c7f9e914fdc8ba7d3f.
The problematic IGT test case (i.e. kms_atomic@plane-immutable-zpos) has
been fixed as of commit cb77add45011 ("tests/kms_atomic: remove zpos <
N-planes assert") to the IGT repo. So, reintroduce the reverted code.
Link:
https://gitlab.freedesktop.org/drm/igt-gpu-tools/-/commit/cb77add45011b129e21f3cb2a4089a73dde56179
Signed-off-by: Hamza Mahfooz
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c
index 894bc7e4fdaa..df568a7cd005 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c
@@ -1469,6 +1469,15 @@ int amdgpu_dm_plane_init(struct amdgpu_display_manager
*dm,
drm_plane_create_blend_mode_property(plane, blend_caps);
}
+ if (plane->type == DRM_PLANE_TYPE_PRIMARY) {
+ drm_plane_create_zpos_immutable_property(plane, 0);
+ } else if (plane->type == DRM_PLANE_TYPE_OVERLAY) {
+ unsigned int zpos = 1 + drm_plane_index(plane);
+ drm_plane_create_zpos_property(plane, zpos, 1, 254);
+ } else if (plane->type == DRM_PLANE_TYPE_CURSOR) {
+ drm_plane_create_zpos_immutable_property(plane, 255);
+ }
+
if (plane->type == DRM_PLANE_TYPE_PRIMARY &&
plane_cap &&
(plane_cap->pixel_format_support.nv12 ||
--
2.41.0
Re: [PATCH (set 1) 00/20] Rid W=1 warnings from GPU
On 8/24/23 08:07, Lee Jones wrote: On Thu, 24 Aug 2023, Jani Nikula wrote: On Thu, 24 Aug 2023, Lee Jones wrote: This set is part of a larger effort attempting to clean-up W=1 kernel builds, which are currently overwhelmingly riddled with niggly little warnings. The next question is, how do we keep it W=1 clean going forward? My plan was to fix them all, then move each warning to W=0. Arnd recently submitted a set doing just that for a bunch of them. https://lore.kernel.org/all/20230811140327.3754597-1-a...@kernel.org/ I like to think a bunch of this is built on top of my previous efforts. GPU is a particularly tricky though - the warnings seem to come in faster than I can squash them. Maybe the maintainers can find a way to test new patches on merge? I guess on that note, do you know if there is a way to run `scripts/kernel-doc` on patches instead of whole files? That would make much easier to block new kernel-doc issues from appearing. Most people don't use W=1 because it's too noisy, so it's a bit of a catch-22. In i915, we enable a lot of W=1 warnings using subdir-ccflags-y in our Makefile. For CI/developer use we also enable kernel-doc warnings by default. Should we start enabling some of those warning flags in drm/Makefile to to keep the entire subsystem warning free? That would we awesome! We'd just need buy-in. -- Hamza
Re: [PATCH v2] drm/amdgpu: register a dirty framebuffer callback for fbcon
On 8/23/23 16:51, Alex Deucher wrote:
@Mahfooz, Hamza
can you respin with the NULL check?
sure.
Alex
On Wed, Aug 16, 2023 at 10:25 AM Christian König
wrote:
Am 16.08.23 um 15:41 schrieb Hamza Mahfooz:
On 8/16/23 01:55, Christian König wrote:
Am 15.08.23 um 19:26 schrieb Hamza Mahfooz:
fbcon requires that we implement &drm_framebuffer_funcs.dirty.
Otherwise, the framebuffer might take a while to flush (which would
manifest as noticeable lag). However, we can't enable this callback for
non-fbcon cases since it might cause too many atomic commits to be made
at once. So, implement amdgpu_dirtyfb() and only enable it for fbcon
framebuffers on devices that support atomic KMS.
Cc: Aurabindo Pillai
Cc: Mario Limonciello
Cc: sta...@vger.kernel.org # 6.1+
Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2519
Signed-off-by: Hamza Mahfooz
---
v2: update variable names
---
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 26
-
1 file changed, 25 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
index d20dd3f852fc..d3b59f99cb7c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
@@ -38,6 +38,8 @@
#include
#include
#include
+#include
+#include
#include
#include
#include
@@ -532,11 +534,29 @@ bool amdgpu_display_ddc_probe(struct
amdgpu_connector *amdgpu_connector,
return true;
}
+static int amdgpu_dirtyfb(struct drm_framebuffer *fb, struct
drm_file *file,
+ unsigned int flags, unsigned int color,
+ struct drm_clip_rect *clips, unsigned int num_clips)
+{
+
+if (strcmp(fb->comm, "[fbcon]"))
+return -ENOSYS;
Once more to the v2 of this patch: Tests like those are a pretty big
NO-GO for upstreaming.
On closer inspection it is actually sufficient to check if `file` is
NULL here (since it means that the request isn't from userspace). So, do
you think that would be palatable for upstream?
That's certainly better than doing a string compare, but I'm not sure if
that's sufficient.
In general drivers shouldn't have any special handling for fdcon.
You should probably have Thomas Zimmermann take a
look at this.
Regards,
Christian.
Regards,
Christian.
+
+return drm_atomic_helper_dirtyfb(fb, file, flags, color, clips,
+ num_clips);
+}
+
static const struct drm_framebuffer_funcs amdgpu_fb_funcs = {
.destroy = drm_gem_fb_destroy,
.create_handle = drm_gem_fb_create_handle,
};
+static const struct drm_framebuffer_funcs amdgpu_fb_funcs_atomic = {
+.destroy = drm_gem_fb_destroy,
+.create_handle = drm_gem_fb_create_handle,
+.dirty = amdgpu_dirtyfb
+};
+
uint32_t amdgpu_display_supported_domains(struct amdgpu_device *adev,
uint64_t bo_flags)
{
@@ -1139,7 +1159,11 @@ static int
amdgpu_display_gem_fb_verify_and_init(struct drm_device *dev,
if (ret)
goto err;
-ret = drm_framebuffer_init(dev, &rfb->base, &amdgpu_fb_funcs);
+if (drm_drv_uses_atomic_modeset(dev))
+ret = drm_framebuffer_init(dev, &rfb->base,
+ &amdgpu_fb_funcs_atomic);
+else
+ret = drm_framebuffer_init(dev, &rfb->base, &amdgpu_fb_funcs);
if (ret)
goto err;
--
Hamza
[PATCH] drm/amd/display: register edp_backlight_control() for DCN301
As made mention of in commit 099303e9a9bd ("drm/amd/display: eDP
intermittent black screen during PnP"), we need to turn off the
display's backlight before powering off an eDP display. Not doing so
will result in undefined behaviour according to the eDP spec. So, set
DCN301's edp_backlight_control() function pointer to
dce110_edp_backlight_control().
Cc: sta...@vger.kernel.org
Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2765
Fixes: 9c75891feef0 ("drm/amd/display: rework recent update PHY state commit")
Suggested-by: Swapnil Patel
Signed-off-by: Hamza Mahfooz
---
drivers/gpu/drm/amd/display/dc/dcn301/dcn301_init.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn301/dcn301_init.c
b/drivers/gpu/drm/amd/display/dc/dcn301/dcn301_init.c
index 257df8660b4c..61205cdbe2d5 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn301/dcn301_init.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn301/dcn301_init.c
@@ -75,6 +75,7 @@ static const struct hw_sequencer_funcs dcn301_funcs = {
.get_hw_state = dcn10_get_hw_state,
.clear_status_bits = dcn10_clear_status_bits,
.wait_for_mpcc_disconnect = dcn10_wait_for_mpcc_disconnect,
+ .edp_backlight_control = dce110_edp_backlight_control,
.edp_power_control = dce110_edp_power_control,
.edp_wait_for_hpd_ready = dce110_edp_wait_for_hpd_ready,
.set_cursor_position = dcn10_set_cursor_position,
--
2.41.0
Re: [PATCH] drm/amd/display: fix mode scaling (RMX_.*)
On 8/18/23 09:28, Alex Deucher wrote:
On Fri, Aug 18, 2023 at 9:25 AM Hamza Mahfooz wrote:
As made mention of in commit 4a2df0d1f28e ("drm/amd/display: Fixed
non-native modes not lighting up"), we shouldn't call
drm_mode_set_crtcinfo() once the crtc timings have been decided. Since,
it can cause settings to be unintentionally overwritten. So, since
dm_state is never NULL now, we can use old_stream to determine if we
should call drm_mode_set_crtcinfo() because we only need to set the crtc
timing parameters for entirely new streams.
Cc: Harry Wentland
Cc: Rodrigo Siqueira
Fixes: 712237a4a1b4 ("drm/amd/display: Always set crtcinfo from
create_stream_for_sink")
Signed-off-by: Hamza Mahfooz
Does this fix:
https://gitlab.freedesktop.org/drm/amd/-/issues/2783
If so, add a link tag for that.
The issue I'm addressing is specific to the colorspace patches (which
weren't ported to 6.4.y to my knowledge). So, that's probably unrelated.
Alex
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 3b27b7742854..e9aff5014e39 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -6035,7 +6035,7 @@ create_stream_for_sink(struct amdgpu_dm_connector
*aconnector,
if (recalculate_timing)
drm_mode_set_crtcinfo(&saved_mode, 0);
- else
+ else if (!old_stream)
drm_mode_set_crtcinfo(&mode, 0);
/*
--
2.41.0
--
Hamza
[PATCH] drm/amd/display: fix mode scaling (RMX_.*)
As made mention of in commit 4a2df0d1f28e ("drm/amd/display: Fixed
non-native modes not lighting up"), we shouldn't call
drm_mode_set_crtcinfo() once the crtc timings have been decided. Since,
it can cause settings to be unintentionally overwritten. So, since
dm_state is never NULL now, we can use old_stream to determine if we
should call drm_mode_set_crtcinfo() because we only need to set the crtc
timing parameters for entirely new streams.
Cc: Harry Wentland
Cc: Rodrigo Siqueira
Fixes: 712237a4a1b4 ("drm/amd/display: Always set crtcinfo from
create_stream_for_sink")
Signed-off-by: Hamza Mahfooz
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 3b27b7742854..e9aff5014e39 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -6035,7 +6035,7 @@ create_stream_for_sink(struct amdgpu_dm_connector
*aconnector,
if (recalculate_timing)
drm_mode_set_crtcinfo(&saved_mode, 0);
- else
+ else if (!old_stream)
drm_mode_set_crtcinfo(&mode, 0);
/*
--
2.41.0
Re: [PATCH v2] drm/amdgpu: register a dirty framebuffer callback for fbcon
On 8/16/23 01:55, Christian König wrote:
Am 15.08.23 um 19:26 schrieb Hamza Mahfooz:
fbcon requires that we implement &drm_framebuffer_funcs.dirty.
Otherwise, the framebuffer might take a while to flush (which would
manifest as noticeable lag). However, we can't enable this callback for
non-fbcon cases since it might cause too many atomic commits to be made
at once. So, implement amdgpu_dirtyfb() and only enable it for fbcon
framebuffers on devices that support atomic KMS.
Cc: Aurabindo Pillai
Cc: Mario Limonciello
Cc: sta...@vger.kernel.org # 6.1+
Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2519
Signed-off-by: Hamza Mahfooz
---
v2: update variable names
---
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 26 -
1 file changed, 25 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
index d20dd3f852fc..d3b59f99cb7c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
@@ -38,6 +38,8 @@
#include
#include
#include
+#include
+#include
#include
#include
#include
@@ -532,11 +534,29 @@ bool amdgpu_display_ddc_probe(struct
amdgpu_connector *amdgpu_connector,
return true;
}
+static int amdgpu_dirtyfb(struct drm_framebuffer *fb, struct drm_file
*file,
+ unsigned int flags, unsigned int color,
+ struct drm_clip_rect *clips, unsigned int num_clips)
+{
+
+ if (strcmp(fb->comm, "[fbcon]"))
+ return -ENOSYS;
Once more to the v2 of this patch: Tests like those are a pretty big
NO-GO for upstreaming.
On closer inspection it is actually sufficient to check if `file` is
NULL here (since it means that the request isn't from userspace). So, do
you think that would be palatable for upstream?
Regards,
Christian.
+
+ return drm_atomic_helper_dirtyfb(fb, file, flags, color, clips,
+ num_clips);
+}
+
static const struct drm_framebuffer_funcs amdgpu_fb_funcs = {
.destroy = drm_gem_fb_destroy,
.create_handle = drm_gem_fb_create_handle,
};
+static const struct drm_framebuffer_funcs amdgpu_fb_funcs_atomic = {
+ .destroy = drm_gem_fb_destroy,
+ .create_handle = drm_gem_fb_create_handle,
+ .dirty = amdgpu_dirtyfb
+};
+
uint32_t amdgpu_display_supported_domains(struct amdgpu_device *adev,
uint64_t bo_flags)
{
@@ -1139,7 +1159,11 @@ static int
amdgpu_display_gem_fb_verify_and_init(struct drm_device *dev,
if (ret)
goto err;
- ret = drm_framebuffer_init(dev, &rfb->base, &amdgpu_fb_funcs);
+ if (drm_drv_uses_atomic_modeset(dev))
+ ret = drm_framebuffer_init(dev, &rfb->base,
+ &amdgpu_fb_funcs_atomic);
+ else
+ ret = drm_framebuffer_init(dev, &rfb->base, &amdgpu_fb_funcs);
if (ret)
goto err;
--
Hamza
[PATCH v2] drm/amdgpu: register a dirty framebuffer callback for fbcon
fbcon requires that we implement &drm_framebuffer_funcs.dirty.
Otherwise, the framebuffer might take a while to flush (which would
manifest as noticeable lag). However, we can't enable this callback for
non-fbcon cases since it might cause too many atomic commits to be made
at once. So, implement amdgpu_dirtyfb() and only enable it for fbcon
framebuffers on devices that support atomic KMS.
Cc: Aurabindo Pillai
Cc: Mario Limonciello
Cc: sta...@vger.kernel.org # 6.1+
Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2519
Signed-off-by: Hamza Mahfooz
---
v2: update variable names
---
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 26 -
1 file changed, 25 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
index d20dd3f852fc..d3b59f99cb7c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
@@ -38,6 +38,8 @@
#include
#include
#include
+#include
+#include
#include
#include
#include
@@ -532,11 +534,29 @@ bool amdgpu_display_ddc_probe(struct amdgpu_connector
*amdgpu_connector,
return true;
}
+static int amdgpu_dirtyfb(struct drm_framebuffer *fb, struct drm_file *file,
+ unsigned int flags, unsigned int color,
+ struct drm_clip_rect *clips, unsigned int num_clips)
+{
+
+ if (strcmp(fb->comm, "[fbcon]"))
+ return -ENOSYS;
+
+ return drm_atomic_helper_dirtyfb(fb, file, flags, color, clips,
+num_clips);
+}
+
static const struct drm_framebuffer_funcs amdgpu_fb_funcs = {
.destroy = drm_gem_fb_destroy,
.create_handle = drm_gem_fb_create_handle,
};
+static const struct drm_framebuffer_funcs amdgpu_fb_funcs_atomic = {
+ .destroy = drm_gem_fb_destroy,
+ .create_handle = drm_gem_fb_create_handle,
+ .dirty = amdgpu_dirtyfb
+};
+
uint32_t amdgpu_display_supported_domains(struct amdgpu_device *adev,
uint64_t bo_flags)
{
@@ -1139,7 +1159,11 @@ static int amdgpu_display_gem_fb_verify_and_init(struct
drm_device *dev,
if (ret)
goto err;
- ret = drm_framebuffer_init(dev, &rfb->base, &amdgpu_fb_funcs);
+ if (drm_drv_uses_atomic_modeset(dev))
+ ret = drm_framebuffer_init(dev, &rfb->base,
+ &amdgpu_fb_funcs_atomic);
+ else
+ ret = drm_framebuffer_init(dev, &rfb->base, &amdgpu_fb_funcs);
if (ret)
goto err;
--
2.41.0
[PATCH] drm/amdgpu: register a dirty framebuffer callback for fbcon
fbcon requires that we implement &drm_framebuffer_funcs.dirty.
Otherwise, the framebuffer might take awhile to flush (which would
manifest as noticeable lag). However, we can't enable this callback for
non-fbcon cases since it might cause too many atomic commits to be made
at once. So, implement amdgpu_dirtyfb() and only enable it for fbcon
framebuffers on devices that support atomic KMS.
Cc: Aurabindo Pillai
Cc: Mario Limonciello
Cc: sta...@vger.kernel.org # 6.1+
Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2519
Signed-off-by: Hamza Mahfooz
---
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 26 -
1 file changed, 25 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
index d20dd3f852fc..743db9aee68c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
@@ -38,6 +38,8 @@
#include
#include
#include
+#include
+#include
#include
#include
#include
@@ -532,11 +534,29 @@ bool amdgpu_display_ddc_probe(struct amdgpu_connector
*amdgpu_connector,
return true;
}
+static int amdgpu_dirtyfb(struct drm_framebuffer *fb, struct drm_file *file,
+ unsigned int flags, unsigned int color,
+ struct drm_clip_rect *clips, unsigned int num_clips)
+{
+
+ if (strcmp(framebuffer->comm, "[fbcon]"))
+ return -ENOSYS;
+
+ return drm_atomic_helper_dirtyfb(framebuffer, file_priv, flags, color,
+clips, num_clips);
+}
+
static const struct drm_framebuffer_funcs amdgpu_fb_funcs = {
.destroy = drm_gem_fb_destroy,
.create_handle = drm_gem_fb_create_handle,
};
+static const struct drm_framebuffer_funcs amdgpu_fb_funcs_atomic = {
+ .destroy = drm_gem_fb_destroy,
+ .create_handle = drm_gem_fb_create_handle,
+ .dirty = amdgpu_dirtyfb
+};
+
uint32_t amdgpu_display_supported_domains(struct amdgpu_device *adev,
uint64_t bo_flags)
{
@@ -1139,7 +1159,11 @@ static int amdgpu_display_gem_fb_verify_and_init(struct
drm_device *dev,
if (ret)
goto err;
- ret = drm_framebuffer_init(dev, &rfb->base, &amdgpu_fb_funcs);
+ if (drm_drv_uses_atomic_modeset(dev))
+ ret = drm_framebuffer_init(dev, &rfb->base,
+ &amdgpu_fb_funcs_atomic);
+ else
+ ret = drm_framebuffer_init(dev, &rfb->base, &amdgpu_fb_funcs);
if (ret)
goto err;
--
2.41.0
[PATCH v2] drm/amd/display: ensure async flips are only accepted for fast updates
We should be checking to see if async flips are supported in
amdgpu_dm_atomic_check() (i.e. not dm_crtc_helper_atomic_check()). Also,
async flipping isn't supported if a plane's framebuffer changes memory
domains during an atomic commit. So, move the check from
dm_crtc_helper_atomic_check() to amdgpu_dm_atomic_check() and check if
the memory domain has changed in amdgpu_dm_atomic_check().
Cc: sta...@vger.kernel.org
Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2733
Fixes: 3f86b60691e6 ("drm/amd/display: only accept async flips for fast
updates")
Signed-off-by: Hamza Mahfooz
---
v2: link issue and revert back to the old way of setting update_type.
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 24 ---
.../amd/display/amdgpu_dm/amdgpu_dm_crtc.c| 12 --
2 files changed, 21 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 32fb551862b0..1d3afab5bc85 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -8086,10 +8086,12 @@ static void amdgpu_dm_commit_planes(struct
drm_atomic_state *state,
* fast updates.
*/
if (crtc->state->async_flip &&
- acrtc_state->update_type != UPDATE_TYPE_FAST)
+ (acrtc_state->update_type != UPDATE_TYPE_FAST ||
+get_mem_type(old_plane_state->fb) != get_mem_type(fb)))
drm_warn_once(state->dev,
"[PLANE:%d:%s] async flip with non-fast
update\n",
plane->base.id, plane->name);
+
bundle->flip_addrs[planes_count].flip_immediate =
crtc->state->async_flip &&
acrtc_state->update_type == UPDATE_TYPE_FAST &&
@@ -10050,6 +10052,11 @@ static int amdgpu_dm_atomic_check(struct drm_device
*dev,
/* Remove exiting planes if they are modified */
for_each_oldnew_plane_in_state_reverse(state, plane, old_plane_state,
new_plane_state, i) {
+ if (old_plane_state->fb && new_plane_state->fb &&
+ get_mem_type(old_plane_state->fb) !=
+ get_mem_type(new_plane_state->fb))
+ lock_and_validation_needed = true;
+
ret = dm_update_plane_state(dc, state, plane,
old_plane_state,
new_plane_state,
@@ -10297,9 +10304,20 @@ static int amdgpu_dm_atomic_check(struct drm_device
*dev,
struct dm_crtc_state *dm_new_crtc_state =
to_dm_crtc_state(new_crtc_state);
+ /*
+* Only allow async flips for fast updates that don't change
+* the FB pitch, the DCC state, rotation, etc.
+*/
+ if (new_crtc_state->async_flip && lock_and_validation_needed) {
+ drm_dbg_atomic(crtc->dev,
+ "[CRTC:%d:%s] async flips are only
supported for fast updates\n",
+ crtc->base.id, crtc->name);
+ ret = -EINVAL;
+ goto fail;
+ }
+
dm_new_crtc_state->update_type = lock_and_validation_needed ?
-UPDATE_TYPE_FULL :
-UPDATE_TYPE_FAST;
+ UPDATE_TYPE_FULL : UPDATE_TYPE_FAST;
}
/* Must be success */
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crtc.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crtc.c
index 30d4c6fd95f5..440fc0869a34 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crtc.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crtc.c
@@ -398,18 +398,6 @@ static int dm_crtc_helper_atomic_check(struct drm_crtc
*crtc,
return -EINVAL;
}
- /*
-* Only allow async flips for fast updates that don't change the FB
-* pitch, the DCC state, rotation, etc.
-*/
- if (crtc_state->async_flip &&
- dm_crtc_state->update_type != UPDATE_TYPE_FAST) {
- drm_dbg_atomic(crtc->dev,
- "[CRTC:%d:%s] async flips are only supported for
fast updates\n",
- crtc->base.id, crtc->name);
- return -EINVAL;
- }
-
/* In some use cases, like reset, no stream is attached */
if (!dm_crtc_state->stream)
return 0;
--
2.41.0
[PATCH] drm/amd/display: ensure async flips are only accepted for fast updates
We should be checking to see if async flips are supported in
amdgpu_dm_atomic_check() (i.e. not dm_crtc_helper_atomic_check()). Also,
async flipping isn't supported if a plane's framebuffer changes memory
domains during an atomic commit. So, move the check from
dm_crtc_helper_atomic_check() to amdgpu_dm_atomic_check() and check if
the memory domain has changed in amdgpu_dm_atomic_check().
Cc: sta...@vger.kernel.org
Fixes: 3f86b60691e6 ("drm/amd/display: only accept async flips for fast
updates")
Tested-by: Marcus Seyfarth
Signed-off-by: Hamza Mahfooz
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 25 ---
.../amd/display/amdgpu_dm/amdgpu_dm_crtc.c| 12 -
2 files changed, 21 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 32fb551862b0..e561d99b3f40 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -8086,7 +8086,8 @@ static void amdgpu_dm_commit_planes(struct
drm_atomic_state *state,
* fast updates.
*/
if (crtc->state->async_flip &&
- acrtc_state->update_type != UPDATE_TYPE_FAST)
+ (acrtc_state->update_type != UPDATE_TYPE_FAST ||
+get_mem_type(old_plane_state->fb) != get_mem_type(fb)))
drm_warn_once(state->dev,
"[PLANE:%d:%s] async flip with non-fast
update\n",
plane->base.id, plane->name);
@@ -10050,12 +10051,18 @@ static int amdgpu_dm_atomic_check(struct drm_device
*dev,
/* Remove exiting planes if they are modified */
for_each_oldnew_plane_in_state_reverse(state, plane, old_plane_state,
new_plane_state, i) {
+ if (old_plane_state->fb && new_plane_state->fb &&
+ get_mem_type(old_plane_state->fb) !=
+ get_mem_type(new_plane_state->fb))
+ lock_and_validation_needed = true;
+
ret = dm_update_plane_state(dc, state, plane,
old_plane_state,
new_plane_state,
false,
&lock_and_validation_needed,
&is_top_most_overlay);
+
if (ret) {
DRM_DEBUG_DRIVER("dm_update_plane_state() failed\n");
goto fail;
@@ -10069,6 +10076,7 @@ static int amdgpu_dm_atomic_check(struct drm_device
*dev,
new_crtc_state,
false,
&lock_and_validation_needed);
+
if (ret) {
DRM_DEBUG_DRIVER("DISABLE: dm_update_crtc_state()
failed\n");
goto fail;
@@ -10297,9 +10305,18 @@ static int amdgpu_dm_atomic_check(struct drm_device
*dev,
struct dm_crtc_state *dm_new_crtc_state =
to_dm_crtc_state(new_crtc_state);
- dm_new_crtc_state->update_type = lock_and_validation_needed ?
-UPDATE_TYPE_FULL :
-UPDATE_TYPE_FAST;
+ /*
+* Only allow async flips for fast updates that don't change
+* the FB pitch, the DCC state, rotation, etc.
+*/
+ if (new_crtc_state->async_flip && lock_and_validation_needed) {
+ drm_dbg_atomic(crtc->dev,
+ "[CRTC:%d:%s] async flips are only
supported for fast updates\n",
+ crtc->base.id, crtc->name);
+ ret = -EINVAL;
+ goto fail;
+ } else
+ dm_new_crtc_state->update_type = UPDATE_TYPE_FAST;
}
/* Must be success */
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crtc.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crtc.c
index 30d4c6fd95f5..440fc0869a34 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crtc.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crtc.c
@@ -398,18 +398,6 @@ static int dm_crtc_helper_atomic_check(struct drm_crtc
*crtc,
return -EINVAL;
}
- /*
-* Only allow async flips for fast updates that don't change the FB
-* pitch, the DCC state, rotation, etc.
-*/
- if (crtc_state->async_flip &&
- dm_crtc_
