Re: [PATCH 1/2] drm/amdgpu: drop pm_sysfs_en flag from amdgpu_device structure
Am 10.03.23 um 06:03 schrieb Guchun Chen:
pm_sysfs_en is overlapped with pm.sysfs_initialized, so drop it
for simplifying code(no functional change).
Signed-off-by: Guchun Chen
Acked-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 1 -
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 9 +++--
2 files changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 164141bc8b4a..386729cc45d4 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -1023,7 +1023,6 @@ struct amdgpu_device {
boolin_runpm;
boolhas_pr3;
- boolpm_sysfs_en;
boolucode_sysfs_en;
boolpsp_sysfs_en;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index da5b0258a237..41ef3368556b 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -3864,11 +3864,8 @@ int amdgpu_device_init(struct amdgpu_device *adev,
adev->mm_stats.log2_max_MBps = ilog2(max(1u, max_MBps));
r = amdgpu_pm_sysfs_init(adev);
- if (r) {
- adev->pm_sysfs_en = false;
- DRM_ERROR("registering pm debugfs failed (%d).\n", r);
- } else
- adev->pm_sysfs_en = true;
+ if (r)
+ DRM_ERROR("registering pm sysfs failed (%d).\n", r);
r = amdgpu_ucode_sysfs_init(adev);
if (r) {
@@ -4011,7 +4008,7 @@ void amdgpu_device_fini_hw(struct amdgpu_device *adev)
if (adev->mman.initialized)
drain_workqueue(adev->mman.bdev.wq);
- if (adev->pm_sysfs_en)
+ if (adev->pm.sysfs_initialized)
amdgpu_pm_sysfs_fini(adev);
if (adev->ucode_sysfs_en)
amdgpu_ucode_sysfs_fini(adev);
Re: [PATCH 2/2] drm/amdgpu: use drm_device pointer directly rather than convert again
Am 10.03.23 um 06:04 schrieb Guchun Chen: The convert from adev is redundant. Signed-off-by: Guchun Chen Reviewed-by: Christian König --- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c index 41ef3368556b..2937912b7757 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c @@ -5575,7 +5575,7 @@ int amdgpu_device_baco_enter(struct drm_device *dev) struct amdgpu_device *adev = drm_to_adev(dev); struct amdgpu_ras *ras = amdgpu_ras_get_context(adev); - if (!amdgpu_device_supports_baco(adev_to_drm(adev))) + if (!amdgpu_device_supports_baco(dev)) return -ENOTSUPP; if (ras && adev->ras_enabled && @@ -5591,7 +5591,7 @@ int amdgpu_device_baco_exit(struct drm_device *dev) struct amdgpu_ras *ras = amdgpu_ras_get_context(adev); int ret = 0; - if (!amdgpu_device_supports_baco(adev_to_drm(adev))) + if (!amdgpu_device_supports_baco(dev)) return -ENOTSUPP; ret = amdgpu_dpm_baco_exit(adev);
Re: [PATCH] amd/display/debugfs: add sysfs entry to read PSR residency from firmware
On 3/10/2023 12:00 PM, S, Shirish wrote:
On 3/8/2023 11:52 PM, Hamza Mahfooz wrote:
On 3/8/23 02:10, Shirish S wrote:
[Why]
Currently there aren't any methods to determine PSR state residency.
[How]
create a sysfs entry for reading residency and internally hook it up
to existing functionality of reading PSR residency from firmware.
Signed-off-by: Shirish S
---
.../amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 19
+++
1 file changed, 19 insertions(+)
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 abf7895d1608..8ff2802db5b5 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
@@ -27,6 +27,7 @@
#include
#include "dc.h"
+#include "dc_link.h"
Please drop this include, the relevant function should already be
accessible from dc.h.
Good catch. Removed and respun the patch
(https://patchwork.freedesktop.org/patch/526211/)
Pls review.
Regards,
Shirish S
Well, the code structure has been changed now since : "0078c924e733
drm/amd/display: move eDP panel control logic to link_edp_panel_control"
Now "dc.h" no more includes "link.h".
#include "amdgpu.h"
#include "amdgpu_dm.h"
#include "amdgpu_dm_debugfs.h"
@@ -2793,6 +2794,22 @@ static int psr_get(void *data, u64 *val)
return 0;
}
+/*
+ * Read PSR state residency
+ */
+static int psr_read_residency(void *data, u64 *val)
+{
+ struct amdgpu_dm_connector *connector = data;
+ struct dc_link *link = connector->dc_link;
+ u32 residency;
+
+ dc_link_get_psr_residency(link, );
Did you mean to use link_get_psr_residency() here?
Yes, my code was a bit older, have incorporated final changes in new
patch: https://patchwork.freedesktop.org/patch/526213/
Pls review.
Regards,
Shirish S
+
+ *val = (u64)residency;
+
+ return 0;
+}
+
/*
* Set dmcub trace event IRQ enable or disable.
* Usage to enable dmcub trace event IRQ: echo 1 >
/sys/kernel/debug/dri/0/amdgpu_dm_dmcub_trace_event_en
@@ -2828,6 +2845,7 @@
DEFINE_DEBUGFS_ATTRIBUTE(dmcub_trace_event_state_fops,
dmcub_trace_event_state_g
dmcub_trace_event_state_set, "%llu\n");
DEFINE_DEBUGFS_ATTRIBUTE(psr_fops, psr_get, NULL, "%llu\n");
+DEFINE_DEBUGFS_ATTRIBUTE(psr_residency_fops, psr_read_residency,
NULL, "%llu\n");
DEFINE_SHOW_ATTRIBUTE(current_backlight);
DEFINE_SHOW_ATTRIBUTE(target_backlight);
@@ -2991,6 +3009,7 @@ void connector_debugfs_init(struct
amdgpu_dm_connector *connector)
if (connector->base.connector_type == DRM_MODE_CONNECTOR_eDP) {
debugfs_create_file_unsafe("psr_capability", 0444, dir,
connector, _capability_fops);
debugfs_create_file_unsafe("psr_state", 0444, dir,
connector, _fops);
+ debugfs_create_file_unsafe("psr_residency", 0444, dir,
connector, _residency_fops);
debugfs_create_file("amdgpu_current_backlight_pwm", 0444,
dir, connector,
_backlight_fops);
debugfs_create_file("amdgpu_target_backlight_pwm", 0444,
dir, connector,
[PATCH] amd/display/debugfs: add sysfs entry to read PSR residency from firmware
[Why]
Currently there aren't any methods to determine PSR state residency.
[How]
create a sysfs entry for reading residency and internally hook it up
to existing functionality of reading PSR residency from firmware.
Signed-off-by: Shirish S
---
.../amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 19 +++
1 file changed, 19 insertions(+)
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 abf7895d1608..d8a5cde2b06f 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
@@ -35,6 +35,7 @@
#include "resource.h"
#include "dsc.h"
#include "link_hwss.h"
+#include "link.h"
#include "dc/dc_dmub_srv.h"
#include "link/protocols/link_dp_capability.h"
@@ -2793,6 +2794,22 @@ static int psr_get(void *data, u64 *val)
return 0;
}
+/*
+ * Read PSR state residency
+ */
+static int psr_read_residency(void *data, u64 *val)
+{
+ struct amdgpu_dm_connector *connector = data;
+ struct dc_link *link = connector->dc_link;
+ u32 residency;
+
+ link_get_psr_residency(link, );
+
+ *val = (u64)residency;
+
+ return 0;
+}
+
/*
* Set dmcub trace event IRQ enable or disable.
* Usage to enable dmcub trace event IRQ: echo 1 >
/sys/kernel/debug/dri/0/amdgpu_dm_dmcub_trace_event_en
@@ -2828,6 +2845,7 @@ DEFINE_DEBUGFS_ATTRIBUTE(dmcub_trace_event_state_fops,
dmcub_trace_event_state_g
dmcub_trace_event_state_set, "%llu\n");
DEFINE_DEBUGFS_ATTRIBUTE(psr_fops, psr_get, NULL, "%llu\n");
+DEFINE_DEBUGFS_ATTRIBUTE(psr_residency_fops, psr_read_residency, NULL,
"%llu\n");
DEFINE_SHOW_ATTRIBUTE(current_backlight);
DEFINE_SHOW_ATTRIBUTE(target_backlight);
@@ -2991,6 +3009,7 @@ void connector_debugfs_init(struct amdgpu_dm_connector
*connector)
if (connector->base.connector_type == DRM_MODE_CONNECTOR_eDP) {
debugfs_create_file_unsafe("psr_capability", 0444, dir,
connector, _capability_fops);
debugfs_create_file_unsafe("psr_state", 0444, dir, connector,
_fops);
+ debugfs_create_file_unsafe("psr_residency", 0444, dir,
connector, _residency_fops);
debugfs_create_file("amdgpu_current_backlight_pwm", 0444, dir,
connector,
_backlight_fops);
debugfs_create_file("amdgpu_target_backlight_pwm", 0444, dir,
connector,
--
2.17.1
Re: [PATCH] amd/display/debugfs: add sysfs entry to read PSR residency from firmware
On 3/8/2023 11:52 PM, Hamza Mahfooz wrote:
On 3/8/23 02:10, Shirish S wrote:
[Why]
Currently there aren't any methods to determine PSR state residency.
[How]
create a sysfs entry for reading residency and internally hook it up
to existing functionality of reading PSR residency from firmware.
Signed-off-by: Shirish S
---
.../amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 19 +++
1 file changed, 19 insertions(+)
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 abf7895d1608..8ff2802db5b5 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
@@ -27,6 +27,7 @@
#include
#include "dc.h"
+#include "dc_link.h"
Please drop this include, the relevant function should already be
accessible from dc.h.
Good catch. Removed and respun the patch
(https://patchwork.freedesktop.org/patch/526211/)
Pls review.
Regards,
Shirish S
#include "amdgpu.h"
#include "amdgpu_dm.h"
#include "amdgpu_dm_debugfs.h"
@@ -2793,6 +2794,22 @@ static int psr_get(void *data, u64 *val)
return 0;
}
+/*
+ * Read PSR state residency
+ */
+static int psr_read_residency(void *data, u64 *val)
+{
+ struct amdgpu_dm_connector *connector = data;
+ struct dc_link *link = connector->dc_link;
+ u32 residency;
+
+ dc_link_get_psr_residency(link, );
Did you mean to use link_get_psr_residency() here?
+
+ *val = (u64)residency;
+
+ return 0;
+}
+
/*
* Set dmcub trace event IRQ enable or disable.
* Usage to enable dmcub trace event IRQ: echo 1 >
/sys/kernel/debug/dri/0/amdgpu_dm_dmcub_trace_event_en
@@ -2828,6 +2845,7 @@
DEFINE_DEBUGFS_ATTRIBUTE(dmcub_trace_event_state_fops,
dmcub_trace_event_state_g
dmcub_trace_event_state_set, "%llu\n");
DEFINE_DEBUGFS_ATTRIBUTE(psr_fops, psr_get, NULL, "%llu\n");
+DEFINE_DEBUGFS_ATTRIBUTE(psr_residency_fops, psr_read_residency,
NULL, "%llu\n");
DEFINE_SHOW_ATTRIBUTE(current_backlight);
DEFINE_SHOW_ATTRIBUTE(target_backlight);
@@ -2991,6 +3009,7 @@ void connector_debugfs_init(struct
amdgpu_dm_connector *connector)
if (connector->base.connector_type == DRM_MODE_CONNECTOR_eDP) {
debugfs_create_file_unsafe("psr_capability", 0444, dir,
connector, _capability_fops);
debugfs_create_file_unsafe("psr_state", 0444, dir,
connector, _fops);
+ debugfs_create_file_unsafe("psr_residency", 0444, dir,
connector, _residency_fops);
debugfs_create_file("amdgpu_current_backlight_pwm", 0444,
dir, connector,
_backlight_fops);
debugfs_create_file("amdgpu_target_backlight_pwm", 0444,
dir, connector,
[PATCH] amd/display/debugfs: add sysfs entry to read PSR residency from firmware
[Why]
Currently there aren't any methods to determine PSR state residency.
[How]
create a sysfs entry for reading residency and internally hook it up
to existing functionality of reading PSR residency from firmware.
Signed-off-by: Shirish S
---
.../amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 18 ++
1 file changed, 18 insertions(+)
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 abf7895d1608..6dfd4cb42949 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
@@ -2793,6 +2793,22 @@ static int psr_get(void *data, u64 *val)
return 0;
}
+/*
+ * Read PSR state residency
+ */
+static int psr_read_residency(void *data, u64 *val)
+{
+ struct amdgpu_dm_connector *connector = data;
+ struct dc_link *link = connector->dc_link;
+ u32 residency;
+
+ dc_link_get_psr_residency(link, );
+
+ *val = (u64)residency;
+
+ return 0;
+}
+
/*
* Set dmcub trace event IRQ enable or disable.
* Usage to enable dmcub trace event IRQ: echo 1 >
/sys/kernel/debug/dri/0/amdgpu_dm_dmcub_trace_event_en
@@ -2828,6 +2844,7 @@ DEFINE_DEBUGFS_ATTRIBUTE(dmcub_trace_event_state_fops,
dmcub_trace_event_state_g
dmcub_trace_event_state_set, "%llu\n");
DEFINE_DEBUGFS_ATTRIBUTE(psr_fops, psr_get, NULL, "%llu\n");
+DEFINE_DEBUGFS_ATTRIBUTE(psr_residency_fops, psr_read_residency, NULL,
"%llu\n");
DEFINE_SHOW_ATTRIBUTE(current_backlight);
DEFINE_SHOW_ATTRIBUTE(target_backlight);
@@ -2991,6 +3008,7 @@ void connector_debugfs_init(struct amdgpu_dm_connector
*connector)
if (connector->base.connector_type == DRM_MODE_CONNECTOR_eDP) {
debugfs_create_file_unsafe("psr_capability", 0444, dir,
connector, _capability_fops);
debugfs_create_file_unsafe("psr_state", 0444, dir, connector,
_fops);
+ debugfs_create_file_unsafe("psr_residency", 0444, dir,
connector, _residency_fops);
debugfs_create_file("amdgpu_current_backlight_pwm", 0444, dir,
connector,
_backlight_fops);
debugfs_create_file("amdgpu_target_backlight_pwm", 0444, dir,
connector,
--
2.17.1
[PATCH 2/2] drm/amdgpu: use drm_device pointer directly rather than convert again
The convert from adev is redundant. Signed-off-by: Guchun Chen --- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c index 41ef3368556b..2937912b7757 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c @@ -5575,7 +5575,7 @@ int amdgpu_device_baco_enter(struct drm_device *dev) struct amdgpu_device *adev = drm_to_adev(dev); struct amdgpu_ras *ras = amdgpu_ras_get_context(adev); - if (!amdgpu_device_supports_baco(adev_to_drm(adev))) + if (!amdgpu_device_supports_baco(dev)) return -ENOTSUPP; if (ras && adev->ras_enabled && @@ -5591,7 +5591,7 @@ int amdgpu_device_baco_exit(struct drm_device *dev) struct amdgpu_ras *ras = amdgpu_ras_get_context(adev); int ret = 0; - if (!amdgpu_device_supports_baco(adev_to_drm(adev))) + if (!amdgpu_device_supports_baco(dev)) return -ENOTSUPP; ret = amdgpu_dpm_baco_exit(adev); -- 2.25.1
[PATCH 1/2] drm/amdgpu: drop pm_sysfs_en flag from amdgpu_device structure
pm_sysfs_en is overlapped with pm.sysfs_initialized, so drop it
for simplifying code(no functional change).
Signed-off-by: Guchun Chen
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 1 -
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 9 +++--
2 files changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 164141bc8b4a..386729cc45d4 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -1023,7 +1023,6 @@ struct amdgpu_device {
boolin_runpm;
boolhas_pr3;
- boolpm_sysfs_en;
boolucode_sysfs_en;
boolpsp_sysfs_en;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index da5b0258a237..41ef3368556b 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -3864,11 +3864,8 @@ int amdgpu_device_init(struct amdgpu_device *adev,
adev->mm_stats.log2_max_MBps = ilog2(max(1u, max_MBps));
r = amdgpu_pm_sysfs_init(adev);
- if (r) {
- adev->pm_sysfs_en = false;
- DRM_ERROR("registering pm debugfs failed (%d).\n", r);
- } else
- adev->pm_sysfs_en = true;
+ if (r)
+ DRM_ERROR("registering pm sysfs failed (%d).\n", r);
r = amdgpu_ucode_sysfs_init(adev);
if (r) {
@@ -4011,7 +4008,7 @@ void amdgpu_device_fini_hw(struct amdgpu_device *adev)
if (adev->mman.initialized)
drain_workqueue(adev->mman.bdev.wq);
- if (adev->pm_sysfs_en)
+ if (adev->pm.sysfs_initialized)
amdgpu_pm_sysfs_fini(adev);
if (adev->ucode_sysfs_en)
amdgpu_ucode_sysfs_fini(adev);
--
2.25.1
RE: [PATCH] drm/amdgpu/nv: fix codec array for SR_IOV
Acked-by: Guchun Chen
> -Original Message-
> From: amd-gfx On Behalf Of Alex
> Deucher
> Sent: Friday, March 10, 2023 11:14 AM
> To: Deucher, Alexander
> Cc: Jiapeng Chong ; Abaci Robot
> ; amd-gfx@lists.freedesktop.org
> Subject: Re: [PATCH] drm/amdgpu/nv: fix codec array for SR_IOV
>
> Ping?
>
> On Wed, Mar 8, 2023 at 10:51 PM Alex Deucher
> wrote:
> >
> > Copy paste error.
> >
> > Fixes: 384334120b66 ("drm/amdgpu/nv: don't expose AV1 if VCN0 is
> > harvested")
> > Reported-by: Abaci Robot
> > Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=4454
> > Cc: Jiapeng Chong
> > Signed-off-by: Alex Deucher
> > ---
> > drivers/gpu/drm/amd/amdgpu/nv.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/nv.c
> > b/drivers/gpu/drm/amd/amdgpu/nv.c index 855d390c41de..22e25ca285f8
> > 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/nv.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/nv.c
> > @@ -1055,8 +1055,8 @@ static int nv_common_late_init(void *handle)
> > amdgpu_virt_update_sriov_video_codec(adev,
> >
> > sriov_sc_video_codecs_encode_array,
> >
> ARRAY_SIZE(sriov_sc_video_codecs_encode_array),
> > -
> sriov_sc_video_codecs_decode_array_vcn1,
> > -
> ARRAY_SIZE(sriov_sc_video_codecs_decode_array_vcn1));
> > +
> sriov_sc_video_codecs_decode_array_vcn0,
> > +
> > + ARRAY_SIZE(sriov_sc_video_codecs_decode_array_vcn0));
> > }
> > }
> >
> > --
> > 2.39.2
> >
Re: [PATCH 2/2] drm/amd/pm: Fix navi10 incorrect OD volage after resume
On Thu, Mar 9, 2023 at 6:54 AM Lazar, Lijo wrote:
>
>
>
> On 3/9/2023 8:11 AM, Quan, Evan wrote:
> > [AMD Official Use Only - General]
> >
> >
> >
> >> -Original Message-
> >> From: Deucher, Alexander
> >> Sent: Wednesday, March 8, 2023 11:20 PM
> >> To: amd-gfx@lists.freedesktop.org
> >> Cc: Deucher, Alexander ; Błażej Szczygieł
> >> ; Quan, Evan
> >> Subject: [PATCH 2/2] drm/amd/pm: Fix navi10 incorrect OD volage after
> >> resume
> >>
> >> Always setup overdrive tables after resume. Preserve only some
> >> user-defined settings in user_overdrive_table if they're set.
> >>
> >> Copy restored user_overdrive_table into od_table to get correct
> >> values.
> >>
> >> On cold boot, BTC was triggered and GfxVfCurve was calibrated. We
> >> got VfCurve settings (a). On resuming back, BTC will be triggered
> >> again and GfxVfCurve will be recalibrated. VfCurve settings (b)
> >> got may be different from those of cold boot. So if we reuse
> >> those VfCurve settings (a) got on cold boot on suspend, we can
> >> run into discrepencies.
> >>
> >> Based on the sienna cichlid patch from Błażej Szczygieł
> >>
> >>
> >> Cc: Błażej Szczygieł
> >> Cc: Evan Quan
> >> Signed-off-by: Alex Deucher
> >> ---
> >> .../gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c | 47
> >> +++
> >> 1 file changed, 37 insertions(+), 10 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c
> >> b/drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c
> >> index 95da6dd1cc65..68201d8e1c72 100644
> >> --- a/drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c
> >> +++ b/drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c
> >> @@ -2510,16 +2510,9 @@ static int navi10_set_default_od_settings(struct
> >> smu_context *smu)
> >> (OverDriveTable_t *)smu->smu_table.boot_overdrive_table;
> >> OverDriveTable_t *user_od_table =
> >> (OverDriveTable_t *)smu->smu_table.user_overdrive_table;
> >> +OverDriveTable_t user_od_table_bak;
> >> int ret = 0;
> >>
> >> -/*
> >> - * For S3/S4/Runpm resume, no need to setup those overdrive
> >> tables again as
> >> - * - either they already have the default OD settings got during
> >> cold
> >> bootup
> >> - * - or they have some user customized OD settings which cannot be
> >> overwritten
> >> - */
> >> -if (smu->adev->in_suspend)
> >> -return 0;
> >> -
> >> ret = smu_cmn_update_table(smu, SMU_TABLE_OVERDRIVE, 0,
> >> (void *)boot_od_table, false);
> >> if (ret) {
> >> dev_err(smu->adev->dev, "Failed to get overdrive table!\n");
> >> @@ -2553,7 +2546,27 @@ static int navi10_set_default_od_settings(struct
> >> smu_context *smu)
> >> navi10_dump_od_table(smu, boot_od_table);
> >>
> >> memcpy(od_table, boot_od_table, sizeof(OverDriveTable_t));
> >> -memcpy(user_od_table, boot_od_table, sizeof(OverDriveTable_t));
> >> +
> >> +/*
> >> + * For S3/S4/Runpm resume, we need to setup those overdrive
> >> tables again,
> >> + * but we have to preserve user defined values in "user_od_table".
> >> + */
> >> +if (!smu->adev->in_suspend) {
> >> +memcpy(user_od_table, boot_od_table,
> >> sizeof(OverDriveTable_t));
> >> +smu->user_dpm_profile.user_od = false;
> >> +} else if (smu->user_dpm_profile.user_od) {
> >> +memcpy(_od_table_bak, user_od_table,
> >> sizeof(OverDriveTable_t));
> >> +memcpy(user_od_table, boot_od_table,
> >> sizeof(OverDriveTable_t));
> >> +user_od_table->GfxclkFmin =
> >> user_od_table_bak.GfxclkFmin;
> >> +user_od_table->GfxclkFmax =
> >> user_od_table_bak.GfxclkFmax;
> >> +user_od_table->UclkFmax = user_od_table_bak.UclkFmax;
> >> +user_od_table->GfxclkFreq1 =
> >> user_od_table_bak.GfxclkFreq1;
> >> +user_od_table->GfxclkVolt1 =
> >> user_od_table_bak.GfxclkVolt1;
> >> +user_od_table->GfxclkFreq2 =
> >> user_od_table_bak.GfxclkFreq2;
> >> +user_od_table->GfxclkVolt2 =
> >> user_od_table_bak.GfxclkVolt2;
> >> +user_od_table->GfxclkFreq3 =
> >> user_od_table_bak.GfxclkFreq3;
> >> +user_od_table->GfxclkVolt3 =
> >> user_od_table_bak.GfxclkVolt3;
> >> +}
> > Thing is a little tricky for navi10...
> > For navi2x, the vfcurve settings(GfxVfCurve.a, GfxVfCurve.b, GfxVfCurve.c)
> > are not configurable by user. We do not expose them to user.
> > So, we can just load the new vfcurve settings on resuming back without
> > worry about overriding user's settings.
> >
> > Unlike navi2x, user can customize the vfcurve settings(by setting
> > GfxclkFreq/GfxVolt pairs) on navi10. More specifically:
> > - On cold boot, btc was triggered and vfcurve line was calibrated
> > - Driver calculated the target voltage(via
> > navi10_overdrive_get_gfx_clk_base_voltage) for the point
> > frequencies(GfxclkFreq1, GfxclkFreq2, GfxclkFreq3) and expose them to user
> > - e.g. point1
Re: [PATCH] drm/amdgpu/nv: fix codec array for SR_IOV
Ping?
On Wed, Mar 8, 2023 at 10:51 PM Alex Deucher wrote:
>
> Copy paste error.
>
> Fixes: 384334120b66 ("drm/amdgpu/nv: don't expose AV1 if VCN0 is harvested")
> Reported-by: Abaci Robot
> Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=4454
> Cc: Jiapeng Chong
> Signed-off-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/amdgpu/nv.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/nv.c b/drivers/gpu/drm/amd/amdgpu/nv.c
> index 855d390c41de..22e25ca285f8 100644
> --- a/drivers/gpu/drm/amd/amdgpu/nv.c
> +++ b/drivers/gpu/drm/amd/amdgpu/nv.c
> @@ -1055,8 +1055,8 @@ static int nv_common_late_init(void *handle)
> amdgpu_virt_update_sriov_video_codec(adev,
>
> sriov_sc_video_codecs_encode_array,
>
> ARRAY_SIZE(sriov_sc_video_codecs_encode_array),
> -
> sriov_sc_video_codecs_decode_array_vcn1,
> -
> ARRAY_SIZE(sriov_sc_video_codecs_decode_array_vcn1));
> +
> sriov_sc_video_codecs_decode_array_vcn0,
> +
> ARRAY_SIZE(sriov_sc_video_codecs_decode_array_vcn0));
> }
> }
>
> --
> 2.39.2
>
[pull] amdgpu, amdkfd drm-fixes-6.3
Hi Dave, Daniel, Fixes for 6.3. Same pull as yesterday, but drop the KFD patch that caused a regression. The following changes since commit 66305069eb6d17d9190cbcd196f3f7487df47ae8: Merge tag 'drm-misc-fixes-2023-02-23' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes (2023-03-07 05:42:34 +1000) are available in the Git repository at: https://gitlab.freedesktop.org/agd5f/linux.git tags/amd-drm-fixes-6.3-2023-03-09 for you to fetch changes up to 6ce2ea07c5ff0a8188eab0e5cd1f0e4899b36835: drm/amdgpu/soc21: Add video cap query support for VCN_4_0_4 (2023-03-09 22:06:19 -0500) amd-drm-fixes-6.3-2023-03-09: amdgpu: - Misc display fixes - UMC 8.10 fixes - Driver unload fixes - NBIO 7.3.0 fix - Error checking fixes for soc15, nv, soc21 read register interface - Fix video cap query for VCN 4.0.4 amdkfd: - Fix return check in doorbell handling Alex Deucher (3): drm/amdgpu: fix error checking in amdgpu_read_mm_registers for soc15 drm/amdgpu: fix error checking in amdgpu_read_mm_registers for soc21 drm/amdgpu: fix error checking in amdgpu_read_mm_registers for nv Candice Li (2): drm/amdgpu: Support umc node harvest config on umc v8_10 drm/amd/pm: Enable ecc_info table support for smu v13_0_10 Harry Wentland (2): drm/display: Don't block HDR_OUTPUT_METADATA on unknown EOTF drm/connector: print max_requested_bpc in state debugfs Mario Limonciello (1): drm/amd: Fix initialization mistake for NBIO 7.3.0 Shashank Sharma (1): drm/amdgpu: fix return value check in kfd Swapnil Patel (1): drm/amd/display: Update clock table to include highest clock setting Veerabadhran Gopalakrishnan (1): drm/amdgpu/soc21: Add video cap query support for VCN_4_0_4 lyndonli (2): drm/amdgpu: Fix call trace warning and hang when removing amdgpu device drm/amdgpu: Fix the warning info when removing amdgpu device drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c | 10 ++- drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c| 17 + drivers/gpu/drm/amd/amdgpu/amdgpu_umc.h| 7 +- drivers/gpu/drm/amd/amdgpu/gmc_v11_0.c | 1 - drivers/gpu/drm/amd/amdgpu/nbio_v7_2.c | 14 ++-- drivers/gpu/drm/amd/amdgpu/nv.c| 7 +- drivers/gpu/drm/amd/amdgpu/soc15.c | 5 +- drivers/gpu/drm/amd/amdgpu/soc21.c | 8 ++- drivers/gpu/drm/amd/amdgpu/umc_v8_10.h | 4 +- drivers/gpu/drm/amd/amdkfd/kfd_doorbell.c | 2 +- .../drm/amd/display/dc/clk_mgr/dcn301/vg_clk_mgr.c | 19 +- .../gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c | 75 ++ drivers/gpu/drm/display/drm_hdmi_helper.c | 6 +- drivers/gpu/drm/drm_atomic.c | 1 + 15 files changed, 136 insertions(+), 42 deletions(-)
RE: [PATCH v3 2/2] drm/probe_helper: warning on poll_enabled for issue catching
[AMD Official Use Only - General]
Series is acked-by: Evan Quan
> -Original Message-
> From: amd-gfx On Behalf Of
> Guchun Chen
> Sent: Friday, March 10, 2023 9:02 AM
> To: amd-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
> Deucher, Alexander ; Zhang, Hawking
> ; dmitry.barysh...@linaro.org;
> spassw...@web.de; m...@fireburn.co.uk
> Cc: Chen, Guchun
> Subject: [PATCH v3 2/2] drm/probe_helper: warning on poll_enabled for
> issue catching
>
> In order to catch issues in other drivers to ensure proper call sequence of
> polling function.
>
> v2: drop Fixes tag in commit message
>
> Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2411
> Reported-by: Bert Karwatzki
> Suggested-by: Dmitry Baryshkov
> Signed-off-by: Guchun Chen
> ---
> drivers/gpu/drm/drm_probe_helper.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_probe_helper.c
> b/drivers/gpu/drm/drm_probe_helper.c
> index 8127be134c39..85e0e80d4a52 100644
> --- a/drivers/gpu/drm/drm_probe_helper.c
> +++ b/drivers/gpu/drm/drm_probe_helper.c
> @@ -852,6 +852,8 @@ EXPORT_SYMBOL(drm_kms_helper_is_poll_worker);
> */
> void drm_kms_helper_poll_disable(struct drm_device *dev) {
> + WARN_ON(!dev->mode_config.poll_enabled);
> +
> if (dev->mode_config.poll_running)
> drm_kms_helper_disable_hpd(dev);
>
> --
> 2.25.1
[PATCH v3 2/2] drm/probe_helper: warning on poll_enabled for issue catching
In order to catch issues in other drivers to ensure proper call
sequence of polling function.
v2: drop Fixes tag in commit message
Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2411
Reported-by: Bert Karwatzki
Suggested-by: Dmitry Baryshkov
Signed-off-by: Guchun Chen
---
drivers/gpu/drm/drm_probe_helper.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/drm_probe_helper.c
b/drivers/gpu/drm/drm_probe_helper.c
index 8127be134c39..85e0e80d4a52 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@ -852,6 +852,8 @@ EXPORT_SYMBOL(drm_kms_helper_is_poll_worker);
*/
void drm_kms_helper_poll_disable(struct drm_device *dev)
{
+ WARN_ON(!dev->mode_config.poll_enabled);
+
if (dev->mode_config.poll_running)
drm_kms_helper_disable_hpd(dev);
--
2.25.1
[PATCH v3 1/2] drm/amdgpu: move poll enabled/disable into non DC path
Some amd asics having reliable hotplug support don't call
drm_kms_helper_poll_init in driver init sequence. However,
due to the unified suspend/resume path for all asics, because
the output_poll_work->func is not set for these asics, a warning
arrives when suspending.
[ 90.656049]
[ 90.656050] ? console_unlock+0x4d/0x100
[ 90.656053] ? __irq_work_queue_local+0x27/0x60
[ 90.656056] ? irq_work_queue+0x2b/0x50
[ 90.656057] ? __wake_up_klogd+0x40/0x60
[ 90.656059] __cancel_work_timer+0xed/0x180
[ 90.656061] drm_kms_helper_poll_disable.cold+0x1f/0x2c [drm_kms_helper]
[ 90.656072] amdgpu_device_suspend+0x81/0x170 [amdgpu]
[ 90.656180] amdgpu_pmops_runtime_suspend+0xb5/0x1b0 [amdgpu]
[ 90.656269] pci_pm_runtime_suspend+0x61/0x1b0
drm_kms_helper_poll_enable/disable is valid when poll_init is called in
amdgpu code, which is only used in non DC path. So move such codes into
non-DC path code to get rid of such warnings.
v1: introduce use_kms_poll flag in amdgpu as the poll stuff check
v2: use dc_enabled as the flag to simply code
v3: move code into non DC path instead of relying on any flag
Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2411
Fixes: a4e771729a51("drm/probe_helper: sort out poll_running vs poll_enabled")
Reported-by: Bert Karwatzki
Suggested-by: Dmitry Baryshkov
Suggested-by: Alex Deucher
Signed-off-by: Guchun Chen
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 4
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index c4a4e2fe6681..da5b0258a237 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -4145,8 +4145,6 @@ int amdgpu_device_suspend(struct drm_device *dev, bool
fbcon)
if (amdgpu_acpi_smart_shift_update(dev, AMDGPU_SS_DEV_D3))
DRM_WARN("smart shift update failed\n");
- drm_kms_helper_poll_disable(dev);
-
if (fbcon)
drm_fb_helper_set_suspend_unlocked(adev_to_drm(adev)->fb_helper, true);
@@ -4243,8 +4241,6 @@ int amdgpu_device_resume(struct drm_device *dev, bool
fbcon)
if (fbcon)
drm_fb_helper_set_suspend_unlocked(adev_to_drm(adev)->fb_helper, false);
- drm_kms_helper_poll_enable(dev);
-
amdgpu_ras_resume(adev);
if (adev->mode_info.num_crtc) {
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
index 503f89a766c3..d60fe7eb5579 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
@@ -1618,6 +1618,8 @@ int amdgpu_display_suspend_helper(struct amdgpu_device
*adev)
struct drm_connector_list_iter iter;
int r;
+ drm_kms_helper_poll_disable(dev);
+
/* turn off display hw */
drm_modeset_lock_all(dev);
drm_connector_list_iter_begin(dev, );
@@ -1694,6 +1696,8 @@ int amdgpu_display_resume_helper(struct amdgpu_device
*adev)
drm_modeset_unlock_all(dev);
+ drm_kms_helper_poll_enable(dev);
+
return 0;
}
--
2.25.1
[PATCH] drm/amd/display: use a more accurate check in dm_helpers_dp_read_dpcd()
We should be checking if drm_dp_dpcd_read() returns the size that we are asking it to read instead of just checking if it is greater than zero. Also, we should WARN_ON() here since this condition is only ever met, if there is an issue worth investigating. So, compare the return value of drm_dp_dpcd_read() to size and WARN_ON() if they aren't equal. Signed-off-by: Hamza Mahfooz --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 4 ++-- 1 file changed, 2 insertions(+), 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 8d598b322e5b..ed2ed7b1d869 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 @@ -511,8 +511,8 @@ bool dm_helpers_dp_read_dpcd( return false; } - return drm_dp_dpcd_read(>dm_dp_aux.aux, address, - data, size) > 0; + return !WARN_ON(drm_dp_dpcd_read(>dm_dp_aux.aux, address, +data, size) != size); } bool dm_helpers_dp_write_dpcd( -- 2.39.2
Re: [PATCH v3 02/17] drm/connector: Add enum documentation to drm_colorspace
On Thu, Mar 9, 2023 at 11:03 AM Pekka Paalanen wrote:
>
> On Thu, 9 Mar 2023 01:56:11 +0100
> Sebastian Wick wrote:
>
> > On Wed, Mar 8, 2023 at 9:59 AM Pekka Paalanen wrote:
> > >
> > > On Tue, 7 Mar 2023 10:10:52 -0500
> > > Harry Wentland wrote:
> > >
> > > > From: Joshua Ashton
> > > >
> > > > To match the other enums, and add more information about these values.
> > > >
> > > > v2:
> > > > - Specify where an enum entry comes from
> > > > - Clarify DEFAULT and NO_DATA behavior
> > > > - BT.2020 CYCC is "constant luminance"
> > > > - correct type for BT.601
> > > >
> > > > Signed-off-by: Joshua Ashton
> > > > Signed-off-by: Harry Wentland
> > > > Reviewed-by: Harry Wentland
> > >
> > > Hi,
> > >
> > > this effort is really good, but of course I still find things to
> > > nitpick about. If there is no answer to my questions, then I would
> > > prefer the documentation to spell out the unknowns and ambiguities.
> > >
> > > > Cc: Pekka Paalanen
> > > > Cc: Sebastian Wick
> > > > Cc: vitaly.pros...@amd.com
> > > > Cc: Uma Shankar
> > > > Cc: Ville Syrjälä
> > > > Cc: Joshua Ashton
> > > > Cc: dri-de...@lists.freedesktop.org
> > > > Cc: amd-gfx@lists.freedesktop.org
> > > > ---
> > > > include/drm/drm_connector.h | 67 +++--
> > > > 1 file changed, 65 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> > > > index 6d6a53a6b010..bb078666dc34 100644
> > > > --- a/include/drm/drm_connector.h
> > > > +++ b/include/drm/drm_connector.h
> > > > @@ -363,13 +363,76 @@ enum drm_privacy_screen_status {
> > > > PRIVACY_SCREEN_ENABLED_LOCKED,
> > > > };
> > > >
> > > > -/*
> > > > - * This is a consolidated colorimetry list supported by HDMI and
> > > > +/**
> > > > + * enum drm_colorspace - color space
> > > > + *
> > > > + * This enum is a consolidated colorimetry list supported by HDMI and
> > > > * DP protocol standard. The respective connectors will register
> > > > * a property with the subset of this list (supported by that
> > > > * respective protocol). Userspace will set the colorspace through
> > > > * a colorspace property which will be created and exposed to
> > > > * userspace.
> > > > + *
> > > > + * DP definitions come from the DP v2.0 spec
> > > > + * HDMI definitions come from the CTA-861-H spec
> > > > + *
> > > > + * @DRM_MODE_COLORIMETRY_DEFAULT:
> > > > + * Driver specific behavior.
> > > > + * For DP:
> > > > + * RGB encoded: sRGB (IEC 61966-2-1)
> > > > + * YCbCr encoded: ITU-R BT.601 colorimetry format
> > >
> > > Does this mean that HDMI behavior is driver-specific while DP behavior
> > > is as defined?
> > >
> > > Is it intentional that YCbCr encoding also uses different RGB-primaries
> > > than RGB-encoded signal? (BT.601 vs. BT.709/sRGB)
> > >
> > > Or do you need to be more explicit on which parts of each spec apply
> > > (ColourPrimaries vs. TransferCharacteristics vs. MatrixCoefficients in
> > > CICP parlance)?
> > >
> > > E.g. BT.709/sRGB ColourPrimaries with BT.601 MatrixCoefficients.
> >
> > Yeah, just adding to this: The Default Colorspace is something well
> > defined. CTA-861 says:
> >
> > "If bits C0 and C1 are zero, the colorimetry shall correspond to the
> > default colorimetry defined in Section 5.1"
> >
> > and in Section 5.1
> >
> > "In all cases described above, the RGB color space used should be the
> > RGB color space the Sink declares in the Basic Display Parameters and
> > Feature Block of its EDID."
> >
> > If I set DRM_MODE_COLORIMETRY_DEFAULT, I expect the Colorimetry the
> > EDID reports to be in effect and not some driver specific nonsense.
>
> Does that also define the MatrixCoefficients for YCbCr signal with
> DRM_MODE_COLORIMETRY_DEFAULT?
Good question. It doesn't seem like it does, which would make
supporting YCC with the default color space impossible.
> Not that userspace would even care, since RGB-to-YCbCr is all
> driver-internal.
>
> It is interesting you point that out. I guess it means that the basic
> colorimetry from EDID is supposed to be really only the default
> colorimetry and might not have anything to do with the actual panel
> primaries.
>
>
> Thanks,
> pq
[PATCH] drm/amd/display: Set MPC_SPLIT_DYNAMIC for DCN301
Since DC version 3.2.226, DC started to use a new internal commit
sequence that better deals with hardware limitations. Usually, DC adopts
split pipe dynamics to improve the display bandwidth and, in some cases,
to save power. This commit sets MPC_SPLIT_DYNAMIC for DCN301, improving
the bandwidth and fixing the cursor bug on KDE when it tries hardware
rotation.
Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2247
Cc: Melissa Wen
Cc: Xaver Hugl
Signed-off-by: Rodrigo Siqueira
---
drivers/gpu/drm/amd/display/dc/dcn301/dcn301_resource.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn301/dcn301_resource.c
b/drivers/gpu/drm/amd/display/dc/dcn301/dcn301_resource.c
index b93b4498dba4..5ac2a272c380 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn301/dcn301_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn301/dcn301_resource.c
@@ -687,7 +687,7 @@ static const struct dc_debug_options debug_defaults_drv = {
.disable_clock_gate = true,
.disable_pplib_clock_request = true,
.disable_pplib_wm_range = true,
- .pipe_split_policy = MPC_SPLIT_AVOID,
+ .pipe_split_policy = MPC_SPLIT_DYNAMIC,
.force_single_disp_pipe_split = false,
.disable_dcc = DCC_ENABLE,
.vsr_support = true,
--
2.39.2
Re: [pull] amdgpu, amdkfd drm-fixes-6.3
On 3/9/2023 11:32 AM, Alex Deucher wrote: Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding. On Thu, Mar 9, 2023 at 12:16 PM Felix Kuehling wrote: Am 2023-03-08 um 23:38 schrieb Alex Deucher: Hi Dave, Daniel, Fixes for 6.3. The following changes since commit 66305069eb6d17d9190cbcd196f3f7487df47ae8: Merge tag 'drm-misc-fixes-2023-02-23' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes (2023-03-07 05:42:34 +1000) are available in the Git repository at: https://gitlab.freedesktop.org/agd5f/linux.git tags/amd-drm-fixes-6.3-2023-03-08 for you to fetch changes up to 41f95a0e40903fcf70463fcc060b7faf761b23f6: drm/amdgpu/soc21: Add video cap query support for VCN_4_0_4 (2023-03-08 14:39:09 -0500) amd-drm-fixes-6.3-2023-03-08: amdgpu: - Misc display fixes - UMC 8.10 fixes - Driver unload fixes - NBIO 7.3.0 fix - Error checking fixes for soc15, nv, soc21 read register interface - Fix video cap query for VCN 4.0.4 amdkfd: - Fix BO offset for multi-VMA page migration - Fix return check in doorbell handling Alex Deucher (3): drm/amdgpu: fix error checking in amdgpu_read_mm_registers for soc15 drm/amdgpu: fix error checking in amdgpu_read_mm_registers for soc21 drm/amdgpu: fix error checking in amdgpu_read_mm_registers for nv Candice Li (2): drm/amdgpu: Support umc node harvest config on umc v8_10 drm/amd/pm: Enable ecc_info table support for smu v13_0_10 Harry Wentland (2): drm/display: Don't block HDR_OUTPUT_METADATA on unknown EOTF drm/connector: print max_requested_bpc in state debugfs Mario Limonciello (1): drm/amd: Fix initialization mistake for NBIO 7.3.0 Shashank Sharma (1): drm/amdgpu: fix return value check in kfd Swapnil Patel (1): drm/amd/display: Update clock table to include highest clock setting Veerabadhran Gopalakrishnan (1): drm/amdgpu/soc21: Add video cap query support for VCN_4_0_4 Xiaogang Chen (1): drm/amdkfd: Fix BO offset for multi-VMA page migration This patch introduced a regression. Xiaogang is working on a followup fix. I would recommend not to merge it yet. Xiaogang, please add a Fixes tag to your follow-up patch to make the connection clear. Thanks. If it lands today, I'll send an updated PR with the fix. If not, I'll send an updated PR with this patch dropped. Alex Will do it today and let you know. Xiaogang Thanks, Felix lyndonli (2): drm/amdgpu: Fix call trace warning and hang when removing amdgpu device drm/amdgpu: Fix the warning info when removing amdgpu device drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c | 10 ++- drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c| 17 + drivers/gpu/drm/amd/amdgpu/amdgpu_umc.h| 7 +- drivers/gpu/drm/amd/amdgpu/gmc_v11_0.c | 1 - drivers/gpu/drm/amd/amdgpu/nbio_v7_2.c | 14 ++-- drivers/gpu/drm/amd/amdgpu/nv.c| 7 +- drivers/gpu/drm/amd/amdgpu/soc15.c | 5 +- drivers/gpu/drm/amd/amdgpu/soc21.c | 8 ++- drivers/gpu/drm/amd/amdgpu/umc_v8_10.h | 4 +- drivers/gpu/drm/amd/amdkfd/kfd_doorbell.c | 2 +- drivers/gpu/drm/amd/amdkfd/kfd_migrate.c | 17 +++-- .../drm/amd/display/dc/clk_mgr/dcn301/vg_clk_mgr.c | 19 +- .../gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c | 75 ++ drivers/gpu/drm/display/drm_hdmi_helper.c | 6 +- drivers/gpu/drm/drm_atomic.c | 1 + 16 files changed, 146 insertions(+), 49 deletions(-)
Re: [PATCH] drm/amdkfd: fix potential kgd_mem UAFs
Am 2023-03-08 um 16:37 schrieb Chia-I Wu:
kgd_mem should be accessed with p->mutex locked, or it could have been
freed by kfd_ioctl_free_memory_of_gpu.
Thank you for the patch. It's not just about accessing kgd_mem with
p->mutex held. It's also about holding the mutex continuously. I'd
update the description to be more explicit about the invariant being
broken here:
kgd_mem pointers returned by kfd_process_device_translate_handle are
only guaranteed to be valid while p->mutex is held. As soon as the mutex
is unlocked, another thread can free the BO.
I can update the description and submit the patch.
Reviewed-by: Felix Kuehling
Regards,
Felix
Signed-off-by: Chia-I Wu
---
drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
index 6d291aa6386bd..3c630114210d6 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
@@ -1293,14 +1293,14 @@ static int kfd_ioctl_map_memory_to_gpu(struct file
*filep,
args->n_success = i+1;
}
- mutex_unlock(>mutex);
-
err = amdgpu_amdkfd_gpuvm_sync_memory(dev->adev, (struct kgd_mem *)
mem, true);
if (err) {
pr_debug("Sync memory failed, wait interrupted by user
signal\n");
goto sync_memory_failed;
}
+ mutex_unlock(>mutex);
+
/* Flush TLBs after waiting for the page table updates to complete */
for (i = 0; i < args->n_devices; i++) {
peer_pdd = kfd_process_device_data_by_id(p, devices_arr[i]);
@@ -1316,9 +1316,9 @@ static int kfd_ioctl_map_memory_to_gpu(struct file *filep,
bind_process_to_device_failed:
get_mem_obj_from_handle_failed:
map_memory_to_gpu_failed:
+sync_memory_failed:
mutex_unlock(>mutex);
copy_from_user_failed:
-sync_memory_failed:
kfree(devices_arr);
return err;
@@ -1332,6 +1332,7 @@ static int kfd_ioctl_unmap_memory_from_gpu(struct file
*filep,
void *mem;
long err = 0;
uint32_t *devices_arr = NULL, i;
+ bool flush_tlb;
if (!args->n_devices) {
pr_debug("Device IDs array empty\n");
@@ -1384,16 +1385,19 @@ static int kfd_ioctl_unmap_memory_from_gpu(struct file
*filep,
}
args->n_success = i+1;
}
- mutex_unlock(>mutex);
- if (kfd_flush_tlb_after_unmap(pdd->dev)) {
+ flush_tlb = kfd_flush_tlb_after_unmap(pdd->dev);
+ if (flush_tlb) {
err = amdgpu_amdkfd_gpuvm_sync_memory(pdd->dev->adev,
(struct kgd_mem *) mem, true);
if (err) {
pr_debug("Sync memory failed, wait interrupted by user
signal\n");
goto sync_memory_failed;
}
+ }
+ mutex_unlock(>mutex);
+ if (flush_tlb) {
/* Flush TLBs after waiting for the page table updates to
complete */
for (i = 0; i < args->n_devices; i++) {
peer_pdd = kfd_process_device_data_by_id(p,
devices_arr[i]);
@@ -1409,9 +1413,9 @@ static int kfd_ioctl_unmap_memory_from_gpu(struct file
*filep,
bind_process_to_device_failed:
get_mem_obj_from_handle_failed:
unmap_memory_from_gpu_failed:
+sync_memory_failed:
mutex_unlock(>mutex);
copy_from_user_failed:
-sync_memory_failed:
kfree(devices_arr);
return err;
}
Re: [pull] amdgpu, amdkfd drm-fixes-6.3
On Thu, Mar 9, 2023 at 12:16 PM Felix Kuehling wrote: > > > Am 2023-03-08 um 23:38 schrieb Alex Deucher: > > Hi Dave, Daniel, > > > > Fixes for 6.3. > > > > The following changes since commit 66305069eb6d17d9190cbcd196f3f7487df47ae8: > > > >Merge tag 'drm-misc-fixes-2023-02-23' of > > git://anongit.freedesktop.org/drm/drm-misc into drm-fixes (2023-03-07 > > 05:42:34 +1000) > > > > are available in the Git repository at: > > > >https://gitlab.freedesktop.org/agd5f/linux.git > > tags/amd-drm-fixes-6.3-2023-03-08 > > > > for you to fetch changes up to 41f95a0e40903fcf70463fcc060b7faf761b23f6: > > > >drm/amdgpu/soc21: Add video cap query support for VCN_4_0_4 (2023-03-08 > > 14:39:09 -0500) > > > > > > amd-drm-fixes-6.3-2023-03-08: > > > > amdgpu: > > - Misc display fixes > > - UMC 8.10 fixes > > - Driver unload fixes > > - NBIO 7.3.0 fix > > - Error checking fixes for soc15, nv, soc21 read register interface > > - Fix video cap query for VCN 4.0.4 > > > > amdkfd: > > - Fix BO offset for multi-VMA page migration > > - Fix return check in doorbell handling > > > > > > Alex Deucher (3): > >drm/amdgpu: fix error checking in amdgpu_read_mm_registers for soc15 > >drm/amdgpu: fix error checking in amdgpu_read_mm_registers for soc21 > >drm/amdgpu: fix error checking in amdgpu_read_mm_registers for nv > > > > Candice Li (2): > >drm/amdgpu: Support umc node harvest config on umc v8_10 > >drm/amd/pm: Enable ecc_info table support for smu v13_0_10 > > > > Harry Wentland (2): > >drm/display: Don't block HDR_OUTPUT_METADATA on unknown EOTF > >drm/connector: print max_requested_bpc in state debugfs > > > > Mario Limonciello (1): > >drm/amd: Fix initialization mistake for NBIO 7.3.0 > > > > Shashank Sharma (1): > >drm/amdgpu: fix return value check in kfd > > > > Swapnil Patel (1): > >drm/amd/display: Update clock table to include highest clock setting > > > > Veerabadhran Gopalakrishnan (1): > >drm/amdgpu/soc21: Add video cap query support for VCN_4_0_4 > > > > Xiaogang Chen (1): > >drm/amdkfd: Fix BO offset for multi-VMA page migration > > This patch introduced a regression. Xiaogang is working on a followup > fix. I would recommend not to merge it yet. > > Xiaogang, please add a Fixes tag to your follow-up patch to make the > connection clear. Thanks. If it lands today, I'll send an updated PR with the fix. If not, I'll send an updated PR with this patch dropped. Alex > > Thanks, >Felix > > > > > > lyndonli (2): > >drm/amdgpu: Fix call trace warning and hang when removing amdgpu > > device > >drm/amdgpu: Fix the warning info when removing amdgpu device > > > > drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c | 10 ++- > > drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 2 +- > > drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c| 17 + > > drivers/gpu/drm/amd/amdgpu/amdgpu_umc.h| 7 +- > > drivers/gpu/drm/amd/amdgpu/gmc_v11_0.c | 1 - > > drivers/gpu/drm/amd/amdgpu/nbio_v7_2.c | 14 ++-- > > drivers/gpu/drm/amd/amdgpu/nv.c| 7 +- > > drivers/gpu/drm/amd/amdgpu/soc15.c | 5 +- > > drivers/gpu/drm/amd/amdgpu/soc21.c | 8 ++- > > drivers/gpu/drm/amd/amdgpu/umc_v8_10.h | 4 +- > > drivers/gpu/drm/amd/amdkfd/kfd_doorbell.c | 2 +- > > drivers/gpu/drm/amd/amdkfd/kfd_migrate.c | 17 +++-- > > .../drm/amd/display/dc/clk_mgr/dcn301/vg_clk_mgr.c | 19 +- > > .../gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c | 75 > > ++ > > drivers/gpu/drm/display/drm_hdmi_helper.c | 6 +- > > drivers/gpu/drm/drm_atomic.c | 1 + > > 16 files changed, 146 insertions(+), 49 deletions(-)
Re: [pull] amdgpu, amdkfd drm-fixes-6.3
Am 2023-03-08 um 23:38 schrieb Alex Deucher: Hi Dave, Daniel, Fixes for 6.3. The following changes since commit 66305069eb6d17d9190cbcd196f3f7487df47ae8: Merge tag 'drm-misc-fixes-2023-02-23' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes (2023-03-07 05:42:34 +1000) are available in the Git repository at: https://gitlab.freedesktop.org/agd5f/linux.git tags/amd-drm-fixes-6.3-2023-03-08 for you to fetch changes up to 41f95a0e40903fcf70463fcc060b7faf761b23f6: drm/amdgpu/soc21: Add video cap query support for VCN_4_0_4 (2023-03-08 14:39:09 -0500) amd-drm-fixes-6.3-2023-03-08: amdgpu: - Misc display fixes - UMC 8.10 fixes - Driver unload fixes - NBIO 7.3.0 fix - Error checking fixes for soc15, nv, soc21 read register interface - Fix video cap query for VCN 4.0.4 amdkfd: - Fix BO offset for multi-VMA page migration - Fix return check in doorbell handling Alex Deucher (3): drm/amdgpu: fix error checking in amdgpu_read_mm_registers for soc15 drm/amdgpu: fix error checking in amdgpu_read_mm_registers for soc21 drm/amdgpu: fix error checking in amdgpu_read_mm_registers for nv Candice Li (2): drm/amdgpu: Support umc node harvest config on umc v8_10 drm/amd/pm: Enable ecc_info table support for smu v13_0_10 Harry Wentland (2): drm/display: Don't block HDR_OUTPUT_METADATA on unknown EOTF drm/connector: print max_requested_bpc in state debugfs Mario Limonciello (1): drm/amd: Fix initialization mistake for NBIO 7.3.0 Shashank Sharma (1): drm/amdgpu: fix return value check in kfd Swapnil Patel (1): drm/amd/display: Update clock table to include highest clock setting Veerabadhran Gopalakrishnan (1): drm/amdgpu/soc21: Add video cap query support for VCN_4_0_4 Xiaogang Chen (1): drm/amdkfd: Fix BO offset for multi-VMA page migration This patch introduced a regression. Xiaogang is working on a followup fix. I would recommend not to merge it yet. Xiaogang, please add a Fixes tag to your follow-up patch to make the connection clear. Thanks, Felix lyndonli (2): drm/amdgpu: Fix call trace warning and hang when removing amdgpu device drm/amdgpu: Fix the warning info when removing amdgpu device drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c | 10 ++- drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c| 17 + drivers/gpu/drm/amd/amdgpu/amdgpu_umc.h| 7 +- drivers/gpu/drm/amd/amdgpu/gmc_v11_0.c | 1 - drivers/gpu/drm/amd/amdgpu/nbio_v7_2.c | 14 ++-- drivers/gpu/drm/amd/amdgpu/nv.c| 7 +- drivers/gpu/drm/amd/amdgpu/soc15.c | 5 +- drivers/gpu/drm/amd/amdgpu/soc21.c | 8 ++- drivers/gpu/drm/amd/amdgpu/umc_v8_10.h | 4 +- drivers/gpu/drm/amd/amdkfd/kfd_doorbell.c | 2 +- drivers/gpu/drm/amd/amdkfd/kfd_migrate.c | 17 +++-- .../drm/amd/display/dc/clk_mgr/dcn301/vg_clk_mgr.c | 19 +- .../gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c | 75 ++ drivers/gpu/drm/display/drm_hdmi_helper.c | 6 +- drivers/gpu/drm/drm_atomic.c | 1 + 16 files changed, 146 insertions(+), 49 deletions(-)
Re: [PATCH] drm/amdgpu: expose more memory stats in fdinfo
Feel free to add my rb on this and push it to amd-staging-drm-next. Christian. Am 09.03.23 um 17:02 schrieb Marek Olšák: Ping On Thu, Feb 23, 2023 at 1:46 PM Marek Olšák wrote: Updated patch attached. Marek On Mon, Feb 6, 2023 at 4:05 AM Christian König wrote: Just two nit picks: + seq_printf(m, "drm-evicted-visible-vram:\t%llu KiB\n", + stats.evicted_visible_vram/1024UL); For the values not standardized for all DRM drivers we might want to use amd as prefix here instead of drm. + uint64_t requested_gtt; /* how much userspace asked for */ We used to have automated checkers complaining about comments after members. Kerneldoc complicent comments look like this: /* @timestamp replaced by @rcu on dma_fence_release() */ struct rcu_head rcu; Apart from that looks good to me. Regards, Christian. Am 30.01.23 um 07:56 schrieb Marek Olšák: > Hi, > > This will be used for performance investigations. The patch is attached. > > Thanks, > Marek
Re: [PATCH] drm/amdgpu: expose more memory stats in fdinfo
Ping On Thu, Feb 23, 2023 at 1:46 PM Marek Olšák wrote: > Updated patch attached. > > Marek > > On Mon, Feb 6, 2023 at 4:05 AM Christian König < > ckoenig.leichtzumer...@gmail.com> wrote: > >> Just two nit picks: >> >> +seq_printf(m, "drm-evicted-visible-vram:\t%llu KiB\n", >> + stats.evicted_visible_vram/1024UL); >> >> For the values not standardized for all DRM drivers we might want to use >> amd as prefix here instead of drm. >> >> +uint64_t requested_gtt;/* how much userspace asked for */ >> >> We used to have automated checkers complaining about comments after >> members. >> >> Kerneldoc complicent comments look like this: >> >> /* @timestamp replaced by @rcu on dma_fence_release() */ >> struct rcu_head rcu; >> >> Apart from that looks good to me. >> >> Regards, >> Christian. >> >> Am 30.01.23 um 07:56 schrieb Marek Olšák: >> > Hi, >> > >> > This will be used for performance investigations. The patch is attached. >> > >> > Thanks, >> > Marek >> >>
Re: [PATCH] drm/amd/amdgpu: Add missing INT_STAT_DEBUG registers to GC 10.1 and 10.3 headers
On Thu, Mar 9, 2023 at 10:24 AM Tom St Denis wrote: > > Checked against database, copied from GC 9.4.2 header. > > Signed-off-by: Tom St Denis Acked-by: Alex Deucher > --- > .../include/asic_reg/gc/gc_10_1_0_offset.h| 4 ++ > .../include/asic_reg/gc/gc_10_1_0_sh_mask.h | 54 +++ > .../include/asic_reg/gc/gc_10_3_0_offset.h| 4 ++ > .../include/asic_reg/gc/gc_10_3_0_sh_mask.h | 54 +++ > 4 files changed, 116 insertions(+) > > diff --git a/drivers/gpu/drm/amd/include/asic_reg/gc/gc_10_1_0_offset.h > b/drivers/gpu/drm/amd/include/asic_reg/gc/gc_10_1_0_offset.h > index 18d34bbceebe..79c41004c0b6 100644 > --- a/drivers/gpu/drm/amd/include/asic_reg/gc/gc_10_1_0_offset.h > +++ b/drivers/gpu/drm/amd/include/asic_reg/gc/gc_10_1_0_offset.h > @@ -4868,6 +4868,10 @@ > #define mmCP_ME2_PIPE2_INT_STATUS_BASE_IDX > 0 > #define mmCP_ME2_PIPE3_INT_STATUS > 0x1e34 > #define mmCP_ME2_PIPE3_INT_STATUS_BASE_IDX > 0 > +#define mmCP_ME1_INT_STAT_DEBUG > 0x1e35 > +#define mmCP_ME1_INT_STAT_DEBUG_BASE_IDX > 0 > +#define mmCP_ME2_INT_STAT_DEBUG > 0x1e36 > +#define mmCP_ME2_INT_STAT_DEBUG_BASE_IDX > 0 > #define mmCP_GFX_QUEUE_INDEX > 0x1e37 > #define mmCP_GFX_QUEUE_INDEX_BASE_IDX > 0 > #define mmCC_GC_EDC_CONFIG > 0x1e38 > diff --git a/drivers/gpu/drm/amd/include/asic_reg/gc/gc_10_1_0_sh_mask.h > b/drivers/gpu/drm/amd/include/asic_reg/gc/gc_10_1_0_sh_mask.h > index 4127896ffcdf..52043e143067 100644 > --- a/drivers/gpu/drm/amd/include/asic_reg/gc/gc_10_1_0_sh_mask.h > +++ b/drivers/gpu/drm/amd/include/asic_reg/gc/gc_10_1_0_sh_mask.h > @@ -18680,6 +18680,60 @@ > //CC_GC_EDC_CONFIG > #define CC_GC_EDC_CONFIG__DIS_EDC__SHIFT > 0x1 > #define CC_GC_EDC_CONFIG__DIS_EDC_MASK > 0x0002L > +//CP_ME1_INT_STAT_DEBUG > +#define CP_ME1_INT_STAT_DEBUG__CMP_QUERY_STATUS_INT_ASSERTED__SHIFT > 0xc > +#define CP_ME1_INT_STAT_DEBUG__DEQUEUE_REQUEST_INT_ASSERTED__SHIFT > 0xd > +#define CP_ME1_INT_STAT_DEBUG__CP_ECC_ERROR_INT_ASSERTED__SHIFT > 0xe > +#define CP_ME1_INT_STAT_DEBUG__SUA_VIOLATION_INT_STATUS__SHIFT > 0xf > +#define CP_ME1_INT_STAT_DEBUG__GPF_INT_ASSERTED__SHIFT > 0x10 > +#define CP_ME1_INT_STAT_DEBUG__WRM_POLL_TIMEOUT_INT_ASSERTED__SHIFT > 0x11 > +#define CP_ME1_INT_STAT_DEBUG__PRIV_REG_INT_ASSERTED__SHIFT > 0x17 > +#define CP_ME1_INT_STAT_DEBUG__OPCODE_ERROR_INT_ASSERTED__SHIFT > 0x18 > +#define CP_ME1_INT_STAT_DEBUG__TIME_STAMP_INT_ASSERTED__SHIFT > 0x1a > +#define CP_ME1_INT_STAT_DEBUG__RESERVED_BIT_ERROR_INT_ASSERTED__SHIFT > 0x1b > +#define CP_ME1_INT_STAT_DEBUG__GENERIC2_INT_ASSERTED__SHIFT > 0x1d > +#define CP_ME1_INT_STAT_DEBUG__GENERIC1_INT_ASSERTED__SHIFT > 0x1e > +#define CP_ME1_INT_STAT_DEBUG__GENERIC0_INT_ASSERTED__SHIFT > 0x1f > +#define CP_ME1_INT_STAT_DEBUG__CMP_QUERY_STATUS_INT_ASSERTED_MASK > 0x1000L > +#define CP_ME1_INT_STAT_DEBUG__DEQUEUE_REQUEST_INT_ASSERTED_MASK > 0x2000L > +#define CP_ME1_INT_STAT_DEBUG__CP_ECC_ERROR_INT_ASSERTED_MASK > 0x4000L > +#define CP_ME1_INT_STAT_DEBUG__SUA_VIOLATION_INT_STATUS_MASK > 0x8000L > +#define CP_ME1_INT_STAT_DEBUG__GPF_INT_ASSERTED_MASK > 0x0001L > +#define CP_ME1_INT_STAT_DEBUG__WRM_POLL_TIMEOUT_INT_ASSERTED_MASK > 0x0002L > +#define CP_ME1_INT_STAT_DEBUG__PRIV_REG_INT_ASSERTED_MASK
Re: [PATCH] drm/amdkfd: Get prange->offset after svm_range_vram_node_new
Am 2023-03-08 um 13:39 schrieb Chen, Xiaogang:
On 3/8/2023 11:11 AM, Felix Kuehling wrote:
On 2023-03-08 02:45, Xiaogang.Chen wrote:
From: Xiaogang Chen
During miration to vram prange->offset is valid after vram buffer is
located,
either use old one or allocate a new one. Move
svm_range_vram_node_new before migrate
for each vma to get valid prange->offset.
Signed-off-by: Xiaogang Chen
I'd prefer to keep svm_range_vram_node_new in
svm_migrate_copy_to_vram. Logically the memory allocation should be
after migrate_vma_setup. If migrate_vma_setup finds that there is
nothing to migrate, we should not allocate any memory.
Does this fix a real issue, or is this a theoretical fix? I think it
should probably work correctly without this patch.
svm_range_vram_node_new sets prange->offset to 0. If no VRAM was
previously allocated, it should already be 0, so nothing changes.
Maybe we just need a fix to set prange->offset = 0 in
svm_range_vram_node_free.
A real issue is same prange migrate vram->cpu, then cpu->vram. During
vram->cpu pragne got split, so prange->offset got changed, then vram
node got freed by svm_range_vram_node_free, but not update
prange->offset. It is the case KFDSVMRangeTes.MigrateTest. I will
check by set prange->offset = 0 at svm_range_vram_node_free.
In theory, getting prange->offset after svm_range_vram_node_new makes
code logically clearer? svm_range_vram_node_new handles different
cases, we are not sure what prange->offset would be before call it.
I think you're right. It's more complicated than it appears at first
glance. Even if memory is already allocated, it may be on the wrong GPU.
And svm_range_vram_node_free doesn't really free the BO if it's shared
with other pranges. svm_vram_range_new can reuse the existing BO if it
was still referenced by other ranges. So we must remember the
prange->offset even after svm_range_vram_node_free was called.
If migrate_vma_setup fail for a vma, we can svm_range_vram_node_free
the vram buffer got from svm_range_vram_node_new.
I agree. There is this condition at the end of svm_migrate_ram_to_vram:
if (cpages)
prange->actual_loc = best_loc;
You can add
else
svm_range_vram_node_free(prange);
With that addition, the patch is
Reviewed-by: Felix Kuehling
Regards,
Felix
---
drivers/gpu/drm/amd/amdkfd/kfd_migrate.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c
b/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c
index fd54a00e7229..15791490c23e 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c
@@ -310,12 +310,6 @@ svm_migrate_copy_to_vram(struct amdgpu_device
*adev, struct svm_range *prange,
src = scratch;
dst = (uint64_t *)(scratch + npages);
- r = svm_range_vram_node_new(adev, prange, true);
- if (r) {
- dev_dbg(adev->dev, "fail %d to alloc vram\n", r);
- goto out;
- }
-
amdgpu_res_first(prange->ttm_res, ttm_res_offset,
npages << PAGE_SHIFT, );
for (i = j = 0; i < npages; i++) {
@@ -525,6 +519,12 @@ svm_migrate_ram_to_vram(struct svm_range
*prange, uint32_t best_loc,
start = prange->start << PAGE_SHIFT;
end = (prange->last + 1) << PAGE_SHIFT;
+
+ r = svm_range_vram_node_new(adev, prange, true);
+ if (r) {
+ dev_dbg(adev->dev, "fail %d to alloc vram\n", r);
+ return r;
+ }
ttm_res_offset = prange->offset << PAGE_SHIFT;
for (addr = start; addr < end;) {
[PATCH] drm/amd/amdgpu: Add missing INT_STAT_DEBUG registers to GC 10.1 and 10.3 headers
Checked against database, copied from GC 9.4.2 header. Signed-off-by: Tom St Denis --- .../include/asic_reg/gc/gc_10_1_0_offset.h| 4 ++ .../include/asic_reg/gc/gc_10_1_0_sh_mask.h | 54 +++ .../include/asic_reg/gc/gc_10_3_0_offset.h| 4 ++ .../include/asic_reg/gc/gc_10_3_0_sh_mask.h | 54 +++ 4 files changed, 116 insertions(+) diff --git a/drivers/gpu/drm/amd/include/asic_reg/gc/gc_10_1_0_offset.h b/drivers/gpu/drm/amd/include/asic_reg/gc/gc_10_1_0_offset.h index 18d34bbceebe..79c41004c0b6 100644 --- a/drivers/gpu/drm/amd/include/asic_reg/gc/gc_10_1_0_offset.h +++ b/drivers/gpu/drm/amd/include/asic_reg/gc/gc_10_1_0_offset.h @@ -4868,6 +4868,10 @@ #define mmCP_ME2_PIPE2_INT_STATUS_BASE_IDX 0 #define mmCP_ME2_PIPE3_INT_STATUS 0x1e34 #define mmCP_ME2_PIPE3_INT_STATUS_BASE_IDX 0 +#define mmCP_ME1_INT_STAT_DEBUG 0x1e35 +#define mmCP_ME1_INT_STAT_DEBUG_BASE_IDX 0 +#define mmCP_ME2_INT_STAT_DEBUG 0x1e36 +#define mmCP_ME2_INT_STAT_DEBUG_BASE_IDX 0 #define mmCP_GFX_QUEUE_INDEX 0x1e37 #define mmCP_GFX_QUEUE_INDEX_BASE_IDX 0 #define mmCC_GC_EDC_CONFIG 0x1e38 diff --git a/drivers/gpu/drm/amd/include/asic_reg/gc/gc_10_1_0_sh_mask.h b/drivers/gpu/drm/amd/include/asic_reg/gc/gc_10_1_0_sh_mask.h index 4127896ffcdf..52043e143067 100644 --- a/drivers/gpu/drm/amd/include/asic_reg/gc/gc_10_1_0_sh_mask.h +++ b/drivers/gpu/drm/amd/include/asic_reg/gc/gc_10_1_0_sh_mask.h @@ -18680,6 +18680,60 @@ //CC_GC_EDC_CONFIG #define CC_GC_EDC_CONFIG__DIS_EDC__SHIFT 0x1 #define CC_GC_EDC_CONFIG__DIS_EDC_MASK 0x0002L +//CP_ME1_INT_STAT_DEBUG +#define CP_ME1_INT_STAT_DEBUG__CMP_QUERY_STATUS_INT_ASSERTED__SHIFT 0xc +#define CP_ME1_INT_STAT_DEBUG__DEQUEUE_REQUEST_INT_ASSERTED__SHIFT 0xd +#define CP_ME1_INT_STAT_DEBUG__CP_ECC_ERROR_INT_ASSERTED__SHIFT 0xe +#define CP_ME1_INT_STAT_DEBUG__SUA_VIOLATION_INT_STATUS__SHIFT 0xf +#define CP_ME1_INT_STAT_DEBUG__GPF_INT_ASSERTED__SHIFT 0x10 +#define CP_ME1_INT_STAT_DEBUG__WRM_POLL_TIMEOUT_INT_ASSERTED__SHIFT 0x11 +#define CP_ME1_INT_STAT_DEBUG__PRIV_REG_INT_ASSERTED__SHIFT 0x17 +#define CP_ME1_INT_STAT_DEBUG__OPCODE_ERROR_INT_ASSERTED__SHIFT 0x18 +#define CP_ME1_INT_STAT_DEBUG__TIME_STAMP_INT_ASSERTED__SHIFT 0x1a +#define CP_ME1_INT_STAT_DEBUG__RESERVED_BIT_ERROR_INT_ASSERTED__SHIFT 0x1b +#define CP_ME1_INT_STAT_DEBUG__GENERIC2_INT_ASSERTED__SHIFT 0x1d +#define CP_ME1_INT_STAT_DEBUG__GENERIC1_INT_ASSERTED__SHIFT 0x1e +#define CP_ME1_INT_STAT_DEBUG__GENERIC0_INT_ASSERTED__SHIFT 0x1f +#define CP_ME1_INT_STAT_DEBUG__CMP_QUERY_STATUS_INT_ASSERTED_MASK 0x1000L +#define CP_ME1_INT_STAT_DEBUG__DEQUEUE_REQUEST_INT_ASSERTED_MASK 0x2000L +#define CP_ME1_INT_STAT_DEBUG__CP_ECC_ERROR_INT_ASSERTED_MASK 0x4000L +#define CP_ME1_INT_STAT_DEBUG__SUA_VIOLATION_INT_STATUS_MASK 0x8000L +#define CP_ME1_INT_STAT_DEBUG__GPF_INT_ASSERTED_MASK 0x0001L +#define CP_ME1_INT_STAT_DEBUG__WRM_POLL_TIMEOUT_INT_ASSERTED_MASK 0x0002L +#define CP_ME1_INT_STAT_DEBUG__PRIV_REG_INT_ASSERTED_MASK 0x0080L +#define CP_ME1_INT_STAT_DEBUG__OPCODE_ERROR_INT_ASSERTED_MASK 0x0100L +#define CP_ME1_INT_STAT_DEBUG__TIME_STAMP_INT_ASSERTED_MASK
[linux-next:master] BUILD REGRESSION 2c6433e9294b6d0f4d8f08c3c70a3eac434d3ec8
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 2c6433e9294b6d0f4d8f08c3c70a3eac434d3ec8 Add linux-next specific
files for 20230309
Error/Warning reports:
https://lore.kernel.org/oe-kbuild-all/202302111601.jty4lkra-...@intel.com
https://lore.kernel.org/oe-kbuild-all/202303081657.6ble80uy-...@intel.com
https://lore.kernel.org/oe-kbuild-all/202303081807.lblwkmpx-...@intel.com
https://lore.kernel.org/oe-kbuild-all/202303082135.njdx1bij-...@intel.com
https://lore.kernel.org/oe-kbuild-all/202303091430.hbwemt4b-...@intel.com
https://lore.kernel.org/oe-kbuild-all/202303091435.ae36t8f6-...@intel.com
https://lore.kernel.org/oe-kbuild-all/202303091548.vqmh7i6q-...@intel.com
https://lore.kernel.org/oe-kbuild-all/202303091711.howznriy-...@intel.com
https://lore.kernel.org/oe-kbuild-all/202303091728.uue6lwye-...@intel.com
https://lore.kernel.org/oe-kbuild-all/202303092022.jqy5pbvx-...@intel.com
Error/Warning: (recently discovered and may have been fixed)
ERROR: modpost: "intel_soc_pmic_exec_mipi_pmic_seq_element"
[drivers/platform/x86/x86-android-tablets/x86-android-tablets.ko] undefined!
drivers/clk/mvebu/kirkwood.c:358:1: error: expected identifier or '('
drivers/clk/mvebu/kirkwood.c:358:1: error: invalid digit 'd' in decimal constant
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_optc.c:294:6: warning: no
previous prototype for 'optc3_wait_drr_doublebuffer_pending_clear'
[-Wmissing-prototypes]
drivers/gpu/drm/amd/amdgpu/../display/dc/link/protocols/link_dp_capability.c:2184:
warning: expecting prototype for Check if there is a native DP or passive
DP(). Prototype was for dp_is_sink_present() instead
drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu13/smu_v13_0_6_ppt.c:1146:3: warning:
variable 'hotspotlimit' is uninitialized when used here [-Wuninitialized]
drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu13/smu_v13_0_6_ppt.c:1149:24:
warning: variable 'memlimit' is uninitialized when used here [-Wuninitialized]
drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu13/smu_v13_0_6_ppt.c:1152:34:
warning: variable 'software_shutdown_temp' is uninitialized when used here
[-Wuninitialized]
drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu13/smu_v13_0_6_ppt.c:315:17: sparse:
int
drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu13/smu_v13_0_6_ppt.c:315:17: sparse:
void
include/linux/dynamic_debug.h:307:14: error: implicit declaration of function
'strcmp' [-Werror=implicit-function-declaration]
kismet: WARNING: unmet direct dependencies detected for GPIO_SYSCON when
selected by GPIO_SAMA5D2_PIOBU
kismet: WARNING: unmet direct dependencies detected for MFD_STMFX when selected
by PINCTRL_STMFX
kismet: WARNING: unmet direct dependencies detected for OF_GPIO when selected
by GPIO_LOONGSON_64BIT
Unverified Error/Warning (likely false positive, please contact us if
interested):
drivers/iommu/apple-dart.c:1281:1: sparse: sparse: symbol 'apple_dart_pm_ops'
was not declared. Should it be static?
include/linux/gpio/consumer.h: linux/err.h is included more than once.
include/linux/gpio/driver.h: asm/bug.h is included more than once.
Error/Warning ids grouped by kconfigs:
gcc_recent_errors
|-- alpha-allyesconfig
| `--
drivers-gpu-drm-amd-amdgpu-..-display-dc-link-protocols-link_dp_capability.c:warning:expecting-prototype-for-Check-if-there-is-a-native-DP-or-passive-DP().-Prototype-was-for-dp_is_sink_present()-inste
|-- arc-allyesconfig
| `--
drivers-gpu-drm-amd-amdgpu-..-display-dc-link-protocols-link_dp_capability.c:warning:expecting-prototype-for-Check-if-there-is-a-native-DP-or-passive-DP().-Prototype-was-for-dp_is_sink_present()-inste
|-- arm-allmodconfig
| `--
drivers-gpu-drm-amd-amdgpu-..-display-dc-link-protocols-link_dp_capability.c:warning:expecting-prototype-for-Check-if-there-is-a-native-DP-or-passive-DP().-Prototype-was-for-dp_is_sink_present()-inste
|-- arm-allyesconfig
| `--
drivers-gpu-drm-amd-amdgpu-..-display-dc-link-protocols-link_dp_capability.c:warning:expecting-prototype-for-Check-if-there-is-a-native-DP-or-passive-DP().-Prototype-was-for-dp_is_sink_present()-inste
|-- arm-randconfig-r005-20230309
| `--
drivers-gpu-drm-amd-amdgpu-..-display-dc-link-protocols-link_dp_capability.c:warning:expecting-prototype-for-Check-if-there-is-a-native-DP-or-passive-DP().-Prototype-was-for-dp_is_sink_present()-inste
|-- arm-randconfig-r013-20230308
| `--
include-linux-dynamic_debug.h:error:implicit-declaration-of-function-strcmp
|-- arm64-allyesconfig
| |--
drivers-gpu-drm-amd-amdgpu-..-display-dc-dcn30-dcn30_optc.c:warning:no-previous-prototype-for-optc3_wait_drr_doublebuffer_pending_clear
| `--
drivers-gpu-drm-amd-amdgpu-..-display-dc-link-protocols-link_dp_capability.c:warning:expecting-prototype-for-Check-if-there-is-a-native-DP-or-passive-DP().-Prototype-was-for-dp_is_sink_present()-inste
|-- i386-allyesconfig
| |--
drivers-gpu-drm-amd-amdgpu-..-display-dc-dcn30-dcn30_optc.c:warning:no-previous
Re: [PATCH] drm/amd/display: Use swap() instead of open coding it
On 3/8/23 21:52, Jiapeng Chong wrote:
Swap is a function interface that provides exchange function. To avoid
code duplication, we can use swap function.
./drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c:359:57-58: WARNING
opportunity for swap().
Reported-by: Abaci Robot
Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=4448
Signed-off-by: Jiapeng Chong
Applied, thanks!
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 8 ++--
1 file changed, 2 insertions(+), 6 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 ae994c6c65ac..f6d9bbce15b2 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -352,13 +352,9 @@ static inline void reverse_planes_order(struct
dc_surface_update *array_of_surfa
int planes_count)
{
int i, j;
- struct dc_surface_update surface_updates_temp;
- for (i = 0, j = planes_count - 1; i < j; i++, j--) {
- surface_updates_temp = array_of_surface_update[i];
- array_of_surface_update[i] = array_of_surface_update[j];
- array_of_surface_update[j] = surface_updates_temp;
- }
+ for (i = 0, j = planes_count - 1; i < j; i++, j--)
+ swap(array_of_surface_update[i], array_of_surface_update[j]);
}
/**
--
Hamza
Re: [PATCH 1/2] drm/amdgpu: move poll enabled/disable into non DC path
On Thu, Mar 9, 2023 at 12:48 AM Guchun Chen wrote:
>
> Some amd asics having reliable hotplug support don't call
> drm_kms_helper_poll_init in driver init sequence. However,
> due to the unified suspend/resume path for all asics, because
> the output_poll_work->func is not set for these asics, a warning
> arrives when suspending.
>
> [ 90.656049]
> [ 90.656050] ? console_unlock+0x4d/0x100
> [ 90.656053] ? __irq_work_queue_local+0x27/0x60
> [ 90.656056] ? irq_work_queue+0x2b/0x50
> [ 90.656057] ? __wake_up_klogd+0x40/0x60
> [ 90.656059] __cancel_work_timer+0xed/0x180
> [ 90.656061] drm_kms_helper_poll_disable.cold+0x1f/0x2c [drm_kms_helper]
> [ 90.656072] amdgpu_device_suspend+0x81/0x170 [amdgpu]
> [ 90.656180] amdgpu_pmops_runtime_suspend+0xb5/0x1b0 [amdgpu]
> [ 90.656269] pci_pm_runtime_suspend+0x61/0x1b0
>
> drm_kms_helper_poll_enable/disable is valid when poll_init is called in
> amdgpu code, which is only used in non DC path. So move such codes into
> non-DC path code to get rid of such warnings.
>
> Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2411
> Fixes: a4e771729a51("drm/probe_helper: sort out poll_running vs poll_enabled")
> Reported-by: Bert Karwatzki
> Suggested-by: Dmitry Baryshkov
> Suggested-by: Alex Deucher
> Signed-off-by: Guchun Chen
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4
> drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 4
> 2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> index c4a4e2fe6681..da5b0258a237 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> @@ -4145,8 +4145,6 @@ int amdgpu_device_suspend(struct drm_device *dev, bool
> fbcon)
> if (amdgpu_acpi_smart_shift_update(dev, AMDGPU_SS_DEV_D3))
> DRM_WARN("smart shift update failed\n");
>
> - drm_kms_helper_poll_disable(dev);
> -
> if (fbcon)
>
> drm_fb_helper_set_suspend_unlocked(adev_to_drm(adev)->fb_helper, true);
>
> @@ -4243,8 +4241,6 @@ int amdgpu_device_resume(struct drm_device *dev, bool
> fbcon)
> if (fbcon)
>
> drm_fb_helper_set_suspend_unlocked(adev_to_drm(adev)->fb_helper, false);
>
> - drm_kms_helper_poll_enable(dev);
> -
> amdgpu_ras_resume(adev);
>
> if (adev->mode_info.num_crtc) {
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> index 503f89a766c3..d60fe7eb5579 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> @@ -1618,6 +1618,8 @@ int amdgpu_display_suspend_helper(struct amdgpu_device
> *adev)
> struct drm_connector_list_iter iter;
> int r;
>
> + drm_kms_helper_poll_disable(dev);
> +
> /* turn off display hw */
> drm_modeset_lock_all(dev);
> drm_connector_list_iter_begin(dev, );
> @@ -1694,6 +1696,8 @@ int amdgpu_display_resume_helper(struct amdgpu_device
> *adev)
>
> drm_modeset_unlock_all(dev);
>
> + drm_kms_helper_poll_enable(dev);
> +
> return 0;
> }
>
> --
> 2.25.1
>
RE: [PATCH 2/2] drm/probe_helper: warning on poll_enabled for issue catching
> -Original Message-
> From: Dmitry Baryshkov
> Sent: Thursday, March 9, 2023 4:49 PM
> To: Chen, Guchun ; amd-
> g...@lists.freedesktop.org; dri-de...@lists.freedesktop.org; Deucher,
> Alexander ; Zhang, Hawking
> ; spassw...@web.de; m...@fireburn.co.uk
> Subject: Re: [PATCH 2/2] drm/probe_helper: warning on poll_enabled for
> issue catching
>
> On 09/03/2023 07:48, Guchun Chen wrote:
> > In order to catch issues in other drivers to ensure proper call
> > sequence of polling function.
> >
> > Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2411
> > Fixes: a4e771729a51("drm/probe_helper: sort out poll_running vs
> > poll_enabled")
>
> Previously it was suggested that this is not a fix, so the Fixes header is
> incorrect.
>
> Also please use -vN when preparing/sending patchsets. This is v2.
Will fix these in V3.
Regards,
Guchun
> > Reported-by: Bert Karwatzki
> > Suggested-by: Dmitry Baryshkov
> > Signed-off-by: Guchun Chen
> > ---
> > drivers/gpu/drm/drm_probe_helper.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_probe_helper.c
> > b/drivers/gpu/drm/drm_probe_helper.c
> > index 8127be134c39..85e0e80d4a52 100644
> > --- a/drivers/gpu/drm/drm_probe_helper.c
> > +++ b/drivers/gpu/drm/drm_probe_helper.c
> > @@ -852,6 +852,8 @@
> EXPORT_SYMBOL(drm_kms_helper_is_poll_worker);
> >*/
> > void drm_kms_helper_poll_disable(struct drm_device *dev)
> > {
> > + WARN_ON(!dev->mode_config.poll_enabled);
> > +
> > if (dev->mode_config.poll_running)
> > drm_kms_helper_disable_hpd(dev);
> >
>
> --
> With best wishes
> Dmitry
Re: [PATCH 2/2] drm/amd/pm: Fix navi10 incorrect OD volage after resume
On 3/9/2023 8:11 AM, Quan, Evan wrote:
[AMD Official Use Only - General]
-Original Message-
From: Deucher, Alexander
Sent: Wednesday, March 8, 2023 11:20 PM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; Błażej Szczygieł
; Quan, Evan
Subject: [PATCH 2/2] drm/amd/pm: Fix navi10 incorrect OD volage after
resume
Always setup overdrive tables after resume. Preserve only some
user-defined settings in user_overdrive_table if they're set.
Copy restored user_overdrive_table into od_table to get correct
values.
On cold boot, BTC was triggered and GfxVfCurve was calibrated. We
got VfCurve settings (a). On resuming back, BTC will be triggered
again and GfxVfCurve will be recalibrated. VfCurve settings (b)
got may be different from those of cold boot. So if we reuse
those VfCurve settings (a) got on cold boot on suspend, we can
run into discrepencies.
Based on the sienna cichlid patch from Błażej Szczygieł
Cc: Błażej Szczygieł
Cc: Evan Quan
Signed-off-by: Alex Deucher
---
.../gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c | 47
+++
1 file changed, 37 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c
b/drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c
index 95da6dd1cc65..68201d8e1c72 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c
@@ -2510,16 +2510,9 @@ static int navi10_set_default_od_settings(struct
smu_context *smu)
(OverDriveTable_t *)smu->smu_table.boot_overdrive_table;
OverDriveTable_t *user_od_table =
(OverDriveTable_t *)smu->smu_table.user_overdrive_table;
+ OverDriveTable_t user_od_table_bak;
int ret = 0;
- /*
-* For S3/S4/Runpm resume, no need to setup those overdrive
tables again as
-* - either they already have the default OD settings got during cold
bootup
-* - or they have some user customized OD settings which cannot be
overwritten
-*/
- if (smu->adev->in_suspend)
- return 0;
-
ret = smu_cmn_update_table(smu, SMU_TABLE_OVERDRIVE, 0,
(void *)boot_od_table, false);
if (ret) {
dev_err(smu->adev->dev, "Failed to get overdrive table!\n");
@@ -2553,7 +2546,27 @@ static int navi10_set_default_od_settings(struct
smu_context *smu)
navi10_dump_od_table(smu, boot_od_table);
memcpy(od_table, boot_od_table, sizeof(OverDriveTable_t));
- memcpy(user_od_table, boot_od_table, sizeof(OverDriveTable_t));
+
+ /*
+* For S3/S4/Runpm resume, we need to setup those overdrive
tables again,
+* but we have to preserve user defined values in "user_od_table".
+*/
+ if (!smu->adev->in_suspend) {
+ memcpy(user_od_table, boot_od_table,
sizeof(OverDriveTable_t));
+ smu->user_dpm_profile.user_od = false;
+ } else if (smu->user_dpm_profile.user_od) {
+ memcpy(_od_table_bak, user_od_table,
sizeof(OverDriveTable_t));
+ memcpy(user_od_table, boot_od_table,
sizeof(OverDriveTable_t));
+ user_od_table->GfxclkFmin =
user_od_table_bak.GfxclkFmin;
+ user_od_table->GfxclkFmax =
user_od_table_bak.GfxclkFmax;
+ user_od_table->UclkFmax = user_od_table_bak.UclkFmax;
+ user_od_table->GfxclkFreq1 =
user_od_table_bak.GfxclkFreq1;
+ user_od_table->GfxclkVolt1 =
user_od_table_bak.GfxclkVolt1;
+ user_od_table->GfxclkFreq2 =
user_od_table_bak.GfxclkFreq2;
+ user_od_table->GfxclkVolt2 =
user_od_table_bak.GfxclkVolt2;
+ user_od_table->GfxclkFreq3 =
user_od_table_bak.GfxclkFreq3;
+ user_od_table->GfxclkVolt3 =
user_od_table_bak.GfxclkVolt3;
+ }
Thing is a little tricky for navi10...
For navi2x, the vfcurve settings(GfxVfCurve.a, GfxVfCurve.b, GfxVfCurve.c) are
not configurable by user. We do not expose them to user.
So, we can just load the new vfcurve settings on resuming back without worry
about overriding user's settings.
Unlike navi2x, user can customize the vfcurve settings(by setting
GfxclkFreq/GfxVolt pairs) on navi10. More specifically:
- On cold boot, btc was triggered and vfcurve line was calibrated
- Driver calculated the target voltage(via
navi10_overdrive_get_gfx_clk_base_voltage) for the point
frequencies(GfxclkFreq1, GfxclkFreq2, GfxclkFreq3) and expose them to user
- e.g. point1 frequency/voltage: 500Mhz/ 0.75v
- Then user customized the vfcurve line by setting a new target voltage for the
point frequency.
- e.g. 500Mhz / 0.76v --> 10mv added
- On resuming back, the vfcurve line was recalibrated. The target voltage for
the point1 frequency may be changed to for example 0.745v(for 500Mhz). Under
such scenario, if we just restore user's settings(0.76v which will add 15mv),
that might not fit user's original intention.
So, for this case:
1. Either we add some new
Re: [PATCH] drm/amd/pm: Remove unavailable temperature params
[AMD Official Use Only - General]
we'd better to add other patches to avoid create HWMON node file "temp_inputX"
when smu doesn't support sensor type of AMDGPU_PP_SENSOR_EDGE_TEMP.
Reviewed-by: Yang Wang
Best Regards,
Kevin
From: amd-gfx on behalf of Lijo Lazar
Sent: Thursday, March 9, 2023 5:51 PM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; Zhang, Hawking
Subject: [PATCH] drm/amd/pm: Remove unavailable temperature params
Temperature limits are not available for SMU v13.0.6. Also, edge
temperature is not tracked. Remove logic associated with those.
Signed-off-by: Lijo Lazar
Reviewed-by: Hawking Zhang
---
.../drm/amd/pm/swsmu/smu13/smu_v13_0_6_ppt.c | 43 ---
1 file changed, 43 deletions(-)
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_6_ppt.c
b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_6_ppt.c
index 862859bfb9e1..54d36df1306f 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_6_ppt.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_6_ppt.c
@@ -82,12 +82,6 @@
#define smnPCIE_ESM_CTRL 0x111003D0
-static const struct smu_temperature_range smu_v13_0_6_thermal_policy[] = {
- { -273150, 99000, 99000, -273150, 99000, 99000, -273150, 99000, 99000 },
- { 12, 12, 12, 12, 12, 12, 12, 12,
- 12 },
-};
-
static const struct cmn2asic_msg_mapping
smu_v13_0_6_message_map[SMU_MSG_MAX_COUNT] = {
MSG_MAP(TestMessage, PPSMC_MSG_TestMessage,
0),
MSG_MAP(GetSmuVersion, PPSMC_MSG_GetSmuVersion,
1),
@@ -701,9 +695,6 @@ static int smu_v13_0_6_get_smu_metrics_data(struct
smu_context *smu,
case METRICS_AVERAGE_SOCKETPOWER:
*value = SMUQ10_TO_UINT(metrics->SocketPower) << 8;
break;
- case METRICS_TEMPERATURE_EDGE:
- *value = 0;
- break;
case METRICS_TEMPERATURE_HOTSPOT:
*value = SMUQ10_TO_UINT(metrics->MaxSocketTemperature);
break;
@@ -1127,33 +1118,6 @@ static int smu_v13_0_6_force_clk_levels(struct
smu_context *smu,
return ret;
}
-static int
-smu_v13_0_6_get_thermal_temperature_range(struct smu_context *smu,
- struct smu_temperature_range *range)
-{
- uint8_t software_shutdown_temp;
- uint8_t hotspotlimit;
- uint8_t memlimit;
-
- if (!range)
- return -EINVAL;
-
- /* TODO: Find a way to get temperature limits */
- memcpy(range, _v13_0_6_thermal_policy[0],
- sizeof(struct smu_temperature_range));
-
- range->hotspot_crit_max =
- hotspotlimit * SMU_TEMPERATURE_UNITS_PER_CENTIGRADES;
- range->hotspot_emergency_max = (hotspotlimit + CTF_OFFSET_HOTSPOT) *
- SMU_TEMPERATURE_UNITS_PER_CENTIGRADES;
- range->mem_crit_max = memlimit * SMU_TEMPERATURE_UNITS_PER_CENTIGRADES;
- range->mem_emergency_max = (memlimit + CTF_OFFSET_MEM) *
- SMU_TEMPERATURE_UNITS_PER_CENTIGRADES;
- range->software_shutdown_temp = software_shutdown_temp;
-
- return 0;
-}
-
static int smu_v13_0_6_get_current_activity_percent(struct smu_context *smu,
enum amd_pp_sensors sensor,
uint32_t *value)
@@ -1204,10 +1168,6 @@ static int smu_v13_0_6_thermal_get_temperature(struct
smu_context *smu,
ret = smu_v13_0_6_get_smu_metrics_data(
smu, METRICS_TEMPERATURE_HOTSPOT, value);
break;
- case AMDGPU_PP_SENSOR_EDGE_TEMP:
- ret = smu_v13_0_6_get_smu_metrics_data(
- smu, METRICS_TEMPERATURE_EDGE, value);
- break;
case AMDGPU_PP_SENSOR_MEM_TEMP:
ret = smu_v13_0_6_get_smu_metrics_data(
smu, METRICS_TEMPERATURE_MEM, value);
@@ -1244,7 +1204,6 @@ static int smu_v13_0_6_read_sensor(struct smu_context
*smu,
*size = 4;
break;
case AMDGPU_PP_SENSOR_HOTSPOT_TEMP:
- case AMDGPU_PP_SENSOR_EDGE_TEMP:
case AMDGPU_PP_SENSOR_MEM_TEMP:
ret = smu_v13_0_6_thermal_get_temperature(smu, sensor,
(uint32_t *)data);
@@ -2048,8 +2007,6 @@ static const struct pptable_funcs smu_v13_0_6_ppt_funcs =
{
/* dpm/clk tables */
.set_default_dpm_table = smu_v13_0_6_set_default_dpm_table,
.populate_umd_state_clk = smu_v13_0_6_populate_umd_state_clk,
- .get_thermal_temperature_range =
- smu_v13_0_6_get_thermal_temperature_range,
.print_clk_levels = smu_v13_0_6_print_clk_levels,
.force_clk_levels = smu_v13_0_6_force_clk_levels,
RE: [PATCH] [RFC] drm/drm_buddy fails to initialize on 32-bit architectures
[AMD Official Use Only - General]
Hi Luis,
Sorry, I missed this one. Give me some time. I will check on it.
Regards,
Arun
-Original Message-
From: Luís Mendes
Sent: Thursday, March 9, 2023 3:43 PM
To: Koenig, Christian
Cc: a...@linux-foundation.org; amd-gfx list ;
Linux Kernel Mailing List ; Paneer Selvam,
Arunpravin
Subject: Re: [PATCH] [RFC] drm/drm_buddy fails to initialize on 32-bit
architectures
Hi,
Ping? This is actually a regression.
If there is no one available to work this, maybe I can have a look in my spare
time, in accordance with your suggestion.
Regards,
Luís
On Tue, Jan 3, 2023 at 8:44 AM Christian König wrote:
>
> Am 25.12.22 um 20:39 schrieb Luís Mendes:
> > Re-sending with the correct linux-kernel mailing list email address.
> > Sorry for the inconvenience.
> >
> > The proposed patch fixes the issue and allows amdgpu to work again
> > on armhf with a AMD RX 550 card, however it may not be the best
> > solution for the issue, as detailed below.
> >
> > include/log2.h defined macros rounddown_pow_of_two(...) and
> > roundup_pow_of_two(...) do not handle 64-bit values on 32-bit
> > architectures (tested on armv9 armhf machine) causing
> > drm_buddy_init(...) to fail on BUG_ON with an underflow on the order
> > value, thus impeding amdgpu to load properly (no GUI).
> >
> > One option is to modify rounddown_pow_of_two(...) to detect if the
> > variable takes 32 bits or less and call
> > __rounddown_pow_of_two_u32(u32
> > n) or if the variable takes more space than 32 bits, then call
> > __rounddown_pow_of_two_u64(u64 n). This would imply renaming
> > __rounddown_pow_of_two(unsigne d long n) to
> > __rounddown_pow_of_two_u32(u32 n) and add a new function
> > __rounddown_pow_of_two_u64(u64 n). This would be the most
> > transparent solution, however there a few complications, and they are:
> > - that the mm subsystem will fail to link on armhf with an undefined
> > reference on __aeabi_uldivmod
> > - there a few drivers that directly call __rounddown_pow_of_two(...)
> > - that other drivers and subsystems generate warnings
> >
> > So this alternate solution was devised which avoids touching
> > existing code paths, and just updates drm_buddy which seems to be
> > the only driver that is failing, however I am not sure if this is
> > the proper way to go. So I would like to get a second opinion on
> > this, by those who know.
> >
> > /include/linux/log2.h
> > /drivers/gpu/drm/drm_buddy.c
> >
> > Signed-off-by: Luís Mendes
> >> 8--8<
> > diff -uprN linux-next/drivers/gpu/drm/drm_buddy.c
> > linux-nextLM/drivers/gpu/drm/drm_buddy.c
> > --- linux-next/drivers/gpu/drm/drm_buddy.c2022-12-25
> > 16:29:26.0 +
> > +++ linux-nextLM/drivers/gpu/drm/drm_buddy.c2022-12-25
> > 17:04:32.136007116 +
> > @@ -128,7 +128,7 @@ int drm_buddy_init(struct drm_buddy *mm,
> > unsigned int order;
> > u64 root_size;
> >
> > -root_size = rounddown_pow_of_two(size);
> > +root_size = rounddown_pow_of_two_u64(size);
> > order = ilog2(root_size) - ilog2(chunk_size);
>
> I think this can be handled much easier if keep around the root_order
> instead of the root_size in the first place.
>
> Cause ilog2() does the right thing even for non power of two values
> and so we just need the order for the offset subtraction below.
>
> Arun can you take a closer look at this?
>
> Regards,
> Christian.
>
> >
> > root = drm_block_alloc(mm, NULL, order, offset); diff
> > -uprN linux-next/include/linux/log2.h linux-nextLM/include/linux/log2.h
> > --- linux-next/include/linux/log2.h2022-12-25 16:29:29.0 +
> > +++ linux-nextLM/include/linux/log2.h2022-12-25 17:00:34.319901492 +
> > @@ -58,6 +58,18 @@ unsigned long __roundup_pow_of_two(unsig
> > }
> >
> > /**
> > + * __roundup_pow_of_two_u64() - round up to nearest power of two
> > + * (unsgined 64-bits precision version)
> > + * @n: value to round up
> > + */
> > +static inline __attribute__((const))
> > +u64 __roundup_pow_of_two_u64(u64 n) {
> > +return 1ULL << fls64(n - 1);
> > +}
> > +
> > +
> > +/**
> >* __rounddown_pow_of_two() - round down to nearest power of two
> >* @n: value to round down
> >*/
> > @@ -68,6 +80,17 @@ unsigned long __rounddown_pow_of_two(uns
> > }
> >
> > /**
> > + * __rounddown_pow_of_two_u64() - round down to nearest power of
> > +two
> > + * (unsgined 64-bits precision version)
> > + * @n: value to round down
> > + */
> > +static inline __attribute__((const))
> > +u64 __rounddown_pow_of_two_u64(u64 n) {
> > +return 1ULL << (fls64(n) - 1);
> > +}
> > +
> > +/**
> >* const_ilog2 - log base 2 of 32-bit or a 64-bit constant unsigned value
> >* @n: parameter
> >*
> > @@ -163,6 +186,7 @@ unsigned long __rounddown_pow_of_two(uns
> > __ilog2_u64(n)\
> >)
> >
> > +
> > /**
> >* roundup_pow_of_two - round the given
Re: [PATCH] [RFC] drm/drm_buddy fails to initialize on 32-bit architectures
Hi,
Ping? This is actually a regression.
If there is no one available to work this, maybe I can have a look in
my spare time, in accordance with your suggestion.
Regards,
Luís
On Tue, Jan 3, 2023 at 8:44 AM Christian König wrote:
>
> Am 25.12.22 um 20:39 schrieb Luís Mendes:
> > Re-sending with the correct linux-kernel mailing list email address.
> > Sorry for the inconvenience.
> >
> > The proposed patch fixes the issue and allows amdgpu to work again on
> > armhf with a AMD RX 550 card, however it may not be the best solution
> > for the issue, as detailed below.
> >
> > include/log2.h defined macros rounddown_pow_of_two(...) and
> > roundup_pow_of_two(...) do not handle 64-bit values on 32-bit
> > architectures (tested on armv9 armhf machine) causing
> > drm_buddy_init(...) to fail on BUG_ON with an underflow on the order
> > value, thus impeding amdgpu to load properly (no GUI).
> >
> > One option is to modify rounddown_pow_of_two(...) to detect if the
> > variable takes 32 bits or less and call __rounddown_pow_of_two_u32(u32
> > n) or if the variable takes more space than 32 bits, then call
> > __rounddown_pow_of_two_u64(u64 n). This would imply renaming
> > __rounddown_pow_of_two(unsigne
> > d long n) to
> > __rounddown_pow_of_two_u32(u32 n) and add a new function
> > __rounddown_pow_of_two_u64(u64 n). This would be the most transparent
> > solution, however there a few complications, and they are:
> > - that the mm subsystem will fail to link on armhf with an undefined
> > reference on __aeabi_uldivmod
> > - there a few drivers that directly call __rounddown_pow_of_two(...)
> > - that other drivers and subsystems generate warnings
> >
> > So this alternate solution was devised which avoids touching existing
> > code paths, and just updates drm_buddy which seems to be the only
> > driver that is failing, however I am not sure if this is the proper
> > way to go. So I would like to get a second opinion on this, by those
> > who know.
> >
> > /include/linux/log2.h
> > /drivers/gpu/drm/drm_buddy.c
> >
> > Signed-off-by: Luís Mendes
> >> 8--8<
> > diff -uprN linux-next/drivers/gpu/drm/drm_buddy.c
> > linux-nextLM/drivers/gpu/drm/drm_buddy.c
> > --- linux-next/drivers/gpu/drm/drm_buddy.c2022-12-25
> > 16:29:26.0 +
> > +++ linux-nextLM/drivers/gpu/drm/drm_buddy.c2022-12-25
> > 17:04:32.136007116 +
> > @@ -128,7 +128,7 @@ int drm_buddy_init(struct drm_buddy *mm,
> > unsigned int order;
> > u64 root_size;
> >
> > -root_size = rounddown_pow_of_two(size);
> > +root_size = rounddown_pow_of_two_u64(size);
> > order = ilog2(root_size) - ilog2(chunk_size);
>
> I think this can be handled much easier if keep around the root_order
> instead of the root_size in the first place.
>
> Cause ilog2() does the right thing even for non power of two values and
> so we just need the order for the offset subtraction below.
>
> Arun can you take a closer look at this?
>
> Regards,
> Christian.
>
> >
> > root = drm_block_alloc(mm, NULL, order, offset);
> > diff -uprN linux-next/include/linux/log2.h linux-nextLM/include/linux/log2.h
> > --- linux-next/include/linux/log2.h2022-12-25 16:29:29.0 +
> > +++ linux-nextLM/include/linux/log2.h2022-12-25 17:00:34.319901492 +
> > @@ -58,6 +58,18 @@ unsigned long __roundup_pow_of_two(unsig
> > }
> >
> > /**
> > + * __roundup_pow_of_two_u64() - round up to nearest power of two
> > + * (unsgined 64-bits precision version)
> > + * @n: value to round up
> > + */
> > +static inline __attribute__((const))
> > +u64 __roundup_pow_of_two_u64(u64 n)
> > +{
> > +return 1ULL << fls64(n - 1);
> > +}
> > +
> > +
> > +/**
> >* __rounddown_pow_of_two() - round down to nearest power of two
> >* @n: value to round down
> >*/
> > @@ -68,6 +80,17 @@ unsigned long __rounddown_pow_of_two(uns
> > }
> >
> > /**
> > + * __rounddown_pow_of_two_u64() - round down to nearest power of two
> > + * (unsgined 64-bits precision version)
> > + * @n: value to round down
> > + */
> > +static inline __attribute__((const))
> > +u64 __rounddown_pow_of_two_u64(u64 n)
> > +{
> > +return 1ULL << (fls64(n) - 1);
> > +}
> > +
> > +/**
> >* const_ilog2 - log base 2 of 32-bit or a 64-bit constant unsigned value
> >* @n: parameter
> >*
> > @@ -163,6 +186,7 @@ unsigned long __rounddown_pow_of_two(uns
> > __ilog2_u64(n)\
> >)
> >
> > +
> > /**
> >* roundup_pow_of_two - round the given value up to nearest power of two
> >* @n: parameter
> > @@ -181,6 +205,25 @@ unsigned long __rounddown_pow_of_two(uns
> >)
> >
> > /**
> > + * roundup_pow_of_two_u64 - round the given value up to nearest power of
> > two
> > + * (unsgined 64-bits precision version)
> > + * @n: parameter
> > + *
> > + * round the given value up to the nearest power of two
> > + * - the result is undefined when n == 0
> > + * - this can be
Re: [PATCH v3 02/17] drm/connector: Add enum documentation to drm_colorspace
On Thu, 9 Mar 2023 01:56:11 +0100
Sebastian Wick wrote:
> On Wed, Mar 8, 2023 at 9:59 AM Pekka Paalanen wrote:
> >
> > On Tue, 7 Mar 2023 10:10:52 -0500
> > Harry Wentland wrote:
> >
> > > From: Joshua Ashton
> > >
> > > To match the other enums, and add more information about these values.
> > >
> > > v2:
> > > - Specify where an enum entry comes from
> > > - Clarify DEFAULT and NO_DATA behavior
> > > - BT.2020 CYCC is "constant luminance"
> > > - correct type for BT.601
> > >
> > > Signed-off-by: Joshua Ashton
> > > Signed-off-by: Harry Wentland
> > > Reviewed-by: Harry Wentland
> >
> > Hi,
> >
> > this effort is really good, but of course I still find things to
> > nitpick about. If there is no answer to my questions, then I would
> > prefer the documentation to spell out the unknowns and ambiguities.
> >
> > > Cc: Pekka Paalanen
> > > Cc: Sebastian Wick
> > > Cc: vitaly.pros...@amd.com
> > > Cc: Uma Shankar
> > > Cc: Ville Syrjälä
> > > Cc: Joshua Ashton
> > > Cc: dri-de...@lists.freedesktop.org
> > > Cc: amd-gfx@lists.freedesktop.org
> > > ---
> > > include/drm/drm_connector.h | 67 +++--
> > > 1 file changed, 65 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> > > index 6d6a53a6b010..bb078666dc34 100644
> > > --- a/include/drm/drm_connector.h
> > > +++ b/include/drm/drm_connector.h
> > > @@ -363,13 +363,76 @@ enum drm_privacy_screen_status {
> > > PRIVACY_SCREEN_ENABLED_LOCKED,
> > > };
> > >
> > > -/*
> > > - * This is a consolidated colorimetry list supported by HDMI and
> > > +/**
> > > + * enum drm_colorspace - color space
> > > + *
> > > + * This enum is a consolidated colorimetry list supported by HDMI and
> > > * DP protocol standard. The respective connectors will register
> > > * a property with the subset of this list (supported by that
> > > * respective protocol). Userspace will set the colorspace through
> > > * a colorspace property which will be created and exposed to
> > > * userspace.
> > > + *
> > > + * DP definitions come from the DP v2.0 spec
> > > + * HDMI definitions come from the CTA-861-H spec
> > > + *
> > > + * @DRM_MODE_COLORIMETRY_DEFAULT:
> > > + * Driver specific behavior.
> > > + * For DP:
> > > + * RGB encoded: sRGB (IEC 61966-2-1)
> > > + * YCbCr encoded: ITU-R BT.601 colorimetry format
> >
> > Does this mean that HDMI behavior is driver-specific while DP behavior
> > is as defined?
> >
> > Is it intentional that YCbCr encoding also uses different RGB-primaries
> > than RGB-encoded signal? (BT.601 vs. BT.709/sRGB)
> >
> > Or do you need to be more explicit on which parts of each spec apply
> > (ColourPrimaries vs. TransferCharacteristics vs. MatrixCoefficients in
> > CICP parlance)?
> >
> > E.g. BT.709/sRGB ColourPrimaries with BT.601 MatrixCoefficients.
>
> Yeah, just adding to this: The Default Colorspace is something well
> defined. CTA-861 says:
>
> "If bits C0 and C1 are zero, the colorimetry shall correspond to the
> default colorimetry defined in Section 5.1"
>
> and in Section 5.1
>
> "In all cases described above, the RGB color space used should be the
> RGB color space the Sink declares in the Basic Display Parameters and
> Feature Block of its EDID."
>
> If I set DRM_MODE_COLORIMETRY_DEFAULT, I expect the Colorimetry the
> EDID reports to be in effect and not some driver specific nonsense.
Does that also define the MatrixCoefficients for YCbCr signal with
DRM_MODE_COLORIMETRY_DEFAULT?
Not that userspace would even care, since RGB-to-YCbCr is all
driver-internal.
It is interesting you point that out. I guess it means that the basic
colorimetry from EDID is supposed to be really only the default
colorimetry and might not have anything to do with the actual panel
primaries.
Thanks,
pq
pgpHpfGocH9HG.pgp
Description: OpenPGP digital signature
[PATCH] drm/amd/pm: Remove unavailable temperature params
Temperature limits are not available for SMU v13.0.6. Also, edge
temperature is not tracked. Remove logic associated with those.
Signed-off-by: Lijo Lazar
Reviewed-by: Hawking Zhang
---
.../drm/amd/pm/swsmu/smu13/smu_v13_0_6_ppt.c | 43 ---
1 file changed, 43 deletions(-)
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_6_ppt.c
b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_6_ppt.c
index 862859bfb9e1..54d36df1306f 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_6_ppt.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_6_ppt.c
@@ -82,12 +82,6 @@
#define smnPCIE_ESM_CTRL 0x111003D0
-static const struct smu_temperature_range smu_v13_0_6_thermal_policy[] = {
- { -273150, 99000, 99000, -273150, 99000, 99000, -273150, 99000, 99000 },
- { 12, 12, 12, 12, 12, 12, 12, 12,
- 12 },
-};
-
static const struct cmn2asic_msg_mapping
smu_v13_0_6_message_map[SMU_MSG_MAX_COUNT] = {
MSG_MAP(TestMessage, PPSMC_MSG_TestMessage,
0),
MSG_MAP(GetSmuVersion, PPSMC_MSG_GetSmuVersion,
1),
@@ -701,9 +695,6 @@ static int smu_v13_0_6_get_smu_metrics_data(struct
smu_context *smu,
case METRICS_AVERAGE_SOCKETPOWER:
*value = SMUQ10_TO_UINT(metrics->SocketPower) << 8;
break;
- case METRICS_TEMPERATURE_EDGE:
- *value = 0;
- break;
case METRICS_TEMPERATURE_HOTSPOT:
*value = SMUQ10_TO_UINT(metrics->MaxSocketTemperature);
break;
@@ -1127,33 +1118,6 @@ static int smu_v13_0_6_force_clk_levels(struct
smu_context *smu,
return ret;
}
-static int
-smu_v13_0_6_get_thermal_temperature_range(struct smu_context *smu,
- struct smu_temperature_range *range)
-{
- uint8_t software_shutdown_temp;
- uint8_t hotspotlimit;
- uint8_t memlimit;
-
- if (!range)
- return -EINVAL;
-
- /* TODO: Find a way to get temperature limits */
- memcpy(range, _v13_0_6_thermal_policy[0],
- sizeof(struct smu_temperature_range));
-
- range->hotspot_crit_max =
- hotspotlimit * SMU_TEMPERATURE_UNITS_PER_CENTIGRADES;
- range->hotspot_emergency_max = (hotspotlimit + CTF_OFFSET_HOTSPOT) *
- SMU_TEMPERATURE_UNITS_PER_CENTIGRADES;
- range->mem_crit_max = memlimit * SMU_TEMPERATURE_UNITS_PER_CENTIGRADES;
- range->mem_emergency_max = (memlimit + CTF_OFFSET_MEM) *
- SMU_TEMPERATURE_UNITS_PER_CENTIGRADES;
- range->software_shutdown_temp = software_shutdown_temp;
-
- return 0;
-}
-
static int smu_v13_0_6_get_current_activity_percent(struct smu_context *smu,
enum amd_pp_sensors sensor,
uint32_t *value)
@@ -1204,10 +1168,6 @@ static int smu_v13_0_6_thermal_get_temperature(struct
smu_context *smu,
ret = smu_v13_0_6_get_smu_metrics_data(
smu, METRICS_TEMPERATURE_HOTSPOT, value);
break;
- case AMDGPU_PP_SENSOR_EDGE_TEMP:
- ret = smu_v13_0_6_get_smu_metrics_data(
- smu, METRICS_TEMPERATURE_EDGE, value);
- break;
case AMDGPU_PP_SENSOR_MEM_TEMP:
ret = smu_v13_0_6_get_smu_metrics_data(
smu, METRICS_TEMPERATURE_MEM, value);
@@ -1244,7 +1204,6 @@ static int smu_v13_0_6_read_sensor(struct smu_context
*smu,
*size = 4;
break;
case AMDGPU_PP_SENSOR_HOTSPOT_TEMP:
- case AMDGPU_PP_SENSOR_EDGE_TEMP:
case AMDGPU_PP_SENSOR_MEM_TEMP:
ret = smu_v13_0_6_thermal_get_temperature(smu, sensor,
(uint32_t *)data);
@@ -2048,8 +2007,6 @@ static const struct pptable_funcs smu_v13_0_6_ppt_funcs =
{
/* dpm/clk tables */
.set_default_dpm_table = smu_v13_0_6_set_default_dpm_table,
.populate_umd_state_clk = smu_v13_0_6_populate_umd_state_clk,
- .get_thermal_temperature_range =
- smu_v13_0_6_get_thermal_temperature_range,
.print_clk_levels = smu_v13_0_6_print_clk_levels,
.force_clk_levels = smu_v13_0_6_force_clk_levels,
.read_sensor = smu_v13_0_6_read_sensor,
--
2.25.1
Re: [RFC v2 0/6] drm/amd/display: Pass proper parent for DM backlight device v2
Hi all, On 3/8/23 23:10, Hans de Goede wrote: > Hi, > > On 3/8/23 22:58, Hans de Goede wrote: >> Hi All, >> >> Here is version 2 of my patch series to pass the proper parent device >> to backlight_device_register(). >> >> New in version 2 is delaying the registering of the backlight_dev till >> after the drm_connector is registered by doing it from >> drm_connector_funcs.late_register. >> >> This involves first reworking the code a bit to allow delaying >> the registering, so this has turned from a single patch into >> a 6 patch set. >> >> Regards, >> >> Hans > > p.s. > > Like last time this series is marked as RFC because I don't have hw > to test the fix myself. The previous version was tested by 2 reporters > of: https://gitlab.gnome.org/GNOME/gnome-settings-daemon/-/issues/730 > > I hope to get test results from them for this new version soon. I just heard back from one of the reporters that this fixes gnome-settings-daemon picking the wrong backlight device on a hybrid gfx laptop where both GPU-s register a native backlight control. So this series no longer is RFC, but is ready for merging (from my pov) now. Regards, Hans >> Hans de Goede (6): >> drm/amd/display/amdgpu_dm: Fix backlight_device_register() error >> handling >> drm/amd/display/amdgpu_dm: Refactor register_backlight_device() >> drm/amd/display/amdgpu_dm: Add a bl_idx to amdgpu_dm_connector >> drm/amd/display/amdgpu_dm: Move most backlight setup into >> setup_backlight_device() >> drm/amd/display/amdgpu_dm: Make amdgpu_dm_register_backlight_device() >> take an amdgpu_dm_connector >> drm/amd/display: Pass proper parent for DM backlight device >> registration v2 >> >> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 99 --- >> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 1 + >> 2 files changed, 44 insertions(+), 56 deletions(-) >> >
Re: [PATCH 2/2] drm/probe_helper: warning on poll_enabled for issue catching
On 09/03/2023 07:48, Guchun Chen wrote:
In order to catch issues in other drivers to ensure proper call
sequence of polling function.
Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2411
Fixes: a4e771729a51("drm/probe_helper: sort out poll_running vs poll_enabled")
Previously it was suggested that this is not a fix, so the Fixes header
is incorrect.
Also please use -vN when preparing/sending patchsets. This is v2.
Reported-by: Bert Karwatzki
Suggested-by: Dmitry Baryshkov
Signed-off-by: Guchun Chen
---
drivers/gpu/drm/drm_probe_helper.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/drm_probe_helper.c
b/drivers/gpu/drm/drm_probe_helper.c
index 8127be134c39..85e0e80d4a52 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@ -852,6 +852,8 @@ EXPORT_SYMBOL(drm_kms_helper_is_poll_worker);
*/
void drm_kms_helper_poll_disable(struct drm_device *dev)
{
+ WARN_ON(!dev->mode_config.poll_enabled);
+
if (dev->mode_config.poll_running)
drm_kms_helper_disable_hpd(dev);
--
With best wishes
Dmitry
Re: [PATCH 9/9] drm: move ttm_execbuf_util into vmwgfx
Hi, On 3/9/23 06:14, Zack Rusin wrote: On Wed, 2023-03-08 at 10:10 +0100, Christian König wrote: Am 08.03.23 um 06:14 schrieb Zack Rusin: On Tue, 2023-02-28 at 09:34 +0100, Christian König wrote: VMWGFX is the only remaining user of this and should probably moved over to drm_exec when it starts using GEM as well. Is this because vmwgfx piggybacks buffer-id relocations on top of ttm validations or did you just find it too hard to port it over? I'd prefer to avoid ttm moves to vmwgfx and at least have a clear idea of what we need to do to port. I've just found it to hard to port it over because vmwgfx does some strange things with the validation code here. If you want we can take a deeper look at this together, but I need to find some time. Alternatively just tell me how to do it and I will add that to the patch set :) I don't want to hold up the set (it looks good btw), because I had to look at something else today and tomorrow. We overload the validation lists to do quite a bit more than just reservations though. There are, I think, four separate things that need to be refactored there (Christian, feel free to skip this section, this is mainly for VMware folks on the team): 1) Relocations - userspace uses the id's of the bo's in the command stream, but on the kernel side those id's are different (or in vmwgfx terminology gem id != mob id), so the buffer id's in the command stream need to be replaced, 2) Resource validation. vmwgfx splits the userspace objects into buffers and resources (shaders, surfaces, contexts). The resources are not buffers but are backed by them. A single buffer can back multiple different resources and sometimes the kernel has to actually allocate a buffer to back a resource and attach it to it (i.e. in common terminology buffer is the memory and resources are placed in it) . Now this shouldn't be in the kernel at all, the resources shouldn't have been kernel objects and instead we should have left them completely to userspace. The reason behind this is partly historical, since initially the resources (IIRC surfaces and shaders at that time), were per-device and not per context and not backed by buffer objects. The main reason for not doing the transition to user-space for resources was the SVGA device "between-draw-call-validation". If you for example unbound a mob that was backing a resource that was bound to a context, you'd need to start a whole chain of resource invalidations to avoid the device complaining about invalid setups at awkward moments, for example when it felt like suspending. Not sure whether that is gone now though, or whether there are better ways to handle that. /Thomas 3) Coherency tracking. We use validation lists as a central place for tracking which bo's/resources are used in a command buffer and we use it to keep track of which buffers/resources will endup dirty to implement coherency. 4) Central place to allocate memory for relocation/validation nodes. Where we want to endup is with 2 completely gone from the kernel side and 1, 3 and 4 refactored and cleaned up. I think there's at least 4 separate patches to this port, so it's not a trivial thing. We will take a look at this on Friday in more detail to see what we can do. z
Re: [PATCH 9/9] drm: move ttm_execbuf_util into vmwgfx
On 3/8/23 10:10, Christian König wrote: Am 08.03.23 um 06:14 schrieb Zack Rusin: On Tue, 2023-02-28 at 09:34 +0100, Christian König wrote: VMWGFX is the only remaining user of this and should probably moved over to drm_exec when it starts using GEM as well. Is this because vmwgfx piggybacks buffer-id relocations on top of ttm validations or did you just find it too hard to port it over? I'd prefer to avoid ttm moves to vmwgfx and at least have a clear idea of what we need to do to port. I've just found it to hard to port it over because vmwgfx does some strange things with the validation code here. If you want we can take a deeper look at this together, but I need to find some time. Alternatively just tell me how to do it and I will add that to the patch set :) Regards, Christian. Hmm. It turns out Xe was using these from the very start as well. But I will take a look at what it take to deprecate that usage, so don't let that stop this removal. We need a more flexible WW transaction handling anyway. /Thomas z
