[PATCH V3 6/7] drm/amd/pm: enable Wifi RFI mitigation feature support for SMU13.0.0

2023-06-15 Thread Evan Quan
Fulfill the SMU13.0.0 support for Wifi RFI mitigation feature.

Signed-off-by: Evan Quan 
---
 drivers/gpu/drm/amd/pm/swsmu/inc/amdgpu_smu.h |  3 +
 drivers/gpu/drm/amd/pm/swsmu/inc/smu_types.h  |  3 +-
 drivers/gpu/drm/amd/pm/swsmu/inc/smu_v13_0.h  |  3 +
 .../gpu/drm/amd/pm/swsmu/smu13/smu_v13_0.c|  9 +++
 .../drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c  | 60 +++
 5 files changed, 77 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/pm/swsmu/inc/amdgpu_smu.h 
b/drivers/gpu/drm/amd/pm/swsmu/inc/amdgpu_smu.h
index aa63cc43d41c..a8a4be32cc59 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/inc/amdgpu_smu.h
+++ b/drivers/gpu/drm/amd/pm/swsmu/inc/amdgpu_smu.h
@@ -323,6 +323,7 @@ enum smu_table_id
SMU_TABLE_PACE,
SMU_TABLE_ECCINFO,
SMU_TABLE_COMBO_PPTABLE,
+   SMU_TABLE_WIFIBAND,
SMU_TABLE_COUNT,
 };
 
@@ -1496,6 +1497,8 @@ enum smu_baco_seq {
 __dst_size);  \
 })
 
+#define HZ_IN_MHZ  100U
+
 #if !defined(SWSMU_CODE_LAYER_L2) && !defined(SWSMU_CODE_LAYER_L3) && 
!defined(SWSMU_CODE_LAYER_L4)
 int smu_get_power_limit(void *handle,
uint32_t *limit,
diff --git a/drivers/gpu/drm/amd/pm/swsmu/inc/smu_types.h 
b/drivers/gpu/drm/amd/pm/swsmu/inc/smu_types.h
index 297b70b9388f..5bbb60289a79 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/inc/smu_types.h
+++ b/drivers/gpu/drm/amd/pm/swsmu/inc/smu_types.h
@@ -245,7 +245,8 @@
__SMU_DUMMY_MAP(AllowGpo),  \
__SMU_DUMMY_MAP(Mode2Reset),\
__SMU_DUMMY_MAP(RequestI2cTransaction), \
-   __SMU_DUMMY_MAP(GetMetricsTable),
+   __SMU_DUMMY_MAP(GetMetricsTable), \
+   __SMU_DUMMY_MAP(EnableUCLKShadow),
 
 #undef __SMU_DUMMY_MAP
 #define __SMU_DUMMY_MAP(type)  SMU_MSG_##type
diff --git a/drivers/gpu/drm/amd/pm/swsmu/inc/smu_v13_0.h 
b/drivers/gpu/drm/amd/pm/swsmu/inc/smu_v13_0.h
index df3baaab0037..b6fae9b92303 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/inc/smu_v13_0.h
+++ b/drivers/gpu/drm/amd/pm/swsmu/inc/smu_v13_0.h
@@ -303,5 +303,8 @@ int smu_v13_0_get_pptable_from_firmware(struct smu_context 
*smu,
uint32_t *size,
uint32_t pptable_id);
 
+int smu_v13_0_enable_uclk_shadow(struct smu_context *smu,
+bool enablement);
+
 #endif
 #endif
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0.c 
b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0.c
index 393c6a7b9609..8c2230d1d862 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0.c
@@ -2453,3 +2453,12 @@ int smu_v13_0_mode1_reset(struct smu_context *smu)
 
return ret;
 }
+
+int smu_v13_0_enable_uclk_shadow(struct smu_context *smu,
+bool enablement)
+{
+   return smu_cmn_send_smc_msg_with_param(smu,
+  SMU_MSG_EnableUCLKShadow,
+  enablement,
+  NULL);
+}
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c 
b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c
index 09405ef1e3c8..cf75feaee779 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c
@@ -155,6 +155,7 @@ static struct cmn2asic_msg_mapping 
smu_v13_0_0_message_map[SMU_MSG_MAX_COUNT] =
MSG_MAP(AllowGpo,   PPSMC_MSG_SetGpoAllow,  
 0),
MSG_MAP(AllowIHHostInterrupt,   PPSMC_MSG_AllowIHHostInterrupt, 
  0),
MSG_MAP(ReenableAcDcInterrupt,  
PPSMC_MSG_ReenableAcDcInterrupt,   0),
+   MSG_MAP(EnableUCLKShadow,   PPSMC_MSG_EnableUCLKShadow, 
   0),
 };
 
 static struct cmn2asic_mapping smu_v13_0_0_clk_map[SMU_CLK_COUNT] = {
@@ -235,6 +236,7 @@ static struct cmn2asic_mapping 
smu_v13_0_0_table_map[SMU_TABLE_COUNT] = {
TAB_MAP(DRIVER_SMU_CONFIG),
TAB_MAP(ACTIVITY_MONITOR_COEFF),
[SMU_TABLE_COMBO_PPTABLE] = {1, TABLE_COMBO_PPTABLE},
+   TAB_MAP(WIFIBAND),
TAB_MAP(I2C_COMMANDS),
TAB_MAP(ECCINFO),
 };
@@ -472,6 +474,9 @@ static int smu_v13_0_0_tables_init(struct smu_context *smu)
PAGE_SIZE, AMDGPU_GEM_DOMAIN_VRAM);
SMU_TABLE_INIT(tables, SMU_TABLE_ECCINFO, sizeof(EccInfoTable_t),
PAGE_SIZE, AMDGPU_GEM_DOMAIN_VRAM);
+   SMU_TABLE_INIT(tables, SMU_TABLE_WIFIBAND,
+  sizeof(WifiBandEntryTable_t), PAGE_SIZE,
+  AMDGPU_GEM_DOMAIN_VRAM);
 
smu_table->metrics_table = kzalloc(sizeof(SmuMetricsExternal_t), 
GFP_KERNEL);
if (!smu_table->metrics_table)
@@ -2112,6 +2117,58 @@ static ssize_t smu_v13_0_0_get_ecc_info(struct 
smu_context *smu,
return ret;
 }
 
+static bool smu_v13_0_0_wbrf_support_check(struct smu_context *

[PATCH V3 7/7] drm/amd/pm: enable Wifi RFI mitigation feature support for SMU13.0.7

2023-06-15 Thread Evan Quan
Fulfill the SMU13.0.7 support for Wifi RFI mitigation feature.

Signed-off-by: Evan Quan 
---
 .../drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.c  | 59 +++
 1 file changed, 59 insertions(+)

diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.c 
b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.c
index 98a33f8ee209..16c1c04e2034 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.c
@@ -125,6 +125,7 @@ static struct cmn2asic_msg_mapping 
smu_v13_0_7_message_map[SMU_MSG_MAX_COUNT] =
MSG_MAP(ArmD3,  PPSMC_MSG_ArmD3,
   0),
MSG_MAP(AllowGpo,   PPSMC_MSG_SetGpoAllow,  
 0),
MSG_MAP(GetPptLimit,PPSMC_MSG_GetPptLimit,  
   0),
+   MSG_MAP(EnableUCLKShadow,   PPSMC_MSG_EnableUCLKShadow, 
   0),
 };
 
 static struct cmn2asic_mapping smu_v13_0_7_clk_map[SMU_CLK_COUNT] = {
@@ -205,6 +206,7 @@ static struct cmn2asic_mapping 
smu_v13_0_7_table_map[SMU_TABLE_COUNT] = {
TAB_MAP(DRIVER_SMU_CONFIG),
TAB_MAP(ACTIVITY_MONITOR_COEFF),
[SMU_TABLE_COMBO_PPTABLE] = {1, TABLE_COMBO_PPTABLE},
+   TAB_MAP(WIFIBAND),
 };
 
 static struct cmn2asic_mapping smu_v13_0_7_pwr_src_map[SMU_POWER_SOURCE_COUNT] 
= {
@@ -487,6 +489,9 @@ static int smu_v13_0_7_tables_init(struct smu_context *smu)
   AMDGPU_GEM_DOMAIN_VRAM);
SMU_TABLE_INIT(tables, SMU_TABLE_COMBO_PPTABLE, 
MP0_MP1_DATA_REGION_SIZE_COMBOPPTABLE,
PAGE_SIZE, AMDGPU_GEM_DOMAIN_VRAM);
+   SMU_TABLE_INIT(tables, SMU_TABLE_WIFIBAND,
+  sizeof(WifiBandEntryTable_t), PAGE_SIZE,
+  AMDGPU_GEM_DOMAIN_VRAM);
 
smu_table->metrics_table = kzalloc(sizeof(SmuMetricsExternal_t), 
GFP_KERNEL);
if (!smu_table->metrics_table)
@@ -1721,6 +1726,57 @@ static int smu_v13_0_7_set_df_cstate(struct smu_context 
*smu,
   NULL);
 }
 
+static bool smu_v13_0_7_wbrf_support_check(struct smu_context *smu)
+{
+   return smu->smc_fw_version > 0x00524600;
+}
+
+static int smu_v13_0_7_set_wbrf_exclusion_ranges(struct smu_context *smu,
+struct exclusion_range 
*exclusion_ranges)
+{
+   WifiBandEntryTable_t wifi_bands;
+   int valid_entries = 0;
+   int ret, i;
+
+   memset(&wifi_bands, 0, sizeof(wifi_bands));
+   for (i = 0; i < ARRAY_SIZE(wifi_bands.WifiBandEntry); i++) {
+   if (!exclusion_ranges[i].start &&
+   !exclusion_ranges[i].end)
+   break;
+
+   /* PMFW expects the inputs to be in Mhz unit */
+   wifi_bands.WifiBandEntry[valid_entries].LowFreq =
+   DIV_ROUND_DOWN_ULL(exclusion_ranges[i].start, 
HZ_IN_MHZ);
+   wifi_bands.WifiBandEntry[valid_entries++].HighFreq =
+   DIV_ROUND_UP_ULL(exclusion_ranges[i].end, HZ_IN_MHZ);
+   }
+   wifi_bands.WifiBandEntryNum = valid_entries;
+
+   /*
+* Per confirm with PMFW team, WifiBandEntryNum = 0 is a valid setting.
+* Considering the scenarios below:
+* - At first the wifi device adds an exclusion range e.g. (2400,2500) 
to
+*   BIOS and our driver gets notified. We will set WifiBandEntryNum = 1
+*   and pass the WifiBandEntry (2400, 2500) to PMFW.
+*
+* - Later the wifi device removes the wifiband list added above and
+*   our driver gets notified again. At this time, driver will set
+*   WifiBandEntryNum = 0 and pass an empty WifiBandEntry list to PMFW.
+*   - PMFW may still need to do some uclk shadow update(e.g. switching
+* from shadow clock back to primary clock) on receiving this.
+*/
+
+   ret = smu_cmn_update_table(smu,
+  SMU_TABLE_WIFIBAND,
+  0,
+  (void *)(&wifi_bands),
+  true);
+   if (ret)
+   dev_err(smu->adev->dev, "Failed to set wifiband!");
+
+   return ret;
+}
+
 static const struct pptable_funcs smu_v13_0_7_ppt_funcs = {
.get_allowed_feature_mask = smu_v13_0_7_get_allowed_feature_mask,
.set_default_dpm_table = smu_v13_0_7_set_default_dpm_table,
@@ -1786,6 +1842,9 @@ static const struct pptable_funcs smu_v13_0_7_ppt_funcs = 
{
.set_mp1_state = smu_v13_0_7_set_mp1_state,
.set_df_cstate = smu_v13_0_7_set_df_cstate,
.gpo_control = smu_v13_0_gpo_control,
+   .is_asic_wbrf_supported = smu_v13_0_7_wbrf_support_check,
+   .enable_uclk_shadow = smu_v13_0_enable_uclk_shadow,
+   .set_wbrf_exclusion_ranges = smu_v13_0_7_set_wbrf_exclusion_ranges,
 };
 
 void smu_v13_0_7_set_ppt_funcs(struct smu_context *smu)
-- 
2.34.1



[PATCH V3 5/7] drm/amd/pm: add flood detection for wbrf events

2023-06-15 Thread Evan Quan
To protect PMFW from being overloaded.

Signed-off-by: Evan Quan 
---
 drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c | 28 ---
 drivers/gpu/drm/amd/pm/swsmu/inc/amdgpu_smu.h |  7 +
 2 files changed, 31 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c 
b/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
index 89f876cc60e6..2619e310ef54 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
@@ -1272,6 +1272,22 @@ static void smu_wbrf_event_handler(struct amdgpu_device 
*adev)
 {
struct smu_context *smu = adev->powerplay.pp_handle;
 
+   schedule_delayed_work(&smu->wbrf_delayed_work,
+ msecs_to_jiffies(SMU_WBRF_EVENT_HANDLING_PACE));
+}
+
+/**
+ * smu_wbrf_delayed_work_handler - callback on delayed work timer expired
+ *
+ * @work: struct work_struct pointer
+ *
+ * Flood is over and driver will consume the latest exclusion ranges.
+ */
+static void smu_wbrf_delayed_work_handler(struct work_struct *work)
+{
+   struct smu_context *smu =
+   container_of(work, struct smu_context, wbrf_delayed_work.work);
+
smu_wbrf_handle_exclusion_ranges(smu);
 }
 
@@ -1311,6 +1327,9 @@ static int smu_wbrf_init(struct smu_context *smu)
if (!smu->wbrf_supported)
return 0;
 
+   INIT_DELAYED_WORK(&smu->wbrf_delayed_work,
+ smu_wbrf_delayed_work_handler);
+
ret = amdgpu_acpi_register_wbrf_notify_handler(adev,
   smu_wbrf_event_handler);
if (ret)
@@ -1321,11 +1340,10 @@ static int smu_wbrf_init(struct smu_context *smu)
 * before our driver loaded. To make sure our driver
 * is awared of those exclusion ranges.
 */
-   ret = smu_wbrf_handle_exclusion_ranges(smu);
-   if (ret)
-   dev_err(adev->dev, "Failed to handle wbrf exclusion ranges\n");
+   schedule_delayed_work(&smu->wbrf_delayed_work,
+ msecs_to_jiffies(SMU_WBRF_EVENT_HANDLING_PACE));
 
-   return ret;
+   return 0;
 }
 
 /**
@@ -1343,6 +1361,8 @@ static void smu_wbrf_fini(struct smu_context *smu)
return;
 
amdgpu_acpi_unregister_wbrf_notify_handler(adev);
+
+   cancel_delayed_work_sync(&smu->wbrf_delayed_work);
 }
 
 static int smu_smc_hw_setup(struct smu_context *smu)
diff --git a/drivers/gpu/drm/amd/pm/swsmu/inc/amdgpu_smu.h 
b/drivers/gpu/drm/amd/pm/swsmu/inc/amdgpu_smu.h
index ff0af3da0be2..aa63cc43d41c 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/inc/amdgpu_smu.h
+++ b/drivers/gpu/drm/amd/pm/swsmu/inc/amdgpu_smu.h
@@ -478,6 +478,12 @@ struct stb_context {
 
 #define WORKLOAD_POLICY_MAX 7
 
+/*
+ * Configure wbrf event handling pace as there can be only one
+ * event processed every SMU_WBRF_EVENT_HANDLING_PACE ms.
+ */
+#define SMU_WBRF_EVENT_HANDLING_PACE   10
+
 struct smu_context
 {
struct amdgpu_device*adev;
@@ -576,6 +582,7 @@ struct smu_context
 
/* data structures for wbrf feature support */
boolwbrf_supported;
+   struct delayed_work wbrf_delayed_work;
 };
 
 struct i2c_adapter;
-- 
2.34.1



[PATCH V3 4/7] drm/amd/pm: setup the framework to support Wifi RFI mitigation feature

2023-06-15 Thread Evan Quan
With WBRF feature supported, as a driver responding to the frequencies,
amdgpu driver is able to do shadow pstate switching to mitigate possible
interference(between its (G-)DDR memory clocks and local radio module
frequency bands used by Wifi 6/6e/7).

To make WBRF feature functional, the kernel needs to be configured with
CONFIG_ACPI_WBRF and the platform is equipped with necessary ACPI based
mechanism to get amdgpu driver notified.

Signed-off-by: Evan Quan 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu.h   |  26 +++
 drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c  |  63 ++
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c   |  19 ++
 drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c | 184 ++
 drivers/gpu/drm/amd/pm/swsmu/inc/amdgpu_smu.h |  20 ++
 drivers/gpu/drm/amd/pm/swsmu/smu_internal.h   |   3 +
 6 files changed, 315 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 02b827785e39..2f2ec64ed1b2 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -50,6 +50,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -241,6 +242,7 @@ extern int amdgpu_num_kcq;
 #define AMDGPU_VCNFW_LOG_SIZE (32 * 1024)
 extern int amdgpu_vcnfw_log;
 extern int amdgpu_sg_display;
+extern int amdgpu_wbrf;
 
 #define AMDGPU_VM_MAX_NUM_CTX  4096
 #define AMDGPU_SG_THRESHOLD(256*1024*1024)
@@ -741,6 +743,9 @@ struct amdgpu_reset_domain;
  */
 #define AMDGPU_HAS_VRAM(_adev) ((_adev)->gmc.real_vram_size)
 
+typedef
+void (*wbrf_notify_handler) (struct amdgpu_device *adev);
+
 struct amdgpu_device {
struct device   *dev;
struct pci_dev  *pdev;
@@ -1050,6 +1055,8 @@ struct amdgpu_device {
 
booljob_hang;
booldc_enabled;
+
+   wbrf_notify_handler wbrf_event_handler;
 };
 
 static inline struct amdgpu_device *drm_to_adev(struct drm_device *ddev)
@@ -1381,6 +1388,25 @@ static inline int amdgpu_acpi_smart_shift_update(struct 
drm_device *dev,
 enum amdgpu_ss ss_state) { 
return 0; }
 #endif
 
+#if defined(CONFIG_ACPI_WBRF)
+bool amdgpu_acpi_is_wbrf_supported(struct amdgpu_device *adev);
+int amdgpu_acpi_wbrf_retrieve_exclusions(struct amdgpu_device *adev,
+struct wbrf_ranges_out 
*exclusions_out);
+int amdgpu_acpi_register_wbrf_notify_handler(struct amdgpu_device *adev,
+wbrf_notify_handler handler);
+int amdgpu_acpi_unregister_wbrf_notify_handler(struct amdgpu_device *adev);
+#else
+static inline bool amdgpu_acpi_is_wbrf_supported(struct amdgpu_device *adev) { 
return false; }
+static inline
+int amdgpu_acpi_wbrf_retrieve_exclusions(struct amdgpu_device *adev,
+struct wbrf_ranges_out 
*exclusions_out) { return 0; }
+static inline
+int amdgpu_acpi_register_wbrf_notify_handler(struct amdgpu_device *adev,
+wbrf_notify_handler handler) { 
return 0; }
+static inline
+int amdgpu_acpi_unregister_wbrf_notify_handler(struct amdgpu_device *adev) { 
return 0; }
+#endif
+
 #if defined(CONFIG_ACPI) && defined(CONFIG_SUSPEND)
 bool amdgpu_acpi_is_s3_active(struct amdgpu_device *adev);
 bool amdgpu_acpi_is_s0ix_active(struct amdgpu_device *adev);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
index aeeec211861c..efbe6dd91d1a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
@@ -1105,3 +1105,66 @@ bool amdgpu_acpi_is_s0ix_active(struct amdgpu_device 
*adev)
 }
 
 #endif /* CONFIG_SUSPEND */
+
+#ifdef CONFIG_ACPI_WBRF
+bool amdgpu_acpi_is_wbrf_supported(struct amdgpu_device *adev)
+{
+   struct acpi_device *acpi_dev = ACPI_COMPANION(adev->dev);
+
+   if (!acpi_dev)
+   return false;
+
+   return wbrf_supported_consumer(acpi_dev);
+}
+
+int amdgpu_acpi_wbrf_retrieve_exclusions(struct amdgpu_device *adev,
+struct wbrf_ranges_out *exclusions_out)
+{
+   struct acpi_device *acpi_dev = ACPI_COMPANION(adev->dev);
+
+   if (!acpi_dev)
+   return -ENODEV;
+
+   return wbrf_retrieve_exclusions(acpi_dev, exclusions_out);
+}
+
+#define CPM_GPU_NOTIFY_COMMAND 0x55
+static void amdgpu_acpi_wbrf_event(acpi_handle handle, u32 event, void *data)
+{
+   struct amdgpu_device *adev = (struct amdgpu_device *)data;
+
+   if (event == CPM_GPU_NOTIFY_COMMAND &&
+   adev->wbrf_event_handler)
+   adev->wbrf_event_handler(adev);
+}
+
+int amdgpu_acpi_register_wbrf_notify_handler(struct amdgpu_device *adev,
+wbrf_notify_handler handler)
+{
+   struct acpi_handle *acpi_hdler = ACPI_HANDLE(adev->dev);

[PATCH V3 3/7] drm/amd/pm: update driver_if and ppsmc headers for coming wbrf feature

2023-06-15 Thread Evan Quan
Add those data structures to support Wifi RFI mitigation feature.

Signed-off-by: Evan Quan 
---
 .../pm/swsmu/inc/pmfw_if/smu13_driver_if_v13_0_0.h | 14 +-
 .../pm/swsmu/inc/pmfw_if/smu13_driver_if_v13_0_7.h | 14 +-
 .../amd/pm/swsmu/inc/pmfw_if/smu_v13_0_0_ppsmc.h   |  3 ++-
 .../amd/pm/swsmu/inc/pmfw_if/smu_v13_0_7_ppsmc.h   |  3 ++-
 4 files changed, 30 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/amd/pm/swsmu/inc/pmfw_if/smu13_driver_if_v13_0_0.h 
b/drivers/gpu/drm/amd/pm/swsmu/inc/pmfw_if/smu13_driver_if_v13_0_0.h
index b686fb68a6e7..d64188fb5839 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/inc/pmfw_if/smu13_driver_if_v13_0_0.h
+++ b/drivers/gpu/drm/amd/pm/swsmu/inc/pmfw_if/smu13_driver_if_v13_0_0.h
@@ -388,6 +388,17 @@ typedef struct {
   EccInfo_t  EccInfo[24];
 } EccInfoTable_t;
 
+typedef struct {
+  uint16_t LowFreq;
+  uint16_t HighFreq;
+} WifiOneBand_t;
+
+typedef struct {
+  uint32_t WifiBandEntryNum;
+  WifiOneBand_tWifiBandEntry[11];
+  uint32_t MmHubPadding[8];
+} WifiBandEntryTable_t;
+
 //D3HOT sequences
 typedef enum {
   BACO_SEQUENCE,
@@ -1592,7 +1603,8 @@ typedef struct {
 #define TABLE_I2C_COMMANDS9
 #define TABLE_DRIVER_INFO 10
 #define TABLE_ECCINFO 11
-#define TABLE_COUNT   12
+#define TABLE_WIFIBAND12
+#define TABLE_COUNT   13
 
 //IH Interupt ID
 #define IH_INTERRUPT_ID_TO_DRIVER   0xFE
diff --git a/drivers/gpu/drm/amd/pm/swsmu/inc/pmfw_if/smu13_driver_if_v13_0_7.h 
b/drivers/gpu/drm/amd/pm/swsmu/inc/pmfw_if/smu13_driver_if_v13_0_7.h
index 4c46a0392451..77483e8485e7 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/inc/pmfw_if/smu13_driver_if_v13_0_7.h
+++ b/drivers/gpu/drm/amd/pm/swsmu/inc/pmfw_if/smu13_driver_if_v13_0_7.h
@@ -392,6 +392,17 @@ typedef struct {
   EccInfo_t  EccInfo[24];
 } EccInfoTable_t;
 
+typedef struct {
+  uint16_t LowFreq;
+  uint16_t HighFreq;
+} WifiOneBand_t;
+
+typedef struct {
+  uint32_t WifiBandEntryNum;
+  WifiOneBand_tWifiBandEntry[11];
+  uint32_t MmHubPadding[8];
+} WifiBandEntryTable_t;
+
 //D3HOT sequences
 typedef enum {
   BACO_SEQUENCE,
@@ -1624,7 +1635,8 @@ typedef struct {
 #define TABLE_I2C_COMMANDS9
 #define TABLE_DRIVER_INFO 10
 #define TABLE_ECCINFO 11
-#define TABLE_COUNT   12
+#define TABLE_WIFIBAND12
+#define TABLE_COUNT   13
 
 //IH Interupt ID
 #define IH_INTERRUPT_ID_TO_DRIVER   0xFE
diff --git a/drivers/gpu/drm/amd/pm/swsmu/inc/pmfw_if/smu_v13_0_0_ppsmc.h 
b/drivers/gpu/drm/amd/pm/swsmu/inc/pmfw_if/smu_v13_0_0_ppsmc.h
index 10cff75b44d5..c98cc32d11bd 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/inc/pmfw_if/smu_v13_0_0_ppsmc.h
+++ b/drivers/gpu/drm/amd/pm/swsmu/inc/pmfw_if/smu_v13_0_0_ppsmc.h
@@ -138,7 +138,8 @@
 #define PPSMC_MSG_SetBadMemoryPagesRetiredFlagsPerChannel 0x4A
 #define PPSMC_MSG_SetPriorityDeltaGain   0x4B
 #define PPSMC_MSG_AllowIHHostInterrupt   0x4C
-#define PPSMC_Message_Count  0x4D
+#define PPSMC_MSG_EnableUCLKShadow   0x51
+#define PPSMC_Message_Count  0x52
 
 //Debug Dump Message
 #define DEBUGSMC_MSG_TestMessage0x1
diff --git a/drivers/gpu/drm/amd/pm/swsmu/inc/pmfw_if/smu_v13_0_7_ppsmc.h 
b/drivers/gpu/drm/amd/pm/swsmu/inc/pmfw_if/smu_v13_0_7_ppsmc.h
index 6aaefca9b595..a6bf9cdd130e 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/inc/pmfw_if/smu_v13_0_7_ppsmc.h
+++ b/drivers/gpu/drm/amd/pm/swsmu/inc/pmfw_if/smu_v13_0_7_ppsmc.h
@@ -134,6 +134,7 @@
 #define PPSMC_MSG_SetBadMemoryPagesRetiredFlagsPerChannel 0x4A
 #define PPSMC_MSG_SetPriorityDeltaGain   0x4B
 #define PPSMC_MSG_AllowIHHostInterrupt   0x4C
-#define PPSMC_Message_Count  0x4D
+#define PPSMC_MSG_EnableUCLKShadow   0x51
+#define PPSMC_Message_Count  0x52
 
 #endif
-- 
2.34.1



[PATCH V3 2/7] wifi: mac80211: Add support for ACPI WBRF

2023-06-15 Thread Evan Quan
From: Mario Limonciello 

To support AMD's WBRF interference mitigation mechanism, Wifi adapters
utilized in the system must register the frequencies in use(or unregister
those frequencies no longer used) via the dedicated APCI calls. So that,
other drivers responding to the frequencies can take proper actions to
mitigate possible interference.

To make WBRF feature functional, the kernel needs to be configured with
CONFIG_ACPI_WBRF and the platform is equipped with WBRF support(from
BIOS and drivers).

Signed-off-by: Mario Limonciello 
Co-developed-by: Evan Quan 
Signed-off-by: Evan Quan 
--
v1->v2:
  - place the new added member(`wbrf_supported`) in
ieee80211_local(Johannes)
  - handle chandefs change scenario properly(Johannes)
  - some minor fixes around code sharing and possible invalid input
checks(Johannes)
---
 include/net/cfg80211.h |   8 +++
 net/mac80211/Makefile  |   2 +
 net/mac80211/chan.c|  11 +++
 net/mac80211/ieee80211_i.h |  19 +
 net/mac80211/main.c|   2 +
 net/mac80211/wbrf.c| 137 +
 net/wireless/chan.c|   3 +-
 7 files changed, 181 insertions(+), 1 deletion(-)
 create mode 100644 net/mac80211/wbrf.c

diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 9e04f69712b1..c6dc337eafce 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -920,6 +920,14 @@ const struct cfg80211_chan_def *
 cfg80211_chandef_compatible(const struct cfg80211_chan_def *chandef1,
const struct cfg80211_chan_def *chandef2);
 
+/**
+ * nl80211_chan_width_to_mhz - get the channel width in Mhz
+ * @chan_width: the channel width from &enum nl80211_chan_width
+ * Return: channel width in Mhz if the chan_width from &enum nl80211_chan_width
+ * is valid. -1 otherwise.
+ */
+int nl80211_chan_width_to_mhz(enum nl80211_chan_width chan_width);
+
 /**
  * cfg80211_chandef_valid - check if a channel definition is valid
  * @chandef: the channel definition to check
diff --git a/net/mac80211/Makefile b/net/mac80211/Makefile
index b8de44da1fb8..709eb678f42a 100644
--- a/net/mac80211/Makefile
+++ b/net/mac80211/Makefile
@@ -65,4 +65,6 @@ rc80211_minstrel-$(CONFIG_MAC80211_DEBUGFS) += \
 
 mac80211-$(CONFIG_MAC80211_RC_MINSTREL) += $(rc80211_minstrel-y)
 
+mac80211-$(CONFIG_ACPI_WBRF) += wbrf.o
+
 ccflags-y += -DDEBUG
diff --git a/net/mac80211/chan.c b/net/mac80211/chan.c
index 77c90ed8f5d7..0c5289a9aa6c 100644
--- a/net/mac80211/chan.c
+++ b/net/mac80211/chan.c
@@ -506,11 +506,16 @@ static void _ieee80211_change_chanctx(struct 
ieee80211_local *local,
 
WARN_ON(!cfg80211_chandef_compatible(&ctx->conf.def, chandef));
 
+   ieee80211_remove_wbrf(local, &ctx->conf.def);
+
ctx->conf.def = *chandef;
 
/* check if min chanctx also changed */
changed = IEEE80211_CHANCTX_CHANGE_WIDTH |
  _ieee80211_recalc_chanctx_min_def(local, ctx, rsvd_for);
+
+   ieee80211_add_wbrf(local, &ctx->conf.def);
+
drv_change_chanctx(local, ctx, changed);
 
if (!local->use_chanctx) {
@@ -668,6 +673,10 @@ static int ieee80211_add_chanctx(struct ieee80211_local 
*local,
lockdep_assert_held(&local->mtx);
lockdep_assert_held(&local->chanctx_mtx);
 
+   err = ieee80211_add_wbrf(local, &ctx->conf.def);
+   if (err)
+   return err;
+
if (!local->use_chanctx)
local->hw.conf.radar_enabled = ctx->conf.radar_enabled;
 
@@ -748,6 +757,8 @@ static void ieee80211_del_chanctx(struct ieee80211_local 
*local,
}
 
ieee80211_recalc_idle(local);
+
+   ieee80211_remove_wbrf(local, &ctx->conf.def);
 }
 
 static void ieee80211_free_chanctx(struct ieee80211_local *local,
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index b0372e76f373..f832de16073b 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -1591,6 +1591,10 @@ struct ieee80211_local {
 
/* extended capabilities provided by mac80211 */
u8 ext_capa[8];
+
+#ifdef CONFIG_ACPI_WBRF
+   bool wbrf_supported;
+#endif
 };
 
 static inline struct ieee80211_sub_if_data *
@@ -2615,4 +2619,19 @@ ieee80211_eht_cap_ie_to_sta_eht_cap(struct 
ieee80211_sub_if_data *sdata,
const struct ieee80211_eht_cap_elem 
*eht_cap_ie_elem,
u8 eht_cap_len,
struct link_sta_info *link_sta);
+
+#ifdef CONFIG_ACPI_WBRF
+void ieee80211_check_wbrf_support(struct ieee80211_local *local);
+int ieee80211_add_wbrf(struct ieee80211_local *local,
+  struct cfg80211_chan_def *chandef);
+void ieee80211_remove_wbrf(struct ieee80211_local *local,
+  struct cfg80211_chan_def *chandef);
+#else
+static inline void ieee80211_check_wbrf_support(struct ieee80211_local *local) 
{ }
+static inline int ieee80211_add_wbrf(struct ieee80211_local *local,
+ 

[PATCH V3 1/7] drivers/acpi: Add support for Wifi band RF mitigations

2023-06-15 Thread Evan Quan
From: Mario Limonciello 

Due to electrical and mechanical constraints in certain platform designs
there may be likely interference of relatively high-powered harmonics of
the (G-)DDR memory clocks with local radio module frequency bands used
by Wifi 6/6e/7.

To mitigate this, AMD has introduced an ACPI based mechanism that
devices can use to notify active use of particular frequencies so
that devices can make relative internal adjustments as necessary
to avoid this resonance.

In order for a device to support this, the expected flow for device
driver or subsystems:

Drivers/subsystems contributing frequencies:

1) During probe, check `wbrf_supported_producer` to see if WBRF supported
   for the device.
2) If adding frequencies, then call `wbrf_add_exclusion` with the
   start and end ranges of the frequencies.
3) If removing frequencies, then call `wbrf_remove_exclusion` with
   start and end ranges of the frequencies.

Drivers/subsystems responding to frequencies:

1) During probe, check `wbrf_supported_consumer` to see if WBRF is supported
   for the device.
2) Call the `wbrf_retrieve_exclusions` to retrieve the current
   exclusions on receiving an ACPI notification for a new frequency
   change.

Signed-off-by: Mario Limonciello 
Co-developed-by: Evan Quan 
Signed-off-by: Evan Quan 
--
v1->v2:
  - move those wlan specific implementations to net/mac80211(Mario)
---
 drivers/acpi/Kconfig |   7 ++
 drivers/acpi/Makefile|   2 +
 drivers/acpi/acpi_wbrf.c | 215 +++
 include/linux/wbrf.h |  55 ++
 4 files changed, 279 insertions(+)
 create mode 100644 drivers/acpi/acpi_wbrf.c
 create mode 100644 include/linux/wbrf.h

diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index ccbeab9500ec..9ee7c7dcc3e6 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -611,3 +611,10 @@ config X86_PM_TIMER
 
  You should nearly always say Y here because many modern
  systems require this timer.
+
+config ACPI_WBRF
+   bool "ACPI Wifi band RF mitigation mechanism"
+   help
+ Wifi band RF mitigation mechanism allows multiple drivers from
+ different domains to notify the frequencies in use so that hardware
+ can be reconfigured to avoid harmonic conflicts.
\ No newline at end of file
diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index feb36c0b9446..be173e76aa62 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -131,3 +131,5 @@ obj-y   += dptf/
 obj-$(CONFIG_ARM64)+= arm64/
 
 obj-$(CONFIG_ACPI_VIOT)+= viot.o
+
+obj-$(CONFIG_ACPI_WBRF)+= acpi_wbrf.o
\ No newline at end of file
diff --git a/drivers/acpi/acpi_wbrf.c b/drivers/acpi/acpi_wbrf.c
new file mode 100644
index ..8c275998ac29
--- /dev/null
+++ b/drivers/acpi/acpi_wbrf.c
@@ -0,0 +1,215 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * AMD Wifi Band Exclusion Interface
+ * Copyright (C) 2023 Advanced Micro Devices
+ *
+ */
+
+#include 
+
+/* functions */
+#define WBRF_RECORD0x1
+#define WBRF_RETRIEVE  0x2
+
+/* record actions */
+#define WBRF_RECORD_ADD0x0
+#define WBRF_RECORD_REMOVE 0x1
+
+#define WBRF_REVISION  0x1
+
+static const guid_t wifi_acpi_dsm_guid =
+   GUID_INIT(0x7b7656cf, 0xdc3d, 0x4c1c,
+ 0x83, 0xe9, 0x66, 0xe7, 0x21, 0xde, 0x30, 0x70);
+
+static int wbrf_dsm(struct acpi_device *adev, u8 fn,
+   union acpi_object *argv4,
+   union acpi_object **out)
+{
+   union acpi_object *obj;
+   int rc;
+
+   obj = acpi_evaluate_dsm(adev->handle, &wifi_acpi_dsm_guid,
+   WBRF_REVISION, fn, argv4);
+   if (!obj)
+   return -ENXIO;
+
+   switch (obj->type) {
+   case ACPI_TYPE_BUFFER:
+   if (!*out) {
+   rc = -EINVAL;
+   break;
+   }
+   *out = obj;
+   return 0;
+
+   case ACPI_TYPE_INTEGER:
+   rc =  obj->integer.value ? -EINVAL : 0;
+   break;
+   default:
+   rc = -EOPNOTSUPP;
+   }
+   ACPI_FREE(obj);
+
+   return rc;
+}
+
+static int wbrf_record(struct acpi_device *adev, uint8_t action,
+  struct wbrf_ranges_in *in)
+{
+   union acpi_object *argv4;
+   uint32_t num_of_ranges = 0;
+   uint32_t arg_idx = 0;
+   uint32_t loop_idx;
+   int ret;
+
+   if (!in)
+   return -EINVAL;
+
+   for (loop_idx = 0; loop_idx < ARRAY_SIZE(in->band_list);
+loop_idx++)
+   if (in->band_list[loop_idx].start &&
+   in->band_list[loop_idx].end)
+   num_of_ranges++;
+
+   argv4 = kzalloc(sizeof(*argv4) * (2 * num_of_ranges + 2 + 1), 
GFP_KERNEL);
+   if (!argv4)
+   return -ENOMEM;
+
+   argv4[arg_idx].package.type = A

[PATCH V3 0/7] Support Wifi RFI interference mitigation feature

2023-06-15 Thread Evan Quan
Due to electrical and mechanical constraints in certain platform designs there 
may
be likely interference of relatively high-powered harmonics of the (G-)DDR 
memory
clocks with local radio module frequency bands used by Wifi 6/6e/7. To mitigate
possible RFI interference producers can advertise the frequencies in use and
consumers can use this information to avoid using these frequencies for
sensitive features.

The whole patch set is based on 6.4-rc3. With some brief introductions as below:
Patch1: Core ACPI interfaces needed to support WBRF feature.
Patch2: Enable WBRF support for wifi subsystem.
Patch3 - 7: Enable WBRF support for AMD graphics driver.

Evan Quan (5):
  drm/amd/pm: update driver_if and ppsmc headers for coming wbrf feature
  drm/amd/pm: setup the framework to support Wifi RFI mitigation feature
  drm/amd/pm: add flood detection for wbrf events
  drm/amd/pm: enable Wifi RFI mitigation feature support for SMU13.0.0
  drm/amd/pm: enable Wifi RFI mitigation feature support for SMU13.0.7

Mario Limonciello (2):
  drivers/acpi: Add support for Wifi band RF mitigations
  wifi: mac80211: Add support for ACPI WBRF

 drivers/acpi/Kconfig  |   7 +
 drivers/acpi/Makefile |   2 +
 drivers/acpi/acpi_wbrf.c  | 215 ++
 drivers/gpu/drm/amd/amdgpu/amdgpu.h   |  26 +++
 drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c  |  63 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c   |  19 ++
 drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c | 204 +
 drivers/gpu/drm/amd/pm/swsmu/inc/amdgpu_smu.h |  30 +++
 .../inc/pmfw_if/smu13_driver_if_v13_0_0.h |  14 +-
 .../inc/pmfw_if/smu13_driver_if_v13_0_7.h |  14 +-
 .../pm/swsmu/inc/pmfw_if/smu_v13_0_0_ppsmc.h  |   3 +-
 .../pm/swsmu/inc/pmfw_if/smu_v13_0_7_ppsmc.h  |   3 +-
 drivers/gpu/drm/amd/pm/swsmu/inc/smu_types.h  |   3 +-
 drivers/gpu/drm/amd/pm/swsmu/inc/smu_v13_0.h  |   3 +
 .../gpu/drm/amd/pm/swsmu/smu13/smu_v13_0.c|   9 +
 .../drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c  |  60 +
 .../drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.c  |  59 +
 drivers/gpu/drm/amd/pm/swsmu/smu_internal.h   |   3 +
 include/linux/wbrf.h  |  55 +
 include/net/cfg80211.h|   8 +
 net/mac80211/Makefile |   2 +
 net/mac80211/chan.c   |  11 +
 net/mac80211/ieee80211_i.h|  19 ++
 net/mac80211/main.c   |   2 +
 net/mac80211/wbrf.c   | 137 +++
 net/wireless/chan.c   |   3 +-
 26 files changed, 968 insertions(+), 6 deletions(-)
 create mode 100644 drivers/acpi/acpi_wbrf.c
 create mode 100644 include/linux/wbrf.h
 create mode 100644 net/mac80211/wbrf.c

-- 
2.34.1



[PATCH] drm/amdgpu: fix clearing mappings for BOs that are always valid in VM

2023-06-15 Thread Samuel Pitoiset
If the BO has been moved the PT should be updated, otherwise the VAs
might point to invalid PT.

This fixes random GPU hangs when replacing sparse mappings from the
userspace, while OP_MAP/OP_UNMAP works fine because always valid BOs
are correctly handled there.

Cc: sta...@vger.kernel.org
Signed-off-by: Samuel Pitoiset 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index 143d11afe0e5..eff73c428b12 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -1771,18 +1771,30 @@ int amdgpu_vm_bo_clear_mappings(struct amdgpu_device 
*adev,
 
/* Insert partial mapping before the range */
if (!list_empty(&before->list)) {
+   struct amdgpu_bo *bo = before->bo_va->base.bo;
+
amdgpu_vm_it_insert(before, &vm->va);
if (before->flags & AMDGPU_PTE_PRT)
amdgpu_vm_prt_get(adev);
+
+   if (bo && bo->tbo.base.resv == vm->root.bo->tbo.base.resv &&
+   !before->bo_va->base.moved)
+   amdgpu_vm_bo_moved(&before->bo_va->base);
} else {
kfree(before);
}
 
/* Insert partial mapping after the range */
if (!list_empty(&after->list)) {
+   struct amdgpu_bo *bo = after->bo_va->base.bo;
+
amdgpu_vm_it_insert(after, &vm->va);
if (after->flags & AMDGPU_PTE_PRT)
amdgpu_vm_prt_get(adev);
+
+   if (bo && bo->tbo.base.resv == vm->root.bo->tbo.base.resv &&
+   !after->bo_va->base.moved)
+   amdgpu_vm_bo_moved(&after->bo_va->base);
} else {
kfree(after);
}
-- 
2.41.0



[PATCH] drm/amdgpu: enable mcbp by default on gfx9 chips

2023-06-15 Thread jiadong.zhu
From: Jiadong Zhu 

Gfx9 is using software rings which would trigger mcbp in some cases.
Thus the parameter amdgpu_mcbp shall be enabled by default.

Signed-off-by: Jiadong Zhu 
---
 drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c 
b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
index 65577eca58f1..1b3cfda946f9 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
@@ -4527,6 +4527,7 @@ static int gfx_v9_0_early_init(void *handle)
adev->gfx.xcc_mask = 1;
adev->gfx.num_compute_rings = min(amdgpu_gfx_get_num_kcq(adev),
  AMDGPU_MAX_COMPUTE_RINGS);
+   amdgpu_mcbp = 1;
gfx_v9_0_set_kiq_pm4_funcs(adev);
gfx_v9_0_set_ring_funcs(adev);
gfx_v9_0_set_irq_funcs(adev);
-- 
2.25.1



Re: [PATCH] drm/amdkfd: set coherent host access capability flag

2023-06-15 Thread Felix Kuehling



Am 2023-06-16 um 00:29 schrieb Felix Kuehling:


Am 2023-06-15 um 18:54 schrieb Alex Sierra:

This flag determines whether the host possesses coherent access to
the memory of the device.

Signed-off-by: Alex Sierra 
---
  drivers/gpu/drm/amd/amdkfd/kfd_topology.c | 4 
  1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_topology.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_topology.c

index 90b86a6ac7bd..7ede3de4f7fb 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_topology.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_topology.c
@@ -2107,6 +2107,10 @@ int kfd_topology_add_device(struct kfd_node *gpu)
  if (KFD_IS_SVM_API_SUPPORTED(dev->gpu->adev))
  dev->node_props.capability |= HSA_CAP_SVMAPI_SUPPORTED;
  +    if (dev->gpu->adev->gmc.is_app_apu |
+    dev->gpu->adev->gmc.xgmi.connected_to_cpu)
+    dev->node_props.capability |= HSA_CAP_FLAGS_COHERENTHOSTACCESS;


I believe this is not true for "small APUs" because they map the 
framebuffer as WC on the CPU. I think you need to check specifically 
for APP APU.


Never mind, I read it wrong. You are checking the correct APP APU flag. 
Just one more nit-pick, in the condition you should use logical OR (a || 
b), not bit-wise OR (a | b). With that fixed, the patch is


Reviewed-by: Felix Kuehling 




Regards,
  Felix



+
  kfd_debug_print_topology();
    kfd_notify_gpu_change(gpu_id, 1);


Re: [PATCH] drm/amdkfd: set coherent host access capability flag

2023-06-15 Thread Felix Kuehling



Am 2023-06-15 um 18:54 schrieb Alex Sierra:

This flag determines whether the host possesses coherent access to
the memory of the device.

Signed-off-by: Alex Sierra 
---
  drivers/gpu/drm/amd/amdkfd/kfd_topology.c | 4 
  1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_topology.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_topology.c
index 90b86a6ac7bd..7ede3de4f7fb 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_topology.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_topology.c
@@ -2107,6 +2107,10 @@ int kfd_topology_add_device(struct kfd_node *gpu)
if (KFD_IS_SVM_API_SUPPORTED(dev->gpu->adev))
dev->node_props.capability |= HSA_CAP_SVMAPI_SUPPORTED;
  
+	if (dev->gpu->adev->gmc.is_app_apu |

+   dev->gpu->adev->gmc.xgmi.connected_to_cpu)
+   dev->node_props.capability |= HSA_CAP_FLAGS_COHERENTHOSTACCESS;


I believe this is not true for "small APUs" because they map the 
framebuffer as WC on the CPU. I think you need to check specifically for 
APP APU.


Regards,
  Felix



+
kfd_debug_print_topology();
  
  	kfd_notify_gpu_change(gpu_id, 1);


[PATCH 2/2] drm/amd/pm: update the LC_L1_INACTIIVY setting to address possible noise issue

2023-06-15 Thread Evan Quan
It is proved that insufficient LC_L1_INACTIIVY setting can cause audio
noise on some platform. With the LC_L1_INACTIIVY increased to 4ms, the
issue can be resolved.

Signed-off-by: Evan Quan 
---
 drivers/gpu/drm/amd/amdgpu/nbio_v2_3.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/nbio_v2_3.c 
b/drivers/gpu/drm/amd/amdgpu/nbio_v2_3.c
index 7ba47fc1917b..4038455d7998 100644
--- a/drivers/gpu/drm/amd/amdgpu/nbio_v2_3.c
+++ b/drivers/gpu/drm/amd/amdgpu/nbio_v2_3.c
@@ -345,7 +345,7 @@ static void nbio_v2_3_init_registers(struct amdgpu_device 
*adev)
 }
 
 #define NAVI10_PCIE__LC_L0S_INACTIVITY_DEFAULT 0x // off by 
default, no gains over L1
-#define NAVI10_PCIE__LC_L1_INACTIVITY_DEFAULT  0x0009 // 1=1us, 
9=1ms
+#define NAVI10_PCIE__LC_L1_INACTIVITY_DEFAULT  0x000A // 1=1us, 
9=1ms, 10=4ms
 #define NAVI10_PCIE__LC_L1_INACTIVITY_TBT_DEFAULT  0x000E // 400ms
 
 static void nbio_v2_3_enable_aspm(struct amdgpu_device *adev,
-- 
2.34.1



[PATCH 1/2] drm/amd/pm: revise the ASPM settings for thunderbolt attached scenario

2023-06-15 Thread Evan Quan
Also, correct the comment for NAVI10_PCIE__LC_L1_INACTIVITY_TBT_DEFAULT
as 0x000E stands for 400ms instead of 4ms.

Signed-off-by: Evan Quan 
---
 drivers/gpu/drm/amd/amdgpu/nbio_v2_3.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/nbio_v2_3.c 
b/drivers/gpu/drm/amd/amdgpu/nbio_v2_3.c
index aa761ff3a5fa..7ba47fc1917b 100644
--- a/drivers/gpu/drm/amd/amdgpu/nbio_v2_3.c
+++ b/drivers/gpu/drm/amd/amdgpu/nbio_v2_3.c
@@ -346,7 +346,7 @@ static void nbio_v2_3_init_registers(struct amdgpu_device 
*adev)
 
 #define NAVI10_PCIE__LC_L0S_INACTIVITY_DEFAULT 0x // off by 
default, no gains over L1
 #define NAVI10_PCIE__LC_L1_INACTIVITY_DEFAULT  0x0009 // 1=1us, 
9=1ms
-#define NAVI10_PCIE__LC_L1_INACTIVITY_TBT_DEFAULT  0x000E // 4ms
+#define NAVI10_PCIE__LC_L1_INACTIVITY_TBT_DEFAULT  0x000E // 400ms
 
 static void nbio_v2_3_enable_aspm(struct amdgpu_device *adev,
  bool enable)
@@ -479,9 +479,12 @@ static void nbio_v2_3_program_aspm(struct amdgpu_device 
*adev)
WREG32_SOC15(NBIO, 0, mmRCC_BIF_STRAP5, data);
 
def = data = RREG32_PCIE(smnPCIE_LC_CNTL);
-   data &= ~PCIE_LC_CNTL__LC_L0S_INACTIVITY_MASK;
-   data |= 0x9 << PCIE_LC_CNTL__LC_L1_INACTIVITY__SHIFT;
-   data |= 0x1 << PCIE_LC_CNTL__LC_PMI_TO_L1_DIS__SHIFT;
+   data |= NAVI10_PCIE__LC_L0S_INACTIVITY_DEFAULT << 
PCIE_LC_CNTL__LC_L0S_INACTIVITY__SHIFT;
+   if (pci_is_thunderbolt_attached(adev->pdev))
+   data |= NAVI10_PCIE__LC_L1_INACTIVITY_TBT_DEFAULT  << 
PCIE_LC_CNTL__LC_L1_INACTIVITY__SHIFT;
+   else
+   data |= NAVI10_PCIE__LC_L1_INACTIVITY_DEFAULT << 
PCIE_LC_CNTL__LC_L1_INACTIVITY__SHIFT;
+   data &= ~PCIE_LC_CNTL__LC_PMI_TO_L1_DIS_MASK;
if (def != data)
WREG32_PCIE(smnPCIE_LC_CNTL, data);
 
-- 
2.34.1



RE: [PATCH] drm/amdkfd: set coherent host access capability flag

2023-06-15 Thread Sierra Guiza, Alejandro (Alex)
[AMD Official Use Only - General]

CC: Rajneesh

> -Original Message-
> From: Sierra Guiza, Alejandro (Alex) 
> Sent: Thursday, June 15, 2023 5:55 PM
> To: amd-gfx@lists.freedesktop.org; Kuehling, Felix 
> Cc: Yat Sin, David ; Sierra Guiza, Alejandro (Alex)
> 
> Subject: [PATCH] drm/amdkfd: set coherent host access capability flag
>
> This flag determines whether the host possesses coherent access to the
> memory of the device.
>
> Signed-off-by: Alex Sierra 
> ---
>  drivers/gpu/drm/amd/amdkfd/kfd_topology.c | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_topology.c
> b/drivers/gpu/drm/amd/amdkfd/kfd_topology.c
> index 90b86a6ac7bd..7ede3de4f7fb 100644
> --- a/drivers/gpu/drm/amd/amdkfd/kfd_topology.c
> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_topology.c
> @@ -2107,6 +2107,10 @@ int kfd_topology_add_device(struct kfd_node
> *gpu)
>   if (KFD_IS_SVM_API_SUPPORTED(dev->gpu->adev))
>   dev->node_props.capability |=
> HSA_CAP_SVMAPI_SUPPORTED;
>
> + if (dev->gpu->adev->gmc.is_app_apu |
> + dev->gpu->adev->gmc.xgmi.connected_to_cpu)
> + dev->node_props.capability |=
> HSA_CAP_FLAGS_COHERENTHOSTACCESS;
> +
>   kfd_debug_print_topology();
>
>   kfd_notify_gpu_change(gpu_id, 1);
> --
> 2.32.0



Re: [PATCH] drm/amdgpu/atomfirmware: fix LPDDR5 width reporting

2023-06-15 Thread Zhang, Hawking
[AMD Official Use Only - General]

Acked-by: Hawking Zhang 

Regards,
Hawking

Get Outlook for iOS

From: amd-gfx  on behalf of Alex Deucher 

Sent: Friday, June 16, 2023 6:13:17 AM
To: amd-gfx@lists.freedesktop.org 
Cc: Deucher, Alexander 
Subject: [PATCH] drm/amdgpu/atomfirmware: fix LPDDR5 width reporting

LPDDR5 channels are 32 bit rather than 64, report the width properly
in the log.

v2: Only LPDDR5 are 32 bits per channel.  DDR5 is 64 bits per channel

Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2468
Signed-off-by: Alex Deucher 
---
 .../gpu/drm/amd/amdgpu/amdgpu_atomfirmware.c   | 18 --
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_atomfirmware.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_atomfirmware.c
index ef4b9a41f20a..0b7f4c4d58e5 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_atomfirmware.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_atomfirmware.c
@@ -327,10 +327,13 @@ amdgpu_atomfirmware_get_vram_info(struct amdgpu_device 
*adev,
 mem_channel_number = 
igp_info->v11.umachannelnumber;
 if (!mem_channel_number)
 mem_channel_number = 1;
-   /* channel width is 64 */
-   if (vram_width)
-   *vram_width = 
mem_channel_number * 64;
 mem_type = igp_info->v11.memorytype;
+   if (mem_type == LpDdr5MemType)
+   mem_channel_width = 32;
+   else
+   mem_channel_width = 64;
+   if (vram_width)
+   *vram_width = 
mem_channel_number * mem_channel_width;
 if (vram_type)
 *vram_type = 
convert_atom_mem_type_to_vram_type(adev, mem_type);
 break;
@@ -345,10 +348,13 @@ amdgpu_atomfirmware_get_vram_info(struct amdgpu_device 
*adev,
 mem_channel_number = 
igp_info->v21.umachannelnumber;
 if (!mem_channel_number)
 mem_channel_number = 1;
-   /* channel width is 64 */
-   if (vram_width)
-   *vram_width = 
mem_channel_number * 64;
 mem_type = igp_info->v21.memorytype;
+   if (mem_type == LpDdr5MemType)
+   mem_channel_width = 32;
+   else
+   mem_channel_width = 64;
+   if (vram_width)
+   *vram_width = 
mem_channel_number * mem_channel_width;
 if (vram_type)
 *vram_type = 
convert_atom_mem_type_to_vram_type(adev, mem_type);
 break;
--
2.40.1



[PATCH] drm/amdkfd: set coherent host access capability flag

2023-06-15 Thread Alex Sierra
This flag determines whether the host possesses coherent access to
the memory of the device.

Signed-off-by: Alex Sierra 
---
 drivers/gpu/drm/amd/amdkfd/kfd_topology.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_topology.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_topology.c
index 90b86a6ac7bd..7ede3de4f7fb 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_topology.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_topology.c
@@ -2107,6 +2107,10 @@ int kfd_topology_add_device(struct kfd_node *gpu)
if (KFD_IS_SVM_API_SUPPORTED(dev->gpu->adev))
dev->node_props.capability |= HSA_CAP_SVMAPI_SUPPORTED;
 
+   if (dev->gpu->adev->gmc.is_app_apu |
+   dev->gpu->adev->gmc.xgmi.connected_to_cpu)
+   dev->node_props.capability |= HSA_CAP_FLAGS_COHERENTHOSTACCESS;
+
kfd_debug_print_topology();
 
kfd_notify_gpu_change(gpu_id, 1);
-- 
2.32.0



[PATCH] drm/amdkfd: set coherent host access capability flag

2023-06-15 Thread Alex Sierra
This flag determines whether the host possesses coherent access to
the memory of the device.

Signed-off-by: Alex Sierra 
---
 drivers/gpu/drm/amd/amdkfd/kfd_topology.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_topology.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_topology.c
index 90b86a6ac7bd..296219be350d 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_topology.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_topology.c
@@ -2107,6 +2107,9 @@ int kfd_topology_add_device(struct kfd_node *gpu)
if (KFD_IS_SVM_API_SUPPORTED(dev->gpu->adev))
dev->node_props.capability |= HSA_CAP_SVMAPI_SUPPORTED;
 
+   if (dev->gpu->adev->gmc.xgmi.connected_to_cpu)
+   dev->node_props.capability |= HSA_CAP_FLAGS_COHERENTHOSTACCESS;
+
kfd_debug_print_topology();
 
kfd_notify_gpu_change(gpu_id, 1);
-- 
2.32.0



[PATCH] drm/amdgpu/atomfirmware: fix LPDDR5 width reporting

2023-06-15 Thread Alex Deucher
LPDDR5 channels are 32 bit rather than 64, report the width properly
in the log.

v2: Only LPDDR5 are 32 bits per channel.  DDR5 is 64 bits per channel

Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2468
Signed-off-by: Alex Deucher 
---
 .../gpu/drm/amd/amdgpu/amdgpu_atomfirmware.c   | 18 --
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_atomfirmware.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_atomfirmware.c
index ef4b9a41f20a..0b7f4c4d58e5 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_atomfirmware.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_atomfirmware.c
@@ -327,10 +327,13 @@ amdgpu_atomfirmware_get_vram_info(struct amdgpu_device 
*adev,
mem_channel_number = 
igp_info->v11.umachannelnumber;
if (!mem_channel_number)
mem_channel_number = 1;
-   /* channel width is 64 */
-   if (vram_width)
-   *vram_width = 
mem_channel_number * 64;
mem_type = igp_info->v11.memorytype;
+   if (mem_type == LpDdr5MemType)
+   mem_channel_width = 32;
+   else
+   mem_channel_width = 64;
+   if (vram_width)
+   *vram_width = 
mem_channel_number * mem_channel_width;
if (vram_type)
*vram_type = 
convert_atom_mem_type_to_vram_type(adev, mem_type);
break;
@@ -345,10 +348,13 @@ amdgpu_atomfirmware_get_vram_info(struct amdgpu_device 
*adev,
mem_channel_number = 
igp_info->v21.umachannelnumber;
if (!mem_channel_number)
mem_channel_number = 1;
-   /* channel width is 64 */
-   if (vram_width)
-   *vram_width = 
mem_channel_number * 64;
mem_type = igp_info->v21.memorytype;
+   if (mem_type == LpDdr5MemType)
+   mem_channel_width = 32;
+   else
+   mem_channel_width = 64;
+   if (vram_width)
+   *vram_width = 
mem_channel_number * mem_channel_width;
if (vram_type)
*vram_type = 
convert_atom_mem_type_to_vram_type(adev, mem_type);
break;
-- 
2.40.1



Re: [PATCH v7 2/8] PCI/VGA: Deal only with VGA class devices

2023-06-15 Thread Alex Deucher
On Wed, Jun 14, 2023 at 6:50 AM Sui Jingfeng  wrote:
>
> Hi,
>
> On 2023/6/13 11:01, Sui Jingfeng wrote:
> > From: Sui Jingfeng 
> >
> > Deal only with the VGA devcie(pdev->class == 0x0300), so replace the
> > pci_get_subsys() function with pci_get_class(). Filter the non-PCI display
> > device(pdev->class != 0x0300) out. There no need to process the non-display
> > PCI device.
> >
> > Cc: Bjorn Helgaas 
> > Signed-off-by: Sui Jingfeng 
> > ---
> >   drivers/pci/vgaarb.c | 22 --
> >   1 file changed, 12 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/pci/vgaarb.c b/drivers/pci/vgaarb.c
> > index c1bc6c983932..22a505e877dc 100644
> > --- a/drivers/pci/vgaarb.c
> > +++ b/drivers/pci/vgaarb.c
> > @@ -754,10 +754,6 @@ static bool vga_arbiter_add_pci_device(struct pci_dev 
> > *pdev)
> >   struct pci_dev *bridge;
> >   u16 cmd;
> >
> > - /* Only deal with VGA class devices */
> > - if ((pdev->class >> 8) != PCI_CLASS_DISPLAY_VGA)
> > - return false;
> > -
>
> Hi, here is probably a bug fixing.
>
> For an example, nvidia render only GPU typically has 0x0380.
>
> at its PCI class number, but  render only GPU should not participate in
> the arbitration.
>
> As it shouldn't snoop the legacy fixed VGA address.
>
> It(render only GPU) can not display anything.
>
>
> But 0x0380 >> 8 = 0x03, the filter  failed.
>
>
> >   /* Allocate structure */
> >   vgadev = kzalloc(sizeof(struct vga_device), GFP_KERNEL);
> >   if (vgadev == NULL) {
> > @@ -1500,7 +1496,9 @@ static int pci_notify(struct notifier_block *nb, 
> > unsigned long action,
> >   struct pci_dev *pdev = to_pci_dev(dev);
> >   bool notify = false;
> >
> > - vgaarb_dbg(dev, "%s\n", __func__);
> > + /* Only deal with VGA class devices */
> > + if (pdev->class != PCI_CLASS_DISPLAY_VGA << 8)
> > + return 0;
>
> So here we only care 0x0300, my initial intent is to make an optimization,
>
> nowadays sane display graphic card should all has 0x0300 as its PCI
> class number, is this complete right?
>
> ```
>
> #define PCI_BASE_CLASS_DISPLAY0x03
> #define PCI_CLASS_DISPLAY_VGA0x0300
> #define PCI_CLASS_DISPLAY_XGA0x0301
> #define PCI_CLASS_DISPLAY_3D0x0302
> #define PCI_CLASS_DISPLAY_OTHER0x0380
>
> ```
>
> Any ideas ?

I'm not quite sure what you are asking about here.  For vga_arb, we
only care about VGA class devices since those should be on the only
ones that might have VGA routed to them.  However, as VGA gets
deprecated, you'll have more non VGA PCI classes for devices which
could be the pre-OS console device.

Alex

>
> >   /* For now we're only intereted in devices added and removed. I didn't
> >* test this thing here, so someone needs to double check for the
> > @@ -1510,6 +1508,8 @@ static int pci_notify(struct notifier_block *nb, 
> > unsigned long action,
> >   else if (action == BUS_NOTIFY_DEL_DEVICE)
> >   notify = vga_arbiter_del_pci_device(pdev);
> >
> > + vgaarb_dbg(dev, "%s: action = %lu\n", __func__, action);
> > +
> >   if (notify)
> >   vga_arbiter_notify_clients();
> >   return 0;
> > @@ -1534,8 +1534,8 @@ static struct miscdevice vga_arb_device = {
> >
> >   static int __init vga_arb_device_init(void)
> >   {
> > + struct pci_dev *pdev = NULL;
> >   int rc;
> > - struct pci_dev *pdev;
> >
> >   rc = misc_register(&vga_arb_device);
> >   if (rc < 0)
> > @@ -1545,11 +1545,13 @@ static int __init vga_arb_device_init(void)
> >
> >   /* We add all PCI devices satisfying VGA class in the arbiter by
> >* default */
> > - pdev = NULL;
> > - while ((pdev =
> > - pci_get_subsys(PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID,
> > -PCI_ANY_ID, pdev)) != NULL)
> > + while (1) {
> > + pdev = pci_get_class(PCI_CLASS_DISPLAY_VGA << 8, pdev);
> > + if (!pdev)
> > + break;
> > +
> >   vga_arbiter_add_pci_device(pdev);
> > + }
> >
> >   pr_info("loaded\n");
> >   return rc;
>
> --
> Jingfeng
>


Re: [PATCH v9 02/14] mm: move page zone helpers from mm.h to mmzone.h

2023-06-15 Thread Peter Xu
On Thu, Jun 15, 2023 at 09:15:26PM +0100, Matthew Wilcox wrote:
> On Thu, Jun 15, 2023 at 03:33:12PM -0400, Peter Xu wrote:
> > My question is whether page_zonenum() is ready for taking all kinds of tail
> > pages?
> > 
> > Zone device tail pages all look fine, per memmap_init_zone_device().  The
> > question was other kinds of usual compound pages, like either thp or
> > hugetlb.  IIUC page->flags can be uninitialized for those tail pages.
> 
> I don't think that's true.  It's my understanding that page->flags is
> initialised for all pages in memmap at boot / hotplug / delayed-init
> time.  So you can check things like zone, node, etc on literally any
> page.  Contrariwise, those flags are not available in tail pages for
> use by the entity that has allocated a compound page / large folio.

Oh so the zone mask is special.  Fair enough.

> 
> Also, I don't believe zone device pages support compound allocation.
> I think they're always allocated as order-0.

Totally not familiar with zone device pages, but memmap_init_zone_device()
has pfns_per_compound which can be >1.  From there, memmap_init_compound()
does go ahead and setup pages as compound ones.

Thanks!

-- 
Peter Xu



[PATCH 6/6] drm/amd/display: Get replay info from VSDB

2023-06-15 Thread Bhawanpreet Lakha
We need to make sure that the panel supports replay.

This info is inside the amd vsdb (vendor specific data block). Create a
function to parse the block and read the replay_mode bit.

Signed-off-by: Bhawanpreet Lakha 
---
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 37 +++
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 14 +++
 .../amd/display/amdgpu_dm/amdgpu_dm_replay.c  | 11 +++---
 3 files changed, 57 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index a6551c049cc1..d74d5ba39d92 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -10546,6 +10546,41 @@ static bool parse_edid_cea(struct amdgpu_dm_connector 
*aconnector,
return ret;
 }
 
+static int parse_amd_vsdb(struct amdgpu_dm_connector *aconnector,
+   struct edid *edid, struct amdgpu_hdmi_vsdb_info *vsdb_info)
+{
+   u8 *edid_ext = NULL;
+   int i;
+   int j = 0;
+
+   if (edid == NULL || edid->extensions == 0)
+   return -ENODEV;
+
+   /* Find DisplayID extension */
+   for (i = 0; i < edid->extensions; i++) {
+   edid_ext = (void *)(edid + (i + 1));
+   if (edid_ext[0] == DISPLAYID_EXT)
+   break;
+   }
+
+   while (j < EDID_LENGTH) {
+
+   struct amd_vsdb_block *amd_vsdb = (struct amd_vsdb_block 
*)&edid_ext[j];
+   unsigned int ieeeId = (amd_vsdb->ieee_id[2] << 16) | 
(amd_vsdb->ieee_id[1] << 8) | (amd_vsdb->ieee_id[0]);
+
+   if (ieeeId == 
HDMI_AMD_VENDOR_SPECIFIC_DATA_BLOCK_IEEE_REGISTRATION_ID &&
+   amd_vsdb->version == 
HDMI_AMD_VENDOR_SPECIFIC_DATA_BLOCK_VERSION_3) {
+   vsdb_info->replay_mode = (amd_vsdb->feature_caps & 
AMD_VSDB_VERSION_3_FEATURECAP_REPLAYMODE) ? true : false;
+   DRM_DEBUG_KMS("Panel supports Replay Mode: %d\n", 
vsdb_info->replay_mode);
+
+   return true;
+   }
+   j++;
+   }
+
+   return false;
+}
+
 static int parse_hdmi_amd_vsdb(struct amdgpu_dm_connector *aconnector,
struct edid *edid, struct amdgpu_hdmi_vsdb_info *vsdb_info)
 {
@@ -10681,6 +10716,8 @@ void amdgpu_dm_update_freesync_caps(struct 
drm_connector *connector,
freesync_capable = true;
}
}
+   parse_amd_vsdb(amdgpu_dm_connector, edid, &vsdb_info);
+
} else if (edid && sink->sink_signal == SIGNAL_TYPE_HDMI_TYPE_A) {
i = parse_hdmi_amd_vsdb(amdgpu_dm_connector, edid, &vsdb_info);
if (i >= 0 && vsdb_info.freesync_supported) {
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
index 4561f55afa99..5c9cf6c147d7 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
@@ -51,6 +51,9 @@
 
 #define AMDGPU_DMUB_NOTIFICATION_MAX 5
 
+#define HDMI_AMD_VENDOR_SPECIFIC_DATA_BLOCK_IEEE_REGISTRATION_ID 0x1A
+#define AMD_VSDB_VERSION_3_FEATURECAP_REPLAYMODE 0x40
+#define HDMI_AMD_VENDOR_SPECIFIC_DATA_BLOCK_VERSION_3 0x3
 /*
 #include "include/amdgpu_dal_power_if.h"
 #include "amdgpu_dm_irq.h"
@@ -75,6 +78,12 @@ struct dmub_srv;
 struct dc_plane_state;
 struct dmub_notification;
 
+struct amd_vsdb_block {
+   unsigned char ieee_id[3];
+   unsigned char version;
+   unsigned char feature_caps;
+};
+
 struct common_irq_params {
struct amdgpu_device *adev;
enum dc_irq_source irq_src;
@@ -604,6 +613,11 @@ struct amdgpu_hdmi_vsdb_info {
 * @max_refresh_rate_hz: FreeSync Maximum Refresh Rate in Hz
 */
unsigned int max_refresh_rate_hz;
+
+   /**
+* @replay mode: Replay supported
+*/
+   bool replay_mode;
 };
 
 struct amdgpu_dm_connector {
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_replay.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_replay.c
index 7690ab6125a1..f82575e09848 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_replay.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_replay.c
@@ -46,11 +46,8 @@ static bool link_supports_replay(struct dc_link *link, 
struct amdgpu_dm_connecto
if (!state->freesync_capable)
return false;
 
-   //TODO VSDB replay check
-   /* i = parse_amd_vsdb(aconnector, edid, &vsdb_info); */
-
-   /* if(!vsdb_info.replay_mode) */
-   /*  return false; */
+   if (!aconnector->vsdb_info.replay_mode)
+   return false;
 
// Check the eDP version
if (dpcd_caps->edp_rev < EDP_REVISION_13)
@@ -77,6 +74,10 @@ bool amdgpu_dm_setup_replay(struct dc_link *link, struct 
amdgpu_dm_connector *ac
struct replay_config pr_config;
union replay_

[PATCH 5/6] drm/amd/display: Enable Replay for static screen use cases

2023-06-15 Thread Bhawanpreet Lakha
- Setup replay config on device init.
- Enable replay if feature is enabled and psr is not going to be enabled
- Add debug masks to enable replay on supported ASICs

Signed-off-by: Bhawanpreet Lakha 
---
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 19 +++
 .../amd/display/amdgpu_dm/amdgpu_dm_crtc.c|  4 
 drivers/gpu/drm/amd/include/amd_shared.h  |  2 ++
 3 files changed, 25 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 2446529c329a..a6551c049cc1 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -65,6 +65,7 @@
 #include "amdgpu_dm_debugfs.h"
 #endif
 #include "amdgpu_dm_psr.h"
+#include "amdgpu_dm_replay.h"
 
 #include "ivsrcid/ivsrcid_vislands30.h"
 
@@ -4315,6 +4316,7 @@ static int amdgpu_dm_initialize_drm_device(struct 
amdgpu_device *adev)
enum dc_connection_type new_connection_type = dc_connection_none;
const struct dc_plane_cap *plane;
bool psr_feature_enabled = false;
+   bool replay_feature_enabled = false;
int max_overlay = dm->dc->caps.max_slave_planes;
 
dm->display_indexes_num = dm->dc->caps.max_streams;
@@ -4424,6 +4426,20 @@ static int amdgpu_dm_initialize_drm_device(struct 
amdgpu_device *adev)
}
}
 
+   if (!(amdgpu_dc_debug_mask & DC_DISABLE_REPLAY)) {
+   switch (adev->ip_versions[DCE_HWIP][0]) {
+   case IP_VERSION(3, 1, 4):
+   case IP_VERSION(3, 1, 5):
+   case IP_VERSION(3, 1, 6):
+   case IP_VERSION(3, 2, 0):
+   case IP_VERSION(3, 2, 1):
+   replay_feature_enabled = true;
+   break;
+   default:
+   replay_feature_enabled = amdgpu_dc_feature_mask & 
DC_REPLAY_MASK;
+   break;
+   }
+   }
/* loops over all connectors on the board */
for (i = 0; i < link_cnt; i++) {
struct dc_link *link = NULL;
@@ -4480,6 +4496,9 @@ static int amdgpu_dm_initialize_drm_device(struct 
amdgpu_device *adev)
 */
if (link->psr_settings.psr_feature_enabled)

adev_to_drm(adev)->vblank_disable_immediate = false;
+
+   if (replay_feature_enabled)
+   amdgpu_dm_setup_replay(link, 
aconnector);
}
}
amdgpu_set_panel_orientation(&aconnector->base);
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crtc.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crtc.c
index 440fc0869a34..44323cef5dfd 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crtc.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crtc.c
@@ -29,6 +29,7 @@
 #include "dc.h"
 #include "amdgpu.h"
 #include "amdgpu_dm_psr.h"
+#include "amdgpu_dm_replay.h"
 #include "amdgpu_dm_crtc.h"
 #include "amdgpu_dm_plane.h"
 #include "amdgpu_dm_trace.h"
@@ -132,8 +133,11 @@ static void vblank_control_worker(struct work_struct *work)
 #ifdef CONFIG_DRM_AMD_SECURE_DISPLAY
   
!amdgpu_dm_crc_window_is_activated(&vblank_work->acrtc->base) &&
 #endif
+  
vblank_work->stream->link->panel_config.psr.disallow_replay &&
   vblank_work->acrtc->dm_irq_params.allow_psr_entry) {
amdgpu_dm_psr_enable(vblank_work->stream);
+   } else if 
(vblank_work->stream->link->replay_settings.replay_feature_enabled) {
+   amdgpu_dm_replay_enable(vblank_work->stream, false);
}
}
 
diff --git a/drivers/gpu/drm/amd/include/amd_shared.h 
b/drivers/gpu/drm/amd/include/amd_shared.h
index f175e65b853a..c6d4cca646c2 100644
--- a/drivers/gpu/drm/amd/include/amd_shared.h
+++ b/drivers/gpu/drm/amd/include/amd_shared.h
@@ -240,6 +240,7 @@ enum DC_FEATURE_MASK {
DC_DISABLE_LTTPR_DP2_0 = (1 << 6), //0x40, disabled by default
DC_PSR_ALLOW_SMU_OPT = (1 << 7), //0x80, disabled by default
DC_PSR_ALLOW_MULTI_DISP_OPT = (1 << 8), //0x100, disabled by default
+   DC_REPLAY_MASK = (1 << 9), //0x200, disabled by default for dcn < 3.1.4
 };
 
 enum DC_DEBUG_MASK {
@@ -250,6 +251,7 @@ enum DC_DEBUG_MASK {
DC_DISABLE_PSR = 0x10,
DC_FORCE_SUBVP_MCLK_SWITCH = 0x20,
DC_DISABLE_MPO = 0x40,
+   DC_DISABLE_REPLAY = 0x50,
 };
 
 enum amd_dpm_forced_level;
-- 
2.25.1



[PATCH 3/6] drm/amd/display: Add Freesync Panel DM code

2023-06-15 Thread Bhawanpreet Lakha
We need certain conditions for replay to be enabled, so create an
interface in DM to enable/disable replay.

Signed-off-by: Bhawanpreet Lakha 
---
 .../gpu/drm/amd/display/amdgpu_dm/Makefile|   2 +-
 .../amd/display/amdgpu_dm/amdgpu_dm_replay.c  | 183 ++
 .../amd/display/amdgpu_dm/amdgpu_dm_replay.h  |  46 +
 .../drm/amd/display/dc/core/dc_link_exports.c |   5 +
 drivers/gpu/drm/amd/display/dc/dc.h   |   2 +
 .../amd/display/modules/power/power_helpers.c |   5 +
 .../amd/display/modules/power/power_helpers.h |   2 +
 7 files changed, 244 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_replay.c
 create mode 100644 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_replay.h

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/Makefile 
b/drivers/gpu/drm/amd/display/amdgpu_dm/Makefile
index 249b073f6a23..8bf94920d23e 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/Makefile
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/Makefile
@@ -38,7 +38,7 @@ AMDGPUDM += dc_fpu.o
 endif
 
 ifneq ($(CONFIG_DRM_AMD_DC),)
-AMDGPUDM += amdgpu_dm_services.o amdgpu_dm_helpers.o amdgpu_dm_pp_smu.o 
amdgpu_dm_psr.o
+AMDGPUDM += amdgpu_dm_services.o amdgpu_dm_helpers.o amdgpu_dm_pp_smu.o 
amdgpu_dm_psr.o amdgpu_dm_replay.o
 endif
 
 AMDGPUDM += amdgpu_dm_hdcp.o
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_replay.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_replay.c
new file mode 100644
index ..7690ab6125a1
--- /dev/null
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_replay.c
@@ -0,0 +1,183 @@
+/*
+ * Copyright 2023 Advanced Micro Devices, Inc.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ *
+ * Authors: AMD
+ *
+ */
+
+#include "amdgpu_dm_replay.h"
+#include "dc.h"
+#include "dm_helpers.h"
+#include "amdgpu_dm.h"
+#include "modules/power/power_helpers.h"
+#include "dmub/inc/dmub_cmd.h"
+#include "dc/inc/link.h"
+
+/*
+ * link_supports_replay() - check if the link supports replay
+ * @link: link
+ * @aconnector: aconnector
+ *
+ */
+static bool link_supports_replay(struct dc_link *link, struct 
amdgpu_dm_connector *aconnector)
+{
+   struct dm_connector_state *state = 
to_dm_connector_state(aconnector->base.state);
+   struct dpcd_caps *dpcd_caps = &link->dpcd_caps;
+   struct adaptive_sync_caps *as_caps = 
&link->dpcd_caps.adaptive_sync_caps;
+
+   if (!state->freesync_capable)
+   return false;
+
+   //TODO VSDB replay check
+   /* i = parse_amd_vsdb(aconnector, edid, &vsdb_info); */
+
+   /* if(!vsdb_info.replay_mode) */
+   /*  return false; */
+
+   // Check the eDP version
+   if (dpcd_caps->edp_rev < EDP_REVISION_13)
+   return false;
+
+   if (!dpcd_caps->alpm_caps.bits.AUX_WAKE_ALPM_CAP)
+   return false;
+
+   // Check adaptive sync support cap
+   if (!as_caps->dp_adap_sync_caps.bits.ADAPTIVE_SYNC_SDP_SUPPORT)
+   return false;
+
+   return true;
+}
+
+/*
+ * amdgpu_dm_setup_replay() - setup replay configuration
+ * @link: link
+ * @aconnector: aconnector
+ *
+ */
+bool amdgpu_dm_setup_replay(struct dc_link *link, struct amdgpu_dm_connector 
*aconnector)
+{
+   struct replay_config pr_config;
+   union replay_debug_flags *debug_flags = NULL;
+
+   if (!dc_is_embedded_signal(link->connector_signal))
+   return false;
+
+   if (link->panel_config.psr.disallow_replay)
+   return false;
+
+   if (!link_supports_replay(link, aconnector))
+   return false;
+
+   // Mark Replay is supported in link and update related attributes
+   pr_config.replay_supported = true;
+   pr_config.replay_power_opt_supported = 0;
+   pr_config.replay_enable_option |= pr_enable_option_static_screen;
+   pr_config.replay_timing_sync_supported = aconnector->max_vfreq >= 2 * 
aconnector->min_vfreq ? true : false;
+
+   

[PATCH 2/6] drm/amd/display: Add Functions to enable Freesync Panel Replay

2023-06-15 Thread Bhawanpreet Lakha
Add various functions for replay, such as construct, destroy, enable
get_state, and copy_setting etc. These functions communicate with the
firmware to setup and enable panel replay

Signed-off-by: Bhawanpreet Lakha 
---
 drivers/gpu/drm/amd/display/dc/dce/Makefile   |   2 +-
 .../gpu/drm/amd/display/dc/dce/dmub_replay.c  | 303 ++
 .../gpu/drm/amd/display/dc/dce/dmub_replay.h  |  58 
 .../drm/amd/display/dc/dcn31/dcn31_resource.c |  12 +
 .../amd/display/dc/dcn314/dcn314_resource.c   |  12 +
 drivers/gpu/drm/amd/display/dc/inc/link.h |  14 +
 .../drm/amd/display/dc/link/link_factory.c|   7 +
 .../link/protocols/link_edp_panel_control.c   | 165 ++
 .../link/protocols/link_edp_panel_control.h   |   8 +
 9 files changed, 580 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/amd/display/dc/dce/dmub_replay.c
 create mode 100644 drivers/gpu/drm/amd/display/dc/dce/dmub_replay.h

diff --git a/drivers/gpu/drm/amd/display/dc/dce/Makefile 
b/drivers/gpu/drm/amd/display/dc/dce/Makefile
index 01490c9ba958..15b64c26d5a2 100644
--- a/drivers/gpu/drm/amd/display/dc/dce/Makefile
+++ b/drivers/gpu/drm/amd/display/dc/dce/Makefile
@@ -30,7 +30,7 @@ DCE = dce_audio.o dce_stream_encoder.o dce_link_encoder.o 
dce_hwseq.o \
 dce_mem_input.o dce_clock_source.o dce_scl_filters.o dce_transform.o \
 dce_opp.o dce_dmcu.o dce_abm.o dce_ipp.o dce_aux.o \
 dce_i2c.o dce_i2c_hw.o dce_i2c_sw.o dmub_psr.o dmub_abm.o dmub_abm_lcd.o 
dce_panel_cntl.o \
-dmub_hw_lock_mgr.o dmub_outbox.o
+dmub_hw_lock_mgr.o dmub_outbox.o dmub_replay.o
 
 AMD_DAL_DCE = $(addprefix $(AMDDALPATH)/dc/dce/,$(DCE))
 
diff --git a/drivers/gpu/drm/amd/display/dc/dce/dmub_replay.c 
b/drivers/gpu/drm/amd/display/dc/dce/dmub_replay.c
new file mode 100644
index ..cab7e71fd27f
--- /dev/null
+++ b/drivers/gpu/drm/amd/display/dc/dce/dmub_replay.c
@@ -0,0 +1,303 @@
+/*
+ * Copyright 2023 Advanced Micro Devices, Inc.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ *
+ * Authors: AMD
+ *
+ */
+
+#include "dc.h"
+#include "dc_dmub_srv.h"
+#include "dmub/dmub_srv.h"
+#include "core_types.h"
+#include "dmub_replay.h"
+
+#define DC_TRACE_LEVEL_MESSAGE(...) /* do nothing */
+
+#define MAX_PIPES 6
+
+/**
+ * Get Replay state from firmware.
+ */
+static void dmub_replay_get_state(struct dmub_replay *dmub, enum replay_state 
*state, uint8_t panel_inst)
+{
+   struct dmub_srv *srv = dmub->ctx->dmub_srv->dmub;
+   /* uint32_t raw_state = 0; */
+   uint32_t retry_count = 0;
+   enum dmub_status status;
+
+   do {
+   // Send gpint command and wait for ack
+   status = dmub_srv_send_gpint_command(srv, 
DMUB_GPINT__GET_REPLAY_STATE, panel_inst, 30);
+
+   if (status == DMUB_STATUS_OK) {
+   // GPINT was executed, get response
+   dmub_srv_get_gpint_response(srv, (uint32_t *)state);
+   } else
+   // Return invalid state when GPINT times out
+   *state = REPLAY_STATE_INVALID;
+   } while (++retry_count <= 1000 && *state == REPLAY_STATE_INVALID);
+
+   // Assert if max retry hit
+   if (retry_count >= 1000 && *state == REPLAY_STATE_INVALID) {
+   ASSERT(0);
+   /* To-do: Add retry fail log */
+   }
+}
+
+/**
+ * Enable/Disable Replay.
+ */
+static void dmub_replay_enable(struct dmub_replay *dmub, bool enable, bool 
wait, uint8_t panel_inst)
+{
+   union dmub_rb_cmd cmd;
+   struct dc_context *dc = dmub->ctx;
+   uint32_t retry_count;
+   enum replay_state state = REPLAY_STATE_0;
+
+   memset(&cmd, 0, sizeof(cmd));
+   cmd.replay_enable.header.type = DMUB_CMD__REPLAY;
+   cmd.replay_enable.data.panel_inst = panel_inst;
+
+   cmd.replay_enable.header.sub_type = DMUB_CMD__REPLAY_ENABLE;
+   if (enable)
+   cmd.replay_enable.data.enable = REPLAY_ENABLE;
+   else
+  

[PATCH 4/6] drm/amd/display: Read replay data from sink

2023-06-15 Thread Bhawanpreet Lakha
Read DP_SINK_PR_PIXEL_DEVIATION_PER_LINE  and
DP_SINK_PR_MAX_NUMBER_OF_DEVIATION_LINE

Signed-off-by: Bhawanpreet Lakha 
---
 .../amd/display/dc/link/protocols/link_dp_capability.c | 10 ++
 drivers/gpu/drm/amd/display/include/dpcd_defs.h|  4 +++-
 2 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/dc/link/protocols/link_dp_capability.c 
b/drivers/gpu/drm/amd/display/dc/link/protocols/link_dp_capability.c
index 3a5e80b57711..5eec5d9bfd68 100644
--- a/drivers/gpu/drm/amd/display/dc/link/protocols/link_dp_capability.c
+++ b/drivers/gpu/drm/amd/display/dc/link/protocols/link_dp_capability.c
@@ -2008,6 +2008,16 @@ void detect_edp_sink_caps(struct dc_link *link)
core_link_read_dpcd(link, DP_RECEIVER_ALPM_CAP,
&link->dpcd_caps.alpm_caps.raw,
sizeof(link->dpcd_caps.alpm_caps.raw));
+
+   /*
+* Read REPLAY info
+*/
+   core_link_read_dpcd(link, DP_SINK_PR_PIXEL_DEVIATION_PER_LINE,
+   &link->dpcd_caps.pr_info.pixel_deviation_per_line,
+   
sizeof(link->dpcd_caps.pr_info.pixel_deviation_per_line));
+   core_link_read_dpcd(link, DP_SINK_PR_MAX_NUMBER_OF_DEVIATION_LINE,
+   &link->dpcd_caps.pr_info.max_deviation_line,
+   sizeof(link->dpcd_caps.pr_info.max_deviation_line));
 }
 
 bool dp_get_max_link_enc_cap(const struct dc_link *link, struct 
dc_link_settings *max_link_enc_cap)
diff --git a/drivers/gpu/drm/amd/display/include/dpcd_defs.h 
b/drivers/gpu/drm/amd/display/include/dpcd_defs.h
index c062a44db078..5b70145abf12 100644
--- a/drivers/gpu/drm/amd/display/include/dpcd_defs.h
+++ b/drivers/gpu/drm/amd/display/include/dpcd_defs.h
@@ -172,6 +172,8 @@ enum dpcd_psr_sink_states {
 #define DP_SOURCE_BACKLIGHT_CURRENT_PEAK0x326
 #define DP_SOURCE_BACKLIGHT_CONTROL0x32E
 #define DP_SOURCE_BACKLIGHT_ENABLE 0x32F
-#define DP_SOURCE_MINIMUM_HBLANK_SUPPORTED 0x340
+#define DP_SOURCE_MINIMUM_HBLANK_SUPPORTED 0x340
+#define DP_SINK_PR_PIXEL_DEVIATION_PER_LINE 0x379
+#define DP_SINK_PR_MAX_NUMBER_OF_DEVIATION_LINE 0x37A
 
 #endif /* __DAL_DPCD_DEFS_H__ */
-- 
2.25.1



[PATCH 1/6] drm/amd/display: Add structs for Freesync Panel Replay

2023-06-15 Thread Bhawanpreet Lakha
In some instances, the GPU is transmitting repeated frame to the sink
without any updates or changes in the content. These repeat transmission
are wasteful, resulting in power draw in different aspects of the system

1. DCN is fetching the frame of data from DF/UMC/DRAM. This memory traffic
prevents power down of parts of this HW path.

2. GPU is transmitting pixel data to the display through the main link of
the DisplayPort interface. This prevents power down of both the Source
transmitter (TX) and the Sink receiver (RX)

The concepts of utilizing replay is similar to PSR, but there is a benefit of:
Source and Sink remaining synchronized which allows for
- lower latency when switching from replay to live frames
- enable the possibility of more use cases
- easy control of the sink's refresh rate during replay

Due to Source and Sink remaining timing synchronized, Replay can be activated
in more UI scenarios.

Signed-off-by: Bhawanpreet Lakha 
---
 drivers/gpu/drm/amd/display/dc/dc.h   |   3 +
 drivers/gpu/drm/amd/display/dc/dc_dp_types.h  |  29 ++
 drivers/gpu/drm/amd/display/dc/dc_types.h |  41 ++
 .../gpu/drm/amd/display/dc/inc/core_types.h   |  19 +
 .../gpu/drm/amd/display/dmub/inc/dmub_cmd.h   | 408 ++
 5 files changed, 500 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/dc/dc.h 
b/drivers/gpu/drm/amd/display/dc/dc.h
index 26d05e225088..c3a41db3c91c 100644
--- a/drivers/gpu/drm/amd/display/dc/dc.h
+++ b/drivers/gpu/drm/amd/display/dc/dc.h
@@ -428,6 +428,7 @@ enum visual_confirm {
VISUAL_CONFIRM_SWAPCHAIN = 6,
VISUAL_CONFIRM_FAMS = 7,
VISUAL_CONFIRM_SWIZZLE = 9,
+   VISUAL_CONFIRM_REPLAY = 12,
VISUAL_CONFIRM_SUBVP = 14,
VISUAL_CONFIRM_MCLK_SWITCH = 16,
 };
@@ -1505,6 +1506,8 @@ struct dc_link {
 
struct psr_settings psr_settings;
 
+   struct replay_settings replay_settings;
+
/* Drive settings read from integrated info table */
struct dc_lane_settings bios_forced_drive_settings;
 
diff --git a/drivers/gpu/drm/amd/display/dc/dc_dp_types.h 
b/drivers/gpu/drm/amd/display/dc/dc_dp_types.h
index 55139d7bf422..cfaa39c5dd16 100644
--- a/drivers/gpu/drm/amd/display/dc/dc_dp_types.h
+++ b/drivers/gpu/drm/amd/display/dc/dc_dp_types.h
@@ -1117,6 +1117,11 @@ struct edp_psr_info {
uint8_t force_psrsu_cap;
 };
 
+struct replay_info {
+   uint8_t pixel_deviation_per_line;
+   uint8_t max_deviation_line;
+};
+
 struct dprx_states {
bool cable_id_written;
 };
@@ -1236,6 +1241,8 @@ struct dpcd_caps {
uint8_t edp_rev;
union edp_alpm_caps alpm_caps;
struct edp_psr_info psr_info;
+
+   struct replay_info pr_info;
 };
 
 union dpcd_sink_ext_caps {
@@ -1276,6 +1283,28 @@ union dpcd_psr_configuration {
unsigned char raw;
 };
 
+union replay_enable_and_configuration {
+   struct {
+   unsigned char FREESYNC_PANEL_REPLAY_MODE  :1;
+   unsigned char TIMING_DESYNC_ERROR_VERIFICATION:1;
+   unsigned char STATE_TRANSITION_ERROR_DETECTION:1;
+   unsigned char RESERVED0   :1;
+   unsigned char RESERVED1   :4;
+   } bits;
+   unsigned char raw;
+};
+
+union dpcd_replay_configuration {
+   struct {
+   unsigned char STATE_TRANSITION_ERROR_STATUS: 1;
+   unsigned char DESYNC_ERROR_STATUS  : 1;
+   unsigned char SINK_DEVICE_REPLAY_STATUS: 3;
+   unsigned char SINK_FRAME_LOCKED: 2;
+   unsigned char RESERVED : 1;
+   } bits;
+   unsigned char raw;
+};
+
 union dpcd_alpm_configuration {
struct {
unsigned char ENABLE: 1;
diff --git a/drivers/gpu/drm/amd/display/dc/dc_types.h 
b/drivers/gpu/drm/amd/display/dc/dc_types.h
index 0ce7728a5a4b..b77ceb442fa2 100644
--- a/drivers/gpu/drm/amd/display/dc/dc_types.h
+++ b/drivers/gpu/drm/amd/display/dc/dc_types.h
@@ -1014,6 +1014,45 @@ struct psr_settings {
unsigned int psr_power_opt;
 };
 
+enum replay_coasting_vtotal_type {
+   PR_COASTING_TYPE_NOM = 0,
+   PR_COASTING_TYPE_STATIC,
+   PR_COASTING_TYPE_FULL_SCREEN_VIDEO,
+   PR_COASTING_TYPE_TEST_HARNESS,
+   PR_COASTING_TYPE_NUM,
+};
+
+union replay_error_status {
+   struct {
+   unsigned char STATE_TRANSITION_ERROR:1;
+   unsigned char LINK_CRC_ERROR:1;
+   unsigned char DESYNC_ERROR  :1;
+   unsigned char RESERVED  :5;
+   } bits;
+   unsigned char raw;
+};
+
+struct replay_config {
+   bool replay_supported;  // Replay feature is 
supported
+   unsigned int replay_power_opt_supported;// Power opt flags that 
are supported
+ 

[PATCH 0/6] Freesync Panel Replay

2023-06-15 Thread Bhawanpreet Lakha
This patch set introduces Freesync Panel Replay capability on DCN 3.1.4
and newer

These patches are enabling panel replay in static screen use-cases.
Other use cases will be added as they are ready

*Please note that there is a bug I am seeing with these patches where
there is a hang after the screen is idle for a few minutes. I am
actively debugging this and will send an updated patch set once the fix
is found


The importance of Replay


In some instances, the GPU is transmitting repeated frames to the sink
without any updates or changes in the content. These repeat transmission
are wasteful, resulting in power draw in different aspects of the system

1. DCN is fetching the frame of data from DF/UMC/DRAM. This memory traffic
prevents power down of parts of this HW path.

2. GPU is transmitting pixel data to the display through the main link of
the DisplayPort interface. This prevents power down of both the Source
transmitter (TX) and the Sink receiver (RX)



How it improves on PSR


The concepts of utilizing replay is similar to PSR, but there is a benefit of:
Source and Sink remaining synchronized which allows for
- lower latency when switching from replay to live frames
- enable the possibility of more use cases
- easy control of the sink's refresh rate during replay

Due to Source and Sink remaining timing synchronized, Replay can be activated
in more UI scenarios.


Regards,
Bhawan



Bhawanpreet Lakha (6):
  drm/amd/display: Add structs for Freesync Panel Replay
  drm/amd/display: Add Functions to enable Freesync Panel Replay
  drm/amd/display: Add Freesync Panel DM code
  drm/amd/display: Read replay data from sink
  drm/amd/display: Enable Replay for static screen use cases
  drm/amd/display: Get replay info from VSDB

 .../gpu/drm/amd/display/amdgpu_dm/Makefile|   2 +-
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |  56 +++
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h |  14 +
 .../amd/display/amdgpu_dm/amdgpu_dm_crtc.c|   4 +
 .../amd/display/amdgpu_dm/amdgpu_dm_replay.c  | 184 
 .../amd/display/amdgpu_dm/amdgpu_dm_replay.h  |  46 ++
 .../drm/amd/display/dc/core/dc_link_exports.c |   5 +
 drivers/gpu/drm/amd/display/dc/dc.h   |   5 +
 drivers/gpu/drm/amd/display/dc/dc_dp_types.h  |  29 ++
 drivers/gpu/drm/amd/display/dc/dc_types.h |  41 ++
 drivers/gpu/drm/amd/display/dc/dce/Makefile   |   2 +-
 .../gpu/drm/amd/display/dc/dce/dmub_replay.c  | 303 +
 .../gpu/drm/amd/display/dc/dce/dmub_replay.h  |  58 +++
 .../drm/amd/display/dc/dcn31/dcn31_resource.c |  12 +
 .../amd/display/dc/dcn314/dcn314_resource.c   |  12 +
 .../gpu/drm/amd/display/dc/inc/core_types.h   |  19 +
 drivers/gpu/drm/amd/display/dc/inc/link.h |  14 +
 .../drm/amd/display/dc/link/link_factory.c|   7 +
 .../dc/link/protocols/link_dp_capability.c|  10 +
 .../link/protocols/link_edp_panel_control.c   | 165 +++
 .../link/protocols/link_edp_panel_control.h   |   8 +
 .../gpu/drm/amd/display/dmub/inc/dmub_cmd.h   | 408 ++
 .../gpu/drm/amd/display/include/dpcd_defs.h   |   4 +-
 .../amd/display/modules/power/power_helpers.c |   5 +
 .../amd/display/modules/power/power_helpers.h |   2 +
 drivers/gpu/drm/amd/include/amd_shared.h  |   2 +
 26 files changed, 1414 insertions(+), 3 deletions(-)
 create mode 100644 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_replay.c
 create mode 100644 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_replay.h
 create mode 100644 drivers/gpu/drm/amd/display/dc/dce/dmub_replay.c
 create mode 100644 drivers/gpu/drm/amd/display/dc/dce/dmub_replay.h

-- 
2.25.1



Re: [PATCH v9 02/14] mm: move page zone helpers from mm.h to mmzone.h

2023-06-15 Thread Peter Xu
Hello, all,

On Fri, Jul 15, 2022 at 10:05:09AM -0500, Alex Sierra wrote:
> +static inline enum zone_type page_zonenum(const struct page *page)
> +{
> + ASSERT_EXCLUSIVE_BITS(page->flags, ZONES_MASK << ZONES_PGSHIFT);
> + return (page->flags >> ZONES_PGSHIFT) & ZONES_MASK;
> +}

Sorry to hijack this patch - not directly relevant to the movement, but
relevant to this helper, so maybe I can leverage the cc list..

My question is whether page_zonenum() is ready for taking all kinds of tail
pages?

Zone device tail pages all look fine, per memmap_init_zone_device().  The
question was other kinds of usual compound pages, like either thp or
hugetlb.  IIUC page->flags can be uninitialized for those tail pages.

Asking because I noticed it seems possible that page_zonenum() can just
take any random tail page as input, e.g.:

try_grab_folio -> is_pci_p2pdma_page -> is_zone_device_page -> page_zonenum

I'm worried it'll just read fake things, but maybe I just missed something?

Thanks,

-- 
Peter Xu



Re: [PATCH v9 02/14] mm: move page zone helpers from mm.h to mmzone.h

2023-06-15 Thread Matthew Wilcox
On Thu, Jun 15, 2023 at 03:33:12PM -0400, Peter Xu wrote:
> My question is whether page_zonenum() is ready for taking all kinds of tail
> pages?
> 
> Zone device tail pages all look fine, per memmap_init_zone_device().  The
> question was other kinds of usual compound pages, like either thp or
> hugetlb.  IIUC page->flags can be uninitialized for those tail pages.

I don't think that's true.  It's my understanding that page->flags is
initialised for all pages in memmap at boot / hotplug / delayed-init
time.  So you can check things like zone, node, etc on literally any
page.  Contrariwise, those flags are not available in tail pages for
use by the entity that has allocated a compound page / large folio.

Also, I don't believe zone device pages support compound allocation.
I think they're always allocated as order-0.



Re: [PATCH 1/2] drm/amdgpu: Skip TMR for MP0_HWIP 13.0.6

2023-06-15 Thread Deucher, Alexander
[Public]

Series is:
Reviewed-by: Alex Deucher 

From: Luo, Zhigang 
Sent: Thursday, June 15, 2023 1:49 PM
To: amd-gfx@lists.freedesktop.org 
Cc: Deucher, Alexander ; Luo, Zhigang 

Subject: [PATCH 1/2] drm/amdgpu: Skip TMR for MP0_HWIP 13.0.6

For SRIOV VF, no TMR needed.

Signed-off-by: Zhigang Luo 
Change-Id: If9556cf60dfcbd95e102b1387cf233e902d9490e
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
index e15c27e05564..ac9b57231589 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
@@ -839,6 +839,7 @@ static bool psp_skip_tmr(struct psp_context *psp)
 case IP_VERSION(11, 0, 9):
 case IP_VERSION(11, 0, 7):
 case IP_VERSION(13, 0, 2):
+   case IP_VERSION(13, 0, 6):
 case IP_VERSION(13, 0, 10):
 return true;
 default:
--
2.25.1



[PATCH 2/2] drm/amdgpu: port SRIOV VF missed changes

2023-06-15 Thread Zhigang Luo
port SRIOV VF missed changes from gfx_v9_0 to gfx_v9_4_3.

Signed-off-by: Zhigang Luo 
Change-Id: Id580820376c8d653e9ec5ebf5a8b950cd0a67e1a
---
 drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.c | 15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.c 
b/drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.c
index c1ee54d4c3d3..76b189bd244a 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.c
@@ -1762,6 +1762,8 @@ static int gfx_v9_4_3_xcc_kiq_init_queue(struct 
amdgpu_ring *ring, int xcc_id)
((struct v9_mqd_allocation *)mqd)->dynamic_cu_mask = 0x;
((struct v9_mqd_allocation *)mqd)->dynamic_rb_mask = 0x;
mutex_lock(&adev->srbm_mutex);
+   if (amdgpu_sriov_vf(adev) && adev->in_suspend)
+   amdgpu_ring_clear_ring(ring);
soc15_grbm_select(adev, ring->me, ring->pipe, ring->queue, 0, 
GET_INST(GC, xcc_id));
gfx_v9_4_3_xcc_mqd_init(ring, xcc_id);
gfx_v9_4_3_xcc_kiq_init_register(ring, xcc_id);
@@ -1960,6 +1962,16 @@ static void gfx_v9_4_3_xcc_fini(struct amdgpu_device 
*adev, int xcc_id)
if (amdgpu_gfx_disable_kcq(adev, xcc_id))
DRM_ERROR("XCD %d KCQ disable failed\n", xcc_id);
 
+   if (amdgpu_sriov_vf(adev)) {
+   /* must disable polling for SRIOV when hw finished, otherwise
+* CPC engine may still keep fetching WB address which is 
already
+* invalid after sw finished and trigger DMAR reading error in
+* hypervisor side.
+*/
+   WREG32_FIELD15_PREREG(GC, GET_INST(GC, xcc_id), 
CP_PQ_WPTR_POLL_CNTL, EN, 0);
+   return;
+   }
+
/* Use deinitialize sequence from CAIL when unbinding device
 * from driver, otherwise KIQ is hanging when binding back
 */
@@ -1984,7 +1996,8 @@ static int gfx_v9_4_3_hw_init(void *handle)
int r;
struct amdgpu_device *adev = (struct amdgpu_device *)handle;
 
-   gfx_v9_4_3_init_golden_registers(adev);
+   if (!amdgpu_sriov_vf(adev))
+   gfx_v9_4_3_init_golden_registers(adev);
 
gfx_v9_4_3_constants_init(adev);
 
-- 
2.25.1



[PATCH 1/2] drm/amdgpu: Skip TMR for MP0_HWIP 13.0.6

2023-06-15 Thread Zhigang Luo
For SRIOV VF, no TMR needed.

Signed-off-by: Zhigang Luo 
Change-Id: If9556cf60dfcbd95e102b1387cf233e902d9490e
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
index e15c27e05564..ac9b57231589 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
@@ -839,6 +839,7 @@ static bool psp_skip_tmr(struct psp_context *psp)
case IP_VERSION(11, 0, 9):
case IP_VERSION(11, 0, 7):
case IP_VERSION(13, 0, 2):
+   case IP_VERSION(13, 0, 6):
case IP_VERSION(13, 0, 10):
return true;
default:
-- 
2.25.1



Re: [PATCH 2/2] drm/amdgpu: Move clocks closer to its only usage in amdgpu_parse_cg_state()

2023-06-15 Thread Alex Deucher
Applied the series.  Thanks!

Alex

On Thu, Jun 15, 2023 at 1:06 PM Nathan Chancellor  wrote:
>
> After commit a25a9dae2067 ("drm/amd/amdgpu: enable W=1 for amdgpu"),
> there is an instance of -Wunused-const-variable when CONFIG_DEBUG_FS is
> disabled:
>
>   drivers/gpu/drm/amd/amdgpu/../pm/amdgpu_pm.c:38:34: error: unused variable 
> 'clocks' [-Werror,-Wunused-const-variable]
>  38 | static const struct cg_flag_name clocks[] = {
> |  ^
>   1 error generated.
>
> clocks is only used when CONFIG_DEBUG_FS is set, so move the definition
> into the CONFIG_DEBUG_FS block right above its only usage to clear up
> the warning.
>
> Signed-off-by: Nathan Chancellor 
> ---
>  drivers/gpu/drm/amd/pm/amdgpu_pm.c | 76 
> +++---
>  1 file changed, 38 insertions(+), 38 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/pm/amdgpu_pm.c 
> b/drivers/gpu/drm/amd/pm/amdgpu_pm.c
> index a57952b93e73..386ccf11e657 100644
> --- a/drivers/gpu/drm/amd/pm/amdgpu_pm.c
> +++ b/drivers/gpu/drm/amd/pm/amdgpu_pm.c
> @@ -35,44 +35,6 @@
>  #include 
>  #include 
>
> -static const struct cg_flag_name clocks[] = {
> -   {AMD_CG_SUPPORT_GFX_FGCG, "Graphics Fine Grain Clock Gating"},
> -   {AMD_CG_SUPPORT_GFX_MGCG, "Graphics Medium Grain Clock Gating"},
> -   {AMD_CG_SUPPORT_GFX_MGLS, "Graphics Medium Grain memory Light Sleep"},
> -   {AMD_CG_SUPPORT_GFX_CGCG, "Graphics Coarse Grain Clock Gating"},
> -   {AMD_CG_SUPPORT_GFX_CGLS, "Graphics Coarse Grain memory Light Sleep"},
> -   {AMD_CG_SUPPORT_GFX_CGTS, "Graphics Coarse Grain Tree Shader Clock 
> Gating"},
> -   {AMD_CG_SUPPORT_GFX_CGTS_LS, "Graphics Coarse Grain Tree Shader Light 
> Sleep"},
> -   {AMD_CG_SUPPORT_GFX_CP_LS, "Graphics Command Processor Light Sleep"},
> -   {AMD_CG_SUPPORT_GFX_RLC_LS, "Graphics Run List Controller Light 
> Sleep"},
> -   {AMD_CG_SUPPORT_GFX_3D_CGCG, "Graphics 3D Coarse Grain Clock Gating"},
> -   {AMD_CG_SUPPORT_GFX_3D_CGLS, "Graphics 3D Coarse Grain memory Light 
> Sleep"},
> -   {AMD_CG_SUPPORT_MC_LS, "Memory Controller Light Sleep"},
> -   {AMD_CG_SUPPORT_MC_MGCG, "Memory Controller Medium Grain Clock 
> Gating"},
> -   {AMD_CG_SUPPORT_SDMA_LS, "System Direct Memory Access Light Sleep"},
> -   {AMD_CG_SUPPORT_SDMA_MGCG, "System Direct Memory Access Medium Grain 
> Clock Gating"},
> -   {AMD_CG_SUPPORT_BIF_MGCG, "Bus Interface Medium Grain Clock Gating"},
> -   {AMD_CG_SUPPORT_BIF_LS, "Bus Interface Light Sleep"},
> -   {AMD_CG_SUPPORT_UVD_MGCG, "Unified Video Decoder Medium Grain Clock 
> Gating"},
> -   {AMD_CG_SUPPORT_VCE_MGCG, "Video Compression Engine Medium Grain 
> Clock Gating"},
> -   {AMD_CG_SUPPORT_HDP_LS, "Host Data Path Light Sleep"},
> -   {AMD_CG_SUPPORT_HDP_MGCG, "Host Data Path Medium Grain Clock Gating"},
> -   {AMD_CG_SUPPORT_DRM_MGCG, "Digital Right Management Medium Grain 
> Clock Gating"},
> -   {AMD_CG_SUPPORT_DRM_LS, "Digital Right Management Light Sleep"},
> -   {AMD_CG_SUPPORT_ROM_MGCG, "Rom Medium Grain Clock Gating"},
> -   {AMD_CG_SUPPORT_DF_MGCG, "Data Fabric Medium Grain Clock Gating"},
> -   {AMD_CG_SUPPORT_VCN_MGCG, "VCN Medium Grain Clock Gating"},
> -   {AMD_CG_SUPPORT_HDP_DS, "Host Data Path Deep Sleep"},
> -   {AMD_CG_SUPPORT_HDP_SD, "Host Data Path Shutdown"},
> -   {AMD_CG_SUPPORT_IH_CG, "Interrupt Handler Clock Gating"},
> -   {AMD_CG_SUPPORT_JPEG_MGCG, "JPEG Medium Grain Clock Gating"},
> -   {AMD_CG_SUPPORT_REPEATER_FGCG, "Repeater Fine Grain Clock Gating"},
> -   {AMD_CG_SUPPORT_GFX_PERF_CLK, "Perfmon Clock Gating"},
> -   {AMD_CG_SUPPORT_ATHUB_MGCG, "Address Translation Hub Medium Grain 
> Clock Gating"},
> -   {AMD_CG_SUPPORT_ATHUB_LS, "Address Translation Hub Light Sleep"},
> -   {0, NULL},
> -};
> -
>  static const struct hwmon_temp_label {
> enum PP_HWMON_TEMP channel;
> const char *label;
> @@ -3684,6 +3646,44 @@ static int amdgpu_debugfs_pm_info_pp(struct seq_file 
> *m, struct amdgpu_device *a
> return 0;
>  }
>
> +static const struct cg_flag_name clocks[] = {
> +   {AMD_CG_SUPPORT_GFX_FGCG, "Graphics Fine Grain Clock Gating"},
> +   {AMD_CG_SUPPORT_GFX_MGCG, "Graphics Medium Grain Clock Gating"},
> +   {AMD_CG_SUPPORT_GFX_MGLS, "Graphics Medium Grain memory Light Sleep"},
> +   {AMD_CG_SUPPORT_GFX_CGCG, "Graphics Coarse Grain Clock Gating"},
> +   {AMD_CG_SUPPORT_GFX_CGLS, "Graphics Coarse Grain memory Light Sleep"},
> +   {AMD_CG_SUPPORT_GFX_CGTS, "Graphics Coarse Grain Tree Shader Clock 
> Gating"},
> +   {AMD_CG_SUPPORT_GFX_CGTS_LS, "Graphics Coarse Grain Tree Shader Light 
> Sleep"},
> +   {AMD_CG_SUPPORT_GFX_CP_LS, "Graphics Command Processor Light Sleep"},
> +   {AMD_CG_SUPPORT_GFX_RLC_LS, "Graphics Run List Controller Light 
> Sleep"},
> +   {AMD_CG_SUPPORT_GFX_3D_CGCG, "Graphics 3D Coarse Grain Clock Gating"},
> +   {AMD

Re: [PATCH] drm/amd/pm: remove unneeded variable

2023-06-15 Thread Alex Deucher
Applied, but please check your mailer.  I had to manually fix this up.

Alex

On Wed, Jun 14, 2023 at 3:21 AM  wrote:
>
> fix the following coccicheck warning:
>
> drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c:1657:14-18: Unneeded
> variable: "size".
>
> Signed-off-by: Mingtong Bao 
> ---
>   drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c | 10 +-
>   1 file changed, 5 insertions(+), 5 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 275f708db636..c94d825a871b 100644
> --- a/drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c
> +++ b/drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c
> @@ -1654,7 +1654,7 @@ static int navi10_force_clk_levels(struct
> smu_context *smu,
>  enum smu_clk_type clk_type, uint32_t mask)
>   {
>
> -int ret = 0, size = 0;
> +int ret = 0;
>   uint32_t soft_min_level = 0, soft_max_level = 0, min_freq = 0,
> max_freq = 0;
>
>   soft_min_level = mask ? (ffs(mask) - 1) : 0;
> @@ -1675,15 +1675,15 @@ static int navi10_force_clk_levels(struct
> smu_context *smu,
>
>   ret = smu_v11_0_get_dpm_freq_by_index(smu, clk_type,
> soft_min_level, &min_freq);
>   if (ret)
> -return size;
> +return 0;
>
>   ret = smu_v11_0_get_dpm_freq_by_index(smu, clk_type,
> soft_max_level, &max_freq);
>   if (ret)
> -return size;
> +return 0;
>
>   ret = smu_v11_0_set_soft_freq_limited_range(smu, clk_type,
> min_freq, max_freq);
>   if (ret)
> -return size;
> +return 0;
>   break;
>   case SMU_DCEFCLK:
>   dev_info(smu->adev->dev,"Setting DCEFCLK min/max dpm level is
> not supported!\n");
> @@ -1693,7 +1693,7 @@ static int navi10_force_clk_levels(struct
> smu_context *smu,
>   break;
>   }
>
> -return size;
> +return 0;
>   }
>
>   static int navi10_populate_umd_state_clk(struct smu_context *smu)


Re: [PATCH] drm/amdgpu: remove unneeded variable

2023-06-15 Thread Alex Deucher
On Wed, Jun 14, 2023 at 3:20 AM  wrote:
>
> fix the following coccicheck warning:
>
> drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu7_powertune.c:1156:5-11:
> Unneeded variable: "result".
>

This variable is used and the code fails to compile with it removed.

Alex

> Signed-off-by: Mingtong Bao 
> ---
>   drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu7_powertune.c | 3 +--
>   1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu7_powertune.c
> b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu7_powertune.c
> index 21be23ec3c79..36aa7657c66d 100644
> --- a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu7_powertune.c
> +++ b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu7_powertune.c
> @@ -1153,7 +1153,6 @@ int smu7_enable_power_containment(struct pp_hwmgr
> *hwmgr)
>   struct phm_ppt_v1_information *table_info =
>   (struct phm_ppt_v1_information *)(hwmgr->pptable);
>   int smc_result;
> -int result = 0;
>   struct phm_cac_tdp_table *cac_table;
>
>   data->power_containment_features = 0;
> @@ -1191,7 +1190,7 @@ int smu7_enable_power_containment(struct pp_hwmgr
> *hwmgr)
>   }
>   }
>   }
> -return result;
> +return 0;
>   }
>
>   int smu7_disable_power_containment(struct pp_hwmgr *hwmgr)


Re: [PATCH] amd/display/dc:remove repeating expression

2023-06-15 Thread Alex Deucher
Applied.  Thanks!

Alex

On Wed, Jun 14, 2023 at 1:36 AM Ammar Faizi  wrote:
>
> On 6/14/23 10:49 AM, Wang Ming wrote:
> > Identify issues that arise by using the tests/doubletest.cocci
> > semantic patch.Need to remove duplicate expression in if statement.
> >
> > Signed-off-by: Wang Ming 
>
> Reviewed-by: Ammar Faizi 
>
> --
> Ammar Faizi


[PATCH 2/2] drm/amdgpu: Move clocks closer to its only usage in amdgpu_parse_cg_state()

2023-06-15 Thread Nathan Chancellor
After commit a25a9dae2067 ("drm/amd/amdgpu: enable W=1 for amdgpu"),
there is an instance of -Wunused-const-variable when CONFIG_DEBUG_FS is
disabled:

  drivers/gpu/drm/amd/amdgpu/../pm/amdgpu_pm.c:38:34: error: unused variable 
'clocks' [-Werror,-Wunused-const-variable]
 38 | static const struct cg_flag_name clocks[] = {
|  ^
  1 error generated.

clocks is only used when CONFIG_DEBUG_FS is set, so move the definition
into the CONFIG_DEBUG_FS block right above its only usage to clear up
the warning.

Signed-off-by: Nathan Chancellor 
---
 drivers/gpu/drm/amd/pm/amdgpu_pm.c | 76 +++---
 1 file changed, 38 insertions(+), 38 deletions(-)

diff --git a/drivers/gpu/drm/amd/pm/amdgpu_pm.c 
b/drivers/gpu/drm/amd/pm/amdgpu_pm.c
index a57952b93e73..386ccf11e657 100644
--- a/drivers/gpu/drm/amd/pm/amdgpu_pm.c
+++ b/drivers/gpu/drm/amd/pm/amdgpu_pm.c
@@ -35,44 +35,6 @@
 #include 
 #include 
 
-static const struct cg_flag_name clocks[] = {
-   {AMD_CG_SUPPORT_GFX_FGCG, "Graphics Fine Grain Clock Gating"},
-   {AMD_CG_SUPPORT_GFX_MGCG, "Graphics Medium Grain Clock Gating"},
-   {AMD_CG_SUPPORT_GFX_MGLS, "Graphics Medium Grain memory Light Sleep"},
-   {AMD_CG_SUPPORT_GFX_CGCG, "Graphics Coarse Grain Clock Gating"},
-   {AMD_CG_SUPPORT_GFX_CGLS, "Graphics Coarse Grain memory Light Sleep"},
-   {AMD_CG_SUPPORT_GFX_CGTS, "Graphics Coarse Grain Tree Shader Clock 
Gating"},
-   {AMD_CG_SUPPORT_GFX_CGTS_LS, "Graphics Coarse Grain Tree Shader Light 
Sleep"},
-   {AMD_CG_SUPPORT_GFX_CP_LS, "Graphics Command Processor Light Sleep"},
-   {AMD_CG_SUPPORT_GFX_RLC_LS, "Graphics Run List Controller Light Sleep"},
-   {AMD_CG_SUPPORT_GFX_3D_CGCG, "Graphics 3D Coarse Grain Clock Gating"},
-   {AMD_CG_SUPPORT_GFX_3D_CGLS, "Graphics 3D Coarse Grain memory Light 
Sleep"},
-   {AMD_CG_SUPPORT_MC_LS, "Memory Controller Light Sleep"},
-   {AMD_CG_SUPPORT_MC_MGCG, "Memory Controller Medium Grain Clock Gating"},
-   {AMD_CG_SUPPORT_SDMA_LS, "System Direct Memory Access Light Sleep"},
-   {AMD_CG_SUPPORT_SDMA_MGCG, "System Direct Memory Access Medium Grain 
Clock Gating"},
-   {AMD_CG_SUPPORT_BIF_MGCG, "Bus Interface Medium Grain Clock Gating"},
-   {AMD_CG_SUPPORT_BIF_LS, "Bus Interface Light Sleep"},
-   {AMD_CG_SUPPORT_UVD_MGCG, "Unified Video Decoder Medium Grain Clock 
Gating"},
-   {AMD_CG_SUPPORT_VCE_MGCG, "Video Compression Engine Medium Grain Clock 
Gating"},
-   {AMD_CG_SUPPORT_HDP_LS, "Host Data Path Light Sleep"},
-   {AMD_CG_SUPPORT_HDP_MGCG, "Host Data Path Medium Grain Clock Gating"},
-   {AMD_CG_SUPPORT_DRM_MGCG, "Digital Right Management Medium Grain Clock 
Gating"},
-   {AMD_CG_SUPPORT_DRM_LS, "Digital Right Management Light Sleep"},
-   {AMD_CG_SUPPORT_ROM_MGCG, "Rom Medium Grain Clock Gating"},
-   {AMD_CG_SUPPORT_DF_MGCG, "Data Fabric Medium Grain Clock Gating"},
-   {AMD_CG_SUPPORT_VCN_MGCG, "VCN Medium Grain Clock Gating"},
-   {AMD_CG_SUPPORT_HDP_DS, "Host Data Path Deep Sleep"},
-   {AMD_CG_SUPPORT_HDP_SD, "Host Data Path Shutdown"},
-   {AMD_CG_SUPPORT_IH_CG, "Interrupt Handler Clock Gating"},
-   {AMD_CG_SUPPORT_JPEG_MGCG, "JPEG Medium Grain Clock Gating"},
-   {AMD_CG_SUPPORT_REPEATER_FGCG, "Repeater Fine Grain Clock Gating"},
-   {AMD_CG_SUPPORT_GFX_PERF_CLK, "Perfmon Clock Gating"},
-   {AMD_CG_SUPPORT_ATHUB_MGCG, "Address Translation Hub Medium Grain Clock 
Gating"},
-   {AMD_CG_SUPPORT_ATHUB_LS, "Address Translation Hub Light Sleep"},
-   {0, NULL},
-};
-
 static const struct hwmon_temp_label {
enum PP_HWMON_TEMP channel;
const char *label;
@@ -3684,6 +3646,44 @@ static int amdgpu_debugfs_pm_info_pp(struct seq_file *m, 
struct amdgpu_device *a
return 0;
 }
 
+static const struct cg_flag_name clocks[] = {
+   {AMD_CG_SUPPORT_GFX_FGCG, "Graphics Fine Grain Clock Gating"},
+   {AMD_CG_SUPPORT_GFX_MGCG, "Graphics Medium Grain Clock Gating"},
+   {AMD_CG_SUPPORT_GFX_MGLS, "Graphics Medium Grain memory Light Sleep"},
+   {AMD_CG_SUPPORT_GFX_CGCG, "Graphics Coarse Grain Clock Gating"},
+   {AMD_CG_SUPPORT_GFX_CGLS, "Graphics Coarse Grain memory Light Sleep"},
+   {AMD_CG_SUPPORT_GFX_CGTS, "Graphics Coarse Grain Tree Shader Clock 
Gating"},
+   {AMD_CG_SUPPORT_GFX_CGTS_LS, "Graphics Coarse Grain Tree Shader Light 
Sleep"},
+   {AMD_CG_SUPPORT_GFX_CP_LS, "Graphics Command Processor Light Sleep"},
+   {AMD_CG_SUPPORT_GFX_RLC_LS, "Graphics Run List Controller Light Sleep"},
+   {AMD_CG_SUPPORT_GFX_3D_CGCG, "Graphics 3D Coarse Grain Clock Gating"},
+   {AMD_CG_SUPPORT_GFX_3D_CGLS, "Graphics 3D Coarse Grain memory Light 
Sleep"},
+   {AMD_CG_SUPPORT_MC_LS, "Memory Controller Light Sleep"},
+   {AMD_CG_SUPPORT_MC_MGCG, "Memory Controller Medium Grain Clock Gating"},
+   {AMD_CG_SUPPORT_SDMA_LS, "System Direct Memory Access Light Slee

[PATCH 0/2] drm/amdgpu: Fix instances of -Wunused-const-variable with CONFIG_DEBUG_FS=n

2023-06-15 Thread Nathan Chancellor
Hi all,

After commit a25a9dae2067 ("drm/amd/amdgpu: enable W=1 for amdgpu"),
I see a few instances of -Wunused-const-variable with configurations
that do not enable CONFIG_DEBUG_FS, such as Alpine Linux's. This series
includes two patches to resolve each warning I see.

---
Nathan Chancellor (2):
  drm/amdgpu: Remove CONFIG_DEBUG_FS guard around body of 
amdgpu_rap_debugfs_init()
  drm/amdgpu: Move clocks closer to its only usage in 
amdgpu_parse_cg_state()

 drivers/gpu/drm/amd/amdgpu/amdgpu_rap.c |  2 -
 drivers/gpu/drm/amd/pm/amdgpu_pm.c  | 76 -
 2 files changed, 38 insertions(+), 40 deletions(-)
---
base-commit: d297eedf83f5af96751c0da1e4355c19244a55a2
change-id: 20230615-amdgpu-wunused-const-variable-wo-debugfs-308ce8e17329

Best regards,
-- 
Nathan Chancellor 



[PATCH 1/2] drm/amdgpu: Remove CONFIG_DEBUG_FS guard around body of amdgpu_rap_debugfs_init()

2023-06-15 Thread Nathan Chancellor
After commit a25a9dae2067 ("drm/amd/amdgpu: enable W=1 for amdgpu"),
there is an instance of -Wunused-const-variable when CONFIG_DEBUG_FS is
disabled:

  drivers/gpu/drm/amd/amdgpu/amdgpu_rap.c:110:37: error: unused variable 
'amdgpu_rap_debugfs_ops' [-Werror,-Wunused-const-variable]
110 | static const struct file_operations amdgpu_rap_debugfs_ops = {
| ^
  1 error generated.

There is no reason for the body of this function to be guarded when
CONFIG_DEBUG_FS is disabled, as debugfs_create_file() is a stub that
just returns an error pointer in that situation. Remove the preprocessor
guards so that the variable never appears unused, while not changing
anything at run time.

Signed-off-by: Nathan Chancellor 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_rap.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_rap.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_rap.c
index 12010c988c8b..123bcf5c2bb1 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_rap.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_rap.c
@@ -116,7 +116,6 @@ static const struct file_operations amdgpu_rap_debugfs_ops 
= {
 
 void amdgpu_rap_debugfs_init(struct amdgpu_device *adev)
 {
-#if defined(CONFIG_DEBUG_FS)
struct drm_minor *minor = adev_to_drm(adev)->primary;
 
if (!adev->psp.rap_context.context.initialized)
@@ -124,5 +123,4 @@ void amdgpu_rap_debugfs_init(struct amdgpu_device *adev)
 
debugfs_create_file("rap_test", S_IWUSR, minor->debugfs_root,
adev, &amdgpu_rap_debugfs_ops);
-#endif
 }

-- 
2.41.0



RE: [PATCH] drm/amdgpu: mark GC 9.4.3 experimental for now

2023-06-15 Thread Zhang, Hawking
[AMD Official Use Only - General]

Reviewed-by: Hawking Zhang 

Regards,
Hawking
-Original Message-
From: amd-gfx  On Behalf Of Alex Deucher
Sent: Thursday, June 15, 2023 22:03
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander 
Subject: [PATCH] drm/amdgpu: mark GC 9.4.3 experimental for now

Mark as experimental for now until we get closer to production to avoid 
possible undesireable behavior when mixing newer boards with older kernels.

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
index 859882109f55..60f765676a9d 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
@@ -1896,6 +1896,8 @@ static int amdgpu_discovery_set_gc_ip_blocks(struct 
amdgpu_device *adev)
amdgpu_device_ip_block_add(adev, &gfx_v9_0_ip_block);
break;
case IP_VERSION(9, 4, 3):
+   if (!amdgpu_exp_hw_support)
+   return -EINVAL;
amdgpu_device_ip_block_add(adev, &gfx_v9_4_3_ip_block);
break;
case IP_VERSION(10, 1, 10):
--
2.40.1



Re: [PATCH 2/3] drm/amdgpu: Implement new dummy vram manager

2023-06-15 Thread Felix Kuehling



Am 2023-06-15 um 03:37 schrieb Christian König:

Am 14.06.23 um 17:42 schrieb Felix Kuehling:

Am 2023-06-14 um 06:38 schrieb Christian König:

Am 10.05.23 um 00:01 schrieb Alex Deucher:

From: Rajneesh Bhardwaj 

This adds dummy vram manager to support ASICs that do not have a
dedicated or carvedout vram domain.


Well that doesn't seem to make much sense. Why we should have that?


TTM always expects a resource manager for VRAM. There are no NULL 
pointer checks in TTM for not having a resource manager for VRAM. The 
existing amdgpu_vram_mgr gets confused if there is no VRAM. It seemed 
cleaner to add a dummy manager than to scatter conditions for a 
memory-less GPU corner case through the regular VRAM manager.


Well no that's absolutely *not* cleaner. TTM has a predefined manager 
if you need to use a dummy.


I think you are referring to ttm_range_manager. ttm_range_man_alloc does 
a bunch of useless stuff when there is no hope of succeeding:


 * kzalloc a node struct
 * ttm_resource_init
 o add the node to an LRU
 * drm_mm_insert_node_in_range (which fails because the drm_mm was
   created with 0 size)
 * ttm_resource_fini
 o remove the node from an LRU
 * kfree the node struct

In that process it also takes 3 spin_locks. All of that for TTM to 
figure out that VRAM is not a feasible placement. All we need to do here 
in the dummy manager is to return -ENOSPC.


I really don't get why this bothers you so much, or why this is even 
controversial.


Regards,
  Felix




Why the heck didn't you ask me before doing stuff like that?

Regards,
Christian.



Regards,
  Felix




Christian.



Reviewed-by: Felix Kuehling 
Signed-off-by: Rajneesh Bhardwaj 
Signed-off-by: Alex Deucher 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 67 
++--

  1 file changed, 60 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c

index 43d6a9d6a538..89d35d194f2c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
@@ -370,6 +370,45 @@ int amdgpu_vram_mgr_query_page_status(struct 
amdgpu_vram_mgr *mgr,

  return ret;
  }
  +static void amdgpu_dummy_vram_mgr_debug(struct 
ttm_resource_manager *man,

+  struct drm_printer *printer)
+{
+    DRM_DEBUG_DRIVER("Dummy vram mgr debug\n");
+}
+
+static bool amdgpu_dummy_vram_mgr_compatible(struct 
ttm_resource_manager *man,

+   struct ttm_resource *res,
+   const struct ttm_place *place,
+   size_t size)
+{
+    DRM_DEBUG_DRIVER("Dummy vram mgr compatible\n");
+    return false;
+}
+
+static bool amdgpu_dummy_vram_mgr_intersects(struct 
ttm_resource_manager *man,

+   struct ttm_resource *res,
+   const struct ttm_place *place,
+   size_t size)
+{
+    DRM_DEBUG_DRIVER("Dummy vram mgr intersects\n");
+    return true;
+}
+
+static void amdgpu_dummy_vram_mgr_del(struct ttm_resource_manager 
*man,

+    struct ttm_resource *res)
+{
+    DRM_DEBUG_DRIVER("Dummy vram mgr deleted\n");
+}
+
+static int amdgpu_dummy_vram_mgr_new(struct ttm_resource_manager 
*man,

+   struct ttm_buffer_object *tbo,
+   const struct ttm_place *place,
+   struct ttm_resource **res)
+{
+    DRM_DEBUG_DRIVER("Dummy vram mgr new\n");
+    return -ENOSPC;
+}
+
  /**
   * amdgpu_vram_mgr_new - allocate new ranges
   *
@@ -817,6 +856,14 @@ static void amdgpu_vram_mgr_debug(struct 
ttm_resource_manager *man,

  mutex_unlock(&mgr->lock);
  }
  +static const struct ttm_resource_manager_func 
amdgpu_dummy_vram_mgr_func = {

+    .alloc    = amdgpu_dummy_vram_mgr_new,
+    .free    = amdgpu_dummy_vram_mgr_del,
+    .intersects = amdgpu_dummy_vram_mgr_intersects,
+    .compatible = amdgpu_dummy_vram_mgr_compatible,
+    .debug    = amdgpu_dummy_vram_mgr_debug
+};
+
  static const struct ttm_resource_manager_func 
amdgpu_vram_mgr_func = {

  .alloc    = amdgpu_vram_mgr_new,
  .free    = amdgpu_vram_mgr_del,
@@ -841,17 +888,22 @@ int amdgpu_vram_mgr_init(struct amdgpu_device 
*adev)

  ttm_resource_manager_init(man, &adev->mman.bdev,
    adev->gmc.real_vram_size);
  -    man->func = &amdgpu_vram_mgr_func;
-
-    err = drm_buddy_init(&mgr->mm, man->size, PAGE_SIZE);
-    if (err)
-    return err;
-
  mutex_init(&mgr->lock);
  INIT_LIST_HEAD(&mgr->reservations_pending);
  INIT_LIST_HEAD(&mgr->reserved_pages);
  mgr->default_page_size = PAGE_SIZE;
  +    if (!adev->gmc.is_app_apu) {
+    man->func = &amdgpu_vram_mgr_func;
+
+    err = drm_buddy_init(&mgr->mm, man->size, PAGE_SIZE);
+    if (err)
+    return err;
+    } else {
+    man->func = &amdgpu_dummy_vram_mgr_func;
+    DRM_INFO("Setup dummy vram mgr\n");
+    }
+
  ttm_set_driver_manager(&adev->mman.bdev, TTM_PL_VRAM, 

Re: [PATCH 2/2] drm/amd/display: disable RCO for DCN314

2023-06-15 Thread Harry Wentland



On 6/14/23 16:42, Hamza Mahfooz wrote:
> From: Daniel Miess 
> 
> [Why]
> RCO is causing error messages on some DCN314 systems
> 
> [How]
> Force disable RCO for DCN314
> 
> Fixes: 0e1961c93839 ("drm/amd/display: Enable dcn314 DPP RCO")
> Reviewed-by: Nicholas Kazlauskas 
> Acked-by: Hamza Mahfooz 
> Signed-off-by: Daniel Miess 

Series is
Reviewed-by: Harry Wentland 

Harry

> ---
>  drivers/gpu/drm/amd/display/dc/dcn314/dcn314_dccg.c | 2 +-
>  drivers/gpu/drm/amd/display/dc/dcn314/dcn314_resource.c | 3 +++
>  2 files changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/amd/display/dc/dcn314/dcn314_dccg.c 
> b/drivers/gpu/drm/amd/display/dc/dcn314/dcn314_dccg.c
> index cf23d7bc560a..0746ed31d1d1 100644
> --- a/drivers/gpu/drm/amd/display/dc/dcn314/dcn314_dccg.c
> +++ b/drivers/gpu/drm/amd/display/dc/dcn314/dcn314_dccg.c
> @@ -332,7 +332,7 @@ static void dccg314_dpp_root_clock_control(
>  {
>   struct dcn_dccg *dccg_dcn = TO_DCN_DCCG(dccg);
>  
> - if (dccg->dpp_clock_gated[dpp_inst] == clock_on)
> + if (dccg->dpp_clock_gated[dpp_inst] != clock_on)
>   return;
>  
>   if (clock_on) {
> diff --git a/drivers/gpu/drm/amd/display/dc/dcn314/dcn314_resource.c 
> b/drivers/gpu/drm/amd/display/dc/dcn314/dcn314_resource.c
> index ef49b4d7742f..6a9024aa3285 100644
> --- a/drivers/gpu/drm/amd/display/dc/dcn314/dcn314_resource.c
> +++ b/drivers/gpu/drm/amd/display/dc/dcn314/dcn314_resource.c
> @@ -1908,6 +1908,9 @@ static bool dcn314_resource_construct(
>   dc->debug.disable_dpp_power_gate = true;
>   dc->debug.disable_hubp_power_gate = true;
>  
> + /* Disable root clock optimization */
> + dc->debug.root_clock_optimization.u32All = 0;
> +
>   // Init the vm_helper
>   if (dc->vm_helper)
>   vm_helper_init(dc->vm_helper, 16);



[PATCH] drm/amdgpu: mark GC 9.4.3 experimental for now

2023-06-15 Thread Alex Deucher
Mark as experimental for now until we get closer to production
to avoid possible undesireable behavior when mixing newer
boards with older kernels.

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
index 859882109f55..60f765676a9d 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
@@ -1896,6 +1896,8 @@ static int amdgpu_discovery_set_gc_ip_blocks(struct 
amdgpu_device *adev)
amdgpu_device_ip_block_add(adev, &gfx_v9_0_ip_block);
break;
case IP_VERSION(9, 4, 3):
+   if (!amdgpu_exp_hw_support)
+   return -EINVAL;
amdgpu_device_ip_block_add(adev, &gfx_v9_4_3_ip_block);
break;
case IP_VERSION(10, 1, 10):
-- 
2.40.1



RE: [PATCH] drm/amdgpu/atomfirmware: fix DDR5 width reporting

2023-06-15 Thread Zhang, Hawking
[AMD Official Use Only - General]

Acked-by: Hawking Zhang 

Regards,
Hawking
-Original Message-
From: amd-gfx  On Behalf Of Alex Deucher
Sent: Thursday, June 15, 2023 21:18
To: Deucher, Alexander 
Cc: amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/amdgpu/atomfirmware: fix DDR5 width reporting

Ping?

On Mon, Jun 12, 2023 at 5:47 PM Alex Deucher  wrote:
>
> Ping?
>
> On Wed, Jun 7, 2023 at 12:46 PM Alex Deucher  
> wrote:
> >
> > DDR5 channels are 32 bit rather than 64, report the width properly
> > in the log.
> >
> > Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2468
> > Signed-off-by: Alex Deucher 
> > ---
> >  .../gpu/drm/amd/amdgpu/amdgpu_atomfirmware.c  | 20
> > +--
> >  1 file changed, 14 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_atomfirmware.c
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_atomfirmware.c
> > index ef4b9a41f20a..6b3bdc27f778 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_atomfirmware.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_atomfirmware.c
> > @@ -327,10 +327,14 @@ amdgpu_atomfirmware_get_vram_info(struct 
> > amdgpu_device *adev,
> > mem_channel_number = 
> > igp_info->v11.umachannelnumber;
> > if (!mem_channel_number)
> > mem_channel_number = 1;
> > -   /* channel width is 64 */
> > -   if (vram_width)
> > -   *vram_width = 
> > mem_channel_number * 64;
> > mem_type =
> > igp_info->v11.memorytype;
> > +   if ((mem_type == Ddr5MemType) ||
> > +   (mem_type == LpDdr5MemType))
> > +   mem_channel_width = 32;
> > +   else
> > +   mem_channel_width = 64;
> > +   if (vram_width)
> > +   *vram_width =
> > + mem_channel_number * mem_channel_width;
> > if (vram_type)
> > *vram_type = 
> > convert_atom_mem_type_to_vram_type(adev, mem_type);
> > break; @@ -345,10 +349,14 @@
> > amdgpu_atomfirmware_get_vram_info(struct amdgpu_device *adev,
> > mem_channel_number = 
> > igp_info->v21.umachannelnumber;
> > if (!mem_channel_number)
> > mem_channel_number = 1;
> > -   /* channel width is 64 */
> > -   if (vram_width)
> > -   *vram_width = 
> > mem_channel_number * 64;
> > mem_type =
> > igp_info->v21.memorytype;
> > +   if ((mem_type == Ddr5MemType) ||
> > +   (mem_type == LpDdr5MemType))
> > +   mem_channel_width = 32;
> > +   else
> > +   mem_channel_width = 64;
> > +   if (vram_width)
> > +   *vram_width =
> > + mem_channel_number * mem_channel_width;
> > if (vram_type)
> > *vram_type = 
> > convert_atom_mem_type_to_vram_type(adev, mem_type);
> > break;
> > --
> > 2.40.1
> >


Re: [PATCH] drm/amdgpu: Skip mark offset for high priority rings

2023-06-15 Thread Alex Deucher
Acked-by: Alex Deucher 

On Thu, Jun 15, 2023 at 7:19 AM  wrote:
>
> From: Jiadong Zhu 
>
> Only low priority rings are using chunks to save the offset.
> Bypass the mark offset callings from high priority rings.
>
> Signed-off-by: Jiadong Zhu 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ring_mux.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring_mux.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring_mux.c
> index 73516abef662..b779ee4bbaa7 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring_mux.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring_mux.c
> @@ -423,6 +423,9 @@ void amdgpu_sw_ring_ib_mark_offset(struct amdgpu_ring 
> *ring, enum amdgpu_ring_mu
> struct amdgpu_ring_mux *mux = &adev->gfx.muxer;
> unsigned offset;
>
> +   if (ring->hw_prio > AMDGPU_RING_PRIO_DEFAULT)
> +   return;
> +
> offset = ring->wptr & ring->buf_mask;
>
> amdgpu_ring_mux_ib_mark_offset(mux, ring, offset, type);
> --
> 2.25.1
>


Re: [PATCH] drm/amdgpu/atomfirmware: fix DDR5 width reporting

2023-06-15 Thread Alex Deucher
Ping?

On Mon, Jun 12, 2023 at 5:47 PM Alex Deucher  wrote:
>
> Ping?
>
> On Wed, Jun 7, 2023 at 12:46 PM Alex Deucher  
> wrote:
> >
> > DDR5 channels are 32 bit rather than 64, report the width properly
> > in the log.
> >
> > Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2468
> > Signed-off-by: Alex Deucher 
> > ---
> >  .../gpu/drm/amd/amdgpu/amdgpu_atomfirmware.c  | 20 +--
> >  1 file changed, 14 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_atomfirmware.c 
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_atomfirmware.c
> > index ef4b9a41f20a..6b3bdc27f778 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_atomfirmware.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_atomfirmware.c
> > @@ -327,10 +327,14 @@ amdgpu_atomfirmware_get_vram_info(struct 
> > amdgpu_device *adev,
> > mem_channel_number = 
> > igp_info->v11.umachannelnumber;
> > if (!mem_channel_number)
> > mem_channel_number = 1;
> > -   /* channel width is 64 */
> > -   if (vram_width)
> > -   *vram_width = 
> > mem_channel_number * 64;
> > mem_type = igp_info->v11.memorytype;
> > +   if ((mem_type == Ddr5MemType) ||
> > +   (mem_type == LpDdr5MemType))
> > +   mem_channel_width = 32;
> > +   else
> > +   mem_channel_width = 64;
> > +   if (vram_width)
> > +   *vram_width = 
> > mem_channel_number * mem_channel_width;
> > if (vram_type)
> > *vram_type = 
> > convert_atom_mem_type_to_vram_type(adev, mem_type);
> > break;
> > @@ -345,10 +349,14 @@ amdgpu_atomfirmware_get_vram_info(struct 
> > amdgpu_device *adev,
> > mem_channel_number = 
> > igp_info->v21.umachannelnumber;
> > if (!mem_channel_number)
> > mem_channel_number = 1;
> > -   /* channel width is 64 */
> > -   if (vram_width)
> > -   *vram_width = 
> > mem_channel_number * 64;
> > mem_type = igp_info->v21.memorytype;
> > +   if ((mem_type == Ddr5MemType) ||
> > +   (mem_type == LpDdr5MemType))
> > +   mem_channel_width = 32;
> > +   else
> > +   mem_channel_width = 64;
> > +   if (vram_width)
> > +   *vram_width = 
> > mem_channel_number * mem_channel_width;
> > if (vram_type)
> > *vram_type = 
> > convert_atom_mem_type_to_vram_type(adev, mem_type);
> > break;
> > --
> > 2.40.1
> >


Re: [RFC PATCH v2 00/18] Add DRM CRTC 3D LUT interface

2023-06-15 Thread Jacopo Mondi
Hi Pekka
thanks for the reply

On Thu, Jun 15, 2023 at 10:14:05AM +0300, Pekka Paalanen wrote:
> On Tue, 13 Jun 2023 17:43:55 +0200
> Jacopo Mondi  wrote:
>
> > Hello
> >
> >I'm completing the support for 3D LUT on R-Car DU peripheral
> > and I have used this series as a base.
> >
> > I'm wondering, since quite some time has passed without any update if
> > this series is still a thing and it makes any sense for me to try to
> > bring it forward.
> >
> > I'm asking as I've noticed:
> > "[PATCH 00/36] drm/amd/display: add AMD driver-specific properties for 
> > color mgmt"
> >
> > which seems to supersede this proposal with driver-specific
> > properties.
> >
> > I asked Melissa privately but I wasn't able to get an hold of her, so
> > if anyone has any clue feel free to reply :)
>
> Hi,
>
> since no-one else replied, I'll point you to the thread starting at
> https://lists.freedesktop.org/archives/dri-devel/2023-May/403173.html

Yes, Melissa pointed me to that series privately yesterday.

However, and here I might be missing something, per-plane properties do
not apply well to the HW pipeline I'm looking at.

The R-Car DU has a 1D LUT and a 3D LUT at the CRTC level (I guess
'post blending' is the right term here) ?  A per-plane property
doesn't seem to match how the HW work, but please feel free to correct
me as this is all rather new to me and I might be overlooking
something.

My plan at the moment would have been to base my work on Melissa's RFC
and re-send to prop discussions, unless it is certainly a dead-end and
I have missed how to properly use per-plane properties on our HW.

Thank you!

> and continuing to June. That is the plan of getting a common UAPI for
> these things.
>
>
> Thanks,
> pq
>
>
> >
> > Thanks
> >   j
> >
> > On Mon, Jan 09, 2023 at 01:38:28PM -0100, Melissa Wen wrote:
> > > Hi,
> > >
> > > After collecting comments in different places, here is a second version
> > > of the work on adding DRM CRTC 3D LUT support to the current DRM color
> > > mgmt interface. In comparison to previous proposals [1][2][3], here we
> > > add 3D LUT before gamma 1D LUT, but also a shaper 1D LUT before 3D LUT,
> > > that means the following DRM CRTC color correction pipeline:
> > >
> > > Blend -> Degamma 1D LUT -> CTM -> Shaper 1D LUT -> 3D LUT -> Gamma 1D LUT
> > >
> > > and we also add a DRM CRTC LUT3D_MODE property, based on Alex Hung
> > > proposal for pre-blending 3D LUT [4] (Thanks!), instead of just a
> > > LUT3D_SIZE, that allows userspace to use different supported settings of
> > > 3D LUT, fitting VA-API and new color API better. In this sense, I
> > > adjusted the pre-blending proposal for post-blending usage.
> > >
> > > Patches 1-6 targets the addition of shaper LUT and 3D LUT properties to
> > > the current DRM CRTC color mgmt pipeline. Patch 6 can be considered an
> > > extra/optional patch to define a default value for LUT3D_MODE, inspired
> > > by what we do for the plane blend mode property (pre-multiplied).
> > >
> > > Patches 7-18 targets AMD display code to enable shaper and 3D LUT usage
> > > on DCN 301 (our HW case). Patches 7-9 performs code cleanups on current
> > > AMD DM colors code, patch 10 updates AMD stream in case of user 3D LUT
> > > changes, patch 11/12 rework AMD MPC 3D LUT resource handling by context
> > > for DCN 301 (easily extendible to other DCN families). Finally, from
> > > 13-18, we wire up SHAPER LUT, LUT3D and LUT3D MODE to AMD display
> > > driver, exposing modes supported by HW and programming user shaper and
> > > 3D LUT accordingly.
> > >
> > > Our target userspace is Gamescope/SteamOS.
> > >
> > > Basic IGT tests were based on [5][6] and are available here (in-progress):
> > > https://gitlab.freedesktop.org/mwen/igt-gpu-tools/-/commits/crtc-lut3d-api
> > >
> > > [1] 
> > > https://lore.kernel.org/all/20201221015730.28333-1-laurent.pinchart+rene...@ideasonboard.com/
> > > [2] 
> > > https://github.com/vsyrjala/linux/commit/4d28e8ddf2a076f30f9e5bdc17cbb4656fe23e69
> > > [3] 
> > > https://lore.kernel.org/amd-gfx/20220619223104.667413-1-m...@igalia.com/
> > > [4] 
> > > https://lore.kernel.org/dri-devel/20221004211451.1475215-1-alex.h...@amd.com/
> > > [5] https://patchwork.freedesktop.org/series/90165/
> > > [6] https://patchwork.freedesktop.org/series/109402/
> > > [VA_API] 
> > > http://intel.github.io/libva/structVAProcFilterParameterBuffer3DLUT.html
> > > [KMS_pipe_API] https://gitlab.freedesktop.org/pq/color-and-hdr/-/issues/11
> > >
> > > Let me know your thoughts.
> > >
> > > Thanks,
> > >
> > > Melissa
> > >
> > > Alex Hung (2):
> > >   drm: Add 3D LUT mode and its attributes
> > >   drm/amd/display: Define 3D LUT struct for HDR planes
> > >
> > > Melissa Wen (16):
> > >   drm/drm_color_mgmt: add shaper LUT to color mgmt properties
> > >   drm/drm_color_mgmt: add 3D LUT props to DRM color mgmt
> > >   drm/drm_color_mgmt: add function to create 3D LUT modes supported
> > >   drm/drm_color_mgmt: add function to attach 3D LUT props
> > >   d

Re: Fw: [PATCH] drm/amdgpu: add amdgpu_timeout_ring_* file to debugfs

2023-06-15 Thread Alex Deucher
On Thu, Jun 15, 2023 at 5:14 AM Christian König
 wrote:
>
> Am 15.06.23 um 10:55 schrieb Nicolai Hähnle:
> > On Thu, Jun 15, 2023 at 9:47 AM Christian König
> >  wrote:
>  Uh, that's very dangerous what you do here and wouldn't work in a whole
>  bunch of cases.
> >>> Please elaborate: *what* case doesn't work?
> >> The core memory management can wait at any time for the GPU reset to 
> >> finish.
> >>
> >> If we set the timeout to infinity we risk just deadlocking the kernel.
> > Okay, thanks. I may have seen some aspect of this before in cases
> > where GPU reset failed and left processes in an unkillable state.
> >
> > I'll be honest, I've seen my fair share of exotic GPU hangs and to put
> > it mildly I'm not impressed by the kernel's handling of them.
>
> Yeah, and I completely agree with you. The whole situation around that
> is just horrible.
>
> > Obviously you know much more about the intricacies of kernel memory
> > management than I do, but the fact that processes can end up in an
> > unkillable state for *any* GPU-related reason feels to me like the
> > result of a bad design decision somewhere.
> >
> > But anyway, I'm not even asking you to fix those problems. All I'm
> > asking you is to let me do *my* job, part of which is to help prevent
> > GPU hangs from happening in the first place. For that, I need useful
> > debugging facilities -- and so do others.
> >
> >
> >>> Again, being able to disable GPU recovery is a crucial debugging
> >>> feature. We need to be able to inspect the live state of hung shaders,
> >>> and we need to be able to single-step through shaders. All of that
> >>> requires disabling GPU recovery.
> >> Yeah, I'm perfectly aware of that. The problem is this is just *not*
> >> supported on Linux for graphics shaders.
> >>
> >> What you can do is to run the shader with something like CWSR enabled
> >> (or an to be invented graphics equivalent). Since we are debugging the
> >> shader anyway that should be possible I think.
> >>
> >>> Forcing people to reboot just to be able to disable GPU recovery for
> >>> debugging is developer hostile.
> >> Well, I think you misunderstood me. The suggestion was even to force
> >> them to re-compile the kernel driver to disable GPU recovery.
> >>
> >> Disabling GPU recovery is *not* something you can do and expect the
> >> system to be stable.
> >>
> >> The only case we can do that is when we attach a JTAG debugger in an AMD
> >> lab.
> > You're being *completely* unreasonable here. Even Windows(!) allows
> > disabling GPU recovery at runtime from software, and Windows is
> > usually far more developer hostile than Linux in these things.
> > Seriously, this level of hostility against developers coming from you
> > is not okay.
>
> Well, I'm not hostile against developers, but just realistic that this
> will lead to even more problems.
>
> And I rather avoid problems with end-users than with developers because
> the later are usually the more skilled people.
>
> As far as I can see that Windows allowed to disable GPU recovery was
> actually the source of the problem and is absolutely no argument to
> repeat the same mistake on Linux again.
>
> > Yes, it's a tool that has sharp edges. That is perfectly well
> > understood. If we need to add warning labels then so be it. And if the
> > details of *how* to change the timeout or disable GPU recovery at
> > runtime should be changed, that too is fine. But it's an important
> > tool. Can we please just move forward on this in a pragmatic fashion?
>
> Yes and because of this I'm just rejecting this approach here.
>
> Rebooting to disable GPU reset is perfectly fine and reasonable to do
> for a developer.
>
> As I said the requirement I have for the other extreme is to make it a
> compile time only option and I'm trying to avoid that as well.

I have to agree with Nicolai here.  I think it's reasonable to be able
to enable a debugging mode at runtime if you are root.  There are
plenty of other dangerous things you can do via debugfs.  This is the
least of our worries.  Pretty much the first thing anyone one does
when trying to debug a hang is to disable reset.  This seems like a
nice compromise.

Alex

>
> Regards,
> Christian.
>
> >
> > Thanks,
> > Nicolai
> >
> >
> >> Regards,
> >> Christian.
> >>
> >>> So again, if there really are cases where this "doesn't work" (and
> >>> those cases aren't just that your desktop will freeze -- that part is
> >>> intentional), then let's talk through it and see how to address them.
> >>>
> >>> Thanks,
> >>> Nicolai
> >>>
> >>>
>  Regards,
>  Christian.
> 
> > Signed-off-by: Nicolai Hähnle 
> > ---
> > drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c | 32 
> > +++-
> > 1 file changed, 31 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c 
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c
> > index dc474b809604..32d223daa789 100644
> > --- a/drive

RE: [PATCH] drm/amdgpu: Rename aqua_vanjaram_reg_init.c

2023-06-15 Thread Zhang, Hawking
[AMD Official Use Only - General]

Reviewed-by: Hawking Zhang 

Regards,
Hawking
-Original Message-
From: Lazar, Lijo 
Sent: Thursday, June 15, 2023 18:29
To: amd-gfx@lists.freedesktop.org
Cc: Zhang, Hawking ; Deucher, Alexander 
; Kamal, Asad ; Ma, Le 

Subject: [PATCH] drm/amdgpu: Rename aqua_vanjaram_reg_init.c

This contains SOC specific functions, rename to a more generic format .c 
=> aqua_vanjaram.c

Signed-off-by: Lijo Lazar 
---
 drivers/gpu/drm/amd/amdgpu/Makefile | 2 +-
 .../amd/amdgpu/{aqua_vanjaram_reg_init.c => aqua_vanjaram.c}| 0
 2 files changed, 1 insertion(+), 1 deletion(-)  rename 
drivers/gpu/drm/amd/amdgpu/{aqua_vanjaram_reg_init.c => aqua_vanjaram.c} (100%)

diff --git a/drivers/gpu/drm/amd/amdgpu/Makefile 
b/drivers/gpu/drm/amd/amdgpu/Makefile
index 8d16f280b695..60c800d22e89 100644
--- a/drivers/gpu/drm/amd/amdgpu/Makefile
+++ b/drivers/gpu/drm/amd/amdgpu/Makefile
@@ -98,7 +98,7 @@ amdgpu-y += \
vega20_reg_init.o nbio_v7_4.o nbio_v2_3.o nv.o arct_reg_init.o 
mxgpu_nv.o \
nbio_v7_2.o hdp_v4_0.o hdp_v5_0.o aldebaran_reg_init.o aldebaran.o 
soc21.o \
sienna_cichlid.o smu_v13_0_10.o nbio_v4_3.o hdp_v6_0.o nbio_v7_7.o 
hdp_v5_2.o lsdma_v6_0.o \
-   nbio_v7_9.o aqua_vanjaram_reg_init.o
+   nbio_v7_9.o aqua_vanjaram.o

 # add DF block
 amdgpu-y += \
diff --git a/drivers/gpu/drm/amd/amdgpu/aqua_vanjaram_reg_init.c 
b/drivers/gpu/drm/amd/amdgpu/aqua_vanjaram.c
similarity index 100%
rename from drivers/gpu/drm/amd/amdgpu/aqua_vanjaram_reg_init.c
rename to drivers/gpu/drm/amd/amdgpu/aqua_vanjaram.c
--
2.25.1



Re: [PATCH 3/9] drm/ttm: use per BO cleanup workers

2023-06-15 Thread Karol Herbst
On Thu, Jun 15, 2023 at 1:19 PM Christian König
 wrote:
>
> Am 13.06.23 um 16:18 schrieb Karol Herbst:
> > On Tue, Jun 13, 2023 at 3:59 PM Christian König
> >  wrote:
> >> Am 13.06.23 um 15:05 schrieb Karol Herbst:
> >>> On Mon, Dec 5, 2022 at 2:40 PM Christian König  
> >>> wrote:
>  Am 29.11.22 um 22:14 schrieb Felix Kuehling:
> > On 2022-11-25 05:21, Christian König wrote:
> >> Instead of a single worker going over the list of delete BOs in regular
> >> intervals use a per BO worker which blocks for the resv object and
> >> locking of the BO.
> >>
> >> This not only simplifies the handling massively, but also results in
> >> much better response time when cleaning up buffers.
> >>
> >> Signed-off-by: Christian König 
> > Just thinking out loud: If I understand it correctly, this can cause a
> > lot of sleeping worker threads when
> > AMDGPU_GEM_CREATE_VRAM_WIPE_ON_RELEASE is used and many BOs are freed
> > at the same time. This happens e.g. when a KFD process terminates or
> > crashes. I guess with a concurrency-managed workqueue this isn't going
> > to be excessive. And since it's on a per device workqueue, it doesn't
> > stall work items on the system work queue or from other devices.
>  Yes, exactly that. The last parameter to alloc_workqueue() limits how
>  many work items can be sleeping.
> 
> > I'm trying to understand why you set WQ_MEM_RECLAIM. This work queue
> > is not about freeing ttm_resources but about freeing the BOs. But it
> > affects freeing of ghost_objs that are holding the ttm_resources being
> > freed.
>  Well if the BO is idle, but not immediately lockable we delegate freeing
>  the backing pages in the TT object to those workers as well. It might
>  even be a good idea to use a separate wq for this case.
> 
> > If those assumptions all make sense, patches 1-3 are
> >
> > Reviewed-by: Felix Kuehling 
>  Thanks,
>  Christian.
> 
> >>> This patch causes a heap use-after-free when using nouveau with the
> >>> potential of trashing filesystems, is there a way to revert it until
> >>> we figure out a proper solution to the problem?
> >> Uff I don't think so, we have quite some work based on top of this. But
> >> let me double check.
> >>
> > yeah.. I already talked with Dave about fixing this issue as Dave has
> > more knowledge on this part of the driver (I hope), so we might have a
> > fix soonish, but the concerning part is, that it's already out to
> > users, so might be better to be able to revert it if the fix takes a
> > while to emerge.
>
> We at least can't revert easily. This was fixing issues where we have
> seen OOM situations because TTM wasn't releasing resources fast enough.
>
> >> On the other hand have you tried running this with KASAN to catch use
> >> after free errors?
> > yes: https://gitlab.freedesktop.org/drm/nouveau/-/issues/213#note_1942777
> >
> >> Since we now block for work to finish and not check every few
> >> milliseconds to garbage collect memory will now be reclaimed much faster
> >> after freeing it.
> > yeah, that kinda makes sense. This entire issue feels like a race
> > happening as I need to run the OpenGL CTS in parallel with 8+ threads
> > to trigger it reliably.
>
> Yeah, from the bug report that's a classic use after free because of a race.
>
> Easiest would be to make sure everybody has a reference to the fence.
>

turns out nouveau was using `dma_fence_is_signaled_locked` without
taking the lock. Fixing that seems to improve the situation by a lot,
so I think we have a fix to resolve this problem.

> Regards,
> Christian.
>
> >
> >> Regards,
> >> Christian.
> >>
> >>> Bug: https://gitlab.freedesktop.org/drm/nouveau/-/issues/213
> >>>
> >>> example trace on affected systems:
> >>>
> >>> [ 4102.946946] general protection fault, probably for non-canonical
> >>> address 0x5f775ce3bd949b45:  [#3] PREEMPT SMP NOPTI
> >>> [ 4102.957794] CPU: 12 PID: 89561 Comm: glcts Tainted: G  D
> >>>   6.3.5-200.fc38.x86_64 #1
> >>> [ 4102.966556] Hardware name: ASUS System Product Name/PRIME B660-PLUS
> >>> D4, BIOS 0418 10/13/2021
> >>> [ 4102.974972] RIP: 0010:__kmem_cache_alloc_node+0x1ba/0x320
> >>> [ 4102.980362] Code: 2b 14 25 28 00 00 00 0f 85 74 01 00 00 48 83 c4
> >>> 18 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc 41 8b 47 28 4d 8b 07
> >>> 48 01 f8 <48> 8b 18 48 89 c1 49 33 9f b8 00 00 00 48 0f c9 48 31 cb 41
> >>> f6 c0
> >>> [ 4102.999073] RSP: 0018:9764e0057b40 EFLAGS: 00010202
> >>> [ 4103.004291] RAX: 5f775ce3bd949b45 RBX: 0dc0 RCX: 
> >>> 0046
> >>> [ 4103.011408] RDX: 0002cf87600c RSI: 0dc0 RDI: 
> >>> 5f775ce3bd949b15
> >>> [ 4103.018528] RBP: 0dc0 R08: 000390c0 R09: 
> >>> 30302d6d
> >>> [ 4103.025649] R10: 756c7473 R11: 20090298 R12: 
> >>> 
> >>> [ 4103.032767] R13:  R14: 

Re: [PATCH 3/9] drm/ttm: use per BO cleanup workers

2023-06-15 Thread Christian König

Am 13.06.23 um 16:18 schrieb Karol Herbst:

On Tue, Jun 13, 2023 at 3:59 PM Christian König
 wrote:

Am 13.06.23 um 15:05 schrieb Karol Herbst:

On Mon, Dec 5, 2022 at 2:40 PM Christian König  wrote:

Am 29.11.22 um 22:14 schrieb Felix Kuehling:

On 2022-11-25 05:21, Christian König wrote:

Instead of a single worker going over the list of delete BOs in regular
intervals use a per BO worker which blocks for the resv object and
locking of the BO.

This not only simplifies the handling massively, but also results in
much better response time when cleaning up buffers.

Signed-off-by: Christian König 

Just thinking out loud: If I understand it correctly, this can cause a
lot of sleeping worker threads when
AMDGPU_GEM_CREATE_VRAM_WIPE_ON_RELEASE is used and many BOs are freed
at the same time. This happens e.g. when a KFD process terminates or
crashes. I guess with a concurrency-managed workqueue this isn't going
to be excessive. And since it's on a per device workqueue, it doesn't
stall work items on the system work queue or from other devices.

Yes, exactly that. The last parameter to alloc_workqueue() limits how
many work items can be sleeping.


I'm trying to understand why you set WQ_MEM_RECLAIM. This work queue
is not about freeing ttm_resources but about freeing the BOs. But it
affects freeing of ghost_objs that are holding the ttm_resources being
freed.

Well if the BO is idle, but not immediately lockable we delegate freeing
the backing pages in the TT object to those workers as well. It might
even be a good idea to use a separate wq for this case.


If those assumptions all make sense, patches 1-3 are

Reviewed-by: Felix Kuehling 

Thanks,
Christian.


This patch causes a heap use-after-free when using nouveau with the
potential of trashing filesystems, is there a way to revert it until
we figure out a proper solution to the problem?

Uff I don't think so, we have quite some work based on top of this. But
let me double check.


yeah.. I already talked with Dave about fixing this issue as Dave has
more knowledge on this part of the driver (I hope), so we might have a
fix soonish, but the concerning part is, that it's already out to
users, so might be better to be able to revert it if the fix takes a
while to emerge.


We at least can't revert easily. This was fixing issues where we have 
seen OOM situations because TTM wasn't releasing resources fast enough.



On the other hand have you tried running this with KASAN to catch use
after free errors?

yes: https://gitlab.freedesktop.org/drm/nouveau/-/issues/213#note_1942777


Since we now block for work to finish and not check every few
milliseconds to garbage collect memory will now be reclaimed much faster
after freeing it.

yeah, that kinda makes sense. This entire issue feels like a race
happening as I need to run the OpenGL CTS in parallel with 8+ threads
to trigger it reliably.


Yeah, from the bug report that's a classic use after free because of a race.

Easiest would be to make sure everybody has a reference to the fence.

Regards,
Christian.




Regards,
Christian.


Bug: https://gitlab.freedesktop.org/drm/nouveau/-/issues/213

example trace on affected systems:

[ 4102.946946] general protection fault, probably for non-canonical
address 0x5f775ce3bd949b45:  [#3] PREEMPT SMP NOPTI
[ 4102.957794] CPU: 12 PID: 89561 Comm: glcts Tainted: G  D
  6.3.5-200.fc38.x86_64 #1
[ 4102.966556] Hardware name: ASUS System Product Name/PRIME B660-PLUS
D4, BIOS 0418 10/13/2021
[ 4102.974972] RIP: 0010:__kmem_cache_alloc_node+0x1ba/0x320
[ 4102.980362] Code: 2b 14 25 28 00 00 00 0f 85 74 01 00 00 48 83 c4
18 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc 41 8b 47 28 4d 8b 07
48 01 f8 <48> 8b 18 48 89 c1 49 33 9f b8 00 00 00 48 0f c9 48 31 cb 41
f6 c0
[ 4102.999073] RSP: 0018:9764e0057b40 EFLAGS: 00010202
[ 4103.004291] RAX: 5f775ce3bd949b45 RBX: 0dc0 RCX: 0046
[ 4103.011408] RDX: 0002cf87600c RSI: 0dc0 RDI: 5f775ce3bd949b15
[ 4103.018528] RBP: 0dc0 R08: 000390c0 R09: 30302d6d
[ 4103.025649] R10: 756c7473 R11: 20090298 R12: 
[ 4103.032767] R13:  R14: 0046 R15: 8bda80042600
[ 4103.039887] FS:  7f386a85ef00() GS:8be1df70()
knlGS:
[ 4103.047958] CS:  0010 DS:  ES:  CR0: 80050033
[ 4103.053692] CR2: 0493b868 CR3: 00014c3ba000 CR4: 00f50ee0
[ 4103.060812] PKRU: 5554
[ 4103.063520] Call Trace:
[ 4103.065970]  
[ 4103.068071]  ? die_addr+0x36/0x90
[ 4103.071384]  ? exc_general_protection+0x1be/0x420
[ 4103.076081]  ? asm_exc_general_protection+0x26/0x30
[ 4103.080952]  ? __kmem_cache_alloc_node+0x1ba/0x320
[ 4103.085734]  ? ext4_htree_store_dirent+0x42/0x180
[ 4103.090431]  ? ext4_htree_store_dirent+0x42/0x180
[ 4103.095132]  __kmalloc+0x4d/0x150
[ 4103.098444]  ext4_htree_store_dirent+0x42/0x180
[ 4103.102970]  htree_dirblock_to_tree+0x1ed/0x370
[ 4

[PATCH] drm/amdgpu: Skip mark offset for high priority rings

2023-06-15 Thread jiadong.zhu
From: Jiadong Zhu 

Only low priority rings are using chunks to save the offset.
Bypass the mark offset callings from high priority rings.

Signed-off-by: Jiadong Zhu 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_ring_mux.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring_mux.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring_mux.c
index 73516abef662..b779ee4bbaa7 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring_mux.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring_mux.c
@@ -423,6 +423,9 @@ void amdgpu_sw_ring_ib_mark_offset(struct amdgpu_ring 
*ring, enum amdgpu_ring_mu
struct amdgpu_ring_mux *mux = &adev->gfx.muxer;
unsigned offset;
 
+   if (ring->hw_prio > AMDGPU_RING_PRIO_DEFAULT)
+   return;
+
offset = ring->wptr & ring->buf_mask;
 
amdgpu_ring_mux_ib_mark_offset(mux, ring, offset, type);
-- 
2.25.1



Re: [RFC PATCH v2 00/18] Add DRM CRTC 3D LUT interface

2023-06-15 Thread Pekka Paalanen
On Thu, 15 Jun 2023 10:07:35 +0200
Jacopo Mondi  wrote:

> Hi Pekka
> thanks for the reply
> 
> On Thu, Jun 15, 2023 at 10:14:05AM +0300, Pekka Paalanen wrote:
> > On Tue, 13 Jun 2023 17:43:55 +0200
> > Jacopo Mondi  wrote:
> >  
> > > Hello
> > >
> > >I'm completing the support for 3D LUT on R-Car DU peripheral
> > > and I have used this series as a base.
> > >
> > > I'm wondering, since quite some time has passed without any update if
> > > this series is still a thing and it makes any sense for me to try to
> > > bring it forward.
> > >
> > > I'm asking as I've noticed:
> > > "[PATCH 00/36] drm/amd/display: add AMD driver-specific properties for 
> > > color mgmt"
> > >
> > > which seems to supersede this proposal with driver-specific
> > > properties.
> > >
> > > I asked Melissa privately but I wasn't able to get an hold of her, so
> > > if anyone has any clue feel free to reply :)  
> >
> > Hi,
> >
> > since no-one else replied, I'll point you to the thread starting at
> > https://lists.freedesktop.org/archives/dri-devel/2023-May/403173.html  
> 
> Yes, Melissa pointed me to that series privately yesterday.
> 
> However, and here I might be missing something, per-plane properties do
> not apply well to the HW pipeline I'm looking at.
> 
> The R-Car DU has a 1D LUT and a 3D LUT at the CRTC level (I guess
> 'post blending' is the right term here) ?  A per-plane property
> doesn't seem to match how the HW work, but please feel free to correct
> me as this is all rather new to me and I might be overlooking
> something.

Post-blending, correct. The long term plan is to replicate the same
idea to post-blending as it is planned for pre-blending.

> 
> My plan at the moment would have been to base my work on Melissa's RFC
> and re-send to prop discussions, unless it is certainly a dead-end and
> I have missed how to properly use per-plane properties on our HW.

I'm not a kernel dev nor a maintainer, so I can't comment on what would
be acceptable in the mean time before the new pipeline design is
implemented. The long term plan is to supersede all existing color
transformation related properties with pipelines.


Thanks,
pq

> 
> Thank you!
> 
> > and continuing to June. That is the plan of getting a common UAPI for
> > these things.
> >
> >
> > Thanks,
> > pq
> >
> >  
> > >
> > > Thanks
> > >   j
> > >
> > > On Mon, Jan 09, 2023 at 01:38:28PM -0100, Melissa Wen wrote:  
> > > > Hi,
> > > >
> > > > After collecting comments in different places, here is a second version
> > > > of the work on adding DRM CRTC 3D LUT support to the current DRM color
> > > > mgmt interface. In comparison to previous proposals [1][2][3], here we
> > > > add 3D LUT before gamma 1D LUT, but also a shaper 1D LUT before 3D LUT,
> > > > that means the following DRM CRTC color correction pipeline:
> > > >
> > > > Blend -> Degamma 1D LUT -> CTM -> Shaper 1D LUT -> 3D LUT -> Gamma 1D 
> > > > LUT
> > > >
> > > > and we also add a DRM CRTC LUT3D_MODE property, based on Alex Hung
> > > > proposal for pre-blending 3D LUT [4] (Thanks!), instead of just a
> > > > LUT3D_SIZE, that allows userspace to use different supported settings of
> > > > 3D LUT, fitting VA-API and new color API better. In this sense, I
> > > > adjusted the pre-blending proposal for post-blending usage.
> > > >
> > > > Patches 1-6 targets the addition of shaper LUT and 3D LUT properties to
> > > > the current DRM CRTC color mgmt pipeline. Patch 6 can be considered an
> > > > extra/optional patch to define a default value for LUT3D_MODE, inspired
> > > > by what we do for the plane blend mode property (pre-multiplied).
> > > >
> > > > Patches 7-18 targets AMD display code to enable shaper and 3D LUT usage
> > > > on DCN 301 (our HW case). Patches 7-9 performs code cleanups on current
> > > > AMD DM colors code, patch 10 updates AMD stream in case of user 3D LUT
> > > > changes, patch 11/12 rework AMD MPC 3D LUT resource handling by context
> > > > for DCN 301 (easily extendible to other DCN families). Finally, from
> > > > 13-18, we wire up SHAPER LUT, LUT3D and LUT3D MODE to AMD display
> > > > driver, exposing modes supported by HW and programming user shaper and
> > > > 3D LUT accordingly.
> > > >
> > > > Our target userspace is Gamescope/SteamOS.
> > > >
> > > > Basic IGT tests were based on [5][6] and are available here 
> > > > (in-progress):
> > > > https://gitlab.freedesktop.org/mwen/igt-gpu-tools/-/commits/crtc-lut3d-api
> > > >
> > > > [1] 
> > > > https://lore.kernel.org/all/20201221015730.28333-1-laurent.pinchart+rene...@ideasonboard.com/
> > > > [2] 
> > > > https://github.com/vsyrjala/linux/commit/4d28e8ddf2a076f30f9e5bdc17cbb4656fe23e69
> > > > [3] 
> > > > https://lore.kernel.org/amd-gfx/20220619223104.667413-1-m...@igalia.com/
> > > > [4] 
> > > > https://lore.kernel.org/dri-devel/20221004211451.1475215-1-alex.h...@amd.com/
> > > > [5] https://patchwork.freedesktop.org/series/90165/
> > > > [6] https://patchwork.freedesktop.org/series/109402/
> > > 

[PATCH] drm/amdgpu: Rename aqua_vanjaram_reg_init.c

2023-06-15 Thread Lijo Lazar
This contains SOC specific functions, rename to a more generic format
.c => aqua_vanjaram.c

Signed-off-by: Lijo Lazar 
---
 drivers/gpu/drm/amd/amdgpu/Makefile | 2 +-
 .../amd/amdgpu/{aqua_vanjaram_reg_init.c => aqua_vanjaram.c}| 0
 2 files changed, 1 insertion(+), 1 deletion(-)
 rename drivers/gpu/drm/amd/amdgpu/{aqua_vanjaram_reg_init.c => 
aqua_vanjaram.c} (100%)

diff --git a/drivers/gpu/drm/amd/amdgpu/Makefile 
b/drivers/gpu/drm/amd/amdgpu/Makefile
index 8d16f280b695..60c800d22e89 100644
--- a/drivers/gpu/drm/amd/amdgpu/Makefile
+++ b/drivers/gpu/drm/amd/amdgpu/Makefile
@@ -98,7 +98,7 @@ amdgpu-y += \
vega20_reg_init.o nbio_v7_4.o nbio_v2_3.o nv.o arct_reg_init.o 
mxgpu_nv.o \
nbio_v7_2.o hdp_v4_0.o hdp_v5_0.o aldebaran_reg_init.o aldebaran.o 
soc21.o \
sienna_cichlid.o smu_v13_0_10.o nbio_v4_3.o hdp_v6_0.o nbio_v7_7.o 
hdp_v5_2.o lsdma_v6_0.o \
-   nbio_v7_9.o aqua_vanjaram_reg_init.o
+   nbio_v7_9.o aqua_vanjaram.o
 
 # add DF block
 amdgpu-y += \
diff --git a/drivers/gpu/drm/amd/amdgpu/aqua_vanjaram_reg_init.c 
b/drivers/gpu/drm/amd/amdgpu/aqua_vanjaram.c
similarity index 100%
rename from drivers/gpu/drm/amd/amdgpu/aqua_vanjaram_reg_init.c
rename to drivers/gpu/drm/amd/amdgpu/aqua_vanjaram.c
-- 
2.25.1



RE: [PATCH] drm/amdgpu: Add vbios attribute only if supported

2023-06-15 Thread Ma, Le
[AMD Official Use Only - General]

Reviewed-by: Le Ma 

> -Original Message-
> From: amd-gfx  On Behalf Of Lijo
> Lazar
> Sent: Thursday, June 15, 2023 4:56 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander ; Ma, Le
> ; Kamal, Asad ; Zhang, Hawking
> 
> Subject: [PATCH] drm/amdgpu: Add vbios attribute only if supported
>
> Not all devices carry VBIOS version information. Add the device attribute 
> only if
> supported.
>
> Signed-off-by: Lijo Lazar 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c | 9 +
> drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.h | 1 +
>  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c   | 5 +
>  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c  | 2 --
>  4 files changed, 15 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c
> index 9ba4817a9148..f4e3c133a16c 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c
> @@ -1791,6 +1791,15 @@ const struct attribute_group
> amdgpu_vbios_version_attr_group = {
>   .attrs = amdgpu_vbios_version_attrs
>  };
>
> +int amdgpu_atombios_sysfs_init(struct amdgpu_device *adev) {
> + if (adev->mode_info.atom_context)
> + return devm_device_add_group(adev->dev,
> +
> &amdgpu_vbios_version_attr_group);
> +
> + return 0;
> +}
> +
>  /**
>   * amdgpu_atombios_fini - free the driver info and callbacks for atombios
>   *
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.h
> index 4153d520e2a3..b639a80ee3fc 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.h
> @@ -217,5 +217,6 @@ int amdgpu_atombios_get_data_table(struct
> amdgpu_device *adev,
>
>  void amdgpu_atombios_fini(struct amdgpu_device *adev);  int
> amdgpu_atombios_init(struct amdgpu_device *adev);
> +int amdgpu_atombios_sysfs_init(struct amdgpu_device *adev);
>
>  #endif
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> index e25f085ee886..eda0a598722e 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> @@ -4018,6 +4018,11 @@ int amdgpu_device_init(struct amdgpu_device *adev,
>   /* Get a log2 for easy divisions. */
>   adev->mm_stats.log2_max_MBps = ilog2(max(1u, max_MBps));
>
> + r = amdgpu_atombios_sysfs_init(adev);
> + if (r)
> + drm_err(&adev->ddev,
> + "registering atombios sysfs failed (%d).\n", r);
> +
>   r = amdgpu_pm_sysfs_init(adev);
>   if (r)
>   DRM_ERROR("registering pm sysfs failed (%d).\n", r); diff --git
> a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> index 999d008b6b48..70455b00c36e 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> @@ -2896,12 +2896,10 @@ static struct pci_error_handlers
> amdgpu_pci_err_handler = {
>
>  extern const struct attribute_group amdgpu_vram_mgr_attr_group;  extern
> const struct attribute_group amdgpu_gtt_mgr_attr_group; -extern const struct
> attribute_group amdgpu_vbios_version_attr_group;
>
>  static const struct attribute_group *amdgpu_sysfs_groups[] = {
>   &amdgpu_vram_mgr_attr_group,
>   &amdgpu_gtt_mgr_attr_group,
> - &amdgpu_vbios_version_attr_group,
>   NULL,
>  };
>
> --
> 2.25.1



Re: Fw: [PATCH] drm/amdgpu: add amdgpu_timeout_ring_* file to debugfs

2023-06-15 Thread Christian König

Am 15.06.23 um 10:55 schrieb Nicolai Hähnle:

On Thu, Jun 15, 2023 at 9:47 AM Christian König
 wrote:

Uh, that's very dangerous what you do here and wouldn't work in a whole
bunch of cases.

Please elaborate: *what* case doesn't work?

The core memory management can wait at any time for the GPU reset to finish.

If we set the timeout to infinity we risk just deadlocking the kernel.

Okay, thanks. I may have seen some aspect of this before in cases
where GPU reset failed and left processes in an unkillable state.

I'll be honest, I've seen my fair share of exotic GPU hangs and to put
it mildly I'm not impressed by the kernel's handling of them.


Yeah, and I completely agree with you. The whole situation around that 
is just horrible.



Obviously you know much more about the intricacies of kernel memory
management than I do, but the fact that processes can end up in an
unkillable state for *any* GPU-related reason feels to me like the
result of a bad design decision somewhere.

But anyway, I'm not even asking you to fix those problems. All I'm
asking you is to let me do *my* job, part of which is to help prevent
GPU hangs from happening in the first place. For that, I need useful
debugging facilities -- and so do others.



Again, being able to disable GPU recovery is a crucial debugging
feature. We need to be able to inspect the live state of hung shaders,
and we need to be able to single-step through shaders. All of that
requires disabling GPU recovery.

Yeah, I'm perfectly aware of that. The problem is this is just *not*
supported on Linux for graphics shaders.

What you can do is to run the shader with something like CWSR enabled
(or an to be invented graphics equivalent). Since we are debugging the
shader anyway that should be possible I think.


Forcing people to reboot just to be able to disable GPU recovery for
debugging is developer hostile.

Well, I think you misunderstood me. The suggestion was even to force
them to re-compile the kernel driver to disable GPU recovery.

Disabling GPU recovery is *not* something you can do and expect the
system to be stable.

The only case we can do that is when we attach a JTAG debugger in an AMD
lab.

You're being *completely* unreasonable here. Even Windows(!) allows
disabling GPU recovery at runtime from software, and Windows is
usually far more developer hostile than Linux in these things.
Seriously, this level of hostility against developers coming from you
is not okay.


Well, I'm not hostile against developers, but just realistic that this 
will lead to even more problems.


And I rather avoid problems with end-users than with developers because 
the later are usually the more skilled people.


As far as I can see that Windows allowed to disable GPU recovery was 
actually the source of the problem and is absolutely no argument to 
repeat the same mistake on Linux again.



Yes, it's a tool that has sharp edges. That is perfectly well
understood. If we need to add warning labels then so be it. And if the
details of *how* to change the timeout or disable GPU recovery at
runtime should be changed, that too is fine. But it's an important
tool. Can we please just move forward on this in a pragmatic fashion?


Yes and because of this I'm just rejecting this approach here.

Rebooting to disable GPU reset is perfectly fine and reasonable to do 
for a developer.


As I said the requirement I have for the other extreme is to make it a 
compile time only option and I'm trying to avoid that as well.


Regards,
Christian.



Thanks,
Nicolai



Regards,
Christian.


So again, if there really are cases where this "doesn't work" (and
those cases aren't just that your desktop will freeze -- that part is
intentional), then let's talk through it and see how to address them.

Thanks,
Nicolai



Regards,
Christian.


Signed-off-by: Nicolai Hähnle 
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c | 32 +++-
1 file changed, 31 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c
index dc474b809604..32d223daa789 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c
@@ -471,35 +471,65 @@ static ssize_t amdgpu_debugfs_ring_read(struct file *f, 
char __user *buf,

 return result;
}

static const struct file_operations amdgpu_debugfs_ring_fops = {
 .owner = THIS_MODULE,
 .read = amdgpu_debugfs_ring_read,
 .llseek = default_llseek
};

+static int amdgpu_debugfs_timeout_ring_get(void *data, u64 *val) {
+ struct amdgpu_ring *ring = data;
+
+ if (ring->sched.timeout == MAX_SCHEDULE_TIMEOUT)
+ *val = 0;
+ else
+ *val = jiffies_to_msecs(ring->sched.timeout);
+
+ return 0;
+}
+
+static int amdgpu_debugfs_timeout_ring_set(void *data, u64 val) {
+ struct amdgpu_ring *ring = data;
+
+ if (val == 0)
+ ring->sched.timeout = MAX_SCHEDULE_TIMEOUT;
+ 

[PATCH] drm/amdgpu: Add vbios attribute only if supported

2023-06-15 Thread Lijo Lazar
Not all devices carry VBIOS version information. Add the device
attribute only if supported.

Signed-off-by: Lijo Lazar 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c | 9 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.h | 1 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c   | 5 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c  | 2 --
 4 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c
index 9ba4817a9148..f4e3c133a16c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c
@@ -1791,6 +1791,15 @@ const struct attribute_group 
amdgpu_vbios_version_attr_group = {
.attrs = amdgpu_vbios_version_attrs
 };
 
+int amdgpu_atombios_sysfs_init(struct amdgpu_device *adev)
+{
+   if (adev->mode_info.atom_context)
+   return devm_device_add_group(adev->dev,
+&amdgpu_vbios_version_attr_group);
+
+   return 0;
+}
+
 /**
  * amdgpu_atombios_fini - free the driver info and callbacks for atombios
  *
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.h
index 4153d520e2a3..b639a80ee3fc 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.h
@@ -217,5 +217,6 @@ int amdgpu_atombios_get_data_table(struct amdgpu_device 
*adev,
 
 void amdgpu_atombios_fini(struct amdgpu_device *adev);
 int amdgpu_atombios_init(struct amdgpu_device *adev);
+int amdgpu_atombios_sysfs_init(struct amdgpu_device *adev);
 
 #endif
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index e25f085ee886..eda0a598722e 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -4018,6 +4018,11 @@ int amdgpu_device_init(struct amdgpu_device *adev,
/* Get a log2 for easy divisions. */
adev->mm_stats.log2_max_MBps = ilog2(max(1u, max_MBps));
 
+   r = amdgpu_atombios_sysfs_init(adev);
+   if (r)
+   drm_err(&adev->ddev,
+   "registering atombios sysfs failed (%d).\n", r);
+
r = amdgpu_pm_sysfs_init(adev);
if (r)
DRM_ERROR("registering pm sysfs failed (%d).\n", r);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 999d008b6b48..70455b00c36e 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -2896,12 +2896,10 @@ static struct pci_error_handlers amdgpu_pci_err_handler 
= {
 
 extern const struct attribute_group amdgpu_vram_mgr_attr_group;
 extern const struct attribute_group amdgpu_gtt_mgr_attr_group;
-extern const struct attribute_group amdgpu_vbios_version_attr_group;
 
 static const struct attribute_group *amdgpu_sysfs_groups[] = {
&amdgpu_vram_mgr_attr_group,
&amdgpu_gtt_mgr_attr_group,
-   &amdgpu_vbios_version_attr_group,
NULL,
 };
 
-- 
2.25.1



Re: Fw: [PATCH] drm/amdgpu: add amdgpu_timeout_ring_* file to debugfs

2023-06-15 Thread Nicolai Hähnle
On Thu, Jun 15, 2023 at 9:47 AM Christian König
 wrote:
> >> Uh, that's very dangerous what you do here and wouldn't work in a whole
> >> bunch of cases.
> > Please elaborate: *what* case doesn't work?
>
> The core memory management can wait at any time for the GPU reset to finish.
>
> If we set the timeout to infinity we risk just deadlocking the kernel.

Okay, thanks. I may have seen some aspect of this before in cases
where GPU reset failed and left processes in an unkillable state.

I'll be honest, I've seen my fair share of exotic GPU hangs and to put
it mildly I'm not impressed by the kernel's handling of them.
Obviously you know much more about the intricacies of kernel memory
management than I do, but the fact that processes can end up in an
unkillable state for *any* GPU-related reason feels to me like the
result of a bad design decision somewhere.

But anyway, I'm not even asking you to fix those problems. All I'm
asking you is to let me do *my* job, part of which is to help prevent
GPU hangs from happening in the first place. For that, I need useful
debugging facilities -- and so do others.


> > Again, being able to disable GPU recovery is a crucial debugging
> > feature. We need to be able to inspect the live state of hung shaders,
> > and we need to be able to single-step through shaders. All of that
> > requires disabling GPU recovery.
>
> Yeah, I'm perfectly aware of that. The problem is this is just *not*
> supported on Linux for graphics shaders.
>
> What you can do is to run the shader with something like CWSR enabled
> (or an to be invented graphics equivalent). Since we are debugging the
> shader anyway that should be possible I think.
>
> > Forcing people to reboot just to be able to disable GPU recovery for
> > debugging is developer hostile.
>
> Well, I think you misunderstood me. The suggestion was even to force
> them to re-compile the kernel driver to disable GPU recovery.
>
> Disabling GPU recovery is *not* something you can do and expect the
> system to be stable.
>
> The only case we can do that is when we attach a JTAG debugger in an AMD
> lab.

You're being *completely* unreasonable here. Even Windows(!) allows
disabling GPU recovery at runtime from software, and Windows is
usually far more developer hostile than Linux in these things.
Seriously, this level of hostility against developers coming from you
is not okay.

Yes, it's a tool that has sharp edges. That is perfectly well
understood. If we need to add warning labels then so be it. And if the
details of *how* to change the timeout or disable GPU recovery at
runtime should be changed, that too is fine. But it's an important
tool. Can we please just move forward on this in a pragmatic fashion?

Thanks,
Nicolai


>
> Regards,
> Christian.
>
> >
> > So again, if there really are cases where this "doesn't work" (and
> > those cases aren't just that your desktop will freeze -- that part is
> > intentional), then let's talk through it and see how to address them.
> >
> > Thanks,
> > Nicolai
> >
> >
> >> Regards,
> >> Christian.
> >>
> >>> Signed-off-by: Nicolai Hähnle 
> >>> ---
> >>>drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c | 32 +++-
> >>>1 file changed, 31 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c 
> >>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c
> >>> index dc474b809604..32d223daa789 100644
> >>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c
> >>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c
> >>> @@ -471,35 +471,65 @@ static ssize_t amdgpu_debugfs_ring_read(struct file 
> >>> *f, char __user *buf,
> >>>
> >>> return result;
> >>>}
> >>>
> >>>static const struct file_operations amdgpu_debugfs_ring_fops = {
> >>> .owner = THIS_MODULE,
> >>> .read = amdgpu_debugfs_ring_read,
> >>> .llseek = default_llseek
> >>>};
> >>>
> >>> +static int amdgpu_debugfs_timeout_ring_get(void *data, u64 *val) {
> >>> + struct amdgpu_ring *ring = data;
> >>> +
> >>> + if (ring->sched.timeout == MAX_SCHEDULE_TIMEOUT)
> >>> + *val = 0;
> >>> + else
> >>> + *val = jiffies_to_msecs(ring->sched.timeout);
> >>> +
> >>> + return 0;
> >>> +}
> >>> +
> >>> +static int amdgpu_debugfs_timeout_ring_set(void *data, u64 val) {
> >>> + struct amdgpu_ring *ring = data;
> >>> +
> >>> + if (val == 0)
> >>> + ring->sched.timeout = MAX_SCHEDULE_TIMEOUT;
> >>> + else
> >>> + ring->sched.timeout = msecs_to_jiffies(val);
> >>> +
> >>> + return 0;
> >>> +}
> >>> +
> >>> +DEFINE_DEBUGFS_ATTRIBUTE(amdgpu_debugfs_timeout_ring_fops,
> >>> +  amdgpu_debugfs_timeout_ring_get,
> >>> +  amdgpu_debugfs_timeout_ring_set,
> >>> +  "%llu\n");
> >>> +
> >>>#endif
> >>>
> >>>void amdgpu_debugfs_ring_init(struct amdgpu_device *adev,
> >>>   struct amdgpu_ring *ring)
> >>>{
> >>>

Re: [PATCH 1/6] drm/amdgpu/bu: Use legacy TLB flush for gfx943

2023-06-15 Thread Christian König
All those workaround were only to be used during bringup and are not 
supposed for upstreaming.


Especially we probably don't want the module parameter to override the 
MTYPE used in the VM mappings in a release.


Christian.

Am 10.05.23 um 19:56 schrieb Alex Deucher:

From: Graham Sider 

Invalidate TLBs via a legacy flush request (flush_type=0) prior to the
heavyweight flush requests (flush_type=2) in gmc_v9_0.c. This is
temporarily required to mitigate a bug causing CPC UTCL1 to return stale
translations after invalidation requests in address range mode.

Signed-off-by: Graham Sider 
Reviewed-by: Philip Yang 
Signed-off-by: Alex Deucher 
---
  drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 17 +
  1 file changed, 17 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c 
b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
index f000e0e89bd0..d28ffdb07ae6 100644
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
@@ -833,6 +833,14 @@ static void gmc_v9_0_flush_gpu_tlb(struct amdgpu_device 
*adev, uint32_t vmid,
 */
inv_req = gmc_v9_0_get_invalidate_req(vmid, 2);
inv_req2 = gmc_v9_0_get_invalidate_req(vmid, flush_type);
+   } else if (flush_type == 2 &&
+  adev->ip_versions[GC_HWIP][0] == IP_VERSION(9, 4, 3)) {
+   /* FIXME: Temporarily add a legacy flush (type 0) before 
heavyweight
+* flush for gfx943 to mitigate a bug which causes CPC UTCL1 to 
return
+* stale translations even after TLB heavyweight flush.
+*/
+   inv_req = gmc_v9_0_get_invalidate_req(vmid, 0);
+   inv_req2 = gmc_v9_0_get_invalidate_req(vmid, flush_type);
} else {
inv_req = gmc_v9_0_get_invalidate_req(vmid, flush_type);
inv_req2 = 0;
@@ -976,6 +984,15 @@ static int gmc_v9_0_flush_gpu_tlb_pasid(struct 
amdgpu_device *adev,
if (vega20_xgmi_wa)
kiq->pmf->kiq_invalidate_tlbs(ring,
  pasid, 2, all_hub);
+
+   /* FIXME: Temporarily add a legacy flush (type 0) before 
heavyweight
+* flush for gfx943 to mitigate a bug which causes CPC UTCL1 to 
return
+* stale translations even after TLB heavyweight flush.
+*/
+   if (flush_type == 2 && adev->ip_versions[GC_HWIP][0] == 
IP_VERSION(9, 4, 3))
+   kiq->pmf->kiq_invalidate_tlbs(ring,
+   pasid, 0, all_hub);
+
kiq->pmf->kiq_invalidate_tlbs(ring,
pasid, flush_type, all_hub);
r = amdgpu_fence_emit_polling(ring, &seq, MAX_KIQ_REG_WAIT);




Re: [PATCH 1/2] drm/amdgpu: make sure BOs are locked in amdgpu_vm_get_memory

2023-06-15 Thread Christian König

Am 06.06.23 um 03:11 schrieb Chen, Guchun:

[Public]

Acked-by: Guchun Chen  for this series.

A simple question is we don't need to hold the lock if bo locations are not 
changed?


Well we take the look to make sure that BO locations don't change.

Otherwise we potentially access freed memory when looking at the resource.

Regards,
Christian.



Regards,
Guchun


-Original Message-
From: Christian König 
Sent: Monday, June 5, 2023 5:11 PM
To: amd-gfx@lists.freedesktop.org; mikhail.v.gavri...@gmail.com; Chen,
Guchun 
Subject: [PATCH 1/2] drm/amdgpu: make sure BOs are locked in
amdgpu_vm_get_memory

We need to grab the lock of the BO or otherwise can run into a crash when
we try to inspect the current location.

Signed-off-by: Christian König 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 69 +++-
--
  1 file changed, 39 insertions(+), 30 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index 3c0310576b3b..2c8cafec48a4 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -920,42 +920,51 @@ int amdgpu_vm_update_range(struct
amdgpu_device *adev, struct amdgpu_vm *vm,
   return r;
  }

+static void amdgpu_vm_bo_get_memory(struct amdgpu_bo_va *bo_va,
+ struct amdgpu_mem_stats *stats) {
+ struct amdgpu_vm *vm = bo_va->base.vm;
+ struct amdgpu_bo *bo = bo_va->base.bo;
+
+ if (!bo)
+ return;
+
+ /*
+  * For now ignore BOs which are currently locked and potentially
+  * changing their location.
+  */
+ if (bo->tbo.base.resv != vm->root.bo->tbo.base.resv &&
+ !dma_resv_trylock(bo->tbo.base.resv))
+ return;
+
+ amdgpu_bo_get_memory(bo, stats);
+ if (bo->tbo.base.resv != vm->root.bo->tbo.base.resv)
+ dma_resv_unlock(bo->tbo.base.resv);
+}
+
  void amdgpu_vm_get_memory(struct amdgpu_vm *vm,
 struct amdgpu_mem_stats *stats)
  {
   struct amdgpu_bo_va *bo_va, *tmp;

   spin_lock(&vm->status_lock);
- list_for_each_entry_safe(bo_va, tmp, &vm->idle, base.vm_status) {
- if (!bo_va->base.bo)
- continue;
- amdgpu_bo_get_memory(bo_va->base.bo, stats);
- }
- list_for_each_entry_safe(bo_va, tmp, &vm->evicted, base.vm_status)
{
- if (!bo_va->base.bo)
- continue;
- amdgpu_bo_get_memory(bo_va->base.bo, stats);
- }
- list_for_each_entry_safe(bo_va, tmp, &vm->relocated,
base.vm_status) {
- if (!bo_va->base.bo)
- continue;
- amdgpu_bo_get_memory(bo_va->base.bo, stats);
- }
- list_for_each_entry_safe(bo_va, tmp, &vm->moved, base.vm_status)
{
- if (!bo_va->base.bo)
- continue;
- amdgpu_bo_get_memory(bo_va->base.bo, stats);
- }
- list_for_each_entry_safe(bo_va, tmp, &vm->invalidated,
base.vm_status) {
- if (!bo_va->base.bo)
- continue;
- amdgpu_bo_get_memory(bo_va->base.bo, stats);
- }
- list_for_each_entry_safe(bo_va, tmp, &vm->done, base.vm_status) {
- if (!bo_va->base.bo)
- continue;
- amdgpu_bo_get_memory(bo_va->base.bo, stats);
- }
+ list_for_each_entry_safe(bo_va, tmp, &vm->idle, base.vm_status)
+ amdgpu_vm_bo_get_memory(bo_va, stats);
+
+ list_for_each_entry_safe(bo_va, tmp, &vm->evicted, base.vm_status)
+ amdgpu_vm_bo_get_memory(bo_va, stats);
+
+ list_for_each_entry_safe(bo_va, tmp, &vm->relocated,
base.vm_status)
+ amdgpu_vm_bo_get_memory(bo_va, stats);
+
+ list_for_each_entry_safe(bo_va, tmp, &vm->moved, base.vm_status)
+ amdgpu_vm_bo_get_memory(bo_va, stats);
+
+ list_for_each_entry_safe(bo_va, tmp, &vm->invalidated,
base.vm_status)
+ amdgpu_vm_bo_get_memory(bo_va, stats);
+
+ list_for_each_entry_safe(bo_va, tmp, &vm->done, base.vm_status)
+ amdgpu_vm_bo_get_memory(bo_va, stats);
   spin_unlock(&vm->status_lock);
  }

--
2.34.1




Re: Fw: [PATCH] drm/amdgpu: add amdgpu_timeout_ring_* file to debugfs

2023-06-15 Thread Christian König

Am 14.06.23 um 21:20 schrieb Nicolai Hähnle:

Hi Christian,


Report the per-ring timeout in milliseconds and allow users to adjust
the timeout dynamically. This can be useful for debugging, e.g. to more
easily test whether a submission genuinely hangs or is just taking very
long, and to temporarily disable GPU recovery so that shader problems
can be examined in detail, including single-stepping through shader
code.

It feels a bit questionable to access ring->sched.timeout without any
locking -- under a C++ memory model it would technically be undefined
behavior. But it's not like a lot can go wrong here in practice, and
it's not clear to me what locking or atomics, if any, should be used.

Uh, that's very dangerous what you do here and wouldn't work in a whole
bunch of cases.

Please elaborate: *what* case doesn't work?


The core memory management can wait at any time for the GPU reset to finish.

If we set the timeout to infinity we risk just deadlocking the kernel.

See here as well: https://lpc.events/event/11/contributions/1115/





First of all GPU recovery is part of normal operation and necessary for
system stability. So disabling GPU recovery is actually not a good idea
in the first place.

That's a complete non-argument because the whole point of this is that
it is a debugging feature. You're using this when the system as a
whole (most likely a UMD component) is already broken in some way.
Putting this in debugfs is not an accident.



We already discussed that we probably need to taint the kernel if we do
so to indicate in crash logs that the system is not considered stable
any more. The problem was only that there wasn't an agreement on how to
do this.

I'd be happy to add kernel tainting if you tell me how.



Since this here now makes it even easier to disable GPU recovery it's
probably not the right approach.

Again, being able to disable GPU recovery is a crucial debugging
feature. We need to be able to inspect the live state of hung shaders,
and we need to be able to single-step through shaders. All of that
requires disabling GPU recovery.


Yeah, I'm perfectly aware of that. The problem is this is just *not* 
supported on Linux for graphics shaders.


What you can do is to run the shader with something like CWSR enabled 
(or an to be invented graphics equivalent). Since we are debugging the 
shader anyway that should be possible I think.



Forcing people to reboot just to be able to disable GPU recovery for
debugging is developer hostile.


Well, I think you misunderstood me. The suggestion was even to force 
them to re-compile the kernel driver to disable GPU recovery.


Disabling GPU recovery is *not* something you can do and expect the 
system to be stable.


The only case we can do that is when we attach a JTAG debugger in an AMD 
lab.


Regards,
Christian.



So again, if there really are cases where this "doesn't work" (and
those cases aren't just that your desktop will freeze -- that part is
intentional), then let's talk through it and see how to address them.

Thanks,
Nicolai



Regards,
Christian.


Signed-off-by: Nicolai Hähnle 
---
   drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c | 32 +++-
   1 file changed, 31 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c
index dc474b809604..32d223daa789 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c
@@ -471,35 +471,65 @@ static ssize_t amdgpu_debugfs_ring_read(struct file *f, 
char __user *buf,

return result;
   }

   static const struct file_operations amdgpu_debugfs_ring_fops = {
.owner = THIS_MODULE,
.read = amdgpu_debugfs_ring_read,
.llseek = default_llseek
   };

+static int amdgpu_debugfs_timeout_ring_get(void *data, u64 *val) {
+ struct amdgpu_ring *ring = data;
+
+ if (ring->sched.timeout == MAX_SCHEDULE_TIMEOUT)
+ *val = 0;
+ else
+ *val = jiffies_to_msecs(ring->sched.timeout);
+
+ return 0;
+}
+
+static int amdgpu_debugfs_timeout_ring_set(void *data, u64 val) {
+ struct amdgpu_ring *ring = data;
+
+ if (val == 0)
+ ring->sched.timeout = MAX_SCHEDULE_TIMEOUT;
+ else
+ ring->sched.timeout = msecs_to_jiffies(val);
+
+ return 0;
+}
+
+DEFINE_DEBUGFS_ATTRIBUTE(amdgpu_debugfs_timeout_ring_fops,
+  amdgpu_debugfs_timeout_ring_get,
+  amdgpu_debugfs_timeout_ring_set,
+  "%llu\n");
+
   #endif

   void amdgpu_debugfs_ring_init(struct amdgpu_device *adev,
  struct amdgpu_ring *ring)
   {
   #if defined(CONFIG_DEBUG_FS)
struct drm_minor *minor = adev_to_drm(adev)->primary;
struct dentry *root = minor->debugfs_root;
- char name[32];
+ char name[40];

sprintf(name, "amdgpu_ring_%s", ring->name);
debugfs_create_file_size(name, S_IFREG | S_IRUGO, root, ring,

Re: [PATCH 2/3] drm/amdgpu: Implement new dummy vram manager

2023-06-15 Thread Christian König

Am 14.06.23 um 17:42 schrieb Felix Kuehling:

Am 2023-06-14 um 06:38 schrieb Christian König:

Am 10.05.23 um 00:01 schrieb Alex Deucher:

From: Rajneesh Bhardwaj 

This adds dummy vram manager to support ASICs that do not have a
dedicated or carvedout vram domain.


Well that doesn't seem to make much sense. Why we should have that?


TTM always expects a resource manager for VRAM. There are no NULL 
pointer checks in TTM for not having a resource manager for VRAM. The 
existing amdgpu_vram_mgr gets confused if there is no VRAM. It seemed 
cleaner to add a dummy manager than to scatter conditions for a 
memory-less GPU corner case through the regular VRAM manager.


Well no that's absolutely *not* cleaner. TTM has a predefined manager if 
you need to use a dummy.


Why the heck didn't you ask me before doing stuff like that?

Regards,
Christian.



Regards,
  Felix




Christian.



Reviewed-by: Felix Kuehling 
Signed-off-by: Rajneesh Bhardwaj 
Signed-off-by: Alex Deucher 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 67 
++--

  1 file changed, 60 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c

index 43d6a9d6a538..89d35d194f2c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
@@ -370,6 +370,45 @@ int amdgpu_vram_mgr_query_page_status(struct 
amdgpu_vram_mgr *mgr,

  return ret;
  }
  +static void amdgpu_dummy_vram_mgr_debug(struct 
ttm_resource_manager *man,

+  struct drm_printer *printer)
+{
+    DRM_DEBUG_DRIVER("Dummy vram mgr debug\n");
+}
+
+static bool amdgpu_dummy_vram_mgr_compatible(struct 
ttm_resource_manager *man,

+   struct ttm_resource *res,
+   const struct ttm_place *place,
+   size_t size)
+{
+    DRM_DEBUG_DRIVER("Dummy vram mgr compatible\n");
+    return false;
+}
+
+static bool amdgpu_dummy_vram_mgr_intersects(struct 
ttm_resource_manager *man,

+   struct ttm_resource *res,
+   const struct ttm_place *place,
+   size_t size)
+{
+    DRM_DEBUG_DRIVER("Dummy vram mgr intersects\n");
+    return true;
+}
+
+static void amdgpu_dummy_vram_mgr_del(struct ttm_resource_manager 
*man,

+    struct ttm_resource *res)
+{
+    DRM_DEBUG_DRIVER("Dummy vram mgr deleted\n");
+}
+
+static int amdgpu_dummy_vram_mgr_new(struct ttm_resource_manager *man,
+   struct ttm_buffer_object *tbo,
+   const struct ttm_place *place,
+   struct ttm_resource **res)
+{
+    DRM_DEBUG_DRIVER("Dummy vram mgr new\n");
+    return -ENOSPC;
+}
+
  /**
   * amdgpu_vram_mgr_new - allocate new ranges
   *
@@ -817,6 +856,14 @@ static void amdgpu_vram_mgr_debug(struct 
ttm_resource_manager *man,

  mutex_unlock(&mgr->lock);
  }
  +static const struct ttm_resource_manager_func 
amdgpu_dummy_vram_mgr_func = {

+    .alloc    = amdgpu_dummy_vram_mgr_new,
+    .free    = amdgpu_dummy_vram_mgr_del,
+    .intersects = amdgpu_dummy_vram_mgr_intersects,
+    .compatible = amdgpu_dummy_vram_mgr_compatible,
+    .debug    = amdgpu_dummy_vram_mgr_debug
+};
+
  static const struct ttm_resource_manager_func amdgpu_vram_mgr_func 
= {

  .alloc    = amdgpu_vram_mgr_new,
  .free    = amdgpu_vram_mgr_del,
@@ -841,17 +888,22 @@ int amdgpu_vram_mgr_init(struct amdgpu_device 
*adev)

  ttm_resource_manager_init(man, &adev->mman.bdev,
    adev->gmc.real_vram_size);
  -    man->func = &amdgpu_vram_mgr_func;
-
-    err = drm_buddy_init(&mgr->mm, man->size, PAGE_SIZE);
-    if (err)
-    return err;
-
  mutex_init(&mgr->lock);
  INIT_LIST_HEAD(&mgr->reservations_pending);
  INIT_LIST_HEAD(&mgr->reserved_pages);
  mgr->default_page_size = PAGE_SIZE;
  +    if (!adev->gmc.is_app_apu) {
+    man->func = &amdgpu_vram_mgr_func;
+
+    err = drm_buddy_init(&mgr->mm, man->size, PAGE_SIZE);
+    if (err)
+    return err;
+    } else {
+    man->func = &amdgpu_dummy_vram_mgr_func;
+    DRM_INFO("Setup dummy vram mgr\n");
+    }
+
  ttm_set_driver_manager(&adev->mman.bdev, TTM_PL_VRAM, 
&mgr->manager);

  ttm_resource_manager_set_used(man, true);
  return 0;
@@ -886,7 +938,8 @@ void amdgpu_vram_mgr_fini(struct amdgpu_device 
*adev)

  drm_buddy_free_list(&mgr->mm, &rsv->allocated);
  kfree(rsv);
  }
-    drm_buddy_fini(&mgr->mm);
+    if (!adev->gmc.is_app_apu)
+    drm_buddy_fini(&mgr->mm);
  mutex_unlock(&mgr->lock);
    ttm_resource_manager_cleanup(man);






Re: [RFC PATCH v2 00/18] Add DRM CRTC 3D LUT interface

2023-06-15 Thread Pekka Paalanen
On Tue, 13 Jun 2023 17:43:55 +0200
Jacopo Mondi  wrote:

> Hello
> 
>I'm completing the support for 3D LUT on R-Car DU peripheral
> and I have used this series as a base.
> 
> I'm wondering, since quite some time has passed without any update if
> this series is still a thing and it makes any sense for me to try to
> bring it forward.
> 
> I'm asking as I've noticed:
> "[PATCH 00/36] drm/amd/display: add AMD driver-specific properties for color 
> mgmt"
> 
> which seems to supersede this proposal with driver-specific
> properties.
> 
> I asked Melissa privately but I wasn't able to get an hold of her, so
> if anyone has any clue feel free to reply :)

Hi,

since no-one else replied, I'll point you to the thread starting at
https://lists.freedesktop.org/archives/dri-devel/2023-May/403173.html
and continuing to June. That is the plan of getting a common UAPI for
these things.


Thanks,
pq


> 
> Thanks
>   j
> 
> On Mon, Jan 09, 2023 at 01:38:28PM -0100, Melissa Wen wrote:
> > Hi,
> >
> > After collecting comments in different places, here is a second version
> > of the work on adding DRM CRTC 3D LUT support to the current DRM color
> > mgmt interface. In comparison to previous proposals [1][2][3], here we
> > add 3D LUT before gamma 1D LUT, but also a shaper 1D LUT before 3D LUT,
> > that means the following DRM CRTC color correction pipeline:
> >
> > Blend -> Degamma 1D LUT -> CTM -> Shaper 1D LUT -> 3D LUT -> Gamma 1D LUT
> >
> > and we also add a DRM CRTC LUT3D_MODE property, based on Alex Hung
> > proposal for pre-blending 3D LUT [4] (Thanks!), instead of just a
> > LUT3D_SIZE, that allows userspace to use different supported settings of
> > 3D LUT, fitting VA-API and new color API better. In this sense, I
> > adjusted the pre-blending proposal for post-blending usage.
> >
> > Patches 1-6 targets the addition of shaper LUT and 3D LUT properties to
> > the current DRM CRTC color mgmt pipeline. Patch 6 can be considered an
> > extra/optional patch to define a default value for LUT3D_MODE, inspired
> > by what we do for the plane blend mode property (pre-multiplied).
> >
> > Patches 7-18 targets AMD display code to enable shaper and 3D LUT usage
> > on DCN 301 (our HW case). Patches 7-9 performs code cleanups on current
> > AMD DM colors code, patch 10 updates AMD stream in case of user 3D LUT
> > changes, patch 11/12 rework AMD MPC 3D LUT resource handling by context
> > for DCN 301 (easily extendible to other DCN families). Finally, from
> > 13-18, we wire up SHAPER LUT, LUT3D and LUT3D MODE to AMD display
> > driver, exposing modes supported by HW and programming user shaper and
> > 3D LUT accordingly.
> >
> > Our target userspace is Gamescope/SteamOS.
> >
> > Basic IGT tests were based on [5][6] and are available here (in-progress):
> > https://gitlab.freedesktop.org/mwen/igt-gpu-tools/-/commits/crtc-lut3d-api
> >
> > [1] 
> > https://lore.kernel.org/all/20201221015730.28333-1-laurent.pinchart+rene...@ideasonboard.com/
> > [2] 
> > https://github.com/vsyrjala/linux/commit/4d28e8ddf2a076f30f9e5bdc17cbb4656fe23e69
> > [3] https://lore.kernel.org/amd-gfx/20220619223104.667413-1-m...@igalia.com/
> > [4] 
> > https://lore.kernel.org/dri-devel/20221004211451.1475215-1-alex.h...@amd.com/
> > [5] https://patchwork.freedesktop.org/series/90165/
> > [6] https://patchwork.freedesktop.org/series/109402/
> > [VA_API] 
> > http://intel.github.io/libva/structVAProcFilterParameterBuffer3DLUT.html
> > [KMS_pipe_API] https://gitlab.freedesktop.org/pq/color-and-hdr/-/issues/11
> >
> > Let me know your thoughts.
> >
> > Thanks,
> >
> > Melissa
> >
> > Alex Hung (2):
> >   drm: Add 3D LUT mode and its attributes
> >   drm/amd/display: Define 3D LUT struct for HDR planes
> >
> > Melissa Wen (16):
> >   drm/drm_color_mgmt: add shaper LUT to color mgmt properties
> >   drm/drm_color_mgmt: add 3D LUT props to DRM color mgmt
> >   drm/drm_color_mgmt: add function to create 3D LUT modes supported
> >   drm/drm_color_mgmt: add function to attach 3D LUT props
> >   drm/drm_color_mgmt: set first lut3d mode as default
> >   drm/amd/display: remove unused regamma condition
> >   drm/amd/display: add comments to describe DM crtc color mgmt behavior
> >   drm/amd/display: encapsulate atomic regamma operation
> >   drm/amd/display: update lut3d and shaper lut to stream
> >   drm/amd/display: handle MPC 3D LUT resources for a given context
> >   drm/amd/display: acquire/release 3D LUT resources for ctx on DCN301
> >   drm/amd/display: expand array of supported 3D LUT modes
> >   drm/amd/display: enable 3D-LUT DRM properties if supported
> >   drm/amd/display: add user 3D LUT support to the amdgpu_dm color
> > pipeline
> >   drm/amd/display: decouple steps to reuse in shaper LUT support
> >   drm/amd/display: add user shaper LUT support to amdgpu_dm color
> > pipeline
> >
> >  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |   6 +
> >  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h |   3 +
> >  .../amd/display/amdgpu_dm/amdgpu_d